For anybody who’s not yet discovered ITCSS (Inverted Triangle CSS), a scalable CSS methodology designed by Harry Roberts; it’s a system that attempts to make as much use of the CSS cascade as possible. Starting by applying styles as generically as is viable; rules gradually increase in specificity.
ITCSS uses the following pattern:
- Settings - Universal; more conceptual than physical. As they can be applied anywhere, they reside at the top.
- Mixins - Similar to settings, but as they often rely on them, they reside on the layer beneath.
- Generic - If you don’t use a preprocessor, your styles probably begin here. Generic styles aren’t meant to change over the duration of a project. Tools such as CSS resets reside here.
- Elements - Elements target HTML elements. Before classes need to be styled, elements should be targeted to cover the groundwork.
- Objects - Objects are generic classes that will be used in multiple different contexts throughout a project. An example of this is your grid system. You’re likely going to be using this to lay out most of a webpage and thus it will be used within a wide range of contexts.
- Components - Components are used to furnish your website. They are for building specific features that might be used across pages, such as buttons, tab bars and cards.
- Trumps/Utilities - These might be considered a last resort. If you would otherwise be required to create a very specific selector to make your CSS work, you might consider relying on a trump instead. These classes themselves aren't very specific at all, however they make use of the
!importantflag to ensure that they're not overwritten.
This approach to writing CSS, to some extent, is likely something that you already do, whether or not you ever put much thought into it. To me, it makes great sense to structure your project in this manner, and having read more about it, there are advantages that I’d not even previously considered, such as a reduction in the number of styles that you have to scroll past in the inspector because they’re being overwritten elsewhere.
Un-invert the Triangle
I’d like to propose a system in which we flip the inverted triangle when we create our HTML elements. The idea here is to follow a structure for your class names which will improve readability for anyone working on your project. It is based on the ITCSS namespaces, but you can still apply it to your work without using the methodology or namespacing.
Put most simply, and most widely applicable: the system involves declaring the most descriptive class names first, with classes decreasing in specificity as the reader gets to the end.
Following the ITCSS structure, class names would be ordered as follows:
<div class="component object generic utility">
The benefit of this is approach is that we allow ourselves and other developers to quickly see, at a glance, what each element in our HTML is being used for. An element might look something like this:
<section class=" loyalty-scheme__intro container text-center font-size--large " >
From here, anybody new to this project or this particular element can immediately see it related to a loyalty scheme, which is likely the most important piece of information about it.
For elements with 3 or 4 classes, this may not seem like a particularly important process, but as elements begin to use more and more classes, including media query utilities, the class list can get very long, and it can be difficult to spot the relevant class names between all of the minor ones. For example, the following is difficult to understand with ease:
<section class=" padding-top--large [email protected] text-center container [email protected] [email protected] [email protected] loyalty-scheme__intro [email protected] " >
When compared to this:
<section class=" loyalty-scheme__intro container [email protected] text-center [email protected] [email protected] [email protected] padding-top--large [email protected] " >
Strictly speaking, I’m not proposing a direct inversion of the inverted triangle, since utility classes still reside last in the order. The reason for this is because they are typically descriptive of specific style changes being applied to the element, such as a margin being added, or a background colour being used, however they don’t describe the component itself.