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

On Friday, October 23, 2009 at 10:59 AM, Jonas Sicking wrote:
> 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.

Mostly I was trying to clarify that I feel the real focus is #2.

> 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.

I feel those who would benefit most are the non-browser developers, such as script library authors.

> 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.

Extensions are not always immediately popular. They may begin more localized, but expand their reach as authors find them useful. Furthermore, if prefixes are the chosen solution I expect this will motivate extension authors to keep their prefixes short, increasing the chance of collision.

> 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.



Received on Saturday, 24 October 2009 00:06:16 UTC