Re: Decentralised extensibility idea (ISSUE-41)

On Sun, Jan 17, 2010 at 9:52 AM, Toby Inkster <tai@g5n.co.uk> wrote:
> On Sun, 2010-01-17 at 09:39 -0800, Tab Atkins Jr. wrote:
>> I'm making a stronger point than that, though.  Even in the presence
>> of just a single extension, you are unable to extract the data unless
>> you specifically know the extension being used.  You require vocab
>> knowledge just to disambiguate it from HTML itself.
>
> Indeed. Extraction of data by generic agents is not intended to be a use
> case the proposal satisfies. If you consider this to be a problem, note
> that this problem also applies to the existing method of extensibility
> suggested by the HTML5 draft (i.e. extensibility by becoming an
> "applicable specification").
>
> The advantage that my DE proposal has over "applicable specification
> extensibility" are: scoped URI-based opt-in; and well-established
> fallback parsing, behaviour and rendering.

Ah, I think I've been misinterpreting your proposal's intent, then.  I
had assumed it was meant to be competing in the same space that
Microdata and RDFa were.  Instead, this seems to be about full-on
language extension - adding new elements/attributes to HTML itself by
embedding them using existing extension mechanisms (@class and
@data-*).

That puts it into a completely new realm, then, and links it to an
entirely different set of objections.  I don't believe that the HTML
language *should* be extended in a distributed manner, where anyone
can publish some half-baked vocab extension and see it recognized.
The "applicable specification" clause ensures that the extension is
accepted by a large enough group of people to make the validator
authors recognize it, which is a reasonable minimum quality bar.  It
also ensures that, when such a specification *does* become popular
enough to be recognized, it's using first-class pieces of the language
- plain attributes and element names - which are much easier to
author.  Forcing language extensions into an embedding ghetto just
ensures that they'll always be difficult to use.

The one realm where unilateral extension of the language *is*
recognized to be useful is in experimental implementations by browser
vendors, where it's never expected for the extension to be recognized
except by that specific browser, and the extension itself it intended
to disappear in the future when it either gets rejected or accepted
into the language proper.  In these cases I think that the
already-discussed idea of just using vendor-prefixed attributes will
work fine; it's simpler than your proposal and makes it more clear
that these are proprietary vendor experiments, not seriously proposed
language extensions.

In conclusion, I think this debate has been had before.  The existing
mechanism for extending the HTML language results in cleaner design
and implicitly contains a minimum quality bar.  The
previously-discussed mechanism for allowing vendors to implement
experimental features are slightly simpler to use and more clearly
indicate their experimental status.  Your proposal is worse than
either mechanism in the realm that the mechanism is intended for.

~TJ

Received on Sunday, 17 January 2010 18:25:57 UTC