WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
8007
createElement() and XHTML (A dynamically created table not rendered as such)
https://bugs.webkit.org/show_bug.cgi?id=8007
Summary
createElement() and XHTML (A dynamically created table not rendered as such)
Michael Salmon
Reported
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.
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
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Alexey Proskuryakov
Comment 1
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.
mitz
Comment 2
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.
mitz
Comment 3
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.
mitz
Comment 4
2006-10-02 07:34:20 PDT
***
Bug 10733
has been marked as a duplicate of this bug. ***
mitz
Comment 5
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.
Alexey Proskuryakov
Comment 6
2006-10-02 08:07:45 PDT
***
Bug 10150
has been marked as a duplicate of this bug. ***
Alexey Proskuryakov
Comment 7
2006-10-05 03:27:54 PDT
Mozilla bug: <
https://bugzilla.mozilla.org/show_bug.cgi?id=280692
>.
Darin Adler
Comment 8
2007-07-09 09:46:05 PDT
***
Bug 14506
has been marked as a duplicate of this bug. ***
Darin Adler
Comment 9
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).
Darin Adler
Comment 10
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.
Rob Buis
Comment 11
2007-07-10 02:03:20 PDT
Created
attachment 15462
[details]
First attempt This contains the work I did on
bug 14506
. Cheers, Rob.
Maciej Stachowiak
Comment 12
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
Rob Buis
Comment 13
2007-07-10 02:24:39 PDT
Landed in
r24146
.
Simon Pieters
Comment 14
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.
Dave Hyatt
Comment 15
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!
Dave Hyatt
Comment 16
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.
Maciej Stachowiak
Comment 17
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).
Ian 'Hixie' Hickson
Comment 18
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?
Kevin McCullough
Comment 19
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
Robert Burns
Comment 20
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.
Robert Burns
Comment 21
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."
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug