Re: Suggestion for generic CSS vendor prefix

On Mar 24, 2010, at 1:29 PM, "Anne van Kesteren" <annevk@opera.com>  
wrote:

> On Wed, 24 Mar 2010 21:07:19 +0100, Aryeh Gregor <Simetrical+w3c@gmail.com 
> > wrote:
>> On Mon, Mar 22, 2010 at 5:21 PM, Robert O'Callahan <robert@ocallahan.org 
>> > wrote:
>>> 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.
>>
>> So does anyone have a specific proposal on how to fix this?  What
>> would be an appropriate procedure to freeze syntax for a given
>> property and allow unprefixed use?  There have been some fairly
>> specific suggestions from the "introduce a shared prefix" camp, but  
>> no
>> one has come up with an actual proposal for dropping prefixes sooner
>> (that I've seen).  This is a real problem, and a solution is needed.
>
> I think for properties that are relatively stable we should just  
> declare them "implementable" regardless of what the status is of the  
> draft specification they happen to be in. If a property is declared  
> "implementable" it can be implemented without prefix and major  
> changes to the property will no longer be made unless major issues  
> are found. Properties on this list would include e.g. overflow-x,  
> overflow-y, and box-sizing.

On the other hand, you have properties like 'border-image' that was  
pretty stable before it went through a major change which was  
incompatible with experimental implements. I don't think that could  
have been predicted. And naturally I, for one, wouldn't have wanted it  
prevented due to widespread use of the existing version for iPhone  
buttons. Or what if border-radius had been unprefixed before
On Mar 24, 2010, at 1:29 PM, "Anne van Kesteren" <annevk@opera.com>  
wrote:

> On Wed, 24 Mar 2010 21:07:19 +0100, Aryeh Gregor <Simetrical+w3c@gmail.com 
> > wrote:
>> On Mon, Mar 22, 2010 at 5:21 PM, Robert O'Callahan <robert@ocallahan.org 
>> > wrote:
>>> 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.
>>
>> So does anyone have a specific proposal on how to fix this?  What
>> would be an appropriate procedure to freeze syntax for a given
>> property and allow unprefixed use?  There have been some fairly
>> specific suggestions from the "introduce a shared prefix" camp, but  
>> no
>> one has come up with an actual proposal for dropping prefixes sooner
>> (that I've seen).  This is a real problem, and a solution is needed.
>
> I think for properties that are relatively stable we should just  
> declare them "implementable" regardless of what the status is of the  
> draft specification they happen to be in. If a property is declared  
> "implementable" it can be implemented without prefix and major  
> changes to the property will no longer be made unless major issues  
> are found. Properties on this list would include e.g. overflow-x,  
> overflow-y, and box-sizing.

On the other hand, you have properties like 'border-image' that was  
pretty stable before it went through a major change which was  
incompatible with experimental implements. I don't think that could  
have been predicted. And naturally I, for one, wouldn't have wanted it  
prevented due to widespread use of the existing version for iPhone  
buttons. Or what if border-radius had been unprefixed before the issue  
of percentages had been settled, or when the individual corners were  
specified differently for different browsers? I think CR is when it is  
stable enough to be unprefixed.

Received on Wednesday, 24 March 2010 21:49:28 UTC