More thoughts on HTML class naming conventions

I recently came across a gist Nicolas Gallagher had posted on HTML class naming conventions. I had seen how he named classes before in from his post, About HTML semantics and front end architecture, though I wanted to jot down some more thoughts on this topic.

Common naming conventions

Below are a few common naming conventions I’ve seen other developers using.

The issue I see with the last two naming conventions is that it can be hard see spot the difference where a module ends and a modifier or subcomponent starts when module names are made up of multiple words like product rating.

.product-rating{...}.product-rating--featured{...}/* Modifer (Submodule) with double dashes is easy to spot and understand */.product-rating__label{...}/* Subcomponent with double underscore is easy to spot and understand */.product-rating{...}.product-rating-featured{...}/* Modifier (Submodule) with single dash may be harder to understand that feature is a modifier of product-rating and not necessarily its own module */.product-rating--label{...}.product-rating{...}/* Module */.product-rating--featured{...}.product-rating-label/* Subcomponent with single dash. Harder to understand label is component of product rating. */

One way to get around this would be to use camelCase for module names and only use dashes to separate modules from modifiers and subcomponents.

All of the naming conventions look a little odd at first glance. I think it is important to remind others the overall goal of a HTML class naming convention would be to add clarity for developers, though it can take a while for other developers to understand the thinking behind it and grow accustom to it.