Class Encapsulation Patterns on CSS: How it can make your life better or ruin it once and for all
One of the biggest difficulties for a programmer is naming the things that he writes, being possible to find hundreds or even thousands of guides, tutorials and good practice standards to find the perfect name.
CSS doesn’t escape this.
When we develop with CSS or any preprocessor, at some point we will put classes inside other classes, to specify styles or even organise the code better. Let’s assume that we want to create a header for our site, using SASS:
Simple, isn’t it?
Now, we need to make classes for the logo, navbar options, user image, etc.
Method 1: Tags, my darling!
Since I’m supposed know all the tags I’m going to use for the header, I could just put the style on them and we’re done!
Well, this is a problem.
Imagine that I need to use the <img> tag for some icon or a user profile image that we will also put in the header, we spoil the whole style!
Method 1 is ideal for elements with minimal complexity to none, which in Atom Design Pattern we call molecules.
So, if you need to do just a simple set of elements, Method 1 will not give you problems, like in the example below:
But we haven’t got there yet, let’s try something more complex…
Method 2: I’ll name it all!
Since using only tags we had problems with the complexity of the structure, let’s put a class for each of the elements inside:
Now, we will not have any problems with overwriting styles, since everything is well detailed and explained. Method 2 is excellent for complex elements, classes that will have n child classes.
But it has a very important negative point. Readability.
Let’s put our classes in the HTML structure:
It’s not hard to read, right?
Let’s imagine an element that has multiple div and inside has some tags together:
From that point forward we would have trouble both reading the classes and making specific changes to some elements in the html file, which makes it difficult for large projects or legacy projects that do not make use of SPA’s. Which brings us to Method 3!
Method 3: Why not both?
As my mother told me a dozen times, in this life you need to know how to measure the amounts of things you do and use.
Method 3 is basically a sum of Method 1 with Method 2, where you must be specific when the scope is larger to have no future problems with other elements and generic when there is simplicity in element structure.
For example, if we needed to put some coloured text and bold text inside our .header-navOption :
As you can see, the parts that we used Method 2 isolated well the classes and inside them, we use Method 1 to facilitate the reading of the structure
That’s all folks!
There are several methods and rules that we can use to build our styles in front-end development, but most of the time it depends on your experience and common sense to use the right methods at the right times.
Even though it is a short text, I hope I have helped or at least given a light to those who are starting or are already from the area looking for other perspectives.
Any question or point you want to add or even correct me, let me know, so we can talk about!
