- From: Brendan Kenny <bckenny@gmail.com>
- Date: Tue, 2 Mar 2010 16:50:18 -0600
- 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 UTC