On Jan 18, 2009, at 02:02, Sam Ruby wrote:
On Sat, Jan 17, 2009 at 5:51 PM, Henri Sivonen <hsivo...@iki.fi>
wrote:
On Jan 17, 2009, at 22:35, Shelley Powers wrote:
Generally, though, RDFa is based on reusing a set of attributes
already
existing in HTML5, and adding a few more.
Also, RDFa uses CURIEs which in turn use the XML namespace mapping
context.
I would assume no differences in the DOM based on XHTML or HTML.
The assumption is incorrect.
Please compare
http://hsivonen.iki.fi/test/moz/xmlns-dom.html
and
http://hsivonen.iki.fi/test/moz/xmlns-dom.xhtml
Same bytes, different media type.
The W3C Recommendation for DOM also describes a readonly attribute on
Attr named 'name'. Discuss.
I have added this to the test cases.
In the DOM API, you can use the namespace-unaware DOM Level 1 view to
make both cases look the same upon getting a parser-inserted value.
(This is, of course, totally against namespace-aware programming
practices, and in non-browser apps, the API might not even expose
qnames or higher-level technologies like RELAX NG or XPath can't
trigger on them.)
But it's too early to declare victory. Surely we want also scripted
setters that mutate the DOM into a state that could have been the
result of a parse.
Now we have tentatively seen that DOM Level 1 APIs seem to do what we
want. So let's try using setAttribute():
http://hsivonen.iki.fi/test/moz/xmlns-dom-setter.html
The result looks the same as the HTML case earlier:
http://hsivonen.iki.fi/test/moz/xmlns-dom.html
But now, the XHTML side using the setter:
http://hsivonen.iki.fi/test/moz/xmlns-dom-setter.xhtml
...gives a result that is different from the parser-inserted attribute
XHTML:
http://hsivonen.iki.fi/test/moz/xmlns-dom.xhtml
Furthermore, the resulting DOM is no longer serializable as XML 1.0.
So let's move to a less intuitive case and use the namespace-aware
Level 2 setter while assuming the use of the namespace-unaware Level 1
getter:
http://hsivonen.iki.fi/test/moz/xmlns-dom-setter-ns.xhtml
Looks good compared to the parser-inserted XHTML case:
http://hsivonen.iki.fi/test/moz/xmlns-dom.xhtml
But now, the HTML side is broken:
http://hsivonen.iki.fi/test/moz/xmlns-dom-setter-ns.html
vs.
http://hsivonen.iki.fi/test/moz/xmlns-dom.html
I put together a very crude demonstration of JavaScript access of a
specific RDFa attribute, about. It's temporary, but if you go to
my main web
page,http://realtech.burningbird.net, and look in the sidebar for
the click
me text, it will traverse each div element looking for an "about"
attribute,
and then pop up an alert with the value of the attribute. I would
use
console rather than alert, but I don't believe all browsers
support console,
yet.
This misses the point, because the inconsistency is with attributes
named
xmlns:foo.
There is a similar inconsistency in how xml:lang is handled. Discuss.
The xml:lang DOM inconsistency has lead to a situation where the
xml:lang/lang area in Validator.nu has has the highest incidence of
validator buts per spec sentence of all areas of HTML5. You've
reported at least one of those bugs. The amount of developer time
needed to get it right was ridiculously high.
fantasai recently wrote: “Unless you're working on a CSS layout engine
yourself, the level of detail, complex interactions with the rest of
CSS, and design and implementation constraints we need to deal with
here are more complicated than you can imagine.” (Source: http://fantasai.inkedblade.net/weblog/2009/layout-is-expensive/)
From my experience with Validator.nu (that doesn't even have a DOM!)
I think I can say: Unless you're working on a software product whose
code reuse between HTML and XHTML depends on the DOM Consistency
Design principle, the badness caused by violations of the DOM
Consistency Design principle is more complicated than you can imagine.
(Where 'you' is not you, Sam, but the generic English you.)
xml:lang was introduced by people who were designing for an XML
universe when it seemed that would be the way the world would go, so
they can be forgiven, and the WHATWG can clean up the mess. Likewise,
the syntax that the SVG WG chose made sense given that they were
designing for an XML world. It can be accepted as legacy, and HTML5
parser writers can spend time optimizing the conditional camel casing.
RDFa, on the other hand, was created by people who fully expected it
to be served as text/html, even though they called it something like
XHTML 1.1 plus RDFa instead of calling it HTML5. Furthermore, when
they saw they wanted to have RDFa in HTML5, too, instead of addressing
HTML issues then, they just continued pushing towards REC. It's easily
looks like this was done so that RDFa could be presented as a done
deal that HTML5 needs to deal with instead of something whose details
are negotiable. Creating a new mess that would have been easily
avoidable is not similarly forgivable. Also, it sets in very bad
precedent if we allow other groups to keep us on the treadmill by
injecting new HTML-hostile features and expecting us to spend cycles
to sort them out by "working the issues".
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
