HN2new | past | comments | ask | show | jobs | submitlogin

It does! In fact, this is the reason sticky positioning exists. See the original proposal at http://lists.w3.org/Archives/Public/www-style/2012Jun/0627.h...:

Many web sites have elements that alternate between being in-flow and being position:fixed, depending on the user's scroll position. This is often done for elements in a sidebar that the page author desires to be always available as the user scrolls, but which slot into a space on the page when scrolled to the top. It can also be done for table headers which remain visible after the top of the table has been scrolled off- screen.

Lots of sites, such as news.google.com (the "Top Stories" sidebar) and yelp.com (the search results map), use scroll event listeners in JavaScript to achive this effect. However, browsers are increasingly moving towards scrolling implementations that make use of hardware acceleration to improve performance, for example by leveraging the GPU, and doing scrolling on a thread other than the main UI thread.

In this situation, browsers may use fast scrolling but fire scroll events asynchronously, which will result in rendering glitches on pages that update element positions from JavaScript via scroll events. Alternatively, the browser may fall into a slow scrolling mode when scroll events are listened for; this impacts the perceived quality of the browser's scrolling. To address this problem, common scrolling behaviors like this should be exposed declaratively, through CSS.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: