2 ms·
I've worked with -ms-scroll-snap-points. It's very limited and an anti-pattern for separation of concerns. You're putting logic of how scrolling should behave i
by msoad 12y ago
I've worked with -ms-scroll-snap-points. It's very limited and an anti-pattern for separation of concerns. You're putting logic of how scrolling should behave in CSS. It's becoming very difficult to do more than just simple logic with this. I've tried updating -ms-scroll-snap-points property on the fly but it didn't work that well.
We need better scroll APIs for sure, but in DOM JavaScript API not in CSS
- taeric 12y agoI'm curious on why logic of how scrolling should behave should not be in CSS. If the concerns are DOM = Data and CSS = presentation. JS would be Dynamic on either of those. That is, if you can statically state your scroll points, it would seem that CSS would make sense for that.
- WorldWideWayne 12y agoIt's nothing new. Scrolling behavior logic has been in CSS since forever with all of the different overflow properties.
- pcwalton 12y ago> We need better scroll APIs for sure, but in DOM JavaScript API not in CSS If it's in CSS, the browser can fundamentally optimize it better. DOM APIs have to run on the JS thread ("main thread") and contend with GC pauses, image decoding (in some browsers), layout (in all mainstream browsers), painting (in most browsers) and so forth. However, if it's in CSS, it can be proxied out to the compositor thread, which runs very little. This makes a huge difference in responsiveness.