[whatwg] XHTML namespace and HTML elements

[Henri Sivonen]

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

> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6777 and
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=7059

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? 
id=488249 ).

> 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  
from http://www.whatwg.org/specs/web-apps/current-work/#apis-in-html-documents 
. 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.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/