If our element would be content sized, we can give it a narrow intrinsic-size width the browser will still give us the natural width upon first layout.We can still use contain-intrinsic-size, however, to reserve a conservative "place-holder" for a few purposes: IntersectionObservers and ResizeObservers, however, guarantee that we can know the bounding boxes of the elements cheaply (post layout) and use the sizing info they provide to reserve space should the system decide to stop laying out elements (setting their height to 0) when they leave the viewport. I'd dismissed contain-intrinsic-size for use in the base stylesheet because it's impossible to know widths and heights to reserve. After sleeping on the problem, a better answer presented itself: leave the flow alone and use IntersectionObservers and ResizeObservers to reserve vertical space using CSS's new contain-intrinsic-size property once elements have been laid out. This also smelled, but it got me playing with ResizeObservers. What should happen if an element in the flow changes its width or height in reaction to the browser lazy-loading content? And what if the scroll direction is up, rather than down?įor a mercifully brief while I also played with absolutely positioning elements on reveal and moving them later. This was conceptually hacky and I couldn't get it working well. One alternative is a "place-keeper" element that grows with rendered content to keep elements that eventually disappear from perturbing scroll position. Much of this was pointed out (if obliquely) in a PR to the ECMAScript spec. Jumping "far" into a document via link or quick scroll could still be jittery.This would not be improved by the previous solution if many articles had been marked visible. Layouts caused by resize can be particularly slow on large documents as they can cause all text flows to need recalculation.Because content-visibility: visible was never removed, layouts inevitably grew slower as more and more content was unfurled by scrolling.The last post on avoiding rendering work for content out of the viewport with content-visibility included a partial solution for how to prevent jumpy scrollbars. Code below has been updated to reflect this. Assuming the browser will calculate a width for an once finally laid out, there's no harm in reserving a narrow but tall place-holder. Contra previous advice, you absolutely should do that, even if you don't know natural widths yet. Update, The Second: After holiday explorations, it turns out that one can, indeed, use contain-intrinsic-size on elements that aren't laid out yet. Update: After hitting a bug related to initial rendering on Android, I've updated the code here and in the snippet to be resilient to browsers deciding (wrongly) to skip rendering the first in the document.
0 kommentar(er)
