[csswg-drafts] [css-link-params] Should params be root var()s or custom env()s? (#12496)

tabatkins has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-link-params] Should params be root var()s or custom env()s? ==
Currently, [link params act as the initial value of a custom property](https://drafts.csswg.org/css-link-params/#using) in the embedded page. This interacts with `@property` by just overriding the initial value specify in the rule.

This feels a little awkward! At the time I wrote this draft, I wasn't thinking about custom env(), but now that I am (in the context of Mixins), I think that's actually a better solution. I think this solves several issues at once:

* Custom env() are kinda intended to solve the "global var()" problem better *anyway*, and link params are a perfect match for "global variable".
* This avoids any conflict with `@property`. 
* It won't conflict with [`@env`](https://drafts.csswg.org/css-mixins/#env-rule) either - link params will live in the global scope, higher than (and thus automatically overridden by) any `@env` rules used anywhere in the sheet. (Probably these are in the exact same scope as JS-set custom envs; I imagine we'll expose them in the JS API when we define that, as global custom envs that exist at page load.)
* You can still use them like a var if you want (allowing them to be overridden in subtrees), by just setting `:root { --foo: env(--foo); }`.
* This solves the hand-shaking problem in a natural way, without us having to do anything special. If you want to pay attention to a `--foo` link param, you'll write `env(--foo)` in your sheet. If you don't, you won't. If you're already using `env(-foo)` *on your own*, without expecting a link param, you'll have already set an `@env` in the appropriate lexical scope, which'll shadow the link param and protect you from it. There's no chance of a param setting a var higher in the tree than you expected, so you get an attacker value rather than an unset variable. Etc. Literally the only way to be attacked is to use `env(--foo)` without ever setting `@env --foo` in your page, which is a trivial error that'll be caught by your DevTools anyway.

So, unless someone comes up with a good reason to do something else, I'm going to change the draft to make them custom envs, instead.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12496 using your GitHub account


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

Received on Thursday, 17 July 2025 20:51:52 UTC