7 ms·

I don't understand: If there is a spec that says, hey, this prefixed stuff will get removed sooner or later, use the non prefixed variant along with the prefixe

• univerio 11y ago
  Because the users would complain that Apple or Google broke all these websites with the latest update. Backwards compatibility is tricky.
  • toomanythings2 11y ago
    Backwards compatibility doesn't apply here because, by definition, prefixed properties are supposed to go away and the intention of them is to go away. Only dumb developers continue to use such things once a standard property is available so it's their own fault if they don't do that.
    • takeda 11y ago
      Totally agree. IMO they probably would be better off if they left the original behavior, but every time prefixes are used (whether they work or not) browser would just display a watermark in a corner saying that website is using experimental features that are not standardized yet and could appear broken.
      • takeda 11y ago
        I see this is not a popular opinion, could someone at least mention why? An experimental feature is experimental, it might change it might disappear. I think my suggestion is still better than not being able to see its effects by default. A note in the corner also is less annoying than a message popping up when page is about to be viewed.
    • jsprogrammer 11y ago
      The problem with prefixes is that they are supposed to go away. Why do I want stuff that is "supposed to go away" in my code? I'd rather just "not have it in the first place".
      • toomanythings2 11y ago
        You are right. The vendor prefixes are there to introduce new properties that they hope will be implemented in the standard. All those prefixes can change or disappear altogether and without notice. However, this is a way for a browser vendor to test their code in real life. If it fails, they can change the prefix and try again till they get it right. You can't do that once it's standardized. In fact, there are a number of properties that have been implemented incorrectly and still exist today but were eventually fixed in the non-prefixed property. But a developer is to then remove the prefixed property. Not complain about it and blame others for their decision to use it in the first place.
      • coldtea 11y ago
        >Why do I want stuff that is "supposed to go away" in my code? Because you want the functionality that it gives.
        • lysp 11y ago
          That's his point - The functionality should be there in the first place.
          • coldtea 11y ago
            Then he wouldn't have said "I'd rather just "not have it in the first place".
        • jsprogrammer 11y ago
          But without prefixes, I wouldn't need to change anything and could still get the functionality.
          • 11y ago
    • cpeterso 11y ago
      Mozilla has reluctantly begun implementing some -webkit- prefixed APIs and CSS properties (i.e. mapping the prefixed name to the standard unprefixed name) to improve compatibility for mobile websites that assume all mobile browsers are some version of WebKit (including Blink). https://bugzilla.mozilla.org/show_bug.cgi?id=1170774 https://bugzilla.mozilla.org/show_bug.cgi?id=1170774
      • digi_owl 11y ago
        Meaning we have come full circle, only being barely better off as webkit is open source...
      • kalleboo 11y ago
        Aaaand we're back to the good old days of "Mozilla 3.0 (compatible; IE)"
        • kuschku 11y ago
          Firefox Mobile has many cases where it even uses Chrome's UA already.
    • will_hughes 11y ago
      > Only dumb developers continue to use such things once a standard property is available There are a LOT of sites which once they get deployed, almost never get touched again. Either because they have no developers available or due to lack of time/interest. So, what was a good way to achieve X at the time the site was developed is no longer be great five years later.
      • ryandrake 11y ago
        If they can't be bothered to fix their code, then those web sites surely wouldn't mind if browsers eventually started popping up a dialog that says "This web site content may be abandoned or no longer supported by [domain]. Proceed with caution!" upon loading outdated code. That would be one way to handle this and direct user complaints to the right party.
        • endgame 11y ago
          I like that approach: http://www.daemonology.net/blog/2016-04-11-write-opinionated-workarounds.html http://www.daemonology.net/blog/2016-04-11-write-opinionated...
          • will_hughes 11y ago
            There's a big difference between changing compiler tools, and showing stuff to end users who likely have no idea what the hell is going on, and we'll just have more of these[1] situations. (Even if it's a fake comment, it's close enough to real responses from people) Most of the sites in the world are run by people who have little to no understanding of the internet beyond the most basic "series of tubes" aspect. If you're going to break something because you don't want to support backwards-compatibility any longer, break it in the least obnoxious way possible. [1] https://i.imgur.com/SL88Z6g.jpg https://i.imgur.com/SL88Z6g.jpg
            • ryandrake 11y ago
              There will always be non-technical users. The trick is to focus their frustration on the parties they should be frustrated with. Take for instance those screens browsers present when you try to visit a website with dodgy security. These are universally awful user experiences and users likely have no idea what the hell is going on, but browsers do it anyway for the users' benefit and for the long-term health of the web. When users encounter these warnings, they don't think "Oh jeez, Firefox sucks so much" they think "I better get the hell out of here and not visit this web site anymore". I'd argue that more strict adherence to standards and rejection of old, deprecated code is better for users because it's better for the long-term health of the web as a platform. The effort spent maintaining a mess of unnecessary backwards-compatibility (particularly with things meant to be temporary from the start) is effort that would be better spent providing actual value for users in the form of quality improvements, better performance, and features.
    • MikeHolman 11y ago
      That is the ideal world. But a lot of web developers don't do this. And who is going to get blamed when websites that used to work (and work in other browsers!) suddenly stop working after a browser update?
    • coldtea 11y ago
      >Backwards compatibility doesn't apply here because, by definition, prefixed properties are supposed to go away and the intention of them is to go away. Only it doesn't work like that. Once it's there and used, it's there -- and whether it was meant or not, nobody gives a flying duck about.
    • pcwalton 11y ago
      That's all well and good, but in practice what happens is that the users of browsers complain and then switch to another browser because sites are broken.
    • cperciva 11y ago
      This comment was flagged away, probably due to the reference to "dumb developers". Please don't use such language here; it's inappropriate and not welcome on Hacker News. I've vouched for your comment because I think you were making an important point, but please choose your words more carefully in the future.
  • MichaelGG 11y ago
    Why aren't these properties hidden under a feature/config flag or otherwise gated?
    • quanticle 11y ago
      That's exactly the policy that Webkit is adopting from now on.
  • rictic 11y ago
    It looks like there may be better options for experimenting without the risk of getting locked in. I believe that Chrome is trying something along these lines: https://infrequently.org/2015/08/doing-science-on-the-web/ https://infrequently.org/2015/08/doing-science-on-the-web/ More reading: https://groups.google.com/a/chromium.org/forum/#!topic/experimentation-dev/GsPtuFt8XqA https://groups.google.com/a/chromium.org/forum/#!topic/exper...
• aiiane 11y ago
  Harm reduction. As it turns out, it's really easy to stick your fingers in your ears and go "the spec says X so tough cookies", but in the real world decisions tend to be made based on actual user impact, and the impact of killing the prefixed variant for some things would be rather large because there are a lot of developers that made decisions which didn't match the intent of the spec.
  • TeMPOraL 11y ago
    The flip side of this approach is that this way bugs get enshrined in standards and stay with us forever. As the apocryphal story story goes, by the time the author of Make discovered his coding error he already had ~10 users, so he decided not to bother fixing it - and now, 39 years later, we still have to be careful to use only TABs and not spaces before commands in our Makefiles.
    • paulddraper 11y ago
      That story would have been better if it had a real mistake.
• Ericson2314 11y ago
  It's sad. Finally, after ~2 decades of the Web (very analogous to OpenGL btw), we've finally learned that having layer 1 (browser or driver) and layer 2 (graphics program, website) both hack around mistakes in the other leads to developer pain and chaos. So we all wish we had been strict as you propose from day 1. Now for better or worse, people still don't want to suddenly "break" the things that were actually broken all along. But thankfully we also don't want to add any more leniency with new features. So this is basically an example of the browsers declaring "no new hacks" and promising to slowly clean up the hacks that exist.
  • kuschku 11y ago
    And then in a few years someone will say "web browser are too complicated and strict, let's build something better for beginners on top of it"
    • mynewtb 11y ago
      You Won't Believe How Fast Your Computer Is With This New 'Native' Technology.
    • Ericson2314 11y ago
      Yeah I'd love to see the Vulkan approach taken.