- From: bmaurer via GitHub <sysbot+gh@w3.org>
- Date: Thu, 16 Feb 2017 18:42:42 +0000
- To: public-css-archive@w3.org
bmaurer has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-contain-1] Make It easier to use contain: size in cases where the size is unknown == At Facebook we've been investigating the extent to which we could use CSS containment. Ideally we'd like to provide as much containment as possible on major elements -- like newsfeed stories -- so that we can enable browser optimizations. However, we've found that one major challenge is that it is often difficult to provide size containment. For example, let's say there's a newsfeed story that is well above the viewport. If we could provide contain: size on that story we could enable a number of browser optimizations. Specifically the spec mentions that when size is contained browsers can potentially: > When the style or contents of a descendant of the containing element is changed, calculating what part of the DOM tree is "dirtied" and might need to be re-laid out can stop at the containing element. > When laying out the page, if the containing element is off-screen or obscured, the layout of its contents can be delayed or done at a lower priority. However, feed stories can change height. For example, we have a longpoll that updates comments and could insert new comments in an existing feed story. A user might also interact with a feed story (eg by writing their own comment, thus changing the size). It can be very difficult to track down all the code paths that can modify the story. In addition, if the story is out of the viewport we don't really care what it's height is. Ideally we'd want behavior along the lines of: (1) If an element is out of the viewport, cache the size and set the height and width to the cached size, then add contain: size (2) when the element comes in the viewport, remove the size cache and recompute the size. If the size has changed and the element is above the scrollTop, adjust scrollTop to remove the jank of scrolling. I've put together a jsfiddle simulating this idea: https://jsfiddle.net/zLr7o6bt/ This page has a set of feed-like stories. Every 100 ms, 1% of the stories have their content changed (and their text made red for debugability). There is an intersection observer that watches for content going in and out of the viewport. When content goes out it sets contain:size on the element using the existing height, when it comes in that is dropped. On most browsers scrolling will cause the page to shift around as the height of elements above the viewport changes. But if you use chrome canary which has scroll anchoring it's relatively smooth -- when the size of an element above the viewport is changed the browser changes the scrolltop to compensate. ### Why do this in the platform? 1) The browser has a better sense of how far outside of the viewport layout should be done to enable smooth scrolling. 2) Scroll anchoring is hard to get right from userspace. 3) With the polyfill if you scroll too fast you'll see the browser paint elements which used the cached size and will overflow the container. With a browser implementation you would get the same behavior as if you hadn't been using contain ### What would the spec look like I'm imagining you'd say something like: ``` .card { contain: strict; width: 500 px; height: auto; contain: content height-auto; height-auto-default: 200px; } ``` By adding height-auto to contain it says to the browser that if the card is outside of the viewport, it's height can be cached from a previous layout, or if it was never laid out a default height of 200px can be used. At any time of the browser's choosing -- but at minimum if any part of the element is in the viewport (using the cached or default size) or if javascript specifically queries the height of the element -- the browser may choose to make the normal height calculation. If it does so, and the bottom of the element was below the scrollTop of its scroll parent then the parent element is adjusted by the change in height. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1043 using your GitHub account
Received on Thursday, 16 February 2017 18:42:49 UTC