At Do, we've been working hard to improve the quality and maintainability of our CSS. Our Rails (3.2.6) backend is up-to-date, well-standardized and fully tested, and we want to bring that to our front-end as well.
One issue we've discussed recently is tag-based styles. One of our developers wrote…
we have avoided tag based rules because of performance, browsers read the rules right to left so if you end the rule with a tag, the browser has to start from a larger set of things before it narrows down the rule.
The reality is that our stylesheets contain quite a number of tag-based rules – and worse than any performance issue we've experienced is the litany of overrides tag-based styles can necessitate down the line.
My thoughts on the subject are this: You can use a tag-based rule if you're comfortable finalizing the style of a particular tag in a given context. This can be tricky because you wind up making this decision for your fellow developers – but there are many fair uses of this technique:
.resource-welcome
…
.header
…
.content
…
strong
font-weight: bold
Deciding that a <strong>
means bold in the content of a welcome card is fair game. You might even choose to generalize the boldness of <strong>
's in a wider context.
The danger comes in when you decide to write something like:
.item-wrapper
li
font-weight: bold
a
color: $blue-colour
In the above, you're esentially adding concrete styling to a selector used as a base style, requiring people who are implementing lists to override the behavior – sometimes this problem cascades multiple times, leading to highly nested trampling styles.