Bug 14594 - REGRESSION: switching to source mode adds xmlns text at the top
Summary: REGRESSION: switching to source mode adds xmlns text at the top
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: 523.x (Safari 3)
Hardware: Macintosh OS X 10.4
: P2 Normal
Assignee: Nobody
URL: http://www.fckeditor.net/nightly/brow...
Keywords:
Depends on:
Blocks: 9915
  Show dependency treegraph
 
Reported: 2007-07-12 10:29 PDT by Alfonso Martínez de Lizarrondo
Modified: 2007-07-17 07:37 PDT (History)
3 users (show)

See Also:


Attachments
Simplified testcase (739 bytes, text/html)
2007-07-14 14:17 PDT, Alfonso Martínez de Lizarrondo
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alfonso Martínez de Lizarrondo 2007-07-12 10:29:07 PDT
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.
Comment 1 Mark Rowe (bdash) 2007-07-13 08:46:19 PDT
The URL you provide results in a 404, so it is not possible to confirm that this bug occurs.
Comment 2 David Kilzer (:ddkilzer) 2007-07-14 13:24:38 PDT
Frederico, what happened to http://www.fckeditor.net/nightly/browsers_test.html?  It's returning a 404 error.

Comment 3 Alfonso Martínez de Lizarrondo 2007-07-14 14:17:34 PDT
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.
Comment 4 Frederico Caldeira Knabben 2007-07-14 14:31:28 PDT
(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.
Comment 5 David Kilzer (:ddkilzer) 2007-07-14 16:59:58 PDT
(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.

Comment 6 Alexey Proskuryakov 2007-07-15 00:26:34 PDT
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().
Comment 7 Frederico Caldeira Knabben 2007-07-16 07:04:06 PDT
(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.
Comment 8 David Kilzer (:ddkilzer) 2007-07-16 08:14:49 PDT
(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!

Comment 9 Alfonso Martínez de Lizarrondo 2007-07-16 14:58:17 PDT
(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.
Comment 10 Alexey Proskuryakov 2007-07-17 07:37:27 PDT
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).