When you ITCSS you have a plan to start your website project organized, stay organized, and end organized. Done right you end up with less code, that was developed faster, that is easier to find, easier to maintain, works with any website, can produce a stylesheet, increases efficiency, increases ROI, and allows you to pass a project off to new hands with greater confidence. What’s not to like? In my decade+ experience styling websites, Inverted Triangle CSS (ITCSS) is the very best front-end web development methodology I have ever used.
Buy-in: Why ITCSS?
Okay, I love ITCSS but why should YOU?
Why Not PatternLab?
Hey! What about Pattern Lab, you say? I hate to break it to you, but Pattern Lab is not a methodology. It is a tool for web developers, however, the idea its creator @bradfrost pitched along with it — Atomic Design — is a methodology. ITCSS and Atomic Design are essentially the same things — front-end organizational strategies meant for approaching styling modularly.
Between Atomic Design and ITCSS, ITCSS is the better practical option.
They are not all that different in their approach. The biggest snag that comes with Atomic Design is you are going to have to think of your own nomenclature for it.
In my experience, no average person has the slightest idea what you are talking about when you try to explain to them a website is going to be built of atoms, organisms, and molecules. You can see how these words have relatable meanings in terms of the general size differentiated breakdowns and incremental build-up of each stage of life compounding on one another… if you have some science geek in you… but, try explaining that to another developer, or worse a marketing person, and see how it goes.
Additionally, if you DO think up your own words for atomic design then you have stripped yourself of half the usefulness. When you go custom you remove the ability to transition code to new developers with efficiency and confidence to make changes. Stick with ITCSS and you can skip the name game and explanations from the get-go.
In web development, modularity is another word for compartmentalized. If you are already in the industry as a front-end developer or you are planning on getting into the industry as a front-end developer be prepared to code a lot of the same things over and over again. I mean it. Every client’s website looks completely different, but underneath many of the components they are made of are similar, if not exactly the same. Think about it, every website has headers, sliders, images, body copy, buttons, links, lists, main content areas, sidebars, etc. and so on and so forth. Visually, one version of a sidebar may be green and positioned on the left edge while another is orange and set to the right. Either way, you can minimize the effort it takes to create, modify, and maintain each component when the code that is responsible for a stand-alone piece of your user-interface has been segmented into its own folder/file space.
ITCSS is accomplishable (sort of) with normal CSS, but its highly advised you use a CSS preprocessing language like SCSS. Bless your ambitious soul if you’re not, but I wouldn’t go without.
Efficiency is the name of the game. When you are fully modular — reaching an “atomic” level of UI deconstruction — you open the infinite potential of layout arrangements. After even a small amount of components, your website can become hard to manage or maintain. Depending if you are coding from a pre-existing design you may or may not know what you’re up against ahead of time. On the matter of file organization for the sake of your own sanity, I recommend keeping things ready to scale from the start. That way when you are ready to scale you won’t have to get ready to scale. See all the time you saved yourself already?
Need a concrete example? Look at what the billion dollar burger giant McDonald’s is doing with their mix and match $3 $2 $1 campaign. You see, 3 x 2 x 1 = 6 possible ways of arranging the three digits. Therefore, from 3 UI components, you could potentially create 720 layout possibilities.
Another example? Bootstrap is a modular component-based website framework. I think it is well done, but it is a 1-size-fits-everything solution. In the field, some of how Bootstrap implements its styles clashes with how I recommend best using ITCSS, but their documentation is a great example of the types of style guides you can create using ITCSS effectively.
Modular efficiency translates into faster development and faster maintenance. You could swing that one of two ways — less time spent developing could lower costs for clients or less time spent developing could increase profit margins for the development team. Either way, someone ends up with a better ROI. If karma is on your mind maybe you should split the difference or 80/20 rule it for good measure. Development happens faster because you have a guideline for eliminating time wasted unnecessarily. You know, all the time spent thinking about what things on your website a style is related to and where that means it should live in your stylesheets. Throughout initial development, you can easily make an association between what you’re creating and where the styles should be. In the future when you need to return to the project for updating, you will still know exactly what and where a style lives because using ITCSS you gave semantic meaning to things, as well as organized your code in a modular way that is easier to digest than a single comprehensive stylesheet.
You’re in! What is ITCSS?
ITCSS is the Inverted Triangle Cascading Stylesheet. The name comes from the literal and conceptual visual the methodology preaches as its cornerstone philosophy — an upside down triangle. The inverted triangle is composed of layers similar to the healthy foods pyramid most of us learn in elementary school. Each layer represents a different ideological layer of style-organization. The idea is that the most general or broadest styles — visually, the base or widest part of the inverted triangle — are the ones at the beginning of your stylesheet. As you traverse down the triangle each layer of style-organization is meant for holding more and more specific styles. For example, you can start with styling for an HTML element, graduate to that element with a class that represents the most default form of an object composed from the element, and then on to an additional or extended class in the component level that represents a uniquely styled version of the object composed of the element. When you do it right you end up with the least amount of code — meaning you will save yourself any unneeded duplication of styles by the design of the methodology.
Take a look at how ITCSS breaks down the organizational layers. The one hard rule to remember is that there should not be any actual CSS output within the first 2 layers. If you are not using a CSS preprocessor like SCSS or LESS you can forget the first 2 layers all together. They are meant for variables, mixins, frameworks, and placeholders.
Breaking Down the Layers – How I do it in the field
I learned everything I needed to know to get started from the link above, listed as the source of the image.
Then I learned what really mattered by implementing ITCSS in real projects for real clients. Overcoming real organizational hurdles that cropped up throughout the development of Vermont Judiciary, The Washington Office of the Insurance Commissioner, Sappi, and GovWebworks — to list a few projects I have been involved with as a developer working with Portland Webworks, a Portland, ME based enterprise-level SaaS and website development company (@portlandwebwork) — has helped me understand ITCSS not only in theory, but in practice from experience.
Settings is for your variables. Things like colors, breakpoint widths, common sizes, and other repeatedly uses values go here. Do not put anything in the settings folder that outputs text.
Tools is for your plugins, mixins, and placeholders. Again, nothing goes in this folder that outputs text. These really are just tools that you will be able to use in subsequent folders down the line. In part to the sequential loading order of CSS, you cannot backward @extend or @include with ITCSS. e.g. tools can be included in generic, objects, elements, utilities, but components should not be included or extend within a lower level folder, such as objects.
Generic is the first layer where it is OK to output text. What goes in this folder are the most very basic aspects of your website. Think along the lines of box-sizing or any frameworks you need to load before adding your own customization on top (like Bootstrap, even though I’ve already told you it’s going to cause you headaches down your ITCSS road). I’m not sure the best way to articulate what this folder is for other than to say that the things you put in here aren’t actual “things” in the sense of what you think about as a piece of your UI, but they are also things that A) you can’t control (because Bootstrap is already coded) and B) that need to load (because any styling you do to customize bootstrap needs to load after bootstrap in order to take precedence).
Elements is the place for your naked HTML markup. All of your basic non-classed or ID’d styling properties go here. (a, h1-h6, ul, ol, li, blockquote, input, etc.). Elements are essentially your first introduction to a stand-alone thing (I don’t want to call them objects because that is the designated word of the next level of ITCSS). All the time, you need to think about: when you place these things on a page what do they look like and how should they behave? Meaning, if a span is always 100px wide then you would put width: 100px; here. Since that’s a horrible way to constrain such a broad and unclassed thing it probably doesn’t belong in the Elements level. Usually, this area is devoid of layout defining style properties. Primarily, stick to base stuff like colors and font-sizes.
Objects are what I like to refer to as component-legos. Objects are the styled version a single piece of a single component of your website. For instance, if you had a form the form would be your component. A form is composed of labels, fields, and buttons. Individually, each is not something that can be placed on a page by itself and offer any functionality, so they are not full-blown components. They are objects aka the building blocks that make up a component. A button is actually a rare exception that you might occasionally place by itself, but that’s okay. You could use these styles anywhere at any time, but more often than not you won’t.
Components are the mainstay of your website. A component is a single modular piece of stand-alone functionality. These are the blocks that your website is built from and are constructed things you styled in the last layer, Objects. Components convey color and size, as well as position and layout for the objects it claims as its own. A component’s styles do not convey anything about how that component is positioned on a page in relation to other components. Those type of styles are what I call contextual. Contextual styles belong in the containing thing and not the thing that’s being manipulated at its root level. For example, if your logo is 50% of your header area you would not assign its width as 50% with the CSS you have grouped together as your logo. You would assign width 50% in your header component’s grouped styles using SCSS nesting or you can implement an additional ITCSS layer called layouts that sits between Components and Utilities as an added level of modularity and organization. It really depends on how strict you are trying to be when it comes to keeping your CSS classes flat (or at a style specificity level of 1).
Utilities are your trump classes, your overrides, your final says, your pink-flamingos. These are things equivalent to a .float-left or .bold-text class. They are something you can apply to your markup that will be loaded last and always take precedence. In theory, the Utilities level is the safe place you can go to add an override class when you feel like you need to use an !important (in an ideal world there is never a good reason for an !important).
Resulting Folder Structure
/scss/ /scss/settings/ /scss/tools/ /scss/generic/ /scss/elements/ /scss/objects/ /scss/components/ /scss/layout/ (optional) /scss/utilities/
Tips for Establishing Your Base SCSS File
With SCSS you typically have a primary scss file like styles.scss and then everything else is modularized _partials.scss files.
Personally, I prefer including each and every partial file individually. It allows you precise fine-grained control over how each modular thing is loaded. Idealistically, load order of your scss partials within any single layer of the ITCSS structure shouldn’t cause problems and using globbing to automate your workflow is OK, but no one is perfect all the time and sometimes it does. It might seem tedious having to remember to @import each partial file as you create user-interface elements, but I promise it’s going to save you at least one unexpected headache down the road — probably on that one day you were really hoping to leave the office on time because that’s when unavoidable disaster always strikes, right?
Using ITCSS is good for clients and developers. ITCSS gives meaning and documentation to things front-end developers routinely recreate for every project. It speeds up the processes of development and upkeep resulting in higher returns on investments and more time you can spend doing MORE useful things. It minimizes the footprint of your code, reducing your opportunities to unnecessarily duplicate styling in multiple places through leveraging CSS’s natural cascading properties. And, having a tried and true front-end methodology provides a shining light to guide your way through development, an easy to read road-map for finding your way back to code you need to update long after you’ve forgotten writing it, and peace of mind throughout the whole process. And if you are wondering, ITCSS works amazingly with BEM.