Let me know if this is what brought you here:
You’re learning Cascading Style Sheets (CSS), and you found yourself wondering what kind of coding convention you should follow for your code.
Or maybe you’re already familiar with CSS and you’re starting a project with new colleagues—and have a dispute about the use of lowercase vs. uppercase letters in your style sheets.
Whatever brought you here, it’s good that you stopped by. Because in this article, we will talk about whether CSS classes should be capitalized or not, along with everything else you should know.
Should You Capitalize CSS Classes?
So… What’s the verdict? Should you, or should you not, capitalize class names and ids in your CSS style sheets?
Most people who write CSS code do so using lowercase letters and hyphens to separate words. Underscores and capitalized letters are generally fine, but they’re not as common.
For example, if you were writing a CSS rule for an HTML element that’s hidden from the DOM, your CSS selector would look like this:
/* Single-word selector */
.hidden {
display: hidden;
}
/* Two-word selector */
.is-hidden {
display: hidden;
}There’s a good reason why this coding convention is most popular among CSS style sheet authors.
In the early days of the web, the Netscape browser didn’t support the use of underscores in class names and ids. And the CSS specification didn’t mention anything about how web browsers should handle uppercase letters.
Although you no longer need to worry about using uppercase letters and underscores in your CSS code, you could say that the use of lowercase letters and hyphens is almost baked into the CSS specification.
Lowercase letters and hyphens is also the coding convention that the CSS specification itself uses for selectors consisting of multiple words—for example, the :first-child pseudo-class and the ::first-letter pseudo-element.
CSS Naming Conventions
There are a number of CSS naming conventions out there that can help you and your team write CSS style sheets in a more consistent and maintainable way.
BEM
The BEM naming convention (in case you’re wondering, “BEM” stands for “Block, Element, Modifier”) is one of the most widely adopted.
Far more than a CSS naming convention, BEM is actually a methodology for creating reusable components with your HTML markup and CSS style sheets.
In BEM, a block represents a component that’s meaningful on its own and an element represents a part of a block that has no meaning of its own.
.block {
/* CSS declarations go here */
}
.block__element {
/* CSS declarations go here */
}
.block__element--modifier {
/* CSS declarations go here */
}For example, a <form> element with a class name of .form would constitute a block, and an <input> element within that form with a class name of .form__input would be an element.
A modifier would represent a specific state of a block or an element, like .form__input--invalid and .form__input--valid.
SMACSS
SMACSS, a mouthful of an abbreviation pronounced “smacks,” stands for “Scalable and Modular Architecture for Cascading Style Sheets.”
More than a naming convention or a style guide, SMACSS is a methodology for categorizing and writing your CSS rules in a way that’s repeatable, maintainable, and, above all, bound to logic and good old common sense.
In SMACSS, all CSS rules fall into one of five categories:
- Base rules
- Layout rules
- Module rules
- State rules
- Theme rules
Base rules are the default rules for your HTML elements, like the styles that apply to the head, body, hyperlinks, paragraphs, and so on.
Layout rules are the rules that divide the screen into a layout that holds one or more modules together.
Module rules are the modular and reusable components within your design, such as buttons, forms, widgets, and so on.
State rules are for specific states of your layouts or modules, like forms with valid and invalid inputs, user preferences for the layout, and so on.
Theme rules determine how the layouts and modules in your web page should look. For example, light theme and dark theme, blue and red buttons, and so on.
SMACSS is more about how you approach and structure your CSS code than how you name the rules and format the declarations in it. However, its author has provided some helpful guidance on code formatting.
OOCSS
Before we talk about OOCSS, we need to get something straight: CSS isn’t a programming language. It’s a style sheet language for styling HTML documents in web browsers.
But if you want to write CSS code as if you were writing in a bonafide programming language, consider adopting OOCSS, or “Object-Oriented CSS.”
OOCSS is a method of structuring your CSS style sheets that takes its cue from object-oriented programming.
Web developers who abide by the principles of OOCSS favor reusable class names over unique ids, and do all that they can to make their CSS rules abstracted from the HTML elements styled with them—and therefore reusable.
So, instead of your CSS rules looking like this:
#nav_button {
background: yellow;
margin: 20px;
padding: 20px;
}You would write CSS rules that look like this:
.button {
margin: 20px;
padding: 20xp;
}
.bg-yellow {
background: yellow;
}The result, as with any other CSS coding convention, are style sheets with less code that’s easier for others to read and for everyone to maintain.
In Conclusion
For a stylesheet language, Cascading Style Sheets is as rich and versatile as it gets.
But its versatility can sometimes backfire, especially for beginner web developers and/or on larger projects. This is where CSS naming conventions and style guides come into play.
Although the CSS specification itself doesn’t prescribe exactly how to write your CSS rules, it gives clear indications that lowercase letters and hyphens are to be preferred—but not mandatory.
So how you write your CSS code really comes down to you, your team, your project, and your organization. The CSS methodologies that we shared here should help you with the rest.
