- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Fri, 9 Jul 2010 10:17:04 -0700
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- Cc: www-style@w3.org
On Jul 9, 2010, at 9:18 AM, Boris Zbarsky wrote: > On 7/9/10 8:51 AM, Brad Kemper wrote: >> Because even if it is listed, it is just theoretical for years, doing nothing but taking up space until the module reaches CR, at which point the syntax or meaning of values may have changed significantly from the way they were implemented in well-established prefixed versions. > > Well, hold on. You can't claim it's cheap to keep supporting the prefixed syntax [1] while at the same time claiming that the prefixed version needs to not change to track the spec and the unprefixed version. > > [...] Note that taking approach #3 (which entails never changing the meaning of your prefixed version of the property) also means that if you implement a property with a prefix and then the spec changes you won't change your prefixed property to match the spec until the spec reaches CR. There have been several instances of this recently, in fact, with UA developers giving exactly the "we can't change the meaning of our prefixed properties" rationale for why they're not making it possible to experiment with the changed spec. Which means there will be no implementation feedback on the changed spec until CR and people implementing the unprefixed version in the wild... I fail to see why this is desirable, myself, from a spec authoring perspective. I didn't say you could never change the way the experimental property works. But by the time it reaches CR, it's got a lot of momentum behind the prefixed versions in the wild, and you are unlikely to change it much in release versions. Thus, Apple supports both "-webkit-border-image' and 'border-image', with significant differences, and authors can use the new one without the old one breaking on sites that use that one.
Received on Friday, 9 July 2010 17:17:40 UTC