Re: "-draftX-" prefix

On Mon, Dec 5, 2011 at 2:19 PM, Alex Mogilevsky <alexmog@microsoft.com> wrote:
> 4)      Versioned W3C prefix: “-draft1-foo:50%” or “-wd1-foo” etc.
>
> If anything can work that allows use of draft specs without vendor prefixes,
> it must be this one. It allows cross-browser authoring for new features, yet
> it doesn’t compromise spec development process.
>
> David Singer has proposed it here:
> http://lists.w3.org/Archives/Public/www-style/2011Nov/0358.html. It had some
> discussion and some opposition; it does look like a good solution to me, if
> done right.
>
> THE TRICK TO MAKING IT WORK IS HOW VERSIONED PREFIXES ARE PROCESSED AND
> MAINTAINED. I think this part is new here.
>
> PARSING AND CASCADING
>
> The version number in draft property is not part of property name. It is
> parsed away and used an instruction for UA for how to interpret the value.
>
> For example:
>
>                 -draft2-foo:50%
>
> means “-draft-foo:50%” applied according to v2 of the draft.
>
> It could also be written as
>
>                 -draft-foo[2]:50%
> or
>                 -draft-foo:50% !v2;
> or even
>                 foo:50% !v2;
>
> (the last one probably not a good idea, as it locks the name “foo” and it
> may be harder to reuse in case this draft is abandoned)
>
> With this approach,
>
> ·         UA doesn’t need to support all versions of the property. It parses
> versions it chooses to understand, then let them cascade normally
>
> ·         Values of unsupported version are ignored
>
> Note that this is not all that different from current situation. UAs support
> one vendor-prefixed version at a time, which is exact equivalent of
> supporting just one of the drafts using above rules.

I agree that this is not that different from the current situation.
So what does this help?

* It doesn't seem to aid in preventing prefixes from being supported
forever.  In fact, it probably makes it worse.
*  It allows authors to write only a single prefix, which is better
than writing 3-4 prefixes.  However, the latter situation is rare
(usually, properties stabilize before more than 1 or 2 browsers have a
prefixed impl).
* It does nothing to stop the pain of authors either writing the
unprefixed version speculatively (creating content that harms our
ability to change the grammar before CR), or never writing the
unprefixed version (preventing browsers from removing support for the
prefixed version).


> Can we make something like this work? If not, it may be true that the only
> hope to fix prefix mess is to speed up spec progress in CSSWG…

It seems clear that the major prefixing failures
(Transition/Animations/Transforms) are caused by specs progressing too
slowly, so fixing that directly seems to be the correct thing to do.

The other prefixing failure (gradients) is largely caused by this
being the very first complex-grammar function in CSS, so we've had
some significant disagreements over how to approach it.  We've worked
out a lot of these issues now, though, so future similar cases
shouldn't have as much problems.

So, it doesn't seem like we need complicated solutions for this stuff.
 We just need to ensure that specs actually reach CR in a timely
manner when they're ready for it.

~TJ

Received on Monday, 5 December 2011 22:58:14 UTC