Bug 14594 – REGRESSION: switching to source mode adds xmlns text at the top

• Component: HTML Editing
• Status: RESOLVED WONTFIX

[Alfonso Martínez de Lizarrondo]

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.

[Mark Rowe (bdash)]

The URL you provide results in a 404, so it is not possible to confirm that this bug occurs.

[David Kilzer (:ddkilzer)]

Frederico, what happened to http://www.fckeditor.net/nightly/browsers_test.html?  It's returning a 404 error.

[Alfonso Martínez de Lizarrondo]

Created attachment 15519 [details]
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.

(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.

[David Kilzer (:ddkilzer)]

(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.

[Alexey Proskuryakov]

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().

(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.

[David Kilzer (:ddkilzer)]

(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!

[Alfonso Martínez de Lizarrondo]

(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.

[Alexey Proskuryakov]

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).