Tailwind has solved a lot of problems. And this is coming from someone who doesn't use it half the time.
Some thoughts about this topic, not necessarily in disagreement:
- Designers seldom think in the way you describe (explicit computer-readable rules, systems of design). A lot of designers are coming from crafts that are more implicit. It doesn't surprise me design business logic is not the topic of conversation.
- You need to update your tailwind classes to reflect your design business logic. Don't do "bg-gray", do "on-surface-emphasis" or whatever business logic. This is just a simple config change.
- You probably brought up modular scale as just one example, but modular type has become near myopic dogma of frontend engineers who haven't had any typesetting experience. A scale of 1.25 vs 1.5 is so in the weeds as to be useless. There are so many alternative ways to set type (e.g. take lessons from CJK typesetting) or innovate typography on the web (e.g. build your own leading-trim implementation!).
I'm a designer, so I absolutely think in terms of design systems where typography is just one part of the puzzle. There are, of course, many ways to set type — but the point was: no Tailwind engineer talks about typographic scales in the first place. Systematic thinking is absent, which is naturally built in CSS.
Tailwind itself is a design system. The authors actually put together a short book explaining their point of view on design systems (without referencing Tailwind) and I found it very difficult to argue with any of their points.
Then you look at Tailwind and realize it’s almost entirely that book packaged for others to use.
The Tailwind library names grades of colors and sizes for you, but the book is ultimately about iterating design so that you can create your own design system. From the perspective of the book, the Tailwind defaults are inadequate as a design system.
Not really the same, although I realize it can seem that way.
If you go low level enough everything technically fits that bill, it’s just a matter of how much work you have do to put the structure in place and what the burden is for other people to learn it.
It’s akin to raw Perl vs Ruby on Rails. You can do it that way, nothing is stopping you…but there are compelling reasons not to.
That's exactly the argument I'm making about Tailwind. Inadequate as a design system. You have these bundles of rules just a thin step above CSS and there's nothing obvious about how things should look.
I'm kind of surprised why this is even relevant to you. The designers I know work in Figma. The designer and the engineer collaborate to make sure the design isn't too hard to implement, but other than that the designer shouldn't care about whether developers are using Tailwind, StyleX, Sass, vanilla, or whatever.
I hardly expect a designer to take responsibility for something as transient and idiosyncratic as "oh, but this is hard in Tailwind."
Some thoughts about this topic, not necessarily in disagreement:
- Designers seldom think in the way you describe (explicit computer-readable rules, systems of design). A lot of designers are coming from crafts that are more implicit. It doesn't surprise me design business logic is not the topic of conversation.
- You need to update your tailwind classes to reflect your design business logic. Don't do "bg-gray", do "on-surface-emphasis" or whatever business logic. This is just a simple config change.
- You probably brought up modular scale as just one example, but modular type has become near myopic dogma of frontend engineers who haven't had any typesetting experience. A scale of 1.25 vs 1.5 is so in the weeds as to be useless. There are so many alternative ways to set type (e.g. take lessons from CJK typesetting) or innovate typography on the web (e.g. build your own leading-trim implementation!).