Re: Decentralised extensibility idea (ISSUE-41)

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="">
> 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=""
> 		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="" >
<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= >
<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= >
<link id=MyML  rel=profile href=" >
<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>

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