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

Re: Unprefixing CSS properties

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 16 Nov 2011 16:25:15 -0800
Message-ID: <CAAWBYDBuZpYjP0DUpbyCqr83S+h99eVym-3D6aM0dZ8LmN1s3A@mail.gmail.com>
To: robert@ocallahan.org
Cc: www-style <www-style@w3.org>
On Tue, Nov 15, 2011 at 8:02 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
> Web authors have complained a lot about excessive need for vendor prefixing.
> Henri Sivonen has recently blogged about the damage prefixing can do to the
> Web --- see http://hsivonen.iki.fi/vendor-prefixes/.
>
> One observation is that when browser vendors already agree closely on the
> syntax and semantics of a property, and when Web authors routinely use the
> same property value for multiple engines' prefixed properties and the
> unprefixed property, in public Web content, vendor prefixes are providing
> negligible benefit and incur considerable costs --- or outright harm. I
> think we can improve the situation in the short term with relatively low
> risk by identifying properties whose specs are not yet in CR, but where the
> spec is considered stable (but for whatever reason not ready to enter CR,
> perhaps because it contains other properties that aren't stable), and
> agreeing to encourage unprefixed implementations of those properties.
> Naturally we still want implementations to be reasonably conformant before
> shipping unprefixed.
>
> We had a meeting about this with some Mozilla developers today and came up
> with a proposed list of properties/features which we think are eligible for
> unprefixing:
>
> 2D Transforms: all properties
> 3D Transforms: all properties
> Transitions: all properties
> Animations: all properties (responses to feedback urgently need to be added
> to the spec, and that should probably happen first)

Disagree with 3d transforms. I don't think we have any real idea how
preserve3d is supposed to work, for example.

For the rest, I agree, but mainly because those three specs would
already *be* in CR and unprefixed if their editors hadn't dropped
them.


> Conditional: nested @-rules (probably no-one would have prefixed this
> anyway)

Agree, generic abilities like that don't get prefixed generally.


> Images: image() value, 'object-*', 'image-*'

Why did you omit element()?  Do Moz people have some issues with it?
If so, could you tell me about them in a new thread?  It at least has
an implementation - image() has 0 afaik.

If you wait a week or two for the Image Values LC, or until January or
so for CR, gradients will be stable as well.


> Text: 'tab-size', 'hyphens', 'text-align-last', 'text-decoration-*'

Agree, but Fantasai is already planning to split Text and punt half of
it to level 4.  We should figure out what properties to deal with
within that conversation, and just push it quickly so it hits CR
anyway.


> Values: a subset of calc() (the intersection of what IE9 and Gecko
> implement), the new units

What's the subset of calc()?  Is it just "everything but min() and
max()"?  If so, we should just punt min() and max().

The only remaining bits are attr() and cycle().  I presume you find
those unstable?

> Selectors 4: :matches, :any-link, :nth-match, :nth-last-match, :column,
> :nth-column, :nth-last-column

Agree, though we could just cut Selectors 4 and push it quickly to CR
as well.  That could take as little as a few months.



Addressing the rest of the thread:

My view as simultaneously a web author, a spec writer, and an
implementor is that prefixes are good overall, but that we currently
have some high-profile failures of prefixing that are distracting us.
Particularly, Transitions, Animations, and Transforms have been
languishing in WD for far too long due to neglect, and *should*
already be in CR.

That's a failure of people, not the policy.  We can route around the
policy for these specs right now to stanch the bleeding, but the
correct solution is for editors to not drop their specs on the floor.

The other failure is gradients, which have gone through a ton of
revisions internally.  I think they're better for it, but I'm not sure
the pain to authors is worth it.  Things like this are fixable in a
different way - I believe that we browsers shouldn't expose prefixed
properties in our public versions.  Exposing them in betas or
nightlies still lets people experiment with the features without them
showing up in publicly-exposed websites or adopted as valid practices.
 This *also* puts a social pressure on us, the spec authors, to get
our shit in order and finish our specs, so people *can* use them
publicly-exposed websites.

We've discussed this seriously within Chrome, and I believe roc likes
this as well.  There are difficulties with it (convincing the release
engineers to accept pushing an untested binary to beta because we
switched off some prefixed features), but I think it's doable.

~TJ
Received on Thursday, 17 November 2011 00:26:06 GMT

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