- From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
- Date: Wed, 22 Feb 2017 02:47:41 +0000
- To: public-css-archive@w3.org
> From a practical standpoint I'm not sure if it's that common to do a multi-column infinite scroll. I don't think it is common, but as long as it is possible, any in-browser solution has to know how to deal with it. Site-specific JavaScript solutions can work from the assumption that this particular site doesn't have this problems, but browser engines have to deal with the general case. > For backgrounds I think this is actually a case where the author likely does not want to make the background jump when above-the-viewport content jumps -- since the sensical use case for a background here is some sort of repeating pattern. That seems fairly likely, but here too it's not the only possibility in the general case, and it is tricky to infer intent. > This doesn't quite make sense to me. If feed story X, which is off screen, currently has contain:strict and an filter/blur applied to it the browser can choose not to layout X while it's off screen. My assumption was that this had been laid out once, frozen in place with a hand-calculated height, and you would gray/blur it out until you've had the chance to update it (or to verify that no update is needed). If you assume it has never been laid out at all, then yes, that doesn't quite work. my assumption was that there would not be such a thing in browser engines as elements that have not been laid out. All elements are laid out, so you can always show them if you want to, but as your js does, we'd turn on strict containment with a manual size to turn off updating the size of the element and relaying out its surrounding when off screen, and flip that when getting in / near the viewport. The costlier thing isn't really (in most cases) to relayout the element itself, but its surroundings when its size changes. So if you sroll too fast before JS has had a chance to catch up and unfreeze an element, you'd still have something to paint (and if you didn't have an up to date layout, the engine can quickly do one within the existing size), and I was suggesting graying/bluring it out (plus overflow: hidden or overflow:clip) to make it clear to a user who is accidentally seeing it that it's expected for this element to look weird, and that it will get back to normal real soon. -- GitHub Notification of comment by frivoal Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1043#issuecomment-281552372 using your GitHub account
Received on Wednesday, 22 February 2017 02:47:48 UTC