I was unfortunately made aware of this tweet today and it felt like a blast from the past. Y’know what I’m talking about: the old days when you’d get a PSD from a designer and build it. It’s a real simplistic way of looking at front-end development so I thought I’d jot down what I do in that situation, hypothetically in definitely not a sub-tweet fashion.

The “simple” explanation is that style queries compare the equality of computed values and not assignments. The computed value results from resolving value dependencies, which generally means absolutizing relative values. Both sides of the query are evaluated and resolved before the comparison.

To recap the improvements this aims to make: No wrapper class is required; We’re working with a consistent margin direction; Collapsing margins are avoided (which may or may not be an improvement, depending on your stance); There’s no setting styles and then immediately overriding them;

When translating components from design to development, it’s common to find properties that relate to the content and not to the component itself. This considerate approach to component design creates complicated props, steeper learning curves, and eventual technical debt. However, the key to avoiding these pitfalls is selfish or self-interested component design.

The "ondark" virus is infecting token names in the design systems community everywhere. While it might seem intuitive at first, naming your tokens this way is bad for your health. This isn't about what a token name should include, it's about what it shouldn't.