Skip content-specific names
A class tied to one piece of content breaks when the markup moves.
Adam Wathan@adamwathan@mdavis1982 I try to avoid content-specific class names, leads to hard to maintain CSS in my experience :/ Fav article on it:
Adam Wathan@adamwathanI kinda want to rewrite one of our Tailwind UI page examples with custom content-derived class names just to compare the compiled CSS + HTML size after network compression, but I think I would be so paralyzed trying to come up with names that it would take me a week 😵💫
Adam Wathan@adamwathan@nicklmitch @tmcw The alternative is a class like `.profile-banner-wrapper` that sets `display: flex` though right? That feels like a lot more overhead and indirection than something within a Levenshtein stone’s throw of the raw CSS property.
Adam Wathan@adamwathan@mark_story Can't just use `.btn-primary` directly in the markup, no, instead let's target `.process-type-switcher li fieldset a`! 😑
The bad pane echoes the selector joked about in the fourth post.
Move the widget
Move the widget to the other place.
Content-derived namesBad
Utility classesGood
<ul class="flex gap-2">
<li><a class="rounded-full bg-sunken px-3 py-1">Docs</a></li>
</ul>Why it matters, pros and cons
Why it matters
A content name ties the styles to one place in one page. Move the markup and the selector no longer matches.
Pros
- The look travels with the element, wherever you put it.
- No descendant selectors to keep in step with the markup.
- Nothing to invent: the class is close to the CSS property.
Cons
- Markup shows more detail than a single semantic name.
- Repeats across many pages should still become one component.
- Teams used to BEM may find it noisy at first.