- 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