[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..