- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Tue, 27 Jan 2026 19:38:17 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-values] Provide functions for resolving relative units based on type`, and agreed to the following: * `RESOLVED: add value/type conversion functions to css-values-5` <details><summary>The full IRC log of that discussion</summary> <dholbert> miriam: this is sort of me seeing stuff happpening in the ecosystem and wondering if we want to address it more directly<br> <dholbert> miriam: people have often been confused with variables and inheritance, what inherits and what resolves after inheritance<br> <dholbert> miriam: not many people have been using registration until recently<br> <dholbert> so the beahvior was that you inherit an unresolved token, and it turns into a type when you apply the variable<br> <dholbert> and then you get whatever type result, and that inherits from there. but the variable itself was an abstract thing that would resolve later<br> <dholbert> once people started playing with registering properties, that changed. a calculation gets resolved down to a length, and that's what inherirts<br> <kizu> q+<br> <dholbert> whether you want resolution early or late doesn't always align with whether it makes sense to register the property for other reasons (e.g. to set an initial value)<br> <dholbert> if you give the property a type by registering it, you have to give it an initial value<br> <dholbert> then you can never use fallbacks after the property is registered<br> <oriol> q+<br> <emilio> q+<br> <dholbert> it's useful both to capture values and have the resolved value inherit<br> <dholbert> I've linked to feature requests where people have asked for ways to inherit a calculation or expression rather than a resolved value<br> <dholbert> miriam: there have been solutions posted, with how to use custom functions [...]<br> <dholbert> this is becoming more exposed to authors as we add functions and mix-ins<br> <dholbert> we have these various behaviors but not ways of tying into them.<br> <dholbert> there are also requests for type-casting, e.g. taking a number and treating it as a string for generated content. Or the reverse<br> <TabAtkins> q+<br> <dholbert> miriam: so I wonder if we need some built-in ways for working with types in CSS, so authors don't have to reach for these workarounds<br> <astearns> ack kizu<br> <dholbert> kizu: there are some workarounds for some of the types<br> <dholbert> kizu: if your'e using currentColor inside relative color syntax or color-mix or as-is, your'e not able to get the resolved final value of the color calcluation and use it in style queries or if computations<br> <dholbert> kizu: becaues it will only be available at used value time<br> <dholbert> kizu: if authors had a way to say they want to resolve it up-front, that'd be very useful<br> <dholbert> kizu: but generally, big +1 to have this built-in<br> <astearns> ack oriol<br> <emilio> I don't think we want to resolve currentColor, that'd be really weird fwiw<br> <dholbert> oriol: I agree with trying to find solutions<br> <dholbert> oriol: this isn't specific to registered property types<br> <dholbert> oriol: one of the issues that miriam linked -- what was desired there, wasn't using registered properties at all. instead it was a custom property whose value was a var() expression pointing to another variable<br> <dholbert> oriol: and then in descendants, they could change the value of the referenced variable<br> <dholbert> oriol: another example about 'em' units, not absolutizing them at computed value time<br> <dholbert> oriol: it would be good to find a solution that addresses as many of these use cases as possible<br> <astearns> ack emilio<br> <dholbert> emilio: 2 things here... one, "i want to keep the unresolved stuff" - that's different and worth dealing with separately<br> <dholbert> emilio: "i want this variable, but compute it to a length" - that seems reasonable<br> <bramus> q+<br> <dholbert> emilio: we maybe could reuse some of the type syntax that we have for attr. But "i want this attr as a length" gives you the specified length, not the computed length<br> <lea> depending on how we design this feature, we could even do things like `background: url(foo.svg) no-repeat bottom right color(revert-rule)` for the earlier issue<br> <dholbert> emilio: currentColor is its own special case because it's part of the computed color. So resolving it would be weird, since nothing resolves it, except maybe 'color' property<br> <lea> q?<br> <lea> q+<br> <dholbert> emilio: I'd propose we add a type syntax within 'var'<br> <dholbert> emilio: should have same behavior as attr(), to trigger the same computation. Parse as a length, give you the 'em' size for example<br> <TabAtkins> parse() and compute()<br> <TabAtkins> with identical args<br> <dholbert> emilio: maybe we need 'resolve(type(...))' or 'compute(type(...))'<br> <dholbert> emilio: keeping unresolved variables around is a bit weirder -- what does it mean for a computed value to have a var reference<br> <dholbert> miriam: in some ways that's what custom functions do. you have an argument, and the argument sticks around. it's sort of a variable reference that can be plugged in<br> <dholbert> TabAtkins: doesn't stick around past computed-value though. it substitutes at normal var substition time, because that's how we handle functions<br> <kizu> q+<br> <dholbert> emilio: something consistent with attr() would be nice. Nice to figure out how to handle unresolved references, but that's very weird<br> <emilio> s/computed(type(...))/computed(<type>)//<br> <emilio> s/computed(type(...))/computed(<type>)/<br> <dholbert> miriam: there's also a type function used in defining parameters for mixins & functions... can we use that<br> <dholbert> emilio: I would assume that keeps the specified thing<br> <dholbert> TabAtkins: same grammar space, type functions are identical<br> <dholbert> TabAtkins: attr does some additional parsing<br> <dholbert> TabAtkins: as long as you're sticking to the type function, it's the same between the two<br> <astearns> ack TabAtkins<br> <dholbert> TabAtkins: generally I support this. people are already working around this. I have an example in the spec, with a hand-written link converter function<br> <dholbert> TabAtkins: silly to have folks rewriting this over and over, even if it's trivial<br> <astearns> s/link/length/<br> <dholbert> TabAtkins: I'm ok with having 2 versions as emilio says<br> <dholbert> TabAtkins: I'm ok if there's a parse-only version like attr(), but I mostly want to be sure we have the useful one<br> <dholbert> emilio: it would be weird if [...]<br> <astearns> ack bramus<br> <emilio> var(--foo type(<length>)) resolved em to pixels, but attr(foo type(<length>)) didn't<br> <dholbert> bramus: +1 to the use-cases. typecasting in general has come up within the community a lot<br> <dholbert> bramus: people are already registering custom properties with a certain type, and then they compute before they inherit... maybe we add a descriptor to custom properties that say "don't compute this before inheritance"?<br> <dholbert> bramus: e.g. register property as a length, give it a value 2em, and if this flag is set, you'd always inherit "2em"<br> <dholbert> bramus: so it would be recognized as a type<br> <dholbert> bramus: and would reject "blue"<br> <dholbert> emilio: that would be the attr() behavior<br> <dholbert> emilio: that's what the type() function would do<br> <miriam> This issue proposes something like @bramus is suggesting: https://github.com/w3c/csswg-drafts/issues/13188 `inherits: declaration`<br> <astearns> ack lea<br> <lea> scribe+<br> <TabAtkins> Oh I absolutely was not wanting to tie it to var(), where did this idea come from?<br> <TabAtkins> I presumed it was just emilio thinking out loud<br> <lea> lea: General support for the use cases too. Idea: rather than tying it to `var()` which limits it (e.g. now we need a new one for `inherit()`), what if we decouple it from the actual value? E.g. `as(var(--foo) type(<color>))`or something. It would be a little more verbose but much more flexible. E.g. what we were discussing before would become a single declaration: `background: url(foo.svg) no-repeat bottom right as(revert-rule type(<color>))`<br> <astearns> ack kizu<br> <dholbert> TabAtkins: that's a huge scope expansion, I don't want to mess around with that as part of this issue. Can discuss after<br> <dholbert> kizu: I remember use-case for computing currentColor. Imagine we have a container<br> <dholbert> kizu: we want to capture its currentColor, and then override it on some inner element, and then restore it on a deeper inner element<br> <emilio> q+<br> <dholbert> kizu: right now we can't do that.<br> <lea> would `inherit(color)` help with this?<br> <dholbert> kizu: you can't access currentColor from ancestor<br> <dholbert> kizu: if we were to implement this as a native feature that computes it, we could do this<br> <lea> q?<br> <astearns> ack emilio<br> <dholbert> emilio: there are strong reasons to postpone calculating currentColor<br> <dholbert> emilio: it would introduce a lot of dependencies between stuff<br> <dholbert> emilio: color right now doesn't introduce any dependency on anything else, because currentColor is deferred<br> <dholbert> emilio: if it wasn't, then every property that takes a color would be cyclic<br> <lea> q+<br> <dholbert> kizu: can we capture the inherited color? not the current element's color, but the inherited one<br> <dholbert> emilio: that's more feasible but orthogonal to this issue<br> <astearns> ack lea<br> <dholbert> lea: there's the inherit() function, with an intent-to-prototype in chromium maybe<br> <dholbert> lea: would inherit(color) solve this problem, once that's landed?<br> <dholbert> emilio: as-written, that would return `currentColor` keyword, since that's its own computed value<br> <dholbert> astearns: sounds like handling currentColor is a separate issue<br> <dholbert> emilio: yeah<br> <dholbert> astearns: but I'm hearing a lot of support for handling types like this.<br> <dholbert> astearns: do we need a resolution?<br> <dholbert> astearns: or should we think more in the issue?<br> <dholbert> TabAtkins: resolution should be good. We have a proposal<br> <dholbert> TabAtkins: additional features can be layered on top<br> <dholbert> TabAtkins: we have a straightforward use-case to solve, and a concrete proposal<br> <dholbert> TabAtkins: proposed resolution: add value/type conversion functions to css-values-5<br> <dholbert> fantasai: do we have a syntax for it?<br> <dholbert> TabAtkins: no strict proposed syntax; we can put something in the spec and see what people think<br> <dholbert> RESOLVED: add value/type conversion functions to css-values-5<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12488#issuecomment-3807146514 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 27 January 2026 19:38:18 UTC