I haven't seen cascades be a problem since the days of monolithic, app-wide stylesheets, and no project I personally know of works that way anymore.

Just about everyone uses component-specific styles with a limited set of selectors where there are very few collisions per property, and pretty clear specificity winners when there are.

If the alternative to the cascade is that you have to repeat granular style choices on every single element, I'll take the cascade every time.

▲

Klonoar a day ago | parent [-]

> Just about everyone uses component-specific styles

Yeah.

At which point you can simply use e.g Tailwind.

▲

Lalabadie a day ago | parent | next [-]

What component-specific styles look like:

class="menu-item"

Styles-in-HTML (Tailwind):

class="m-4 mb-2 p-2 border border-radius-sm border gray-200 hover:border-gray-300 font-sm sm:font-xs [...]"

You can be completely insensitive to or unbothered by the difference, but that doesn't mean they're equivalent.

	▲	Klonoar 12 hours ago \| parent [-]
		I'm not saying they're equivalent. I'm saying that the latter is better, especially in the context of reviewing LLM output. With the former, I need to cross-reference two different stacks (HTML and CSS) and construct a mental model every time I move between components. With the latter, I can simply look at one output (HTML) and move on with my life, knowing that the chances of conflicts/issues/etc are fairly limited. You guys are advocating for keeping the semantic separation that we originally aimed for with HTML/CSS, but in an LLM world this is yet another distinction that probably "does not matter".

▲

spankalee a day ago | parent | prev [-]

No, because many components have internals that need to be styled consistently with parts of other components.

With plain CSS components can easily share styles and use them by adding the correct class name to elements.

With Tailwind you have to copy your list of super fine-grained classes to each component, and try to keep them in sync over time