CSS: contain-intrinsic-size: auto, and converting to a shorthand property

[cbiesinger]

Ya ya yawm TAG!

I'm requesting a TAG review of contain-intrinsic-size: auto, and converting to a shorthand property.

This adds an "auto" keyword to contain-intrinsic-size, which lets the rendering engine remember the last
used size so that the author does not have to guess correctly (with a fallback size if the element was
never laid out without size containment).
Also, longhand properties were added, including logical axes: contain-intrinsic-width, contain-intrinsic-height, contain-intrinsic-block-size, contain-intrinsic-inline-size

• Explainer¹ (minimally containing user needs and example code): https://gist.github.com/cbiesinger/f2378dbcd215495c3a1daf9696a8e91f
• Specification URL: https://drafts.csswg.org/css-sizing-4/#propdef-contain-intrinsic-size
• Tests: not written yet; I am filing this review before implementation and test writing has started.
• Security and Privacy self-review²: n/a
• GitHub repo (if you prefer feedback filed there): https://github.com/w3c/csswg-drafts/issues
• Primary contacts (and their relationship to the specification):
  • Vladimir Levin (@vmpstr), Google
  • Christian Biesinger (@cbiesinger), Google
• Organization(s)/project(s) driving the specification: Google and the CSSWG
• Key pieces of existing multi-stakeholder review or discussion of this specification: [css-sizing-4][css-contain-2] Revisiting auto-sizing when size-containment applies w3c/csswg-drafts#5668 (comment)
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/6740477866934272

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: Ideally within the next month or so
• The group where the work on this specification is currently being done: CSSWG
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): CSSWG
• Major unresolved issues with or opposition to this specification: none
• This work is being funded by: Google

You should also know that...

[please tell us anything you think is relevant to this review]

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

[LeaVerou]

My thoughts while looking at this:

First, this definitely solves a real problem. Indeed, it's quite a hassle if authors need to guess the correct intrinsic size for this property, and it creates a maintenance nightmare when there are a lot of elements whose intrinsic sizes need to be contained.

On the other hand, CSS has always been this nice reactive language in which things apply and then they stop applying without leaving any side effects behind. Unlike (common) programming languages, there are no ordered steps, the current state is always a function of what currently applies, and there is value in that simplicity. The concept of last remembered size that is introduced here breaks this fundamental assumption, introducing side effects that persist after properties have stopped applying. It introduces state that is not inspectable and has no obvious cause. Is there any other existing CSS feature that produces lasting side effects in that way?
Have other ways to solve this problem been sufficiently explored that do not change the way CSS works so dramatically?

[vmpstr]

Thank you for your feedback!

The concept of last remembered size that is introduced here breaks this fundamental assumption, introducing side effects that persist after properties have stopped applying.

contain-intrinsic-size only has an effect if we have size containment, so the side effect here is tied to the presence of size containment (whether introduced by contain property directly or via something like content-visibility). In other words, I claim that the side effect introduced here does not persist after the property has stopped applying -- it's just not the same property, if that makes sense. But that's a bit of a pedantic point. Other than that, you're right that this introduces a state that is captured at a time different from when the property begin applying.

Is there any other existing CSS feature that produces lasting side effects in that way?

I'm not aware of anything in CSS that relies on previous sizing like this. However, we do have things like content-visibility: auto which depend on element visibility, relying essentially on IntersectionObserver timing. There are also things like container queries, which selectively apply different styles depending on the current state / size of elements. It's not the same as contain-intrincis-size auto, for sure, but I feel like it falls in a similar bucket of things that aren't exactly side-effect free.

Have other ways to solve this problem been sufficiently explored that do not change the way CSS works so dramatically?

The piece of data that we want to capture here is the size that really only the UA knows for sure. Script, for example, can get at this size and the advice that we've been giving developers is to use a polyfill of this feature, directly using ResizeObserver or getBoundingClientRect to set appropriate values of contain-intrinsic-size at appropriate times. But in order for us to do this "automatically" in CSS we would need to snapshot this size before we apply size containment and use it at the time that size containment applies. So fundamentally, there is a timing dependency here that I believe is unavoidable.

[LeaVerou]

@hober and I discussed this in a breakout today during our VF2F.
We think that the improvement this feature offers over the existing JS library appears to be very incremental, so it appears that the benefit of adding this feature to the Web Platform does not outweigh the additional complexity, and the cost of breaking one of the fundamental assumptions of CSS.