Sass Customization

Sooner or later you'll want TrailMap's primary color to be an actual trail green instead of Bootstrap's default blue. The tempting shortcut is to write a stylesheet full of !important overrides after the Bootstrap CDN link. The correct fix — and the one that actually scales as a project grows — is overriding Bootstrap 4's Sass $variables before Bootstrap's own Sass files are imported, using the npm/Sass build from the Setup & Dependencies lesson, not the plain CDN link.

Why !important Overrides Are a Bad Habit

Bootstrap's compiled CSS already has fairly specific selectors. Fighting it after the fact usually means stacking more and more !important declarations as new components need the same override:

/* fighting the compiled CSS after the fact */
.btn-primary {
  background-color: #2e7d32 !important;
  border-color: #2e7d32 !important;
}
.badge-primary {
  background-color: #2e7d32 !important;
}
.bg-primary {
  background-color: #2e7d32 !important;
}
.text-primary {
  color: #2e7d32 !important;
}

Every single component and utility that touches $primary needs its own override, the color value is duplicated everywhere it appears, and any future Bootstrap component you add (a new badge variant, a new alert) needs yet another rule added to keep up. It's brittle, and it fights the browser's own cascade instead of working with it.

The Proper Way: Override Variables Before Importing Bootstrap

Bootstrap 4's own Sass source defines $primary, $secondary, $font-family-base, and dozens of other variables with !default — meaning any value you set for the same variable name earlier in the compile wins, and every component and utility that references $primary picks up your value automatically, with zero !important anywhere.

// custom.scss — order matters: variables first, then Bootstrap
$primary: #2e7d32;

@import "../node_modules/bootstrap/scss/bootstrap";
Note: the variable override must come before the @import line. Bootstrap's Sass files use !default on each variable, which only assigns the built-in value if nothing has set that variable name yet — set it after the import and it's too late, the components are already compiled against the default.

Worked Example: Recoloring TrailMap's $primary to Trail Green

With $primary set to a trail green before the Bootstrap import, every component that relies on the primary color updates automatically — no per-component overrides needed:

// custom.scss
$primary: #2e7d32; // trail green

@import "../node_modules/bootstrap/scss/bootstrap";

Compile it, link the resulting CSS file instead of the CDN stylesheet, and .btn-primary, .badge-primary, .bg-primary, .text-primary, focus rings, and even form validation's default accent all render in trail green — TrailMap's brand color, applied once, everywhere it belongs.

Why the CDN Build Can't Be Customized This Way

The bootstrap.min.css file loaded straight from a CDN is already fully compiled — its variables were resolved into fixed color values at Bootstrap's own build time, long before it reached your page. There is no Sass left in that file for a variable override to hook into. Sass-variable customization only works when you control the compile step: installing Bootstrap's source via npm, writing your own entry .scss file that sets variables and then imports Bootstrap's Sass, and running that through a Sass compiler yourself — exactly the workflow covered in Setup & Dependencies.

Next up, go beyond the basic 12-column grid with Advanced Grid — ordering, offsetting, and row-cols.