Re: [csswg-drafts] [css-contain-3] Reference named containers for cq units (#7858)

> @LeaVerou Note that a `<dimension-token>` is a single token, not `<number-token> <ident-token>`. For example, `width: 100px` has a `<dimension-token>` and works, `width: 10/**/px` has a `<number-token> <ident-token>` and doesn't work.
> 
> So Romain is right that with the current syntax, `10cqi(card)` would be a `<dimension-token>` followed by a `()-block`. I guess we could leave this as 2 tokens, which would have some oddities like accepting `10cqi/**/(card)` as valid even if that wouldn't be valid with a function token, or change the syntax to treat it as a single token.

I was referring to how `<dimension-token>` is built up by smaller tokens, see the railroad diagrams here: https://drafts.csswg.org/css-syntax/#ref-for-typedef-dimension-token%E2%91%A2
I imagine this would change to include a `<function-token>` branch.
The alternative, as you point out, has several issues.

> Or just go with the simpler `calc(10 * cqi(card))`. I also like the `cqi(10, card)` from the previous comment.

> Might be better as `cqi(<name> [, <multiplier>])` to allow without the multiplier, or even a syntax that allows a name or multiplier or both. Without a name it would be similar to current cq units (maybe not needed), without a multiplier it would return a single unit (a more useful shorthand). Since idents and numbers have distinct syntax, they could be space-separated and optional without relying on order.

Is `cqi(card, 10)` just syntactic sugar for `calc(10 * cqi(card))`? If so, my preference would be to keep the `cqi()` definition short and not add syntactic sugar for simple math. If there's a huge need for it, we can add it later (with the syntax Miriam proposes). 

-- 
GitHub Notification of comment by LeaVerou
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7858#issuecomment-1373549155 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 6 January 2023 12:07:29 UTC