Skip to content

Instantly share code, notes, and snippets.

@arbales
Created Aug 15, 2012
Embed
What would you like to do?
Tag-based Styling

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.contentstrong
      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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment