Quick and Dirty Bootstrap Overrides at Runtime

Bootstrap 5.2 and above have provided solutions to the methods described in this article. So if you are using Bootstrap 5.2 or later, you can use CSS variables directly for custom overrides.

Bootstrap, this old-fashioned web front-end framework, is loved by others, and some people sneer at it. No matter what perspective you take, it is a powerful UI framework with wide application, most people understand its basics and deliver highly predictable results.

Bootstrap has its own design philosophy. It requires you to build HTML in a specific way, overwrite styles in a specific way, build core files in a specific way, and include them in a specific way in the website. Normally, this is OK unless your colleague writes bad Bootstrap code, but it doesn't cover all use cases.

Bootstrap tends to be generated on the server side and does not like to overwrite its styles at runtime. If you need to implement some kind of visual theme functionality in your application, Bootstrap recommends that you generate separate stylesheets for each theme and toggle stylesheets if needed. This is a great way to do this if you are giving your users a predefined theme. But what if you want a user-defined theme? You can set up your application to run Sass and compile new stylesheets and save them to the server, but that requires a lot of work – plus you have to communicate with the backend staff and the DevOps team, which would be a lot of trouble if you just want to, say, swap the primary and secondary colors.

This is what I was facing at that time.

I'm building a multi-user SaaS application using Django and Vue that has a fixed layout, but also needs to be able to change brand colors for each user account and have an automatic default color theme. Another requirement is that we won't redeploy the application every time we add a new user. Finally, every backend and DevOps developer is currently busy with other projects, so I have to fix this alone.

Since I don't want to compile Sass at runtime, I can create stylesheets and inject them into the page, but this is not a good solution because we're focusing on colors. The compiled Bootstrap stylesheet renders the color values ​​as explicit hexadecimal values, and (I just checked) there are 23 instances of main blue in my stylesheet. For the primary color alone, I need to overwrite each instance and then standardize again for the secondary color, warning color, hazard color, and all the other conventions and colors we want to change. It's complicated and has a lot of work. I don't want to do that.

Fortunately, this new application does not need to support Internet Explorer 11, which means I can use CSS variables. They are also great, can be defined after the stylesheet is loaded, flowing in all directions and changing all the colors I want, right? Bootstrap generates that large list of variables in the :root element, so this should be simple.

At this point I learned that Bootstrap only renders some of its values ​​as variables in the stylesheet, and that this variable list is entirely for end-user use. Most of the variables in this list are not referenced in the rest of the stylesheet, so redefining them has no effect. (However, it is worth noting that better runtime variable support may be provided in the future.)

So I want my Bootstrap stylesheet to be rendered with CSS variables that can be operated on the server side rather than on the static color value, which is strictly impossible. If you set the color variable to a CSS variable, Sass will not compile. There are some clever tricks to make Sass do this (one here, and one more), but they require branching Bootstrap, and getting out of the upgrade path gives my app some vulnerability that I'm not willing to add. If I'm totally honest, the real reason I'm not implementing these solutions is that I can't figure out how to get either to work with my Sass compiler. But you may have better luck.

I think it's worth explaining my preferred workflow here. I prefer to run Sass locally on my development machine to build the stylesheet and submit the compiled stylesheet to the repository. Best practice recommendations should compile stylesheets during deployment, which is correct, but I work for a growing, perpetually understood startup. I use Sass because I like it, but it is obviously a topic in my work and I don't have the time, ability or mental strength to integrate my Sass builds with our various deployment pipelines.

It's also a kind of legal evil self-defense: I don't want our full stack developers to get in touch with my elaborate styles and start writing whatever they want; and I find that for some reason they're having a lot of trouble with installing Node on their laptops. well! They could only ask me for help, and that was exactly the way I wanted.

All of this says: If I can't get the stylesheet to render with the variables inside it, then nothing can prevent me from injecting it into the stylesheet after the stylesheet is compiled .

Witness the power of search and replacement!

All we have to do is go into Bootstrap and find the colors we want to replace, which are conveniently located in the:root style at the top of the compiled stylesheet:

 <code>:root { --bs-blue: #002E6D; --bs-indigo: #6610F2; // ... other variables }</code>

Get the value of for example --bs-primary, which is the old-fashioned Bootstrap blue. I'm using Gulp to compile my stylesheets, so let's look at the Sass task function in gulpfile.js:

 var gulp = require('gulp');
var sass = require('gulp-sass')(require('sass'));
var sourcemaps = require('gulp-sourcemaps');
var gulpreplace = require('gulp-replace');

function sassCompile() {
  return gulp.src('static/sass/project.scss')
    .pipe(sourcemaps.init())
    .pipe(sass({outputStyle: 'expanded'}))
    .pipe(sourcemaps.write('.'))
    .pipe(gulpreplace(/#002E6D/ig, 'var(--ct-primary)'))
    .pipe(gulp.dest('static/css/'));
}
exports.sass = sassCompile;

Compile the stylesheet and then view it.

 :root {
  --bs-blue: var(--ct-primary);
  --bs-indigo: #6610F2;
  // ... other variables
}

Great, OK, we now have a complete stylesheet that requires a variable value to represent blue. Note that it changes both the main color and "blue". This is not a subtle technique. I call it fast and rough for a reason, but getting a finer grained color replacement control is fairly easy if you need it. For example, if you want to keep "blue" and "main" as separate values, go into your Sass and redefine the $blue and $primary Sass variables to different values, then you can find and replace them separately as you want.

Next, we need to define the new default variable value in the application. Doing this in the HTML header is very simple:

<link href="/static/css/project.css" rel="stylesheet">
<style>
  :root {
    --ct-primary: #002E6D;
  }
</style>

Run it and everything will show up. Everything that needs to be blue is blue. Repeat this process a few times and you can suddenly control many colors in the Bootstrap stylesheet. These are the variables I chose to provide to the user, and their default color values:

 --ct-primary: #002E6D;
--ct-primary-hover: #00275d;
// ... other variables

Now, the fun begins! From here, you can directly manipulate these default values ​​as needed, or add a second :root style below the default values ​​to overwrite only the colors you want. Or like me, put a text field in the user profile that outputs the :root style to your title, overwriting whatever you need. Look, you can now override Bootstrap at runtime without recompiling the stylesheet or driving yourself crazy.

This is certainly not an elegant solution, but it solves a very specific use case that developers have been trying to solve for years. And this has proven to be a very efficient solution for me before Bootstrap decided to allow us to easily overwrite variables at runtime.

The above is the detailed content of Quick and Dirty Bootstrap Overrides at Runtime. For more information, please follow other related articles on the PHP Chinese website!