- 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