I think I read that a while back, which is the main reason I'm able to get past the "visceral reaction" as he so aptly put it. The part about separation of concerns being a false hope and bad framing rings true: "concerns" in software are hazily defined at the best of times. Thinking about dependency between CSS and HTML also makes sense. But I don't really like his examples, and I'm not convinced his evidence reaches quite as far as his final conclusion. For one thing ".author-bio" should have been "#author-bio".

Thinking out loud, now: the problem of CSS and HTML depending on each other makes me think of the dependency inversion principle. Basically, make both of them depend on some common interface or protocol, so they can change independently. Utility classes are in the same territory, but I don't think it's reasonable to demand that the shared language be app-independent, or put another way, to demand that a library author relieve you of the burden of naming your domain objects.

I suspect the ideal approach is app-specific "content-agnostic" classes, defined in terms of some library of helpful classes that are not themselves directly invoked in HTML, with #ids as needed for specialization. But I don't know, maybe I'll just try to the tailwind thing out on a new project.