Re: [whatwg] XHTML namespace and HTML elements
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 hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] XHTML namespace and HTML elements
On Tue, 30 Jun 2009, Olli Pettay wrote: I wonder what (and where) are the reasons to use XHTML namespace also with HTML elements. The main reason was simplification. * Consistency for scripts in HTML and XHTML. For example, a script can now use createElementNS() in both without having to check the mode first. * Consistency for CSS in HTML and XHTML. * Consistency for SVG features (e.g. scripting) across HTML and XHTML now that we have SVG-in-HTML and SVG-in-XHTML. * Sanity of implementation. Browsers have had all kinds of weird behaviour to act one way in text/html and another in XML while wanting elements to have consistent behaviour in both. * A better-defined set of rules for handling mixing of XML and non-XML nodes, e.g. when importing XHTML nodes from XMLHttpRequest'ed XML documents into text/html documents. ...and so on. The behavior causes few issues like https://bugzilla.mozilla.org/show_bug.cgi?id=501312 and http://www.w3.org/Bugs/Public/show_bug.cgi?id=6777 and http://www.w3.org/Bugs/Public/show_bug.cgi?id=7059 These are really minor issues compared to the benefits. And what are the problems if and when null namespace is used with HTML elements (like in =FF3.5). Mostly lack of consistency. Gecko actually used to do this like HTML5 suggests, it was only changed because of a desire to match what was at the time thought to be the spec, if I recall correctly. HTML5 changed this early on precisely so that this change could be reverted. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
