- From: Sam Ruby <rubys@intertwingly.net>
- Date: Thu, 05 Mar 2009 22:04:57 -0500
- To: Rob Sayre <rsayre@mozilla.com>
- CC: Tim Berners-Lee <timbl@w3.org>, Henri Sivonen <hsivonen@iki.fi>, Ben Adida <ben@adida.net>, Julian Reschke <julian.reschke@gmx.de>, Mark Nottingham <mnot@mnot.net>, HTMLWG WG <public-html@w3.org>, RDFa mailing list <public-rdf-in-xhtml-tf@w3.org>, public-xhtml2@w3.org, "www-tag@w3.org WG" <www-tag@w3.org>, Chris Wilson <Chris.Wilson@microsoft.com>
+cc: Chris Wilson Rob Sayre wrote: > The biggest problem is that HTML parsers must reparent elements. This > would make discerning in-scope namespaces difficult. This argument doesn't resonate with me. If properly spec'ed there certainly would be cases where the answer wasn't obvious; but if the spec simply were to chose one interpretation in such cases, then it doesn't seem to me that it would be difficult to implement to that spec interoperably. > Separately, xmlns forbids elements with undeclared prefixes. Those > sorts of restrictions won't fly in HTML as she are spoke. The best > one could hope for is a spec that defines an xmlns subset that would > work in both HTML and XML. html5 permits all sorts of things that isn't permitted in xml. To my mind the best that one could hope for is a spec that defines a syntax for HTML5 that is a near superset of what xml+xmlns allows. I've heard two other arguments that make considerably more sense to me. One is that adding such support for namespaces would increase computational path length and/or memory requirements, at a time when all browser vendors are attempting to focus on performance improvements. I doubt that this has been properly benchmarked, but this argument makes some sense to me. Perhaps if there were a will for this to be done, I'm confident that browser vendors would be able to find a way, perhaps using lazy evaluation, to accommodate this. But with existing content, there would be zero benefit, and without benefit, there understandably isn't much motivation. The other argument that I have heard is that such support would be unfortunate as it would encourage the use of a flawed and error-prone design. Namespaces have always been controversial, even in XML. But there is one consideration that may trump all of the above, and is why I added Chris to the cc list. IE has a non-trivial marketshare, and apparently has user requirements for namespaces. Enough so that they chose to expand namespace support in IE8. My understanding is that what IE8 supports evolved over time and isn't pretty, so not even Microsoft would propose standardizing what IE8 currently implements. Chris Wilson has the todo to define what he thinks could be standardized, and the current target for that action is a week from today. My read is that if a suitable standard were defined and agreed to, Microsoft would be willing to move in that direction over subsequent releases of IE. What they would not be willing to do is to have no namespace support at all. Chris is welcome to correct me here. And since the overriding goal for HTML5 is consistency (even in the face of erroneous input) and interoperability, it would be a shame if other browser vendors were to not seriously consider such a proposal. I also don't believe that MS would spec something that they themselves couldn't implement efficiently. - Sam Ruby
Received on Friday, 6 March 2009 03:05:46 UTC