At the last f2f, when we discussed the proposal to allow an async-layout element to specify a "default" size while it's not actually laying out its contents (effectively contain:size), over the course of the conversation we ended up redefining it into a more general ability to manually set the intrinsic size of an element.

As we've experimented with implementation, tho, we've come to realize that this generalization accidentally significantly broke the usability of the feature for its original use-case.

• With the original (attribute-based) proposal, previously authors could set the "default size" property on all async-layout elements, and it would only trigger when needed (when the element wasn't displaying its children); it would stop affecting anything once full layout started working. With this change, authors instead have to carefully target their rules so that 'intrinsic-size' stops applying when full layout starts, or else lingering effects of the property can produce confusing layout artifacts.
• With our exploration into an alternative CSS-based async layout, you can't even target things carefully anymore; you instead have to track "is locked/unlocked" separately with script and rely on that to apply/unapply 'intrinsic-size', breaking all the elegant simplicity.

Regarding the additional use-cases we ended up addressing with the revised "applies all the time" property:

• Per dbaron's comment, the auto/legacy usecase that partially justified the expansion of the concept needs some more thought anyway, and should maybe be a separate feature.
• The "generate appropriate scrollbars for virtual scrollers" use-case ([css-sizing-4] Scrollbars when intrinsic-width is > width? #4415) was just a nice freebie feature; it's not an important feature to preserve right now, and can be easily hacked with a fake element at the moment.

So after discussion with @vmpstr and @chrishtr, we'd like to change tactics: we want to withdraw the general intrinsic-size property for now, and return to the earlier concept of something that solely provides a non-zero size for contents solely when size containment is applying.

Name is up for grabs; it just needs to be something other than 'intrinsic-size', since it's explicitly not setting that general concept.

And then separately we'll still want to figure out a good solution to the auto/legacy use-case, but need to review dbaron's feedback.