Standard CSS has become beautiful, Tailwind may no longer be necessary

Recently, I realized that standard CSS has evolved quite a lot.

When I talk with other engineers, it seems like many people do not know about it, so I will share it here.

For several years now, CSS has been able to write nesting syntax as a standard feature. This is a tremendous evolution.

In many projects, people introduced sass or scss to extend CSS, or used CSS frameworks that define styles through classes, such as Bootstrap.

Bootstrap had a big problem. That is that it ends up looking like a design prepared by Bootstrap.

When you show the page to someone else, they instantly see, “Ah, this was made with Bootstrap.” That is the problem.

Then the option that appeared was Tailwind CSS.

Tailwind CSS is utility-first, and it allows you to design from scratch without having to think of class names yourself.

However, Tailwind CSS also had a big problem. That is that the html file becomes hard to read.

For example, when defining a button, you have to go out of your way to write code like this. Buttons are naturally something you reuse.

<a
  href="#contact"
  class="inline-flex min-h-12 items-center justify-center rounded-full bg-blue-600 px-6 py-3 text-sm font-bold leading-none text-white shadow-lg shadow-blue-600/20 transition hover:bg-blue-700 focus:outline-none focus:ring-2 focus:ring-blue-500 focus:ring-offset-2"
>
  Contact us
</a>

What was born to solve this problem was Daisy UI.

For many years, I have used Daisy UI in my personal development projects.

It allowed me to write classes like Bootstrap, and at the same time I could customize it so that it would not feel like a template. It seemed like the best possible answer.

But daisyUI is also Tailwind CSS inside after all. The HTML file is hard to read. Manipulating the HTML file for styling itself seemed to me to be outside the single responsibility principle.

So I happened to look into standard CSS. Then I was surprised that recently it has evolved in ways like this.

• Nesting syntax can now be written as standard
• With :has(), styles can now be applied to a parent element according to the state of its child elements
• With :is(), multiple selectors can be written together more easily
• With :where(), base styles can be written more easily without increasing specificity
• With custom properties, colors, spacing, border radius, font sizes, and so on can be managed more easily on the CSS side

In particular, the fact that nesting syntax can now be written as standard is big. Because the structure of CSS becomes closer to the structure of HTML, the readability becomes much better.

I am currently trying to start a web production company specialized in a certain industry. In that process, when creating a landing page using standard CSS, I generated code like this.

<nav class="header" aria-label="navigation">
  <ul>
    <li><a href="#" aria-current="page">Home</a></li>
    <li><a href="#">Support</a></li>
    <li><a href="#">Area</a></li>
    <li><a href="#">Pricing</a></li>
    <li><a href="#">Contact</a></li>
  </ul>
</nav>

.header {
  width: 100%;
  min-height: var(--size-px-10);
  display: flex;
  align-items: center;
  justify-content: flex-end;
  padding-inline: var(--size-px-8);
  box-sizing: border-box;

  ul {
    display: flex;
    align-items: center;
    justify-content: flex-end;
    gap: var(--size-px-8);
    margin: 0;
    padding: 0;
    list-style: none;
  }

  a {
    display: inline-flex;
    align-items: center;
    min-height: var(--size-px-8);
    color: var(--gray-12);
    font-size: var(--font-size-2);
    font-weight: var(--font-weight-7);
    line-height: 1;
    text-decoration: none;
    white-space: nowrap;

    &[aria-current="page"] {
      text-decoration: underline;
      text-decoration-thickness: var(--border-size-2);
      text-underline-offset: var(--size-2);
    }
  }
}

@media (--md-n-below) {
  .header {
    min-height: auto;
    justify-content: flex-start;
    padding: var(--size-px-4);
    overflow-x: auto;

    ul {
      gap: var(--size-px-5);
    }

    a {
      font-size: var(--font-size-1);
    }
  }
}

Because the HTML shows the hierarchical structure as it is, it is very easy to read.

By the way, defining variables from scratch myself is difficult, so I introduced a library called OpenProps, which was highly rated on GitHub. Though when I say library, it is a raw CSS file.

So far, this approach is working well.

I am not trying to completely deny Tailwind CSS. Thanks to Tailwind CSS’s utility-first philosophy, I was able to roughly understand what kinds of classes exist in CSS. I probably would not have been able to do what I wanted if I had only touched standard CSS. But Tailwind CSS’s documentation is very complete, and the class names are also very easy to understand.

Even so, is it really necessary to go out of our way to dirty the HTML file? That is how I feel.