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

Re: Unprefixing CSS properties

From: Jon Rimmer <jon.rimmer@gmail.com>
Date: Sat, 19 Nov 2011 16:29:35 +0000
Message-ID: <CA+ZDCiAr+w7XP1oa3hDKFEUOae-7ovXdCTN9Nr233+N38OB-Wg@mail.gmail.com>
To: Brian Manthos <brianman@microsoft.com>
Cc: "robert@ocallahan.org" <robert@ocallahan.org>, Brad Kemper <brad.kemper@gmail.com>, Sylvain Galineau <sylvaing@microsoft.com>, www-style <www-style@w3.org>
On 19 November 2011 01:30, Brian Manthos <brianman@microsoft.com> wrote:
>> Authors are taught to set the same values they're using for prefixed properties for the
>> unprefixed version as well, to "future proof" their production sites. Such usage
>> constrains browser implementers, and by extension the WG, to make sure the spec
>> evolves in a way that doesn't break those sites.
> This is incorrect guidance and should be corrected.

What? If I only include the prefixed property, and the syntax changes,
my site breaks. If I also include an unprefixed version, and the
syntax changes, my site still breaks, so what difference does it make?
(Or rather, it doesn't "break", it simply reverts to the fallback
behaviour that I will provide for older browsers that never supported
these new features.)

I'm really struggling to see any logic or evidence behind the argument
that prefixes enable new features to be enabled and used in anger,
then later changed. If you want people to make enough use of new
features to reveal problems, then you're going to end up with a body
of content that relies on the original implementation, and which will
break when the syntax changes, regardless of whether those features
are using a prefix or not. This is exactly what the experience of
Webkit has proved. If you don't make new features widely available,
then you won't need to worry about changing the API, but nor will you
get significant stress testing of it.

It seems like these are simple principles of API versioning, yet
everybody is acting as if some magic combination of prefixing,
published guidance and developer-build restriction will eliminate
them. It won't.

You should all just agree to drop vendor prefixes, or make them an
optional way to target implementations on a per-UA, and move on.
Concentrate on reducing the body of content that is broken by spec
changes by minimising the period of instability, by avoiding
bike-shedding and working quickly to stabilise syntaxes. Don't keep
trying to solve unsolvable problems or save authors from ourselves.

Jon Rimmer
Received on Saturday, 19 November 2011 16:30:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:07 UTC