14594 2007-07-12 10:29:07 -0700 REGRESSION: switching to source mode adds xmlns text at the top 2007-07-17 07:37:27 -0700 1 1 1 Unclassified WebKit HTML Editing 523.x (Safari 3) Mac OS X 10.4 RESOLVED WONTFIX http://www.fckeditor.net/nightly/browsers_test.html P2 Normal --- 9915 0 amla70 webkit-unassigned ap mrowe webkit oldest_to_newest 4947 0 amla70 2007-07-12 10:29:07 -0700 Load http://www.fckeditor.net/nightly/browsers_test.html and switch to source mode, at the top there will appear a xmlns="http://www.w3.org/1999/xhtml"> text. The demo is working fine (in this aspect) with r24096, but fails now with r24182 If neccesary I might generate a simplified testcase, but at least I would like to know that someone else can confirm the problem. 4887 1 mrowe 2007-07-13 08:46:19 -0700 The URL you provide results in a 404, so it is not possible to confirm that this bug occurs. 4782 2 ddkilzer 2007-07-14 13:24:38 -0700 Frederico, what happened to http://www.fckeditor.net/nightly/browsers_test.html? It's returning a 404 error. 4765 3 15519 amla70 2007-07-14 14:17:34 -0700 Created attachment 15519 Simplified testcase I've thought about the problem and I've creted this testcase, so the url is no longer necessary. The recent nightlies append the xmlns attribute. 4762 4 webkit 2007-07-14 14:31:28 -0700 (In reply to comment #2) > Frederico, what happened to > http://www.fckeditor.net/nightly/browsers_test.html? It's returning a 404 > error. > We have moved to a new server yesterday and that page was missing. I've restored it. Thanks for the prompt advice David. 4725 5 ddkilzer 2007-07-14 16:59:58 -0700 (In reply to comment #3) > Created an attachment (id=15519) [edit] > Simplified testcase > > I've thought about the problem and I've creted this testcase, so the url is no > longer necessary. > The recent nightlies append the xmlns attribute. Both this attachment and the original URL (http://www.fckeditor.net/nightly/browsers_test.html) include the xmlns attribute when downloaded via wget. I don't think Safari is adding this. Please confirm. 4737 6 ap 2007-07-15 00:26:34 -0700 I think this is caused by the fix to bug 8007, and is expected behavior. Document.createElement() now always creates elements in xhtml namespace, and of course, the namespace is serialized to source. One needs to either be prepared to get it, or to use HTML documents created with DOMImplementation.createHTMLDocument(). 4627 7 webkit 2007-07-16 07:04:06 -0700 (In reply to comment #5) > Both this attachment and the original URL > (http://www.fckeditor.net/nightly/browsers_test.html) include the xmlns > attribute when downloaded via wget. I don't think Safari is adding this. > Please confirm. I think you didn't understood it well David. The bug is not in the page itself, but in the editor, which loads inside of it. Just check the original bug description. 4625 8 ddkilzer 2007-07-16 08:14:49 -0700 (In reply to comment #7) > (In reply to comment #5) > > Both this attachment and the original URL > > (http://www.fckeditor.net/nightly/browsers_test.html) include the xmlns > > attribute when downloaded via wget. I don't think Safari is adding this. > > Please confirm. > > I think you didn't understood it well David. The bug is not in the page itself, > but in the editor, which loads inside of it. Just check the original bug > description. Yep, ap explained it in Comment #6. Thanks! 4584 9 amla70 2007-07-16 14:58:17 -0700 (In reply to comment #6) > I think this is caused by the fix to bug 8007, and is expected behavior. > Document.createElement() now always creates elements in xhtml namespace, and of > course, the namespace is serialized to source. One needs to either be prepared > to get it, or to use HTML documents created with > DOMImplementation.createHTMLDocument(). > The only problem with this behavior is that it differs from what Firefox and Opera are doing. It isn't hard to workaround it in this case and even they way that the code is used right now in FCKeditor might be wrong, but as I said the output in Firefox and Opera of the testcase is different. 4533 10 ap 2007-07-17 07:37:27 -0700 We match Firefox in that createElement() always creates HTML elements (even in SVG documents), so the difference is that Firefox uses a null namespace for HTML elements, and we use http://www.w3.org/1999/xhtml. In this, we follow the current HTML5 draft, so Firefox and Opera may get the same behavior some day. Alternatively, a better solution for HTML5 will be found, and then WebKit will need to change again. From the draft: To ease migration from HTML to XHTML, UAs conforming to this specification will place elements in HTML in the http://www.w3.org/1999/xhtml namespace, at least for the purposes of the DOM and CSS. The term "elements in the HTML namespace", or "HTML elements" for short, when used in this specification, thus refers to both HTML and XHTML elements. So, I'm closing this bug as WONTFIX (it's valid in that we don't match other browsers or any final specification, but it was a deliberate decision). 15519 2007-07-14 14:17:34 -0700 2007-07-14 14:17:34 -0700 Simplified testcase xml_serializer.html text/html 739 amla70 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxodG1sIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hodG1sIj4NCjxoZWFk Pg0KCTx0aXRsZT5YTUwgc2VyaWFsaXplcjwvdGl0bGU+DQoJPG1ldGEgaHR0cC1lcXVpdj0iQ29u dGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiIC8+DQoNCjwvaGVh ZD4NCjxib2R5Pg0KCTxzY3JpcHQgdHlwZT0idGV4dC9qYXZhc2NyaXB0Ij4NCg0KCS8vIENyZWF0 ZSB0aGUgWE1MIERPTURvY3VtZW50IG9iamVjdC4NCgl2YXIgWE1MID0gZG9jdW1lbnQuaW1wbGVt ZW50YXRpb24uY3JlYXRlRG9jdW1lbnQoICcnLCAnJywgbnVsbCApIDsNCg0KCS8vIEFkZCBhIHJv b3QgZWxlbWVudCB0aGF0IGhvbGRzIGFsbCBjaGlsZCBub2Rlcy4NCgl2YXIgTWFpbk5vZGUgPSBY TUwuYXBwZW5kQ2hpbGQoIFhNTC5jcmVhdGVFbGVtZW50KCAneGh0bWwnICkgKSA7DQoNCgkvLyBD cmVhdGUgdGhlIFhNTFNlcmlhbGl6ZXIuDQoJdmFyIG9TZXJpYWxpemVyID0gbmV3IFhNTFNlcmlh bGl6ZXIoKSA7DQoNCgkvLyBSZXR1cm4gdGhlIHNlcmlhbGl6ZWQgWE1MIGFzIGEgc3RyaW5nLg0K CXZhciBzWEhUTUwgPSBvU2VyaWFsaXplci5zZXJpYWxpemVUb1N0cmluZyggTWFpbk5vZGUgKSA7 DQoNCg0KYWxlcnQoc1hIVE1MKQ0KDQoNCgk8L3NjcmlwdD4NCjwvYm9keT4NCjwvaHRtbD4NCg==