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.
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.
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.
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.
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.
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.
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...
The consumers are using different browsers. People who write HTML are often not very competent and cannot make page display properly everywhere.
I use Chromium (because unlike Chrome it is open source). Video playback doesn't work even on twitter and vimeo (who can afford to hire good developers) let alone smaller websites. But it works on Youtube (not always, some videos require flash) and Wikipedia.
UPD: That is why I think people sould learn from Wikipedia developers and not some hipster guys explaining how to connect Redux to Angular2 using ES7.
Video playback doesn't work even on twitter and vimeo
This is because they use H.264, a patented but common video codec. Chrome includes a licensed decoder for it, but Chromium cannot include that because it's open source. Firefox "solves" this by relying on installed system libraries (for video) and a licensing hack by Cisco (for WebRTC).
Your experience is a pretty good illustration that Chromium is not the open source version of Chrome.
Chromium might not support H.264 but it supports VP8 and some open source codec Wikipedia uses. So the problem is with developers relying on proprietary codecs.
H264 isn't proprietary, it's patented. Anyway, like my own post here, what you say is factually right but besides the point. Users expect H264 to work or the web will break. Like -webkit prefixes.
> Are the costumers using Chrome? Then devs should test on Chrome too.
I do test on Chrome! The context is Chrome removing standardised features with no warning years down the line, breaking existing deployed content.
What do you expect a web developer to do in that case?
No amount of the Chromium team being hostile to web developers will stop people from using Chrome. Yet so long as the Chromium team are breaking websites using standardised features without warning, the web developer's life will be pain.
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.
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.
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...
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 ...
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.
> 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
Chrome was released in 2008, when Firefox' share was up to 28% [0] and Microsoft's monopoly already was over. IIRC, Google used former (or hired away then current?) Firefox developers.
Chrome was insurance for Google. Even with IE's monopoly broken, their search engine could become under threat if someone else outbid them for Firefox's default search. With Chrome having significant marketshare, this is no longer a worry.
It's worth investigating how much money Google lost because Firefox switched to Yahoo, just in the USA, and even accounting for the people that switched back. The number is astoundingly high.
It was insurance also because it let them be sure that Gmail and Docs would keep running and be fast in at least one browser. Remember when Firefox had a slow JS engine and IE was molassa? Microsoft would not go out of their way to make sure that Google could undermine Office, Mozilla maybe would speedup its JS and Apple probably not given its interest in apps.
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.
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.
>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.
No developers can afford to ignore Mobile Safari, so we're all limited by what Apple chooses to support. It's Apple's prerogative to prioritize what they want for Safari, of course, but there is no justification any more for blocking all other browser engines other than hamstringing web apps.
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.
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.
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.
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.
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 ) for a few weeks. So thank you Firefox team!
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.
> If firefox doesn't support -webkit prefix, the developers are forced to consider the compatibility issues
Evidence shows that they don't, and that developers are absolutely not going back and fixing code they shipped years ago, so all the principled stance nets firefox is "firefox breaks <outlook mobile>, it works just fine in chrome, screw that piece of shit firefox".
Blah, my $%#$% credit union, upgraded their web software the other day, and it basically supports only the latest FF, and chrome browsers on the desktop. Complete with a nice please download chrome button, and a refusal to proceeded. I'm running a webkit based alternative browser, and I had to go change my compatibility string to get past it.
I opened a ranty support request about the fact that they should consider replacing their web devs if they were unable to create a site that adhered to standards enough that they didn't feel the need to write browser specific code.
Having spent some time in the past few years doing web development myself, I don't feel the least bit sorry for web developers that are using browser specific prefixes, or other crap. In my experience its actually chrome that has serious rendering bugs these days, and FF/IE manage to render pages pretty similarly. So, at this point if your a web developer using chrome as your default target, that should be considered incompetence.
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?)
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.
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.
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.
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.
Well yes, but there was also significant outreach effort to get rid of the most egregious IE specifics and show how things could be done better and cleaner with (non IE specific) web standards. And that part was rather successful.
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.
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.
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!
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.
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?
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.
Google donated to/funded the Mozilla foundation, promoted a better web browser, and then released a closed source web browser based on both Gecko and Webkit.
Yes, Chrome (at least its rendering engine) is open now. But back when it was released, and the way it was released, was taken by many to be Google taking a big heaping dump on the OSS community.
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).
I think "embeddable" means at least "I have an arbitrary Charles Petzold-style Win32 app and I want to put KHTML in it without adopting my whole app to a framework". KParts was never really designed for this.
Apple's success with WebKit, combined with their success in advancing browser technologies, is partially responsible. To explain...
Their use of vendor prefixes was proscribed by the standards (and may well still be). After years of stagnation in browser technologies, and demand from content producers and developers for advancement, vendor prefixes were seen as a way to vet real-world usage of new standards before they were formalized.
But because standardization was still quite slow, and because vendors (all of them!) were slow to remove prefixes, and because non-WebKit vendors lagged behind WebKit in features (for a while), the proliferation of `-webkit-*` was inevitable.
Today's rejection of vendor prefixes is a reflection of that intersection of problems. They were maybe never a great solution to the problem that preceded them, but they are no longer suitable and that's just fine.
I'd prefer Firefox (and every other vendor) simply disabled handling for prefixes entirely. But there is a ton of content that will never be updated again, and would break. Without some kind of versioning, that's untenable.
And we already saw what happened when Mozilla tried to introduce versioning. (It was never supported by other vendors, and therefore never used by developers.)
