W3C home > Mailing lists > Public > www-style@w3.org > February 2012

About vendor prefixes

From: Adam van den Hoven <adam@littlefyr.com>
Date: Thu, 9 Feb 2012 07:40:35 -0800
Message-ID: <CAAkH_kPbMAe8gniM9C=0vfnR9Ya4K8Z9futYsVQzFPxX64naqQ@mail.gmail.com>
To: www-style@w3.org
Hi all,

I have to wonder about all the hullabaloo over vendor prefixes that seems
to have erupted recently.

I understand the value for me, as a web developer, to use prefixes as flag
that tells me "hey this is not quite finalized". But is there a compelling
reason to use a *vendor specific* prefix? What benefit is there, to me, in
having in my code:


It drives me nutz and it seems that it drives you nutz too.

Why would it not work to simply say that prefixes are always ignored by
browsers? Is it not the case that rules say

   1. if you don't understand a property, ignore it.
   2. if the value for a property is somehow wrong or unknown, ignore it
   (and don't modify the value that the property might already have)

This should handle 90+% of the situations we encounter in day-to-day life.
Lets take the example of border radius where mozilla has (had?) different
properties for specific corners. Would this code necessarily cause problems
for browsers, given the rules as I stated them?

border-top-left-radius: 10px;
border-radius-topleft: 100px;

Sure, on the day that a browser implementing border-radius-topleft decided
to follow the standard, it would have to decide what to do about the
conflicting instructions, but it has to do that regardless.

This has the added benefit that I can choose the prefixes I want. So if I
want to use -css1- -css2- and -css3- for all my properties, no one needs to
care but me (assuming a green field where every browser did this).

For those 10% of situations not handled by the 'normal' rules, you add this
new behaviour. "When it is significant, your browser must honor those
prefixes it knows about, and 'promote' those properties above other
equivalent properties."

Let's say I release my own browser and for very good reasons (bear with me,
I can't think of a reasonable example) my browser interprets multiple
lengths in reverse order for padding, and I'm going to use -adam- for my
prefix. In that case the following:

-adam-padding: 1px 2px 3px 4px;
padding: 5px 6px 7px 8px;

would result in a padding-left value of 1px for my browser and 8px for
everyone else. Any property or function (say gradient functions) would be
handled this way.

I don't know much of anything about creating browsers, other than I rely on
you guys for nearly everything I do. I have probably missed a subtlety and
its almost certainly not as easy to implement as I'd like to think, but I
don't think this breaks the web (if I choose to use my own prefixes then
I'm happy to live with the consequences). This is obviously an issue for
everyone. Prefixes were introduced for very good reasons, I'm sure, but if
they're creating more harm than help right now, maybe its time to think of
a different approach?

Received on Friday, 10 February 2012 08:05:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:11 UTC