Re: A List Apart: Articles: Prefix or Posthack

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?

> 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?

> 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?

> I'm okay with having to change prefixed properties.

But only until the spec goes to CR?  Then you're not ok with having to 
change them anymore?  Why?

> 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.

Agreed.  I think everyone is on board with 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?

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

> 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.

I think we're all on board with that goal.

> 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.

Also on board with that.

-Boris

Received on Friday, 9 July 2010 17:01:50 UTC