Is it common to use multiple stylesheets?

1

I’ve been going through the CSS on a fairly simple portfolio page:

It already feels like a maze, hunting through lines and lines of CSS to find what I want to change.

Is it common to split the stylesheets up? and if so, what are the conventions for naming etc?

I was thinking of maybe doing a separate stylesheet for my media queries at least.

2

yup. its easier to break your stylesheets up by concern so that you can easily find the item you want to edit just but browsing through your file tree

make a main.css file and use @import to centralize all you css files then just link the one main.css file to your html file

1 Like
3

Hello, jonathan.

For myself, I keep the number of stylesheets per page to 1. However, when I use React, I have one stylesheet per component. If the project ends up being quite small, then I will combine the stylesheets.

For HTML and CSS, I try as much as possible to order my CSS selectors as they appear in my HTML page, then media-queries at the bottom.

As for naming convention: I keep the name of my .html, .js, and .css all the same, provided they are linked. So, typically, I will have an index.html, index.js, and index.css.

Whilst I do not do this as much as I should, the best stylesheets I have seen have been almost more comments than CSS. Each stylesheet begins with a table of contents, and each section is ruled-off with a comment line, and numbered.

All of this is not typically what you would/should do after having written the code; this is far too much refactoring. So, in your case, I see no reason why you would not split up your CSS into multiple files.

Remember: If you split up your media-queries, the order in which it is linked in the HTML page is of utmost importance.

Hope this helps

1 Like
4

Thanks guys, this is all great advice! :slight_smile:

5

From a browser point of view, it needs to download and evaluate every file. So if you have lots of stylesheets, it needs to go off and download each one, then parse each one. It can do a certain number in parallel, so it’s not a huge hit, but it’s still a hit (note that HTTP/2 in theory makes it faster to have more small files rather than one big file, but not sure how well that works in practice with CSS)

So normally you’d use something when developing that lets you write seperate CSS files while you’re developing (much easier!), but that then glues all of those files together into one big file when you’re finished (more efficient!).

Examples are SCSS/Sass, or PostCSS, or any of the CSS-in-JS things (like the React styled components library). At simplest level, just some program that takes each of the individual CSS files and appends the contents of them to one output file.

One thing though. This isn’t a good idea:

Because its actually worse than having them as seperate files: it still works the same as having them as seperate files, only you’ve added another step. The browser now has to download a file, parse that file, find out it has an @import statement, go download that file and so on. It breaks the ability of the browser to load files in parallel, basically (note CSS tools like Sass/PostCSS/Less also use @import, but they replace the import statements at the processing step with the contents of file they’re importing, so it’s not the same result)

3 Likes
6

Is there some kind of visual studio code plugin that would do this that you know of? It sounds like an ideal way to work if so!

7

i heard a long time ago that @import was discouraged but never really looked into it. i havent used plain css in a while though. i typically prefer sass so i never really thought about it. do you have a recommendation for where i can read about similar ways to optimize browser code or such similar tips?

8

sass is like css but less annoying. as Dan kinda mentioned, it will take all your sass files and make them into a single css file. so what youd probably do is have a css folder and a sass folder, link your main.css to index.html, breakup all you style sheets with .sass files, centralize to a main.sass file then compile to your main.css file

hope that wasnt too confusing but its easier than it sounds. no extensions are necessary. just run

npm install -g sass

and you can compile your files like this

sass --watch <project folder>/style/sass/main.sass <project folder>/style/css/main.css

1 Like
9

Thanks! I ended up using the Live Sass Compiler. So useful! I’m really loving this atm and will go this way in future projects. Cheers!

10

I am currently using SASS, and I prefer it as it has more controls and features such as mixin (similar to functions), but what I like about it is the efficiency of keeping your code organised and clean.

From what I have learned, the bigger the project, the more likely it is to have split stylesheets. Going back to SASS, they have what they called it, a 7-1 pattern, which is a file system creating seven folders and you put your SCSS files in there. Although they are probably designed for bigger projects, I still use this method for better learning and productivity (unless the project is super small).

The folders and files’ convention can be looked up via these two resources for more details. Hope this helps! :+1:

11

You ideally want to break stylesheets into 2 categories (not necessary files, as now, if they are on the same server there’s practically no difference):

  1. Critical styles for the first things that page will show. These styles will be imported using rel="preload" in order for server to push them without waiting for html file to request them
  2. Non-critical styles, for all async components (components that will anyway wait for data to come in, before they will start rendering)

More about preloading styles: