A scalable approach to write css

9 min readAug 24, 2022

in today’s software world the biggest issue we face while writing code is scalability.

code which is not written in a scalable manner is not maintainable in nature which ends up eating huge development efforts and time to manage it and it is costly

Now when it comes to writing css in a scalable manner there are two main issues -

some things that css in its very nature gets wrong
some things developers gets wrong while writing css

CSS’ fault -

the cascade and inheritance - it may be the key foundation of how css works but it comes with its drawbacks where we all have faced issues where we have written one css rule at one particular place and it breaks somethings up 100 click away in some other place. Thats because css operates in this global namespace where everything cascades and inherits and it can’t be fully encapsulated.
Very loose - so css is very nice and easy to learn which makes it very beginner friendly but at the same time it is very easy to write nasty code as we can not write css in a strict mode as such. it is very loose in that manner.
Highly dependent on source order - lots of languages are dependent on source order but css is very highly dependent on source order. we can easily break everything by changing order of a single rule.
specificity - the biggest issue while writing scalable css is specificity. specificity defines what cascades to where. specificity can undo many things.

Our Fault -

Lack of documentation - as css is not very expressive hence we should write documentations more often but we don’t do it as writing documentation can be expensive and boring.
Lack of Structure - unlike mvc structure where developers know where to find issues based on its a model, view or a controller, css doesn’t have that kind of a paradigm which results in unmaintainable code.
Mixture of ability - css is edited by everyone which results in varying standards and complexity.
Lack of knowledge - lack of knowledge either about css or the project itself may result in bad code and hit performance as new developers come not aware of what exists already (example: any helper classes which is already available, any sass variables which you can already change) and they end up adding more css and redundant logic.
Adding new styles at end of a stylesheet - this is the worst part when a new developer comes and adds styles to the end of the stylesheet which is completely against the css’ cascading and source order base nature.

“ Inheritance, specificity, and source order is one of css’s biggest fundamental problems. “

As we know every bit of css has the potential to pass some information on or accept information from in from of css. this is essentially dependencies.

“ Css is a giant global dependency Mess “

So we need a way to manage this dependency at a very low level. the solution to this will be a way of ordering our css effectively.

Ways of ordering stylesheets -

mirror the web page (old school) - so what we used to do earlier is to arrange our css just like a web page i.e writing the header styles first, then the body styles and at the end the footer styles

the problem with this approach is it didn’t play well with the cascade and inheritance nature of css.

2. Thematic chunks — we moved towards thematic chunks where we use to arrange our typographical styles, button styles, form styles in separate chunks.

the problem with this was now we how do we arrange this chunks. in what order we place this chunks.

3. Just stick it end of the stylesheets - last approach was to stick everything end of the stylesheets to make it work

the problem with this was we were adding more and more complexity at the end of the file and losing structure and maintainability.

Now any of these methods leads to this kind of a messy project.css file —

have you seen sometimes some styles are striked out when you inspect in developer tools ? it is a result of the above picture.

the last problem we are going to discuss is specificity -

as harry robert says -

to understand this better we will try to understand something called specificity graph created by harry Robert.

specificity graph is a visual way of looking into a project’s specificity

it’s a simple line graph.

let’s put the location of the stylesheet where a selector was found in the x axis and in y axis we put the specificity of that selector.

2. now if we put the specificity of most projects out there, we will find a graph like this -

so imagine we have this mountains and valleys in the graph where the mountains are the selectors with highest specificity.

higher the mountain higher the specificity which is why the highest mountain is an “! important selector” as we know in css.

now this isn’t bad exactly. what bad is when we are working on this specificity valleys, working on low specificity css we have to climb over these mountains to override them. the more the project grows there will higher peaks to climb while writing css.

So how do we solve this ?

the easy answer is to “write css in specificity order” to get rid off the mountains and valleys of specificity.

the ideal graph should be -

and we should order our css thematic chunks in this order —

Now that we have talked a lot about the problems with css.

lets talk about the solution —

now there are multiple methodologies out there on how to manage your css.

example- OOCSS, SMACSS, BEM etc.

but i am going to talk about a concept, a school of thought called- ITCSS. which i have implemented in my project and have practically seen the benefit out of it.

So what is ITCSS ?

ITCSS (inverted triangle css) is a layered architecture or should i say a school of thought on how to manage and order your css files in such a way that it solves the cascading and specificity problems and helps your project scale up easily.

You can use ITCSS with preprocessors or without them and it is compatible with CSS methodologies like BEM, SMACSS or OOCSS.

Problems it solves-

A sane environment that is accessible to lots of people
tame and manage source order and the cascading of css
giving manageable folder structure for our css files to live in
reduce waste and redundancy resulting in good performance
end the Specificity Wars.

ITCSS is a diagrammatic representation of a entire project

There are three main matrices we order stylesheets by in the ITCSS methodology-

generic → explicit : we order from writing most generic styles at the top to most specific explicit styles at the bottom of the layer as it better manages your cascading

2. Far-reaching → localised: so the begining of your project you need to write the style selectors, the things that kind of affects the whole DOM and at the bottom of the project you have helper classes which affects a small part of the DOM. this is what gives you the triangle shape.

each layer represents how much of the project that layer can affect -

“ if you stick to these layers you will find a layer at the bottom can not affect a layer at the top and the layer at the top can only cascade nice things down the layers. “

3. Low-specificity → high-specificity: third metric is to order your style files from low specificity to high specificity

The main idea of ITCSS is that it separates your CSS codebase into several sections (called layers), which can be represented as sections of an inverted triangle:

Layers:

Settings- used with preprocessors and contain global variables, font, colour definitions etc

2. Tools- in this layer we put globally used mix-ins and functions.

*note- it’s important not to output any CSS in the first 2 layers.

3. Generic — these are ground zero styles(normalise css, resets, box sizing etc). This is the first layer which generates actual CSS.

4. Base/Elements- styling for bare HTML elements (h1, a, p etc). no classes are here. These come with default styling from the browser so we can redefine them here.

5. Objects — class-based selectors which define undecorated design patterns.

6. Components- specific UI components. This is where most of our work takes place. We often compose UI components of Objects and Components

7. Utilities/Trumps- utilities and helper classes with ability to override anything which goes before in the triangle, e.g. hide helper class

Notes-

specificity slowly increases layer by layer
we affect smaller and smaller bits of DOM at a time
we are progressively adding styles and never undoing which helps with specificity wars and randomly override things

now our source order looks like this-

Benefits-

Manages source order — we know that our source order is roughly specificity based. our source order is based on how much of a DOM it affects.
Filters explicitness- now we have the most explicit styles at the bottom
Tames the cascade- if you inspect a ITCSS based project you will notice how much less strike through styles we have now
sanitises inheritance- now that everything is written in the right order inheritance will be logical
easier for new developers to make changes as they know where to change

How it helps scaling css-

no longer the end of stylesheet to worry about
add things into the relevant layers (usually the last layer).
Things never get more complicated, only bigger
Everything grows in a well rounded manner
the specificity graph keeps trending upward

there is a software engineering principle called Open-closed principle

Open-closed principle states things should be open to extension but close to modification

ITCSS makes you extend everything rather than modifying the global styles hence most of the work in ITCSS happens in the last two few layers where you can add new classes to make things more explicit

Scaling the architecture-

add or remove layers if, as and when you need to
not using pre-processors? Remove the settings and Tools layers
don’t use OOCSS ? Remove object layers
need theming? add theme layer

Thank you for Reading…..! ✌️
- sangeet joy