Bug 8007 – createElement() and XHTML (A dynamically created table not rendered as such)

• Component: Layout and Rendering
• Status: RESOLVED FIXED

[Michael Salmon]

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.

[Alexey Proskuryakov]

Confirmed with ToT. I don't see any improperly closed elements in the inspector; this might have been an artifact of serialization.

Created attachment 10241 [details]
Reduction

DOM tree is ok, render tree isn't. The problem appears to be XHTML-specific.

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.

*** Bug 10733 has been marked as a duplicate of this bug. ***

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.

[Alexey Proskuryakov]

*** Bug 10150 has been marked as a duplicate of this bug. ***

[Alexey Proskuryakov]

Mozilla bug: <https://bugzilla.mozilla.org/show_bug.cgi?id=280692>.

[Darin Adler]

*** Bug 14506 has been marked as a duplicate of this bug. ***

[Darin Adler]

See discussion in bug 14506 (which is a duplicate of this bug) and bug 10932 (which is about the behavior in SVG documents).

[Darin Adler]

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.

[Rob Buis]

Created attachment 15462 [details]
First attempt

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

Rob.

[Maciej Stachowiak]

Comment on attachment 15462 [details]
First attempt

r=me

You may also want to change the comment in LayoutTests/svg/custom/createelement.svg

[Rob Buis]

Landed in r24146.

[Simon Pieters]

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.

[Dave Hyatt]

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!

[Dave Hyatt]

I disagree with what was done here.  I see no reason why createElement would make HTML elements when in XML.

[Maciej Stachowiak]

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

[Ian 'Hixie' Hickson]

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

[Kevin McCullough]

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

[Robert Burns]

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.

[Robert Burns]

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