LeaVerou
commented
3 months ago To be clear, I listed this in #9350 as an idea that doesn't work. I'm not at all convinced this would be a good effort to pursue, and think the Impact/Effort of adding features to improve the design systems workflow when using variables is far better rather than recreating a whole parallel technology that authors need to learn.
What would be the advantage over simply improving variables?
Custom Properties are not really doing the same because they can be locally overwritten at all times.
That is often desirable, e.g. a page may use blue as a primary color, but a note callout may use green, and a warning callout may use red. Admittedly, the low level tokens (e.g. hues, neutrals & tints) are usually constants, but I have also not seen this be a big pain point either.
As @LeaVerou mentioned in #9992 and its more verbose explainer, there is some potential value in making design systems a first-class citizen in the web ecosystem: I’d like to start tracking this idea here, although I’m not sure yet how this would look exactly – I’m afraid the understanding of what a design system actually is and which features it would require that CSS doesn’t already provide may differ considerably. Lea states this at least:
The main purpose of a design system is to make projects more maintainable. One way they achieve this is by limiting the implementation choices authors have. For some CSS properties it’s a bit like only using keywords even though exact values were available, except that with a design system the meaning of these keywords would be selected and centrally set by the local designers instead of W3C. Custom Properties are not really doing the same because they can be locally overwritten at all times. (In #6099 I tossed around an – unpopular – idea how to introduce external “Framework Properties” into
var()that couldn’t be overwritten as easily.)Design systems usually also build more complex structures from lower-level tokens, down to atomic-level. When the assembling of those primary design choices happens on the markup side, this is strongly related to utility classes which have a single small presentational purpose. (In https://github.com/w3c/csswg-drafts/issues/3714#issuecomment-1407783568 I suggested a way to do them better in CSS.) They often follow a systematic nomenclature similar to the global variables that spawned #9992.
Beyond basic design choices like color palettes, fonts or breakpoints, design systems cover higher-level elements like styles, components, patterns, layouts and templates. At least the latter seem out of scope for CSS, but it governs the rest in one way or the other.
The normal cascade of CSS does not seem to play well with usual design systems. That’s probably one of the reasons why the Cascade module is being patched to support other ways, more being proposed (e.g. #5629 and #9350). Although design systems do consider and employ inheritance, my overall feeling is they’d prefer an opt-in model.
That’s just my ramblings so far. What exactly would be required to support design systems better in CSS?