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

Re: A List Apart: Articles: Prefix or Posthack

From: Eric A. Meyer <eric@meyerweb.com>
Date: Fri, 9 Jul 2010 09:59:32 -0400
Message-Id: <a0623091dc85cd9c51307@[]>
To: www-style@w3.org
At 9:02 PM -0700 7/8/10, L. David Baron wrote:

>On Thursday 2010-07-08 22:41 -0400, Eric A. Meyer wrote:
>>  At 6:34 PM -0700 7/8/10, Boris Zbarsky wrote:
>>  >What makes you think it costs little?
>>     I know you're asking Richard, but I'll step in and ask why it
>>  costs more than a little to do, in effect, this:
>>     if (property == '-moz-box-shadow' || property == 'box-shadow') 
>>  As it is, your choice to drop prefixed-property support is hostile
>>  to authors, and I'm having extreme difficulty understanding why you
>>  think it's a good idea to take that path.
>As much as possible, we want to avoid authors putting Gecko-specific
>content on the Web.  Authors who are using -moz-box-shadow should
>also be using box-shadow; if they're not, they're writing
>Gecko-specific CSS (and perhaps some additional WebKit-specific CSS,
>etc., alongside it, which is still hostile to any new entrants in
>the browser space along with any omitted existing browsers).

    I want the same.  But I also have the sense that that doesn't 
always happen-- that a career lifetime of having to write 
browser-specific hacks and sniffers and whatnot have trained people 
to be browser-specific and forget the general case.  In my 
experience, silently punishing people for their forgetfulness or poor 
training doesn't make them better authors.  It just pushes them away 
from using things like CSS.
    Besides which, I think (or maybe I hope) I made clear in the ALA 
piece why I think prefixes should continue to be supported:  in the 
context of a process that is apparently at odds with how it's 
sometimes done.  In my conception, as I said in another message, 
prefixed properties can change behavior from one release to another. 
May, in fact, have to change behavior, as we're seeing with shadow 
blurring.  Eventually they reach a state where they're interoperable 
and no longer changing.  Then the unprefixed version is supported 
along with the prefixed, which is really just aliasing one to the 
other, because the two act the same.
    If you're telling me that vendors are stuck with keeping 
prefixed-property behaviors the same even when changes need to be 
made, then we need to talk instead about ways to version prefixes: 
'-moz-v1-box-shadow' or some such.  Otherwise, we're just begging for 
another case (or many cases) of inconsistent implementations of 
unprefixed properties.

Eric A. Meyer (eric@meyerweb.com)     http://meyerweb.com/
Received on Friday, 9 July 2010 14:00:09 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:37 UTC