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

Re: vendor prefix properties diverging from official properties

From: Brendan Kenny <bckenny@gmail.com>
Date: Tue, 2 Mar 2010 16:50:18 -0600
Message-ID: <ab96c3ef1003021450r30e21574pa5f87fb00602c532@mail.gmail.com>
To: Simon Fraser <smfr@me.com>
Cc: François REMY <fremycompany_pub@yahoo.fr>, Aryeh Gregor <Simetrical+w3c@gmail.com>, Sylvain Galineau <sylvaing@microsoft.com>, Zack Weinberg <zweinberg@mozilla.com>, www-style@w3.org
On Tue, Mar 2, 2010 at 3:11 PM, Simon Fraser <smfr@me.com> wrote:
> On Feb 26, 2010, at 12:41 PM, François REMY wrote:
>
>> I strongly agree.
>>
>> It would be a great benefit for everyone if we could
>> use -wd-border-radius instead of a combinaison of
>> -moz-border-radius and -webkit-border-radius.
>>
>> Browser prefixes remains great for features that are
>> browser-related or that are not part of any working
>> draft, but for features browser would like to introduce
>> in the real world, a -wd- prefix seems better.
>>
>> Regards,
>> François
>>
>> [BTW, I don't like 'draft' as it's too long to type, nor
>> '-w3c-'  since it would mean that w3c properties are
>> not well defined and implemented by browsers, while
>> the objective of the w3c is the complete opposite.
>> '-wd-' seems better to my.]
>
> In principle, having a common prefix on CSS-draft properties sounds like a sensible idea, and certainly apperas to reduce author confusion and effort.
>
> In practice, however, there are serious problems with the proposal. The key here is that a browser implementation of a CSS draft property is a snapshot in time of the specification of that property at the time of implementation. If the draft is revised, it's not the case that all browsers suddenly revise their implementations to match; not only is there a limit on engineering time, but browsers typically have 6-12mo release cycles, so implementation is bound to lag specification.
>
> So having -w3c-image-fit is no more a guarantee of a particular behavior for an author than -moz-image-fit or -webkit-image-fit; in fact, it's probably less so.
>
> The logical solution would be to version the property name so that the author knows what they are getting:
>
> -w3c-20061010-image-fit
>
> but I don't think anyone would want that.
>
> So I'm really not sure that having a common prefix buys us any more convenience for authors.
>
> Simon

While on the surface versioning does sound much worse, it's worth
considering the fact that this problem already exists. Draft
specifications are changed but there still remains only one extension
per UA. Vendors usually go out of their way to remain backwards
compatible, but some ambiguity is inherent and things inevitably break
(as should be expected when using draft properties).

Moreover, the prefixed properties being discussed here aren't actually
vendor extensions in the usual sense, but (as you note) are in fact
*already* snapshot implementations of draft specifications, versioned
to when that particular feature was frozen in that particular browser
release.

However, I agree with you that the change would probably not be well
received, and
-w3c-<version1>-<property>
-w3c-<version2>-<property>
-w3c-<version3>-<property>

certainly looks no better than
-moz-<property>
-ms-<property>
-o-<property>
-webkit-<property>

but, in spite of the way the prefix system is currently used, this
change would limit choices to one axis (draft version) instead of what
is really two (draft version x vendor). This can also help vendors
with backwards compatibility, as parsing draft properties can become
stricter while still supporting early implementations (though I have
no idea if they want or need any help here).

Again, maybe too distasteful of a change, but a versioned, universal
draft prefix is at least worth considering for properties that aren't
actually vendor extensions anyway.

bk
Received on Tuesday, 2 March 2010 22:50:46 GMT

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