- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 04 Aug 2017 10:27:41 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Orthogonal Flow Constraint: viewport vs scroller`, and agreed to the following resolutions: * `RESOLVED: Add "size of nearest fixed scrollport" to the list of things you clamp orthogonal flow inline sizes to, editting the CR.` <details><summary>The full IRC log of that discussion</summary> <Rossen> Topic: Orthogonal Flow Constraint: viewport vs scroller<br> <Rossen> github topic: https://github.com/w3c/csswg-drafts/issues/1391<br> <TabAtkins> fantasai: We resolved to use the nearest scrollport height for orthogonal flow fallback height.<br> <TabAtkins> fantasai: But that can be auto. ICB is always fixed; we want this to be fixed as well.<br> <dbaron> Should it be the nearest scrollport that's non-auto height?<br> <astearns> nearest scrollable definite-height ancestor?<br> <astearns> dang, dbaron beat me to it<br> <TabAtkins> Rossen: When I was working on this, the logic I added was to keep looking for the nearest ancestor that imposes a fixed height or scroller, and if scroller is height:auto I think I keep going up.<br> <TabAtkins> Rossen: You can go figure out the viewport size, but that doesn't buy you much.<br> <TabAtkins> fantasai: I think you want it to be a size you can calc without doing layout.<br> <TabAtkins> Rossen: Which is doable if you find a fixed ancestor.<br> <TabAtkins> fantasai: If you look for fixed size and subtract mbp, you run into problems we saw before with stretch, where you get so much mbp you're zero size.<br> <TabAtkins> fantasai: Also, our goal if you're doing autosize is to not make it larger than what you can see in one screenful; goal is to fit a line of text they can comfortably read. Nearest fixed container might be larger than the viewport.<br> <fantasai> Rossen: But then you'd have that problem with other things<br> <fantasai> TabAtkins: The other things are intended to scroll vertically<br> <TabAtkins> fantasai: It's very important that a line length is less than the size of the viewport, so you don't scroll back and forth.<br> <TabAtkins> fantasai: So nearest fixed container might violate that.<br> <TabAtkins> fantasai: This is why we used viewport instead of some random number.<br> <fantasai> TabAtkins: If it's as big or smaller than the viewport, then even if it's not perfectly nice, the user can sroll it into place and be able to read comfotably<br> <TabAtkins> fremy: You're preventing people from using transforms. They might want large initial size, then scale it down. You'd prevent that.<br> <fantasai> TabAtkins: for transforms all bets are off<br> <fantasai> TabAtkins: We could clamp to smaller of the scrollport and the viewport<br> <TabAtkins> Rossen: Using smaller of fixed-height ancestor or viewport sounds okay.<br> <TabAtkins> fantasai: If your parent is fixed size, we already clamp by that.<br> <TabAtkins> fantasai: But when we don't have a fixed size, we don't want to look up thru multiple layers of auto and find a size bigger than auto.<br> <TabAtkins> Proposal: orthogonal flow fallback height is min(100vh, nearest fixed-size scrollport ancestor's height), no caring about mbp or anything.<br> <TabAtkins> + logical swap for other ordering.<br> <TabAtkins> + available size of immediate container, which normally controls size<br> <fantasai> min(100vh, nearest fixed-size scrollport, available size)<br> <TabAtkins> fantasai: Looking at spec, you choose smaller of "containing block size" and "ICB size", and the issue/discussion was about replacing ICB size.<br> <fantasai> current CR is min(100vh, available size), previous resolution was min(available size, nearest scrollport)<br> <TabAtkins> TabAtkins: So just adding one more bullet to that list, for nearest fixed scrollport.<br> <TabAtkins> RESOLVED: Add "size of nearest fixed scrollport" to the list of things you clamp orthogonal flow inline sizes to, editting the CR.<br> <TabAtkins> <br type=lunch dur=1hr><br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1391#issuecomment-320215251 using your GitHub account
Received on Friday, 4 August 2017 10:36:46 UTC