Skip to main content
U.S. flag

An official website of the United States government

Dot gov

Official websites use .gov
A .gov website belongs to an official government organization in the United States.


Secure .gov websites use HTTPS
A lock ( ) or https:// means you’ve safely connected to the .gov website. Share sensitive information only on official, secure websites.


A site’s architecture should be based on its goals and purposes. This means the guidance here should be adapted to different sites and situations.

Modular or component architecture

When using a modular or component architecture, every page is broken into a series of modular components. There are two sets of these components: components and modules. The architecture starts out with basic HTML element rules: HTML, p, a, form, etc tags that than have components and modules written on top of them. Components are very basic structure such as buttons, blurbs, navs, and positioning structures like insets, island, and enclosure. From here, modules are built with these components. This architecture also attempts to keep the specificity trend in an upwards curve as you move down in the file (more on this to come).

  • Start with an elements file for all tag rules (a, h1-h5, p, *, html, body).
  • Create component files for each structural element, such as buttons, navs, etc. These are mainly class-based and use BEM or another naming scheme.
  • Create more specific structure with modules. For instance, if the logo image and text needs very specific treatment, use a module.
    • Build modules from components through mixins, extends, and HTML.
    • Modules can have higher specificity, it’s fine to use deeper nesting.
  • Have an overrides file or folder comprised of global rules that are meant to override components and modules.
    • These can be generic utilities.
    • A good thing to put here are breakpoint-specific rules, such as hiding something at small breakpoints.

File structure


For the util, typography, elements, and overrides files, once they grow too large (300 lines or more) in size, split them into their own folder with sub files.



As you likely know, CSS rules that are later in the file override earlier rules. This means Sass imports can be used to control inheritance and specificity.

  • Start with base elements.
  • Move to single nested classes and utils.
  • Move next to more specific classes, often with nesting.
  • Move next to overrides, possibly with !important rules.
  • Import alphabetically.
  • Only modify import order for groups of files, not specific files.
// Bad
@import 'module/logo';
@import 'component/mask';
@import 'component/button'; /* Has to be imported after "mask" */

// Good
@import 'component/button';
@import 'component/mask';
@import 'module/logo';
Looking for U.S. government information and services?