- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Fri, 09 Jul 2010 09:18:29 -0700
- To: Brad Kemper <brad.kemper@gmail.com>
- CC: www-style@w3.org
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. At the point when the unprefixed version starts being supported, there are three options, as I see it: 1) Drop support for the prefixed version. 2) Make the prefixed version an alias for the unprefixed one. 3) Keep the prefixed version meaning whatever it meant when you first implemented it, and have separate codepaths for handling them (and some way of deciding what to do if both are specified). #3 has some serious implementation complexity costs. #2 is, imo, pretty much equivalent to #1 except in the cases that we (Mozilla, at least; some other browser vendors seem to have a different stance on this) want to discourage anyway. Specifically, authoring of browser-specific pages. 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. -Boris [1] http://lists.w3.org/Archives/Public/www-style/2010Jul/0102.html last paragraph
Received on Friday, 9 July 2010 16:19:04 UTC