The Evolution of Scalable CSS

I'm actually working on a large design system that's in the process of stripping Tailwind _out_, because it's in fact not scaleable if you want to provide vanilla component styling APIs via custom properties. And as some others here have mentioned, we're not even talking yet about web components, shadow DOM, shadow parts, etc.

Scaleable CSS should adhere to the actual spec of CSS and how its evolving in browsers. Tailwind is a massive, non-standard deviation from the development of CSS.

I enjoyed the overview (though the web component/shadow Dom bits others noted here would have been nice) but I feel like there's a missing realization lurking at the center of this history: the separation of concerns in the web stack was designed for documents, not layouts or visual designs.

Much of the struggling we've seen over the decades is because the separations aren't aligned with how we're using them. It makes sense for documents to have separate stylesheets. It doesn't make sense to fragment the implementation of a layout across several files and complexly-interacting languages.

This isn't really a fault of the article. I only just realized this in the past year myself and I've been writing html since the all caps era. I took a first swing at writing about this recently in: https://t-ravis.com/post/doc/what_color_is_your_markup/

The evolution of practices described in this article is followed up to about ten yeas ago... and then stops, followed by Tailwind. Where is consideration of web components with shadow DOM, which solve the CSS encapsulation problem, the naming problem, and the dead code problem? Where is treatment of CSS variables that pierce the shadow DOM and allow global theming of such components? They are the next step in the evolution of scalable CSS, and yet they are noticeably absent from the discussion.

> With Atomic CSS, the growth of CSS is tied to the number of unique styles used, not the amount of features developers are shipping.

> For example, it’s common to reuse certain properties like flex everywhere. Rather than have these duplicated in stylesheets under different class names, we only pay that cost once. This is true for each property/value combination.

This is true in theory and when you stick to the very basic stateless utility classes. Check the CSS of any larger site using Tailwind and search for a CSS rule, you will see things like

    .opacity-100 {
        opacity:1
    }
    .hover\:opacity-100:hover {
        opacity:1
    }
    .group\:focus-within .group-focus-within\:opacity-100 {
        opacity:1
    }
 

One nice thing about this is that instead of using classes, you can instead statically import the definition and apply it to your element, making it even fail compilation time if you remove some global styling some component still relies on.

And the CSS itself is typed. So the project will not compile if you write invalid css.

CSS is a fully solved problem: CSS modules combined with global utility classes. You probably want sass too, but the important thing is you’re writing CSS, and font have to figure out the DSL, translation, and plugins needed to use CSS features.

Several big names such as Adobe are actively involved, so this has some weight to it.

https://github.com/design-tokens

The style set is a collection of styles rules local (rooted at) to the component. :root denotes the component to which styleset is applied.

The style set definition is strictly local to the component - rules inside it do not pollute global style table. That is close to <style scoped> to anyone who remember such thing.

Here is how styled component.js module looks like:

    const padding = "12px";

    const styleset = CSS.set`
      :root {
         color: var(--theme-color);
         padding:${padding};
         background: var(--theme-back);
      }

      :root > em {
        color: gold;
      }`

    export class TestComponent extends Element {
      render() {
        return <div styleset={styleset}>
          Hello <em>Embedded</em> Style Set
        </div>;
      }
    }

With tailwind and react you now only write JSX files. Not separate files/sections for HTML, JavaScript and CSS your mind constantly needs to connect, although they are split up. Huge plus for someone with a goldfish brain like me, that’s getting super confused with more then 5 files open in the editor.

And with tailwind 3.2 they finally allow multiple config files, so you can easily have multiple tailwind instances inside one project. For example one config for the website and another one for the admin-panel.

Using "design system" values - every color and width variable comes with well chosen constraints!

(from my take on this https://www.swyx.io/why-tailwind)

  .nav {
    &__link {
    }
  }

  .nav {
    a {
    }
  }