CSS Idea: /*autoprefix*/

By on  

Using utilities likes SASS and Compass have made me me think a lot about how we can improve CSS in the short term.  Of course all CSS proposals should go through the W3C standardization process, but the problem is that those processes take a long time.  We also know that there are a lot of things we know we need in CSS:

  • CSS Variables
  • Nested style blocks (a la SASS, LESS, etc.)
  • Macros / routines

We know we need these things but still don't have them yet, and likely wont for years.  That got me to thinking about another problem:  the constant need to do the prefixing of properties for every browser, like this mess:

#someElement {
	-moz-animation-name: myAnimation;
	-webkit-animation-name: myAnimation;
	-ms-animation-name: myAnimation;
	animation-name: myAnimation;

Firefox has un-prefixed a majority of previously prefixed properties, but we still can't get away from this mess for other browsers.  So how can we fix this in the short term, besides making browser vendors unprefix?  One idea is doing something kind of like JavaScript's use strict;  we start our CSS file with something like this comment:


/* and then somewhere in the CSS file */
#someElement {
	animation-name: myAnimation;

If a CSS file started with this CSS comment, the browser would automatically prefix properties that required prefixing.  Since browsers know which properties need prefixing, and they only need to account for their prefix, this type of system would reduce code (and thus smaller/quicker file downloads) and, in theory, be much faster to implement.

Now this isn't a perfect solution by any means.  It should still be standardized at some point and unfortunately some prefixed properties act differently than unprefixed.  Just a thought that I wanted to share, get some feedback on.  Let me know if you think something like this would work!

Track.js Error Reporting

Recent Features

  • Responsive Images: The Ultimate Guide

    Chances are that any Web designers using our Ghostlab browser testing app, which allows seamless testing across all devices simultaneously, will have worked with responsive design in some shape or form. And as today’s websites and devices become ever more varied, a plethora of responsive images...

  • Serving Fonts from CDN

    For maximum performance, we all know we must put our assets on CDN (another domain).  Along with those assets are custom web fonts.  Unfortunately custom web fonts via CDN (or any cross-domain font request) don't work in Firefox or Internet Explorer (correctly so, by spec) though...

Incredible Demos


  1. Nice! I like it!

  2. But what about prefixed properties where syntax differ from vendor to vendor like it has happened in the past for flexbox, gradients, box-shadows and such ? How would the browser know to which syntax you’re referring to ?

    • They would use their own; that’s one of the downfalls of this, though you’d run into that problem anyway…

    • Eventhough autoprefix can be a solution, its a solution for the transition only. Browsers must grow up and understand the standards. :)

  3. Jeremy

    I’ve not really understood why vendor prefixes were really that necessary except in situations when the implementations varied between browsers. However, shouldn’t the default behavior of browsers be to use the official property unless a prefixed version exists (in case of targeting a quirk)? Why should we have to declare them at all?

    • For older versions of the same browser / engine?

  4. Jay

    It seems that browsers are moving away from the prefix:


    He cites a mozilla mail list comment that states similar for Firefox.

    That’s the better path, IMO, than trying to get the browsers to implement something like this across the board. The differences in syntax alone make this a challenging problem.

  5. What’s wrong with using prefixfree.js? http://leaverou.github.io/prefixfree/

    Works like a charme for me, and the extra 2kb load is worth it

    • There’s nothing wrong with it; my idea would provide something “native” though. Not saying either is better.

    • Hackwar

      What is wrong with those solutions is, that instead of reducing the load time of your site, they extremely increase it. These scripts work in a way that they read all loaded CSS files from your HTML and then *after* those have been loaded by the browser, load them again via AJAX, parse them and then set the selectors accordingly. So instead of loading a CSS file once, you load it twice. Yes, the 2kb of the JS is negligible, but the 50kb of extra CSS are actually not. That is why you use SASS/SCSS/Compass instead of this.

  6. Emir

    There is something like sass but with autoprefixes http://roole.org/#prefix I didn’t try it yet, but it looks promising.

  7. Nico

    In my opinion the only possible solution is to ban vendor-prefixes from production releases. They may be used for experiments in beta builds, but the final a release of a browser should only contain properly standardized features. One might say that this brings us back to the development lethargy some years ago, but the current solution brings us back to even older times where developers used to develop for one platform, because it was nearly impossible to cover all of them.

  8. Jhon

    I think that prefixes must be the same in all browsers, e.g. instead of -moz-animation-name: myAnimation; -webkit-animation-name: myAnimation; etc. It would be: -x-animation-name: myAnimation;
    -x represents the universal prefix (for all browsers).

  9. Prefixes aren’t ment to be used on production, they are just for experimenting and Firefox and now Blink chose a good policy for implementing new features, that are only available turning them on in browser settings. You won’t ride a car without one wheel, so should you use very early implementations of functionality in web?

    Also, there is https://github.com/ai/autoprefixer that adds only necessary prefixes referring to CanIUser API, works like a preprocessor.

  10. Adam

    It’s an interesting idea, but the idea of using prefixes is for authors, not browsers. There is no benefit to this over simply never implementing prefixes. Why should the browser translate the property if it can simply use it without prefixes.

    The idea of vendor prefixes made some sense when the development velocity of browsers was measured in years. Now that we have much more rapid iterations it makes no sense, except for those things that’s will likely never be part of a public standard (like for plugins or “native” apps).

  11. Hackwar

    A feature like this might be nice if everybody only used the latest version of the respective browser. Unfortunately that is not the case and instead we have loads of people that work with outdated browsers due to several reasons. My girlfriends netbook ran with FF9.0 until a few days ago, since she didn’t use it that much and FF didn’t query for a new version during those times. So she ran around with a version of FF that was 12 versions old (WTF?!?) and she would gain nothing from this feature.

    I mean, we are not adding the prefixes for the current browsers. All browsers in their latest version right now understand border-radius. But I’m still adding -moz-border-radius, -webkit-border-radius, -o-border-radius and even -ms-border-radius for all those people out there with the not-so-current versions.

    Implementing something like SCSS as a CSS replacement would benefit us all more than this. Because if the browser would prefix the stuff automatically, it would also understand the unprefixed versions directly and we could forget the prefixes altogether.

  12. DrClue

    Typing vendor prefixes was not something I was going to accept as a worthy use of finite lifespan. ~15 lines of code or so that runs during readystates (loading / interactive ) and the little critters ( Khtml Ms O Moz Webkit Web-Kit atsc wap mso all etc.) were history.

    Besides there is way too much fun to be had to allow those wanna-bees to gate crash the festivities, such as creating querySelector/All methods that return CSSStyleRules instead of elements, taking as arguments not only the regular selectors but elements themselves , regexp , and even plain old objects used to search property patterns.

    One would be amazed at just how easy it can be to smoothly fiddle with running animations , Turn the DnD API into a generic resource instead of a nuisance, wail on css3d and a zillion other things by simply replicating a few of the conversation tools one has grown to love in the DOM.

    Another interesting item is that once you get to know each other you’ll start to notice your line counts dropping and performance increasing as while not magic pixie dust , there is an additional plane of reality in working that side of the street that is not outwardly apparent but makes for new and unique development options based on things that have been there nearly forever.

Wrap your code in <pre class="{language}"></pre> tags, link to a GitHub gist, JSFiddle fiddle, or CodePen pen to embed!

Recently on David Walsh Blog

  • OSCON Portland:  Conference  Discount!

    O'Reilly puts on the best web industry conferences in the world.  These conferences include Fluent Conference, Velocity Conference, and the upcoming OSCON in Portland, Oregon from July 20-24.  Open Source Convention (OSCON) is a conference that focuses specifically on open source developers and the tools and possibilities...

  • Follow Redirects with cURL

    I love playing around with cURL. There's something about loading websites via command line that makes me feel like some type of smug hacker, just like tweeting from command line does. I recently cURL'd the Google homepage and saw the following: I found it weird that Google...

  • Developers Have WordPress, Amateurs Have Squarespace, Professional Designers Have the NEW Webydo!

    Web design platforms have traditionally come in one of two varieties. There are the solutions like WordPress and Drupal that are incredibly powerful, but an understanding of web development and coding is required to be able to use those platforms effectively. On the other side of the...

  • Chris Coyierâs Favorite CodePen Demos II

    Hey everyone! Before we get started, I just want to say it’s damn hard to pick this few favorites on CodePen. Not because, as a co-founder of CodePen, I feel like a dad picking which kid he likes best (RUDE). But because there is just so...

  • GSAP + SVG For Power Users: Motion Along A Path

    Now that the GreenSock API is picking up steam, there are many tutorials and Getting Started guides out there to provide good introductions to the library, not to mention GreenSock’s own Forum and Documentation. This article isn’t intended for beginners, but rather a...