Firefox Will Support Non-Standard CSS For WebKit Compatibility (theregister.co.uk) 132
RoccamOccam writes: Mozilla developers have discussed a plan to implement support for a subset of non-standard CSS prefixes used in WebKit. Mozilla developer Daniel Holbert says: "A good chunk of the web today (and particularly the mobile web) effectively relies on -webkit prefixed CSS properties & features. We wish we lived in a world where web content always included standards-based fallback (or at least multiple-vendor-prefixed fallback), but alas, we do not live in that world. To be successful at rendering the web as it exists, we need to add support for a list of frequently-used -webkit prefixed CSS properties & features."
Safari really is the new IE (Score:5, Insightful)
So basically, Edge and Firefox have to adopt their shitty, broken, prefixed CSS, because web developers were too lazy to do things right... just like how Mozilla and others have had to adopt IE6-isms, because developers were too lazy in the same way. Great. Shows just how professional my peers are that they refuse to develop to proper standards, and worse, developed sites without proper (and usually trivial) fallbacks... all for mere eye candy.
Re: (Score:1)
So basically, Edge and Firefox have to adopt their shitty, broken, prefixed CSS, because web developers were too lazy to do things right...
And does this surprise you? And how do you propose getting said lazy developers to fix their stuff???
(Web user browsing bad site):
This site looks terrible in FireFox. Let me try Edge...
Hey it works now. FireFox must be broken...
So you see if one does it, they all must or they look like shit...
Re: (Score:1)
Oh, I'm not saying Mozilla is doing a bad, I'm just expressing my sadness that they've had to do this, as well as stating my opinion that Safari has become the new IE on several levels (though it's an unfair comparison, nobody is fair to browsers around here anyway, so I might as well not be).
Re: (Score:2)
Re: (Score:1)
When you are out and about, you need to take the original Mac Portable with you... 16 lbs of goodness.
Re: (Score:2)
Re: (Score:2)
WebKit team while initially extremely revolutionary have decided to take a massive shit and sit on it for a few years [github.io]
Credit where it's due, they drove the web forward, but the recent investment in WebKit / Safari nightly's is, pathetic, at best.
Re: (Score:2)
Don't believe me? Look at the revision history and release cycle, it's insulting.
Re: (Score:2)
The Webkit team is quite awesome, it's just that there's far too few of them.
Which makes some sense if you're Tim Cook. You want people writing iOS apps in the walled garden instead of cross-platform Web content, and for now you can expect they will, especially if that Web content doesn't work well in Safari.
But at some point, in some markets, that strategy may break down.
Re: (Score:2)
This is an interesting conspiracy theory, but Apple only accounts for around 1/3rd of all Webkit commits.
Uhhh...To which year are you referring? Perhaps half of the names in your link are listed under groups that don't develop webkit anymore. For example Chromium (which there are a lot of in your list) is on the Blink engine now, and has been for a while now. It doesn't appear that they ever purge this list of older maintainers.
Re: (Score:2)
The parent might have been modded down a
Re: (Score:1)
This is divine karma. After all, people were gloating when Opera basically criticised web developers for fucking over web standards for Webkit only standard. And all the freetards were cheering the web developers and telling Opera to jump off the cliff 'cause webkit is still open source eh ?
We've just exchanged one shit company (Microsoft) for another (Apple).
Re: (Score:1)
Webkit kicked my dog and raped my wife.
Or was it the other way around....
Re: (Score:2)
Not like Firefox is a saint in the web standard world. They have their share of sins.
ES6 proxies and arrow functions come to mind, where they implemented bullshit versions that didn't match standard very quickly. Worse, a bunch of peanut gallery would go around complaining that the standard compliant implementations were broken because they didn't match Firefox...
Re: (Score:1)
"So basically, Edge and Firefox have to adopt their shitty, broken, prefixed CSS, because web developers were too lazy to do things right..."
Well, the market should be dictating the product, not the other way around.
If what the market wants was/is not foreseen on some peoples road map, well tough shit for the roadmap.
Re: (Score:2)
You say safari but its just as much chrome, which is also default on android phones just like safari is on iOS phones. In fact, this phenomenon got strengthened when Google starting making Chrome the default android browser and led to this situation.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Well, a lot of the prefixed stuff is actually in the standards,
Re: (Score:1)
Many IT workers who make web pages or templates are not JUST web page builders/designers. Often they wear multiple hats and are the help-desk, hardware repair, DB admin, network admin, desktop developer, etc. etc. etc.
When you wear multiple hats, it's difficult to find time to master them all, and probably an unrealistic
Surprised it too this long (Score:2)
This was much more an issue a few years ago when the iPhone was much more dominant on the mobile web.
Re: (Score:2)
This was much more an issue a few years ago when the iPhone was much more dominant on the mobile web.
How is that? Safari uses Webkit, Google uses a Webkit fork, Opera is now using Webkit... the mobile web is pretty much all Webkit except for Windows Phone and Firefox, both of which have marginal market share.
Re: (Score:2)
Well, at least Firefox has some redeeming qualities, such as addon support. Why other mobile browsers don't support addons is a total mystery to me.
Firefox mobile is kind of crap though, half of the time its renderer flakes and the screen contents don't reflect what's actually on the page (i.e. tapping on a link doesn't do anything because the link isn't actually "there".) Or other weird things happen like you'll scroll down a page and it behaves as if there's nowhere to scroll in any direction, even though
Re: (Score:2)
In my experience it's usually the shitty mobile sites at fault.
I can't tell you how often I have to select "request desktop site" because the mobile site is utter crap.
So this is how liberty dies... (Score:1)
...with thunderous applause.
Yay! Boo? (Score:1)
Yay! On one hand it's nice that Mozilla will render everything as desired. But on the other hand, we've already suffered a long hard fought battle against non-standard crap sites targeting non-standard browsers. So, boo for allowing Apple to be the new Microsoft.
It's the site designers faults, first and foremost. But Mozilla's actions are aiding and abetting. Boo!
Re: (Score:2)
Servo (Score:2)
I'm still wondering if and when Mozilla will give gecko a good ole rewrite.
I thought that's what the Rust language and Servo engine were for.
The list of prefixed properties (Score:5, Informative)
Here's a list of the "-webkit"-prefixed properties.
https://compat.spec.whatwg.org... [whatwg.org]
At least at an initial glance, it seems to me that the criticisms about WebKit being "the new IE" are generally misplaced, since most of the listed properties are aliases for the standard versions of those properties. I.e. WebKit was the first rendering engine to support those properties, but it did so while the web standard was being finalized, so it prefixed those properties, as it is supposed to. Lazy developers implemented those properties using the prefixed property, since that's all that was available at the time, but didn't go back to fix the code afterwards when the standard was finalized.
Long story short, WebKit did things exactly as they were supposed to. They implemented a proposed standard, prefixed it as they were supposed to, and then implemented the standard version later while maintaining support for the prefixed version. Really, the only ones who aren't following best practices are the developers too lazy to update their code to work with the current standards, but if we're going to blame WebKit for being too quick to support proposals, then we may as well blame the other rendering engines for being so slow that the lazy devs couldn't use their prefixed versions. Two sides of the same coin. It's no surprise that one side blames the other.
Re:The list of prefixed properties (Score:4, Insightful)
Where it goes wrong is when other implementations implement the prefixed versions. That makes things worse than any delay in standardizing those features does.
Now there's the standard features, the Firefox-only features, the prefixed features Firefox implements, and the prefixed features Firefox doesn't implement. And we're back to the same hell we were in not long ago and seemed to be climbing out of.
Initiatives like this will not speed up standardization and the adoption of the standards, they will slow it down.
Re: (Score:2)
I don't think anyone is blaming Webkit for anything. The problem lies solely with the developers.
Lazy developers implemented those properties using the prefixed property, since that's all that was available at the time, but didn't go back to fix the code afterwards when the standard was finalized.
Is there a compelling reason to not include the yet-to-be-standard prefixes initially, even if no browsers supported them yet? It seems like any competent developer from the beginning of CSS3 should have included any vendor prefixes as well as the standard, and then they wouldn't have had to go back and "fix" anything, just remove the cruft.
At least at an initial glance, it seems to me that the criticisms about WebKit being "the new IE" are generally misplaced
It's a good analogy, in the sense that if a browser vendor doesn't sup
Re: (Score:2)
After re-reading what I wrote, I should clarify: the problem is with website developers, not browser or engine developers.
Re: (Score:1)
You really think that getting to expend resources changing something that works into the same thing that still works is the kind of thing website developers get to control?
Re: (Score:2)
This subthread is:
http://news.slashdot.org/comme... [slashdot.org]
Yes, I know they said Safari specifically, but what they really were meaning to blame was WebKit...
Re: (Score:2)
No, that first comment is blaming...
because web developers were too lazy to do things right
Re: (Score:2)
Because the "yet-to-be-standard" names ... generally don't exist yet
So what? The browser gets to that line, it doesn't recognize that property name, and the browser ignores it. What's the problem? When a version gets released that supports it, then it will use the property.
Re: (Score:2)
Quite the opposite should happen, actually. Normally a (competent) web developer writes their CSS without any vendor prefixes. They will then use a tool to add the vendor prefixes, which is normally part of their workflow or build process (so is run automatically). That means the developer just writes pure CSS, and the vendor compatibility is taken care of automatically.
Re:The list of prefixed properties (Score:5, Insightful)
Long story short, WebKit did things exactly as they were supposed to. They implemented a proposed standard, prefixed it as they were supposed to, and then implemented the standard version later while maintaining support for the prefixed version. Really, the only ones who aren't following best practices are the developers too lazy to update their code to work with the current standards, but if we're going to blame WebKit for being too quick to support proposals, then we may as well blame the other rendering engines for being so slow that the lazy devs couldn't use their prefixed versions. Two sides of the same coin. It's no surprise that one side blames the other.
I think browser developers could all have gone a little bit further and not enabled their proprietary CSS prefixes in production releases by default. Maybe push those into a "developers only" mode, or an extension, but keep it out of production.
The prefixed CSS rules were supposed to be for not-yet finalized pre-standards versions of stuff the W3C hadn't yet finalized, to give web developers a chance to play with them, test them, and provide feedback so that when W3C finalized their recommendation, they were well tested in the real world and good.
By making them available to everyone early, it incentivized web developers who wanted their websites to look "cutting edge" to make use of the unofficial properties before they were ready. Also, the slowness with which W3C has historically acted to finalize their recommendations exacerbates this incentive. If a web developer waits for the W3C to finalize and only uses W3C recommendations, they're left hoplelessly behind the state of the art.
From that point, it was only a matter of time before a dominant browser emerged with its proprietary prefixes became de facto standards adopted by web developers before W3C was ready to finalize their own version of them. What else could they do?
So, blame W3C for not being faster, but mainly blame browser developers for tacitly allowing and encouraging developers to make use of the experimental CSS properties ahead of itme for production sites.
Re: (Score:2)
I don't think its bad if browsers add some vendor specific features, so that developers can test them. This is one way the standard can be tested on a wide range of devices. It is far better to say "According to our metrics, this feature is enabled on 2000 websites with a total of 20 million users, so it seems to work great and fill a niche" than to say "Well yes it can be implemented but lets first do some bikeshedding".
I agree, one shouldn't blame mozilla. Instead of them having to add the -webkit CSS pro
Re: (Score:2)
At the very least, they could phase them out after the standard is final and all browsers have added non-prefixed versions.
Re: (Score:2)
And break the internet? By now there are thousands of pages, perhaps millions, that are relying on these non-standard prefixes, and like pages designed for IE6, it is going to take years for enough of them to be updated that the prefixed attributes can be safely phased out.
Re: (Score:2)
Yes. The faster those pages break, the faster they'll be fixed.
Re: (Score:2)
The reason why the web became such a mess back in late 90s - early 00s is precisely because everyone was afraid to "break the Internet".
Re: (Score:2)
-webkit- is only the problem because it is widespread. Pretty much the same set of attributes are similarly available with -moz- prefixes, and some are available with -ms- or whatever it is that Microsoft uses for its browsers. So you can't blame WebKit developers, all the browser developers were doing the same thing.
Re: (Score:2)
Why would developers fix them when those sites work in every major mobile browser?
And of course there's no way to become a major mobile browser while all those sites are broken.
Re: (Score:3)
This comment was brought to you by Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36 Edge/12.10136
. Business as usual.
Re: (Score:2)
Why fix what wasn't broken? And now Mozilla's decision means they won't ever have to.
If I ever wrote a web browser, I would subtly alert the user and blame the web site whenever a web page is significantly worse than average at conforming to standards. Maybe a little public shaming would get developers to fix
Re: (Score:1)
Re: (Score:2)
Things have gotten a lot better since the IE days, since browser competition has resurged, we've learned a lot about how to write specifications, and we've stopped chasing irrelevant or impossible dreams (e.g. XML, semantic Web).
No big deal, mostly just aliases (Score:4, Insightful)
Re: (Score:1)
Effectively it means that clueless coders will keep copy-pasting crappy webkit-prefixed HTML from StackOverflow etc, it'll work for them, and they'll assume that it's the right way going forward, and will keep doing that. So in practice it just makes -webkit-* a de facto standard.
Re: (Score:2)
Does -moz- work in other browsers?
Re: (Score:2)
Webkit didn't do exactly what they were "supposed to do":
Prefixes were intended to be used for experimental features, eventually to be removed in favor of standardized versions. But Apple has always promoted Webkit-prefixed features as permanently supported features of Safari that developers should use in production sites. (You could argue that's Apple doing that, not Webkit, but most Webkit staff, especially in those days, worked for Apple.)
Vendors implementing prefixed features were supposed to be on the
Re: (Score:1)
What is stopping webkit from removing legacy support for those prefixed extensions? If they beleived in standards and weren't the new IE, that's what they would do. That would force developers to fix their code.
Re: (Score:1)
firefox caves again (Score:1)
this is becoming an habit with firefox. doing the popular and easy thing, however dubious, instead of correct and proper thing, however difficult,
freedom is undermined more often by laziness, not outright villainy
Re: (Score:3)
Re:No, we don't. (Score:5, Insightful)
when web sites see their numbers start to plummet cause no one can view their site properly, maybe they'll fix it with standards compliant code.
Except that's not what happens. Websites don't see their numbers plummet, browsers see their market share plummet when people notice the site works in one browser and not in another browser. Guess which of those 2 groups Firefox is finding themselves inside. They want to be in the other group, and they don't want to wait for website developers to get their shit together or else Firefox is going to go the same way as Netscape.
If Webkit doesn't want to comply
Webkit is following the standard just fine. The drafts clearly said that browser vendors should implement experimental properties with their own prefixes prior to things being finalized. Every major vendor has their own prefix that was used during that time. Those prefixes are no longer needed, but web developers still launch sites that have the -webkit prefix only, without support for any other browser. So, only Webkit browsers use that CSS, and other browsers look like shit because the web developers didn't bother to put the standard properties, only the prefixed properties. The problem is not browsers, it is lazy and/or incompetent website developers (again).
Re:No, we don't. (Score:5, Insightful)
Those prefixes are no longer needed, but web developers still launch sites that have the -webkit prefix only, without support for any other browser. So, only Webkit browsers use that CSS, and other browsers look like shit because the web developers didn't bother to put the standard properties, only the prefixed properties. The problem is not browsers, it is lazy and/or incompetent website developers (again).
This is true, BUT, when people encounter a page that doesn't display properly on one browser, but works fine on another, they automatically blame the browser, not the lazy, shitty developers.
There is a simple fix -- name and shame. If a non-webkit browser encounters a page with only a -webkit prefix, then the browser should display a message which says something along the line of "This page contains code specifically designed for Safari, Chrome or Opera and may not display properly if you are using a different browser".
It's not a perfect solution, but at least it informs the user that the problem is with the lazy, shitty developers and not the browser. Time to grow some balls -- name and shame.
Re: (Score:3)
So you're saying the way to get market share is to tell your users to use a different browser.
Re: (Score:2)
Re: (Score:2)
There is a problem with Webkit: prefixes were supposed to be for experimentation only, but Apple has always promoted Webkit-prefixed properties as being suitable for use on production sites.
Also, we've figured out that prefixes are useless for what they were designed for (enabling standards to evolve without having to be compatible with early experimental versions). Authors like to "future proof" their sites by writing CSS like "foo { -webkit-blah:pong; blah:pong; }", which means the standardized "blah" is
Mozilla is on the way to become forgotten (Score:1)
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
Have you filed a bug?
Bugzilla doesn't take anonymous reports. I have an account, but Bugzilla won't let me log in, instead telling me my password isn't complex enough.
Standard cliche-liketalking points, sadly! (Score:2)
"A good chunk of the web today (and particularly the mobile web) effectively relies on -webkit prefixed CSS properties & features. We wish we lived in a world where web content always included standards-based fallback (or at least multiple-vendor-prefixed fallback), but alas, we do not live in that world. To be successful at rendering the web as it exists, we need to add support for a list of frequently-used -webkit prefixed CSS properties & features."
This has always been the case. Are they telling us they had no clue it's been this way all along?
Re: (Score:3)
We thought we should try site evangelism and education first. They didn't work. With Microsoft's help they might have had a better chance (though I think they probably still wouldn't have worked), but Microsoft caved before we did.
Oh this is going to be fun... (Score:2)
The point of the vendor prefixes was so vendors could implement experimental, non-standard, or all around "stuff that is not meant for all browsers".
That way, I can put a webkit prefixed property to do something webkit specific (maybe to compensate for a bug), and not have to worry about other browsers. It's not perfect: webkit is a very broad subset of rendering engines, there's differing versions, etc...but it could be worse.
And so Firefox will make it worse. What happens when the latest evergreen version
Re: (Score:2)
The point of the vendor prefixes was so vendors could implement experimental, non-standard, or all around "stuff that is not meant for all browsers".
So what's the point of having standards then?
We already went through this bullshit years ago with Internet Explorer.
Because IE comes pre-installed on Windows, that's what most people tend to use. As a result, developers started creating pages that ignored standards and used IE's nonstandard bullshit. IE became the standard, and for years (as just one example) people rarely used CSS because IE's support for CSS was so shitty and broken.
It wasn't until Firefox and Chrome came along that there was a big push
Re: (Score:2)
Standards are for taking experimental and/or non-standard stuff and making it, well, standard. Standards don't pop into existence out of the ether.
Re: (Score:2)
In Firefox Webkit-prefixed properties are mostly just aliases to the corresponding standardized properties. We're adding very little actual new behavior.
Re: (Score:2)
Then it should be just as easy for Webkit to make the standardized properties aliases for the Webkit-prefixed ones. And then Webkit-prefixed stuff can be dropped and the site maintainers and devs have an easier time of it as they can just use the standardized properties and not worry about whether it's rendering on Webkit or not. Updating the stylesheets ought to be straightforward property-name replacement. I really really don't want to go back to the bad old days of browser detection and companies specify
Standards (Score:2)
We wish we lived in a world where web content always included standards-based fallback (or at least multiple-vendor-prefixed fallback), but alas, we do not live in that world.
Yeah, mainly because people keep caving in and supporting non-standard shit. C'mon, show a little backbone, will ya?
What's the point of standards then? (Score:2)
If other engines wind up having to implement other vendor's prefixes anyhow, why even bother with a standards body? This seems rather dubious...
Re: (Score:2)
Why not instead put the blame on the free software community for failing to produce HTML tools that live up to the feature set and usability of Adobe CS6?
Devs should be beaten over the head (Score:2)
Re: (Score:2)
HTML4 has been superseded by HTML5. To which specific non-conformances do you refer?