W3C home > Mailing lists > Public > www-style@w3.org > March 2010

Re: Suggestion for generic CSS vendor prefix

From: Bert Bos <bert@w3.org>
Date: Wed, 24 Mar 2010 14:51:24 -0400
Message-ID: <4BAA5F2C.6050403@w3.org>
To: www-style <www-style@w3.org>
On 22/3/10 17:21, Robert O'Callahan wrote:
> The previous big thread on this topic explained very clearly why a generic
> prefix is a bad idea.
> 1) Before the syntax and behavior of a property is frozen, different
> browsers' implementation of the property are likely to vary, often because
> their implementations reflect different versions of the draft spec. Using a
> common prefix in this situation is a bad idea.
> 2) Once the syntax and behavior of a property is frozen, authors and
> browsers should simply use the unprefixed version of the property.
> If there is a problem we need to solve here, it's that for some properties
> there's a long gap between the syntax and behavior freezing and the spec
> going into CR, at which time unprefixed implementations are officially
> allowed. Fixing that requires a change in policy and/or process.

I agree with that.

If properties that are experimental, unstable and temporary cease to be
seen as such by a large group of users, that suggests (but doesn't
imply) that the definitions are being developed too slowly.

In the particular case of 'border-radius', the blocking issue[1] is
whether (and, if so, how) to specify specific color transitions in the
corners of a two-color border. Maybe this isn't as important as we
thought, maybe we are overlooking a simple way to circumvent the
problem, but maybe also it is a real problem and we failed to explain it.

[1] http://www.w3.org/Style/CSS/Tracker/issues/120

  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos                               W3C/ERCIM
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France
Received on Wednesday, 24 March 2010 18:51:53 UTC

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