Mass-unprefixing in Firefox 16(paulrouget.com)
paulrouget.com
Mass-unprefixing in Firefox 16
http://paulrouget.com/e/unprefixing-in-firefox-16/
7 comments
That's exactly what Firefox developers like Henri Sivonen [1] and David Baron [2] think, and their proposals have a lot of support within Mozilla and a high chance of being adopted. It would be great to get other vendors on board too.
[1] http://hsivonen.iki.fi/vendor-prefixes/ (see "Keep Experimental Features in Experimental Builds")
[2] https://groups.google.com/d/msg/mozilla.dev.platform/itl6mtx... (dbaron is Mozilla's representative to the W3C Advisory Committee as well being a principal engineer on the layout team and deeply involved in the development of CSS over the past decade.)
[1] http://hsivonen.iki.fi/vendor-prefixes/ (see "Keep Experimental Features in Experimental Builds")
[2] https://groups.google.com/d/msg/mozilla.dev.platform/itl6mtx... (dbaron is Mozilla's representative to the W3C Advisory Committee as well being a principal engineer on the layout team and deeply involved in the development of CSS over the past decade.)
From the first bug linked from the article (at https://bugzilla.mozilla.org/show_bug.cgi?id=762302):
The CSS Working Group has agreed to give the go-ahead to browser implementers to unprefix CSS3 Transitions, Transforms, and Animations:
http://lists.w3.org/Archives/Public/www-style/2012Jun/0105.html
> So contrary to your comments, they're doing this because the W3 said that it's time to do so.
My point is that support for prefixed CSS properties should not be available in stable releases at all.
What they should have done from the beginning (and from other comments seems it will be done in the future) is to enable experimental prefixed CSS properties only in dev builds (to demonstrate to the W3C working group the feasibility of those new properties) and remove such properties from stable releases. In this way the stable releases will have _only_ W3C approved prefixes, not the current mess of draft + CR + TR support.
My point is that support for prefixed CSS properties should not be available in stable releases at all.
What they should have done from the beginning (and from other comments seems it will be done in the future) is to enable experimental prefixed CSS properties only in dev builds (to demonstrate to the W3C working group the feasibility of those new properties) and remove such properties from stable releases. In this way the stable releases will have _only_ W3C approved prefixes, not the current mess of draft + CR + TR support.
In other words: same as IE10. http://blogs.msdn.com/b/ie/archive/2012/06/06/moving-the-sta...
Firefox 16 will hit the mozilla-release channel on October 9: https://wiki.mozilla.org/RapidRelease/Calendar
The problem with all those prefixes is the w3c. They are stuck in the web of the 90.
-moz-border-radius and -moz-box-shadow were both unprefixed in 13, I only know because I had a personal html page themed for firefox exclusively which was affected.
There doesn't seem to be much comment on this unprefixing from Mozilla in any Official capacity, when my personal page was affected it was only by accident that I ran across this page https://developer.mozilla.org/en/Firefox_13_for_developers that mentions it.
Just thought I'd mention this in case anyone was affected.
I personally think we should cut down on prefix use. Whilst it may be impractical to completely eliminate them, they are a PITA for developers, and have made the mobile web too heavily reliant on WebKit.
Maybe this is pigheaded or troglodyte-esque of me, but I solve this problem by refusing to use any CSS 'features' that require prefixes.
I can live without gradients, my life will go on.
I can live without gradients, my life will go on.
Hmm, good point. In general I rarely use special prefixed CSS features, and the ones that I do are rarely worth the effort.
I know, i am using transitions/gradients on my project and i have to write 5(!) different rules just to set one property. This is for production code.
Edit: And i should mention, this is not a mobile website, it's a desktop site.
background: -webkit-linear-gradient(#fff, #fdd 75%, #fcc);
background: -moz-linear-gradient(#fff, #fdd 75%, #fcc);
background: -ms-linear-gradient(#fff, #fdd 75%, #fcc);
background: -o-linear-gradient(#fff, #fdd 75%, #fcc);
background: linear-gradient(#fff, #fdd 75%, #fcc);
Edit: And i should mention, this is not a mobile website, it's a desktop site.
Missed one:
And it's also an example of why prefixes were invented - the syntax is totally different.
I think vendors should unprefix the moment their prefix matches the spec.
background: -webkit-gradient(linear, 0 0, 0 100%, from(#fff) color-stop(75%, #fdd) to(#fcc));
And it's also an example of why prefixes were invented - the syntax is totally different.
I think vendors should unprefix the moment their prefix matches the spec.
>>I think vendors should unprefix the moment their prefix matches the spec.
most of the time when all prefixed version are the same it means there isn't a CR for the spec, and it is therefore in flux. unprefixing it would mean sites would break if and when it is changed before reaching recommendation.
most of the time when all prefixed version are the same it means there isn't a CR for the spec, and it is therefore in flux. unprefixing it would mean sites would break if and when it is changed before reaching recommendation.
Don't know what "CR" is (community recommendation?), but obviously I mean once the spec is finalized, not just when the spec is proposed.
Candidate Recommendation; the state of a W3 recommendation where they call for vendor implementations.
and as I said, this is not the case for most things that are prefixed.
They would break anyway, what's your point?
Yeah. And that's without supporting older versions of syntax. You might need another 2 or 3 lines if you're unlucky, or possibly worse.
Many people including myself think prefixes should be eliminated entirely[1], or replaced with a single prefix for the experimental[2].
[1] http://paulirish.com/2012/vendor-prefixes-are-not-developer-...
[2] http://www.quirksmode.org/blog/archives/2010/03/css_vendor_p...
Many people including myself think prefixes should be eliminated entirely[1], or replaced with a single prefix for the experimental[2].
[1] http://paulirish.com/2012/vendor-prefixes-are-not-developer-...
[2] http://www.quirksmode.org/blog/archives/2010/03/css_vendor_p...
Why not uses SASS and let mixins do that crap?
It's probably just me but I don't use libraries and secondary "languages" that compile to another language (in web development context). So no jquery, coffeescript, SASS, LESS, pIE etc. I don't feel satisfied when my code's efficiency/speed depends on some one else's code. It somehow means i am not in full control of things. I like to keep dependencies to a minimum. Which basically means I don't want to include any files in my webpage that are not written by me. (Google Analytics is an exception though)
It's kind of an obsession really, to the point that I furiously try not to use any third party library unless absolutely needed. And I haven't needed one until now. And I have also yet to regret these decisions.
It's kind of an obsession really, to the point that I furiously try not to use any third party library unless absolutely needed. And I haven't needed one until now. And I have also yet to regret these decisions.
You must be a rich man. I don't have the time or money to exclude everything that's Not Invented Here.
Yes, I see your point. Re inventing the well makes no sense, i agree whole heatedly. But the fact is i never had to reinvent the wheel, outside of the prefixing madness. I kind of hate jquery. It used to be very useful back in day but nowadays unless it's something very specific, jquery pretty much falls face first compared to native browser stuff. Using queryselectorall for example is alot faster in browser where as jquery is very slow, same goes for most common js functions and animations.
So i am not for reinventing the wheel, i just don't like to use square tires when round ones are better and readily available.
So i am not for reinventing the wheel, i just don't like to use square tires when round ones are better and readily available.
I use CoffeeScript, but I'm reluctant to use SASS or LESS, since they are ugly and I generally want to avoid having to use software to manipulate my HTML/CSS content. I'm fine with JS, but I like my compile script only having to copy my index.html and style.css file across, not having to invoke a CSS compiler.
The CSS compilers really dont make much sense to me. The language is very easy/simple as is (vendor prefixes are a mess though) and having a compiler's overhead on every request does not feel right to me.
I love JS though, in fact it's my favorite go to language for all kinds of work, heavy duty or light. I thinks that is also a part of the reason I am not inclined towards languages that compile to JS, they kind of destroy the experience of writing JS, which I am very fond of.
I love JS though, in fact it's my favorite go to language for all kinds of work, heavy duty or light. I thinks that is also a part of the reason I am not inclined towards languages that compile to JS, they kind of destroy the experience of writing JS, which I am very fond of.
If you're running the LESS compiler on every request, you're doing it wrong. Doing that might make sense in development, but for deployment you're expected to run the compiler once to generate a single static, minified CSS file. Same as JS compilers/minifiers in that respect.
As far as what these compilers do? Yes, CSS is nice enough as it is; that's why these compilers don't mess with the syntax too much. Most of what they're useful for is acting as a macro preprocessor (so you can use @color macros and automatically generate vendor prefixes, for instance), as well as for efficiently combining multiple source files.
If you're not familiar with how useful CSS compilers like LESS can be, I'd highly recommend that you take a look at Twitter Bootstrap. They use the macro-processing features pretty heavily, and to impressive effect. For instance, most of the colors in a Bootstrap site are configured in variables.less -- including light/dark color variants! -- so you can change around the whole color scheme of a Bootstrap site by adjusting just a few color definitions.
As far as what these compilers do? Yes, CSS is nice enough as it is; that's why these compilers don't mess with the syntax too much. Most of what they're useful for is acting as a macro preprocessor (so you can use @color macros and automatically generate vendor prefixes, for instance), as well as for efficiently combining multiple source files.
If you're not familiar with how useful CSS compilers like LESS can be, I'd highly recommend that you take a look at Twitter Bootstrap. They use the macro-processing features pretty heavily, and to impressive effect. For instance, most of the colors in a Bootstrap site are configured in variables.less -- including light/dark color variants! -- so you can change around the whole color scheme of a Bootstrap site by adjusting just a few color definitions.
> you're expected to run the compiler once to generate a single static, minified CSS file.
Yes, i stand corrected on that, i don't use them but that is not an excuse for ignorance. Plus compiling once makes more sense than compiling every time.
I also use webkit's web inspector for making live changes to a stylesheet and then saving the file in the end, very convenient compared to the changing-saving-uploading-refreshing cycle. Also it is another barrier to entry for my open source project. (someone has to know all the compiling process to contribute)
And as for uses of compilers, with CSS variables at the horizon (already functional in chrome canary IIRC) and other than this vendor prefixing problem (which everyone knows is very real and seeing the rapid release cycles of all major browsers now days, it is not far fetched to see a solution being cooked up some time soon) compilers don't have much to tackle. The cost v/s return ratio will reduce and probably even be negative in near future (if not already).
The cost is of compiling every time during development and once every time production code changes. I don't know about you, but if i am not live editing css in web inspector, i make a ton of very small changes to CSS and try them out one by one by refreshing the page. Not a great experience if i have to go to command line every time i change a byte.
> Efficiently combining multiple source files.
This problem can only arise in very big projects and if your project is in that category then there are all sorts of solutions available. (including writing your own compiler) But if that problem exists in a small or even middle sized project, them i believe, the solution is not the compiler but to re-factor the code base to use less files or merging them.
Yes, i stand corrected on that, i don't use them but that is not an excuse for ignorance. Plus compiling once makes more sense than compiling every time.
I also use webkit's web inspector for making live changes to a stylesheet and then saving the file in the end, very convenient compared to the changing-saving-uploading-refreshing cycle. Also it is another barrier to entry for my open source project. (someone has to know all the compiling process to contribute)
And as for uses of compilers, with CSS variables at the horizon (already functional in chrome canary IIRC) and other than this vendor prefixing problem (which everyone knows is very real and seeing the rapid release cycles of all major browsers now days, it is not far fetched to see a solution being cooked up some time soon) compilers don't have much to tackle. The cost v/s return ratio will reduce and probably even be negative in near future (if not already).
The cost is of compiling every time during development and once every time production code changes. I don't know about you, but if i am not live editing css in web inspector, i make a ton of very small changes to CSS and try them out one by one by refreshing the page. Not a great experience if i have to go to command line every time i change a byte.
> Efficiently combining multiple source files.
This problem can only arise in very big projects and if your project is in that category then there are all sorts of solutions available. (including writing your own compiler) But if that problem exists in a small or even middle sized project, them i believe, the solution is not the compiler but to re-factor the code base to use less files or merging them.
The most elegant way to handle this (IMO) is to use a combination of Compass(http://compass-style.org/) and Vogue(http://aboutcode.net/vogue/).
Compass has a great command line feature called "watch" that simply watches for file system events (linux, os x) or polls (windows) your folders for changes and recompiles your stylesheets.
Vogue detects stylesheet changes right away and reloads them in your page via WebSockets.
Instead of dealing with Chrome's inspector, making changes, then copying them to your CSS (and translating if you like SASS), I simply make changes in my editor on one monitor while watching my site on the other monitor. The overhead is minimal - I see changes within about 500ms.
Compass is great even just as a build tool, and I used it before I learned SASS. It's fantastic for its simple mixins like linear-gradient and even better when you start chaining them together. One of my favorite mixins I use throughout my code:
Compass has a great command line feature called "watch" that simply watches for file system events (linux, os x) or polls (windows) your folders for changes and recompiles your stylesheets.
Vogue detects stylesheet changes right away and reloads them in your page via WebSockets.
Instead of dealing with Chrome's inspector, making changes, then copying them to your CSS (and translating if you like SASS), I simply make changes in my editor on one monitor while watching my site on the other monitor. The overhead is minimal - I see changes within about 500ms.
Compass is great even just as a build tool, and I used it before I learned SASS. It's fantastic for its simple mixins like linear-gradient and even better when you start chaining them together. One of my favorite mixins I use throughout my code:
@mixin buttonGradient($color){
@include basicBackgroundGradient($color);
&:hover, &.hover{
@include basicBackgroundGradient(hover-color($color));
}
&:active, &.active{
@include basicBackgroundGradient(active-color($color));
}
}
@mixin basicBackgroundGradient($color, $percent:12%){
background: $color;
@include background-image(linear-gradient($color, darken($color, $percent)));
}
Actually chrome has this feature too. When you have saved a file once manually, it keeps track. So whenever you make live changes on the resources panel it live updates the DOM and upon clicking save, it automatically rewrites the file at it's original location. So it pretty much mimics the solution you suggested without any command line tools, extra file inclusion, downloads, etc. (http://www.youtube.com/watch?v=3pxf3Ju2row)
If you go up, you can read my comment in which i say why i dont like extra libraries, compilers for web work. (http://news.ycombinator.com/item?id=4219980) This is pretty much why.
And for the global mixin, (Which is pretty cool IMO, it really enables a lot more possibilities and creativity) you pretty much give the reason not to use them anywhere out side of practice work. 18 lines are huge. Plus css variables are pretty much on horizon, it is well worth the wait.
If you go up, you can read my comment in which i say why i dont like extra libraries, compilers for web work. (http://news.ycombinator.com/item?id=4219980) This is pretty much why.
And for the global mixin, (Which is pretty cool IMO, it really enables a lot more possibilities and creativity) you pretty much give the reason not to use them anywhere out side of practice work. 18 lines are huge. Plus css variables are pretty much on horizon, it is well worth the wait.
> Not a great experience if i have to go to command line every time i change a byte.
That's why, as was already mentioned, you generate them on the fly during development and generate them statically for production. That way you change the file on the file in your editor and it's updated immediately in your dev environment, but there's zero overhead in production.
That's why, as was already mentioned, you generate them on the fly during development and generate them statically for production. That way you change the file on the file in your editor and it's updated immediately in your dev environment, but there's zero overhead in production.
What request overhead? I thought people used them when developing and pushed the compiled result to the server.
And I love JS too, but I use CoffeeScript since it's basically syntactic sugar for JS that saves me some keystrokes and makes my code more readable.
And I love JS too, but I use CoffeeScript since it's basically syntactic sugar for JS that saves me some keystrokes and makes my code more readable.
> I thought people used them when developing and pushed the compiled result to the server.
Oh well, i see, that makes sense, but as i said i don't use them so i don't know very much about them. I probably should use them once just for the sake of checking them out. And coffeescript too. Thanks!
Oh well, i see, that makes sense, but as i said i don't use them so i don't know very much about them. I probably should use them once just for the sake of checking them out. And coffeescript too. Thanks!
> The CSS compilers really dont make much sense to me.
CSS doesn't have variables. I can change my site's color scheme by changing just a few variables. (And I need to, too, because I'm not exactly great at picking them out in the first place...)
CSS doesn't have variables. I can change my site's color scheme by changing just a few variables. (And I need to, too, because I'm not exactly great at picking them out in the first place...)
Your comment actually explains to me, what I didn't know without CSS experience: What this post is actually about.
Looks like this is begging for a macro. Write it once, highlight, ctrl+something, the other specific versions are automatically created in place.
I recently switched to Sublime Text[1] as my editor of choice, and one of the available packages is a macro that runs CSS blocks through prefixr[2]. It's been an absolute godsend (and Sublime Text in general is ... sublime.)
[1] http://www.sublimetext.com/
[2] http://prefixr.com/
[1] http://www.sublimetext.com/
[2] http://prefixr.com/
Why include the MS prefix? the only browser that support is not yet in production and will presumably unprefix it before it ships.
The project i am working on needs IE support, and i won't be making big changes to code once it has been deployed. It's a contract based work and not employment. So if it is not unprefixed by august, i will still have support for the browser.
Not really, unless you only contracted to support IE 10.
There is a proprietary filter property that works on previous versions IE.
There is a proprietary filter property that works on previous versions IE.
"I am not surprised at all if developers move to supporting just webkit."
that's why Mozilla is unprefixing IMO.
But yep, so much for standards.
that's why Mozilla is unprefixing IMO.
But yep, so much for standards.
Dear browser makers, please, enable your prefixed CSS properties only in dev/night/beta builds. Leave only unprefixed CSS properties in the release stable browsers. With this you will be able to test new features, show them to web developers and, at the same time, save them from the madness of maintaining five different slightly different versions of new CSS properties. How many developers do you think will not remove the `-moz-` prefixes from they CSS? Who do you expect to say "from now on we will only support Firefox 16, let's drop the prefixed version used by older versions"?
Prefixes are for testing, not for stable applications.