Yes it might've worked by the standard.I understand that.
And honestly I'm having a bit of difficulty imagining how a website could legitimately use this sort of eventListener and not be a prime example of sloppy coding. It's been this way for over half a year and I haven't noticed anything broken by it. Yeah, I'm finding it a little difficult to get worked up about this. If a later version changes the location of a menu item or icon, the company has to invest in "retraining". They managed to avoid even accidentally picking up bits of new info along the way. Yet they know nothing more about how things work than when they started. If you've ever worked in an office setting, you will have seen tons of users who have used the same systems for years. They will go to such extraordinary lengths to avoid learning, that actually learning would have been far less effort. In fact most of them really hate learning. You can't count on them to figure out new things. You can only count on users to find the most ingenious ways to break things. It's like a smudge on the screen, except users would probably figure out that not all web sites started having smudges in a fixed position.ĭuring your first week of working in this industry, you will quickly learn one thing: never, ever depend on users to figure out anything. All websites and web apps that did any sort of draggable UI (sliders, maps, reorderable lists, even slide-in panels) were affected and essentially broken by this change. This was not backward compatible change by any means. Basically, Chrome broke half of user websites, the ones that were relying on touch/scroll events being cancellable, at the benefit of winning some performance for websites that were not yet aware of this optional optimization. They call it " an intervention." Now, this is a terrible thing to do. That's why on February 1, 2017, they made all top-level event listeners passive by default. It was more concerned about its own product performance, Google Chrome Mobile. It's a win-win, right? Turned out, Google wasn't concerned about your websites at all. Old websites continue to work (slow, as before), and new websites have an option to be made faster at the cost of an additional feature check and one more option.
The gist of it: if you mark onscroll/ontouch event listener as passive, Mobile Google can scroll your page faster (let's not go into details, but that's how things are). Chrome team proposed the API change to add passive option because it allowed them to speed up scrolling on mobile websites. In 2016, Google came along and decided that this API was not extensible enough. So the story goes like this: there's a widely-used piece of DOM API called "addEventListener." Almost every web site or web app that does anything dynamic with JS probably depends on this method in some way.
Chrome based browsers 2017 ditd software#
Reader Tablizer writes (edited and condensed): The Chrome team "broke the web" to make Chrome perform better, according to Nikita Prokopov, a software engineer.
0 kommentar(er)
