10 ms·

Firefox 49 fixes sites designed with WebKit in mind, and more

156 points by dwaxe 10y ago

Ezhik 10y ago
I'm worried about Chrome's dominance, honestly. Google can basically dictate things the same way Microsoft did in the past. We are obviously not in quite the same situation - open source and all, but there have ready been several cases where Google just decided to do things, and other players in the field had no choice but to follow.
- prohor 10y ago
  Yes like this one - just dropping part of current SVG standard that was supported by all browsers. Without any notification and replacement it broke some sites. Why? Because it was too much code, low adoption and it is depreciated in SVG 2.0 draft. https://bugs.chromium.org/p/chromium/issues/detail?id=539385 https://bugs.chromium.org/p/chromium/issues/detail?id=539385
  - tangue 10y ago
    Css regions was included in Canary and ousted because it was too much code too (and because basically the Chrome Team didn't like the spec.) And I'm not talking about the half baked html5 widgets like datepicker ...
  - TazeTSchnitzel 10y ago
    The comments in that thread are really saddening. I feel sorry for those developers that have suddenly had their applications broken for them on a whim by the Chromium team. I write JS code and deliver it to clients. What will I tell them when their website widgets break because Chrome removed SVG support entirely?
    - a3n 10y ago
      Give them a thumbnail explanation of what Chrome did, and suggest a more inclusive browser.
      - TazeTSchnitzel 10y ago
        But they don't decide what browser their customers use.
        a3n 10y ago
        Then suggest that they detect browsers, and put up a little non-distracting version of your thumbnail explanation to their customers. :) If this is truly distracting or breaking to your clients' customers, then someone is going to have to do or say something.
        Ezhik 10y ago
        The terrible truth is that consumers don't give a shit about standards, freedom, and the greater good. They just want the website to work with the least amount of effort possible.
        pawadu 10y ago
        Lets turn this around: The terrible truth is that some web devs don't give a shit about web standards. They just want the site to look good on their iMac with Safari. So now we have huge webkit emulation layers in all major browser...
        Ygg2 10y ago
        Or to turn it around: The terrible truth is that Chrome don't give a shit about standards, freedom, and the greater good. They just want to write their code with the least amount of effort possible, standards be damned.
        pawadu 10y ago
        I don't understand your logic here. Are the costumers using Chrome? Then devs should test on Chrome too. Are the costumers NOT using Chrome? Then what is the problem??
    - codedokode 10y ago
      It is bad idea to rely on new features anyway. How will your website work in a 5-year-old browser?
      - themihai 10y ago
        Like on a 5 year old browser. Honestly, unless you develop for government I don't see any reason to consider 5 year old browsers. Do you develop apps for iPhone 1 or Android 1? The web is already behind anyway...
      - TazeTSchnitzel 10y ago
        New features? Chrome was removing an old, standard web feature supported everywhere for years.
  - chickenbane 10y ago
    Actually, Chrome dropping a feature that was removed from a spec, was a lot of code and had low adoption sounds like a good idea. Engineering is always about trade-offs, and choosing a good balance in Chrome is what made it so popular. The parent of this comment was worried about Chrome's "dominance", but remember Chrome was the last browser to the party. Safari's dominance appears to be the reason Firefox added -webkit prefixes. If you really think the SVG feature was important and Chrome should support it, then lobby for it to be part of the standard and for other web developers to use it. But it's not a great example of Chrome pushing its whim on others.
    - fphhotchips 10y ago
      Isn't that the point though? This is part of the standard, and was being used by developers. Not many developers, but then I'm pretty sure that there are parts of lots of standards that are barely used - doesn't mean we just go around taking them out because we feel like it. The best part of Firefox/Netscape/Chrome/Safari/Opera eating IE's lunch was that they all converged (roughly) on standards compliance, so we didn't have to have "Built for IE 6.0" stickers all over everything. Chrome ditching parts of the standard just because they don't like it is the fast track back to there.
    - prohor 10y ago
      Yes, but the problem it is part of current standard, 2.0 is still work in progress. Also alternative API from SVG 2.0 is not yet delivered by Chrome either as far as I know.
      - gsnedders 10y ago
        The Chrome team removed something that there was agreement across all browsers to deprecate, and which was made optional in a near-finished spec. Also, it's perfectly typical for drafts to be what implementers are targeting, as plenty of published specs receive almost no errata and any issues in them only get addressed in new revisions.
- TheCowboy 10y ago
  This is the right general idea to be concerned about. Chrome was, in my opinion, an attempt to undermine Microsoft's dominance. It was also a business strategy, since a browser monopoly by MS could be the death to www.google.com. (I think that there is enough desktop browser competition to keep things in check for now, but it could become a problem.) I think a bigger potential threat is the dominance of Apple and their control over iOS with the requirement that "Apps that browse the web must use the iOS WebKit framework and WebKit Javascript" and other platform restrictions.
  - vbezhenar 10y ago
    What iOS dominance are you talking about? Android has larger market share, last time I checked. Even if that's not true in some regions, it's not dominance at all. If people don't like iOS restrictions, they can use Android, it's very competitive platform. Don't forget that Windows is really the only universal desktop operating system. OS X hard wired to Macs and Linux has really tiny share on desktop market. So those laws about monopolists can be applied to Windows, but with iOS it's a very different situation.
    - oneplane 10y ago
      It doesn't matter how big the OS is if the users don't use the browser. I'm not sure what the numbers are this year, but it's been iOS's browser and iOS's AppStore that has the most activity and/or money.
      - SomeCallMeTim 10y ago
        >iOS's AppStore that has the most activity and/or money. iOS AppStore has higher total sales so far, but the difference isn't that great, and Android is due to pass the AppStore in about 2018 [1]. I've seen a phone vs tablet breakdown that implied Android phone app sales actually surpassed iOS a few years ago, but I can't find it now. The huge difference was in iPad app sales which were much higher than Android, and it would be easy to believe that the difference in overall app revenues per store was made up by the difference in tablet revenues. [1] http://www.androidauthority.com/play-store-revenue-growth-2018-406474/ http://www.androidauthority.com/play-store-revenue-growth-20...
- skrowl 10y ago
  This exactly. Too many people make Chrome sites and Chrome apps instead of WEB apps.
- btgeekboy 10y ago
  Open source only matters to an extent. If Google's the primary source of committers, they can reject patches. And if a patch is rejected, sure you can fork, but your new browser will have 0 marketshare.
Bino 10y ago
Hmm, I really feel Apple is to blame for this mess, just my gut feeling.
- kitsunesoba 10y ago
  Mozilla is at least partially responsible as well. WebKit only became as dominant as it did because it was readily and easily embeddable, highly portable, and nearly language and toolkit agnostic. Gecko easily could've become a major player as well, but instead of looking ahead and making Gecko more appealing to developers and OEMs, they dropped support for embedded Gecko entirely and doubled down on Gecko and Firefox for all practical purposes being one in the same and forcing anyone interested in using Gecko to wrestle around with XULRunner. So today WebKit is everywhere (even where Chrome/Blink isn't) and is the bar all others are measured by. Had Mozilla been more amicable to projects like Camino and K-Meleon things might be different now.
  - pcwalton 10y ago
    KHTML was hardly embeddable, portable, or language/toolkit agnostic at the time.
    - lmm 10y ago
      It was absolutely embeddadble - the KPart was a first-class supported way of using it (widely used in other KDE applications) - and at least somewhat portable (KDE on windows predates WebKit).
      - gcp 10y ago
        But didn't KPart rely on KDE (libs)? That's hardly embeddable in any meaningful sense. Gecko was embeddable too if everything you wrote was XUL :-)
        lmm 10y ago
        Kdeui was (and remains) a first-class toolkit for writing arbitrary applications (and widely used as such) in a way that XUL has never really been.
EdSharkey 10y ago
Stick it to 'em, Mozilla! Don't let perfect be the enemy of the good.
liquidise 10y ago
In response to the complaints about "this is Big Internet Corps. fault", i think that is hasty. I code systems for all major modern browsers (including IE and Edge) and Cordova. I can count on exactly 0 fingers the number of times i have used a '-browser' prefix in the last year. The fact of the matter is that standards are moving fast and better still is the rate at which browsers are implementing those standards is very powerful. The use of css prefixes is, in my opinion, lazy. Many of popular directives are now implemented by browsers in the generic form anyways. The ones that are not can almost always be achieved through another styling method.
- kccqzy 10y ago
  I use flexbox (with autoprefixer) extensively and I think achieving similar designs without flexbox is a waste of programmer productivity. Yes I am lazy but I think it's productive.
  - masklinn 10y ago
    Flexbox is available unprefixed in all current browser versions.
- eyelidlessness 10y ago
  There's nothing lazy about supporting older browser versions.
  - roblabla 10y ago
    Yes, but instead of writing them by hand, you should just use the unprefixed version, and use autoprefixer to support older browsers. This also ensures you don't forget anyone.
sigvef 10y ago
Thanks Mozilla! Lots of great work being done, and it can be easy to take it for granted at times. This release makes me particularly happy because if fixes a WebRTC/MediaStream bug that I've been wrestling with on my current project ( https://www.zombocam.com https://www.zombocam.com ) for a few weeks. So thank you Firefox team!
- alexbecker 10y ago
  Is this named for http://www.zombo.com/ http://www.zombo.com/ by any chance?
  - sigvef 10y ago
    Anything is possible with Zombocam :P
chaosfox 10y ago
hah thats funny, back in the day Opera also supported webkit prefixes[1], today it uses the blink engine. 1. http://www.opera.com/docs/specs/presto2.12/css/aliases/ http://www.opera.com/docs/specs/presto2.12/css/aliases/
- tr4656 10y ago
  Blink is a fork of webkit so it supports webkit prefixes anyways.
  - thunderbong 10y ago
    He's talking about Opera 12 and before which was built on the Presto engine, not the Webkit engine
    - codedokode 10y ago
      The case with Opera is interesting. The web standards became so complicated that Opera was unable to maintain their alternative engine and implement all of new features. Microsoft might have to switch to webkit in the future too.
deleted 10y ago
[deleted]
consto 10y ago
These sites have all broken because of the way browsers handle new css properties, and by that I mean the -browser prefix. Web developers see this new shiny feature that either makes the page prettier, or easier to create, of course they'll use them. If browser developers really wanted web developers not to use these properties they would have to be enabled, manually, per browser. That would allow people to create implementations and test them, but stop prefixes getting onto the general web. Instead we are left with many browsers (i.e. not chrome) being forced to implement each others prefixes, and to a lesser extend JS libraries.
- TazeTSchnitzel 10y ago
  > If browser developers really wanted web developers not to use these properties they would have to be enabled, manually, per browser. That is precisely the approach being taken these days. Prefixes are legacy.
- flukus 10y ago
  I'm just as happy not using them, but try convincing clients/bosses to live without rounded corners.
Scarbutt 10y ago
One of the reasons I moved back to chrome from firefox was that it got annoying of dealing with websites that didn't work well in firefox, so this is a good UX improvement IMO. But now it means firefox has to chase chrome's tail all the time?
- dblohm7 10y ago
  It shouldn't: experimental web features are now hidden behind browser preferences instead of prefixes that anybody can (ab)use.
hobarrera 10y ago
For years now it's been obvious that Chrome is the new IE. This merely makes it even more obvious.
- bitmapbrother 10y ago
  No, IE shit the bed with its pathetic compliance with web standards. If anything, Edge is the new IE. Chrome is one of the most web standard compliant browsers out there and as long as it stays that way I'm okay with its dominance.
  - ameliaquining 10y ago
    In my experience, the new IE is Safari.
    - hobarrera 10y ago
      Safari has barely any market share, so definitely no.
      - ameliaquining 10y ago
        On mobile, it has plenty. And I mostly meant in terms of speed to adopt new web standards and features.
  - gcp 10y ago
    Chrome is one of the most web standard compliant browsers out there It helps if you're the one making the standards. Much of the current web standardization effort is just documenting what Chrome does and what particular bugs Blink has.
    - masklinn 10y ago
      > Much of the current web standardization effort is just documenting what Chrome does and what particular bugs Blink has. Which is exactly what "the current web standardisation" was with respect to MSIE back in the days of the Second War.
frik 10y ago
That was the tipping point of Opera and IE/Edge too. Opera 12 had various methods to emulate other browsers behaviours and compatibility domain-lists, in the end Opera 12 died and the next version, Opera 15, was just a fork of Chromium. IE/Edge feels pretty broken in modern web similar to Opera 12 back then. The question is were is webkit/Safari is this game. Most website have stylesheets that mention webkit prefixes, and it's now clear why Google removed the prefixes from their webkit fork (blink). It's bad for the end user and the web devs, but good for them.
6mirrors 10y ago
From the perspective of web developers, this is a bad decision as it encourages the direct use of non-standard features and thus leaves even more space for compatibility issues. Here is why: If firefox doesn't support -webkit prefix, the developers are forced to consider the compatibility issues and use something like "autoprefixer" to help. All of the experimental features will work as well as they could on different browsers (IE, Chrome, Firefox...) But if firefox support -webkit prefix and the developers buy it, they will write something like '-webkit-feature' directly and assume it will work on the major browsers. The problem is, major browsers only includes webkit based browsers, what about IE ? If a developer uses a non-standard feature directly, forcing he/she to consider the potential problems is better than leaving him/her a fragile solution.
- djsumdog 10y ago
  I have to agree totally. This change is asinine. They're basically inserting a regression away from standards just so content will look slightly better in their bowser (To gain browser share?)
  - EdSharkey 10y ago
    I think Firefox will continue to support non-prefixed equivalents as well. Also, it seems like there are some useful -webkit- prefixed CSS properties that haven't yet been standardized with an unprefixed name. I think this is a good thing, they're adding new features that will (hopefully) get standardized someday. Let's heap some scorn on those websites and internal corporate teams that do all their work on Chrome and Safari and never test on other browsers. It's always laziness (not testing their crap at all) or lame excuses (Chrome is faster, why would I bother?) that's to blame. I don't mind being the "Firefox guy" on teams I'm part of and making sure my baby always gets some love.
  - masklinn 10y ago
    There's no regression from standard, they're not removing standard support.
  - otabdeveloper1 10y ago
minitech 10y ago
Firefox 49 supports background-clip: text, but thanks to these changes, the safest pattern to use to get it working in Firefox is still the -webkit one! color: #0dd; background-image: -webkit-linear-gradient(to right, #0cf, #0fc); -webkit-background-clip: text; -webkit-text-fill-color: transparent; https://jsfiddle.net/8kyzg826/ https://jsfiddle.net/8kyzg826/
teekert 10y ago
So, will I now see that very very nice mobile ui for outlook on FF mobile as well as on Chrome on android? Edit: Yes!! Finally!! Now, if only it would handle favicons the way chrome does it (many sites have a nice favicon for on the Android Launcher desktop in chrome, while in FF they get a low res white on orange star icon. Very ugly... On second inspection, seems like Chrome makes nice icon out of the first letter of the main domain and matches the main color to the one used on the site as a default, while FF has that star.) Also, it lacks drag-to-refresh as it does in Chrome. But I can tap the address bar and "enter" of course.
- nachtigall 10y ago
  > Also, it lacks drag-to-refresh as it does in Chrome. But I can tap the address bar and "enter" of course. You can also "Menu" > "Reload".

156 points by dwaxe 10y ago

Ezhik 10y ago

I'm worried about Chrome's dominance, honestly. Google can basically dictate things the same way Microsoft did in the past. We are obviously not in quite the same situation - open source and all, but there have ready been several cases where Google just decided to do things, and other players in the field had no choice but to follow.

prohor 10y ago
Yes like this one - just dropping part of current SVG standard that was supported by all browsers. Without any notification and replacement it broke some sites. Why? Because it was too much code, low adoption and it is depreciated in SVG 2.0 draft. https://bugs.chromium.org/p/chromium/issues/detail?id=539385 https://bugs.chromium.org/p/chromium/issues/detail?id=539385
- tangue 10y ago
  Css regions was included in Canary and ousted because it was too much code too (and because basically the Chrome Team didn't like the spec.) And I'm not talking about the half baked html5 widgets like datepicker ...
- TazeTSchnitzel 10y ago
  The comments in that thread are really saddening. I feel sorry for those developers that have suddenly had their applications broken for them on a whim by the Chromium team. I write JS code and deliver it to clients. What will I tell them when their website widgets break because Chrome removed SVG support entirely?
  - a3n 10y ago
    Give them a thumbnail explanation of what Chrome did, and suggest a more inclusive browser.
    - TazeTSchnitzel 10y ago
      But they don't decide what browser their customers use.
      - a3n 10y ago
        Then suggest that they detect browsers, and put up a little non-distracting version of your thumbnail explanation to their customers. :) If this is truly distracting or breaking to your clients' customers, then someone is going to have to do or say something.
        Ezhik 10y ago
        The terrible truth is that consumers don't give a shit about standards, freedom, and the greater good. They just want the website to work with the least amount of effort possible.
        pawadu 10y ago
        Lets turn this around: The terrible truth is that some web devs don't give a shit about web standards. They just want the site to look good on their iMac with Safari. So now we have huge webkit emulation layers in all major browser...
        Ygg2 10y ago
        Or to turn it around: The terrible truth is that Chrome don't give a shit about standards, freedom, and the greater good. They just want to write their code with the least amount of effort possible, standards be damned.
      - pawadu 10y ago
        I don't understand your logic here. Are the costumers using Chrome? Then devs should test on Chrome too. Are the costumers NOT using Chrome? Then what is the problem??
  - codedokode 10y ago
    It is bad idea to rely on new features anyway. How will your website work in a 5-year-old browser?
    - themihai 10y ago
      Like on a 5 year old browser. Honestly, unless you develop for government I don't see any reason to consider 5 year old browsers. Do you develop apps for iPhone 1 or Android 1? The web is already behind anyway...
    - TazeTSchnitzel 10y ago
      New features? Chrome was removing an old, standard web feature supported everywhere for years.
- chickenbane 10y ago
  Actually, Chrome dropping a feature that was removed from a spec, was a lot of code and had low adoption sounds like a good idea. Engineering is always about trade-offs, and choosing a good balance in Chrome is what made it so popular. The parent of this comment was worried about Chrome's "dominance", but remember Chrome was the last browser to the party. Safari's dominance appears to be the reason Firefox added -webkit prefixes. If you really think the SVG feature was important and Chrome should support it, then lobby for it to be part of the standard and for other web developers to use it. But it's not a great example of Chrome pushing its whim on others.
  - fphhotchips 10y ago
    Isn't that the point though? This is part of the standard, and was being used by developers. Not many developers, but then I'm pretty sure that there are parts of lots of standards that are barely used - doesn't mean we just go around taking them out because we feel like it. The best part of Firefox/Netscape/Chrome/Safari/Opera eating IE's lunch was that they all converged (roughly) on standards compliance, so we didn't have to have "Built for IE 6.0" stickers all over everything. Chrome ditching parts of the standard just because they don't like it is the fast track back to there.
  - prohor 10y ago
    Yes, but the problem it is part of current standard, 2.0 is still work in progress. Also alternative API from SVG 2.0 is not yet delivered by Chrome either as far as I know.
    - gsnedders 10y ago
      The Chrome team removed something that there was agreement across all browsers to deprecate, and which was made optional in a near-finished spec. Also, it's perfectly typical for drafts to be what implementers are targeting, as plenty of published specs receive almost no errata and any issues in them only get addressed in new revisions.
TheCowboy 10y ago
This is the right general idea to be concerned about. Chrome was, in my opinion, an attempt to undermine Microsoft's dominance. It was also a business strategy, since a browser monopoly by MS could be the death to www.google.com. (I think that there is enough desktop browser competition to keep things in check for now, but it could become a problem.) I think a bigger potential threat is the dominance of Apple and their control over iOS with the requirement that "Apps that browse the web must use the iOS WebKit framework and WebKit Javascript" and other platform restrictions.
- vbezhenar 10y ago
  What iOS dominance are you talking about? Android has larger market share, last time I checked. Even if that's not true in some regions, it's not dominance at all. If people don't like iOS restrictions, they can use Android, it's very competitive platform. Don't forget that Windows is really the only universal desktop operating system. OS X hard wired to Macs and Linux has really tiny share on desktop market. So those laws about monopolists can be applied to Windows, but with iOS it's a very different situation.
  - oneplane 10y ago
    It doesn't matter how big the OS is if the users don't use the browser. I'm not sure what the numbers are this year, but it's been iOS's browser and iOS's AppStore that has the most activity and/or money.
    - SomeCallMeTim 10y ago
      >iOS's AppStore that has the most activity and/or money. iOS AppStore has higher total sales so far, but the difference isn't that great, and Android is due to pass the AppStore in about 2018 [1]. I've seen a phone vs tablet breakdown that implied Android phone app sales actually surpassed iOS a few years ago, but I can't find it now. The huge difference was in iPad app sales which were much higher than Android, and it would be easy to believe that the difference in overall app revenues per store was made up by the difference in tablet revenues. [1] http://www.androidauthority.com/play-store-revenue-growth-2018-406474/ http://www.androidauthority.com/play-store-revenue-growth-20...
skrowl 10y ago
This exactly. Too many people make Chrome sites and Chrome apps instead of WEB apps.
btgeekboy 10y ago
Open source only matters to an extent. If Google's the primary source of committers, they can reject patches. And if a patch is rejected, sure you can fork, but your new browser will have 0 marketshare.

Bino 10y ago

Hmm, I really feel Apple is to blame for this mess, just my gut feeling.

kitsunesoba 10y ago
Mozilla is at least partially responsible as well. WebKit only became as dominant as it did because it was readily and easily embeddable, highly portable, and nearly language and toolkit agnostic. Gecko easily could've become a major player as well, but instead of looking ahead and making Gecko more appealing to developers and OEMs, they dropped support for embedded Gecko entirely and doubled down on Gecko and Firefox for all practical purposes being one in the same and forcing anyone interested in using Gecko to wrestle around with XULRunner. So today WebKit is everywhere (even where Chrome/Blink isn't) and is the bar all others are measured by. Had Mozilla been more amicable to projects like Camino and K-Meleon things might be different now.
- pcwalton 10y ago
  KHTML was hardly embeddable, portable, or language/toolkit agnostic at the time.
  - lmm 10y ago
    It was absolutely embeddadble - the KPart was a first-class supported way of using it (widely used in other KDE applications) - and at least somewhat portable (KDE on windows predates WebKit).
    - gcp 10y ago
      But didn't KPart rely on KDE (libs)? That's hardly embeddable in any meaningful sense. Gecko was embeddable too if everything you wrote was XUL :-)
      - lmm 10y ago
        Kdeui was (and remains) a first-class toolkit for writing arbitrary applications (and widely used as such) in a way that XUL has never really been.

EdSharkey 10y ago

Stick it to 'em, Mozilla! Don't let perfect be the enemy of the good.

liquidise 10y ago

In response to the complaints about "this is Big Internet Corps. fault", i think that is hasty. I code systems for all major modern browsers (including IE and Edge) and Cordova. I can count on exactly 0 fingers the number of times i have used a '-browser' prefix in the last year. The fact of the matter is that standards are moving fast and better still is the rate at which browsers are implementing those standards is very powerful. The use of css prefixes is, in my opinion, lazy. Many of popular directives are now implemented by browsers in the generic form anyways. The ones that are not can almost always be achieved through another styling method.

kccqzy 10y ago
I use flexbox (with autoprefixer) extensively and I think achieving similar designs without flexbox is a waste of programmer productivity. Yes I am lazy but I think it's productive.
- masklinn 10y ago
  Flexbox is available unprefixed in all current browser versions.
eyelidlessness 10y ago
There's nothing lazy about supporting older browser versions.
- roblabla 10y ago
  Yes, but instead of writing them by hand, you should just use the unprefixed version, and use autoprefixer to support older browsers. This also ensures you don't forget anyone.

sigvef 10y ago

Thanks Mozilla! Lots of great work being done, and it can be easy to take it for granted at times. This release makes me particularly happy because if fixes a WebRTC/MediaStream bug that I've been wrestling with on my current project ( https://www.zombocam.com https://www.zombocam.com ) for a few weeks. So thank you Firefox team!

alexbecker 10y ago
Is this named for http://www.zombo.com/ http://www.zombo.com/ by any chance?
- sigvef 10y ago
  Anything is possible with Zombocam :P

chaosfox 10y ago

hah thats funny, back in the day Opera also supported webkit prefixes[1], today it uses the blink engine. 1. http://www.opera.com/docs/specs/presto2.12/css/aliases/ http://www.opera.com/docs/specs/presto2.12/css/aliases/

tr4656 10y ago
Blink is a fork of webkit so it supports webkit prefixes anyways.
- thunderbong 10y ago
  He's talking about Opera 12 and before which was built on the Presto engine, not the Webkit engine
  - codedokode 10y ago
    The case with Opera is interesting. The web standards became so complicated that Opera was unable to maintain their alternative engine and implement all of new features. Microsoft might have to switch to webkit in the future too.

deleted 10y ago

[deleted]

consto 10y ago

These sites have all broken because of the way browsers handle new css properties, and by that I mean the -browser prefix. Web developers see this new shiny feature that either makes the page prettier, or easier to create, of course they'll use them. If browser developers really wanted web developers not to use these properties they would have to be enabled, manually, per browser. That would allow people to create implementations and test them, but stop prefixes getting onto the general web. Instead we are left with many browsers (i.e. not chrome) being forced to implement each others prefixes, and to a lesser extend JS libraries.

TazeTSchnitzel 10y ago
> If browser developers really wanted web developers not to use these properties they would have to be enabled, manually, per browser. That is precisely the approach being taken these days. Prefixes are legacy.
flukus 10y ago
I'm just as happy not using them, but try convincing clients/bosses to live without rounded corners.

Scarbutt 10y ago

One of the reasons I moved back to chrome from firefox was that it got annoying of dealing with websites that didn't work well in firefox, so this is a good UX improvement IMO. But now it means firefox has to chase chrome's tail all the time?

dblohm7 10y ago
It shouldn't: experimental web features are now hidden behind browser preferences instead of prefixes that anybody can (ab)use.

hobarrera 10y ago

For years now it's been obvious that Chrome is the new IE. This merely makes it even more obvious.

bitmapbrother 10y ago
No, IE shit the bed with its pathetic compliance with web standards. If anything, Edge is the new IE. Chrome is one of the most web standard compliant browsers out there and as long as it stays that way I'm okay with its dominance.
- ameliaquining 10y ago
  In my experience, the new IE is Safari.
  - hobarrera 10y ago
    Safari has barely any market share, so definitely no.
    - ameliaquining 10y ago
      On mobile, it has plenty. And I mostly meant in terms of speed to adopt new web standards and features.
- gcp 10y ago
  Chrome is one of the most web standard compliant browsers out there It helps if you're the one making the standards. Much of the current web standardization effort is just documenting what Chrome does and what particular bugs Blink has.
  - masklinn 10y ago
    > Much of the current web standardization effort is just documenting what Chrome does and what particular bugs Blink has. Which is exactly what "the current web standardisation" was with respect to MSIE back in the days of the Second War.

frik 10y ago

That was the tipping point of Opera and IE/Edge too. Opera 12 had various methods to emulate other browsers behaviours and compatibility domain-lists, in the end Opera 12 died and the next version, Opera 15, was just a fork of Chromium. IE/Edge feels pretty broken in modern web similar to Opera 12 back then. The question is were is webkit/Safari is this game. Most website have stylesheets that mention webkit prefixes, and it's now clear why Google removed the prefixes from their webkit fork (blink). It's bad for the end user and the web devs, but good for them.

6mirrors 10y ago

From the perspective of web developers, this is a bad decision as it encourages the direct use of non-standard features and thus leaves even more space for compatibility issues. Here is why: If firefox doesn't support -webkit prefix, the developers are forced to consider the compatibility issues and use something like "autoprefixer" to help. All of the experimental features will work as well as they could on different browsers (IE, Chrome, Firefox...) But if firefox support -webkit prefix and the developers buy it, they will write something like '-webkit-feature' directly and assume it will work on the major browsers. The problem is, major browsers only includes webkit based browsers, what about IE ? If a developer uses a non-standard feature directly, forcing he/she to consider the potential problems is better than leaving him/her a fragile solution.

djsumdog 10y ago
I have to agree totally. This change is asinine. They're basically inserting a regression away from standards just so content will look slightly better in their bowser (To gain browser share?)
- EdSharkey 10y ago
  I think Firefox will continue to support non-prefixed equivalents as well. Also, it seems like there are some useful -webkit- prefixed CSS properties that haven't yet been standardized with an unprefixed name. I think this is a good thing, they're adding new features that will (hopefully) get standardized someday. Let's heap some scorn on those websites and internal corporate teams that do all their work on Chrome and Safari and never test on other browsers. It's always laziness (not testing their crap at all) or lame excuses (Chrome is faster, why would I bother?) that's to blame. I don't mind being the "Firefox guy" on teams I'm part of and making sure my baby always gets some love.
- masklinn 10y ago
  There's no regression from standard, they're not removing standard support.
- otabdeveloper1 10y ago

minitech 10y ago

Firefox 49 supports background-clip: text, but thanks to these changes, the safest pattern to use to get it working in Firefox is still the -webkit one! color: #0dd; background-image: -webkit-linear-gradient(to right, #0cf, #0fc); -webkit-background-clip: text; -webkit-text-fill-color: transparent; https://jsfiddle.net/8kyzg826/ https://jsfiddle.net/8kyzg826/

teekert 10y ago

So, will I now see that very very nice mobile ui for outlook on FF mobile as well as on Chrome on android? Edit: Yes!! Finally!! Now, if only it would handle favicons the way chrome does it (many sites have a nice favicon for on the Android Launcher desktop in chrome, while in FF they get a low res white on orange star icon. Very ugly... On second inspection, seems like Chrome makes nice icon out of the first letter of the main domain and matches the main color to the one used on the site as a default, while FF has that star.) Also, it lacks drag-to-refresh as it does in Chrome. But I can tap the address bar and "enter" of course.

nachtigall 10y ago
> Also, it lacks drag-to-refresh as it does in Chrome. But I can tap the address bar and "enter" of course. You can also "Menu" > "Reload".