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: Thu, 8 Jul 2010 15:32:48 -0400
Message-Id: <a06230917c85bd4431d64@[192.168.1.196]>
To: (wrong string) äper <christoph.paeper@crissov.de>, www-style list <www-style@w3.org>
At 8:35 PM +0200 7/8/10, Christoph Päper wrote:

>Although he actually addresses and rejects it, Eric Meyer seems to 
>assume that stylesheets are revised on a regular basis. CSS authors 
>must never make this assumption.

    Actually, explicitly I assume that CSS won't be revised after it's 
written.  The ongoing support of prefixed properties by browsers 
(even after they're allowed to remove the prefix) means those styles 
will continue to operate.  Yes, some behaviors might change in the 
meantime, but that is the risk people run.  Besides which, anyone 
still using that CSS after the behavior change will fix it, get it 
fixed, or drop it.

>=> Authors must never use vendor prefixed properties on the Web.
>=> Authors should never use draft prefixed properties on the Web.
>=> Authors should be safe to use anything unprefixed that gets into 
>CR, even if some of it gets removed later on.
>
>[...]
>
>=> UAs should ignore all rules with vendor prefixes, their own or 
>someone else's, except when loaded from disk or localhost.
>~~ At least for non-draft, proprietary features.

    This proposal would work to limit long-term problems and fulfill 
most of the goals I sought to fulfill, I agree.
    The downside-- and I regard it as being a very serious one-- is 
that very, very few people would actually use the prefixed 
properties, because they have better things to do with their time 
than fiddle around with something they can't put to use in their 
work.  That greatly reduces the number of eyeballs that are, whether 
they know it or not, searching for bugs and inconsistencies.
    With prefixed properties in the wild, we get a whole lot of people 
doing crazy things and finding unforeseen flaws or inconsistent 
implementations.  With the local-only proposal you are making, we get 
only those people dedicated enough to play with curiosities despite 
their lack of immediate benefit.
    There would also be the drawback of creating a situation where 
browsers act one way during development, and in some cases very 
differently after deployment.  I'm not sure you could get the vendors 
to accept that inconsistency, although perhaps I'm wrong about that. 
I'd be very interested to hear what the local reps think.

-- 
Eric A. Meyer (eric@meyerweb.com)     http://meyerweb.com/
Received on Thursday, 8 July 2010 19:33:23 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:29 GMT