Proposal: intrinsic-size CSS property

[chrishtr]

http://tabatkins.github.io/specs/css-content-size/

This property specifies the size to reserve for elements which already have contain:size. contain:size without content-size is like having `content-size: 0px 0px. It's useful for providing placeholder sizes of subtrees in cases when it is not desirable to render the subtrees.

See also https://github.com/WICG/display-locking/blob/master/explainer-new.md for examples and background that helps to motivate this property.

Feedback appreciated!

[dbaron]

We've talked in the past about a property that sets the intrinsic size(s) of an element. Should this also be that property (or one of those properties) as well?

[chrishtr]

The standalone motivation for the property is to provide a placeholder sizing for subtree content which is either not yet available or not rendered.

[tabatkins]

The intrinsic size stuff's main motivation is getting a good size for a replaced element as soon it's in the document, rather than waiting for the resource to load. While using CSS for that has been discussed, it still puts the necessary information behind a resource load (the CSS stylesheet). So the current proposals for that have all stayed within HTML attributes so far, which seems reasonable.

So I lean towards not trying to merge these pieces of functionality, even tho I agree they're close in their natures.

[astearns]

I'm a little hesitant to add a separate property that only applies in particular contain scenarios. Could the size values be added as optional additional values to go along with the size value in contain? Something like contain: size 200px 200px or contain: size(200px 200px) might make the connection more clear.

[tabatkins]

We thought about that, but it ends up working awkwardly with our current async-render design.

Basically, once you tell a subtree to be async-rendered, it automatically applies several containments, in addition to whatever else you might be specifying in your own stylesheet. One of those is size containment, so if you needed to apply it yourself to get this functionality, that wouldn't work.

• Our earlier design instead required you to apply the necessary containments to get async-rendering to work at all, but that seemed awkward and bad. It puts a non-obvious hurdle in the way of authors getting this to work ("why isn't my element rendering async? I set the attribute correctly!") and it's future-hostile if we add more containment options in the future that we want async stuff to rely on (suddenly all the old pages using async will just become sync, as they're lacking necessary containment values).
• We assign the necessary containments "magically" in an additive way, rather than using a UA stylesheet that could be overridden, because of the lessons we learned with the hidden attribute: doing it in a normal UA rule becomes trivial to accidentally override when applying your own lesser containments, while doing it in a UA-important rule means you can't apply extra containments beyond what the feature requires, because the author rule will lose. If/when we get additive cascade features we can probably avoid the magic.
• We might be able to get around this by specifying that if both size containment and size-with-child containment are applied, the size-with-child wins out. Or that the magic doesn't attempt to add size containment if it detects size-with-child containment already in place.
• If the containment value definitely turns on size containment, then you need to make sure you only apply it when the element is invisible-subtree mode (rendering="invisible" or rendering="invisible-activatable"). That's not difficult (we purposely designed the feature to make the attribute a source of truth, so you can use it in selectors to style differently based on current state), but it is one more detail to think about, versus just blind applying a property that'll only have an effect when it matters. Alternately we could make it a containment value that just modifies size containment but has no effect on its own, which feels a little weird but I guess not terrible.

So, yeah, we've avoided it for now, but it's possible to do if the group decides a specialty property is overkill.

[vmpstr]

It would be nice for the spec to explicitly call out layout modes where the contain: size layout is not empty. The two examples I know of are:

• <select multiple>, that lays out as if it had a default number of default height items. My proposal is if content-size is not none, then it should lay out with all of its contents being sized to content-size (not just a single child, which would be the case with the current wording)
• grid layout, which may be sized to something based on various grid parameters. It's unclear whether it's a good idea to pretend we have a child, place it, and size based on that.

[chrishtr]

Here is a dedicated explainer for content-size, with extra examples:

https://github.com/WICG/display-locking/blob/master/explainer-content-size.md

[css-meeting-bot]

The CSS Working Group just discussed Contain Size, and agreed to the following:

• RESOLVED: Add proxy-width/height/inline-size/block-size with values legacy | auto | <length>

The full IRC log of that discussion

<fantasai> Topic: Contain Size
<astearns> explainer: https://github.com/WICG/display-locking/blob/master/explainer-content-size.md
<fantasai> chrishtr: Posted a new explainer
<dbaron> s/Contain Size/content-size/
<fantasai> chrishtr: content-size is a new CSS property
<fantasai> chrishtr: If 'contain: size' is specified, content-size is treated as intrinsic size of contents
<fantasai> chrishtr: proposing that be able to set intrinsic width/height passed to intrinsic sizing algorithms
<fantasai> chrishtr: Reason we believe it's useful is that you can use it when a subtree is not yet ready or you don't want it to have its own layout
<fantasai> chrishtr: can express a placeholder sizing for it
<fantasai> chrishtr: Allows communicating that placeholder sizing, so that flex/grid/table/etc can take that into account
<astearns> github: https://github.com//issues/4229
<fantasai> chrishtr: If we've skipped rendering as an optimization, dev can use to communicate placeholder sizing
<fantasai> SimonSapin: Would this property apply without 'contain'?
<Rossen_> a?
<fantasai> chrishtr: When you don't have 'contain: size', no
<Rossen_> q?
<AmeliaBR> q+
<fantasai> chrishtr: Only applies when 'contain: size'. Reason is that 'contain: size' causes no competing intrinsic size
<fantasai> chrishtr: 2nd reason is that it fits neatly with render subtree attribute proposal
<fantasai> florian: Can you expand on the second point? I'm not faimilar with that
<fantasai> florian: In isolation proposition makes sense, but not sure why it's not coupled with a more generic intrinsic size feature
<fantasai> TabAtkins: One reason was that, as chrishtr said, that means you have competing information. We don't think that's useful to have two sources of truth there
<fantasai> TabAtkins: Seems like only time you need to provide a better intrinsic size is when you're contain sizing already
<fantasai> dbaron: I'm skeptical of that
<fantasai> dbaron: I think there are a bunch of cases, where intrinsic sizing doesn't provide good results and devs might wnat to provide it
<fantasai> dbaron: Talked about some o those cases in the past
<fantasai> dbaron: Some cases devs want to override only in one dimension
<fantasai> TabAtkins: Bad behavior of intrins scorllers maybe?
<fantasai> TabAtkins: flexboxes blowing up
<fantasai> dbaron: Didn't have that in my head, but sure
<fantasai> TabAtkins: That's intriguing
<fantasai> AmeliaBR: Also cases we've had where certain modes cause things to collapse down to zero, and might be better not to
<fantasai> AmeliaBR: Lots of cases there might be a demand for it
<fantasai> AmeliaBR: Wrt naming, 'content-size' might be interepreted as size of content-box
<fantasai> AmeliaBR: If there is a limitation, tho, should be good reasons for it
<fantasai> TabAtkins: Yes, happy to come up with better name
<Rossen_> q?
<chris> rrsagent, here
<RRSAgent> See https://www.w3.org/2019/09/15-css-irc#T00-39-05
<fantasai> TabAtkins: Cases that fantasai and I identified where boxes get too big in intrinsic sizing, and currently don't have a way to opt into better behavior
<AmeliaBR> ack me
<fantasai> TabAtkins: In some cases can inflate itnrinsic size, others might be able to shrink
<fantasai> TabAtkins: good idea
<Rossen_> ack fantasai
<florian> fantasai: Support florian and dbaron , this should probably be a generic mechanism
<florian> fantasai: the value space would be legacy | auto | <size>
<florian> ???: what is the diff between legacy and auto
<TabAtkins> s/???/cbiesinger/
<florian> fantasai: scrollers collapsing to 0 or not
<florian> fantasai: if inside a flex item, there is an overflow:scroll pre element with a very long line, the min-content size is the size of the very long line, that makes the flex item be very large, even though we could just have made it into a scroller
<fantasai> TabAtkins: Semantics are still a bit funky, if you provide a size wouldn't do anything unless you're contain: size
<fantasai> fantasai: Well, I think it would
<xfq_> ack dbaron
<fantasai> dbaron: I would also note that there are cases where intrinsic sizing provids sizes that are too small, e.g. in cases with percents
<florian> fantasai: if you specify an explicit size, that takes over and you ignore the content
<fantasai> TabAtkins: Could do that... was wondering if you wanted to max them
<fantasai> AmeliaBR: Doing a max or min doesn't work if we want to accept both use cases of dealing with cases where intrinsic size is too big or too small
<fantasai> AmeliaBR: Just say if you specify a value, you wanted to override
<fantasai> chrishtr: All these examples that were alluded to but not explicit, please write into issue
<fantasai> fantasai: Based on discussion, this doesn't go into contain, goes into Sizing level 4
<florian> fantasai: based on this discussion, this goes into sizing-4, not contain-2
<fantasai> Rossen_: Anything else on this topic
<fantasai> TabAtkins: Discussion was good
<fantasai> chrishtr: Point Florian raised about, what are you talking about wrt render subtree
<fantasai> chrishtr: maybe wait until we talk about that
<fantasai> chrishtr: but 5min background on render subtree, though it's on the HTML spec
<fantasai> chrishtr: package, how they fit together matters, so just want to mention
<fantasai> Rossen_: we can put that topic next
<fantasai> chrishtr: Just want to give an overview of what it is, what use csaes are, how it functions
<fantasai> chrishtr: so can get some feedback
<fantasai> Rossen_: So content-size, or whatever we're going to call it, will go to size level 4
<fantasai> Rossen_: Any objections to add it?
<chrishtr> Explainer that contains rendersubtree: https://github.com/WICG/display-locking/blob/master/README.md
<fantasai> TabAtkins: maybe call it intrinsic-size
<fantasai> fantasai: Nobody wants to spell that
<fantasai> TabAtkins: true
<fantasai> fantasai: There was a suggestion that this be split into width/height not one property for both dimensions
<fantasai> fantasai: Seems to be the proposal is foo-width/height/inline-size/block-size
<fantasai> iank_: legacy as initial value?
<fantasai> PROPOSAL: Add proxy-width/height/inline-size/block-size with values legacy | auto | <length>
<fantasai> RESOLVED: Add proxy-width/height/inline-size/block-size with values legacy | auto | <length>

[tabatkins]

Reopening for review - @dbaron, you had some significant thoughts about this property during TPAC. Mind giving it a look? https://drafts.csswg.org/css-sizing-4/#intrinsic-contribution

[tabatkins]

And agenda+ just to bring it up for review at the next call.

[Malvoz]

With the potential addition of the size property, I presume proxy-size should be a thing?

[tabatkins]

It's already in there (as intrinsic-size); you might have missed it because it's at the end of the section.

[heycam]

Is legacy really the right name for the initial value, i.e. is it always the objectively wrong thing to do for a scrollable element compared to auto, and it's just that we're unable to change the initial value due to compat? Or could there be legitimate cases for using it?

I'd prefer if we had value names that indicated it is changing something about scrollable elements somehow, but I don't have any great suggestions.

[AmeliaBR]

I'd prefer if we had value names that indicated it is changing something

What about from-content for auto, and then something like from-content-including-overflow for legacy? Make it clear what they mean, but also make it clear that the second one is an awkward thing that we don't usually recommend…

PS, Should we change the title of this issue to match the current name of the proposed property (intrinsic-size)?

[css-meeting-bot]

The CSS Working Group just discussed Proposal: content-size CSS property, and agreed to the following:

• RESOLVED: intrinsic-size is the name of the new property and value set is 'auto', 'legacy' and a length

The full IRC log of that discussion

<dael> Topic: Proposal: content-size CSS property
<dael> github: https://github.com//issues/4229
<AmeliaBR> https://drafts.csswg.org/css-sizing-4/#intrinsic-size-override
<dael> TabAtkins: With fantasai help and later edits after review with impl we drafted the property the internsic size property in L4
<dael> TabAtkins: Sets intrinisic size of the content. WE thought we could do it by manipluating contributions, but not workable so it explicitly sets the intrinsic size. Further discussion about how to interact with overflow.
<dael> TabAtkins: This is what we discussed at TPAC and said it was cool. It's authored now, review if you're interested
<dael> florian: Contribution vs intrinsic summary?
<dael> TabAtkins: Are you familiar with difference? Contribution is what a child element will tell parent its size is when parent defines size. If the child has width 50px it will say that regardless of content
<dael> Rossen_: Important to know it's border box size of the child. Content is content size which is content-box. That trips a lot of people
<dael> TabAtkins: Reason why we couldn't go with contribution is bc it doesn't have effect on sizing of element itself. It only effects parent's size. As defined before this property contribution is how it wants to be sized normally. Had to switch to the intrinsic size so when it tries to size itself it uses those contribution
<dael> AmeliaBR: I think new name helps clarify. It's using wording we have. As long as consistent that this new property does the intrinsic size it might help clear up confusion
<dael> TabAtkins: fantasai and I concerned with spelling being tricky, but it's used throughout the language so we figured it was a lost cause and should use the same word
<dael> AmeliaBR: One point from heycam at end of issue about naming of keywords. He has a good point that legacy and auto aren't informative. Before naming something legacy we want to make sure we're certain only use case is desc stupid existing behavior
<dael> TabAtkins: fantasai and I are convinced this is bad old legacy behavior and you wouldn't want intrinsic size of a scroller to report a really wide size. POint of a scroller is it's scrollable. We believe this is legacy and we do not want it. Lost opportunity to fix it but we think it is a straight up mistake and naming reflects that
<dael> Rossen_: Proposal?
<dael> TabAtkins: No resolution now. We did resolve at TPAC. This is a request for review.
<tantek> I suppose if we end up with another legacy behavior we can call it 'legacy2'
<dael> AmeliaBR: Resolve to accept the new names?
<fantasai> Issue wrt legacy vs normal wp-login.php?redirect_to=https%3A%2F%2Fwww.w3.org%2Fblog%2FCSS%2Fwp-admin%2F&reauth=1
<dael> TabAtkins: Probably? Let's resolve on intrinsic-size as the name with 'auto' and 'legacy' values
<fantasai> sorry https://github.com//issues/1865
<dael> Rossen_: Prop: intrinsic-size is the name of the new property and value set is 'auto' 'legacy'
<dael> emilio: Wasn't there a proposal to set intrinsic size and that's separate? Seems like it should be a size not a keyword
<dael> AmeliaBR: Default is a keyword that is do what we normally do
<dael> TabAtkins: And you can spec a length or 2 lengths
<dael> Rossen_: Objections to intrinsic-size is the name of the new property and value set is 'auto' 'legacy' and a length
<dael> RESOLVED: intrinsic-size is the name of the new property and value set is 'auto', 'legacy' and a length

[dbaron]

(I got here via w3ctag/design-reviews#437.)

I reviewed the current definitions of the intrinsic-* properties, and I'm somewhat concerned about the naming here given the way this interacts with overflow.

The current default behavior for the scrollable values of overflow (which include hidden) is that they lead to the min-content size being zeroed out (as far as the parent sees), but the max-content size propagating through the element to its parent. In other words, this is a "middle" behavior in between propagating the intrinsic size through for both min-content and max-content, and zeroing out for both min-content and max-content. (At least, I believe this is what Gecko implements, and I believe it had to implement it this way for compatibility.)

I recall seeing strong use cases for both behaviors for min-content size (zero out, or propagate through). I'm less sure about for max-content size. This makes me hesitant to have the default behavior called legacy; it is a behavior for which a good set of use cases exist.

I suspect (though I'm not sure) the non-default auto behavior is actually the less interesting deviation from the current default; I think there may be stronger use cases for "don't zero out min-content" than for "zero out max-content" (particularly with overflow: hidden). At the very least, I'm pretty sure I recall seeing such use cases, but it's been a few years so I don't remember details. I think we should offer this option.

Given that I think there are three reasonable options here for overflow interaction rather than two (and they should probably all be offered), I think legacy and auto are not good names.

(Also, if any of the three options shouldn't be offered because it doesn't have strong use cases, the one I would skip is the one currently defined as auto. This is both because of the three I recall seeing the fewest use cases that needed it, and because it is largely achievable by specifying 0 (although only for certain overflow values).)

---

I also think the definitions that refer to overflow: visible also should also include overflow: clip; I think the way to do that is to refer to whether the box establishes a scroll container.

[tabatkins]

Closing because https://drafts.csswg.org/css-sizing-4/#intrinsic now defines this property, as 'contain-intrinsic-size'.