- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Sun, 18 Jan 2009 12:07:30 +0200
On Jan 18, 2009, at 02:02, Sam Ruby wrote: > On Sat, Jan 17, 2009 at 5:51 PM, Henri Sivonen <hsivonen at 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 hsivonen at iki.fi http://hsivonen.iki.fi/
Received on Sunday, 18 January 2009 02:07:30 UTC