Re: A List Apart: Articles: Prefix or Posthack

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

>On 7/9/10 9:19 AM, Eric A. Meyer wrote:
>>  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{...};
>
>I agree this is an issue.  However authors who use 
>-moz-linear-gradient have _already_ had to update their stylesheets 
>once when we changed the syntax.  Why is that OK but asking them to 
>update when the spec goes to CR is not ok?

    I don't understand the distinction you're drawing, but maybe 
because I come at it from a different direction.  Once a spec hits CR 
or is even ready to hit CR, at which point bare properties can be 
supported in conforming implementations, there shouldn't be any more 
changes to behavior.  That's what I'm trying to accomplish here.

>>  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.
>
>Sure.  And their project might break any time if the spec changes 
>and we track it, right?

    Right.  That is a possibility no matter how we approach this, 
whether we do it the way it's done now, or the way I proposed, or the 
way Christoph proposed, or some other as-yet-unimagined way.  Part of 
what I'm trying to do is minimize the odds of it happening once CR is 
reached.  Before that, it has to be permitted, or else there's little 
point in having prefixes on in-spec properties at all, regardless of 
the stage of the spec.

>>  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?
>
>Fully agreed.  The issue is how to make sure we get this feedback. 
>Are we at least agreed that freezing your vendor prefixed property 
>the moment you implement it is not hte way to do it?

    Yes, I think I've been clear about that.

>>  That would mean vendors changing the way they handle
>>  prefixes, and apparently even more so than I had realized.
>
>Well, right now you're advocating a behavior (change prefixed 
>properties until the spec goes to CR, then freeze in perpetuity as 
>an alias to the unprefixed property) that seems to be 
>philosophically opposed to both the Webkit/IE and Gecko approaches 
>(which are already philosophically quite different).  Are we on the 
>same page so far?

    Insofar as we realize that there are a whole host of different pages, yes.

>As I already said, that approach doesn't make that much sense to me, 
>personally....

    Nor does the way it's done now make sense to me, personally...

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

Received on Friday, 9 July 2010 18:24:48 UTC