[css-contain] What should container font relative units match against by default?

[nt1m]

#8855 resolved on adding new container-font relative units, however it's not clear which container they should query against. cqw & cqh can match against different containers depending on the container type (inline-size vs. size).

Some options are:

• nearest named container: useful by default, drawback would be the inconsistency with cqw/cqh (which may be confusing if you are using them in an un-named @container at-rule)
• style containers: this makes sense, and is somewhat consistent with cqw/cqh, drawback is that this would always be the parent element, so the units would be useless without the notation from [css-contain-3] Reference named containers for cq units #7858
• inline-size containers: would be somewhat consistent with the majority of the cqw cases, but not really obvious behavior.
• adding a new font container-type
• only allowing those units with the notation from [css-contain-3] Reference named containers for cq units #7858, although having to always specify a container name might be extra-verbose.

cc @mirisuzanne @tabatkins @fantasai

[mirisuzanne]

This is a good list of options, thanks for laying them out. A few I'd maybe remove:

• I think both named containers and style containers (the first two options) are too broad to be useful, especially as authors start naming more style containers.
• Restricting this to math functions makes the default use-cases more difficult, which isn't ideal.

Like you say, inline containers probably have the best overlap with current use-cases, but not a great theoretical reasoning. That makes me hesitant to consider it a full solution. The new container type stands out as most attractive to me, since it allows explicit marking of containers, without needing the full inline-size containment. Then, if we think inline-size containers also match well enough, we could also say inline-size containers implicitly trigger the container-type: text (name TBD) behavior. Then setting text without inline-size would be available for a non-contained option.

(That implicit addition to inline-size doesn't feel essential to me, but might provide nice ergonomics to match author expectation)

[mirisuzanne]

Our proposed resolutions:

• Inline-size containers implicitly act as containers for container font relative units
• Fallback to the comparable root font units when no appropriate container is available
• Provide an explicit container-type: font (we can bike-shed the name if needed)

[nt1m]

• size containers should also implicitly act as containers for container font relative units, given they imply inline-size containment.

[bleper]

I think it might be important for authors to disable the behavior of adding an implicit container type. It might be worth looking at how this is resolved in the case of safe/unsafe alignments (example: size normal gives the old behavior and size, size text gives the new behavior) or add a new property, controlling mapping units to container (example: container-scope with values font, size, auto)?

[css-meeting-bot]

The CSS Working Group just discussed [css-contain] What should container font relative units match against by default?, and agreed to the following:

• ACTION(miriam): File an issue about creating an explicit font container

The full IRC log of that discussion

<myles> Topic: [css-contain] What should container font relative units match against by default?
<myles> github: https://github.com//issues/9255
<myles> ntim: we recently added container font relative units. It's unclear which container to query against. If you look at cqw or cqh it can match different containers. If you hae inline size container, then one will match but the other won't
<myles> ntim: So we have the same issue with font relative units. There are a few options. We could create a new container type which is a font container type. We could use the nearest container. We could always require a container name. There are many solutions
<myles> mia: doing it implicitly based on named containers seems to generic. Implicitly based on sized containers maybe is waht people expect. But there's a question if we need to turn it off if we're doing it implicitly. In my mind, we need an explicit way to do it, and we can ask "do we also want inline-size an dize containers to do it implicitly as well"
<myles> mia: my starting proposal is "we want a new container type with a very bikesheddable name"
<emilio> q+
<myles> astearns: there are 3 things there. let's discuss whether we should have an explicit continer type for font units first.
<oriol> q+
<myles> astearns: I want to push back a little. i agree the size containers people would expect the font units to work with them. Is anyone going to want to set a font container with no size contain?
<myles> fantasai: I think that's quite possible
<astearns> ack emilio
<myles> fantasai: if you look at CJK typesetting, there's a lot of measurements in general layout that are with respect to font units. If you have component that's a smaller font size, you need to set that up as a reference, that seems useful.
<myles> s/mia/miriam/
<myles> emilio: Size containers are heavyweight. they depend on layout. this would be a new container that depends on style. having this new font container type involves a bunch of new ... you need to start tracking a bunch of different things. Is it useful to establish a reference point for these? my feeling is maybe not?
<astearns> ack oriol
<myles> oriol: this might be an argument fo rnot making all elements style containser. but if it's automatic, it would make sense to add a new container type for fonts
<myles> ntim: To reply to style containser, the problem is if you say style containers are for font relative units, then every element....
<myles> astearns: you are agreeing
<futhark> q+
<astearns> ack dbaron
<myles> oriol: If this is not the case, you'd need to expicitly set the style container
<ntim> s/then every element/then every element becomes a reference point
<myles> dbaron: my initial intuition is the container font relative units don't require very much, but they are also container size relative units that depend on size containment. I'm wondering if devs will get confused if these things are relative to different containers. Or if the expectation are all relative to the same things? Or maybe we already ahve things relative to different htings already?
<astearns> ack futhark
<myles> miriam: Yes, they are relative to different htings. That's the reason we might want to do this on size containser. It's expected that, since i've created a size container, my units hsould update. So we will want an implicit version. Do we want an explicit version too?
<myles> futhark: I can think of use cases ... but can't we also solve this CSS custom properties and the calculations based on them?
<myles> futhark: I can see use cases where you don't' have size container but you have style container. If you have a specific element that you want to query, can't you do that typically with custom properties? Like, propagate it down with a custom property?
<myles> miriam: Not only that, we said we're going to have the functional version of these units where you can have a container name. That lets you reference a specific container
<myles> futhark: But that could be any named container. It doesn't mean that it has to be a style container or size container. But that woud be explicit anyway, right?
<myles> miriam: Yeah.
<myles> astearns: Alright.
<myles> astearns: Um.
<myles> astearns: we can either resolve to have a font-specific container that we define, or we can decide to do it later
<myles> astearns: if it's warranted.
<myles> astearns: I'm kind of in the second camp, but i'm not going to object to defining it
<myles> miriam: We can add it later. If we're not sure, i'm ok with waiting.
<myles> ACTION(miriam): File an issue about creating an explicit font container
<myles> astearns: Let's move on
<oriol> q+
<myles> astearns: Can we resolve on: inline size containers are containers for font relative units.
<astearns> ack oriol
<miriam> q+
<astearns> ack miriam
<myles> oriol: my concern would be like ... all elements are implicitly style containers, and then we are considering a new type of container, maybe if we implicitly say that inline size containers are also font containers then ... i'm not opposed to it, it's a nicer default, but it makes me worried.
<ntim> q+
<astearns> ack ntim
<myles> miriam: I disagree that it's fighting us. I think this is different from what we want from style containers. We planed ahead that we want different kinds of containers. We are talking about different kinds of containers. Style containers work correctly for what they are doing. Now we are discussing another thing for another use case. That's how we designed it.
<myles> ntim: I can understand oriol. If inline-size contains font, then if we add another one, what's the implication chain look like?
<andruud> It's indeed biting us now, Oriol.
<myles> miriam: ...The dependencies between container types...
<astearns> ack dbaron
<andruud> Lookup on font-size is fundamentally querying style.
<myles> dbaron: to clarify, when you say "inline size container" i think what is meant here is "any containment type that implies inline size containment which today is size and inline-size"
<astearns> ack fantasai
<myles> fantasai: i'm not certain that we want to tie inline size with font if there's no way to un-tie them
<myles> astearns: that's the next thign
<myles> s/thign/thing
<myles> astearns: but yes, that is obviously the next question
<myles> astearns: Let's see if we can resolve that containers that imply inline-size containment also affect the font container units
<dbaron> And this is looking at the container-type and not the containment, right?
<ntim> container-type yes
<ntim> not contain
<myles> miriam: "container for font-relative units"
<myles> miriam: To answer dbaron this is about a container type, not a type of containment
<myles> ntim: oriol had a question
<myles> oriol: I would be more comfortable if there was a way to turn it off
<myles> fantasai: Rather than resolving, can you take a straw poll, "we should resolve inline containment causes font container unit containment" and see how much of the room feels that this is the right direction?
<myles> fantasai: +1 -1 0
<myles> fantasai: We need to feel confident before moving on
<ntim> ntim: 0
<florian> 0
<emilio> 0
<vmpstr> 0
<futhark> 0
<miriam> +1
<astearns> +1
<myles> astearns: "+1" is agreeing to the connection. "-1" is "no, don't make the connection"
<andruud> 0
<jfkthame_> 0
<dbaron> 0
<fantasai> POLL: We should tie font container units to inline-size container type
<oriol> Mild -1
<bramus> 0
<fantasai> -0
<myles> 0 for myles and 0 for hober
<nicole_> 0
<fantasai> myles: fantasai was saying, unless we're confident about going in this direction, we shouldn't resolve on it
<nicole_> oh sorry, +1
<myles> fantasai: it doesn't seem that we have confidence that this is the right answer. we shouldn't do it unless we are confiden
<ntim> q+
<myles> fantasai: there is a way that's a functional notation that we've defined where you can ask for a named container. We can ship those and see if people almost always map them to size containers. Or is there a lot of variation. If they are always using the inline-size containers, then we can do that
<miriam> q+
<astearns> ack ntim
<myles> fantasai: But if they are all over the place, we can make them not connected
<myles> ntim: How we do it in webkit is we will go through all containers with a relevant container type. So we need to know container type.
<astearns> ack myles
<myles> astearns: i think what fantasai is saying that we would require a new container name, and later on relax that requirement
<myles> ntim: Even then, it will look through everything, and filter by type first. And then by name
<myles> fantasai: That's true.
<astearns> ack miriam
<myles> miriam: My comment might not matter since it doesn't work for the implementation, but yeah, I like in theory that we could do that research. But in practice requiring a name on every unit is a lot.
<myles> fantasai: Can we survey web devs who would be interested?
<myles> miriam: Potentially.
<bramus> We can ask around
<nicole_> q+
<myles> nicole_: Maybe people need to try it in order to give reasonable feedback
<dbaron> some way of gathering needs from web developers does seem useful here
<myles> astearns: My intuition is that inline-size is what i'd expect to effect these units. but i might be wrong. It would be good to get author feedback.
<myles> miriam: That's what we want to prototype?
<myles> nicole_: It sounds like we'll either survey devs or make a prototype.
<myles> fantasai: Or maybe both
<myles> fantasai: "Please try the prototype, we are looking for an answer to this question"
<myles> astearns: nicole_, can you sign up for that?
<myles> nicole_: miriam what do you think
<myles> miriam: "i can't tell you what you can prototype"
<ntim> q+
<myles> nicole_: Are there blockers for prototyping?
<myles> miriam: no
<myles> nicole_: ok, we can prototype
<astearns> ack ntim
<astearns> ack nicole_
<myles> ntim: We can introduce a container type "all" and then all would be a shorthand for font, inline-size, size
<myles> miriam: I think that gives us future problems potentially
<dbaron> +1 to miriam
<dbaron> miriam: if we add a new one, does it get added to "all"
<myles> astearns: We are taking this back to the issue for prototyping and survey result. Hopefully soon we can have more info to make better decisions.
<ntim> ntim: I would argue that inline-size is becoming all if we add font to it

[mirisuzanne]

ACTION(miriam): File an issue about creating an explicit font container

We took this action item assuming the main issue would move forward without it. That's not what happened, so leaving discussion entirely in this issue for now. We can open a new one when it's actually needed.