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

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

From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
Date: Wed, 22 Feb 2017 02:47:41 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-281552372-1487731660-sysbot+gh@w3.org>
> From a practical standpoint I'm not sure if it's that common to do a
 multi-column infinite scroll.

I don't think it is common, but as long as it is possible, any 
in-browser solution has to know how to deal with it. Site-specific 
JavaScript solutions can work from the assumption that this particular
 site doesn't have this problems, but browser engines have to deal 
with the general case.

> For backgrounds I think this is actually a case where the author 
likely does not want to make the background jump when 
above-the-viewport content jumps -- since the sensical use case for a 
background here is some sort of repeating pattern.

That seems fairly likely, but here too it's not the only possibility 
in the general case, and it is tricky to infer intent.

> This doesn't quite make sense to me. If feed story X, which is off 
screen, currently has contain:strict and an filter/blur applied to it 
the browser can choose not to layout X while it's off screen.

My assumption was that this had been laid out once, frozen in place 
with a hand-calculated height, and you would gray/blur it out until 
you've had the chance to update it (or to verify that no update is 
needed). If you assume it has never been laid out at all, then yes, 
that doesn't quite work. my assumption was that there would not be 
such a thing in browser engines as elements that have not been laid 
out. All elements are laid out, so you can always show them if you 
want to, but as your js does, we'd turn on strict containment with a 
manual size to turn off updating the size of the element and relaying 
out its surrounding when off screen, and flip that when getting in / 
near the viewport. The costlier thing isn't really (in most cases) to 
relayout the element itself, but its surroundings when its size 

So if you sroll too fast before JS has had a chance to catch up and 
unfreeze an element, you'd still have something to paint (and if you 
didn't have an up to date layout, the engine can quickly do one within
 the existing size), and I was suggesting graying/bluring it out (plus
 overflow: hidden or overflow:clip) to make it clear to a user who is 
accidentally seeing it that it's expected for this element to look 
weird, and that it will get back to normal real soon.

GitHub Notification of comment by frivoal
Please view or discuss this issue at 
 using your GitHub account
Received on Wednesday, 22 February 2017 02:47:48 UTC

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