- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 23 Oct 2009 10:58:51 -0700
- 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 things. 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 error. / Jonas
Received on Friday, 23 October 2009 17:59:46 UTC