Re: [csswg-drafts] [css-sizing][css-contain] Are intrinsic sizing keywords definite with size containment? (#7206)

The CSS Working Group just discussed `[css-sizing][css-contain] Are intrinsic sizing keywords definite with size containment?`, and agreed to the following:

* `RESOLVED: no change to specified behavior`

<details><summary>The full IRC log of that discussion</summary>
&lt;emeyer> Topic: [css-sizing][css-contain] Are intrinsic sizing keywords definite with size containment?<br>
&lt;emeyer> github: https://github.com/w3c/csswg-drafts/issues/7206<br>
&lt;emeyer> oriol: Normally, when we have an element with height: auto, if there’s a descendant that’s a percentage, it gets set to auto<br>
&lt;TabAtkins> q+<br>
&lt;emeyer> …In a case where a container has size containment and doesn’t depend on descendants, what should happen?<br>
&lt;emeyer> …Implementations treat this as cyclic<br>
&lt;emeyer> …auto height container should resolve to zero, and percentages of content should be zero<br>
&lt;emilio> q+<br>
&lt;emeyer> …if container is height: 100px, descendants at 50% are 50px<br>
&lt;emeyer> TabAtkins: We don’t currently treat a no-contents element being non-cyclic, so I don’t see how contain: size would change that<br>
&lt;emeyer> …I support what implementations are doing<br>
&lt;emeyer> oriol: If there are no content, can you tell whether the height is considered to be definite or not?<br>
&lt;emeyer> TabAtkins: Nothing we’ve written makes the assumption that that’s the case<br>
&lt;emeyer> TabAtkins: You have to perform layout to know the size, even if nothing is actually laid out<br>
&lt;Rossen_> ack TabAtkins<br>
&lt;Rossen_> ack emeyer<br>
&lt;Rossen_> ack emilio<br>
&lt;emeyer> emilio: I think I agree with Tab; it’s easy to back-compute on block axis, but in other places it might not be<br>
&lt;emeyer> …Complex cases tend not to be very interoperable<br>
&lt;emeyer> …It’s not obvious to me you can define the sizes of element without performing layout on the elements<br>
&lt;emeyer> …I’d rather not make this more complicated<br>
&lt;emeyer> Rossen_: Agreed.<br>
&lt;emilio> s/back-compute on block axis/back-compute the size on a block container<br>
&lt;emeyer> …proposed path forward is to resolve as no change; objections?<br>
&lt;emeyer> emilio: I would like the specifications clarified, even if it’s just a note or example<br>
&lt;emeyer> …I don’t thin kthe behavior we want to resolve on is clear form the current specification<br>
&lt;emeyer> …Adding something that clarifies that this case is still cyclic would be preferred<br>
&lt;emilio> +1 to clarify, do we define this block-axis back-computation of percentages properly somewhere?<br>
&lt;emilio> s/emilio:/oriol: :-)<br>
&lt;emeyer> Rossen_: Please add a comment on the issue with proposed addition text<br>
&lt;emeyer> RESOLVED: no change to specified behavior<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7206#issuecomment-1218266195 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 17 August 2022 16:49:23 UTC