CSS Idea: /*autoprefix*/
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:
/*autoprefix*/
/* 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!
Nice! I like it!
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. :)
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?
It seems that browsers are moving away from the prefix:
http://alistapart.com/blog/post/paul-irish-on-chrome-moving-to-blink
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.
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.
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.
There is something like sass but with autoprefixes http://roole.org/#prefix I didn’t try it yet, but it looks promising.
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.
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).
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.
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).
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-radiusand even-ms-border-radiusfor 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.
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.