[whatwg] XHTML namespace and HTML elements
hsivonen at iki.fi
Tue Jun 30 05:46:46 PDT 2009
On Jun 30, 2009, at 15:11, Olli Pettay wrote:
> I wonder what (and where) are the reasons to use XHTML namespace
> also with HTML elements.
> The behavior causes few issues like
> https://bugzilla.mozilla.org/show_bug.cgi?id=501312 and
A variant of this corner case already existed with attribute nodes. It
seems to me that setting uppercase no-namespace attributes on the XML
side, moving the node to an HTML document and getting the attributes
on the other side has no use cases, so I think this isn't a problem in
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6777 and
The patch that introduced this one unfortunate new special case to
Gecko removed 20 instances of code dealing with the namespace duality
and opened up the opportunity to eliminate 105 more such instances
(all virtual calls; https://bugzilla.mozilla.org/show_bug.cgi?
> And what are the problems if and when null namespace is used with HTML
> elements (like in <=FF3.5).
I think having a tree with mixed HTML and XML-trait nodes is more
confusing than the edge case from bug 501312. You can get such mixed
trees in practice by having script code that uses createElementNS("http://www.w3.org/1999/xhtml
", ...) in order to work with both HTML and XHTML.
> When script libraries need to check if some element is an (X)HTML
> element, they could always use instanceof.
There are also non-browser apps that don't run scripts at all and,
therefore, don't need to implement the HTML-specific DOM Core deltas
. Those apps benefit even more than browsers, since the above-parser
differences between HTML and XHTML are abstracted away even more
completely than in the UAs that have to support legacy existing scripts.
In general, I think maintaining differences between HTML and XHTML
serves no useful purpose when it's not done to support existing content.
hsivonen at iki.fi
More information about the whatwg