- From: Dan Brickley <danbri@danbri.org>
- Date: Sun, 01 Mar 2009 20:51:08 +0100
- To: Rob Sayre <rsayre@mozilla.com>
- CC: Sam Ruby <rubys@intertwingly.net>, Mark Nottingham <mnot@mnot.net>, Ben Adida <ben@adida.net>, Manu Sporny <msporny@digitalbazaar.com>, "www-tag@w3.org WG" <www-tag@w3.org>, HTMLWG WG <public-html@w3.org>, RDFa mailing list <public-rdf-in-xhtml-tf@w3.org>, public-xhtml2@w3.org
On 1/3/09 20:13, Rob Sayre wrote: > On 3/1/09 2:09 PM, Dan Brickley wrote: >>> Do you mean it won't work technically, or that it would be using the >>> attributes in a way that's unintended? RDFa already uses XML Namespaces >>> and HTML in ways that those specifications don't cover. What's different >>> about my example? >> >> >> This option has been bounced around a few times on the HTML and WHATWG >> lists. The general consensus seemed to be that this wasn't what data- >> attributes were intended for. Of course the HTML5 spec is still in >> flux, and they could be redefined to do this kind of thing too. >> Whether that would be a good idea, I don't know. > > My question was about what's different from the current RDFa strategy of > using other specifications in ways that weren't intended. Even in XHTML, > using QNames in content is a flagrant layering violation, and certainly > unintended by XMLNS. So I think your answer didn't really address my > question. Sorry, I took it as a rhetorical question. I lost interest in the idea of using the data- mechanism when there was little encouragement from HTML5 experts to explore those options. Re qnames and qname-like mechanisms, ... I have (nearly) always been pretty squeamish. But the RDFa and CURIE design had plenty of review and discussion, here and around W3C. If it is a flagrant layering violation, it shouldn't have gone to REC. But it seems enough folk could live with it, even though there are difficulties / risks. FWIW we discussed the options for something similar back in 1998 for RDF/XML (I initially propoposed it, but changed my mind). What's different now? RDFa had to do *something*. It seems the TAG and W3C AC and other reviews found the tradeoff acceptable. Lots of pieces of the puzzle were already frozen. HTML5 is different in that it is not frozen, and there is active ongoing dialog with the people working on it. Wilfully stretching the meaning of brand new language constructs (data-foo) while they're already undeployed and their spec is still in flux, just seems a bit silly. Why not just change them. > However, unlike XMLNS, we could change the HTML5 text. Those attributes > are obviously going to leak all over the place, so I can't see how it > would matter. Yup > Here's my suggestion: > > "Custom data attributes store data for which there are no appropriate > attributes or elements. Authors should be aware that these HTML5 has no > facilities to protect against naming collisions in the data- namespace." > > data-rdfa- seems very unlikely to collide with anything. This is pretty close to the current proposal floating around for stuffing prefix to URI bindings into a non-xmlns attribute. Just it involves tweaking the prose definition of data-* rather than adding a new attribute. cheers, Dan
Received on Sunday, 1 March 2009 19:51:59 UTC