RE: A List Apart: Articles: Prefix or Posthack

Friday, July 09, 2010 12:02 AM <dbaron@dbaron.org>:

>As much as possible, we want to avoid authors putting Gecko-specific
>content on the Web.  

David,

The philosophical thrust of this, I understand completely. After all,
vendor-specific content is what the standardization process is designed to
avoid. Vendor prefixes are a deal with the devil.
But let's make the best deal we can.

Again:

>As much as possible, we want to avoid authors putting Gecko-specific
>content on the Web.

The problem is, there's no "as much as possible" possible because you can't
have your cake and eat it, too. Once you add a feature with a prefix, the
cat is out of the bag. (If for no other reason, authors will leave the
prefixed code in place far beyond the release cycle to accommodate those who
continue to use previous Gecko releases.)
So the question is not what we are going to encourage or discourage but how
are we to manage what has already happened as we go forward? - How do we
manage the transition from the prefixed property to the unprefixed property?

(Look, I've been watching the world of browsers and standards roll by for
over ten years now and when I first saw the system of vendor prefixes appear
I couldn't help but think, "Wow. What a simple and easy system for
introducing new properties without driving everybody nuts." That's *my*
philosophical thrust. And I'm not alone, obviously.)

>So we have a choice between:
>1. supporting the -moz- prefix permanently
>2. supporting both for one release cycle to give authors a transition
period
>3. dropping the prefix immediately

I don't have any problem with #1 - and, seemingly other implementers don't
either. And in deference to those authors who are recommending it, I'd like
you to keep an open mind about it.

But since we're playing Let's Make A Deal (with the devil, that is), let's
see what's behind Door #2:

>2. supporting both for one release cycle to give authors a transition
period

Ok, there's a fair case to be made for an expiration. Never say "Never".
But why should one release cycle be the trigger? I'm sorry, but that seems
kind of arbitrary, if not solipsistic.
I don't have an alternative to propose. But I don't think there would be
consensus on an appropriate "trigger point" anyway. And that only reinforces
my predisposition to #1.

As for Door #3:

>3. dropping the prefix immediately

Do you mean no vendor prefixes at all? What's immediately? Not sure what you
mean.

Lastly, one thing that's been mentioned is a desire that authors
future-proof by pairing the prefixed code with the unprefixed code:

div.someclass{
-moz-box-shadow:....;
box-shadow:......;
}

This certainly *would seem* like a best practice. (With the emphasis on
"would seem" - if the syntax is still in high flux, as it sometimes is,
authors still have to bet on the horse they think will win for the
unprefixed property. So where's the future-proofing?)
However, implementers *could* enforce the pairing. Perhaps this would be an
acceptable interim step before pulling support for the prefix entirely. 
If -moz-box-shadow is used, box-shadow must follow within the rule. 

Does that work for you on any level?

Additional thoughts anybody?

Regards,

rich


-----Original Message-----
From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf
Of L. David Baron
Sent: Friday, July 09, 2010 12:02 AM
To: www-style@w3.org
Subject: Re: A List Apart: Articles: Prefix or Posthack

On Thursday 2010-07-08 22:41 -0400, Eric A. Meyer wrote:
> At 6:34 PM -0700 7/8/10, Boris Zbarsky wrote:
> 
> >What makes you think it costs little?
> 
>    I know you're asking Richard, but I'll step in and ask why it
> costs more than a little to do, in effect, this:
> 
>    if (property == '-moz-box-shadow' || property == 'box-shadow')
boxShadow();
> 
> As it is, your choice to drop prefixed-property support is hostile
> to authors, and I'm having extreme difficulty understanding why you
> think it's a good idea to take that path.

As much as possible, we want to avoid authors putting Gecko-specific
content on the Web.  Authors who are using -moz-box-shadow should
also be using box-shadow; if they're not, they're writing
Gecko-specific CSS (and perhaps some additional WebKit-specific CSS,
etc., alongside it, which is still hostile to any new entrants in
the browser space along with any omitted existing browsers).

So we have a choice between:
1. supporting the -moz- prefix permanently
2. supporting both for one release cycle to give authors a transition
   period
3. dropping the prefix immediately

I have trouble seeing any advantages of (2) over (3), since if we
wait longer to drop support for the prefixed version, there will
only be *more* content written using the prefix.

I really don't want to do (1), since it means that authors will
permanently be able to write Gecko-specific CSS without ever seeing
that it's a problem.

-David

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/

Received on Friday, 9 July 2010 16:15:45 UTC