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

Re: A List Apart: Articles: Prefix or Posthack

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Fri, 09 Jul 2010 09:18:29 -0700
Message-ID: <4C374BD5.1000503@mit.edu>
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.


[1] http://lists.w3.org/Archives/Public/www-style/2010Jul/0102.html last 
Received on Friday, 9 July 2010 16:19:04 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:13:48 UTC