W3C home > Mailing lists > Public > www-tag@w3.org > March 2009

Re: @rel syntax in RDFa (relevant to ISSUE-60 discussion), was: Using XMLNS in link/@rel

From: Sam Ruby <rubys@intertwingly.net>
Date: Thu, 05 Mar 2009 22:04:57 -0500
Message-ID: <49B092D9.5060807@intertwingly.net>
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:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:13 GMT