I’ve found that trying to write semantic markup has helped me write cleaner HTML. It’s been a useful guideline, but it hasn’t been perfect, and I’ve sometimes struggled with how to model things well. Recently at the March SoftwareGR event, I heard Jonathan Snook relay an example that I found very insightful.
Here’s Jon’s example: On a previous site he had a widget listing event locations and had applied a CSS class named “location.” This ran into trouble when he wanted to list products with the same visual style: it is awkward and confusing (and likely to led to errors when another developer needed to refactor things) to apply a class of “location” to a “product.” Jon felt the better answer would’ve been to have a class like “highlight” in the first place, which could meaningfully and semantically apply in both places.
When we talk about CSS classes being semantic, we frequently will talk about it matching up with something in our business or technical domain. The key insight Jon drove me to is that the domain of CSS is styling. CSS does not live in our business domain. Naming a CSS class for things in your business domain is not always what you want because you may have two of the same business domain objects that need different styles, and conversely you may have two totally different domain objects that have the same structure (and therefore the same styling).
The key is to balance avoiding the visual domain (i.e. avoiding classes like “green”), without dropping into your business domain (“product”).
If two things have the same structure and the same information hierarchy, then they should probably share the same CSS class. A good rule might be to imagine your widget with all the content blurred out.
The generalized takeway for me is that “A good semantic model cuts across a single layer of abstraction.” I’ve rarely been able to build anything that conforms to that goal perfectly, but I’ve always found it a good guiding principle.