Re: A List Apart: Articles: Prefix or Posthack

Eric A. Meyer wrote:
>>>  then there will be a lot more reluctance to use vendor prefixes.

> At 8:32 AM -0700 7/9/10, Boris Zbarsky wrote:
>> 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!"

I'll play devil's advocate and ask, why can't they use it?  Firefox 4
will probably introduce several new behaviours that won't work for the
sites that authors are building today, either.  Your point seems to be
that once an author has embarked on exploiting a particular behaviour
(eg achieving a box shadow through pure CSS) then they have the right to
  expect that that behaviour be always available.  Maybe you're right --
but you'll have to justify that claim first.  Personally, whilst I
tend to expect unprefixed properties not to drop off the radar,  I
have rather different expectations for experimental properties.

If my site uses -moz-box-shadow today in Firefox 3.5 and 3.6 but fails
to get any box shadow in Firefox 4 because it fails to support
-moz-box-shadow, then tough luck for me.  I might go back and update the
site to use the unprefixed property -- but I'd have to have done that
anyway if I weren't using prefixed properties and wanted box
shadows in Firefox 4.  The error seems to lie in thinking that using
prefixed properties to tap into something earlier saves you time later.

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

I'm not sure I see the analogy, but for fun I'll try:  the date and I
both understand that the date (experimental) is something that's fun for
now while I'm waiting for the right person to come along (unprefixed
property).  [And vice versa of course! :-p]  It's mutually understood
that the date will be discarded when that permanent person comes along.
  This means at some point in the future I'm probably going to have to
make the effort (go back and revise the stylesheet) to have the tattoo
with the date's name surgically removed (add the unprefixed property,
and possibly remove the prefixed one).  Alternatively I might just keep
the tattoo and live with the possible associated marital strife.

(The case "date becomes life partner" is handled by "My partner would
make me erase all my tattoos anyway once we're married" so I'm not saved
any effort ;-)

I know what you're thinking:

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

As so often with these sorts of discussion, there seems to be a "one
size fits all" mentality, which I've never understood.  Things I do on
websites for prominent brand clients aren't the same as things I do for
granny's knitting pattern website.  I might use -moz-box-shadow on the
latter, but not the former.  How I tailor my work for a given situation
is part of what I get paid for.  So the high value client doesn't get
-moz-box-shadow, but that doesn't mean I don't experiment with that
property.  Web authors tend to be highly experimental and so I don't
think we should automatically assume that prefixed properties will be
ignored.

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Friday, 9 July 2010 17:30:17 UTC