Re: [csswg-drafts] [css-sizing-4] Only apply contain-intrinsic-size: auto with content-visibility: auto (#6308)

The CSS Working Group just discussed `contain-intrinsic-size and content-visibility`, and agreed to the following:

* `RESOLVED: Drop the "not relevant to the user" condition from c-i-s:auto`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> Topic: contain-intrinsic-size and content-visibility<br>
&lt;TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/6308#issuecomment-1191880225<br>
&lt;TabAtkins> vmpstr: We previous resolved that cis:auto applies only if cv:auto also applies<br>
&lt;TabAtkins> vmpstr: When doing spec changes there was some confusiont aht Oriol pointed out about whether this also applies to cv:hidden<br>
&lt;TabAtkins> vmpstr: For context, we have "relevant to the user", and "skips its contents"<br>
&lt;TabAtkins> vmpstr: For cv:hidden, we say the affected element always skips its contents<br>
&lt;TabAtkins> vmpstr: For cv:auto, it skips its content only if it's not relevant to the user<br>
&lt;TabAtkins> vmpstr: So current spec text for cis:auto applies if the element is not relevant to the user *and* skips its contents<br>
&lt;TabAtkins> vmpstr: This wording implies if should apply to cv:hidden, but only if it's not relevant to the user. This isn't a state we track for cv:hidden elements<br>
&lt;TabAtkins> vmpstr: I don't think we *should* track that state. Should change the spec.<br>
&lt;TabAtkins> vmpstr: I don't feel strongly about how<br>
&lt;TabAtkins> vmpstr: Could drop "is relevant to the user" from cis, so it'll apply to cv:hidden always, or cv:auto when it skips its content<br>
&lt;TabAtkins> vmpstr: Alternately could make it clear that cis only applies to cv:auto<br>
&lt;TabAtkins> vmpstr: TAG talked about only applying it to cv:auto<br>
&lt;TabAtkins> vmpstr: Applying it to cv:hidden seems a little awkward. Dunno use-cases, value doesn't switch between skipping contents and not; dev just sets it.<br>
&lt;oriol> q+<br>
&lt;astearns> ack oriol<br>
&lt;TabAtkins> oriol: Clarifiction: cv:hidden always skips contents, then it triggers size containment.<br>
&lt;TabAtkins> oriol: With size containment we don't record last remembered size<br>
&lt;flackr> q+<br>
&lt;TabAtkins> oriol: If cv:hidden is applied from the start we'll never have a size<br>
&lt;TabAtkins> oriol: So this can affect when you're adding cv:hidden dynamically and there was a remembered size from before; quesiton is whether ot use it or not<br>
&lt;astearns> ack flackr<br>
&lt;TabAtkins> flackr: I think from a dev pov, applying it to hidden allows authors to use hidden to do their own show/hide logic (rather than relying on cv:auto)<br>
&lt;fantasai> TabAtkins: I wrote the spec the way it was because it seemed to me that it was something that applied to certain concepts, and anything using those concepts would want ...<br>
&lt;fantasai> TabAtkins: I agree it's slightly wrong<br>
&lt;fantasai> TabAtkins: but iirc, it was intentionally written to rely on a quality of the element rather than a property value<br>
&lt;emilio> q+<br>
&lt;fantasai> TabAtkins: specifically because I thought hidden should apply<br>
&lt;astearns> ack emilio<br>
&lt;TabAtkins> vmpstr: So I think easiest is to jus tmake it apply if the element skips its content, and remove the relevant from teh user condition<br>
&lt;TabAtkins> emilio: I think there's a tangential issue about this. Shoudl also define how long a remembered size remains<br>
&lt;TabAtkins> emilio: Oriol has been writing some changes that implement the spec to the letter; it's not great<br>
&lt;TabAtkins> emilio: Adds some complexity to remove remembered size at intersectionobserver time.<br>
&lt;TabAtkins> emilio: So depending on how we resolve this, the interaction of switching between values might be more complex<br>
&lt;TabAtkins> astearns: emilio/oriol, are you okay with removing "relevant to the user" and raise further issues as we go? or do you prefer locking to a property value<br>
&lt;TabAtkins> emilio: Dont' think I have a strong opinion<br>
&lt;TabAtkins> oriol: Fine with either<br>
&lt;TabAtkins> oriol: Think problems emilio referred to are a bit orthogonal<br>
&lt;TabAtkins> astearns: So does anyone want to argue against dropping the condition?<br>
&lt;TabAtkins> astearns: So proposed resolution is to remove the "not relevant to the user" condition in c-i-s<br>
&lt;TabAtkins> RESOLVED: Drop the "not relevant to the user" condition from c-i-s:auto<br>
&lt;TabAtkins> astearns: Anyone think we need to bring this back to the TAG?<br>
</details>


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


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

Received on Wednesday, 27 July 2022 16:41:26 UTC