W3C home > Mailing lists > Public > public-html@w3.org > October 2009

Re: ISSUE-41/ACTION-97 decentralized-extensibility

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 23 Oct 2009 10:58:51 -0700
Message-ID: <63df84f0910231058m4d106fb8w206977f8462d7e21@mail.gmail.com>
To: Tony Ross <tross@microsoft.com>
Cc: "public-html@w3.org" <public-html@w3.org>
On Thu, Oct 22, 2009 at 2:22 PM, Tony Ross <tross@microsoft.com> wrote:
> Given some of the comments in this thread, I'd like to step back and try to get consensus on the core problem. Specifically I want to know whether or not the group feels providing some sort of a solution for decentralized extensibility, in particular decentralized extensibility of markup, is important.
> In short, should HTML 5 provide an explicit means for others to define custom elements and attributes within HTML markup?
> Note that supporting decentralized markup extensibility does not necessarily mean you feel XML Namespaces are the appropriate solution. Other ideas have been shared and there are certainly many possible solutions, each with their own pros and cons. For the moment let's put these discussions aside. If we cannot agree on the problem, then debating the technical details of a potential solution is pointless.

Hi Tony,

You're actually asking two somewhat different questions:

1. Should HTML5 have decentralized extensibility.
2. Should HTML5 provide an explicit means for others to define custom
elements/attributes within HTML markup.

The spec actually already has a some amount of 1. Primarily Microdata.
I think that that type of decentralized extensibility is definitely
good, but I think the spec is solving that already. Potentially a few
more hooks could be useful, like allowing uris as rel-tokens (which if
I'm reading the spec now is not allowed unless registered, thus it
might not qualify as "decentralized").

As for 2, I don't really feel strongly. As a browser developer I like
the idea of every now and then being able to do experimental
extensions in the form of elements, the same way that we do for CSS.
It allows us to test features without cluttering up the namespace of
standardized element names. And since I'd like to see this on occasion
for browsers, I'd imagine that others would want to do it for other

However I'm not greatly concerned about naming collisions. Generally
these extensions should be fairly localized in small communities. If
an extension is intended for a larger audience it makes sense to
coordinate through a standards organization in order to make sure that
everyone produces and consumes the element in a specified manner. And
since the extension is localized in smaller communities I think naming
collisions can be avoided.

It would make sense though to have a formalized way to name these
extensions in order to allow validators to treat them accordingly. For
example saying that anything containing a ':', or starting with
"-token-" is a local extension. The validator could then appropriately
flag the document as containing extensions without flagging it as an

/ Jonas
Received on Friday, 23 October 2009 17:59:46 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:25:38 UTC