
Mass-unprefixing in Firefox 16 - cleverjake
http://paulrouget.com/e/unprefixing-in-firefox-16/
======
gioele
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.

~~~
kstrauser
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.

~~~
gioele
> 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.

------
TazeTSchnitzel
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
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.

~~~
ars
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
>>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
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
Candidate Recommendation; the state of a W3 recommendation where they call for
vendor implementations.

------
bugschivers
-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.

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

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

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

------
kaizenfury7
None of the bug links are working for me.

~~~
paulrouget
Should work now.

