- From: Roman Komarov via GitHub <sysbot+gh@w3.org>
- Date: Mon, 16 Oct 2023 07:34:01 +0000
- To: public-css-archive@w3.org
I remember when I was thinking about this problem, my idea of a compromised solution was to go the other way: to treat the usage of the properties as _unregistered_ custom properties. My usual test for something like that: is it easy to have a working polyfill that would allow doing this? If we'd think of the values as custom properties, then it is _very_ easy to do so, and it just works: https://codepen.io/kizu/pen/QWzRJjB Just by replacing every value with a variable, we make it so things “just work”. Of course, the compromise is that we could have, say, two different `font-size` on `.panel` and `.sub-panel`, but even then, if we'd have an ability to get also strip a value out of units, then we could just make the calculation ourselves: https://codepen.io/kizu/pen/MWZdzjx?editors=1100 We will probably lose a number of other things that proper serialization would give us, but I'd say that using non-serialized and just treating them as if they were custom properties (with the same cyclic dependency tracking that already works) would cover most of the use cases. Especially, if this would _only_ be necessary for the regular `var()` — with inherited values we won't have any cyclic dependency issues, and the difference in using `inherit(padding)` vs `var(padding)` would be easy enough to understand (`inherit` would give us serialized value, while `var()` would give us non-serialized). -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9454#issuecomment-1763893913 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 16 October 2023 07:34:03 UTC