3 ms·
I'd hardly call this feature pointless. Scroll events, with cancellation support, have been a thing for well over a decade. This solves a very real problem of h
by connor4312 9y ago
I'd hardly call this feature pointless. Scroll events, with cancellation support, have been a thing for well over a decade. This solves a very real problem of having to execute single-threaded application code that blocks scrolling. Particularly on mobile where resources are constrained and scrolling is smooth, this is a big problem.
Having developers hint to the browser that the event will not be cancelled solves it very simply. Far more simply and predictably than any kind of static analysis could.
- syberspace 9y agoYou seem to be misunderstanding my point. I'm definitely all for passive listeners. But I am very much against putting more workarounds for shitty developers directly into the browser.
- onion2k 9y agoThe change we're discussing here is something that the developer will need to explicitly add to their code; By marking a touch or wheel listener as passive, the developer is promising the handler won't call preventDefault to disable scrolling. Shitty developers who are lazy aren't likely to add that to their code if it 'works' without it. They are shitty after all. They won't care about a janky scroll on their webpage. Heck, they probably won't even test different ways of scrolling. Therefore it's fair to think this change is for awesome developers who test things and find that there's a problem, and need a way to fix it.
- syberspace 9y agoyes, passive listeners are great. What I don't want in my browser is a static analyzing tool as the first comment I answered to suggested
- Piskvorrr 9y agoWell...that's a bummer, as modern JS virtual machines used in browsers all use some sort of predictive code path model, and such static analysis is an integral part of this.