meyerweb.com

Skip to: site navigation/presentation
Skip to: Thoughts From Eric

In Defense of Vendor Prefixes

…that having been the original working title for “Prefix or Posthack“, my latest article for A List Apart.  (Sort of like Return of the Jedi had a working title of Blue Harvest.)  In a fairly quick read, I make the case that vendor prefixes are not only good, they have the potential to be great and to deliver greater interoperability and advancement of CSS.

So far the reaction has been overwhelmingly positive, which frankly came as a bit of a surprise.  The annoyance factor of prefixes is undeniable, and it’s been my experience that annoyance dramatically hardens opposition regardless of whether or not there are good reasons to oppose.  I could flatter myself that the agreement is due to the Obvious Rightness of my argument, but I suspect it’s actually that I merely articulated what most people had already instinctively decided for themselves.  Which isn’t a bad place to be.

Anyway, if you haven’t already, feel free to decide for yourself by reading the article—which, I feel like mentioning for no clear reason, is only the fourth piece I’ve ever written for ALA.

Seven Responses»

    • #1
    • Comment
    • Wed 7 Jul 2010
    • 1451
    Stephanie Hobson wrote in to say...

    The annoyance factor of prefixes is less than the annoyance factor of hacks ;)

    • #2
    • Comment
    • Wed 7 Jul 2010
    • 1614
    Michael C. wrote in to say...

    Indeed, and I think that anyone “advanced” enough in CSS to be aware of vendor prefixes is most likely someone who also went through /* the pai\n of “\”}\”” various @hacks \*/.

    • #3
    • Comment
    • Wed 7 Jul 2010
    • 1858
    Miles wrote in to say...

    The prefixes are intentional, its as simple as that. Which means we can make them what we want them to be.

    It becomes a win-win for authors that want a way to “filter” for different browsers and their capabilities, and its a way for vendors that want to test something and see what works and get feedback.

    • #4
    • Comment
    • Sun 11 Jul 2010
    • 2036
    Richard Fink wrote in to say...

    “it’s actually that I merely articulated what most people had already instinctively decided for themselves.”

    True for me. Glad someone with your standing brought it to the fore. I only hope implementors reach a consensus on best-practice for prefixes. Like any system, predictability and consistency are key.

    • #5
    • Comment
    • Sun 18 Jul 2010
    • 1201
    Adam wrote in to say...

    Any predictions for how browsers can prefix CSS3 features that aren’t properties like -moz-border-radius? I’ve seen on css3.info that Firefox 4 will bring -moz-calc() which is cool, but I wonder how one would prefix, say, the new “rem” unit (http://www.w3.org/TR/css3-values/#relative).

    • #6
    • Comment
    • Thu 5 Aug 2010
    • 1202
    Mike wrote in to say...

    To be honest, I sort of wish every property could have a vender specific prefix, not just the in progress ones.

    Every now and then, for reasons you can’t figure, you need to get Webkit to have a different line height than other browsers, or Firefox needs a different width, or IE needs a different margin and you just wish you could:
    p { line-height: 22px; -webkit-line-height: 24px; }

    • #7
    • Comment
    • Wed 15 Sep 2010
    • 1100
    Erik wrote in to say...

    Honestly you could probably say the most random craziest thing and people would agree with you. Because people trust you. You are are the best of the best. A lot of people don’t think for themselves. You have a lot of influence on today’s standards and practices and people know it. Some follow blindly.

    But, you are trusted for a reason. You’ve not yet lead us astray.

Leave a Comment

Line and paragraph breaks automatic, e-mail address required but never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>



Remember to encode character entities if you're posting markup examples! Management reserves the right to edit or remove any comment—especially those that are abusive, irrelevant to the topic at hand, or made by anonymous posters—although honestly, most edits are a matter of fixing mangled markup. Thus the note about encoding your entities. If you're satisfied with what you've written, then go ahead...


July 2010
SMTWTFS
June October
 123
45678910
11121314151617
18192021222324
25262728293031

Sidestep

Feeds

Extras