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

Re: Policy for one vendor using the vendor-prefix from another vendor?

From: Brad Kemper <brad.kemper@gmail.com>
Date: Wed, 12 May 2010 10:16:43 -0700
Cc: www-style@w3.org
Message-Id: <1D145173-9069-4608-9035-6DA0632A9E00@gmail.com>
To: Allan Sandfeld Jensen <kde@carewolf.com>

On May 11, 2010, at 4:40 PM, Allan Sandfeld Jensen wrote:

> On Tuesday 11 May 2010, Daniel Glazman wrote:
>> Le 11/05/10 21:29, Alex Mogilevsky a écrit :
>>> Prefixes are intended for experimental and proprietary features. In this
>>> case, it is a proprietary feature of Webkit that is used by enough
>>> content that it becomes attractive to be compatible with. Although it is
>>> not the direction we would like to see as a standards group, it is
>>> conceptually no different from third parties opening PDF or RTF files...
>> -moz-border-radius was an even more attractive property than
>> -webkit-text-size-adjust to all web designers and I don't think other
>> implementors implemented that mozilla proprietary extension...
> Just for the record KHTML has adopted several -webkit- properties which 
> automatically translates to similar -khtml- properties. Some of these where 
> originally -khtml- properties later renamed in the webkit branch, but some 
> like -webkit-border-radius are later developments. The rationalle for reusing 
> vendor-properties in these cases have that we also share the implemenation of 
> the property. 
> Looking forward though, I Personally see no problem with reusing -moz- and -
> ms- properties either. If these properties catches on, it is more of a hint to 
> the W3C to move quicker to standardize those properties before it is too late. 

I think it is a very bad precedent. As an author, I am much more concerned with having reasonable, predictable rendering than I am with wagging my finger at the WG. 

I'm less worried about KHTML using -webkit-, as they both branch off the same base code (more different than, say, Safari and Chrome, as I understand it, but that may be more of a gray area). But unless IE9 is going to support almost all of the same properties as Webkit, and in the same way at the same time, they should not be using another rendering engine's prefix. It is a slippery slope, and I might already be using some other CSS way to deal with non-Webkit UAs, or I might be using two or more -webkit-prefixed properties in conjunction with each other that would not work well if only one was supported. 

I don't know that we could actually say a UA is non-complient if it used another's prefix (how would that work? Would you have to query the UA first to find out what prefix it is going to claim for its own?). But at least it should be strongly discouraged. Pick a prefix of your own, and use that. Or pick someone else's. But you only get one (or in rare cases two, if your UA is very, very much similar to another).
Received on Wednesday, 12 May 2010 17:17:22 UTC

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