Hacker News Reader

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/w3c/touch-events/issues/74 , 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.

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

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

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

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

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

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

> This is why old websites from 1998 still work in your browser.

Unless their navigation interface used a Java applet.

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

> Another way of phrasing it: Google is putting users first, ahead of developers.

For the most part, Google is putting its developers ahead of your developers. They could have e.g. jitted scroll handlers to bail out of passive, but did not, and instead broke all active scroll listeners.

> The vast majority of times scroll listening is used, a passive listener is the correct implementation and just wasn't available when the code was written.

And once again minorities get to visit the mass grave through no fault of their own.

> They could have e.g. jitted scroll handlers to bail out of passive

Could they? From my understanding passive listeners do not stop execution, so even if a specific handler wants to bail out at run time it will already be too late to do so.

> once again minorities get to visit the mass grave

You don't think you're being a touch hyperbolic here? You can still use a non-passive listener if you want to, you just have to opt into it. Defaults should serve the majority use cases, that's the whole point of having them.

I can appreciate this outlook, but I still worry about "just wasn't available when the code was written".

Code rot is very real for websites, and I worry that in the quest to do things 'right' Chrome is undervaluing the incremental harm done by every change. I don't think this action broke the web, but I'm wary of the idea that breaking changes can be casually blamed on the people who didn't update fast enough.

Change is bad, inasmuch as it makes new work for maintainers and harms user experience where maintenance isn't prompt. It's often necessary, but there ought to be an open discussion about timeframes and impact before a change happens. In this case, the discussion largely happened after the fact.

> there ought to be an open discussion about timeframes and impact before a change happens

There was. In fact, there's a whole GitHub project dedicated to discussing proposed interventions like these: https://github.com/WICG/interventions

All interventions also get posted on the blink-dev mailing list before they are implemented: https://groups.google.com/a/chromium.org/forum/#!forum/blink...

The real problem here is the fact that active listeners are still a problem to begin with.

It'd be absolutely insane if a native app did not get first crack at all input events. This is how they all work (iOS, Android, Windows - take your pick), and the mere existence of a touch/scroll listener is never a problem.

But on the web simply having a scroll listener is such a massive performance issue that it's worth introducing not just a new API to get events after they've happened, but to then make that the default? Why not just fix the performance problem instead of hacking and slashing around it?

No, it's not to serve users. Users don't want broken webpages either. It's to make their own browser look faster at the expense of webpage authors. Because users will blame webpage authors for their webpage being broken. Would they know that they could have this same page unbroken with slightly worse performance, no one would choose the better performance.

Sure, there's something to be said about webpage authors getting off their butts quicker, if their webpage is actually broken, rather than just not quite as fast as it could be, but the majority of webpages are not actively maintained. Chrome is simply breaking those. With only 8 months of a transitional period, there's no two sides to this argument. What they've done is unresponsible in every way.

The problem is that it wasn't only the scroll event but also the mousemove event.

I maintain a library of interactive widgets for an education product with a lot of dragging and dropping and I was hit hard by this.

I understand the reasons behind this, and I agree something thad to be done, but Google is making it difficult for devs to sympathise with the unilateral intervention. It's not the what, it's the how.

that's a load of bollocks. if google wants a better web, he needs to work toward better standards. implementing a vendor specific api by fiat with broken detection is what fucked the web in the first place!

same with apple - "now we'll ignore user-scalable=no and screw every responsive webapp out there"

instead of user punishing badly behaved application, vendor are indiscriminately breaking well behaved apps whether they're doing the right thing or not (ie. apps that use em and thus respect user accessibility settings)

this leaves both developers AND users with a sub-par browser experience - like all canvas games out there now get zoomed on double taps, an animation which is often enough to stress the device gpu so much that the browser crashes.

I'm all for improving the web, but there are ways that work and there's this force feeding crap to developer without tough and foresight, and we as a community need to call what's good and what's crap for what it is.

> same with apple - "now we'll ignore user-scalable=no and screw every responsive webapp out there"

Maybe because 90% of responsive webapps would be better implemented as standard html websites which would improve performance and help preserving battery.

90% according to whom?

According to me. Maybe even higher than 90%. There are a few applications where you need a single-page app. Google Docs is an example or websites that integrate a messenger (e.g. Facebook). For the rest, SPA are a waste of resources and work worse with slow internet. Reddit is a prime example. UX has deteriorated since they switched to loading everything dynamically (again, only me as a source) with no good reason to implement it that way.

what the hell are you on about now? responsive web doesn't mean hulking javascript monsters automatically.

responsive web also doesnt mean youd need to disable zooming

Fine, I'll call out that it's good.

I mean honestly you should have seen the writing on the wall with user-scalable: it inhibited the user from doing something they wanted to do, it hurt accessibility, it made websites imperceptibly inconsistent, and there isn't a good way of asking the user if they would like to disable zoom.

Shut the W3C down, call Mozilla, close the Acid pages, now Spivak calls out what's good for the web.

You know what's good for the web? Standards. Standards that are thoughtful and consistent.

Since you want to be pedantic the user-scalable and user-zoom viewport tags aren't an official standard. They currently exist in the CSS Device Adaptation Module Level 1 Working Draft.

Here are the comments on the property:

> Authors should not suppress (with user-zoom: fixed) or limit (with max-zoom) the ability of users to resize a document, as this causes accessibility and usability issues.

> There may be specific use cases where preventing users from zooming may be appropriate, such as map applications – where custom zoom functionality is handled via scripting. However, in general this practice should be avoided.

> Most user agents now allow users to always zoom, regardless of any restrictions specified by web content – either by default, or as a setting/option (which may however not be immediately apparent to users).

> and there isn't a good way of asking the user if they would like to disable zoom.

Whats wrong with "This page wants disable zooming. Allow?"?

That would fix the canvas web game usecase.