Bug 8007 - createElement() and XHTML (A dynamically created table not rendered as such)
Summary: createElement() and XHTML (A dynamically created table not rendered as such)
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 417.x
Hardware: Macintosh OS X 10.4
: P2 Major
Assignee: Nobody
URL: http://michael.mesme.org/playlists/bu...
Keywords: HasReduction
: 10150 10733 14506 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-03-27 02:10 PST by Michael Salmon
Modified: 2007-08-14 20:39 PDT (History)
10 users (show)

See Also:


Attachments
Reduction (974 bytes, application/xhtml+xml)
2006-08-26 09:55 PDT, mitz
no flags Details
Further reduction (587 bytes, application/xhtml+xml)
2006-10-02 07:32 PDT, mitz
no flags Details
First attempt (54.67 KB, patch)
2007-07-10 02:03 PDT, Rob Buis
mjs: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Salmon 2006-03-27 02:10:43 PST
I have written a script that dynamically creates a tbody and attaches it to a table in an xhtml document. In firefox this works as expected but with safari I just get a line of text. When I examine the DOM tree for the page after clicking on an arrow head image I see:

<tbody/><tr/><td/>...</td></tr></tbody>

in a table that is buried in a couple of lists.
Comment 1 Alexey Proskuryakov 2006-03-27 10:04:05 PST
Confirmed with ToT. I don't see any improperly closed elements in the inspector; this might have been an artifact of serialization.
Comment 2 mitz 2006-08-26 09:55:56 PDT
Created attachment 10241 [details]
Reduction

DOM tree is ok, render tree isn't. The problem appears to be XHTML-specific.
Comment 3 mitz 2006-10-02 07:32:29 PDT
Created attachment 10866 [details]
Further reduction

This shows the root cause: WebKit's document.createElement() sets the namespace URI to null. Firefox sets it to the XHTML namespace URI.
Comment 4 mitz 2006-10-02 07:34:20 PDT
*** Bug 10733 has been marked as a duplicate of this bug. ***
Comment 5 mitz 2006-10-02 07:38:55 PDT
To clarify comment #3, what I meant was that Document::createElement() simply calls on createElementNS passing the null string for the namespace. The result is that you get generic elements instead of HTML elements.
Comment 6 Alexey Proskuryakov 2006-10-02 08:07:45 PDT
*** Bug 10150 has been marked as a duplicate of this bug. ***
Comment 7 Alexey Proskuryakov 2006-10-05 03:27:54 PDT
Mozilla bug: <https://bugzilla.mozilla.org/show_bug.cgi?id=280692>.
Comment 8 Darin Adler 2007-07-09 09:46:05 PDT
*** Bug 14506 has been marked as a duplicate of this bug. ***
Comment 9 Darin Adler 2007-07-09 09:47:20 PDT
See discussion in bug 14506 (which is a duplicate of this bug) and bug 10932 (which is about the behavior in SVG documents).
Comment 10 Darin Adler 2007-07-09 09:48:03 PDT
Maciej says:

Given what HTML5 says, and Mozilla's stance, I think we should make createElement always use the XHTML namespace. It would then be possible to remove the HTMLDocument override for createElement.

And I agree.
Comment 11 Rob Buis 2007-07-10 02:03:20 PDT
Created attachment 15462 [details]
First attempt

This contains the work I did on bug 14506.
Cheers,

Rob.
Comment 12 Maciej Stachowiak 2007-07-10 02:16:42 PDT
Comment on attachment 15462 [details]
First attempt

r=me

You may also want to change the comment in LayoutTests/svg/custom/createelement.svg
Comment 13 Rob Buis 2007-07-10 02:24:39 PDT
Landed in r24146.
Comment 14 Simon Pieters 2007-07-23 13:01:15 PDT
What HTML5 says about createElement() only applies to HTML documents.

This patch always lowercases the name. Do we want that? Firefox and Opera don't do that in XML.
Comment 15 Dave Hyatt 2007-07-23 13:03:34 PDT
Comment on attachment 15462 [details]
First attempt

A bunch of tests have changed from success to failure with this patch.  I am inclined to agree with zcorpan.  Can we revisit this?

e.g.,

LayoutTests/dom/xhtml/level1/core/hc_documentcreateelementcasesensitive-expected.txt

Changed from success to failure!
Comment 16 Dave Hyatt 2007-07-23 13:04:51 PDT
I disagree with what was done here.  I see no reason why createElement would make HTML elements when in XML.

Comment 17 Maciej Stachowiak 2007-08-06 18:31:56 PDT
It turns out that for compatibility reasons we can't do this for all XML documents. But for compatibility with Firefox, we need to do it for XHTML documents (as determined by Content-Type, apparently).
Comment 18 Ian 'Hixie' Hickson 2007-08-06 21:26:42 PDT
(In reply to comment #17)
> It turns out that for compatibility reasons we can't do this for all XML
> documents. But for compatibility with Firefox, we need to do it for XHTML
> documents (as determined by Content-Type, apparently).

Could you elaborate on this? Is the legacy content in question so important that it can't be bulldozed?
Comment 19 Kevin McCullough 2007-08-08 15:20:53 PDT
So I reverted r24146 and made some changes so now when calling createElement the namespace will be XHTML if the document is an HTMLDocument or a Document created with an XHTML MIME type.  This should make sense as before any createElement call on a Document would be XHTML which doesn't seem right and does not match firefox behavior.  Also the previous behavior hindered at least one website's use (Zimbra).

My change is r24935
Comment 20 Robert Burns 2007-08-14 13:01:55 PDT
I think the most sensible behavior here (and one that would be typically compatible with mozilla) would be to use the default namespace for document.createElement Passing the default namesapce to createElementNS when none is given just makes sense. This would be compatible with Mozilla whenever the document the default namespace was "http://www.w3.org/1999/xhtml". It would be compatible with Opera whenever the root element had the default namespace (i.e., "xmlns='http://www.w3.org/1999/xhtml'").

In any event, invoking a method and leaving off an argument says to me use the default. This would make this method much more universally useful rather than only for XHTML. It would also make it behave consistently in HTML5 (though its a little early to be citing this spec), since there the root element and the default namesapce will always be 'http://www.w3.org/1999/xhtml'. However, in XML this is a natural generalization of the createElement method so that it works if the default namesapce is SVG or MathML or whatever.
Comment 21 Robert Burns 2007-08-14 20:39:28 PDT
Does anyone know how IE processes document.createElement in XML with and without namespaces? I'd imagine that if IE ever gets around to adding XHTML support it might follow the same approach that it already uses (perhaps that's how the DOM recommendation ended up so strange). 

BTW, I notice that none of the relevant language on this uses any normative phrases. This may be an oversight by the authors, but that shouldn't be the only assumption in reading this. Its quite possible the authors deliberately left the normative language out of the recommendation on this issue. If that is the case, they may have simply been trying to discuss issues of concern to DOM users and not telling implementations how to handle these things. That may be bad for interoperability, but that's where we find ourselves. Just for easy reference here are the two most relevant places I found discussing the issue in the recommendation:

http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#ID-2141741547

http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#Namespaces-Considerations

In particular:

"The "NS" methods, such as Document.createElementNS(namespaceURI, qualifiedName) and Document.createAttributeNS(namespaceURI, qualifiedName), are meant to be used by namespace aware applications. Simple applications that do not use namespaces can use the DOM Level 1 methods, such as Document.createElement(tagName) and Document.createAttribute(name). Elements and attributes created in this way do not have any namespace prefix, namespace URI, or local name."