- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 29 Apr 2020 15:45:26 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Clarify that contain:size affects track sizing`. <details><summary>The full IRC log of that discussion</summary> <myles> Topic: Clarify that contain:size affects track sizing<br> <Rossen_> github: https://github.com/w3c/csswg-drafts/issues/4931<br> <myles> florian: mats palmgren and I were having a long discussion about what the spec currently means. We are coming down to agreeing what's desired, but not what the actual words in the spec say. contain:size says that when you try to figure out the size of an element or its intrinsic size, you treat it as if it has no descendents, then you do layout. He was wondering does this mean you do track sizing of grid with our without descendents?<br> <myles> florian: AFAIAC, Track sizing for layout, it's not intrinsic sizing. If you have no children, then you have no implicit tracks, then you look at explicit tracks, then you know the grid, and you lay out.<br> <iank_> q+<br> <myles> florian: But if there is intrinsic sizing of the tracks, should this be canceled out?<br> <Rossen_> q?<br> <myles> florian: Earlier, number of tracks is not described as being sizing<br> <myles> florian: The conclusion is that no, you don't create implicit tracks for the grid, because that would change the size of the grid. But when you do a layout, you calculate the track size property. We are now agreeing now. But we are disagreeing on whether the words in the spec say that<br> <myles> florian: If your track sizes have a fixed min number of pixels, then you incorporate it, and do a full layout.<br> <myles> oriol: Currently in chromium, the contents are taken into account. They are placed in the grid and they can create implicit tracks.<br> <myles> oriol: This defeats the point of having size containment, since now the size of teh grid container can depend on contents. But the dependency is not on the size of hte contents, but instead their computed style<br> <myles> oriol: But instead this would be style containment... but I'm fine with what florian is proposing.<br> <myles> florian: Size-containment means your own size is unaffected by your children. Not that your children's sizes are contained.<br> <AmeliaBR> Size containment is supposed to prevent intrinsic sizing from affecting parent/siblings. So shouldn't affect internal grid layout beyond the size of the box.<br> <myles> florian: To achieve that, we need children not to create implicit trakcs<br> <Rossen_> ack iank_<br> <fantasai> +1 to AmeliaBR's description<br> <myles> iank_: I agree with that model. However, we may want to consider changing what size containment means, given container queries we just discussed. Currently, your grid template columns will affect the inline size of your element. In david's proposal, if you have a container query and it can affect some subset of properties, grid template columns can't do that.<br> <myles> iank_: There are only 2 layout modes that are special here: grid and multicol.<br> <AmeliaBR> q?<br> <myles> iank_: So we could change size containment to act more like block and flexbox, and ignore grid template columns. This means that containment queries, if you can style a certain amount of properties, grid template can be one of these properties<br> <myles> dbaron: I think we're a few steps away from determining whether this is a possibility at all. But it sounds reasonable<br> <myles> iank_: I worry if we don't consider this soon, we'll start closing off opportunities.<br> <myles> iank_: This might be a better way to write the spec and avoid this whole problem.<br> <dbaron> s/reasonable/reasonable. Not sure we're ready to make decisions based on it, but also not sure we want to foreclose it./<br> <AmeliaBR> q+<br> <myles> florian: I think this is compatible with the goals. If we do get the ability to do container queries, that could make this restriction worth it. Later, we might also want a stricter kind of containment, if that's valuable<br> <myles> iank_: I would push back against that. Having one grid+multicol ... people understand what size containment does. It matches that mental model. I don't think we should add unnecessary complexity there.<br> <myles> florian: Thinking through this, if you have a grid that is a block-level child of whatever's around it, it will be sized with width, and everything isfine. But if its intrinsic size ... [missed]<br> <Rossen_> ack AmeliaBR<br> <myles> AmeliaBR: There seems to be a bit of confusion of whether the issue is about which properties affect the calculated size that you're containing to, vs once you've contained that size which features are you restricting. Do these two necessarily have to be the same? Are we allowed to look at the column properties and figure out they determine a minimum size, and say "okay that's the size we're containing to we can figure out just by looking properties on this<br> <myles> element, no need to look at children"<br> <Rossen_> q?<br> <myles> AmeliaBR: But then in another case, the column properties might be auto, or otherwise based on intrinsic size of the child contents, and so in that case the size that would be contained would be dependent on other properties on the element we're containing. When we go to lay out the grid inside that element, can we still lay out that grid based on the children and if the results from laying out the grid is larger than the container size, then we get scrollbars<br> <myles> florian: The spec say you have to do that. That's what i was trying to say when I wrote it. Mats disagrees that's what it says. Perhaps either TabAtkins or I should rewrite it to make sure it says that. But maybe if container queries happen, this will need updating<br> <myles> florian: Notice that this is further along on the req track than grid is, so maybe this text should be done in grid instead.<br> <Rossen_> ack fantasai<br> <myles> fantasai: I agree with florian. This is the most straightforward way to define it.<br> <myles> fantasai: Even if we weren't tracking these specs process-wise. It could be called out in contain<br> <myles> florian: There's a note already.<br> <myles> fantasai: yes. iank_'s point about wanting grid-template-columns to be changeable is a good one, but if we're not doing that, then if the idea that it doens't create intrinisic tracks is unworkable, we have to put them in tracks somehow, we can't put them all on top of each other<br> <myles> florian: There are two phases. 1. size 2. lay out. For the first phase, pretend it has no children, don't consider implicit tracks but do consider explicit ones. 2nd phase: Of course we consider implicit tracks.<br> <fremy> (+1 to proposal)<br> <myles> fantasai: Proposal: Clarify the contain spec about ignoring children when doing intrinsic sizing, but don't ignore for layout<br> <myles> fantasai: And open a second issue about whether grid should have g-t-c be ignored for intrinsic sizing, and put it in the grid spec<br> <myles> iank_: It should go in the containment spec. The min and max content size is affected.<br> <myles> florian: for multicol as well?<br> <myles> iank_: Potentially. columns won't affect intrinsic size of multicol.<br> <myles> florian: What if you say columns: 3 300 column-gap: 300, what's teh benefit of [missed]<br> <myles> iank_: Inside the container query, you can change the size of the contents, but you can't change the number of children<br> <myles> iank_: This is a strictly better if we get container queries. Now is the right time to do it.<br> <myles> Rossen_: I see support in IRC by fremy<br> <fantasai> s/min and max content/min- and max-content/<br> <myles> florian: This will also be a change in form controls, which are weird and not completely replaced elements, and are not 0 when they are empty<br> <myles> florian: I ran into a bug about this. Dropdowns with no children are big enough to not only have the arrow but also have some space where its contents would be<br> <myles> Rossen_: What is the summary?<br> <myles> florian: Proposal: Replace what we have in .1 of size containment, where it says [reads]<br> <fantasai> Kinda discussing 'contain: size' vs 'contain: children' seems like...<br> <myles> florian: And to say that all elements are .... no. we don't want 0. we still want to fill available width.<br> <myles> florian: If you're a block and you're size contained, you're supposed to fill your container<br> <myles> iank_: I agree it should be potentially an exception for replaced elements and non-replaced elements<br> <myles> Rossen_: Let's take these one by one<br> <myles> Rossen_: For the contain spec, we are going to add a clarification of ignoring children for intrinsic sizing purposes and not layout<br> <fantasai> ... were 'contain: size' treats min-content and max-content sizes as `contain-intrinsic-size`, and 'contain: children' pretends there's no children for purpose of intrinsic sizes...<br> <myles> florian: We're either going to tweak the wording editorially, or we're changing that min-content and max-content width and height are 0<br> <myles> dbaron: I'm nervous about addressing min content and max content only without also saying what the effects on layout are. Size containment affects both of them.<br> <myles> florian: There is no effect on layout.<br> <myles> dbaron: I think there is from one layout model to another. That's correct for grid, but I don't think every layout model lays out that way. For example, block does in one dimension but not the other<br> <myles> AmeliaBR: How about "for the purposes of determining size, min-content and max-content are 0, but they go back to normal when laying out children?"<br> <myles> dbaron: I'm trying to think through it again.<br> <myles> dbaron: don't wait on me.<br> <myles> Rossen_: It's valid to not resolve on this if we're not ...<br> <myles> florian: We've uncovered something new and significant. There is a benefit to simplify the definition for the purpose of container queries, then we can go back to github to see what it would be.<br> <myles> Rossen_: It would be great to consider more than grid in here. Would this ever be possible in tables?<br> <myles> florian: Size containment does not apply to various table parts<br> <myles> iank_: Table size containment is broken in many browsers<br> <myles> Rossen_: let's end here.<br> <myles> Rossen_: florian, you have lots of feedback here to put into the issue. Let's continue making forward progress there. Feel free to open the grid-related issue if we need to go that way.<br> <myles> Rossen_: That's everything for this one. Thank you!<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4931#issuecomment-621296713 using your GitHub account
Received on Wednesday, 29 April 2020 15:45:28 UTC