Firefox Will Support Non-Standard CSS For WebKit Compatibility (theregister.co.uk)

← Back to Stories (view on slashdot.org)

Firefox Will Support Non-Standard CSS For WebKit Compatibility (theregister.co.uk)

Posted by samzenpus on Monday January 4, 2016 @11:22AM from the making-it-work dept.

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."

132 comments

Min score:

Reason:

Sort:

Safari really is the new IE by Anonymous Coward · 2016-01-04 11:28 · 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.
1. Re:Safari really is the new IE by Anonymous Coward · 2016-01-04 11:40 · 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...
2. Re:Safari really is the new IE by Anonymous Coward · 2016-01-04 11:50 · 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).
3. Re:Safari really is the new IE by Anonymous Coward · 2016-01-04 11:50 · Score: 0, Interesting
  
  It isn't so much Safari, more Chrome.
  And it isn't even Webkit devs fault, it is the shit standards committee for being too slow at making things standards and shit developers for using experimental code.
  But the biggest part of the issue is web browser vendors having experimental things behind a prefix in the first place!
  It should only ever work if someone enabled a flag in the advanced settings, like originally planned. (about half of the experimental code is behind a flag, the rest completely open)
  Fact: most developers are awful at their work and cannot make simple, informed and sensible decisions.
  People go on about how children can't make informed decisions yet there are billions of adults that regularly make stupid decisions every damn day.
  Last I remember when I was a kid, I decided my entire future down to the T, and multiple backups in case I never got in to said industries for whatever reason. (I know, I know, I am a minority, but I point you back to the start of this paragraph, most people suck all kinds of ass.)
4. Re:Safari really is the new IE by Anonymous Coward · 2016-01-04 11:56 · Score: 0
  
  Hit people with Apple products in the face when you see them.
5. Re:Safari really is the new IE by Anonymous Coward · 2016-01-04 11:59 · 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).
6. Re:Safari really is the new IE by Anonymous Coward · 2016-01-04 12:08 · Score: 0
  
  I'm parsing this as needing to carry an Apple product with which I hit everyone I see. Time to bring my Mac Plus out of the closet.
7. Re:Safari really is the new IE by Shados · 2016-01-04 12:09 · Score: 1
  
  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...
8. Re:Safari really is the new IE by rudy_wayne · 2016-01-04 12:54 · Score: 0
  
  Webkit kicked my dog and raped my wife.
  Or was it the other way around....
9. Re:Safari really is the new IE by Anonymous Coward · 2016-01-04 13:41 · 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.
10. Re:Safari really is the new IE by arglebargle_xiv · 2016-01-04 14:52 · Score: 1
  
  What really surprises me is that this is the first Firefox headline in I-don't-know-how-long that doesn't boil down to "Mozilla announces yet another way they're going to fuck up what used to be a leading web browser".
11. Re:Safari really is the new IE by DanJ_UK · 2016-01-04 14:52 · Score: 1
  
  Umm, no.
  
  WebKit team while initially extremely revolutionary have decided to take a massive shit and sit on it for a few years
  
  Credit where it's due, they drove the web forward, but the recent investment in WebKit / Safari nightly's is, pathetic, at best.
  
  --
  - Dan
12. Re:Safari really is the new IE by DanJ_UK · 2016-01-04 14:55 · Score: 1
  
  +++ and a lot later than you would expect from the so called pioneers of recent web browser technologies. They've only just caught up with other vendors, I have no idea what the fuck Apple's management are doing bearing in mind that Safari is literally WebKit with some additional integrations.
  
  Don't believe me? Look at the revision history and release cycle, it's insulting.
  
  --
  - Dan
13. Re:Safari really is the new IE by kangsterizer · 2016-01-04 14:58 · Score: 1
  
  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.
14. Re:Safari really is the new IE by Anonymous Coward · 2016-01-04 15:22 · Score: 0
  
  Hit people with Apple products in the face when you see them.
  I'm parsing this as needing to carry an Apple product with which I hit everyone I see. Time to bring my Mac Plus out of the closet.
  If you see a person with Apple products in their face, hit them.
15. Re:Safari really is the new IE by edremy · 2016-01-04 15:52 · Score: 1
  
  Do it with the first generation Mac Portable. Maximum impact
  
  --
  "Seven Deadly Sins? I thought it was a to-do list!"
16. Re:Safari really is the new IE by Anonymous Coward · 2016-01-04 15:53 · Score: 0
  
  They're certainly not, but comparing the work of Firefox on the next JS standard (which they helped to develop and push forward) to iOS's many CSS sins is like comparing a tree to an entire forest. Who would use these core JS features that could be done via other means (and only worked in Firefox), compared to all of those shiny trinkets that could only be done in Flash (not on the iPhone) or via really difficult means (not feasible on early iPhones)?
  That, and unlike Safari, Firefox is actively trying to deprecate these prefixed features, while the latest Safari pushed new prefixed non-standardized features ones out, because Apple apparently does not care much at all about catching up on existing web standards compared to farting out shiny new trinkets that aren't even remotely standardized yet.
17. Re:Safari really is the new IE by Anonymous Coward · 2016-01-04 15:58 · Score: 0
  
  That's utter nonsense. The "market" is not devoid of responsibility when they make an utter mess, just because they wanted to chase the latest fad. That, and the market is not one solid entity, as is evidenced by the fact that relatively few idiots were as unprofessional as to cause this problem in the first place. The "roadmap" is there to prevent this kind of retrograde selfish bullshit in the first place, but some people think they should wag the dog because they're special snowflakes.
18. Re:Safari really is the new IE by Anonymous Coward · 2016-01-04 15:59 · Score: 0
  
  Web developers lazy? Say it aint so!! And lol at you thinking web monkeys can qualify as professional. 99% would be lost without someone on StackOverflow doing their job.
19. Re:Safari really is the new IE by davester666 · 2016-01-04 16:04 · Score: 1
  
  When you are out and about, you need to take the original Mac Portable with you... 16 lbs of goodness.
  
  --
  Sleep your way to a whiter smile...date a dentist!
20. Re:Safari really is the new IE by roca · 2016-01-04 16:09 · Score: 1
  
  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.
21. Re: Safari really is the new IE by Anonymous Coward · 2016-01-04 16:58 · Score: 0
  
  The market defines
22. Re:Safari really is the new IE by Anonymous Coward · 2016-01-04 17:16 · Score: 0
  
  They don't have to. It's just part of the stupidity that has taken hold of Mozilla. I remember the time when they promoted standards. Now they're sabotaging them.
23. Re:Safari really is the new IE by Anonymous Coward · 2016-01-04 17:35 · Score: 0
  
  Chrome forked webkit. They're on Blink now. The stock Android browser has always been webkit though.
24. Re:Safari really is the new IE by Anonymous Coward · 2016-01-04 17:39 · Score: 0
  
  The Webkit team is quite awesome, it's just that there's far too few of them.
  This page would beg to differ.
  
  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.
  This is an interesting conspiracy theory, but Apple only accounts for around 1/3rd of all Webkit commits.
25. Re:Safari really is the new IE by ArmoredDragon · 2016-01-04 18:23 · Score: 1
  
  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.
26. Re:Safari really is the new IE by dgatwood · 2016-01-04 18:28 · Score: 1
  
  And it isn't even Webkit devs fault, it is the shit standards committee for being too slow at making things standards and shit developers for using experimental code. But the biggest part of the issue is web browser vendors having experimental things behind a prefix in the first place! It should only ever work if someone enabled a flag in the advanced settings, like originally planned. (about half of the experimental code is behind a flag, the rest completely open)
  
  The parent might have been modded down as inflammatory, but IMO, this part is basically dead on (albeit a bit too harsh). In my mind, CSS3 is a constantly evolving nightmare of ever-changing proportions, and the vendor prefix thing is just plain nutty. Either it is something that will likely be part of the standard as-is, in which case it shouldn't have a vendor prefix, or it isn't, in which case it shouldn't be enabled by default. The problem is that it takes so many years between when somebody realizes that they need to solve some missing functionality in CSS yesterday and when the standards bodies actually decide that it should be standardized that the train has not only left the station, but has circled the globe a hundred times before they even shout "All aboard!"
  Because it takes so long, you end up with companies who make mobile browsers telling web developers that they basically have to use these vendor-specific tags to work around browser-specific quirks and similar, and then web developers do so, and the non-vendor-prefixed versions don't get added because they aren't part of the spec yet, and by the time they become part of the spec, those web developers have already moved on to other projects, and it works now, so why change it?
  The entire CSS standards process, at least from the perspective of an outsider, seems to be thoroughly bass-ackwards, if you know what I mean. Until that gets straightened out, expect more of this silliness in the future. There are so many parts of the CSS spec that should have been nailed down as final standards years ago, but are still in "Candidate Recommendation" state since 2014. I began starting to use it experimentally two days before it went into that state. Chrome enabled it by default a few months later, as did WebKit.
  So now, two years later, I now have content sold through the iBooks Store (among others) that uses CSS shapes. We're way past the point where this spec is readily mutable, IMO, because people have been using it publicly for about 1.5 years. Yet it is still stuck in a "Candidate Recommendation" state because there's really only one code base that supports the feature (WebKit and Blink hadn't split when work on this spec began, so they don't qualify as two independent implementations, despite cumulatively being used in almost three-quarters of the browsers out there, between Chrome, Safari, Opera, and various other WebKit-based browsers).
  It seems to me, then, that the biggest problem facing the standards process is that neither Microsoft nor Firefox is able to keep up with the rate at which the CSS spec is expanding. Fixing that lag should probably become a priority, as it seems to be a big part of why things take so long to become proper standards. But failing that, the standards process needs to treat WebKit and Blink as separate code bases, even though some of their implementation might have shared a common lineage at one time. At this point, I'm pretty sure they've diverged enough that they should be treated as independent.
  
  --
  Check out my sci-fi/humor trilogy at PatriotsBooks.
27. Re:Safari really is the new IE by Anonymous Coward · 2016-01-04 19:28 · Score: 0
  
  They don't need to, it's just them scratching an itch. The number of people on mobile not using Safari or Chrome is near zero when you consider the billions of mobile devices in the wild. Moz is dead, they killed it years ago becoming the antithesis of why it was created in the first place.
28. Re:Safari really is the new IE by jrumney · 2016-01-04 19:32 · Score: 1
  
  The blame for this lies squarely with the W3C. The CSS3 standard was too slow evolving, and the W3C requested browser makers to prefix any non-finalised attributes with -browsername- to avoid non-standard implementations polluting the global namespace. While a noble goal, the result is that developers who want shiny new features have to use the non-standard prefixes, and with standard browsers on iPhone and Android being WebKit based, and a lot of the latest features being aimed at mobile, we end up with -webkit-* being the new default. It would have been better to introduce a single prefix like -draft- for items already under consideration for the standard, so that all the browsers could use the same prefix from the start.
29. Re:Safari really is the new IE by Flammon · 2016-01-04 23:44 · Score: 1
  
  It's not a matter of laziness, it's a matter of funding.
  
  --
  ayottesoftware.com
30. Re:Safari really is the new IE by Anonymous Coward · 2016-01-05 00:07 · Score: 0
  
  I'm assuming you're trying to blame Apple because the most commonly used prefix is "-webkit-" but vendor prefixes for CSS aren't something unique to the WebKit rendering engine (which is also used by other browsers, like Chrome).
31. Re:Safari really is the new IE by Anonymous Coward · 2016-01-05 02:36 · Score: 0
  
  Webkit gave me polio.
32. Re:Safari really is the new IE by tlhIngan · 2016-01-05 04:23 · 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... 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.
  Well, a lot of the prefixed stuff is actually in the standards, so what Mozilla had to do was merely alias the prefixed version to the proper standard name.
  It's just easier for one browser to fix their parser to handle the aliases than to ask lots of web developers to fix their code. Especially with the usershare of Firefox these days, most people will be more apt to blame Firefox than fix their code.
33. Re:Safari really is the new IE by Anonymous Coward · 2016-01-05 05:43 · Score: 0
  
  While I agree that the W3C has moved at a glacial pace (this time - when it suits them to hurt me, they move quickly enough), I also don't see the problem with the vendor prefixes. I have pages out there where the same property defined half a dozen ways (not counting scripts to enforce behaviors). Who does that hurt? Whatever browser comes along will pick up whichever definition works for them, ignore the rest, and ultimately do something close to what I expect. Is it because I don't choke the pages with 2MB of CSS and 4MB of JS, the slightest hiccup in which utterly destroys any and all usability?
34. Re: Safari really is the new IE by Anonymous Coward · 2016-01-05 06:57 · Score: 0
  
  I'm sick and tired of the bashing of web programmers. We are just working with the tools they give us. Besides it looks like every discipline of programmer uses SO, not just us web guys.
  http://www.midinam.com/b/stack-overflow-most-popular-programming-languages-tags-cm579
35. Re: Safari really is the new IE by Anonymous Coward · 2016-01-05 14:23 · Score: 0
  
  If it's mere eye-candy, the fallback is it doesn't matter if it appears or not.
36. Re:Safari really is the new IE by Tablizer · 2016-01-06 13:06 · Score: 1
  
  adopt their shitty, broken, prefixed CSS, because web developers were too lazy to do things right... Shows just how professional my peers are that they refuse to develop to proper standards
  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 expectation.
  You can claim the organization "should" hire specialists, and thus more people, but they would need a clear reason. The organization doesn't care or know anything about "web standards", they just want sufficient staff to "get it done" without paying too much.
  
  --
  Table-ized A.I.
Surprised it too this long by Carewolf · 2016-01-04 11:30 · Score: 1

This was much more an issue a few years ago when the iPhone was much more dominant on the mobile web.
1. Re:Surprised it too this long by Kjella · 2016-01-04 11:34 · Score: 1
  
  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.
  
  --
  Live today, because you never know what tomorrow brings
2. Re:Surprised it too this long by ArmoredDragon · 2016-01-04 18:29 · Score: 1
  
  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 you're in the middle of the fucking page.
  That, and its text editor for web forms sucks floppy donkey dick.
  But again, the addons...
3. Re:Surprised it too this long by gstoddart · 2016-01-06 06:20 · Score: 1
  
  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
  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.
  
  --
  Lost at C:>. Found at C.
So this is how liberty dies... by Anonymous Coward · 2016-01-04 11:31 · Score: 1

...with thunderous applause.
Yay! Boo? by Anonymous Coward · 2016-01-04 11:43 · 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!
1. Re:Yay! Boo? by malditaenvidia · 2016-01-05 02:48 · Score: 1
  
  I'm still wondering if and when Mozilla will give gecko a good ole rewrite. They've been using the same Netscape engine for 15 years.
The list of prefixed properties by Anubis+IV · 2016-01-04 11:45 · Score: 5, Informative

Here's a list of the "-webkit"-prefixed properties.
https://compat.spec.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.
1. Re:The list of prefixed properties by Anonymous Coward · 2016-01-04 11:48 · Score: 0
  
  +5 informative.
2. Re:The list of prefixed properties by Anonymous Coward · 2016-01-04 11:58 · 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.
3. Re:The list of prefixed properties by amicusNYCL · 2016-01-04 11:59 · Score: 1
  
  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 support the -webkit properties then their browser may appear broken, due to incompetent developers using only those properties (i.e., things only supported by Webkit, just like they used to use things only supported by IE). It's an apt analogy, a de-facto "standard" created by incompetent developers not understanding the things they're using. It's not suggesting anything about the relative merits of the Webkit engine versus any version of IE.
  
  --
  "Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
4. Re:The list of prefixed properties by amicusNYCL · 2016-01-04 12:02 · Score: 1
  
  After re-reading what I wrote, I should clarify: the problem is with website developers, not browser or engine developers.
  
  --
  "Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
5. Re:The list of prefixed properties by Junior+J.+Junior+III · 2016-01-04 12:11 · Score: 4, 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.
  
  --
  You see? You see? Your stupid minds! Stupid! Stupid!
6. Re:The list of prefixed properties by mattack2 · 2016-01-04 12:13 · Score: 1
  
  I don't think anyone is blaming Webkit for anything.
  
  This subthread is:
  http://news.slashdot.org/comme...
  Yes, I know they said Safari specifically, but what they really were meaning to blame was WebKit...
7. Re:The list of prefixed properties by Anonymous Coward · 2016-01-04 12:32 · Score: 0
  
  Meanwhile, Firefox is doing the *exact opposite* of what it's supposed to do: Implementing prefixed properties as if it were a different browser.
  Part of the "standard web" push has always been: Broken sites will sometimes be broken, and it is up to developers, not browser vendors, to fix them.
  Once this change is made, we can definitely blame Firefox for promoting the broken web.
8. Re:The list of prefixed properties by Ichijo · 2016-01-04 12:33 · Score: 1
  
  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.
  
  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 their code.
  
  --
  Any sufficiently unpopular but cohesive argument is indistinguishable from trolling.
9. Re:The list of prefixed properties by Anonymous Coward · 2016-01-04 13:42 · Score: 0
  
  It was broken.
  I didn't work in all major browsers.
  They should not have used it in the first place.
10. Re:The list of prefixed properties by NotInHere · 2016-01-04 13:54 · Score: 1
  
  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 properties in order to render websites properly, webkit based browsers should drop them, and force the developers to switch to the standard version. Of course, one can say the developers are lazy or the how-to copypasta tutorials are outdated, but even if you say the developers are smart, if they want to support an as wide range of users as possible, and if there are more devices with outdated versions of webkit based browsers out than firefox installations, it makes no sense for the developer to support the standard version. Perhaps in five years when all those android devices (I'd guess most of the outdated webkit browsers are AOSP stock browser) are broken and their owners bought new ones they will switch, but thanks to mozilla and google not chosing to not support the vendor specific properties, the switch will happen even later.
11. Re:The list of prefixed properties by Anonymous Coward · 2016-01-04 14:27 · Score: 0
  
  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.
  That's pretty much what happened with IE. The issue was that web standards were too far behind so Netscape and IE had their own implementations of things that didn't exist in web standards. The same thing happened with proprietary extensions (which also includes Flash, ActiveX, etc), created because of the limitations of web standards, when web standards finally caught up nobody wanted to go back and re-write the older software.
  The problem is that standards bodies are notoriously incompetent which leads to sluggish output and they can't keep up pace with innovation.
12. Re:The list of prefixed properties by Anonymous Coward · 2016-01-04 14:47 · Score: 0
  
  The problem lies solely with the developers.
  More with the standards bodies, they are so slow to act.
  
  Is there a compelling reason to not include the yet-to-be-standard prefixes initially, even if no browsers supported them yet?
  Because the "yet-to-be-standard" names (they aren't prefixes in the standard) generally don't exist yet and even when they do the vendor-specific version may not be [vendor-prefix]-[standard name], in fact very often it isn't.
13. Re:The list of prefixed properties by Anonymous Coward · 2016-01-04 15:32 · Score: 0
  
  Mod parent up!
14. Re:The list of prefixed properties by Anonymous Coward · 2016-01-04 16:02 · Score: 0
  
  I think browser developers could all have gone a little bit further and not enabled their proprietary CSS prefixes in production releases by default.
  
  This. This is the correct answer.
  Consider current W3C guidance at http://www.w3.org/TR/CSS/#proprietary-extension:
  "The prefixing requirement allows shipping specialized features in closed environments without conflicting with future additions to standard CSS. The restriction on exposure to open systems is to prevent accidentally causing the public CSS environment to depend on an unstandardized proprietary extensions."
  There are really two groups to shame here. And it's not lazy developers who haven't updated their sites.
  First, browsers were built and made public - released out of closed environments and into the open - built upon WebKit with these proprietary prefixes. That shouldn't have happened. This isn't necessarily WebKit's fault - but I think Apple and Google could have prevented this from becoming the issue that it did, by not releasing non-standard prefixes into the wild. Proprietary features should only have been available with prefixes in "beta" or "canary" builds, and until there was a standard, those features shouldn't have made it into stable builds at all.
  Second, after those prefixed features became available in the wild, lazy and eager developers picked up and built sites using them, and released those sites into the wild. That also should not have happened. The prefixed features are supposed to allow you to get a head start on developing new capabilities before the standard releases... but you're not supposed to release those capabilities until the standard is actually a standard.
  It's not really fair to blame whatever developers may have inherited a site for not updating it to the standard once it became available. That's not when the problem was introduced. Updating a public, released website from a prefixed feature to the standard is just cleaning up a mess created by the original developers who used a feature that wasn't ready for the world wide web, who were in turn enabled by browser-makers who released support before they should have.
15. Re:The list of prefixed properties by roca · 2016-01-04 16:12 · Score: 1
  
  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.
16. Re:The list of prefixed properties by roca · 2016-01-04 16:14 · Score: 1
  
  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).
17. Re:The list of prefixed properties by roca · 2016-01-04 16:27 · Score: 1
  
  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 hook for getting those features standardized. Webkit people hardly did any of that; IIRC they produced a couple of half-baked specs for transitions, animations and transforms, and other vendors had to do most of the work to make those real specs. Many other prefixed features they have made no attempt to standardize at all. This is partly because for a very long time now Apple has declined to pay even one person to work full time on Web standards.
18. Re:The list of prefixed properties by Anonymous Coward · 2016-01-04 16:55 · Score: 0
  
  Simple fix: when Webkit is updated to use the standardized version (once the standard is finalized), remove the -webkit version even from Webkit. Then the lazy colored pencil jockeys have to change their code to keep it working.
  That they didn't disable the pre-standard extensions once the standard took over is the first failing.
  That now the developers of other browsers feel a need to implement Webkit's old pre-standard behaviors because of lazy site designers is the second failing.
19. Re: The list of prefixed properties by Anonymous Coward · 2016-01-04 17:08 · Score: 0
  
  Thank you, actual information... This was just another slashdot fail article
20. Re:The list of prefixed properties by shutdown+-p+now · 2016-01-04 17:17 · Score: 1
  
  At the very least, they could phase them out after the standard is final and all browsers have added non-prefixed versions.
21. Re:The list of prefixed properties by Anonymous Coward · 2016-01-04 18:25 · 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?
22. Re:The list of prefixed properties by jrumney · 2016-01-04 19:39 · Score: 1
  
  First, browsers were built and made public - released out of closed environments and into the open - built upon WebKit with these proprietary prefixes.
  -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.
23. Re:The list of prefixed properties by jrumney · 2016-01-04 19:42 · Score: 1
  
  At the very least, they could phase them out after the standard is final and all browsers have added non-prefixed versions.
  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.
24. Re:The list of prefixed properties by jrumney · 2016-01-04 19:50 · Score: 2
  
  Part of the "standard web" push has always been: Broken sites will sometimes be broken, and it is up to developers, not browser vendors, to fix them.
  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.
25. Re:The list of prefixed properties by dave420 · 2016-01-04 21:02 · Score: 1
  
  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.
26. Re:The list of prefixed properties by ShoulderOfOrion · 2016-01-05 00:04 · Score: 1
  
  Yes. The faster those pages break, the faster they'll be fixed.
27. Re:The list of prefixed properties by Anonymous Coward · 2016-01-05 00:23 · Score: 0
  
  Both Chrome and Firefox have adopted a policy not to use the prefixes anymore some years ago: https://www.chromium.org/blink#vendor-prefixes
  Also, according to http://caniuse.com/#cats=CSS Firefox's support for CSS seems better than Chrome's
28. Re:The list of prefixed properties by Anonymous Coward · 2016-01-05 01:24 · 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.
29. Re:The list of prefixed properties by thinsoldier · 2016-01-05 03:58 · Score: 1
  
  possible reasons: The developer is dead. The business owner is dead but paid for 6 years of hosting up front. The business has no budget for any changes. The business has no idea something is broken. There is no business, some one just put up a page full of dbz gifs on a free hosting account and it got popular. That person has moved on to more interesting things and has no idea some visitors see a problem. They just keep it up because the ads on the site generate about $50 per year.
30. Re:The list of prefixed properties by thinsoldier · 2016-01-05 04:00 · Score: 1
  
  The same thing stopping all browsers from dropping support for Quirks Mode.
31. Re:The list of prefixed properties by shutdown+-p+now · 2016-01-05 07:04 · Score: 1
  
  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".
32. Re:The list of prefixed properties by amicusNYCL · 2016-01-05 09:38 · Score: 1
  
  No, that first comment is blaming...
  
  because web developers were too lazy to do things right
  
  --
  "Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
33. Re:The list of prefixed properties by amicusNYCL · 2016-01-05 09:40 · Score: 1
  
  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.
  
  --
  "Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
34. Re:The list of prefixed properties by Anonymous Coward · 2016-01-05 10:03 · Score: 0
  
  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.
  Because vendor-specific tags are not all of the form [vendor-prefix]-[standards-name], the whole point of vendor-specific tags is that it is not known if they will become standard nor what they might be called. If they were we wouldn't even need vendor-specific tags at all, you could just use the standards-defined name and the browser would use it if it were supported.
firefox caves again by sittingnut · 2016-01-04 11:47 · 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
1. Re:firefox caves again by Lehk228 · 2016-01-04 13:28 · Score: 2
  
  I don't think supporting a number of nonstandard tags originating from a different open source browser engine is hurting anyone's free-dumb
  
  --
  Snowden and Manning are heroes.
No, we don't. by Anonymous Coward · 2016-01-04 11:51 · Score: 0

"we need to add support for a list of frequently-used -webkit prefixed CSS properties & features"
No we do not. We need to adhere to standards and 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.
Its called a Standard for a reason. If Webkit doesn't want to comply, then they can find out how easy it is for people to move on from their product.
1. Re:No, we don't. by amicusNYCL · 2016-01-04 12:08 · Score: 4, 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).
  
  --
  "Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
2. Re:No, we don't. by rudy_wayne · 2016-01-04 13:09 · Score: 4, 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.
3. Re:No, we don't. by Anonymous Coward · 2016-01-04 13:53 · Score: 0
  
  "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."
  Exactly.
4. Re:No, we don't. by Anonymous Coward · 2016-01-04 14:49 · Score: 0
  
  "Guess I'd better use Chrome so it displays properly"
5. Re:No, we don't. by roca · 2016-01-04 16:17 · Score: 2
  
  So you're saying the way to get market share is to tell your users to use a different browser.
6. Re:No, we don't. by roca · 2016-01-04 16:35 · Score: 1
  
  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 almost as constrained by existing content as it would have been had it never been prefixed. That's why Chrome and Firefox don't prefix any new stuff any more. Instead we keep it behind flags so it's never available to all users until standardized.
  Unfortunately Apple doesn't like that message and continues to implement prefixed stuff and promote its use.
7. Re:No, we don't. by Anonymous Coward · 2016-01-04 17:21 · Score: 0
  
  I remember when IE started doing something like this for perf issues caused by browser plugins - it would pop up a notification bar that says "Plugin X is making the browser slow, would you like to disable it?".
  Of course, the very first plugin that was consistently reported in that manner was MS Office document host (to open Office files within the browser). Which lead to a heated spat contest between the two teams inside MS. IE won, though.
8. Re:No, we don't. by jrumney · 2016-01-04 19:57 · Score: 1
  
  A better solution, rather than naming the browsers that the page was "designed for", which would just make users change to one of those browsers when they see the message frequently: "This page contains obsolete experimental tags for features which have since been standardized", and have Webkit based browsers display the message as well.
9. Re:No, we don't. by Anonymous Coward · 2016-01-05 00:46 · Score: 0
  
  Isn't it easier to simply state that every browser should remove support for the prefixed version after it is standardized?(And a pre-announced deprecation period?)
10. Re:No, we don't. by Anonymous Coward · 2016-01-05 08:05 · Score: 0
  
  There is a simple fix -- name and shame. If a non-webkit browser encounters a page with only a -webkit prefix,
  No. I think you are misinterpreting the issue. The presence of the "-webkit" prefix doesn't automatically mean that there's something wrong with the way the page was coded. It may be present to make legitimate use of a feature available in webkit-based browsers. It may be present to work-around a bug in earlier versions of webkit-based browsers. There are legitimate, non-lazy, and revenue-generating reasons to use the -webkit prefix for certain properties. And, many (most?) webpages share the same stylesheet, regardless of the browser viewing it. Of course there will be -webkit prefixes showing up in the CSS.
  A browser has no way of knowing whether or not a page "looks shitty". To "name and shame", as you propose, a browser would need to understand the designers' intent rather than the code they wrote. As we're painfully aware, computers don't work like that.
  But also... Do you really think that a browser feature that "names and shames" would increase adoption and usage of a browser? Firefox, specifically? And do you honestly think that naming and shaming would actually address the issue of poorly-coded webpages?
  I think that would be a death knell for a minority browser like Firefox.
Mozilla is on the way to become forgotten by sanf780 · 2016-01-04 11:59 · Score: 0

I know it is because of the rest of the world. However, what makes Firefox special these days? Mozilla is copying Apple and Google then.
1. Re: Mozilla is on the way to become forgotten by Anonymous Coward · 2016-01-04 12:25 · Score: 0
  
  Yep. But this is a good thing, I no longer need to keep a dusty old copy of Firefox around to test when some random nerd files a bug about something being broken in Firefox. I can just ignore Firefox completely and if it doesn't work, it's Firefox's fault!
  Which leaves my workflow pretty much unchanged: it used to be "develop in Firefox, test in IE until it works, maybe test in Opera if you have time." These days it's just "develop in Chrome, test in IE, no one else matters."
  Bye bye Firefox, your bloated slow corpse will not be missed!
2. Re: Mozilla is on the way to become forgotten by SuperByelich · 2016-01-04 12:36 · Score: 0
  
  I really don't see how Firefox is considered slow. We give our users a choice of IE, Firefox, or Chrome where I work, and I have found Firefox to be peppier than Chrome usually. Although I enjoy using Seamonkey myself overall.
3. Re: Mozilla is on the way to become forgotten by Anonymous Coward · 2016-01-04 13:24 · Score: 0
  
  Oh, gee, I don't know, probably because people have used it? We've taken to calling to "Firefox (Not Responding)" in bug reports because of the frequent freezes.
  I haven't done a benchmark of our web app recently, but the last time I did Firefox was on the order of 10-20 times slower than Chrome. That's why I call it slow.
4. Re: Mozilla is on the way to become forgotten by RebelWebmaster · 2016-01-04 13:42 · Score: 1
  
  Have you filed a bug?
5. Re: Mozilla is on the way to become forgotten by Anonymous Coward · 2016-01-04 13:46 · Score: 0
  
  With who? With ourselves? I think there may be a low priority bug some place about Firefox being stupidly slow, but honestly, Firefox's usage share is already low enough that it's not worth our time to figure out why. (Best guess is V8 JITs a part of a loop that Firefox doesn't/can't.)
  But beyond that? I don't work for Firefox. They can find their own damned bugs.
6. Re: Mozilla is on the way to become forgotten by Anonymous Coward · 2016-01-04 15:17 · Score: 0
  
  Odd. On Unity's performance benchmarks in 2014 and 2015 Firefox outperforms the rest. Why not work the problem with Firefox's built-in profiler or the profiler add-on? It's pretty easy to use.
7. Re:Mozilla is on the way to become forgotten by Anonymous Coward · 2016-01-04 15:56 · Score: 0
  
  Mozilla has become a shithole no pun intended
8. Re: Mozilla is on the way to become forgotten by nnull · 2016-01-04 17:27 · Score: 1
  
  With whom? He's an anonymous coward. They don't file bugs, they just sprout shit out of their ass making spectacular claims without anything to back it.
9. Re: Mozilla is on the way to become forgotten by Anonymous Coward · 2016-01-04 19:56 · Score: 0
  
  I actually have filed bugs with Firefox in the past, but I can tell you why no one bothers after doing it a few times: they just sit there in the "no one has even looked at this" state forever. (I think it's "new" but it may be "unconfirmed." I don't remember what Bugzilla calls it.)
  After a few times of having a bug receive literally no attention, you learn to not bother trying to document the problems and create a test case. It's not worth the effort.
  Besides, like I said, I don't work for Mozilla, and the bug is that the website is slow in Firefox, not that it doesn't work. Given Firefox's market share it is literally not worth the time to track down whatever's going wrong and it certainly isn't worth filing a bug report that'll just be ignored.
10. Re: Mozilla is on the way to become forgotten by tepples · 2016-01-05 07:48 · Score: 1
  
  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! by bogaboga · 2016-01-04 12:00 · Score: 1

"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?
1. Re:Standard cliche-liketalking points, sadly! by Anonymous Coward · 2016-01-04 16:08 · Score: 0
  
  This is ignoring the fact that for years, they have been trying to get web developers to fix their shit, but web developers ignore it. I get not liking Mozilla because it's trendy to bash on them, but not when you start to just ignore broad swaths of reality. Even Microsoft had this problem, as well as Opera. Opera solved it by becoming a Webkit-based browser; Edge solved it by doing what Firefox is doing. But I guess it's no longer fashionable to bash on those companies?
2. Re:Standard cliche-liketalking points, sadly! by roca · 2016-01-04 16:29 · Score: 2
  
  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... by Shados · 2016-01-04 12:07 · Score: 1

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 of both browsers diverge? We need to fall back to hacks and bullshit, without browser specific properties to fallback on. Time to go back to the good old days of browser hacks and browser specific stylesheets?! I can't wait!
1. Re:Oh this is going to be fun... by rudy_wayne · 2016-01-04 13:19 · Score: 1
  
  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 to get everyone to adhere to W3C standards. Now we're headed in the opposite direction again.
2. Re:Oh this is going to be fun... by Anonymous Coward · 2016-01-04 13:59 · Score: 0
  
  "So what's the point of having standards then?"
  The point of having standards is to provide a baseline all browsers meet.
  There is nothing to stop a browser from having 100% compliance to the standards and/in-addition-to non-standard experimental features.
  The w3 is just baseline to meet, nothing more. Else how the hell are things going to evolve?
3. Re:Oh this is going to be fun... by Lunix+Nutcase · 2016-01-04 16:09 · Score: 1
  
  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.
4. Re:Oh this is going to be fun... by roca · 2016-01-04 16:31 · Score: 1
  
  In Firefox Webkit-prefixed properties are mostly just aliases to the corresponding standardized properties. We're adding very little actual new behavior.
5. Re:Oh this is going to be fun... by Todd+Knarr · 2016-01-05 03:37 · Score: 1
  
  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 specifying not just an official browser but an officially-supported version of that browser (oh, the joys of "you can't use any version of IE higher than 6 but you can't use any version of IE lower than 8").
Standards by wonkey_monkey · 2016-01-04 12:29 · Score: 1

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?

--
systemd is Roko's Basilisk.
1. Re:Standards by Anonymous Coward · 2016-01-04 16:23 · Score: 0
  
  They've been showing it for years, but it never makes them look good; it only gets people claiming they don't support useful web features that others (especially Chrome) have adopted (or had from the start). Frankly Mozilla has spent the better part of a decade fighting this crap, and it's time for them to move on. There are more important battles to fight. It's better at this point just to standardize these non-standard features, since they're not going anywhere.
What's the point of standards then? by danomac · 2016-01-04 12:30 · Score: 1

If other engines wind up having to implement other vendor's prefixes anyhow, why even bother with a standards body? This seems rather dubious...
Yay! More customized scrollbars! by Anonymous Coward · 2016-01-04 13:09 · Score: 0

Just what I was looking for, unclickable or even fully hidden scrollbars!
QuirksWebkit? by Anonymous Coward · 2016-01-04 13:33 · Score: 0

See this is what happens when people use old tools for HTML. A LOT of this blame can be thrown directly at Adobe for no longer producing perpetual license versions of their tools, which means whatever was in CS6 is what people are using. Nobody wants to pay monthly to Adobe to keep their webpages up to date. People will just rather let the page suffer code rot.
1. Re:QuirksWebkit? by tepples · 2016-01-05 09:58 · Score: 1
  
  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?
So what? by Anonymous Coward · 2016-01-04 14:12 · Score: 0

As long as the browser implements the wc3 specs 100%, so what if there are non standard things added in? Thats a Good Thing.
The ideal world is where all browsers implement the wc3 spec 100% and each one adds in there own new ideas as they see fit. Its one major way they have of differentiating themselves from each other - all of them competing, the coolest/best/whatever ideas that developers consistently use and the public demands on their sites eventually getting integrated into the next most standards rev, and so things evolve as they should.
Being 100% compliant in no way implies 'exclusively' and 'limited to'. How is the web supposed to evolve otherwise?
No big deal, mostly just aliases by dwheeler · 2016-01-04 16:22 · Score: 3, Insightful

I looked at the list, and it's really no big deal. Firefox will just add support for some aliases for standard names, so that existing websites that use "-webkit" prefixes will "just work" today. That's good for users, and it doesn't mean the 'death of standards' or anything like that. It's reasonable to ask people to use the standard names going *forward*. However, it takes a long time for older sites to update, and they rarely update completely correctly. This decision means that Firefox users will have a good experience looking at other sites.

--
- David A. Wheeler (see my Secure Programming HOWTO)
1. Re:No big deal, mostly just aliases by shutdown+-p+now · 2016-01-04 17:19 · Score: 0
  
  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.
2. Re:No big deal, mostly just aliases by Anonymous Coward · 2016-01-05 03:41 · Score: 0
  
  Sort of the same way that -moz-* works, then.
3. Re:No big deal, mostly just aliases by shutdown+-p+now · 2016-01-05 07:03 · Score: 1
  
  Does -moz- work in other browsers?
What the Fuck by Anonymous Coward · 2016-01-04 18:34 · Score: 0

And yet they still can't be bothered to get Firefox to comply with HTML 4.0.
1. Re:What the Fuck by tepples · 2016-01-05 09:59 · Score: 1
  
  HTML4 has been superseded by HTML5. To which specific non-conformances do you refer?
We're talking about CSS, right? by Anonymous Coward · 2016-01-04 18:59 · Score: 0

CSS. Not html5. Not JavaScript. The presentational side of the web. I call bullshit on the whole thing. There is not a significant or even visible minority of the web that is functionally broken by prefixed CSS. So a gradient or transition here or there doesn't fire - who the fuck cares? Other than flexbox, I can't think of a single structural CSS implementation that is prefixed. So we're talking about fluff. And Mozilla sucks for what they're doing, which will make the very practice they're grousing about have even less reason stop.
Or stop making websites with all that frippery by Anonymous Coward · 2016-01-05 00:38 · Score: 0

HTML should be just that, HTML. No dynamic this, not DOM that, no cascading javascript AJAXery. Display information for me please, that's all.
1. Re:Or stop making websites with all that frippery by Anonymous Coward · 2016-01-05 03:22 · Score: 0
  
  That ship sailed a looong time ago, old man.
Servo by tepples · 2016-01-05 10:03 · Score: 1

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.
Fuck HTML5 by Anonymous Coward · 2016-01-05 10:38 · Score: 0

HTML3.2 FOR LIIIIIFE!
Devs should be beaten over the head by PJ6 · 2016-01-06 03:13 · Score: 1

and told they're not making any more changes until they fix a major, longstanding bug..