[css-sizing-4] Only apply contain-intrinsic-size: auto with content-visibility: auto

[cbiesinger]

https://drafts.csswg.org/css-sizing-4/#intrinsic-size-override

If auto applies to everything, you can into the situation where an element is visible on screen but rendered with outdated dimensions. For example:

<div style="contain-intrinsic-size: auto 100px; float: left; width: 200px;"></div>

Now, if JS adds contain: size; width: auto;, the element will be rendered at 200px width, even though this size is neither in the current CSS style not is it related to the content size.

This is an unfortunate situation. To fix this, we would like to propose only applying auto if the element also has content-visibility: auto. This would ensure that the remembered size is only used if the element is offscreen, where an outdated size will only affect the scrollbar size.

Thoughts?

@dbaron @chrishtr @vmpstr @tabatkins

[chrishtr]

I think this is a good change, because offscreen placeholder sizing is the only use case we've defined for this feature. And it's very important to provide a way to utilize content-visibility, and this use case, this without script, so that pages can have excellent progressive rendering, and improve performance & accessibility.

Also, for developers who want to have the same behavior without content-visibility: auto, there is always the option to use a RezizeObserver.

[css-meeting-bot]

The CSS Working Group just discussed [css-sizing-4] Only apply contain-intrinsic-size: auto with content-visibility: auto, and agreed to the following:

• RESOLVED: only apply contain-intrinsic-size: auto with content-visibility: auto

The full IRC log of that discussion

<dael> Topic: [css-sizing-4] Only apply contain-intrinsic-size: auto with content-visibility: auto
<dael> github: https://github.com//issues/6308
<dael> cbiesinger: With contain-intrinsic-size: auto. you can get into situation where current size of element is based on css prop that's no longer set on element.
<dael> cbiesinger: Set explicit width, remove it, explicit width could still be rememebred and applied.
<dael> cbiesinger: Weird situation. Main use case for contain-intrinsic-size: auto is when in combo with contain-vsicility: auto
<dael> cbiesinger: Suggestion is to make it only apply with contain-visibility: auto which means this will not be visable for user but address main use case
<dael> cbiesinger: What does WG think. Is this a problem we care about and, if is, is this a good solution
<Rossen_> q?
<dael> TabAtkins: Makes sense to me. Happy to do this.
<dael> emilio: Can you remind me how we made apply contain-intrinsic-size: auto work? Does it only change behavior on the screen?
<dael> emilio: Can you remind me of how we made content-visibility: auto work? Does it change just the used value?
<dael> cbiesinger: Not sure offhand
<dael> emilio: Depending on how that works this doesn't solve the problem or solves it.
<dael> emilio: If the computed value remains auto proposed solution...needs to be more subtle
<dael> chrishtr: Saying script looks at bounding client rect of the offscreen element it would notice old width?
<dael> emilio: Yes, but not complaining. When have content-visbility: auto and becomes visible do we change content-visbility style?
<dael> chrishtr: No. Contain-size is removed
<dael> cbiesinger: Spec only changes used value of contain
<dael> emilio: Then this doesn't solve issue, does it? Need to be only for content-visibility: auto that are offscreen
<dael> cbiesinger: If it's on screen cotnain size won't apply so c-i-s doesn't apply
<TabAtkins> To be clear: it has no effect on the used value of 'contain'. It simply applies containments, *independent* of the 'contain' property.
<dael> emilio: Makes sense. Wanted that clarified
<dael> Rossen_: That satisfies your concern emilio?
<dael> emilio: Yeah. Seems reasonable
<dael> Rossen_: Other opinions or concerns?
<dael> emilio: Another question- if main use case...why do we want to make this special case? I understand it can cause weird behavior. If authors not expected to use c-i-s:auto with things that don't have c-v:auto...do we need to special case?
<dael> chrishtr: Arguement for is to avoid poss of element on screen that dev is confused about. Only use case we know of is placeholder sizing when element is offscreen.
<dael> chrishtr: Had to say if would be a big problem in practice
<dael> emilio: I guess somebody could come with creative use cases. I don't know. I would prefer to not special case if we don't have evidence this is really confusing. not a hill I want to die on
<dael> cbiesinger: I don't really care so much myself. TAG and someone else had concerns and prefered the change. I'm happy not change if WG thinks we don't need to
<dael> emilio: TAG is generally smarter then me. If they think would be confusing I'm okay
<dael> Rossen_: cbiesinger what was the context of the review?
<dael> cbiesinger: Review auto value of c-i-s. I can find a link to the review
<dael> Rossen_: We can link in the issue later
<cbiesinger> https://github.com/w3ctag/design-reviews/issues/624
<dael> Rossen_: There is some thumbs up and lots of not really caring about how this goes one way or the other. I want to call for objections to resolving on this
<dael> Rossen_: We can always come back, but not hearing strong pushback. Proposed behavior does make sense and will improve the behavior
<dael> Rossen_: Objections to only apply contain-intrinsic-size: auto with content-visibility: auto
<dael> RESOLVED: only apply contain-intrinsic-size: auto with content-visibility: auto
<chrishtr> Thanks all!

[tabatkins]

Whoops, didn't link the edits for this issue to this thread: 22a5e0e

[cbiesinger]

Reopening as discussed, that edit does not affect c-v: auto

[chrishtr]

Didn't commit 22a5e0e clarify that c-v: auto is the only feature affected by the auto behavior?

[tabatkins]

No, my mistake, that was an irrelevant commit, it was just about the fact that an element can gain and lose a last remembered size several times. It has nothing to do with the "phantom size visibly sticking around" problem that Christian is talking about here.

The edit I just committed (6eb6faa) is directly handling that, tho.

[chrishtr]

I left a comment on that commit..

[Loirooriol]

I was confused because from the spec it seems that contain-intrinsic-size: auto can be used with content-visibility: hidden, but some WPT and this resolution say it's only with content-visibility: auto.

According to 6eb6faa#r61269377

No, the resolution was worded confusingly to refer to the property value, when it meant the effect; if I did just gate it on the property value, Christian's issue would still apply exactly as stated, with a visible element having a phantom size. The intention was that it needed to only apply while the element was being skipped.

Christian and I discussed whether it made sense to only apply it while being skipped as a result of c-v:auto or in any skip, and we couldn't come up with a good reason to be restrictive.

So in https://software.hixie.ch/utilities/js/live-dom-viewer/saved/10484 I expect both elements to keep being 50px tall when gaining content-visibility: auto or hidden. But in Chromium content-visibility: hidden results in 1px, ignoring the auto in contain-intrinsic-size.

[css-meeting-bot]

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

The full IRC log of that discussion

<TabAtkins> Topic: contain-intrinsic-size and content-visibility
<TabAtkins> github: https://github.com//issues/6308#issuecomment-1191880225
<TabAtkins> vmpstr: We previous resolved that cis:auto applies only if cv:auto also applies
<TabAtkins> vmpstr: When doing spec changes there was some confusiont aht Oriol pointed out about whether this also applies to cv:hidden
<TabAtkins> vmpstr: For context, we have "relevant to the user", and "skips its contents"
<TabAtkins> vmpstr: For cv:hidden, we say the affected element always skips its contents
<TabAtkins> vmpstr: For cv:auto, it skips its content only if it's not relevant to the user
<TabAtkins> vmpstr: So current spec text for cis:auto applies if the element is not relevant to the user *and* skips its contents
<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
<TabAtkins> vmpstr: I don't think we *should* track that state. Should change the spec.
<TabAtkins> vmpstr: I don't feel strongly about how
<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
<TabAtkins> vmpstr: Alternately could make it clear that cis only applies to cv:auto
<TabAtkins> vmpstr: TAG talked about only applying it to cv:auto
<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.
<oriol> q+
<astearns> ack oriol
<TabAtkins> oriol: Clarifiction: cv:hidden always skips contents, then it triggers size containment.
<TabAtkins> oriol: With size containment we don't record last remembered size
<flackr> q+
<TabAtkins> oriol: If cv:hidden is applied from the start we'll never have a size
<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
<astearns> ack flackr
<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)
<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 ...
<fantasai> TabAtkins: I agree it's slightly wrong
<fantasai> TabAtkins: but iirc, it was intentionally written to rely on a quality of the element rather than a property value
<emilio> q+
<fantasai> TabAtkins: specifically because I thought hidden should apply
<astearns> ack emilio
<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
<TabAtkins> emilio: I think there's a tangential issue about this. Shoudl also define how long a remembered size remains
<TabAtkins> emilio: Oriol has been writing some changes that implement the spec to the letter; it's not great
<TabAtkins> emilio: Adds some complexity to remove remembered size at intersectionobserver time.
<TabAtkins> emilio: So depending on how we resolve this, the interaction of switching between values might be more complex
<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
<TabAtkins> emilio: Dont' think I have a strong opinion
<TabAtkins> oriol: Fine with either
<TabAtkins> oriol: Think problems emilio referred to are a bit orthogonal
<TabAtkins> astearns: So does anyone want to argue against dropping the condition?
<TabAtkins> astearns: So proposed resolution is to remove the "not relevant to the user" condition in c-i-s
<TabAtkins> RESOLVED: Drop the "not relevant to the user" condition from c-i-s:auto
<TabAtkins> astearns: Anyone think we need to bring this back to the TAG?