[css-contain-3] Reference named containers for cq units

[una]

In the [contain-level-3] spec it is possible to name containers, referencing them in @container. It is also possible to use container query units. However, it seems like there is a gap (I might be missing it in the spec) for how to reference a named container when using cq units.

An author might want to specify the container they are referencing when using the cq units (rather than defaulting to the nearest container). Using container-name wouldn't work, since it would set the name. Would it be possible to add a "container-reference"-type-property (name TBD) that can be accessed within an CSS declaration?

I.e. for illustration:

.meta p {
  container-reference: card;
  font-size: clamp(1rem, 10cqi, 2rem);
}

[LeaVerou]

That doesn't seem ideal, because then you cannot combine measures from multiple containers.

What if instead of cq* units we got a function that would accept an optional container name? E.g. container([w | h | min | max] [of [<custom-ident> | closest] ]?)

Then one could use custom units to have a --cq* unit that does whatever they want.

[nmn]

What if instead of cq* units we got a function that would accept an optional container name? E.g. container([w | h | min | max] [of [ | closest] ]?)

This feels like the right solution to me, but I'm not sure about the exact syntax proposed. Perhaps we can use container-reference as function name to combine both your ideas?

.meta p {
  font-size: clamp(1rem, container-reference(10cqi, card), 2rem);
}

One benefit I see of doing this is that it extends the container units that have already been introduced and other than learning about a single new function, introduces no new syntax.

I'm not completely sure about the function name though. Some other ideas:

• for-container-named()
• for-container()
• in-container-named()
• from-container()
• container()

---

Further, I'm not sure this syntax could fly, but this could work very well as well:

.meta p {
  /* `of` or `from` or `in` */
  font-size: clamp(1rem, 10cqi of card, 2rem); 
  font-size: clamp(1rem, calc(1rem + (3cqi of card)), 2rem);
}

[Loirooriol]

Or add functional versions of the units: cqw(<container-name>), cqh(<container-name>), etc.

[nmn]

Or add functional versions of the units: cqw(<container-name>), cqh(<container-name>), etc.

This was my initial thought too, but it feels like it might not be valid syntax? Do we have function calls as units in CSS. Or, is it a proposal?

if the syntax 10cqw(<container-name>) is valid, then that would be the absolute best option!

[Loirooriol]

It wouldn't be a unit, it would be a function returning a length that could be used wherever a length is expected, just like calc(10px * 2).

We already have 10--cqw meaning calc(10 * var(--cqw)), so 10cqw() is not unreasonable. But not strictly necessary, since you could use things like calc(10 * cqw(card)) or clamp(1rem, 10 * cqi(card), 2rem).

[mirisuzanne]

Agenda+ to see if we can resolve on this. I agree that the ideal is to have:

• Function names matching the unit names we already have, eg cq*()
• The functions can be used in calc() and return the value of a single unit, eg calc(10 * cqw(card))
• From there, it's a bonus if we can also use the functions directly as units, eg 10cqw(card)

Meanwhile, the plain units without a function argument continue to refer to the nearest available container.

[css-meeting-bot]

The CSS Working Group just discussed [css-contain-3] Reference named containers for cq units.

The full IRC log of that discussion

<dael> miriam: The request is with ontainer quereis want to query a specific container. Can do with full syntax but not w.ith units. Units give nearest container with right dimenions. It's a good default
<dael> miriam: Nice if you can get the width, height, etc from a specific container
<dael> miriam: Prop is starting ith cq functions that match unitis cqw, cqh, etc. Function takes 1 arg which is name of container. Returns the value of @Unit. You can use that in calc, multiply by something, and query a specific container.
<dael> miriam: Bonus request is do we allow function appended to a value is same way as with custom units. Nice to do with functions. Functions are powerfut even without
<dael> TabAtkins: New functional unit is brand new syntax. Not a problem, but just for conservitiveness I think we want to lean existing pattern. I would think takes cq-length and contextually interprets based on cintainer name as other argument
<dael> miriam: Suggestion a function that's both multiplier and name?
<TabAtkins> container-reference(10cqi, card)
<dael> TabAtkins: Same as nmn (sp?)
<dael> TabAtkins: THis function ^ Relative to name from second argument
<ntim> q+
<dael> miriam: Could work. As soon as looking at container-reference with 2 arg does ti have broader uses? container-reference(2em, card) I would use
<dael> TabAtkins: We could define tightly and extend. If we go for more than 1 dimension, aka a calc of stuff, I suppose works. It's more work impl-wise
<dael> fantasai: All of this is longer to type than calc, right? calc with a bunch of functions would be easier
<miriam> calc(10 * cqw(card))
<miriam> container-reference(10cqi, card)
<dael> TabAtkins: What I desc is shorter than doing same thing with calc. If it's conainer reference that takes name and returns the unit length that's longer
<astearns> ack ntim
<fantasai> how is that strictly longer
<dael> ntim: Would it allow querying the units for containers outside of the container chain?
<dael> ntim: And any concerns if it is allowed?
<dael> miriam: The way I was thinking of it is resolves same as container queries so has to be ancestor
<dael> astearns: Nearest ancestor whose name matches
<dael> astearns: One minute left. Hearing this is good to have but a bit of quibbling over syntax.
<dael> miriam: Can take it back to the issue
<TabAtkins> hm, i guess functions with the name of the cq* unit lets you collapse things down to a pretty short thing.
<dael> astearns: Yep. Let's take it back to the issue and go over syntax, but let's try and take this up. Seems like it will be very useful

[Loirooriol]

TabAtkins: New functional unit is brand new syntax. Not a problem, but just for conservitiveness I think we want to lean existing pattern. I would think takes cq-length and contextually interprets based on cintainer name as other argument

I strongly disagree with container-reference(10cqi, card). Precisely, making lengths context-depend would be the complete opposite of an existing pattern. I think it will be very confusing and problematic, and I don't see any need to do that.

Like, if container-reference(10cqi, card) is valid, is container-reference(calc(10cqi), card) also valid? And container-reference(calc(10cqi + 0px), card)? Does it accept any <length>? What does it do for other units?

I'm fine with container-reference(10, cqi, card) or container-reference(10 cqi, card) or calc(10 * container-reference(cqi, card)). But passing a length seems to open an unnecessary can of worms. My preference is for 10cqi(card) or calc(10 * cqi(card)).

[LeaVerou]

Agreed with @Loirooriol, more specifically on this:

But passing a length seems to open an unnecessary can of worms. My preference is for 10cqi(card) or calc(10 * cqi(card)).

[romainmenke]

10cqi(card) is maybe also problematic, I don't like that this is a dimension token with a simple block attached to it.

calc(10 * cqi(card)) seems much more inline with what already exists in CSS today.

[LeaVerou]

10cqi(card) is maybe also problematic, I don't like that this is a dimension token with a simple block attached to it.

It's not. Functional units would expand the definition of <dimension-token> from <number-token> <ident-token> to <number> [ <ident-token> | <function-token> ] (@tabatkins feel free to correct me if I'm mistaken).