On 3/5/09 10:04 PM, Sam Ruby wrote:
+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.
I agree that it is possible to effectively specify something confusing.
The question is whether the specified behavior will create a prisoner's
dilemma. If enough users won't understand the specification, and create
content that unintentionally violates it, that's what will happen. I
know you are aware of most of these examples, but I'll include them here
for others:
1.) http://www.flickr.com/photos/richardgiles/109523955/
2.) http://www.feedparser.org
3.) https://bugzilla.mozilla.org/show_bug.cgi?id=174351#c46
http://trac.webkit.org/changeset/41476/trunk/WebCore/xml/XMLHttpRequest.cpp
https://bugzilla.mozilla.org/show_bug.cgi?id=174351#c60
4.) https://bugzilla.mozilla.org/show_bug.cgi?id=287793 (feed now
contains "o:p" in escaped HTML... victory?)
http://raeldor.blogspot.com/atom.xml
5.)
http://mxr.mozilla.org/mozilla-central/source/uriloader/exthandler/nsExternalHelperAppService.cpp#2539
6.)
http://blog.mozilla.com/rob-sayre/2009/02/23/preferred-atom-10-acceptable-rss/
7.)
http://thresholdstate.com/threshold/4163/rss-feeds-valid-useful-or-accurate
You get the idea.
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.
xmlns is poorly designed in this regard, since an element's prefix can
be rebound in the very last attribute of said element. I believe the
MSXML team showed this to be true. However, it doesn't seem like it
would be a big deal if normal HTML didn't have to worry about that.
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.
I would be interested to see a proposal.
separately:
Anne has sometimes talked about an XHTML5 which was based not on
XML1.0 but rather on something he refers to as XML5.
http://code.google.com/p/xml5/
http://annevankesteren.nl/2007/10/xml5
I think that solution merits further exploration.
I do not want to gate HTML work on revising XML, but I also think that
proposal is worth exploring.
- Rob
