Mozilla to improve Firefox WebKit compatibility
WebKit-based browsers are a dominating force, especially in the mobile world where they are dominating the landscape but more and more also on the desktop.
This should not be a problem compatibility-wise for non-WebKit-based browsers like Firefox, but the truth is that it depends largely on developers and site operators if that is indeed the case.
So-called -webkit prefixed CSS properties and features are being used around the web to make sites and services display fine in WebKit-based browsers.
If there is no fallback, sites may display incorrectly in other browsers or may be outright broken, even if those browsers support the underlying features as well.
There are a couple of explanations why developers or site operators use -webkit prefixes only including laziness, budget constraints, or implementing features at a time where only WebKit browsers supported them.
To counter this, Mozilla added a whitelist of sites that use -webkit prefixes to Firefox in mid-2015 to improve support for these sites in the browser. The list contained almost exclusively sites from Asia for mobile use at the time.
The situation seems to have gotten worse however and not better, and Mozilla made the decision recently to do away with the whitelist to enable support for certain -webkit specific prefixes for all sites visited in Firefox.
The bug, "Alias the most important WebKit CSS properties & features for mobile compatibility" is the main tracking bug for the implementation of the feature.
Mozilla has already launched the new feature in Nightly versions of the Firefox web browser, and plans to make it available in Firefox 46 or 47 Stable depending on development progress.
Firefox Nightly users need to enable a preference in the web browser before it becomes available.
- Type about:config in the browser's address bar and hit enter.
- Confirm that you will be careful.
- Search for the preference layout.css.prefixes.webkit.
- Double-click it.
If layout.css.prefixes.webkit is set to true, it is enable and webkit emulation is running, if set to false, the feature is disabled.
The preference is already part of Firefox Nightly on the desktop and for mobile, and will be made available in other Firefox channels in the coming months.
Mozilla has started to work on a compatibility listing of vendor-specific CSS properties and DOM APIs on top of that that.
This standard describes a collection of non-standard (and often vendor-prefixed) CSS properties and DOM APIs that web browsers need to support for compatibility with the de facto web.
Closing Words
The move should improve compatibility of Firefox especially on the mobile web. While it is definitely beneficial to users of the browser because of that, it may push developers even further down the "WebKit route".
Er, hello people.
Webkit was originally an Apple technology that they open-sourced. Blink is a fork of Webkit to remove features (i.e. IoS features) that Google did not want/need. After the Blink fork, Webkit removed all of the Chrome-specific code that Google had added.
In other words, Blink does not equal Webkit. They both have their own lives.
Thanks Mozilla for supporting an emerging monopoly… Just switch to Blink completely and be done with it!
Good old Firefox is dying a very slow death.
so is chrome the next ie6? everyone is targeting it and its bugs…
nice going mozilla, maybe you wont be on life support long
I’ve done work for Adobe adding CSS features to all the open source browsers. I can say with confidence that all of the comments here are made by severely uninformed people.
That’s a lot to say when you don’t have any backing information. Why don’t you inform us on what we are ignorant about?
Servo – the engine where all customization features for power users are removed out of the UI. No thanks!
It’s a temporary problem, all browser will switch to the mozilla servo engine in 2018
There is only one example which will offer a total seperation of Chromium and Blink. QTWebengine from the QT project.
All other browsers which are “Chromium based” are using directly Chromium, just chaning few aspects of the code. Even Vivaldi is no different. So, you can say Blink=Chromium.
Anyway, i totally oppose a general Webkit monoculture. That means that one developer/a handful of developer groups are actually dictating what exactly a standard and a draft is. That is way too much power in one hand. But no matter of how i personally feel about this or others are feeling, we are getting exactly there.
And almost nothing can be done against it. Because all the one’s who have been opposing that dictatorship either already switched over (Opera) or damaging their good or not so good reputation with all their might (Mozilla, Microsoft) in becoming as close to Chrome as possible.
@lestate, I agree completely
IIRC, Vivaldi is by the original developer of Opera, using his Presto web layout engine – that was the whole point of leaving Opera and creating Vivaldi.
The problem is that Vivaldi does not look, or work, like classic Opera. Nor can it be made to do so. It is slightly better than Chromium, but still bears striking resemblance to it – for those not liking that look and the lack of user choice, it is only a half-step forward.
Vivaldi uses Chromium/Blink.
@Moonchild
I totally agree.
The result will be that all browsers have to adopt that vendor-specific features and if they can’t and their own creations turn out as failures (that outcome Google loves to see the most) they are most likely forced in that later case forced to adopt Chromium.
Full circle. I am sure it is only some amount of time left until Mozilla will join the Chromium bandwagon too. They may show big talk about Servo, how great it is, how much of the future it is, but they had that big talk countless of times before and in most cases it was ending in a disaster for them.
What would be the problem with a “standardized” web render engine? I think it would be beneficial if ALL browsers used Blink.
I’m not saying every browser should be Chromium based, but at least the rendering engine should be common.
They ARE, for all practical purposes, one and the same. If it were not so, all the Chromium based browsers would not be immediately identifiable as such. Note Opera as the best example. If the idiots left at Opera had half the brains they believe they do, they would have made strides to make Opera over Chromium look and feel like Opera with Presto. THAT is what the majority of users wanted, and ostensibly that is what was sought – but the devs left over from the purge were stupid and lazy, and could not code well, so they simply put a new skin on Chrome, removed some features [so it would look like a continuing effort] and began putting them back, slightly modified.
The losers are those who wanted the unique look and feel of Opera, and anyone else that doesn’t like the UI feel and look of Chromium.
because that worked out so well for Opera? A rendering engine can’t just be thrown in, especially blink. Plus, when you have one rendering engine, then you have no competition, resulting in lag. Look how well that worked out for Trident back in the day. Also, blink was created because Google wanted to implement their own things into the rendering engine and cut out a lot of old code. People who want to use blink essentially has to use chromium.
If everyone was on one rendering engine, then there wouldn’t be much development. If everyone was on Blink, then Google calls what they want implemented and what not.
And what if there’s a huge security flaw in that engine? What if you have an engine that is 10% faster, or 10% more “standards-compliant”?
The W3C should be the originator of the standards, not a specific rendering engine or developer. There was a huge uptake in JavaScript performance when Mozilla and Google started competing; that would not have happened in a stagnant “monoculture.” Microsoft also competed (slightly less successfully) at that time, which led to improvements in IE (and eventually the development of Edge). Why would you want to put all your eggs in one basket, leaving development to stagnate?
A classic example of Embrace, Extend, Extinguish by Google, if you ask me: Embrace the CSS standard, extend it with vendor-specific features, make those features popular in such a way that there’s wider adoption, resulting in problems for anyone not supporting those extensions and reducing usability as a result.
It’s sad to see all these efforts of creating standards are simply being thrown out the window in favor of vendor-specific, non-standard quirks and “features”, on top of putting pressure on people actually writing up the standards to change them for specific vendors, the so-called “spec bugs”.
How about a New Year’s resolution that is “We’ll make our websites standards compliant as opposed to just working in 2 or 3 browsers”? :)
It’s simply too easy to run your css through autoprefixer from a devs point of view that not doing it is out-right laziness or plain ignorance. If the site is broken in the browser I do not revisit it. It’s on the site dev to deliver me that content in any browser not the browser vendor. If the site dev does not test if their site works well on what I call the Big 3 then they aren’t much of a dev. Chrome, Webkit, and Mozilla is what I consider Big 3. Waaaay too easy to test that.
Mozilla used to be “Mozilla”. Not the current iteration that is chasing Chrome’s and now Webkit’s tail. Mozilla had it’s own identity. Vendor prefixes should technically not exist in a standardized web. They were brought about by each individual vendor developing their own version of early CSS3 code before it was implemented. Now it’s implemented. I personally would have been happier to hear that Mozilla had dropped it’s prefixes, and any other prefix shims being supported, for standard CSS3 properties only. We wouldn’t need prefixes at all if the vendors would go to standard.
Of course it is a wrong route. Because this only supports Webkit monoculture which we already have. We are exactly in times again where there was one engine which influenced the web as a whole.
Earlier the browser was IE, today it is every browser which uses Webkit.
Nope, in the occurrence of a broken website, I just never access it anymore, lazy ass developers don’t deserve my time.
I think this is yet another blunder from Mozilla.
Webkit route doesn’t equal wrong route. After all Mozilla already has its -moz- for features which are not officially supported in w3c’s latest official specifications and right now it’s simply annoying to use both -moz- and -webkit- prefixes when 95% of the time what follows is identical.
This will be beneficial to everyone as with time it will reduce the .css size and make projects less costly while end users will see 0 difference.
Just fucking switch to WebKit or more preferably Blink.
Some people don’t wish to be pushed into de facto standards, instead of actual WWW3 standards. Also, though I don’t buy into the “Google is evil” stand, I really don’t like ANY browser purveyor to dictate standards – it should be the bailiwick of the standards committee only.
And so it begins. Now Mozilla is heavily running into website compatibility problems, same like Opera, but for a different reason.
And we have seen what the end outcome was in the end. In a Webkit dominated web it becomes harder and harder to support your own product if you are not going down the road to support that specific Webkit drafts. And the more market share Firefox is losing, the more it loses relevance for website developers and is forced to go down even more the road of supporting Webkit draft after Webkit draft.
The race to the utter bottom has become. But it was unavoidable that that was happening sooner or later.
… The race to the utter bottom has become inevitable. But it was unavoidable that that was happening sooner or later.
Seems my comment was crippled during writing *lol*