I'm a bit surprised browsers do in-scrolling events: browser performance has been under heavy optimization for years and switching to "panning mode" with no events emitted while scrolling would seem like a splendid candidate for something like a "Turbo mode". Alternatively the change to disable events could've plausibly been written as a fix to usability bugs caused by in-scroll hover events.<p>This is because I'm not sure if, since -94 or so, I've seen a single case where event handling while scrolling would have actually added to browsing usability at all. It consistently creates two kinds of problems: first laggy scrolling as elements with heavy events handlers get focused and unfocused and secondly crazy behaviour when on-hover menus will open abruptly while scrolling and the state of the page ends up messed up when the scrolling stops.<p>It makes sense to scroll like it happens in mobile devices: the input events drive the scrolling only and the page just pans around as long as the fingers move on the screen, and the browser effectively returns to interactive mode when the scrolling stops.
Hmm. I can only see a minor performance increase in Chrome. Safari is dead smooth regardless of the option selected, and Firefox is pretty hanky even with events disabled.<p>This is probably a useful technique for specific situations where scroll events are causing issues, but it's definitely something that should generally be handled by the browser, rather than the developer. Still, Safari's awesome performance suggests that there's room for improvement in browsers' handling of this situation.
Considering I was just googling about, wondering why I had such awful scrolling FPS, seeing this prompted me to just make a userscript [1]. Just load it up in greasemonkey. Tested in FF2x.<p>Works on all pages, just adds the pointer-hover: none to the body element. Using modified code from the article. Quite useful, really. I'm surprised at how often I subconsciously guide my cursor away from content while scrolling pages to prevent hover effects popping off.<p>[1] <a href="http://userscripts.org/scripts/show/185715" rel="nofollow">http://userscripts.org/scripts/show/185715</a>
I've noticed Safari delaying hover events while scrolling, presumably for this same reason. It seems like something the browser should handle. Individual sites shouldn't be forced to hack around the issue.
Perhaps this is a dumb question because I don't know much about browser performance optimization, but why is a modern browser unable to animate one hover effect over the currently pointed to box at 60 fps as you scroll down the page? That does not sound particularly computationally intensive.
It looks to me like Firefox already does this, only better - when scrolling stops, it not only reënables hover, but also applies its effects immediately. With the JS solution, anything the cursor lands on will only hover once the mouse moves again.
So this is from HTML5Rocks, I go to their site and in the footer. "This is a Google Project"<p>I want to subscribe to their articles, Twitter? No, Google Plus? No,... they only have RSS.<p>Now I wish there was a Google product that works with RSS.
why is hover detection slow? i know browser devs are way behind the times... but three things:<p>* the browser can implement this optimisation<p>* spatial partitioning maybe is a much better general solution. the 2d aabb case is extrememly fast and can handle checks against 10000s of boxes per ms with good memory layout<p>* stagger checks across frames if more optimisation is needed when there are say, 100000s boxes to test (maybe? i'm skeptical even that would be especially slow)
Not much of an effect on my site's timeline (Chrome 31), maybe even a little worse than not having it.<p>Perhaps the demo "paints" a false picture considering that most sites don't have the same simplicity/symmetry of hoverable elements.