[csswg-drafts] [css-env-1] How to handle `env()` in descriptors not exposed as `CSSOMString`? (#11264)

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

== [css-env-1] How to handle `env()` in descriptors not exposed as `CSSOMString`? ==
`env()`-containing declaration values are valid at parse time ([spec](https://drafts.csswg.org/css-env-1/#env-function)). If I am not mistaken, `env()` should be internally preserved even after substitution, and should show up in the serialization, in order to be processed whenever an environment value changes.

But `env()`-containing values are incompatible with [font feature value descriptors](https://drafts.csswg.org/css-fonts-4/#cssfontfeaturevaluesmap) and [`@view-transition/types`](https://drafts.csswg.org/css-view-transitions-2/#dom-cssviewtransitionrule-types), which are the only descriptors exposed as a specific value type via the CSSOM, rather than as a `CSSOMString`.

Now I am aware that the current browser support for `env()` is limited to property declarations and declarations in `@page`/margin rules, and that I am reporting a problem that will probably never happen because authors will never use `env()` for these descriptors. But it might happen for future descriptors.

If `env()` is here to stay for *any descriptor of any rule*, and should be preserved in the serialization, I think any descriptor should either be exposed as `CSSOMString` or not be exposed.

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


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

Received on Saturday, 23 November 2024 04:31:43 UTC