DEV Community: Lia

Thoughts on writing cleaner CSS

Lia — Thu, 24 Dec 2020 20:06:28 +0000

Writing code that is easy to understand by someone else, and easier to maintain, make the top of the list of my priorities in my day-to-day work.

That is why I'd like to share some attitudes or principles I like to consider in the overall scope of writing and reviewing CSS.

I am using SCSS in my projects, so I will use it my examples as well.

1. Advocacy for conventions

There's a word I won't get bored of hearing, and that's the word convention. And maybe conventions are the first step to cleaner code.

From: What naming convention are we adopting? BEM? OOCSS? Atomic classes? Or a utility-first approach? And which of these are more suitable for our projects and ways of working? - to: What's our naming color system? What different units are we using to size things in our project? What best practices do we need to absolutely follow? - answers to these questions will not only lend a sense of order in your projects, but also potentially keep a window of conversation always open when it comes to best practices and practices that - when followed consistently, will benefit everyone in the team.

I had found that agreeing on conventions has driven the quality of our projects and, due to the nature of our projects, has made decision-making faster and even sped up development.

2. Pursuing flexibility over hard conventions

Conventions are great (I'm their biggest fan), but they might not all fit all your projects like a glove.

Take naming, for example. Naming is hard. But what if you can make it flexible instead?

A good example can be colors and naming them.

Some projects only have a short color scheme. So in that case, using a $brand-primary, $brand-secondary approach would do the trick.

What if a third, a fourth or even a fifth color might come up? Then something like this can be appropriate?

$brand-primary: #6200ee;
$brand-secondary: #03DAC6;
$brand-tertiary: #04d820;
$brand-quaternary: #044bd8;
$brand-quinary: #d80455;

But if we take maintainability and usage into account, this approach can become tricky as well if we are using them as part of a helper name.

Keeping an open mind and trying to find something that fits the needs of the project may be the way to go.

In my case, because I have lots and lots of base colors, I am switching to naming my color variables the same as the color name, trying to keep the color names very simple (blue, green, red - regardless of the shade of blue, green and red they really are).

It may be oversimplified, but it helps me be productive in this particular project. And it looks good used with helper classes as well:

// instead of `bg-tertiary`
.bg-blue {
  background-color: $brand-blue;
}

// instead of `bg-quaternary`
.bg-purple {
  background-color: $brand-purple;
}

In my other project, the color scheme is a bit alive.

It changes during development, and this isn't ideal at all. But it can happen. So putting on the flexibility hat once again is needed.

If we have lots of base colors and lots of shades associated with those, we can use a weight-based notation, similar to Google's Material Design:

$brand-red--100: #ce0125;
$brand-red--200: #e52d4c;
$brand-red--300: #a0182e;
$brand-grey--100: #e0e0e7;
$brand-grey--200: #b1b1bf;
$brand-grey--300: #f2f2f7;

In my case, for ease of usage, I assign a --100 modifier to the color that is used more often, and an increasingly higher value to a color used sparingly.

This approach is clean because it's easy to understand and allows me to accommodate a new color without a major refactoring.

3. Making helper classes predictable

Especially when it comes to helpers for font or background helpers, I like to keep things as predictable as possible.

Pursuing consistency between the variable name and the actual helper class - may decrease some of the mental load needed when using it. When using either the helper or the variable name, I need to remember just one thing:

.bg-primary {
  background-color: $brand-primary;
}
.bg-secondary {
  background-color: $brand-secondary;
}

.type-primary {
  font-family: $brand-primary;
}
.type-secondary {
  font-family: $type-secondary;
}

.type-16 {
  font-size: 16px;
}
.type-32 {
  font-size: 32px;
}

4. Keeping things simple

I try to keep a close eye on two things: HTML structure and the way I apply BEM-notation to my components.

For the former, the rule is quite easy. Trying not to use unnecessary div tags or containers - unless they are really required. Otherwise, leveraging the innate properties of the available elements, block and inline elements alike feels like the right thing to do.

If you are using BEM-notation, you might have been a witness to over-nesting and very big components - to the point where readability is affected and one can no longer know where the component starts or begins. The opposite of clean!

If I have a very large component, I try to break it up in a way so that components are better delimited:


// From this...
.header {
    &__title {
    ...
    }
    &__subtitle {
        &--blue {
        ...
        }
        &--red {
        ...    
        }
    }
}

// ...to this.
.header__title {
  ...
}

.header__subtitle {
    &--blue {
     ...
    }
    &--red {
     ...
    }
}

Again, for components with lots of elements, this can ease nesting and make them a little easier to read, debug and refactor.

Finally...

Asking questions, always keeping an open mind and being flexible, as well as pursuing flexibility can be the key opening the door to better collaboration, creativity and, ultimately - making our CSS (and our HTML) cleaner and more enjoyable to maintain and enrich.

🙋🏻 Documenting my front-end implementation frame of thinking

Lia — Sun, 07 Jul 2019 08:06:57 +0000

Long before I started working as a front-end developer, I was asking myself the question: how does a developer think about developing a website? For a newcomer like myself, attempting to answer this question seemed, at the time, an overwhelming task.

After one year of being a front-end developer, I am here to share the way I came to think about building a website.

My goal is to cover the thinking process that goes into the actual planning and building of a website in a very specific case:

The websites I help build are around 80% static and usually not extremely complex
I already have a good idea about the technologies I have to use and the file structure I have to adhere to
Finally, due to the nature of our projects, I am the only front-end developer who works on a project - at least until a first working version is finalised.

All in all, the only variable left in our equation is the website's actual front-end implementation. This is where the thinking process is fired up.

Design is my friend

Before delving into any kind of coding activity, I reserve some quality time with the design files. The main goal is to understand what I'm about to build.

I try to look at the details - to understand the overarching functionalities and possible interactions that may not be evident from the design.

But I also think that it's important to analyse the designs as a whole and understand not only the effort that the project needs in terms of time, but also if there are any difficult challenges ahead.

More often than not, I would do the following:

Meticulously go through the design files

It's also important to remember to check if you have the right format on hand; you should be able to easily take up measurements, export any graphics and check font sizes.

Write down anything that needs further clarification or details
Along the way, I would ask myself: is there something that could be improved in this design? Is there something that - for any reason - could be difficult to adapt on mobile? Could I propose a more technically-appropriate solution? Do I see any issues with the designs, overall?

Sometimes, the best people to discuss the above could be either the designer you're working with, or the project owner/project manager. The result of that conversation should be one or many user stories, as I will tell more about in just a moment.

Let's go on a... user journey

I am aware that there isn't such a thing as a "complete list of requirements". We can never know everything that we need or want in a project, especially in a software-related one.

But I think that once we start writing things down, we already have a good starting point.

As in any other circumstance - writing forces us to clarify our ideas about what we think that needs to be built. Writing things down boils down those ideas to just one, cohesive version of themselves.

Now that I am comfortable with the designs and the requirements, I try to break down the work into larger chunks, making sure I include test cases.

I found Gerkin to be quite useful for doing that.

Not only that test cases help my colleagues from the QA team to understand what exactly needs testing, but it's also clearer for myself in terms of what I should implement. Writing test cases early on it could indirectly document the decision-making behind any possible change - adding transparency into the entire process.

Divide et impera

Now I can start building! Well... almost!

The strategy I am currently undertaking is very much on the divide and conquer side. I am trying to build one thing at a time.

I divide my user stories into even smaller logical units of work.
There are a few benefits stemming from this, such as:

I'm keeping my PRs short, on-point, and thus easier to review by my colleagues
I can plan my work, and I can do that independently
Knowing what's ahead, I can keep track of the progress and have a better grasp of how the project is going
There's also the added psychological benefit of all of that: having a sense of ownership and confidence along the way.

Laying one brick at a time

While I work on smaller logical units of work, I make sure that these are - when possible - worked on in isolation.

I look at the designs and select the sections or elements that could be reused throughout the website. If I have a simple call-to-action section, I ask myself about the possible variations that that component could have, ignoring the context in which it should live. For the context itself, I will build another component and create its own rules.

Perhaps the most compelling benefit of this approach is the confidence of integrating an independent, fully-working component into another. All of a sudden, I have less things to worry about - and I can just focus on the actual integration between them, which, most of the time, could be much simpler to do.

This avoids overcomplicated style rules and messier HTML and it encourages better class naming.

In conclusion

These are the main aspects I have in the back of my mind when starting a new project, excluding the technical side.

I am always trying to look at what I'm doing - day-by-day - with a new pair of eyes and tweak, change or remove things that could be done better, or more efficiently.

If there's one thing I look forward in my daily work - that's change. And I hope that everything I wrote today will, in the end, be a fortunate "victim" of change.