Discovering Modularity And Reusability In HTML and CSS By Accident

Discovering Modularity And Reusability In HTML and CSS By Accident

Jan 30, 2021·

5 min read

Although my website isn't much in terms of layout and styles complexity, I re wrote the styles I had written before, on new year's. Even though the styles were less ( didn't need to have a pre processor or any other framework solution ), I had started to feel the repetition that had started happening – font sizes, colours, layouting.

I'm not a CSS expert, I get by. By complete accident I chose to do something, which, I later realised, has the potential to help save the css complexity in terms of restricting the exponential growth at which css is infamously known to go to, with every new markup that has to be styled in a codebase.

The creator of Tailwind deep dives into how a hybrid approach of Separation of Concerns 'semantic' classes and using Utility Classes together helps bring 'restriction' to what can be used in css. Read that here. This small blogpost was in fact realised after I read Adam Wathan's aforementioned article. That's when I realised that I had independently discovered the basics of this technique, though not in the precise and crisp manner that Adam's experience and creating Tailwind CSS had enabled.

Think about it, each new component or HTML that you are writing gives you the chance to write more CSS. Why? Because it's easy and it's quick. If you've used flex hundreds of times before in different classes, it doesn't hurt you to write it one more time in another class. In big projects this however doesn't scale.

At Goibibo Hotels, we had chosen to go with styled components as our choice to do styles at the time. One of the biggest selling points for us was automagic ✨ critical css. But the fact that our styles were going to literally be packed in components, didn't give us the leeway in terms of being able to 'reuse' styles in a way that would not only help us write lesser CSS ( by reusing as much as possible ) but also to translate that into lesser CSS that shipped to the end user. We couldn't keep waiting for facebook team's holy grail CSS in JS solution to come, which would automatically enable that by super smart code infrastructure tooling. We made a small trade off and went ahead with our choice.

Utility first CSS thinking changes that. It basically means that you are starting off with utility classes like in tailwind css

Screenshot 2021-01-30 at 11.37.23 PM.png

Following are the type of basic utility classes that I made for fonts, colours, basic spacing.

Screenshot 2021-01-30 at 11.50.11 PM.png

But it also means that whenever it makes sense, we should write css styles with 'separation of concerns' in mind. Which basically translates to having 'meaningful' classes which helps us see which part of HTML is what and styling it hence forth. Tailwind though helps to 'club' utility classes into these 'semantic' meaningful classes, so that html doesn't become a potpurri of css utility classes too much.

A small snippet of hand written written 'semantic' classes on my website: Screenshot 2021-01-30 at 11.03.01 PM.png

On my website, you can very roughly see a combination of both utility and 'semantic' classes —

Screenshot 2021-01-30 at 11.40.51 PM.png

In the coming days, I'm going to pick up some web pages and re create them in tailwind css and share what I learn.