Alternative or better architecture of sass guidelines to build multipage site - html

Question

In https://sass-guidelin.es/#architecture is adviced like best practice to build an architecture like that for a site, using partials and having only one CSS file named main.css (the only file that won't be a partial, thus the unique .css outputed from the preprocessor):
<pre>
sass/
|
|– abstracts/
| |– _variables.scss # Sass Variables
| |– _functions.scss # Sass Functions
| |– _mixins.scss # Sass Mixins
| |– _placeholders.scss # Sass Placeholders
|
|– base/
| |– _reset.scss # Reset/normalize
| |– _typography.scss # Typography rules
| … # Etc.
|
|– components/
| |– _buttons.scss # Buttons
| |– _carousel.scss # Carousel
| |– _cover.scss # Cover
| |– _dropdown.scss # Dropdown
| … # Etc.
|
|– layout/
| |– _navigation.scss # Navigation
| |– _grid.scss # Grid system
| |– _header.scss # Header
| |– _footer.scss # Footer
| |– _sidebar.scss # Sidebar
| |– _forms.scss # Forms
| … # Etc.
|
|– pages/
| |– _home.scss # Home specific styles
| |– _contact.scss # Contact specific styles
| … # Etc.
|
|– themes/
| |– _theme.scss # Default theme
| |– _admin.scss # Admin theme
| … # Etc.
|
|– vendors/
| |– _bootstrap.scss # Bootstrap
| |– _jquery-ui.scss # jQuery UI
| … # Etc.
|
`– main.scss # Main Sass file
</pre>
My strong doubt is that in this way there will be a only big main.css file that will embrace the css of others page too (thus, there will be only a main.css file to download but it could be significantly big) and second thing it will be very difficul to avoid conflicts (a simple example, the same id in 2 different pages home and contacts with different rules).
My thinking is that it would be much better to build home.scss and contact.scss (no partials) and so on, having so two different (in my simple example) scss files that will import their specific partials and in this way each page of the site will link a different css page.
Am I completely off track or maybe I have misunderstood the meaning of the guidelines, and therefore my design idea is good?

Answer 1

I can think of three reasons why you may not want to use the approach of using one stylesheet per page:
1) Caching
One main.css vs n <page>.css. You're either loading one file for the entire site, or one file per page. The consideration here might be first load performance vs subsequent page load performance. In my experience CSS files are not massive, so I'd venture to say that the performance gains from splitting your main.css file are negligible.
2) Redundant CSS
If you'd like _grid.scss on every page of your site, then you're loading it separately each time. The same CSS could be loaded by the user n times where n is the amount of pages they view. This may add up to a greater size/time than loading one main.css.
3) Developer experience
Every time you create a page you must include specific dependencies (i.e. #import). The creation and maintenance of this process may introduce unwanted results/complexity in your CSS.

Answer 2

First of all: Best practices are formed to
build optimal running pages
optimizing your workflow
save time to your work
using tested (=working) code solutions
avoid code conflicts
In most cases there are conflicts between the different goals ... and it is up to you find a solution which is the best compromise to your work and to your project.
A. One or multiple CSS files
Indeed, to the user experience (one of) the most critical attributes for a page is the time of page load. I.e. to a page of Amazon/Ebay/Google indeed HUNDREDTH OF A SECOND decides about MILLIONS of revenue. That is no joke, - there are very interesting tests they did on that. So it is not surprising that the tools to optimize your page (i.e. offered in browser Chrome) are looking the pages speed first.
For your CSS that means: best practice (solution) is the method, which speeds up your page measured in milliseconds. To achieve that most critical property is the number of files your page need to load: That is because the time which is needed to connect the Browser with the Server (PER FILE!) is more critical than download time itself.
So, simple optimized pages wrap code together and try to load only one CSS/JS file. A little bit more optimized pages not only compress the code but remove not needed CSS classes to the project. BEST OPTIMZED pages goes one step ahead: they write as much as possible CSS/JS code direct to the HTML file if possible. Just have a look to source code of Google pages ... Google tried to push that technique to the developers with their project 'Google Mobile Accelerated Pages` for some time ... (Not mentioned yet is the next step by using the 'new' technique to load the code only or to the time when it is needed i.e. by using React).
But that is not the best practice to all projects as there are other weightings more important realizing a best practice compromise to a project. So fastest load time is (really) important to eCommerce but not as much on i.e. simple landing-, product-, company-pages (depends on the project). In that case it's the other way around: If resources are restricted the SAVED WORK to build up the page is more important than page speed. And speed optimizing costs A LOT of resources.
In that case best practice is to use tested code, ready to use modules, layouts working out of the box with some little adaptions. That means: best practice now really is to speed up your page building. You do that using big frameworks like Bootstrap which generates a huge amount of not needed classes which has to be loaded to your project (hopefully only one file...) and which cannot be added to the html because of the size. And you use CMS systems like Wordpress and add modules. That way you are faster adding the content and your customer is able to do it on his own. But that means: nearly every module adds own CSS/JS mostly in separated files ... Of course you could optimize that ... but that means one more module which uses cache ... makes coding and debuging more complicate and needs more resources ... and as your customer restricts the resources the best practice compromise in that case is a project with a lot of added CSS/JS files with a huge overhead of loaded code. But to be honest: in most cases that type of projects works and so IN THAT CASE that way indeed is the best practice BECAUSE IT IS THE BEST COMPROMISE to the basic conditions for the special project.
So, what best practice is is up to your project and what attributes you want/need to optimize. Using only one main CSS file is a compromise I personally(!) would say works better in both cases. But that does not(!) need apply your work.
B. Multiple IDs in a project
But there is one thing which need to be said: using multiple IDs for different elements in your project is not a god practice at all and should not be the reason to use different CSS files at all. IDs should be unique not only in a page but in a project at all. So best practice in that case is to form a habit to name your elements (does not matter if Class or ID) in a project in a unique form due to the selector specifity.
That's because best practice compromise: THAT avoids (1) not needed work (=resources) to debug selector conflicts and (2) the need of using multiple CSS files (= better page speed).
You can achieve that:
Avoid IDs if not needed. In MOST cases classes works as well!
Use unique name structure for elements and use nested CSS to elements. That makes it easier to organize your code structure. (SASS helps to write such a code structure.)
C. File structure of project
Best practice of a file structure in a project as well has the target to speed up your works, to organize your coding sturcture which leads to better code. The shown structure is one of the commended ones which works to a lot of coders that way. So, the structure is tested and works.
But if another structure works better to you, don't hesitate to change it to your needs.
What I personal don't like on THIS common used structure are the huge number of directories. It makes me crazy to change between the directories. If I want just to change something in a basic partial file I need (1) to SEARCH and open the folder, then (2) search the file in the dir ...
More native to me is to organize the most needed partial files in ONE SINGLE directory. The trick: ADDING the NAME OF THE SUBDIR to the NAME OF THE FILE keeps the structure.
That way I am able to do the most work on one directory. I don't have to search a directory first and then scroll and search that directory ... I only need to scroll in one directory only. That speeds me up A LOT and keeps my head free when changing between the files!
Maybe you like to have a look to this:
SASS
|
| -- abstracts
= general files which serves the methods for the project
= and which are not often used
= BUT NOT the variables
= Note: most often these files are parts of (own) modules
|
| - functions
| - mixins
| ...
|
| -- myModules
= just the own modules to include (not to change / work in code)
= like your abstracts
|
| -- module-color-manager
|
| -- _files ...
|
| -- module-overlays
|
| -- _files ...
|
| -- ...
|
| -- vendors
= vendor modules
|
| -- bootstrap
| ...
| ...
|
| -- partials
= writing the css code
= working files (most used files = that is my one working folder)
= organized by adding (your) subdir names to file names
= better/easier overview
|
| -- _base-reset
| -- _base-grid
| -- _base-typography
| -- _base-forms
| -- ...
| -- _menu-main
| -- _menu-footer
| -- ...
| -- _structure-header
| -- _structure-footer
| -- _structure-sidebar
| -- _structure-sections
| --...
| -- _component-cards
| -- _component-carousel
| -- ...
| -- _breakpoint-mobile-landscape
| -- _breakpoint-tablet
| -- _breakpoint-dtp-small
| ...
|
|
_configColors (= my variables, colors separated for better overview)
_configProject (= all variables including settings for ALL (own&vendor) modules
main.scss
But once more: BEST PRATICE TO YOU is the structure which organize YOU the way to (1) work fast and (2) makes page fast loading. So do not hesitate to try out and adapt ideas from several suggestions to find the one which works best to you and your special project.