In my last post, I mentioned I was trialling the SUIT CSS naming convention as I redevelop this site. More generically, let’s address why a naming convention should be used at all.
For the purposes of this post, I’m talking specifically about class naming conventions. (While one may have naming conventions for JavaScript functions, variables, and HTML IDs too, they’re not the focus of this post.)
I use a naming convention to link my HTML and CSS
When I first started writing CSS, I threw whichever class fit at the time on any elements requiring them. Take the class author; on a standard blog, this could mean one of a few things:
- an archive of posts by a single author,
- an author’s name in the meta information, or,
- an author’s biography.
Some are more likely than others, but to work out the exact context requires one look at both the HTML and the CSS.
Using a naming convention, it’s easy to see the link between the HTML and CSS by looking at either of the code bases:
.Article {}
.Article_title {}
.Article_author {}<article class="Article">
<h1 class="Article_title">Jailhouse Rock</h1>
<p class="Article_author">by Leiber and Stoller</p>
</article>From the HTML I can deduce the structure of the CSS; and from the CSS, the HTML.
A well thought out naming convention also reduces the chances of collisions
By reducing the page to a set of components, one only needs to consider the names of other components to avoid collisions. Within a component, one only needs to consider other elements also within the component.
Collision detection is reduced from considering the entire web site, to considering only a sub-section of the site. In the final stretch of a development project, this keeps the focus on the end goal, rather than having to take time out to work out why one selector is stepping on the toes of another.
Having a naming convention in and of itself doesn’t solve any problems, but using a systematic approach does. The naming convention makes it easier to stick to a system.
