DEV Community: Alex Dimitrov

Two tips to keep your CSS simpler

Alex Dimitrov — Fri, 07 May 2021 05:50:49 +0000

One of the approaches to write clean code is to also write simple code. Meaning — do your task in a way that is easy to implement, has fewer things that could break, and overall is easy to understand by other developers.

But how does that happen? Well, while achieving greatness might not be what we are going for, trying to simplify things most likely is 🙂

Goal #1 — clean up your code from unneeded rules

One of the easiest simplifications you can use is to not write code. Or if you already wrote it to delete it. Which one? Welp, the one that does nothing in particular. Here is an example:

...some-selector p {
    color: black;
    font-size: 1em;
    margin: 1em;
    line-height: 1.7;
}

Just looking at this snippet without knowing what is going on around it is not enough to decide what to delete. But, for the sake of the example, let's consider the most common use case that you might encounter and see what can we do with the rules:

...some-selector p {
    color: black;  /* Inherittted? */
    font-size: 1em; /* That is default */
    margin: 1em;
    line-height: 1.7; /* for consistency, we might want this set to the parent */
}

If we never set color , then it's inherited as black, so there is no point in defining it here.
font-size is the same, unless you changed the font size, there is no point in writing its default value. This often happens while people are debugging, trying to visualize, or changing values while testing.
line-height is slightly different — if you want visual consistency, often you'd like to have a specific font size for regular content and for low character-per-line content. If you define line-heights in many places, keeping things consistent could be a problem.

So, with cleaning up the above, it's possible to end up with the same result, but code that looks like this:

...some-selector p {
    margin: 1em;
}

We just overwrite the margin sizings. And this could be further simplified if that margin is consistent across the website - if that is the case, we can set it to the top root level just as p { margin: 1em } without the ...some-selector wrapper around it.

Other code that can be cleaned is generally something along the lines of:

div with width: 100% that doesn't have any other rules or parents that would redefine it
height: 100% for regular content (like a <p> tag inside normal <div> tag). That height does nothing.
Complex styles for simple results, but this is harder to showcase or explain — many times there are simpler ways to achieve a design
Reduce depth — in vanilla CSS it's deleting the parent, in Sass, it's moving your selectors a level or two up.
Rules that do nothing in particular (could be any)

Goal #2 - Style only what is needed

Well, this one sounds obvious, isn't it? But we quickly forget it and just go with it, it's not like there is some price to how much code is written, right? Well, there is — time and money come into play when maintaining a medium to large codebase becomes sluggish and people stay away from it.

One of the ways to reduce this complication is to really think about what has to be styled. How are components connected and which component styles what? Here is an example:

/* Demo component that does one thing only. */
.card { color: red; }
.card .card-title {font-size: 2em}

/* A <section> element right in the website wrapper */
.section-welcome {padding: 5em 0;}

If we need a card to be blue when it's inside the .section-welcome element, we have two realistic ways to do it: One is to follow the requirement 1:1 and write .section-welcome .card {}, which will overwrite the .card styles for us. The other approach is to write a modifier for the .card element like .card--secondary for example.

In this example, we can decide which of the two approaches is correct by looking into the design and the requirements. If the welcome section is very specific in its design (something unique for the website) and the .card element has to look different only there, then it's understandable to nest it inside the .section-welcome.

If the .card element changes are less specific and could be reused elsewhere, then it's best to have a modifier. A modifier is an extra class you can set to the component, which will style it and its children differently.

When you might want to use a Modifier:

When the visual change is common enough that it can be used elsewhere in the application or website like color, size, spacing changes etc.
When you can find it used elsewhere in the website. Note* if there are minor differences like 4px smaller padding or some opacity to only one element and consistency isn't what your designer needs but instead 1:1 results, then you can mix modifiers with nested selectors.

When you might want to nest your selector:

When there is only one change to a component on the whole app/website for a specific wrapper.
When you have many wrappers that slightly change a component in a different way. If you were to use modifiers, you would struggle to name them and you'd notice that you can't reuse them.

Some of the tips above are derived from bad practice in design - inconsistency, but in the real world, you will be bombarded with all kinds of scenarios — time limitations, bad designs, unrealistic expectations, difficult team members, lack of testing, change of directions and requirements, browser support that requires hacking, the editing experience (not just static code), backend team changing markup or forgetting a class (modifiers especially) and more. So, it takes experience in all of these problems to come up with the least problematic approach and apply it.

Overall, each situation might require you to think for a minute on the best approach. Don't forget you can refactor code! It's a major reason why big projects get hard to maintain and grow with bad structure — even if you think well of it, put a good architecture, when problems like the ones described above come up, we as developers might often forget things like "If you hack something now, come back to refactor it as soon as possible".

CSS Naming Conventions

Alex Dimitrov — Mon, 03 May 2021 08:59:47 +0000

If you are new to development as a whole, naming conventions might be something you've come across as a "best practice" and tips like "Pick one and follow it" were scattered across books, articles and tutorials.

I won't spend too much time in the what it is, but instead on the why. To be brief, a naming convention is a set of rules on naming things. Such rules might be "Always write with lower case" and "If there are two words, separate with a dash". Some might be more complex like "If a function returns a value, write get infront of it".

In CSS, there are such naming conventions as well, and they solve a problem, which exists due to the nature of how CSS is parsed by the browser.

The problem: You don't really have much of a scope control. Of course, you have at-rules @, that act as a block scope, but not much else. And nesting rules isn't really scoping, not in CSS. Because both examples: .parent {} and .parent .children {} sit in the same global scope. Yes, of course, .children's styles would be applied only if there is a .parent up the tree, but both rules are written in the same level, both are in the same file.

A detour to JavaScript-land:

To illustrate a difference, let's look into how CSS is scoped in the JavaScript world with libraries/frameworks/tools like CSS in JS. There, you can write your CSS again in the same level, but it is truely scoped in the component. It generates unreadable unique classes like .ts7hf which is only available to the component you defined it to. The tool manages the scope for you, you don't have to worry about leaking CSS to other components.

Back to CSS

In CSS, all your code goes into one file. Well, that is not required, **but in the common case that's how it goes. You might bundle CSS files into one, or you might compile Sass files into one, in the end, most often it's the same file. And all rules inside sit **in the same scope. How do you then manage what is applied where, and ensure that no styles leak? By defining a set of rules that a developer must follow. To know and follow, because they are not kept in check by a tool.

First, let's see how a style can leak. In the example below, we define a very simple rule, where all h4 children of our About us page must be red.

.page-template-about-us h4 { color: red; }

Then, in that about us page, we want to output a card component that happens to use the h4 tag for it's heading element:

<div class="card">
    <header class="card-header">
        <h4 class="title">Hello world!</h4>
    </header>
</div>

So now, we want all card elements to have tomato headings. We are doing wild design work here, don't judge!

So, we style it like this:

.card h4 { color: tomato }

Some more experienced developers will already notice at least 4-5 problems with the examples above.

Which color would the headnig end up with? The correct answer is one: It depends on the order of the rules, because both the first and the second styling snippet contain the same Specificity (part of the CSS fundamentals).

The h4 tag will apply the first color defined in the stylesheet, and then get overwritten by the next one, because it has the same level of specificity. The problem here is that you have to worry about the order of your rules. As stated before, they all sit in the global scope, so anything coule be inherited or applyed from any place. Yes, even that small file someone created 6 years ago that is still bundled and you are afraid to delete, because you don't know what elements it styles.

Fix problems by following rules.

The problem above happens when no rules are followed from the start of the project. Fixing that is a real struggle and requires a lot of dev time, QA-ing and risk of breaking the app/website. So it's rarely suggested. Instead, slowly rewrite parts of the website with new styles. There will be another post on that topic exactly.

❌ Don't target pure HTML tags with large-scale selectors.

The example above uses a class on the body element. All HTML elements H4 inside will have the style applied. With that, you only create problems for yourself. Instead, you should better understand the business goal that needs that page to style it's h4 tags and see if there is a better solution.

✅ Style tags by class name as often as possible

In the .card element, you should select the heading element by it's class selector. Most often, it's possible that it's HTML tag could change at some point and that change should be then reflected in CSS.

✅ Follow a naming convention for your classes

The example above uses .title for heading. Yes, it makes sense to name it title, but it's too generic and it isn't scoped to the .card element. A simple change like writing .card-title would increase readability and reduce the chances of styles clashing. Think of it this way — how many components on your app/website would have a title of some sorts? Would you feel safe, naming all of them with the same class? How can you be certain no styles would leak?

What naming conventions exist?

Alright, so we saw some problems that exist because we don't set rules or think about how everything works together. All great, but the example rules above are too few and don't cover all cases, right? The good thing is that people already came up with rules that you can take for free and follow. They work both on small and large scale applications. Which one is the best for you is maybe a bit trickier to decide, so the best thing you can do is build the same app using different conventions and see for yourself.

BEM — Block Element Modifier (documentation)

Maybe the most populer one that comes to mind is BEM. It is easy to understand, the concept is straightforward and just reading a class could tell you about what's going on (when written well of course).

OOCSS — Object Orientated CSS (Guide)

The idea of separating visuals from structural styles is baked into the Object Orientated CSS approach. It focuses a lot less on how you name your classes and more on the idea of what they represent.

SMACSS — Scalable and Modular Architecture for CSS (website)

SMACSS focses more on organizing your styles — placing each selector in it's proper category like Base, Layout, Module etc. It's similar to the categorization done in the previous post in the series: The Component Types in Front-End Development. I have personally taken a ton of the practices in SMACSS in my day-to-day work like the state management (is prefix) or the avoidance of element selectors among many others.

ITCSS — Inverted Triangle CSS (article)

Similar to the Component types, it's a method of grouping your styles based on the context and their purpose. It goes from the most broad selectors to the most specific ones. The article above is a very good read and following that line of thought is always helpful in your code structure.

AMCSS — Attribute modules for CSS (website)

It's a very interesting approach that takes selecting elements to a new place — ignore the Class attribute and use all the custom Data attributes you can add to an HTML element. Instead of writing .button, why not do [am-Button] ? What I liked here is that you can visually differenciate different types of classes. A button can have it's core .button class, but it can also be a js-toggle-modal, which should be maintaining some interactivity. Both are very different, but also applied to the same attribute "class". With AMCSS, this can be separated visually. However, I am kinda iffy on the look of the selectors.

Your naming convention

All of the above are some of the more popular one other developers came up with. But the thing is that you will probably find as many naming conventions as many developers there are. Some will dislike an idea of BEM, so they will skip it and in it's place take something from SMACSS. Some will like the idea of ITCSS's separation, and appliy it with the AMCSS attributes.

I personally love the BEM idea, but it doesn't match the WordPress standard of writing classes with lower case, separated with a single dash. And it's fine, because I can follow the same thinking of BEM, but without the __ and -- as separators. I could also use the .js- and .is- prefixes too from other approaches. And the cool thing - it works, it makes sense and most importantly it's consistent.

Which is the final takeaway from this — do whatever works for you, but do it consistently across the project. Ideally, across all your projects. That way, all developers will expect where to find things and how to write styles without looking at long documentations and set of rules.

The Component Types in Front-End Development

Alex Dimitrov — Sat, 01 May 2021 16:28:17 +0000

As a front-end developer, it's helpful to be able to differenciate the type of components you are working with (or building). Why? Because by knowing the abstraction level of a component, you can composite them in a way that is easier to maintain, extend and modify in the future.

In this short article, we will define different types of components and order them by level of abstraction — the lowest on the list, will be components that do one thing only and are very specific, and up the list are very broad components that could have anything inside really.

One important thing to note however as could create confusion — we are not talking about components (elements) like div or a, but instead components we define as developers.

The list doesn't look into the type of data these components hold or how it's updated or anything of this sort. This list is used when you get an image of the design you need to create and you produce a clean HTML file from it. That's it. No state, no APIs, no backend, SPAs, anything. This list is just the HTML structure in it's purest form.

1. HTML Element Wrappers

It's a Button component. Or a Image component. A Link, List, Avatar, Date, Select and so on. Of course, they can get very complex very quickly, but in it's base form, it's the same as a regular HTML Element + a custom class or a couple of nested HTML Elements like <span> or <svg>.

From a very small scale like a <Button> with a couple of colors like Primary or Secondary, such wrapper could grow to the Select2 library's scale for example. It remains a select, but with a ton of options and views.

Example of HTML Element Wrappers:

Button
List (like a checklist or ingredient list etc)
Heading
Date (like when a post was published)
Counter (example: 17 successful clients)

2. Group of elements

The grouping is a single step above the HTML Element Wrappers — it's a collection of such elements. It's not really a component that can be described as a "Card" or "Comment" or "Header of the website" etc. It's only serving the purpose of wrapping the first level, so that you can style them as a whole.

Let's take the example of the Button component: When you create a <Button> component (or <button class="button">), it applies all the styles from the .button class. But how would that look like when there is a second button next to it? It's too generic to give it a name. You can't really call that class="buttons-for-signing-up". It's too generic, because as soon as you need to reuse these styles for moderating a comment, then it compeltely misses the point.

So, this is where we need the grouping component — an abstract component that cares only about the component that is inside it. Not the data, the component. So, in this case, you can name it .group-buttons or .ctas-wrapper or .buttons-wrapper etc. With a name like that, it doesn't matter if the buttons say "Log in" / "Sign Up" or "Reply" / "Delete". It is still a wrapper. Of what? Of buttons! That's it, nothing more.

The second you wrap your very generic first level component with a specific name, you lock yourself from reusing it. And this goes agains the goal of building a reusable, maintainable and extendable structure.

3. Layout

Layout is a wrapper around other components, not just first level ones. A great example, that many front-end developers know of a Layout is the Grid system. Yep, the same grid you see in Bootstrap, Foundation or the good old 960 grid. It's abstract, becasue it doesn't care about what you put inside. It lays down the structure of your page, similar to HTML itself — what is on top, what is on left, right, bottom etc.

Layouts are a major part of any web app. You can separate a dashboard layout in piece like "top navigation", "main navigation (left)", "main", "footer" and each of those layout sub-components could contain more layouts. This is where CSS Grids shine, btw.

With this knowledge, you might already guess that naming layouts is tricky! Abstract names like the frameworks above use are perfect — small-6 or lg-3 etc, but, what do you do when you want your own? Like Main content of blog post and it's sidebar? When you name such sections, try to keep your names abstract as well, don't name the sidebar as "sidebar", because sometimes, it might hold something completely different. Example names you can use could be "Primary" and "Secondary" or "Primary" and "Aside". None define what exactly goes inside. Naming is maybe one of the hardest parts in development as a whole, not just Front-End, so don't worry if it takes more time to come up with a good name, it will be worth in the end.

As a takeaway - keep the names abstract in this level.

4. Unit

This is the first level where we actually can name a component with a specific name.

When you hear a Component, this is probably what you think of. I called it Unit, for the lack of better name probably at this moment and the confusion it would create if I called it a "Component". Well, everything in this list is a component in one form or another. Heck, even a <a> element is a component if you think about it.

A Unit is something you limit a little, compared to the previous two levels. For example, a (or <div class="comment">). You could have literally a single

tag inside with the comment, but most of the time it would take the author of that commebt, his avatar, a link to reply, a number for which comment this is, when it was posted, replies to it and so on.

Another unit could be a (or <div class="card">) which can hold a heading and a body, maybe a footer. Each of these subcomponents could hold data of any time. This is a bit more generic than a comment as you could wrapp your comments in cards. But the common remains — they are build using smaller HTML Element Wrappers or groups of such or other small components and even other unit-level components.

A Unit is your escape hatch when you need to go specific. You are much more free to do it in this level than in the "Specific standalone HTML Element Wrapper" level, because your units, while named, are open to more types of content. They work mostly as wrappers like in the second level.

5. Specific standalone HTML Element Wrappers

That's a mouthfull, maybe shorter name would be helpful here. But it describes it good — for this one, you are specifically defining what a component should be in it's name. The name this time is not abstract — meaning, it won't hold just any value or content, but something specific.

A Button component can hold text like "Log in" or "Click me" or "Close" or "Download our FREE Ebook". But a component like PDFDownload or <button class="pdf-download"> is much more specific. You shouldn't expect it to open a modal, right? It should download a PDF. Of course, you can inherit styles and attributes from the first level component like Button, but you make it more specific. And this decreases the cases when you can use it.

While this is a smaler component in terms of HTML tags than a Unit, it's less abstract, meaning, it has less use cases. Ideally, keep your specific elements to a minimum. You can even imagine that you have a budget like $1000 and each specific component will cost you $100. Why? Because the second you want to reuse some portion of your component, you have to create a new abstract one, then inherit it in your old specific component and in your new one. If you don't do it, you get repeated code. Here is an example:

You create the PDFDownload component, that should look just like a button. And you even use the <button> HTML tag. It looks like a button, it acts like a button, but it's a PDFDownload. Why? Why not just use <button>? If you change the boder on all your buttons from 1px to 2px after a year, you will have to manually do the same for your PDFDownload component and any other of it's kind.

Duplication is Evil! The concept of duplication is mentioned in countless contexts, not just in development. Conversion Rate Experts wrote a great article on that topic, which looks into the problem from the perspective of information management and how that could even ruin a company. The same thinking is applied in front-end development. Write as little code as possible and try to keep your abstract components abstract and introduce as little specific ones as possible.

6. Page

Pages are the same as specific elements, but in a much larger scale. Instead of the PDFDownload, which is just a button, a page holds everything you see on the screen. A page is what we call the "Homepage" or "About" or "Contacts". You might ask, well, how is that a component?

Remember, a component can be a single HTML Element or HTML Element that contains sub-components or children. What is the largest such HTML element you can think? The one, for sure! Or more often the

as it has all the structure that we care about. That is the reason why WordPress for example puts a class in the with the page ID, page template, type of page etc. Because with that, you can target all Blog post pages for example or the About Us page and so on.

And this is low on the list as it's even less reusable than the specific standalone HTML wrappers — you can have 50 PDF Download buttons, but how many About Me pages do you have?

The lower we go on the list, the less styles you want to write for such components. So it's easy to say that it's usually a bad pracice to write styles for pages, because when you do that, you risk to end up with styles like:

.page-template-about-me,
.page-template-homepage,
.post-1241,
.page-template-resources, ...... {}

Maintaining that list of selectors above is a nightmare and it's easy to mess it up as it keeps on growing. Instead, try to break down your complex components into simpler ones, keep your components more abstract. Use modifiers and variations (more on that in an upcoming post).

Final words

The list above is a guide to what types of components there are and how specific you should get when you create and reuse them. Every front-end developer might have a different naming for such components, might have a different view even and different best practices. This line of thinking is what helped me work on hundreds of projects, many of which were maintained and continue to grow 4-5 years after the first line of code was written.

I have noticed that the lower on the scale I go, the harder it becomes to manage the project. Code smells like the selectors example above appear more often, patches with deeper selectors increase in frequency and overall, the joy of working on the project dies little by little. And I will be honest here, it's very hard to find motivation to work long-term on a bad codebase that is constantly patching old codebase with bad practices, that increases the specific elements and the only abstract ones are the oldest from when it was first build.

It's a responsibility of the developer to keep up with the best practices during all development cycles. A couple of minutes more thinking about a good name, a short search on the existing components, a quick chat with other developers — it all adds up to a better development experience and lower cost for the clients.

The instant gratification of fixing a bug quickly, commiting and deploying is a slippery slope. Doing that without improving the codebase afterwards results in the described scenario above — messy code with a ton of overwriting, specific classes that can't be reused or cases where you use the CommentForm component for a "Get a demo" page, just because your styles on the commenting form were so nice, that the client wanted the same for the main landing page that convers visitors to potential clients. Visually it's pretty, but in the code... well, it doesn't make much sense.

What are Components in the front-end and why do we need them?

Alex Dimitrov — Sat, 01 May 2021 16:25:47 +0000

Let's first address the following problem: It's not super clear what a Component is. Well, many experienced developers will think of the same thing, but that is not true for those who are new to the Front-End world or haven't really though much about architecture of their codebase.

One of the reasons is that the front-end field as a whole is big, there are many developers and leaders that name things differently and might not always agree to what is what. Different things are refered with different names.

For example, what is the difference between Component and Element? Or something else — when you hear Component, do you think about React? Or Vue? Or an HTML tag or tags?

Let's define what is a Component

A component can be thought of as a group of one or more HTML Elements. Elements are the regular HTML elements you can think of — <span>, <div>, <section> and so on.

It's good to start simple, so we will look into a <button> component. This is your regular HTML Element, no React, no nothing. It will render a simple button on the page. Or would it?

The element will render this small pill shaped box under the text.

As you can see, it doesn't look good at all. To make it more useful, we can provide it with text to output inside by wrappin that string with the tag. If we want, we can also give it an attribute like disabled which will fade it out. All of this would result in:

This is all very simple and intuitive. What we really did was to pass values to a function. That function in return outputted a result which was the button you see above. That in of itself is what a Component does! So, from that, we can easily say that any HTML Element is also a Component.

Great, but that's not all, otherwise we wouldn't use two names for the same thing, right? A Component can also be created by combining more HTML Elements into one. Here is an example of a Card component:



<div class="card">
  <h1 class="card-title"></h1>
  <p class="card-description"></p>
</div>

It has three HTML Elements, but it's one Component — Card. Do you see any React code there? No, because a Component is a concept that can be applied to many things. In the front-end world, this is mostly what you see above. Now, let's see the same component in the context of React:



export default function Card() {
  return (
    <div class="card">
      <h1 class="card-title"></h1>
      <p class="card-description"></p>
    </div>
  );
}

What it does is to provide you with the ability to output that markup by just calling <Card /> And in the spirit of HTML Elements, you can also provide arguments that can modify the output, just like with the button example above. In the world of React, such arguments are called props and are passed to the function via the props object. No need to go into details here, even if you haven't worked with React it's completely fine.

So, to sum it up: A component is a group of HTML elements (or just one). That's about it. For libraries like React we can add more settings like passing props and running functions inside, but it is still a Component.

Why do we need components?

This question is important to understand how to use them. In order to use a tool, you first need to know what the job is, right?

The Front-End developer's job (aside from styling) is to provide the markup structure of an application or a website. Throughout my years of development, I've noticed that the markup is the most overlooked bit. Many developers ignore it and jump straight to styling and functionality. But, turns out that this creates a major problem. The markup if your app is it's skeleton. You can't really build properly without having a good structure that can be reused, modified, extended and so on.

One of the core skills of a programmer is the ability to break down one large problem into many smaller problems and tackle them separately.

But, the trick is to be able to stich them together to solve that big problem. Your large application is your big problem. Break it down into smaller ones, by separating pieces of it into components. All these components then must work together. And the structure of combining them and reusing them is this important skill we need to develop.

To think in Components in the context of HTML is like to think in Functions in the context of a program. You don't want it all dumped into one place, right?

Breaking down the application into components helps with:

Create a map of the application - it's easier to navigate and understand your building blocks from just reading class names.
Scoping - you can style HTML Elements without the worry of breaking others. You don't really need CSS in JS to achieve that.
Reusability - You can define your components once and then call them, by passing arguments to fill in the data. This works great with libraries like React, but it's also completely achievable with more standard PHP projects or HTML Templating languages.

And together with everything above you open up the door to your teammates.

This is just the start

If you found out the above as helpful, then please continue reading the other posts of the series as I will be getting into practical examples and guides that will help you structure your code. If you already knew everything there, I still believe that in my following articles you will find good tips or at least a different point of view, which will help you structure your codebase and reduce the time you spend on debugging, adding new code or maintaining the codebase.