Slashdot Mirror

← Back to Stories (view on slashdot.org)

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

Posted by samzenpus on 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."

75 of 132 comments (clear)

  1. Safari really is the new IE by Anonymous Coward · · 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 · · 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 · · 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 · · 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).

    4. Re:Safari really is the new IE by Shados · · 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...

    5. Re:Safari really is the new IE by Anonymous Coward · · 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.

    6. Re:Safari really is the new IE by arglebargle_xiv · · 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".

    7. Re:Safari really is the new IE by DanJ_UK · · 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
    8. Re:Safari really is the new IE by DanJ_UK · · 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
    9. Re:Safari really is the new IE by kangsterizer · · 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.

    10. Re:Safari really is the new IE by edremy · · Score: 1

      Do it with the first generation Mac Portable. Maximum impact

      --
      "Seven Deadly Sins? I thought it was a to-do list!"
    11. Re:Safari really is the new IE by davester666 · · 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!
    12. Re:Safari really is the new IE by roca · · 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.

    13. Re:Safari really is the new IE by ArmoredDragon · · 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.

    14. Re:Safari really is the new IE by dgatwood · · 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.

    15. Re:Safari really is the new IE by jrumney · · 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.

    16. Re:Safari really is the new IE by Flammon · · Score: 1

      It's not a matter of laziness, it's a matter of funding.

      --
      ayottesoftware.com
    17. Re:Safari really is the new IE by tlhIngan · · 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.

    18. Re:Safari really is the new IE by Tablizer · · 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.
  2. Surprised it too this long by Carewolf · · 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 · · 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 · · 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 · · 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.
  3. So this is how liberty dies... by Anonymous Coward · · Score: 1

    ...with thunderous applause.

  4. Yay! Boo? by Anonymous Coward · · 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 · · 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.

  5. The list of prefixed properties by Anubis+IV · · 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 · · 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.

    2. Re:The list of prefixed properties by amicusNYCL · · 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
    3. Re:The list of prefixed properties by amicusNYCL · · 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
    4. Re:The list of prefixed properties by Junior+J.+Junior+III · · 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!
    5. Re:The list of prefixed properties by mattack2 · · 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...

    6. Re:The list of prefixed properties by Ichijo · · 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.
    7. Re:The list of prefixed properties by NotInHere · · 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.

    8. Re:The list of prefixed properties by roca · · 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.

    9. Re:The list of prefixed properties by roca · · 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).

    10. Re:The list of prefixed properties by roca · · 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.

    11. Re:The list of prefixed properties by shutdown+-p+now · · Score: 1

      At the very least, they could phase them out after the standard is final and all browsers have added non-prefixed versions.

    12. Re:The list of prefixed properties by Anonymous Coward · · 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?

    13. Re:The list of prefixed properties by jrumney · · 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.

    14. Re:The list of prefixed properties by jrumney · · 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.

    15. Re:The list of prefixed properties by jrumney · · 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.

    16. Re:The list of prefixed properties by dave420 · · 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.

    17. Re:The list of prefixed properties by ShoulderOfOrion · · Score: 1

      Yes. The faster those pages break, the faster they'll be fixed.

    18. Re:The list of prefixed properties by Anonymous Coward · · 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.

    19. Re:The list of prefixed properties by thinsoldier · · 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.

    20. Re:The list of prefixed properties by thinsoldier · · Score: 1

      The same thing stopping all browsers from dropping support for Quirks Mode.

    21. Re:The list of prefixed properties by shutdown+-p+now · · 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".

    22. Re:The list of prefixed properties by amicusNYCL · · 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
    23. Re:The list of prefixed properties by amicusNYCL · · 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
  6. firefox caves again by sittingnut · · 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 · · 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.
  7. Standard cliche-liketalking points, sadly! by bogaboga · · 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 roca · · 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.

  8. Oh this is going to be fun... by Shados · · 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 · · 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 Lunix+Nutcase · · 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.

    3. Re:Oh this is going to be fun... by roca · · Score: 1

      In Firefox Webkit-prefixed properties are mostly just aliases to the corresponding standardized properties. We're adding very little actual new behavior.

    4. Re:Oh this is going to be fun... by Todd+Knarr · · 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").

  9. Re:No, we don't. by amicusNYCL · · 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
  10. Standards by wonkey_monkey · · 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.
  11. What's the point of standards then? by danomac · · 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...

  12. Re:No, we don't. by rudy_wayne · · 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.

  13. Re: Mozilla is on the way to become forgotten by RebelWebmaster · · Score: 1

    Have you filed a bug?

  14. Re:No, we don't. by roca · · Score: 2

    So you're saying the way to get market share is to tell your users to use a different browser.

  15. No big deal, mostly just aliases by dwheeler · · 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 · · Score: 1

      Does -moz- work in other browsers?

  16. Re:No, we don't. by roca · · 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.

  17. Re: Mozilla is on the way to become forgotten by nnull · · 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.

  18. Re:No, we don't. by jrumney · · 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.

  19. Re: Mozilla is on the way to become forgotten by tepples · · 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.

  20. Re:QuirksWebkit? by tepples · · 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?

  21. Re:What the Fuck by tepples · · Score: 1

    HTML4 has been superseded by HTML5. To which specific non-conformances do you refer?

  22. Servo by tepples · · 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.

  23. Devs should be beaten over the head by PJ6 · · Score: 1

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