4 ms·

The web is the only platform aside from perhaps some assembly languages that is that stable and that ubiquitous. Websites have always been a "write and forget"

The web is the only platform aside from perhaps some assembly languages that is that stable and that ubiquitous. Websites have always been a "write and forget" deal; there never was supposed to be any feedback loop of developers fixing breaking changes. This is why old websites from 1998 still work in your browser. This is why there are piles and piles of cruft within browsers and web standards for making sure old behavior that folks may rely on continues to work. The commitment to stability on the web is astounding; I don't see anyone changing that any time soon. Google should not be breaking things just for its users; because its users are affected when they break things too. That's the problem with Javascript. When Javascript breaks, it's not the developers who get the error, it's users, who have no idea what it means and no way to fix it. This is not the case with e.g. compiled languages; there's no extremely strict guarantee your code will still compile on a new release. That said, Google did push this through the right channels (https://github.com/WICG/interventions/issues/35 https://github.com/WICG/interventions/issues/35 , https://github.com/w3c/touch-events/issues/74 https://github.com/w3c/touch-events/issues/74 , https://github.com/WICG/interventions/issues/18 https://github.com/WICG/interventions/issues/18 ) and it seemed like browser vendors were in agreement that this wouldn't be a problem. This is something that does happen; browser vendors "unship" or break functionality after discussing it sometimes. So while I'm not convinced Chrome stepped out of line here, breaking sites absolutely is not putting users first.

untog 9y ago
> This is why old websites from 1998 still work in your browser. They won't if they use a <blink> tag, for example. The problem is that if we freeze the entire web and demand 100% backwards compatibility, we also can't ever move forwards. This scroll event change is a positive in 99% of cases - should a web site built in 1998 really hold that back? There's no absolute in "putting users first" there - you're either putting the minority user looking at an old site first, or you're putting the majority looking at newer sites first. Maybe it wouldn't be the worst thing in the world to introduce an "archival" mode in a browser. Nothing published on the web is ever truly broken because it's very well documented what it should do. So we can turn those features back on when viewing an older site that requires them - blinking text and all - while still moving forward on the platform people use every day.
- baybal2 9y ago
  I don't get why those guy stand against explicit versioning in JS for the sake of forward compatibility, yet it only leads to no IE6 era JS heavy website running in modern Chrome. In few years time, it will lead to the same thing happening to Chrome JS ecosystem
- katastic 9y ago
  > we also can't ever move forwards. There is a thing called Forward Compatibility. Not everything old has to die to move forward. On our OpenGL 4.x videocards still run OpenGL 1.x. And no, fixed function pipeline of 1.x isn't anything like the modern shader pipeline. (Sidenote: many cards that were designed in the 3.x era and nVidia backported 4.x support into their older cards which is amazing to me.) >Maybe it wouldn't be the worst thing in the world to introduce an "archival" mode in a browser. Internet Explorer already did that.
  - untog 9y ago
    > Not everything old has to die to move forward. But we're talking about a very specific example, where the best option for the vast majority of users was to change default behaviour. There is no "passive event listener still implements active event listener API" equivalent here. You have to make a choice.
- Manishearth 9y ago
  <blink> was never standard cross-browser > There's no absolute in "putting users first" there - you're either putting the minority user looking at an old site first, or you're putting the majority looking at newer sites first. I'm not talking about old sites; I'm talking about current sites. The old sites were illustrative examples of the backwards compatibility in the web. The point is that the web has always been a platform you can deploy code to without needing to tend to it later. This post is an example of it breaking a current site.
katastic 9y ago
>The web is the only platform aside from perhaps some assembly languages that is that stable and that ubiquitous. The first part I agree with. The second, I don't understand. .NET and Java are way more universal than assembly language unless you really split hairs and pretend "any byte code generated by a machine that ends up as assembly = assembly."
cesarb 9y ago
> This is why old websites from 1998 still work in your browser. Unless their navigation interface used a Java applet.
- baybal2 9y ago
  yet, a few years old website is most likely broken now because it runs JS code with half of its API interacting functions being incompatible with current browsers

untog 9y ago

> This is why old websites from 1998 still work in your browser. They won't if they use a <blink> tag, for example. The problem is that if we freeze the entire web and demand 100% backwards compatibility, we also can't ever move forwards. This scroll event change is a positive in 99% of cases - should a web site built in 1998 really hold that back? There's no absolute in "putting users first" there - you're either putting the minority user looking at an old site first, or you're putting the majority looking at newer sites first. Maybe it wouldn't be the worst thing in the world to introduce an "archival" mode in a browser. Nothing published on the web is ever truly broken because it's very well documented what it should do. So we can turn those features back on when viewing an older site that requires them - blinking text and all - while still moving forward on the platform people use every day.

baybal2 9y ago
I don't get why those guy stand against explicit versioning in JS for the sake of forward compatibility, yet it only leads to no IE6 era JS heavy website running in modern Chrome. In few years time, it will lead to the same thing happening to Chrome JS ecosystem
katastic 9y ago
> we also can't ever move forwards. There is a thing called Forward Compatibility. Not everything old has to die to move forward. On our OpenGL 4.x videocards still run OpenGL 1.x. And no, fixed function pipeline of 1.x isn't anything like the modern shader pipeline. (Sidenote: many cards that were designed in the 3.x era and nVidia backported 4.x support into their older cards which is amazing to me.) >Maybe it wouldn't be the worst thing in the world to introduce an "archival" mode in a browser. Internet Explorer already did that.
- untog 9y ago
  > Not everything old has to die to move forward. But we're talking about a very specific example, where the best option for the vast majority of users was to change default behaviour. There is no "passive event listener still implements active event listener API" equivalent here. You have to make a choice.
Manishearth 9y ago
<blink> was never standard cross-browser > There's no absolute in "putting users first" there - you're either putting the minority user looking at an old site first, or you're putting the majority looking at newer sites first. I'm not talking about old sites; I'm talking about current sites. The old sites were illustrative examples of the backwards compatibility in the web. The point is that the web has always been a platform you can deploy code to without needing to tend to it later. This post is an example of it breaking a current site.

katastic 9y ago

>The web is the only platform aside from perhaps some assembly languages that is that stable and that ubiquitous. The first part I agree with. The second, I don't understand. .NET and Java are way more universal than assembly language unless you really split hairs and pretend "any byte code generated by a machine that ends up as assembly = assembly."

cesarb 9y ago

> This is why old websites from 1998 still work in your browser. Unless their navigation interface used a Java applet.

baybal2 9y ago
yet, a few years old website is most likely broken now because it runs JS code with half of its API interacting functions being incompatible with current browsers