Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Firefox The Internet

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

RoccamOccam writes: Mozilla developers have discussed a plan to implement support for a subset of non-standard CSS prefixes used in WebKit. Mozilla developer Daniel Holbert says: "A good chunk of the web today (and particularly the mobile web) effectively relies on -webkit prefixed CSS properties & features. We wish we lived in a world where web content always included standards-based fallback (or at least multiple-vendor-prefixed fallback), but alas, we do not live in that world. To be successful at rendering the web as it exists, we need to add support for a list of frequently-used -webkit prefixed CSS properties & features."
This discussion has been archived. No new comments can be posted.

Firefox Will Support Non-Standard CSS For WebKit Compatibility

Comments Filter:
  • by Anonymous Coward on Monday January 04, 2016 @07:28PM (#51238387)

    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.

    • by Anonymous Coward

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

      • by Anonymous Coward

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

      • 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".
    • by Anonymous Coward

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

    • by Shados ( 741919 )

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

    • by Anonymous Coward

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

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

    • by jrumney ( 197329 )
      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 -
    • by Flammon ( 4726 )
      It's not a matter of laziness, it's a matter of funding.
    • by tlhIngan ( 30335 )

      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,

    • by Tablizer ( 95088 )

      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

  • This was much more an issue a few years ago when the iPhone was much more dominant on the mobile web.

    • by Kjella ( 173770 )

      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.

      • 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

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

  • by Anonymous Coward

    ...with thunderous applause.

  • by Anonymous Coward

    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!

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

  • by Anubis IV ( 1279820 ) on Monday January 04, 2016 @07:45PM (#51238501)

    Here's a list of the "-webkit"-prefixed properties.

    https://compat.spec.whatwg.org... [whatwg.org]

    At least at an initial glance, it seems to me that the criticisms about WebKit being "the new IE" are generally misplaced, since most of the listed properties are aliases for the standard versions of those properties. I.e. WebKit was the first rendering engine to support those properties, but it did so while the web standard was being finalized, so it prefixed those properties, as it is supposed to. Lazy developers implemented those properties using the prefixed property, since that's all that was available at the time, but didn't go back to fix the code afterwards when the standard was finalized.

    Long story short, WebKit did things exactly as they were supposed to. They implemented a proposed standard, prefixed it as they were supposed to, and then implemented the standard version later while maintaining support for the prefixed version. Really, the only ones who aren't following best practices are the developers too lazy to update their code to work with the current standards, but if we're going to blame WebKit for being too quick to support proposals, then we may as well blame the other rendering engines for being so slow that the lazy devs couldn't use their prefixed versions. Two sides of the same coin. It's no surprise that one side blames the other.

    • by Anonymous Coward on Monday January 04, 2016 @07:58PM (#51238601)

      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.

    • I don't think anyone is blaming Webkit for anything. The problem lies solely with the developers.

      Lazy developers implemented those properties using the prefixed property, since that's all that was available at the time, but didn't go back to fix the code afterwards when the standard was finalized.

      Is there a compelling reason to not include the yet-to-be-standard prefixes initially, even if no browsers supported them yet? It seems like any competent developer from the beginning of CSS3 should have included any vendor prefixes as well as the standard, and then they wouldn't have had to go back and "fix" anything, just remove the cruft.

      At least at an initial glance, it seems to me that the criticisms about WebKit being "the new IE" are generally misplaced

      It's a good analogy, in the sense that if a browser vendor doesn't sup

      • After re-reading what I wrote, I should clarify: the problem is with website developers, not browser or engine developers.

        • by Anonymous Coward

          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?

      • I don't think anyone is blaming Webkit for anything.

        This subthread is:
        http://news.slashdot.org/comme... [slashdot.org]
        Yes, I know they said Safari specifically, but what they really were meaning to blame was WebKit...

      • by dave420 ( 699308 )

        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.

    • by Junior J. Junior III ( 192702 ) on Monday January 04, 2016 @08:11PM (#51238693) Homepage

      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.

      • I don't think its bad if browsers add some vendor specific features, so that developers can test them. This is one way the standard can be tested on a wide range of devices. It is far better to say "According to our metrics, this feature is enabled on 2000 websites with a total of 20 million users, so it seems to work great and fill a niche" than to say "Well yes it can be implemented but lets first do some bikeshedding".

        I agree, one shouldn't blame mozilla. Instead of them having to add the -webkit CSS pro

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

        • by jrumney ( 197329 )

          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.

    • by Ichijo ( 607641 )

      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

      • 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.
    • by dwheeler ( 321049 ) on Tuesday January 05, 2016 @12:22AM (#51239793) Homepage Journal
      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.
      • 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.

    • by roca ( 43122 )

      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

    • by Anonymous Coward

      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.

  • 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
       

    • by Lehk228 ( 705449 )
      I don't think supporting a number of nonstandard tags originating from a different open source browser engine is hurting anyone's free-dumb
  • 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.
  • "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?

    • by roca ( 43122 )

      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.

  • 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

    • 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

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

    • by roca ( 43122 )

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

      • Then it should be just as easy for Webkit to make the standardized properties aliases for the Webkit-prefixed ones. And then Webkit-prefixed stuff can be dropped and the site maintainers and devs have an easier time of it as they can just use the standardized properties and not worry about whether it's rendering on Webkit or not. Updating the stylesheets ought to be straightforward property-name replacement. I really really don't want to go back to the bad old days of browser detection and companies specify

  • 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?

  • If other engines wind up having to implement other vendor's prefixes anyhow, why even bother with a standards body? This seems rather dubious...

  • and told they're not making any more changes until they fix a major, longstanding bug. [mozilla.org].

Is it possible that software is not like anything else, that it is meant to be discarded: that the whole point is to always see it as a soap bubble?

Working...