Part of a good CSS architecture is file organization. A monolithic file is fine for solo developers or small projects. For large projects—sites with multiple layouts and content types—it’s smarter to use a modular approach and split your CSS across multiple files.
Splitting your CSS across files makes it easier to parcel tasks out to teams. One developer can work on form input components, while another can focus on a card pattern or media object component. Teams can split work sensibly and increase overall productivity.
So what might a good file structure that splits the CSS across files look like? Here’s a structure that’s similar to one I’ve used in projects:
- typography.css : font faces, weights, line heights, sizes, and styles for headings and body text
- forms.css : styles for form controls and labels
- lists.css : list-specific styles
- tables.css : table-specific styles
- accordion.css : styles for the accordion component
- cards.css : styles for the card component
12 3
CSS frameworks such as Bootstrap , Bulma , and Ulkit use a similar approach. They all become quite granular, with separate files for progress bars, range inputs, close buttons, and tooltips. That granularity allows developers to include only the components they need for a project.
The details of how you split your CSS will depend on your own preferences and practices. If your workflow includes a preprocessor such as Sass or Less, these might be partials with a .scss or .Less extension. You may also add a _config.scss or _config.Less file that contains color and font variables.
Or perhaps you have a more component-centric workflow, as with the component library tool Fracta, or JavaScript frameworks like React[5] and Vue.js[6]. You might instead opt for a single base.css or gLobaL.css file that smooths out browser differences, and use a separate CSS file for each pattern or component.
Something to avoid: organizing your CSS by page or view. Page-centric approaches encourage repetitious code and design inconsistencies. You probably don’t need both .contact-page Label and .home-page Label rule sets. Instead, try to find common patterns or components in your site’s design and build your CSS around them.
Using multiple files during site development doesn’t necessarily mean you’ll use multiple files in production. In most cases, you’ll want to optimize CSS delivery by concatenating files, and separating critical from non-critical CSS. We discuss optimization techniques in Chapter 3.
File organization is just one aspect of CSS architecture. Despite its position in this chapter, it’s actually the least important aspect. In my experience, most CSS architecture problems arise from selector choice and specificity. We’ll discuss how to avoid these issues in the next section.
Source: Brown Tiffany B (2021), CSS , SitePoint; 3rd edition.