Organize and optimize your CSS code in your projects

▶

I'm going to tell you a bit about how I arranged the CSS for my project on DesarrolloLibre, in case you're interested and can pick up some tips. This will be useful if you have a similar development or if you simply want to know how you can organize yourself.

Tip One: Verify how many modules your application has

The first thing we need to keep in mind is how many modules the application will have. In my case, you could say it has three main modules:

1. Academy Website

I consider the Academy website as an additional or different module from the Blog. Although this is a Vue application, and the technology doesn't have much to do with the final CSS, simply because of that fact I consider it a separate module. Besides, it doesn't share the same links and has a slightly different organization.

2. The Blog

This is the main content module.

3. Management Module (Dashboard)

This is the module where I manage the application's content.

CSS Considerations in the Dashboard

Here, in the dashboard, I use the CKEditor plugin, just as you can see. This plugin requires additional CSS, as I have explained in the course, to correctly display bold, headings, ul (unordered lists), and all of this stuff here, since Tailwind breaks it.

Therefore, in this management module, we already have an additional CSS that, for example, I won't have in the Blog, since I don't use the CKEditor plugin anywhere in that section.

Tip Two: Verify which designs you will manage per module

Really, there would only be two differentiated style modules:

• Management Module (Dashboard): Mainly because of the CKEditor comment before and any additional little thing I'm going to put so that the design doesn't break.
• End-User Modules (Blog and Academy): These two modules, although they include different technologies, you could say they have the same design (at least for me).

CSS File Organization by Module

Now we can know how many CSS files we are going to create:

1. app.css File (Dashboard Module)

One will be for the Dashboard, which in my case I called app.css. (I have it repeated; I really have to check which one I'm using in the end, as I don't remember).

• Content: In this file (or the one I'm using), you can find the CSS for CKEditor, just as you can see. This is the CSS that I always use for CKEditor. I could put Tailwind rules here, but that's another thing.
• Purpose: Here I'm going to add the CSS that is specific to my dashboard module, since I won't need it in the Blog, so as not to mix things up.

2. CSS for the Blog

The next one will be the Blog file.

• Content: Here I'm going to place the design for the content elements (the h1, p, ul, images, and others). It's a bit of what you can see here.

3. Base CSS

And another file will be the Base one.

• Purpose: Since it's the same application in the end, we're going to have similar designs (that is, I want to use the same typography in both modules). In my particular case, I'm going to use... (the rest of the sentence is incomplete, but the concept is that common styles go here).

File for Common CSS

To easily inherit styles (instead of copying and pasting, or directly injecting the Blog file here and breaking all the style), we do the following. We put them directly in another file which would be the common one, (which I call base.css). Here I add the design, for example, for cards, the behavior that links, buttons, and other elements common to my whole application will have:

base.css

.card { @apply mt-6 bg-white p-6 rounded-md text-gray-500 shadow-lg dark:bg-gray-600 dark:text-gray-100 }

Summary so far

In summary, here in the base.css file, I'm going to put the design that is common to both modules.

• Just as you can see, everything I'm going to use (which in this case would be, for example, the buttons), I import it from the files that contain the assets or exclusive designs of each module.
• Using the @import tag that we have in CSS, I place base.css in both files. For example, in the Blog's CSS, I place base.css.

Therefore, I am inheriting this design that is common between both platforms or both modules we have.

resources\css\blog.css

@import 'base';

For the rest, I'm left with the specific design, about which I want to give you another little tip.

Before, I always had a lot of problems with this, especially with the topic of images. What I used to do was create a tag called, for example, post (or similar), and there I placed a specific design. That is, I made like a module within another module.

For me, post was basically this publication; therefore, I always tried to change the style a bit so that it was different from the rest of the page (for example, from the listings and others). Once I do this, I don't even know why I did it, but I no longer recommend it to you.

Tip Three: Designs from the root h1 YES post h1 NO

️ Organization of Modules and CSS Styles

The organization I would recommend for your modules is to define the styles directly from the root. That is, you apply the design directly to the base elements such as h1, h2, h3, etc.

Try to avoid doing this (defining very nested or specific styles lightly), because in the end it will complicate your existence a lot. You will define some specific styles this way, but then you will want to define them in an even more specific way. Surely, this will involve touching margins or different positioning, which will be a tremendous problem because the styles will start to overwrite each other. Sometimes the styles you placed in one place will be overwritten, and sometimes the ones you placed at the root. Besides, everything will be very disorganized.

Final Recommendation for CSS

Once clarified what my scheme for working with modules based on CSS is, the final recommendation is the following:

Styles from the Root: Always try to define the styles from the root. (This is a copy you can see, it's not the file I'm using, but I show it as an example).

• Definitive CSS: My final CSS is to take the designs from the root, that is, without placing post-section or anything here. Everything goes from the root. I try to adapt it as best as possible based on what was explained. You can see it directly in the selectors: h1, p, ul, li, and little more.
• Avoid Complex Nesting: Obviously, I want a specific design in this case to change the typography. But what I mean by avoiding clutter is that you shouldn't be placing nested selectors. For example, that you place one thing in content here, then an h1 inside content, and then you complicate things by defining another selector for post and others.

Alternatives to Messy CSS

Try to create a design that is common for everything. If this is not possible, simply work based on components (either based on Vue, Livewire components, or the technology you are using). Make those components there.

But avoid making this mess in CSS because in the end, managing this file will be a nightmare.

To quickly show you the CSS (which is obviously common and you can download it from the development page), you can see it from there. Sure, and here are, so to speak, specific components that I need, since it's a development like any other.

Is there any other section you'd like to review or would you like me to give you specific examples of how to define styles from the root for h1 and p?

CSS for components Yes, NOT for root

In this case, I require some specific components to add spacing.

Here too is a bit of what was mentioned before, and I consider this fine. The problem would be, again, if from here (the code) you placed something similar to this:

style="margin-top: 20px"

This can cause you quite a few problems, as these are styles that are not centralized.

These components are specific designs that you can decide when to use, therefore, their use is optional.

However, if you define the style the other way (inline or within a template), it will be mandatory, since that tag would be inside a template or layout (that is, a view within your development).

Here you can see that everything is managed from the root of the CSS, and this is the way I was able to use the mechanism to have the CSS organized:

resources\css\blog.css

h1, h2, h3, h4, h5, h6, p, ul, ol, li { @apply text-gray-800 dark:text-white } h1 { font-family: ProtestGuerrilla-Regular; @apply  relative } *

If you're wondering about the design details in my application, you can see that I have the main element here, which is the <h1> (main heading).

I created a particular class for it to give this element a green color. I do this to include these little "things" that seek to make the content a bit more pleasant to read, even though, in the end, almost no one likes to read.

That would be the recommendation I could give you about these design elements.

Common size for image and containers

Another important point, which was another problem I had here and just remembered, was the blessed image, because this subject was giving me too many problems. And it was mostly because of this: I created, so to speak, a container, in this case I always called it post, because I always managed different sizes. Here, for example, it is a width: full, but here notice that I'm already placing a max-width on it.

resources\css\blog.css

img { @apply rounded-sm shadow-lg mt-4 mx-auto my-4 w-full; max-width: 500px; }

️ Image Management and Avoiding "Crooked Code"

The problem arises when different image sizes are required to work within the content, which can become a nightmare.

My recommendation is not to implement the sizes directly in the CSS because, again, the code will become quite "crooked". Or, at least, do it based on classes, such as image.middle-size, where you define half or a third of the size.

Definition of Sizes and Containers

My recommended strategy is the following:

• Maximum Size for the Image: Always define a maximum width (max-width) for the image and simply play with the container where it is housed.
• Use of Containers: In my case, my images are always inside a container. Here I am using a Grid System with a container class.

Therefore, if you look at the CSS I have applied:

• The image has a width: full.
• It also has a max-width that I defined, for example, at 500px.

This prevents the image from growing enormously and taking up almost the entire screen. The person who wants to read your content is not interested in the image, but in the text. The image should simply be a representative element and a visual aid commensurate with its value.

Main Tip
Define a maximum size that is common to all your content. If you need to change the size, simply manipulate the container.

This maximum size is the one always allowed. For example, in a publication, you can see that I've "shrunk" the container a bit (I put it at the end; this depends on the scheme, since they all have video, but I'll look for an old publication). 

In an old example, the image only occupies a small piece of the space and not the entire width. For this, again, I used some containers or a grid system.

Conclusion and Call to Action

This is what I wanted to show you. I hope you were able to, at least, consider something interesting. If you have any comments or if you think about what you would improve in what I just explained, or if you have another trick or tip to optimize the CSS, you can comment on it.