- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 28 Aug 2019 16:54:30 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `aspect-ratio-only boxes should be able to size to grid container`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: aspect-ratio-only boxes should be able to size to grid container<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/4228<br> <dael> fantasai: I think case where we found as we audited sizing rules. When we don't have definite available space, could provide grid-container size. Currently undefined or infinity. You have an item and an auto-sized grid track. Tries for max-content. Row doesn't have size so when we try and size we say infinite. Maybe we should provide grid size<br> <dael> fantasai: This would be change to way grid works<br> <dael> fantasai: How it finds the max-content size of an item in a row that is not fixed<br> <dael> jensimmons: When fantasai talked this through I liked what she proposed. Image should fill what's available. I was +1 to it<br> <florian> s/You have white-space: pre/You have white-space: pre-wrap/<br> <dael> fantasai: When trying to find max-content width and item needs to know height to resolve it then we need ot take into account height to find width. If we don't have one we try and shift to container size. IN grid container case the contaier is the grid area and if it's auto it doesn't have a size we can pass to algo<br> <AmeliaBR> q+<br> <dael> fantasai: So it ends up as inifintiy or undef and not a number.<br> <dael> fantasai: Proposa: in case of grid if row doesn't have a size you can use then you look up to grid container and use that<br> <astearns> zakim, open queue<br> <Zakim> ok, astearns, the speaker queue is open<br> <fantasai> https://drafts.csswg.org/css-sizing-3/#intrinsic-sizes<br> <myles> s/cripple them/use them only in a UI context/<br> <dael> fantasai: Applies in sizing of image with aspect ratios ^<br> <AmeliaBR> q+<br> <dael> Rossen_: Every time we try and make a dependency all layout algo become difficult. All layouts are def to operate on a single container item relationship basis. BReaking that rule and defining this layout type you will be defining a size based on an ancestor things become difficult<br> <myles> s/person spoofing/person "spoofing" system UI design/<br> <dael> Rossen_: We have made that exception before like orthogonal flows, but it is implemented as an exception to find the ancestor with a defined size. This is an exception and usually ugly at cost of artifacts.<br> <dael> Rossen_: You can always create cases where this becomes inefficient<br> <myles> s/would expose as/would probably expose as/<br> <dael> fantasai: Not looking at ancestor, grid row looks to grid container<br> <dael> Rossen_: But you have a grid inside a grid insiade a grid. Always a case where these exceptions fall and people think it's just a few above. Already one ancestor, why not more?<br> <dael> fantasai: It's not an ancestor. It's grid container<br> <dael> Rossen_: Layout PoV we're going through area that's used for layout considerations for resolving positioning. We are proposing to escape layout area and go to container which is next level ancestor of grid item<br> <dael> fantasai: Containing block corrisponds to actual box in other layout cases. Grid has abstract containing block as a sub part of grid. When using that to calc max content when itself isn't fixed we look at grid container sizing property. I think this is reasonable to do<br> <dael> Rossen_: In case where grid container has undefined size?<br> <dael> fantasai: No change to that case<br> <dael> Rossen_: But the point I was trying to make is grid container could be a grid item. It needs to go to its container grid<br> <dael> fantasai: Not doing that for writing modes so not doing for aspect ratio. If the grid container was height 100% and 400px it's fixed and would pass down to its children. It's child to parent but in grid there's a structure which is the grid. Grid is containing block of grid child but doesn't look at containing block to get a size<br> <dael> fantasai: Proposal is to say that even though parent is not containing block it takes a size from it when it needs a size<br> <dael> Rossen_: That's my point<br> <dael> fantasai: You're arguing we'd walk up chain, but we're doing child to parent directly<br> <dael> Rossen_: Once we add thigns like subgrid we'll have to keep that use case in mind and continue thinking bout this exception case where we defer to a different level. You will face that case all the time if we make an exception now<br> <dael> Rossen_: Would prefer if we're using the grid item's type contribution. I think it was second proposal? max-content size from available space<br> <dael> fantasai: That's what we're trying to define here<br> <dael> AmeliaBR: Might be helpful to look at breaking this algo to more detail. It's true that there are very simple cases wher eyou gave explicit grid-row height and you want grid items with aspect ratios to fill explicit dimension and auto-size in other and that should happen automatically<br> <dael> AmeliaBR: Rossen_ concern about what if you have rows dependent on parents and other children and how to define non-circular I think there will be using the existing grid text and text with flexbox and aspect ratio where we redefined...<br> <dael> AmeliaBR: I suspect we have necessary sub algo defined<br> <dael> fantasai: We do this for the orthogonal dimension. If the avialable space when sizing a grid item is taken from row with constraint it looks to grid container. Just not with aspect ratio<br> <dael> fantasai: For aspect ratio we need to take from inline dimension and that's not designed<br> <fantasai> https://drafts.csswg.org/css-grid-1/#algo-overview<br> <fantasai> "If calculating the layout of a grid item in this step depends on the available space in the block axis, assume the available space that it would have if any row with a definite max track sizing function had that size and all other rows were infinite. If both the grid container and all tracks have definite sizes, also apply align-content to find the final effective size of any gaps spanned by such items;<br> <fantasai> otherwise ignore the effects of track alignment in this estimation."<br> <fantasai> We need to do this in the inline dimension<br> <dael> AmeliaBR: Are you able to break down where i all existing layout algo there would need to be new rule? THat would make it less scary<br> <dael> fantasai: Yes, right now depends on available space in block axis. We would address it in this section (link above) if you don't have definite row we can provide by grid container<br> <dael> fantasai: If people want to look more we can come back<br> <dael> Rossen_: Own this more thinking, it's a fundemental thing and careful what to select<br> <dael> Rossen_: My pushback is based on working on a lot of it and making such an exception requires adding a lot more information that needs to be kept track of and that complicates layout algo tremendiously<br> <dael> Rossen_: Need to see if this manifests as super common use case with adverse effects or if this is something most people won't hit.<br> <AmeliaBR> s/redefined.../redefined how aspect ratio boxes worked because initial behavior wasn't useful./<br> <dael> Rossen_: I'd prefer to let others comment, esp other people impl layout<br> <dael> Rossen_: That work for you fantasai ?<br> <AmeliaBR> ack me<br> <fantasai> wfm<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4228#issuecomment-525831011 using your GitHub account
Received on Wednesday, 28 August 2019 16:54:32 UTC