- From: Miriam Suzanne via GitHub <sysbot+gh@w3.org>
- Date: Mon, 21 Aug 2023 19:47:56 +0000
- To: public-css-archive@w3.org
This syntax works well for grouping multiple property definitions that share features, but I think it's missing some attention to larger issues in how authors and browsers think about property registration and definitions. I would really like to see a more comprehensive plan for author-ergonomic 'design token' management. In my experience, authors currently use the `:root` and `*` universal selectors to define most custom properties, and only add formal `@property` registration when they explicitly need a syntax for the purpose of interpolation. However, with a shorthand like this, authors might expect that they are doing both in one place: registering an initial value, and also establishing a root/global value. That would be excellent if they could, but currently there's a big technical difference. Initial values are to be 'computationally independent' when there is a defined `syntax` - which means the initial value cannot reference other custom properties, or even use relative units. I don't know what leads to that limitation from an implementation perspective, but it doesn't match author expectations for defining custom properties, and won't work for most use-cases. As long as that restriction is in place, authors will need to keep defining a majority of custom properties on root/global selectors, even after they have a shorthand for registering syntax and initial values – meaning most properties will still need to be defined in two places. In some ways, this is the distinction we also have between spec-defined 'initial' values, and browser-defined 'default' values – which are defined in distinct places, for distinct reasons. And for some author-origin use-cases that will make sense. A shared design system or framework can register properties with computationally independent 'initial' values, and the consuming stylesheets can apply selector-based 'default' values. But in many cases, authors have no reason to distinguish between the two. Most authors don't even know that the distinction exists in CSS. For the majority of design-token use-cases, authors will want initial and default values to match – and in many of those cases, variable-reference and responsive units are essential. I don't know if it's possible to remove the limitation from initial values? But if not, it would be nice to have a way of setting root/global default values _in the same place where registration happens_. I think this will also be essential for #2627, since authors will expect to have responsive units in global environment variables. (Root vs global selectors are used by authors as a shorthand for toggling inheritance without formal registration) -- GitHub Notification of comment by mirisuzanne Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7523#issuecomment-1686940729 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 21 August 2023 19:47:58 UTC