Re: [csswg-drafts] [css-properties-values-api] Shorthand for custom property declaration (#7523)

Quick aside about the "computationally independent" - the reason for that restriction is to avoid authors having to think about what lengths like `3em` are resolved against, and how the behavior is different based on your syntax. An initial value of `3em` with a syntax of `"*"` means the value isn't resolved until it's used on an element so it'll be font-size specific, but a syntax of `"<length>"` means we'd resolve it to a specific length and it wouldn't respond to each value. By disallowing such values entirely we avoid the potential confusion. (For "computationally independent" values, the behavior is the same regardless of syntax.) However, we definitely *could* allow them and resolve them against the global value, if we're okay with this. (Or condition to only be allowed for "global only" variables, where there's no confusion potential.)

---------

And yeah, I think being able to address the "performance" issue is pretty important, so we *do* need a way to declare that a custom property *will not* be changeable per-element, so we can avoid tracking the property in per-element data structures entirely. My objection was to forcing authors to switch their *definition* and *referencing* syntax based on whether it's global or not; ideally we can keep these close.

So, proposal:

* When you register a property, you can declare that it's immutable or global or whatever. This (a) removes the "computationally independent" restriction, resolving them against global values exactly like they are in MQs/etc, and (b) makes the variables no longer changeable on individual elements.
* You can still use `var()` to refer to "global" variables, as normal. (We'd just look for the name in the global table first, then on the element's properties. Various optimizations are possible here, like the globals exposing a bloom filter or something.)
* You can also use `env()` to refer to "global" variables. On an element this is just for clarity, to explicitly indicate you're using a global value rather than an element-specific variable. But `env()` is allowed in various global contexts, like MQs, where `var()` isn't.
* Maybe you can use `env()` to refer to the initial value of non-global properties, too. This is kinda a nice-to-have, I don't think there's a use-case driving this right now. But it would give us a nice consistent behavior, where var()-vs-env() is independent from global-vs-mutable (it's just that global+var() is identical to global+env()).

We'll need to carefully define cycle handling in global variables, of course. Assuming we want @property registrations to be changeable based on MQs (for swapping colors based on color-scheme, for example), we'll need to add some dependency edges based on use in MQs you're nested in. I don't think this is very hard, but it's definitely new code to determine and track these dependencies. (Alternatively, we don't allow them to be nested, and instead rely on solving this in the property-value space; see recent discussions on `light-dark()` function that responds to per-element color-scheme, and similar discussions about a `media()` function usable in var-like contexts. So you'd just set your initial value to be media-dependent or whatever using that stuff. But that means we need to also do @supports/etc.)

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


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

Received on Wednesday, 23 August 2023 17:42:12 UTC