Re: Unprefixing CSS properties

On Wed, Nov 16, 2011 at 7:49 AM, Brian Manthos <> wrote:
>> I think in cases where authors are already widely producing content using
>> the unprefixed property
> I don’t see it that way.  I see it this way:  authors are intentionally
> choosing a bad path if they are producing content based on technology that
> isn’t final yet.

Even if you label the choice authors have made "bad", the choice they
have made still affects the way users of browsers whose prefixes the
authors didn't choose to use experience the Web (thereby adversely
affecting the competitiveness of those browsers).

> If the technology isn’t keeping up with author demand, then perhaps authors
> are really asking for proprietary technology rather than standardized
> technology.

Or they are asking to use standard technology when it is already good
even if it isn't perfect from the WG's point of view. Coping methods
like the one presented in
assume that the implementations of the standard technologies are
already good *enough* except for the barrier imposed by the prefix so
that the same stuff can be given to different browsers with mere
prefix substitutions.

>> I think in cases where authors are already widely producing content using
>> the unprefixed property
>> and assuming that the behavior will match the behavior of the
>> vendor-prefixed properties
> The WG has said stated multiple times that the author is wrong in making
> this assumption, and at least hinted that the author is somewhat foolish in
> building LOB on top of prefixed properties.

Given the how often "final" features end up being close enough to
prefixed features, it's not foolish for a Web author to take the bet
that properties that are prefixed today end up being similar enough
once unprefixed so that using the unprefixed version in anticipation
of future browsers won't break the site significantly. Instead, it
would be foolish for the CSS WG to change a characteristic of e.g. 2D
Transforms that the top 4 engines implement the same way (except for
the prefix) even though the W3C Process, in principle, would allow the
CSS WG to make such changes. And when the implementations differ, it
would be foolish for the CSS WG to pick a totally novel behavior
instead of upholding one of the existing behaviors. (In the general
case; security concerns or maybe some truly exceptional badness could
override what I just said.)

> Such authors are completely missing the point that prefixed properties *are
> not ready* for production content.  That’s much of the point of prefixing.

If they aren't ready for production, it's a bad idea to ship them in
non-experimental browser builds and give authors the opportunity to
completely miss the point.

>> Even if authors aren't using the unprefixed property widely, if the
>> behavior is clear and uncontroversial then the harm of unprefixing should be
>> minimal.
> I disagree.  If the behavior is clear and uncontroversial, then the spec
> should be at CR or REC.

In theory, yes. In practice, the behavior converges enough to be
useful and safe *enough* for deployment well before the behavior has
converged so perfectly that the behavior is "clear" for the purpose of
the CSS WG's way of applying the W3C Process.

Henri Sivonen

Received on Wednesday, 16 November 2011 12:10:31 UTC