12 ms·

Firefox 46 supports some -webkit prefixed CSS properties

71 points by simon04 10y ago

elktea 10y ago
Disappointing, but you can see the corner they're wedged into here. Maintain purity or lose users due to sites not working "because of Firefox".
- kibwen 10y ago
  This is far from unprecedented, the genesis of Firefox basically involved implementing a ton of IE's behavior for compatibility with the web as it existed.
nerdy 10y ago
Very interesting considering WebKit is moving away from prefixes: https://webkit.org/blog/6131/updating-our-prefixing-policy/ https://webkit.org/blog/6131/updating-our-prefixing-policy/
- TazeTSchnitzel 10y ago
  It's the kind of mess that got Firefox to have to implement other browsers' prefixes that led to Blink, Gecko and WebKit ceasing to use them for new features. Unfortunately, that doesn't clean up the existing problems, but it should prevent creating more.
- ddebernardy 10y ago
  And one of the reasons mentioned in there, incidentally, is browser vendors feeling compelled to become compatible with each other's prefixes.
  - nerdy 10y ago
    It seems they agree the existing state of affairs isn't acceptable, but don't agree about how to proceed. Consider Mozilla's perspective... they're trying to refocus on Firefox[1] and immediately after they find a suitable place for Thunderbird[2] they release support for WebKit prefixes while Apple announces dropping the same prefixes. Not only does this mean Mozilla arguably wasted time, it also means they'll have this prefix code as an artifact for some time while it becomes increasingly irrelevant. At the same time, it makes Firefox seem antiquated while the floor falls out from under its user base[3]. 1. http://news.softpedia.com/news/mozilla-wants-to-ditch-thunderbird-email-client-to-focus-more-on-firefox-496980.shtml http://news.softpedia.com/news/mozilla-wants-to-ditch-thunde... 2. http://news.softpedia.com/news/two-foundations-are-willing-to-take-over-thunderbird-development-503408.shtml http://news.softpedia.com/news/two-foundations-are-willing-t... 3. http://www.w3schools.com/browsers/browsers_stats.asp http://www.w3schools.com/browsers/browsers_stats.asp
    - masklinn 10y ago
      > It seems they agree the existing state of affairs isn't acceptable, but don't agree about how to proceed. They completely agree how to proceed, Firefox and Chrome both moved to using feature flags instead of vendor prefixes a while back, but there are so many -webkit- prefixed "advanced" properties in the wild, and developers only testing their site in Chrome (which hasn't removed the old prefixed properties for compatibility reasons) that Mozilla felt compelled to add support for these. Incidentally, they're following Opera[0] and Microsoft[1] in doing so. > while Apple announces dropping the same prefixes Apple didn't announce dropping support for existing prefixed properties (at best they noted that they may remove some over time depending on compatibility needs), only that new features will be gated instead of prefixed going forwards. > it also means they'll have this prefix code as an artifact for some time while it becomes increasingly irrelevant. Prefixed properties are just specific names, the vendor prefix is incidental, Mozilla implemented and enabled a bunch of properties named -webkit-{something} instead of {something}. [0] http://www.sitepoint.com/opera-css3-webkit-prefix/ http://www.sitepoint.com/opera-css3-webkit-prefix/ [1] https://msdn.microsoft.com/en-us/library/mt270097%28v=vs.85%29.aspx https://msdn.microsoft.com/en-us/library/mt270097%28v=vs.85%...
      - nerdy 10y ago
        As I understand it, WebKit's feature flags will not include the webkit prefix: "WebKit’s new policy is to implement experimental features unprefixed" But Mozilla still plans for experimental features to be prefixed: "Mozilla supports a number of extensions to CSS that are prefixed with -moz-. Some of these properties have been included in draft CSS specification for inclusion in the final recommendation, but are still experimental... Once standardized, and the support for the un-prefixed variant added, the prefixed properties are dropped."
        masklinn 10y ago
        I'm not sure what you're trying to say. The webkit quote indicates that new experimental features will be unprefixed and behind flags, which is already the policy at Mozilla. For instance as of Firefox 46 (release channel) "grid" is unprefixed (there is no -moz-grid[0]) but behind a flag (layout.css.grid.enabled). > But Mozilla still plans for experimental features to be prefixed: The quote doesn't support your interpretation, it only indicates that there are -moz-prefixed experimental properties, just as there are -webkit-prefixed experimental properties. [0] well there is a display: -moz-grid value for display but it's a historical XUL property unrelated to the CSS Grid Layout module: https://bugzilla.mozilla.org/show_bug.cgi?id=616605#c10 https://bugzilla.mozilla.org/show_bug.cgi?id=616605#c10
- mccr8 10y ago
  From that article: "We expect to significantly reduce the number of prefixed properties supported over time but Web compatibility will require us to keep around prefixed versions of some features." The features WebKit needs to keep around to continue to work with many websites are presumably about the same as those Firefox felt it had to implement to work with many websites. (Disclaimer: I work on Firefox.)
- gcb0 10y ago
  this is bad. remember when Microsoft was the first to ship a browser shipped by default and dictated the standards by releasing it as they saw fit in that monopolistic browser? (for the kids of today, devs from that day loved ie just like you love chrome today. IE invented the developer panel and ajax request, both things you live by today) well, Google (the irony) sued and won. Microsoft had to remove IE from Windows, and browser vendors agreed to not force standards themselves. that is the only reason we have prefixes. it send the message "we think it's cool, but wait for everyone to agree on the best way to implement this". without prefixes, Google, having the browser monopoly (since Android is the new windows) can dictate the direction as it see fits. just like Microsoft when they sued them.
  - miketaylr 10y ago
    ...what. I don't think you understand how prefixes are used in the wild. Vendor prefixes re-inforce monoculture, they don't prevent it.
  - cpeterso 10y ago
    The modern "no prefixes" approach is to hide the new features behind a runtime flag or in a pre-release beta channel. Web developers can test the feature but not use it in production websites until browser vendors standardize it.
  - magicalist 10y ago
    > well, Google (the irony) sued and won. Microsoft had to remove IE from Windows, and browser vendors agreed to not force standards themselves. What on earth are you talking about? This is not a thing that ever happened.
    - gcb0 10y ago
      are you too young to remember the browser wars and how Google sued ms for giving internet explorer for free with msn as the honepage?
lucideer 10y ago
This specification, created by Mozilla, is also relevant: https://compat.spec.whatwg.org/ https://compat.spec.whatwg.org/
akerro 10y ago
> Firefox 46 supports some -webkit prefixed CSS properties >When implementing new features for the Web, it’s important for us to be able to get them into the hands of developers early, so they can give new things a try > WebKit is moving away from prefixes (webkit.org) Well done Mozilla.
- masklinn 10y ago
  Mozilla is adding support for existing wide-spread -webkit-prefixed properties for compatibility reasons[0][1]. Existing properties which Webkit isn't dropping, they're dropping prefixes for new experimental features, a move Firefox (and Chrome) made more than 3 years ago. Which you'd have know had you read the first comment of the sister story instead of going no further than the story title. [0] https://compat.spec.whatwg.org/#introduction https://compat.spec.whatwg.org/#introduction [1] following the lead of Opera and Microsoft in doing so
untog 10y ago
I don't blame them. I remember reading how IE on Windows 10 sends a Safari user agent because so many sites use user agent sniffing rather than capability detection for things like touch events. So, all disappointing, but we (as an industry) have no-one but ourselves to blame for it. Firefox and MS are just putting the user first.
- sanqui 10y ago
  And, of course, Safari sends a Mozilla user-agent...
  - gcb0 10y ago
    and everyone send in a gecko string...
alex_duf 10y ago
This is making me sad...
josteink 10y ago
And I still see web developers who reject the idea that we have troublesome webkit monoculture. And when you ask them what non-webkit browsers they are testing on, they're response while not literally "What do you mean testing?", effectively conveys the same: "Just use latest Chrome (Works on my machine)". When Microsoft created its initial version of ASP.Net, it was mainly designed to allow Windows VB6 point-and-click programmers to create web applications without understanding how the web worked. It was a joke of a web-framework. The irony is that right now, I can tell the current crop of "ninja" web-developers (who rightfully rejected ASP.Net and its ilk) are starting more and more to look like this generation's VB6 programmers: Unambitious. Untalented. Unprincipled. Web-standards? Whatever works, and this works on my machine. It's quite frightening. I thought we were past this shit.
- kibibu 10y ago
  > It was a joke of a web-framework. Hey, at least it wasn't ASP classic
  - romanovcode 10y ago
    I'm pretty sure he meant ASP Classic. In any case ASP.NET a.k.a. ASP.NET Core is one of the best looking frameworks right now.
    - nwah1 10y ago
      Yep, it is open source, cross-platform, with a fantastic MVC framework and an elegant language (C#). Visual Studio is of course proprietary and windows-only, but it isn't necessary to use. Although you'd be a fool not to use it.
      - skrowl 10y ago
        ASP.NET Core 1 (formerly ASP.NET 5.0) development works great in Visual Studio Code https://code.visualstudio.com/ https://code.visualstudio.com/, which is FOSS (MIT license) https://github.com/Microsoft/vscode/ https://github.com/Microsoft/vscode/ and works on Linux and OS X as well as Windows. A lot of people don't realize that Visual Studio Code is, in fact, it's own product and not a version of full Visual Studio.
skrowl 10y ago
FWIW, Firefox Dev Ed / Aurora has had this for a while and has been on 47 since 08 March. https://www.mozilla.org/en-US/firefox/47.0a2/releasenotes/ https://www.mozilla.org/en-US/firefox/47.0a2/releasenotes/
miketaylr 10y ago
FWIW, these aren't actually enabled in 46 unless you flip the `layout.css.prefixes.webkit` pref to true. (We hope to flip that to true by default soon: https://bugzilla.mozilla.org/show_bug.cgi?id=1259345 https://bugzilla.mozilla.org/show_bug.cgi?id=1259345)
gcb0 10y ago
Google is moving as aggressively as Microsoft was with IE, and Mozilla bent over, again. for the kids that don't remember, go read about why all the worst parts of JavaScript are the way they are...
- gsnedders 10y ago
  The problems with a WebKit monoculture on mobile are as much Apple's fault as they are Google's. Neither did anything to stop it until far too late.
kevinSuttle 10y ago
This is why we can't have nice things. https://webkit.org/blog/6131/updating-our-prefixing-policy/ https://webkit.org/blog/6131/updating-our-prefixing-policy/
newyorkers 10y ago
New changes welcome.

71 points by simon04 10y ago

Disappointing, but you can see the corner they're wedged into here. Maintain purity or lose users due to sites not working "because of Firefox".

kibwen 10y ago
This is far from unprecedented, the genesis of Firefox basically involved implementing a ton of IE's behavior for compatibility with the web as it existed.

nerdy 10y ago

Very interesting considering WebKit is moving away from prefixes: https://webkit.org/blog/6131/updating-our-prefixing-policy/ https://webkit.org/blog/6131/updating-our-prefixing-policy/

TazeTSchnitzel 10y ago
It's the kind of mess that got Firefox to have to implement other browsers' prefixes that led to Blink, Gecko and WebKit ceasing to use them for new features. Unfortunately, that doesn't clean up the existing problems, but it should prevent creating more.
ddebernardy 10y ago
And one of the reasons mentioned in there, incidentally, is browser vendors feeling compelled to become compatible with each other's prefixes.
- nerdy 10y ago
  It seems they agree the existing state of affairs isn't acceptable, but don't agree about how to proceed. Consider Mozilla's perspective... they're trying to refocus on Firefox[1] and immediately after they find a suitable place for Thunderbird[2] they release support for WebKit prefixes while Apple announces dropping the same prefixes. Not only does this mean Mozilla arguably wasted time, it also means they'll have this prefix code as an artifact for some time while it becomes increasingly irrelevant. At the same time, it makes Firefox seem antiquated while the floor falls out from under its user base[3]. 1. http://news.softpedia.com/news/mozilla-wants-to-ditch-thunderbird-email-client-to-focus-more-on-firefox-496980.shtml http://news.softpedia.com/news/mozilla-wants-to-ditch-thunde... 2. http://news.softpedia.com/news/two-foundations-are-willing-to-take-over-thunderbird-development-503408.shtml http://news.softpedia.com/news/two-foundations-are-willing-t... 3. http://www.w3schools.com/browsers/browsers_stats.asp http://www.w3schools.com/browsers/browsers_stats.asp
  - masklinn 10y ago
    > It seems they agree the existing state of affairs isn't acceptable, but don't agree about how to proceed. They completely agree how to proceed, Firefox and Chrome both moved to using feature flags instead of vendor prefixes a while back, but there are so many -webkit- prefixed "advanced" properties in the wild, and developers only testing their site in Chrome (which hasn't removed the old prefixed properties for compatibility reasons) that Mozilla felt compelled to add support for these. Incidentally, they're following Opera[0] and Microsoft[1] in doing so. > while Apple announces dropping the same prefixes Apple didn't announce dropping support for existing prefixed properties (at best they noted that they may remove some over time depending on compatibility needs), only that new features will be gated instead of prefixed going forwards. > it also means they'll have this prefix code as an artifact for some time while it becomes increasingly irrelevant. Prefixed properties are just specific names, the vendor prefix is incidental, Mozilla implemented and enabled a bunch of properties named -webkit-{something} instead of {something}. [0] http://www.sitepoint.com/opera-css3-webkit-prefix/ http://www.sitepoint.com/opera-css3-webkit-prefix/ [1] https://msdn.microsoft.com/en-us/library/mt270097%28v=vs.85%29.aspx https://msdn.microsoft.com/en-us/library/mt270097%28v=vs.85%...
    - nerdy 10y ago
      As I understand it, WebKit's feature flags will not include the webkit prefix: "WebKit’s new policy is to implement experimental features unprefixed" But Mozilla still plans for experimental features to be prefixed: "Mozilla supports a number of extensions to CSS that are prefixed with -moz-. Some of these properties have been included in draft CSS specification for inclusion in the final recommendation, but are still experimental... Once standardized, and the support for the un-prefixed variant added, the prefixed properties are dropped."
      - masklinn 10y ago
        I'm not sure what you're trying to say. The webkit quote indicates that new experimental features will be unprefixed and behind flags, which is already the policy at Mozilla. For instance as of Firefox 46 (release channel) "grid" is unprefixed (there is no -moz-grid[0]) but behind a flag (layout.css.grid.enabled). > But Mozilla still plans for experimental features to be prefixed: The quote doesn't support your interpretation, it only indicates that there are -moz-prefixed experimental properties, just as there are -webkit-prefixed experimental properties. [0] well there is a display: -moz-grid value for display but it's a historical XUL property unrelated to the CSS Grid Layout module: https://bugzilla.mozilla.org/show_bug.cgi?id=616605#c10 https://bugzilla.mozilla.org/show_bug.cgi?id=616605#c10
mccr8 10y ago
From that article: "We expect to significantly reduce the number of prefixed properties supported over time but Web compatibility will require us to keep around prefixed versions of some features." The features WebKit needs to keep around to continue to work with many websites are presumably about the same as those Firefox felt it had to implement to work with many websites. (Disclaimer: I work on Firefox.)
gcb0 10y ago
this is bad. remember when Microsoft was the first to ship a browser shipped by default and dictated the standards by releasing it as they saw fit in that monopolistic browser? (for the kids of today, devs from that day loved ie just like you love chrome today. IE invented the developer panel and ajax request, both things you live by today) well, Google (the irony) sued and won. Microsoft had to remove IE from Windows, and browser vendors agreed to not force standards themselves. that is the only reason we have prefixes. it send the message "we think it's cool, but wait for everyone to agree on the best way to implement this". without prefixes, Google, having the browser monopoly (since Android is the new windows) can dictate the direction as it see fits. just like Microsoft when they sued them.
- miketaylr 10y ago
  ...what. I don't think you understand how prefixes are used in the wild. Vendor prefixes re-inforce monoculture, they don't prevent it.
- cpeterso 10y ago
  The modern "no prefixes" approach is to hide the new features behind a runtime flag or in a pre-release beta channel. Web developers can test the feature but not use it in production websites until browser vendors standardize it.
- magicalist 10y ago
  > well, Google (the irony) sued and won. Microsoft had to remove IE from Windows, and browser vendors agreed to not force standards themselves. What on earth are you talking about? This is not a thing that ever happened.
  - gcb0 10y ago
    are you too young to remember the browser wars and how Google sued ms for giving internet explorer for free with msn as the honepage?

lucideer 10y ago

This specification, created by Mozilla, is also relevant: https://compat.spec.whatwg.org/ https://compat.spec.whatwg.org/

akerro 10y ago

> Firefox 46 supports some -webkit prefixed CSS properties >When implementing new features for the Web, it’s important for us to be able to get them into the hands of developers early, so they can give new things a try > WebKit is moving away from prefixes (webkit.org) Well done Mozilla.

masklinn 10y ago
Mozilla is adding support for existing wide-spread -webkit-prefixed properties for compatibility reasons[0][1]. Existing properties which Webkit isn't dropping, they're dropping prefixes for new experimental features, a move Firefox (and Chrome) made more than 3 years ago. Which you'd have know had you read the first comment of the sister story instead of going no further than the story title. [0] https://compat.spec.whatwg.org/#introduction https://compat.spec.whatwg.org/#introduction [1] following the lead of Opera and Microsoft in doing so

untog 10y ago

I don't blame them. I remember reading how IE on Windows 10 sends a Safari user agent because so many sites use user agent sniffing rather than capability detection for things like touch events. So, all disappointing, but we (as an industry) have no-one but ourselves to blame for it. Firefox and MS are just putting the user first.

sanqui 10y ago
And, of course, Safari sends a Mozilla user-agent...
- gcb0 10y ago
  and everyone send in a gecko string...

alex_duf 10y ago

This is making me sad...

josteink 10y ago

And I still see web developers who reject the idea that we have troublesome webkit monoculture. And when you ask them what non-webkit browsers they are testing on, they're response while not literally "What do you mean testing?", effectively conveys the same: "Just use latest Chrome (Works on my machine)". When Microsoft created its initial version of ASP.Net, it was mainly designed to allow Windows VB6 point-and-click programmers to create web applications without understanding how the web worked. It was a joke of a web-framework. The irony is that right now, I can tell the current crop of "ninja" web-developers (who rightfully rejected ASP.Net and its ilk) are starting more and more to look like this generation's VB6 programmers: Unambitious. Untalented. Unprincipled. Web-standards? Whatever works, and this works on my machine. It's quite frightening. I thought we were past this shit.

kibibu 10y ago
> It was a joke of a web-framework. Hey, at least it wasn't ASP classic
- romanovcode 10y ago
  I'm pretty sure he meant ASP Classic. In any case ASP.NET a.k.a. ASP.NET Core is one of the best looking frameworks right now.
  - nwah1 10y ago
    Yep, it is open source, cross-platform, with a fantastic MVC framework and an elegant language (C#). Visual Studio is of course proprietary and windows-only, but it isn't necessary to use. Although you'd be a fool not to use it.
    - skrowl 10y ago
      ASP.NET Core 1 (formerly ASP.NET 5.0) development works great in Visual Studio Code https://code.visualstudio.com/ https://code.visualstudio.com/, which is FOSS (MIT license) https://github.com/Microsoft/vscode/ https://github.com/Microsoft/vscode/ and works on Linux and OS X as well as Windows. A lot of people don't realize that Visual Studio Code is, in fact, it's own product and not a version of full Visual Studio.

skrowl 10y ago

FWIW, Firefox Dev Ed / Aurora has had this for a while and has been on 47 since 08 March. https://www.mozilla.org/en-US/firefox/47.0a2/releasenotes/ https://www.mozilla.org/en-US/firefox/47.0a2/releasenotes/

miketaylr 10y ago

FWIW, these aren't actually enabled in 46 unless you flip the `layout.css.prefixes.webkit` pref to true. (We hope to flip that to true by default soon: https://bugzilla.mozilla.org/show_bug.cgi?id=1259345 https://bugzilla.mozilla.org/show_bug.cgi?id=1259345)

gcb0 10y ago

Google is moving as aggressively as Microsoft was with IE, and Mozilla bent over, again. for the kids that don't remember, go read about why all the worst parts of JavaScript are the way they are...

gsnedders 10y ago
The problems with a WebKit monoculture on mobile are as much Apple's fault as they are Google's. Neither did anything to stop it until far too late.

kevinSuttle 10y ago

This is why we can't have nice things. https://webkit.org/blog/6131/updating-our-prefixing-policy/ https://webkit.org/blog/6131/updating-our-prefixing-policy/

newyorkers 10y ago

New changes welcome.