Post

I'll often take something that lets me do less naming and naming lookup over separation of concerns. It's not as bad of a problem with component scoped styles. Perhaps a lot of the styling should be based on semantic html, but it doesn't go all the way.

I don't like names because they: - Can take time to pick, disrupting flow - Are sometimes badly named - Are often not updated to reflect changed code - Can be misinterpreted and used for the wrong thing (more of a problem with global style sheets)

There are basically two use cases for SoC. 1. You have developers who write css but does not want to touch the rest of your code. 2. Your code base needs to support multiple themes that goes far beyond what you can do with CSS variables. Both are very rare in my experience.

I meant it as separation between structure/content and presentation. For me personally the sweet spot is semantic CSS grouped with code at component level. I understand what utility-first CSS like brings to the table when collaborating on a project, but never really worked for my brain.

Yes I understand. Separation of content and presentation is less bout wether they live in different files, and more about how they are coupled. If the css ONLY targets the content it is next to, then you have locality of behavior. If not you have separation of concerns

And if for some reason you think Tailwind suits agents better: lol it doesn't really matter for them. Utility-first CSS is just human-DX ergonomics, not necessarily as useful to LLMs (this is just based on personal experience, not quantitative data).

Remember we have a mutual friend who would order his CSS styles by line-length. Like a Christmas tree but for psychopaths.