- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Fri, 15 Jan 2010 04:29:12 +0100
- To: Toby Inkster <tai@g5n.co.uk>
- Cc: "public-html@w3.org" <public-html@w3.org>
Toby Inkster, Thu, 14 Jan 2010 23:30:21 +0000: > This is a sketch of a proposal for decentralised extensibility (DE) in > HTML5. If there is interest in it, I'll be happy to write it up as a > change proposal, but I'd like to see what people think first. HTML4 profiles reborn. Super! Some comments/questions below. ___ > My solution forces otherspecs to subclass existing HTML elements > instead. They do this using the existing class attribute. So, for > example, one might have: > > <span class="Car">Mazda</span> ___ > So, how should one add custom attributes to otherspecs. We repurpose the > data-* attributes: > > <span class="Car" data-engine-size="1.8L" > data-colour="blue">Mazda</span> ___ > This proposal also allows otherspecs to mint their own meta names and > link rel types. So how would you indicate where the rel value comes from? Like this: <link profile="URI" rel="value" href="somewhere" > > Lastly, the mechanism for documents to indicate which otherspecs they're > using: > > <head profile="http://example.com/CarML/html5"> > > The profile attribute would be allowed on any HTML element and would > apply to all descendant elements. Would <link rel="profile" href="uri"> fit into this picture? (See one possibility below.) And what if two profiles apply to the same element, and both of profiles have the same class - e.g. "Car"? (See below.) > As a special case, a profile on <head/> would apply to the whole document. Indeed a special case. But how would <html profile="URI"> and <head profile="URI"> differ? Remember, also, that HTML5, unlike HTML4, allows @class and @id even on <html>, <head> and <title> - even on <meta>. > So, my original XML-style <car/> element could be written as: > > <span > profile="http://example.com/CarML/html5" > class="Car" > data-engine-size="1.8L" > data-colour="blue">Mazda</span> I'm sure some would like to be able to do something like this: <html xmlns:carml="http://example.com/CarML/html5" > <span profile="carml" class="Car">Mazda</span> But thanks to HTML5's freedom w.r.t. where @id/@class might appear, then a perhaps more - as you said - "HTML-ish" (not to say "Twitter-ish") option would be this: <head > <link id=CarML rel=profile href=http://example.com/CarML/html5 > </head> <span profile="#CarML" class="Car">Mazda</span> Note that if a <link> points to a DE profile, then it will not have any descendant elements - so linking to it like this, seems fitting. :-) Also note that @profile - at least <head@profile> - can link to several URIs, so <link@rel="profile"> seems better than @profile for that reason, for this idea. And so, to apply two DE profiles simultaneously, then perhaps this: ? <head > <link id=CarML rel=profile href=http://example.com/CarML/html5 > <link id=MyML rel=profile href="http://example.com/MyML/html5 > </head> <span profile="#CarML #MyML" class="Car" >Mazda</span> I think - when necessary - to separate "Car" from CarML and "Car" from MyML, there should be some prefix option. I don't know, but perhaps simply like this: ? <div class="Japanese" profile="#CarML" > <div class="Favorite" profile="#MyML" > <span class="Car#CarmML" data-colour="blue#MyML" >Mazda</span> </div></div> Or do you see another option? Using a #hash instead of some namespace variant perhaps has some drawbacks, but one advantage is that authors are used to the fact a fragment URI isn't expected to work outside the context - so copy-paste "problems" would not come as any surprise to authors. > So in summary, we should be able to achieve DE by reintroducing > @profile, as a scoped attribute allowed on any element, and giving the > profile mechanism "jurisdiction" to assign non-local meaning to class > names, link relationships, meta names and data-* attributes. > > I'm not proposing this method to replace the current extensibility > method of becoming an "applicable specification", but as an additional > extensibility point with perhaps a lower barrier to entry. > > An optional extra would be a DOM method > getElementsByClassNameWithProfile(classname, profileuri) which return a > collection of elements matching the provided class, but only if they > were within the scope of a particular profile URI. Good stuff! -- leif halvard silli
Received on Friday, 15 January 2010 03:29:47 UTC