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

I'm a bit torn on this.

**On the plus side:**

[1d size containment](https://github.com/w3c/csswg-drafts/issues/1031)
 has been proposed separately for a different reason, but maybe that 
will work out here as well.

I'm wondering: without explicitly adding to containment the concept of
 caching sizes when you're off screen, maybe  browser engines could 
still be smart enough to know that if you have: 1d size containment + 
layout containment + scroll anchoring, then you don't need to 
recompute the height when you're off screen, as it would not affect 
the apparent scroll position anyway.

**On the negative side:**
Regardless of whether we do it as I say above, or with an explicit 
value, this only seems to make sense if you're assuming 1 column 
layout. I you have 2 or more columns of content in parallel, the 
relative height of previous things matters in each column. As the 
height of things above the viewport change in one column and not in 
the other, things in the viewport that used to be side by side no 
longer are. With traditional layout computation, that may be bad UX, 
but it isn't inherently hard. When you add this ability to not update 
the height when outside the viewport though, you get some kind of 
weird stateful layout, where depending on which path you've scrolled 
through at what time, you may have updated the layout of different 
elements, resulting in a different global state.

**putting it back together:**
Thinking of it some more, the problems that happen with multiple 
columns of content also happen with a single column, if you've got non
 uniform backgrounds or borders, so we're stuck with this kind of 
statefull layout problem. I suspect that's not going to be popular 
with implementers.

It's starting to look as if the polifyl you're using is a pretty good 
approach after all. Looking back at the downsides:
* >  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.

This would actually be a problem with browsers too, because painting /
 compositing / scrolling happens on a different thread than layout, so
 you could still get in situations where you've scrolled faster than 
you were able to relayout. Granted, that would probably less often 
since we'd get JS out of the loop, but it could still happen. So maybe
 from the UX point of view, it could be preferable (for example) to do
 it in JS, and in addition to size containment, also apply a `filter: 
grayscale(100%) blur(5px)` to off screen elements, that you remove 
only when you're done setting them back to auto size. That way, if the
 user scrolls so fast that they get some none-updated elements into 
the viewport they'll look non-updated rather than overflowing and 
broken. And with `contain:paint`, the browser would optimize that away
 for off screen things anyway.

* > 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
 
  &
  > Scroll anchoring is hard to get right from userspace.

Hopefully, in due time, all browsers will have scroll anchoring, so 
this downside will go away.

* > The browser has a better sense of how far outside of the viewport 
layout should be done to enable smooth scrolling.

Due to the problem of multiple columns or non uniform backgrounds or 
borders, and because layout and scrolling typically aren't 
synchronized, I don't think that's actually true, and the browser will
 struggle as well.



-- 
GitHub Notification of comment by frivoal
Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/1043#issuecomment-281277097
 using your GitHub account

Received on Tuesday, 21 February 2017 08:32:03 UTC