Decentralised extensibility idea (ISSUE-41)

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.

----

So, what's the point of DE? Essentially different people are publishing
HTML documents about different things. Some people might really want a
<car/> element in HTML:

 <car engine-size="1.8L" colour="blue">Toyota</car>

(I don't drive, so this example picks up pretty much everything I know
about cars - they have engines, colours and manufacturers. But if anyone
wants to buy me one for writing this proposal, I'll have a silver Morgan
Aero 8 thanks.)

This might be really useful for them, being able to style the <car/>
element differently, and perhaps have a script apply a special behaviour
on mouseover.

The trouble is that this is too esoteric to add to HTML. If we added
that then we'd have to add <cake/> and any other (excuse the pun)
half-baked idea people had.

DE allows third-parties to create specifications (which I'll assign the
jargon term "otherspecs") based on HTML5 introducing specialised
elements and attributes.

So far the discussion on DE has mostly revolved on porting XML's DE
mechanism to HTML. This idea however creates a new, more HTML-ish DE
mechanism based on stuff that mostly already exists.

Firstly, how does my proposal allow otherspecs to create their own
special elements? One of the weaknesses with the XML namespace approach
applied to HTML is that if a user-agent comes across:

 <foo:bar foo:baz="..." />

in a document, if it doesn't have specific knowledge of the otherspec,
it will have no idea how to handle it. In the case of browsers, which
are a major class of user agents, they will have no idea how to display
it by default (e.g. is it inline or block?).

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>

The class attribute has traditionally been used mostly by authors for
their own purposes. That doesn't need to conflict with this solution, as
I will later indicate a mechanism for documents to specify which
otherspec(s) they are making use of.

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>

Currently the data-* attributes are reserved entirely for the author's
private use. In this proposal, the definition of those attributes would
be changed to allow otherspecs to assign particular meaning to data-*
attributes, but only in the case where document authors have explicitly
indicated which otherspec(s) they're making use of.

This proposal also allows otherspecs to mint their own meta names and
link rel types.

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. As a special case, a profile on
<head/> would apply to the whole document.

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>

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.

-- 
Toby A Inkster
<mailto:mail@tobyinkster.co.uk>
<http://tobyinkster.co.uk>

Received on Thursday, 14 January 2010 23:31:04 UTC