Re: TWO Change proposals for ISSUE-41 : Distributed Extensibility

On Wed, Mar 17, 2010 at 7:26 AM, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no> wrote:
> Let's say we have a Webkit specific style attribute:
>
>        -webkit:style="color:red"
>
> I suppose internally, Webkit would use its regular CSS interpreter.
> Hence Webkit see this attribute as being in the "@style namespace".
> Whereas other vendors do not.

You read his proposal Y incorrectly.  The idea is that the namespace-y
way to do it would be with "webkit:style=foo".  Proposal Y instead
suggests writing "webkit-style=foo".  This is an ordinary attribute
with no special namespace.  It just contains a prefix that makes it
much less likely to clash with other browsers or future standards.

> So effectively, it would not be a vendor specific prefix? It is all
> just a promise from the other browsers: "No, we will not react to
> [-webkit] even if we see it" ?

I'm not sure what the confusion is here.  Yes, it's a vendor-specific
prefix, in the same way that CSS uses the term.  Only Firefox uses the
-moz- prefix in CSS rules, and other browsers rightly treat it as an
unknown property and ignore it.  In Proposal Y, Firefox would use the
moz- prefix on HTML attributes as well, and it would similarly be
treated as an unknown attribute by other browsers.  So, for example,
if the @autobuffer attribute never existed on <video>, and people were
just now suggesting it, Firefox could implement it as <video
moz-autobuffer>.  Webkit would implement it as <video
webkit-autobuffer>, Opera as <video o-autobuffer>, IE as <video
ms-autobuffer>, etc.  All browsers would pay attention to only the
attribute that they recognize, with their own prefix.  Eventually,
when the attribute gets standardized and stabilized, they would also
recognize the attribute *without* the prefix, as plain <video
autobuffer>.

So, an author wishing to activate the behavior for *all* the browsers
could just write <video moz-autobuffer webkit-autobuffer o-autobuffer
ms-autobuffer>, and when it gets standardized can add plain
@autobuffer to that list while the legacy browsers transition out.
Eventually, when all the browsers the author cares about recognize
plain @autobuffer, they can start just writing <video autobuffer>.
This is the same model that CSS uses.  It's not ideal, but it's better
than all the suggested alternatives.

The only thing remotely controversial about Proposal Y is that it
suggests handling new experimental elements through vendor-specific
attributes as well.  Frex, if <time> had never been invented, but
suddenly FF suggested it, authors would temporarily write <span
moz-time moz-datetime=2010-03-17>March 17th, 2010</span>.  If other
implementations supported it experimentally, you'd just double up the
prefixed attributes.  When it eventually gets standardized and
stabilized, you'd temporarily write <time datetime=2010-03-17 moz-time
moz-datetime=2010-03-17>March 17th, 2010</time> to cater to both the
modern supporting browser and the older one that only knew about the
experimental implementation.  Eventually, when the experimenting
version drops out of attention, you can stop using the moz-*
attributes entirely, and just write <time datetime=2010-03-17>March
17th, 2010</time>.  Again, this is pretty ugly, but it's a better than
any of the suggested alternatives, and much better than just
implementing an experimental version of <time> directly (see: the
problems we had with <canvas>).

~TJ

Received on Wednesday, 17 March 2010 14:50:33 UTC