Re: Decentralised extensibility idea (ISSUE-41)

On Mon, Jan 18, 2010 at 1:18 AM, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no> wrote:
> Tab Atkins Jr., Sun, 17 Jan 2010 10:25:08 -0800:
>> Ah, I think I've been misinterpreting your proposal's intent, then.
>
> That is quite remarkable - given the subject line, and all.

Seriously?  Is that necessary?  Back up a bit.

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

I'm not sure what the reference to namespaces was about at all; I've
commented very little on them personally (though I agree with much of
the objections to them).  The only reference to namespaces in this
thread was referring to them in the same breath as Microdata and RDFa
as generic extensibility mechanisms.

But you are correct, I am against precisely what I just said - I don't
think that HTML should be easily extensible by random authors.  It
should require some relatively substantial quality bar, ideally a
public spec, before an extension is deemed valid.

(There are very specific reasons why I'm against this in the case of
HTML; I am, after all, a Lisper as well, a language in which extending
it is part of the natural process of programming!  A standard
programming language can innovate however it likes, as it all gets
turned into generic machine code before being sent to the user.  HTML,
though, is a public communications language, and only gets 'compiled'
into a page at the client.  It is in the public interest to keep the
language uniform and predictable, and only change it in an open
process that everyone participates in.)

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

Why not?  What bar should be set?  Who should decide it?  It is in a
validator's best interest to reflect popular usage; if there are
popular specs that they flag as invalid, people will stop using them.
They seem like the *perfect* place to assign as the 'quality guardian'
here, as they are the only group with the correct incentives set up by
default.

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

RDFa is on the track to becoming just that.  I'm not certain if any
validator recognizes it quite yet, but the way it's developed is
precisely how the applicable specification clause is meant to be used.
 And though I don't like the way RDFa works, I'd like it even less if
it was embedded via some extension mechanism, rather than using
attributes directly.

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

If they want to solve a problem that requires browsers to respond to
the new markup, then they most certainly *do* need to do so.  What, do
you think there's some magic switch that people can throw and
automatically get their features implemented interoperably in every
browser?  It takes time to go from a full, complete spec to wide
adoption.  Most specs that don't pass through a standards body never
reach the "full, complete" phase (for that matter, many of the specs
that do pass through a standards body don't reach it either, but we at
least have a somewhat higher success rate).  A buggy spec leads to
buggy (or even perfectly conforming, just not-interoperable)
implementations, which leads to author difficulties.

If they're solving a problem that *doesn't* require the browsers to
cooperate and do something new, then why do they care in the first
place?  You don't need a standards body at all then.  Just do your
thing, and if it gets popular enough, validators will recognize it and
it will stop being invalid.

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

I'm not sure what magical powers you're reading into Toby's proposal.
I either don't understand the points you're talking about, or don't
see how they're different from the other extensibility mechanisms that
have been accepted or discussed.

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

Once a pattern has set in, it's very difficult to change.  If there is
a convenient and simple way to upgrade into real elements and
attributes, I'd like to see it explained precisely.

That skips around the issue that I've already raised, though, of why
one shouldn't just use real elements and attributes in the first
place.  It's easier and simpler to just do so, and once your extension
is a success it becomes valid as well.

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

Indeed, direct extension by adding new elements is a bad trip.  This
has been hashed out before; HTML's element names are *not* extensible
in a useful way.  There are ways around this, though - HTML attributes
are extensible in the correct way (they have the correct fallback and
combining behavior), and so we can exploit that instead.

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

What value is added by the profile?

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

I… agree?  That's what I said.

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

Again, I agree.  Vendor-prefixed elements would be horrible.  We
already know this.  Vendor-prefixed attributes, on the other hand,
have similar fallback and combination abilities as vendor-prefixed CSS
properties and values.

~TJ

Received on Monday, 18 January 2010 14:56:59 UTC