W3C home > Mailing lists > Public > www-style@w3.org > November 2011

Re: Unprefixing CSS properties

From: Henri Sivonen <hsivonen@iki.fi>
Date: Thu, 17 Nov 2011 10:55:17 +0200
Message-ID: <CAJQvAueAsZ2edsDb4TqMSxTj_3PEYRMu=OZDFJTMEaNdsYo8gw@mail.gmail.com>
To: "www-style@w3.org" <www-style@w3.org>
On Wed, Nov 16, 2011 at 7:06 PM, Brian Manthos <brianman@microsoft.com> wrote:
> IMO, that's an argument for saying there is a more advanced stage than WD that includes "grammar is stable, only edge cases of behavior remain".  Is that stage CR?  If yes, then the current system supports your suggestion.  If that stage is not CR, perhaps something in between WD and CR should be considered -- and should be considered "unprefixable".
[...]
> I agree.  And I would argue this is where the execution of the CSS process is having problems, not the design.

Evidently, for many things, it's not CR as currently practiced by the
CSS WG. Tab gave reasons why CR failed to be it for certain specs that
in principle should have gone to CR by now. But personally, I think
explanations of *why* it's not CR *as currently practiced* is besides
the point to the question if certain properties could be unprefixed
now. That is, I think unprefixing can happen before the WG
recalibrates CR.

> Drafts, IMO, spend a long time in ED/WD 're-envisioning' what vendors proposed and restructuring it dramatically from what was proposed.  When the editors get "off track" by moving the draft away from "implementer consensus" without implementer support/agreement, that triggers the problem you're mentioning.
>
> Again, I don't think the right solution is to just chuck the system.  The solution is to push back on those controversial edits to the point of reversing them... and then build the argument (test suite!) to support moving forward with the grammars and behaviors that have implementer consensus.

I believe editors feel more free to go off track because the use of
prefixes gives a license for the spec to be substantially different
from what got shipped with prefixes. If vendors waited for a short
(where "short" is very much shorter than the time it takes to get
anything to CR currently) smoke test period while a newly-proposed
feature is in experimental builds and gets initial peer review and
then after convincing themselves that the central characteristics of
the feature are OK enough to be supported forever shipped the feature
unprefixed, I believe an editor tasked with speccing the feature would
be a lot less likely to get off-track and change the feature in ways
that would break existing content too much or spread too much doubt
over the stability of the feature to harm imminent expected deployment
too much.

I've seen a couple of Twitter comments expressing concern that the
approach described in the previous paragraph would occasionally bake
unideal features in the Web platform for all eternity. If the
particularly badly-designed features are rare, I think having an
occasional badly-designed feature that needs to be supported forever
is less bad than it is good to have all the other features be
delivered in a timely way to Web authors in an unprefixed form. And if
feature foo is badly designed in the sense that it doesn't cover
enough use cases, there is the opportunity to launch a feature
better-foo later so that the original foo remains in the platform
mainly for legacy content. (Having features remain in the platform for
legacy content is the normal mode of operation for the Web platform,
and so far, this "worse is better" mode of operation has been
successful.) Moreover, for many features, the initial foo will be good
enough and the cost of better-foo will be avoided, since a better-foo
isn't needed.

Having to support foo and better-foo forever isn't more expensive than
having to support -vendor-foo and foo forever. A big question relevant
to the superiority of -vendor-foo and foo relative to foo and
better-foo is whether -vendor-foo actually gets removed in a timely
fashion. With the IE engine versioning model, it sure looks like that
any -ms-foo is on track for staying around for a very long time.
Currently, it looks like any -webkit-foo is going to stay around for a
long time, too. Some might argue that this is OK, because then only
the vendor that made the -vendor-foo gamble bears the cost of
supporting two things while everyone else gets to support foo only.
Whether that is true depends on how much important content and apps
(including "native" apps that are mere Web engine wrappers showing
HTML/CSS/JS/SVG content and that might be important to get ported to
other Web engine wrapper silos or to the Web proper) come to depend on
-vendor-foo. If the dependence on -vendor-foo becomes pervasive
enough, other vendors will have to support it (with the foreign
prefix) to be competitive. (I've been told Opera supports some
-apple-prefixed property/properties for Widgets already.) If that
happens, everyone would have been better off with the foo and
better-foo model.

CSS is now already a long way into an experiment on this subject:
There are WebKit gradients and there will eventually be unprefixed
gradients. Will WebKit implement unprefixed gradients *and* swiftly
remove WebKit gradients? Failure to remove WebKit gradients would be a
tacit show of belief that there's so much existing content that needs
WebKit gradients that not supporting WebKit gradients would be
disadvantageous. If that happens, will other vendors agree that not
supporting WebKit gradients is disadvantageous and implement them?

If it turns out that WebKit gradients do get swiftly removed, it would
be a strong indication that prefixes weren't needed in the first
place, because an unprefixed feature could have been modified in place
to become grammar-incompatible (hence resulting in deployment of old
syntax getting dropped by the CSS parser) without too much breakage.

If it turns out that WebKit gradients don't get removed *and* other
browsers end up implementing them, it would be an indication that the
unprefixed foo and better-foo model would have been better.

Only an outcome where WebKit gradients don't get switftly removed and
other browsers aren't harmed competitively by not implementing them
would be an indication that's not against the current model.

An outcome where WebKit gradients stay in WebKit but other browsers
are harmed competitively but fail to act on it would still be an
indication against the current model.

It will be interesting to see what happens.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/
Received on Thursday, 17 November 2011 08:55:56 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:46 GMT