- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 07 Feb 2019 00:34:35 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `What track sizes match the concept of "intrinsically-sized track" ?`, and agreed to the following: * `RESOLVED: Accept the edits.` <details><summary>The full IRC log of that discussion</summary> <heycam> Topic: What track sizes match the concept of "intrinsically-sized track" ?<br> <heycam> github: https://github.com/w3c/csswg-drafts/issues/3042<br> <heycam> Rossen: fantasai can you summarize?<br> <Rossen> github: https://github.com/w3c/csswg-drafts/issues/3042<br> <heycam> fantasai: just made some changes and wanted to check that nobody had any issue with the changes<br> <heycam> ... wedefined flexible tracks as intrinsically sized when the grid container has an indefinite size in that axis<br> <fantasai> https://github.com/w3c/csswg-drafts/commit/b86cf52f9d5dca765efa8758896a989847a5c68c<br> <heycam> ... the reason we did that is when you're sizing under a max-content constraint, and you have flexible tracks, we do consider the size of the grid when determining that isze<br> <heycam> ... if the grid floated, with 2 fr tracks -- normally with a fixed size of the grid each track will be 1fr<br> <heycam> ... minmax(0, 1fr)<br> <heycam> ... but if you are max-content sized, you will look at the content<br> <heycam> ... maybe something in one track tacks up 100px, the other track even if empty will be 100px<br> <heycam> ... since we're trying to size the grid such that each track is at least the size of its max-content and it's equially distributed<br> <heycam> ... here they are considered instrinsically sized<br> <heycam> ... so that means when your'e doing baseline alginment stuff, there are cyclic dependenies<br> <heycam> ... and we cut the loop by ignoring certain baseline alignments<br> <heycam> ... which is what originally brought up the issue<br> <heycam> ... so I wanted to double check this all seems ok<br> <heycam> Rossen: the change seems ok on our side<br> <heycam> ... in fact I was almost surprised we're adding this so late<br> <heycam> ... reading through the explanation is exactly what I'd expect the distribution algorithm to do<br> <heycam> ... so adding this clarification is good, we're in support<br> <heycam> ... any other feedback?<br> <heycam> ??: I was fine wiht this change<br> <heycam> ... we wondered if it will be necessary to add something to clarify that this flexible tracks will be considered intrinsically sized even after having resolved the container size in subsequent passes of the grid sizing alg<br> <heycam> ... I mentioned that since Mats already requested something similar for the percentage track resolution<br> <heycam> ... where the grid container is intiially undefined, and after being determined the intrinsic size, we use that size to resolve the percetnage tracks<br> <heycam> ... we wonder if in this case we need to clarify that these flexible tracks will be considered intrinsic even though we already resolved the intrinsic size<br> <heycam> ... because of baseline alignment it has an important impact<br> <heycam> ... we decide to discard some items from baseline alignment because of this cyclyic dependency<br> <heycam> ... once you resolve intrinsic size, it's the agreement we should ....<br> <heycam> ... these flexible tracks should still be considered intrinsically sized<br> <heycam> ... there is no min-content constraint<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/3046<br> <heycam> fantasai: I think you raised a similar issue here in 3046<br> <heycam> ... we can try to clarify if you point out what is needed<br> <lajava> https://github.com/w3c/csswg-drafts/issues/1921#issuecomment-399170288<br> <heycam> ... if the track is considered intrinsically sized then the determination is constant<br> <heycam> lajava: Mats also reequested a similar thing for percentage tracks<br> <heycam> fantasai: I don't know if it makes sense as much, would have to think about it<br> <heycam> Rossen: percetnage tracks in the context of resolving tracks during measuring?<br> <heycam> lajava: yes<br> <heycam> s/??/lajava/<br> <heycam> Rossen: we have discussed this at the past, and our agreement AFAIR is that percentages in this case are ignored<br> <heycam> ... and the intrinsic size is used<br> <heycam> lajava: then we use the resolved intrnsic size to again resolve the percentage tracks?<br> <heycam> ... but we are not doing the same with flexible tracks<br> <heycam> ... we consider them intrinsically sized even though the grid container is not indefinite any more<br> <heycam> ... so we are not doing the same in both cases<br> <heycam> Rossen: they are not, because the percentage will resolve during the layout pass<br> <heycam> ... and for the fr the expectation is that you would have the max-content contribution size taken by that track<br> <heycam> ... if the track were 50% instead of 1fr, you would get 50% of what the max contribution would end up<br> <heycam> ... they are the same during hte measuring pass, intrinscis sizing, but don't beahve the same during the layout sizing<br> <heycam> ... so I'm not sure we need to be necesssarily talking about the two as being the same thing<br> <heycam> lajava: I understand<br> <heycam> ... I wonder if we should specify for the case of the flexible tracks if in this case second pass, in case of orthogonal items were you have to repeat the sizing alg, that we should still keep the original behavior of these fleixble tracks being instrincially sized<br> <heycam> ... and ignore the already resolved value<br> <heycam> ... it may be enough with the current spec<br> <heycam> lajava: the change says that for this prupose flex tracks count as intrinsically sized when the grid container has an indefinite size in the relevant axis<br> <heycam> Rossen: the relevant axis is the key<br> <heycam> ... just trying to process your assertion about orthogonal content and if that has any bearing on this<br> <heycam> lajava: when you repeat the track sizing alg as the spec says, for the case of orthogonal items, in this second pass is it still true that the grid container has indefinite size?<br> <heycam> Rossen: it should<br> <heycam> lajava: yes, I think that is what fantasai and Tab resolved in another issue<br> <heycam> ... but should we specify that somehow?<br> <heycam> ... or is it obvious<br> <heycam> fantasai: I don't know where I would clarify it, but if someone suggests I'm happy to<br> <fantasai> Here's the spec<br> <fantasai> https://drafts.csswg.org/css-grid-1/#row-align<br> <heycam> Rossen: how about lajava if you have the time I would suggest handling this as part of the other issue that was pointed about by fantasai<br> <heycam> ... 3046<br> <heycam> lajava: ok<br> <fantasai> "If baseline alignment is specified on a grid item whose size in that axis depends on the size of an intrinsically-sized track (whose size is therefore dependent on both the item’s size and baseline alignment, creating a cyclic dependency), that item does not participate in baseline alignment, and instead uses its fallback alignment as if that were originally specified. For this purpose, <flex> track<br> <fantasai> sizes count as “intrinsically-sized” when the grid container has an indefinite size in the relevant axis.<br> <heycam> Rossen: and then we can decide whether or not we need to change anything<br> <fantasai> Note: Whether the fallback alignment is used or not does not change over the course of layout: if a cycle exists, it exists."<br> <heycam> fantasai: [reads above quote]<br> <heycam> lajava: ok<br> <heycam> Rossen: back to the original issue, any additional comments about the edits?<br> <heycam> ... any objections on accepting the edits for issue 3042?<br> <heycam> [none heard]<br> <heycam> RESOLVED: Accept the edits.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3042#issuecomment-461244906 using your GitHub account
Received on Thursday, 7 February 2019 00:34:40 UTC