Re: Decentralised extensibility idea (ISSUE-41)

Tab Atkins Jr., Sun, 17 Jan 2010 10:25:08 -0800:
> On Sun, Jan 17, 2010 at 9:52 AM, Toby Inkster 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. 

That is quite remarkable - given the subject line, and all.

[...]
> That puts it into a completely new realm, then, and links it to an
> entirely different set of objections.

The drawer to the left.

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

So opposition against namespaces was just a play: It is extensibility 
itself that you are against. 

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

We don't really know how the "applicable spec" mechanism will work. But 
I don't think we'll simply hand it over to the validator team to tell 
what it is.

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

Do you have concrete examples of *invalid* features that have become 
accepted - attained "applicable specification" status in this manner?

>  Forcing language extensions into an embedding ghetto just
> ensures that they'll always be difficult to use.

We cannot expect that someone that wants to solve a problem joins a 
Working Group desert for 3 to 6 years in order to solve the problem at 
hand.

Toby's DE system allows many things to be tested. It also allows best 
practises to be specified. It allows User Agents quirks to be 
documented and put into a "language".

Basically, it is perfect system for developing and detecting (!) 
Cowpaths. Should therefore be the perfect extension system for a 
cowpath considering working group.

Of course, if the extension is really useful, then one can turn the 
things into "real" elements and attributes. What's the problem?

> The one realm where unilateral extension of the language *is*
> recognized to be useful is in experimental implementations by browser
> vendors,

I have not perceived this to be unilateral. OK, it works fine for CSS. 
But if all the 4 big Web browser vendors each operated with their own 
<time> element (<moz-time>,<webkit-time> etc), then it would be hell 
for authors to try it out.

OTOH, I think that CSS selectors and HTML *attributes* have much in 
common, and with Toby's DE _then_ it would be possible to operate with 
vendor prefixes. For example experiments with the <time> element could 
be performed like this:

<span class="time -moz-time -o-time -ie-time -webkit-time" 
      data-datetime="2007-10-05"
      profile="http://w3.org/html5-experimental"
     >October 5</span>

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

Well, you know, I've heard that it is whether you loose customer that 
counts.

I think that Toby's DE system would be very author friendly, as authors 
are used to working with attributes. It would be *much* simpler to drop 
support for such a profile than it would be to change the 
implementation of e.g. <video>. (OTOH, it couldn't really be considered 
an error to keep support for the profile, if the UA wants to do so, 
either.)

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

I have to say that I think that it only superficially is how you claim.

> In conclusion, I think this debate has been had before.

Drawer to the left.

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

In the CSS business, the vendor specific features are in full use, and 
they do not create much harm. On the contrary, they are often helpful - 
or at least necessary.

As much as I know, during the specification of HTML5, not a single 
vendor have used vendor specific hacks for experimenting with features. 
Hence, I think facts speak against the claim that vendor prefixes would 
be so nice.

In markup, vendor prefixed elements will cause a lot of authoring hacks 
- conditional comments and javascript inserted elements. It will also 
cause that pages suddenly stop to work. Toby's DE system seems likely 
to be causing much more experimentation, as it is much more risk free 
to experiment this way than operating with completely new, experimental 
elements.
-- 
leif halvard silli

Received on Monday, 18 January 2010 07:18:46 UTC