Atomic CSS: Make design tokens customizable

[eliot-akira]

An idea for the future: the CSS utility classes are generated based on a shared set of design tokens, or primitive values - such as spacing, colors, etc.

It would be useful for creating design systems if such values can be customized.

[GabrielGallagher]

Hey @eliot-akira, this is actually something we've been working on and have a planned set of tokens and a GUI for, as it will be necessary in TBlocks in order to have blocks inherit existing styles or extend the existing style system (it's all in Figma). The plan is also to have it interface with theme.json (if it exists) and on a non-block theme to bring some of the niceties of theme.json in. It would be great to coordinate on this so we don't build 2 parallel systems if this is something you plan on working on. I just saw the UnoCSS stuff which also seems to overlap with these plans, so we should probably start a discussion to make sure what we're doing all works together.

[eliot-akira]

@GabrielGallagher @juliacanzani

Yes, definitely that's the plan. I've been studying and referring to the Figma prototypes (exported PDFs) regularly, as well as existing notes and references around this topic - such as standardized design tokens in Gutenberg, theme.json, Design Tokens W3C Community Group, Style Dictionary - as I explore the landscape of best practices and idiosyncratic implementations, to get an idea of what functionality is needed for others to build a design system builder.

I'll prepare the foundation of a "feature project" soon, either a separate repository or as a feature folder within the Template System, so we can discuss and develop the feature collaboratively.

Ideally, I'd like to let others have complete ownership of the feature, but before that there are inter-compatiblity questions that need to be solved together.

---

The Atomic CSS feature is emphasized as "experimental", because my motivation was first to see if it could be done, and then how practically it would work in the long term.

TailwindCSS is controversial, people love it or hate it. So far, I'm in neither camp - I like the convenience but still question if the cost of complexity and verbosity is worth it.

Another motivation was that there are tons of open-source Tailwind templates and component libraries. By using UnoCSS's Wind preset, a large subset of the utility classes are compatible - so I was curious to see if that would open up an ecosystem of templates we can curate into a "standard library" of user-interface components.

---

Also on this topic, I'm preparing a minimal block theme with Bootstrap 5. I've extracted their examples into L&L templates, including their "cheatsheet" which showcases all their components. For people who are familiar with Bootstrap, I bet they would find it useful and quick to build websites using such a library.

---

For the new feature project, I sense that the most suitable solution will be:

• Admin interface for a full range of design tokens, built with Tangible Fields and L&L templates, completely customizable.
• This will generate:
  • CSS variables for the whole site frontend - Must be prefixed
  • Sass/JS/template variables for use within blocks and templates
• And define the primitives and design tokens used by CSS utility classes, such as spacing, colors, etc.

..Well, this comment can be considered a rough draft, I'll organize the ideas and prepare a foundation where we can explore the way forward together.

[GabrielGallagher]

I've been seeing a lot of love for Core Framework and Automatic CSS in a certain corner of the WP page building space lately that seem to have some overlap. They both seem a lot more maximalist than what I assume we'd go for but it's interesting to see how they try to tackle this kind of thing.

[eliot-akira]

Thank you, I skimmed through the two CSS frameworks you mentioned - very interesting how they're solving similar questions. I see what you mean by "maximalist", they both have a huge feature set.

---

Speaking of overlap and compatibility, there's a big on-going effort in the Gutenberg project to address many of the same topics that we're all trying to solve. These discussions are valuable because WordPress core developers are exchanging ideas and defining concrete steps in the larger roadmap.

• Proposal: Standardized block markup, theme.json design tokens, and CSS classes to improve interoperability WordPress/gutenberg#38998
• Global Styles Ongoing Roadmap WordPress/gutenberg#41232
• Design Tools Overview WordPress/gutenberg#33447
• Style engine: functionality and design WordPress/gutenberg#42028
• Adopt a classes-first approach to CSS WordPress/gutenberg#54033

Ideally, it would be nice if we could use core features to meet our needs, or at least re-purpose their functionality, like the Style Engine. However, so far it's too much of a moving target to rely on, and some of their design decisions might be too complex, or maybe not a perfect fit for what we want to achieve.

---

An advantage of Tailwind and UnoCSS, at least as a reference, is that they provide a customizable set of standard design primitives that have been proven to be useful for a large audience of designers and developers. There's a kind of community concensus with wide adoption and production use, more than Gutenberg's style engine and theme.json (or Core Framework and Automatic CSS) - but clearly they're all converging on very similar fundamental concepts.

• The Case for Atomic / Utility-First CSS

---

The Design Tokens Community Group represents a large number of companies such as Adobe, Amazon (who created Style Dictionary), Figma, Google, Microsoft. The technical specs of design tokens is not an actual W3C standard yet, but it's a good reference for what an industry standard might look like as a consensus of many interested parties.