6 ms·

> Turned out, Google wasn’t concerned about your websites at all. It was more concerned about its own product performance, Google Chrome Mobile. As a web devel

by untog 9y ago

> Turned out, Google wasn’t concerned about your websites at all. It was more concerned about its own product performance, Google Chrome Mobile. As a web developer, I see this attitude a lot and it annoys me immensely. Another way of phrasing it: Google is putting users first, ahead of developers. This is as it should be. "your" website exists to serve users, if you're doing a bad job at it then maybe it's an opportunity for self reflection. Janky scrolling behaviour on mobile has been a problem for a long time. Apple also implemented non-standard behaviour for years to avoid it. You should almost never be listening to scroll events in a non-passive way. 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. This is proven by the article itself: the change was made in February of this year. Do you remember the internet breaking that day, and all of us rushing to update our event listeners? No, me neither. Did Chrome really break when the web when absolutely nothing broke?

kllrnohj 9y ago
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?
pier25 9y ago
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.
Sylos 9y ago
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.
LoSboccacc 9y ago
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.
- Spivak 9y ago
  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.
  - jhasse 9y ago
    > 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.
  - LoSboccacc 9y ago
    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.
    - Spivak 9y ago
      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).
masklinn 9y ago
> 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.
- untog 9y ago
  > 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.
Bartweiss 9y ago
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.
- Ajedi32 9y ago
  > 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 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-dev https://groups.google.com/a/chromium.org/forum/#!forum/blink...
Manishearth 9y ago
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.
deleted 9y ago
[deleted]

by untog 9y ago

kllrnohj 9y ago

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?

pier25 9y ago

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.

Sylos 9y ago

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.

LoSboccacc 9y ago

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.

Spivak 9y ago
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.
- jhasse 9y ago
  > 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.
- LoSboccacc 9y ago
  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.
  - Spivak 9y ago
    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).

masklinn 9y ago

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

untog 9y ago
> 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.

Bartweiss 9y ago

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.

Ajedi32 9y ago
> 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 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-dev https://groups.google.com/a/chromium.org/forum/#!forum/blink...

Manishearth 9y ago

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.

deleted 9y ago

[deleted]