Re: A List Apart: Articles: Prefix or Posthack

At 8:32 AM -0700 7/9/10, Boris Zbarsky wrote:

>It's been the default for Gecko for years now, no?  I mean... we 
>dropped -moz-opacity when we shipped Firefox 3.5 (support was gone 
>on trunk in fall 2008 and in the release in June 2009).  We'd 
>dropped other things before that without adding an alias, iirc.

    'opacity' had a tortuous enough history that I'm not sure how many 
lessons we can draw from it, but I also didn't realize that prefix 
support had been dropped altogether.  I'd likely have objected at 
some point if I had.  Besides which, I recognize that what I have 
proposed is a change in past behavior.  I guess I wasn't aware of the 
specific degree of required change, but in for a penny, in for a 
pound, eh?

>>  then there will be a lot more reluctance to use vendor prefixes.
>
>Why?

    Because the perception becomes one of instability.  It doesn't 
have to make logical sense.  If I stood in front of a room of people 
and explained that prefixed properties are in-progress and can 
change, there might be grumbling but they can deal with that.  If I 
then state the prefixed properties will be completely unrecognized in 
the future, the immediate and overwhelming reaction would be, "Why 
the hell are you wasting my time telling me about something that will 
by design stop working?  I can't use that!"
    By analogy, there's a difference between discussing with someone 
you're dating that changes, even major ones, may occur as you each 
grow; and quite another to promise them that you're going to dump 
them at some point down the road.

>>>  -moz-box-shadow: ...;
>>>  box-shadow: ...;
>>>
>>>  as far as I can tell. Am I missing something?
>>
>>  Actually, no, that's fine. But there may be cases where the unprefixed
>>  property is not listed
>
>Why not?  And as David said, aren't those exactly the cases we want 
>to discourage?

    An example that comes to mind, though it's arguably not exactly 
the same thing, is with gradients.  Right now, to get a similar 
effect in WebKit and Gecko, you'd need to write:

   -webkit-gradient{linear,...};
   -moz-linear-gradient{...};

Where the two '...' are actually written very differently.  So then 
I'm supposed to write this?

   -webkit-gradient{linear,...};
   -moz-linear-gradient{...};
   gradient{linear,...};
   linear-gradient{...};

I really doubt that will happen, given that the syntaxes (not to 
mention the property names) are so different.  But if someone needs a 
given gradient for a project, and the client is okay with progressive 
enhancement, they might well do the first of the two examples there.
    We can of course say "well they shouldn't be messing with those in 
the first place" but without people messing with them, how are we 
supposed to get any useful author feedback?  Without that feedback, 
what are the odds that problems will remain undiscovered until it's 
too late?

>I really wonder why people have these expectations that have no 
>bearing on reality, at least not if you're paying attention for the 
>last 2-3 years...

    You could as well ask why people have clearly inaccurate and 
reality-free opinions about politics, science, programming languages, 
or anything else.  That's what happens in any large population, and 
even in most small ones.  Even when people are paying attention.

>>  Perhaps the solution is a major push to change expectations, but my
>>  concern is that even that will push many people away from experimenting
>>  (because "they're just going to kill this later") and thus rob us of
>>  much-needed eyeballs.
>
>I agree that this is a valid concern, but we should be encouraging 
>people to use the unprefixed property at the end if the have this 
>concern.  Of course then if the spec changes they'll have to change 
>their unprefixed usage... but they have to change their prefixed 
>usage too, in that case.  For Gecko, that is.

    I'm okay with having to change prefixed properties.  In fact, that 
needs to be possible.  What I'm arguing for is a situation where 
'bare' (unprefixed) properties should be as close to a guarantee of 
non-changingness as we can manage.  (Nothing's certain, of course, 
but we can try.)  By letting prefixed properties be variable and 
using that as part of the process, we have a chance to get unprefixed 
properties fairly solid.  That would mean vendors changing the way 
they handle prefixes, and apparently even more so than I had realized.
    The end goal for me is to improve things for authors, by making 
bare properties more reliable and solid while still allowing them to 
try out (and thus test out) prefixed properties.  Also, the idea is 
to provide more incentive to create testing suites and a way for 
properties to be publicly declared to have reached interoperability.
    And, of course, I'm trying to do all that within the framework of 
what I believe authors currently expect as well as what I believe 
they will accept.

-- 
Eric A. Meyer (eric@meyerweb.com)     http://meyerweb.com/

Received on Friday, 9 July 2010 16:19:36 UTC