7 ms·

Mass-unprefixing in Firefox 16

71 points by cleverjake 14y ago

kaizenfury7 14y ago
None of the bug links are working for me.
- paulrouget 14y ago
  Should work now.
bugschivers 14y ago
-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 https://developer.mozilla.org/en/Firefox_13_for_developers that mentions it. Just thought I'd mention this in case anyone was affected.
TazeTSchnitzel 14y ago
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.
- Achshar 14y ago
  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. 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); And this is used every time i have to set a gradient. I really wish there were some better options than prefixes. I am not surprised at all if developers move to supporting just webkit. This is a lot of work and maintaining. And without css variables, it is a mess to change a color. It is very tempting to just use the -webkit- version and probably a non prefixed one for future compatibility. 2 is far better than 5. Edit: And i should mention, this is not a mobile website, it's a desktop site.
  - TazeTSchnitzel 14y ago
    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-friendly/ http://paulirish.com/2012/vendor-prefixes-are-not-developer-... [2] http://www.quirksmode.org/blog/archives/2010/03/css_vendor_pref_1.html http://www.quirksmode.org/blog/archives/2010/03/css_vendor_p...
  - ars 14y ago
    Missed one: background: -webkit-gradient(linear, 0 0, 0 100%, from(#fff) color-stop(75%, #fdd) to(#fcc)); (I hope I got that syntax right.) This one should go above webkit-linear-gradient. 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.
    - cleverjake 14y ago
      >>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.
      - ars 14y ago
        Don't know what "CR" is (community recommendation?), but obviously I mean once the spec is finalized, not just when the spec is proposed.
        robin_reala 14y ago
        Candidate Recommendation; the state of a W3 recommendation where they call for vendor implementations.
        14y ago
- SCdF 14y ago
  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.
  - TazeTSchnitzel 14y ago
    Hmm, good point. In general I rarely use special prefixed CSS features, and the ones that I do are rarely worth the effort.
tomjen3 14y ago
The problem with all those prefixes is the w3c. They are stuck in the web of the 90.
gioele 14y ago
I hope I will not see many more of this kind of news. 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.
- mbrubeck 14y ago
  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/ http://hsivonen.iki.fi/vendor-prefixes/ (see "Keep Experimental Features in Experimental Builds") [2] https://groups.google.com/d/msg/mozilla.dev.platform/itl6mtx2dxI/mbdPvbexB2EJ 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.)
- kstrauser 14y ago
  From the first bug linked from the article (at https://bugzilla.mozilla.org/show_bug.cgi?id=762302 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.
  - gioele 14y ago
    > 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.
cpeterso 14y ago
Firefox 16 will hit the mozilla-release channel on October 9: https://wiki.mozilla.org/RapidRelease/Calendar https://wiki.mozilla.org/RapidRelease/Calendar
wdc2012 14y ago
In other words: same as IE10. http://blogs.msdn.com/b/ie/archive/2012/06/06/moving-the-stable-web-forward-in-ie10-release-preview.aspx http://blogs.msdn.com/b/ie/archive/2012/06/06/moving-the-sta...

71 points by cleverjake 14y ago

kaizenfury7 14y ago

None of the bug links are working for me.

paulrouget 14y ago
Should work now.

bugschivers 14y ago

-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 https://developer.mozilla.org/en/Firefox_13_for_developers that mentions it. Just thought I'd mention this in case anyone was affected.

TazeTSchnitzel 14y ago

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.

Achshar 14y ago
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. 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); And this is used every time i have to set a gradient. I really wish there were some better options than prefixes. I am not surprised at all if developers move to supporting just webkit. This is a lot of work and maintaining. And without css variables, it is a mess to change a color. It is very tempting to just use the -webkit- version and probably a non prefixed one for future compatibility. 2 is far better than 5. Edit: And i should mention, this is not a mobile website, it's a desktop site.
- TazeTSchnitzel 14y ago
  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-friendly/ http://paulirish.com/2012/vendor-prefixes-are-not-developer-... [2] http://www.quirksmode.org/blog/archives/2010/03/css_vendor_pref_1.html http://www.quirksmode.org/blog/archives/2010/03/css_vendor_p...
- ars 14y ago
  Missed one: background: -webkit-gradient(linear, 0 0, 0 100%, from(#fff) color-stop(75%, #fdd) to(#fcc)); (I hope I got that syntax right.) This one should go above webkit-linear-gradient. 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.
  - cleverjake 14y ago
    >>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.
    - ars 14y ago
      Don't know what "CR" is (community recommendation?), but obviously I mean once the spec is finalized, not just when the spec is proposed.
      - robin_reala 14y ago
        Candidate Recommendation; the state of a W3 recommendation where they call for vendor implementations.
      - 14y ago
SCdF 14y ago
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.
- TazeTSchnitzel 14y ago
  Hmm, good point. In general I rarely use special prefixed CSS features, and the ones that I do are rarely worth the effort.

tomjen3 14y ago

The problem with all those prefixes is the w3c. They are stuck in the web of the 90.

gioele 14y ago

I hope I will not see many more of this kind of news. 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.

mbrubeck 14y ago
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/ http://hsivonen.iki.fi/vendor-prefixes/ (see "Keep Experimental Features in Experimental Builds") [2] https://groups.google.com/d/msg/mozilla.dev.platform/itl6mtx2dxI/mbdPvbexB2EJ 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.)
kstrauser 14y ago
From the first bug linked from the article (at https://bugzilla.mozilla.org/show_bug.cgi?id=762302 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.
- gioele 14y ago
  > 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.

cpeterso 14y ago

Firefox 16 will hit the mozilla-release channel on October 9: https://wiki.mozilla.org/RapidRelease/Calendar https://wiki.mozilla.org/RapidRelease/Calendar

wdc2012 14y ago

In other words: same as IE10. http://blogs.msdn.com/b/ie/archive/2012/06/06/moving-the-stable-web-forward-in-ie10-release-preview.aspx http://blogs.msdn.com/b/ie/archive/2012/06/06/moving-the-sta...