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.
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)
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?
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
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!