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

Re: Unprefixing CSS properties

From: Florian Rivoal <florianr@opera.com>
Date: Thu, 17 Nov 2011 10:55:11 +0100
To: www-style@w3.org
Message-ID: <op.v424h9ud4p7avi@localhost.localdomain>
Prefixes as currently practiced cause a lot of pain to authors, and they
are harmful to browsers with a comparatively small market share.

It does not necessarily mean we have to drop the idea of prefixes all
together, but we should certainly look into ways to reduce the pain.

On Wed, 16 Nov 2011 05:02:28 +0100, Robert O'Callahan
<robert@ocallahan.org> wrote:

> 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.

Not too long ago, Elika posted this:
http://fantasai.inkedblade.net/weblog/2011/inside-csswg/process

If we want to try your approach of dropping prefixes earlier than CR, the
stage described there as "Stabilizing" may be a good candidate to be
the level of maturity we want. It probably needs to be formalized a little
bit, so that the borders are less fuzzy.

The benefit of pushing unprefixing earlier along the track is that it may
also serve as a hint to the working group about when is the best time to
look into changing the syntax. The recent debates on linear and radial
gradient syntaxes are useful, but they certainly come quite late.

If we have a stage earlier than CR where things get unprefixed, syntax
changes during that stage would be unwelcome. They could still happen when
it is necessary to fix problems, but the "I like it better that way" kind
of argument would forced to happen earlier, which I believe would be a
good thing.

The current process encourages arguments like "this is just syntax, let's
stop the bike-shedding and address that later", which is dangerous for
things that are actually implemented, due to the risk of accumulation of
legacy content.

I am not sure that this is approach is the solution to all our problems,
but I believe it is worth considering seriously, at least as a stop gap
measure.

    - Florian
Received on Thursday, 17 November 2011 09:55:46 GMT

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