W3C home > Mailing lists > Public > public-css-archive@w3.org > February 2017

[csswg-drafts] [css-contain-1] Make It easier to use contain: size in cases where the size is unknown

From: bmaurer via GitHub <sysbot+gh@w3.org>
Date: Thu, 16 Feb 2017 18:42:42 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-208209686-1487270561-sysbot+gh@w3.org>
bmaurer has just created a new issue for 

== [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:


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 

Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/1043 using your GitHub 
Received on Thursday, 16 February 2017 18:42:49 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:08 UTC