- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 30 Jun 2009 21:51:04 +0000 (UTC)
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. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 30 June 2009 14:51:04 UTC