Updated .bg-* and .text-* utilities break when CSS variables are not enabled in v5.1.0 #34756

dgsiegel · 2021-08-16T12:03:53Z

In one of my projects I include the needed Bootstrap SCSS files manually and specifically exclude bootstrap/scss/root, first because I don't rely on most of the CSS variables and secondly because adding all CSS variables increases the CSS file size by about 50-60kb (uncompressed).

With v5.1.0 all .bg-* and .text-* utilities break, as the needed CSS variables are missing, e.g.

.text-white {
    --bs-text-opacity: 1;
    color: rgba(var(--bs-white-rgb), var(--bs-text-opacity)) !important; // --bs-white-rgb is not set
}

Is there a simple way to disable CSS variables generation or to reduce the number of CSS variables? The only way forward right now would be to revert the utility sets back to $theme-colors, but that still leaves an additional --bs-text-opacity: 1; and does not take care of --bs-body-color and the like:

$utilities-text-colors: $theme-colors;
$utilities-bg-colors: $theme-colors;

The text was updated successfully, but these errors were encountered:

WinterSilence · 2021-08-17T05:39:42Z

bootstrap/scss/root required, this variables uses in many files.

iatek · 2021-08-17T22:12:45Z

The whole bg-, text- update in 5.1.0 has seemingly complicated the entire process of adding a new theme-color. The only way I could find to get the bg- and text- classes regenerated for the new "custom" theme color is....

@import "functions";
@import "variables";
@import "mixins";

$custom: #df711b;

$custom-theme-colors: (
  "custom": $custom
);

$theme-colors: map-merge($theme-colors, $custom-theme-colors);
$theme-colors-rgb: map-loop($theme-colors, to-rgb, "$value");
$utilities-colors: map-merge($utilities-colors, $theme-colors-rgb);
$utilities-text-colors: map-loop($utilities-colors, rgba-css-var, "$key", "text");
$utilities-bg-colors: map-loop($utilities-colors, rgba-css-var, "$key", "bg");

@import "bootstrap";

I discovered this on an SO question and here's the working code demo

Whereas in 5.0.2 one could simply follow the example in the docs...

@import "functions";
@import "variables";
@import "mixins";

$custom-colors: (
  "custom-color": #df711b
);

$theme-colors: map-merge($theme-colors, $custom-colors);

Kopyov · 2021-08-18T10:03:35Z

In addition to that, the suggested way of extending color utility classes generates HEX color values instead of RGBA and still keeps useless --bs-text-opacity: 1; in every custom color class

Pythagus · 2021-08-19T07:33:44Z

The whole bg-, text- update in 5.1.0 has seemingly complicated the entire process of adding a new theme-color. The only way I could find to get the bg- and text- classes regenerated for the new "custom" theme color is....
@import "functions";
@import "variables";
@import "mixins";

Thanks!
This really needs to be written in the official documentation!

gigadie · 2021-08-24T10:01:19Z

I consider this either a regression or a lack in documentation.
Thanks @iatek for the above! Unfortunately it didn't work for me.
What finally worked for me was moving mixins after the merge-map and map-loop, like this:

// CUSTOM COLOURS
@import './variables';

// Configuration
@import "node_modules/bootstrap/scss/functions";
@import "node_modules/bootstrap/scss/variables";

$theme-colors: map-merge($theme-colors, $custom-colours);
$theme-colors-rgb: map-loop($theme-colors, to-rgb, "$value");
$utilities-colors: map-merge($utilities-colors, $theme-colors-rgb);
$utilities-text-colors: map-loop($utilities-colors, rgba-css-var, "$key", "text");
$utilities-bg-colors: map-loop($utilities-colors, rgba-css-var, "$key", "bg");

@import "node_modules/bootstrap/scss/mixins";
@import "node_modules/bootstrap/scss/utilities";
// ... and the rest of boostrap

gigadie · 2021-08-24T10:23:44Z

Oh, and btw the same is true if you need to add spacing classes:

@import "node_modules/bootstrap/scss/functions";
@import "node_modules/bootstrap/scss/variables";

// Extend the spacings
$spacers: map-merge(
  $spacers, (
    6: ($spacer * 6)
  )
);

WilliamStam · 2021-08-24T14:19:16Z

arrrggghhhh add +1 to frustration of note. this change has had me tearing my hair out.

i sort of got it working with

_variables.scss (my custom variables)

@import "../../../../../node_modules/bootstrap/scss/functions";
@import "../../../../../node_modules/bootstrap/scss/variables";
@import "../../../../../node_modules/bootstrap/scss/mixins";

$colors: (
...
);
$theme-colors: (
...
);
$theme-colors-rgb: map-loop($theme-colors, to-rgb, "$value");
$utilities-colors: map-merge($utilities-colors, $theme-colors-rgb);
$utilities-text-colors: map-loop($utilities-colors, rgba-css-var, "$key", "text");
$utilities-bg-colors: map-loop($utilities-colors, rgba-css-var, "$key", "bg");

....

styles.scss (main style)

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

at the devs, its changes like this that might actually drive people away tho. would suggest you consider "ability and ease of extending bootstrap" as a core just like getting the code working right. i know people might disagree with this, but this change for instance has some what had me questioning if bootstrap and me remain in a loving relationship or not). 12k lines of css :( last i looked it was around 8 or so

mdo · 2021-08-24T15:50:41Z

Sorry we've been slow to investigate and identify a path forward. We'll need a little more time to experiment and validate the issues identified here. Definitely not in our interest to be causing headaches for folks :).

WilliamStam · 2021-08-24T16:09:06Z

Hehe thanks mdo. I think the 5.1 update took a few people by surprise. Some "breaking" things like this but on the face of it it looks like 5.0 but it's still a big update.

mdo · 2021-09-09T18:05:30Z

Left a comment at #34734 (comment), but cross posting here and closing that as a duplicate. Please read and let me know what you all think about that potential solution. Seems like the best path forward to me so far.

After investigating a bit more, I think the best path forward might to split out some of our reassigned Sass maps into a separate _maps.scss file, and import that after the _variables.scss file. This would allow folks to insert new additions to the $theme-colors map that would be reflected in the subsequent maps.

For example:

// Configuration
@import "functions";
@import "variables";

$starorange: #df711b !default;

$custom-theme-colors: (
  "starorange": $starorange
) !default;

$theme-colors: map-merge($theme-colors, $custom-theme-colors); // stylelint-disable-line scss/dollar-variable-default

@import "maps";
@import "mixins";
@import "utilities";

// Layout & components
// ...

Inside _maps.scss would be the Sass maps for $theme-colors-rgb, $utilities-colors, $utilities-text, and $utilities-bg. I tried this locally and it works for me—both button variants and utilities are generated for the custom color.

isaumya · 2021-09-09T18:51:36Z

Hi @mdo,
Honestly I don't understand why you guys went to the rgba path anyways. It created so many extra css variables along with the the extra bs-opacity variable on every colour utility class.
The colour utility class were perfect in v5.0
I don't know maybe I'm feeling this way as I see no extra benefit of all these hassle.

mdo · 2021-09-09T19:16:02Z

@isaumya This is why: https://getbootstrap.com/docs/5.1/utilities/colors/#opacity. It allows for on the fly manipulation of colors. We've stated we're heading to more CSS variables since developing v5, and there's more coming for components (see #34443, #34600, and #34622).

Kopyov · 2021-09-09T19:39:49Z

@mdo I think lots of people are missing the whole point of introducing RGBa with opacity CSS var. If i understand correctly, this is needed for new text and background opacity logic. But the same can be achieved with regular opacity-* utilities. If that's correct, this means we have a bunch of RGB values defined in :root just for setting the opacity. But this doesn't help to extend color palette, because the suggested method still generates HEX values with opacity CSS var. Why don't we use HSL and HSLa instead, where we can simply change lightness to generate additional tints/shades of *-500 colors and change alpha to control opacity? A few examples here.

WilliamStam · 2021-09-09T19:58:52Z

I love bootstrap but yikes. This all feels like woosh direction gone. I trust you guys to do what's best for the project and I'm in no position to know the big picture with it, but eish. To a long time user at this point I'm just going "I trust the devs" more than what I trust what I'm seeing.

Maybe consider splitting bs up more or having opt in on stuff? The "core" compiled bs with very basic components is still huge.

How many projects does the RGB thing even help?

Maybe with 6 go back to reboot then add stuff to it?

Thanks team. I appreciate the work tho!

mdo · 2021-09-09T21:57:18Z

First up, it’s definitely my fault that these problems have occurred. I didn’t test these changes enough. We’ll be looking into some Sass testing we can add to help avoid situations like this in the future.

I think lots of people are missing the whole point of introducing RGBa with opacity CSS var. If i understand correctly, this is needed for new text and background opacity logic.
...
Why don't we use HSL and HSLa instead, where we can simply change lightness to generate additional tints/shades of *-500 colors and change alpha to control opacity?

HSL is great, but setting colors up with three variables instead of one feels overkill. Experience has shown me most folks are familiar with hex and RGB, so we went that route. The goal wasn’t to really extend the palette—that’s optional for everyone, and the very use case we want to solve for with this issue—but rather to make components and utilities stronger and easier to customize. These RGB values also accomplish what you want with the alpha of HSLA—that’s how we use them for bg and color utilities now.

But the same can be achieved with regular opacity-* utilities.

The same cannot be achieved with opacity utilities. These variable/utility changes apply to color, background-color, and eventually border-color. Changing the opacity of would affect the whole element instead of those individual properties. Sure there are clever ways around this, but usually with added complications.

How many projects does the RGB thing even help?

Considering we only shipped it a month ago, I’m not entirely sure yet :). Give it time for folks to get used to though. For what it’s worth, Tailwind does something like this already and it seems super helpful. Give it a go and let me know what you think.

Maybe consider splitting bs up more or having opt in on stuff? The "core" compiled bs with very basic components is still huge.
...
Maybe with 6 go back to reboot then add stuff to it?

There won’t be any “going back” to Reboot. Reboot came out of Normalize.css and Bootstrap 4. We never started with that :). Bootstrap has been a compilation of components, layout, plugins, and more for the last decade. It’ll most likely stay that way for the next ;).

Regarding file size, if you can find a way to decrease file size while doing all Bootstrap does, I’d love to hear about it :). We try to keep it lean but convenient. That aside, doing a custom build and using PurgeCSS is a great way to streamline it all :).

dgsiegel · 2021-09-09T22:08:20Z

Regarding file size, if you can find a way to decrease file size while doing all Bootstrap does, I’d love to hear about it :). We try to keep it lean but convenient. That aside, doing a custom build and using PurgeCSS is a great way to streamline it all :).

That's my biggest hassle with this change, as CSS variables alone account of over 50-60kb (uncompressed). Would it be somehow feasible to add an option to include/exclude CSS variables?

mdo · 2021-09-09T22:50:18Z

That could be possible. Where are you getting 50-60kb from though? It's maybe a few if you include literally every one of them.

dgsiegel · 2021-09-09T22:58:11Z

That could be possible. Where are you getting 50-60kb from though? It's maybe a few if you include literally every one of them.

I just compared the final result with and without including @import "bootstrap/scss/root";

mdo · 2021-09-09T23:23:32Z

_root.scss is 55 lines of CSS—there's no way it's 50-60kb :). I just checked again, 2kb difference.

# With _root.scss
204316 Sep  9 16:20 bootstrap.css

# Without _root
202579 Sep  9 16:21 bootstrap.css

dgsiegel · 2021-09-10T09:33:52Z

In fact you are right, I just compared 5.0.2 without _root.css and 5.1.1 with:

# 5.0.2 without
208K 10. Sep 11:28 bootstrap.css
# 5.1.1 with
216K 10. Sep 11:29 bootstrap.css

Minifying this will give me a 6kb difference. So the above mentioned difference of 50-60kb was most likely due to not importing other Bootstrap components.

tomsommer · 2021-09-10T11:42:59Z

Should this issue not be fixed in a 5.1.2?

The whole bg-, text- update in 5.1.0 has seemingly complicated the entire process of adding a new theme-color. The only way I could find to get the bg- and text- classes regenerated for the new "custom" theme color is....
@import "functions";
@import "variables";
@import "mixins";

$custom: #df711b;

$custom-theme-colors: (
  "custom": $custom
);

$theme-colors: map-merge($theme-colors, $custom-theme-colors);
$theme-colors-rgb: map-loop($theme-colors, to-rgb, "$value");
$utilities-colors: map-merge($utilities-colors, $theme-colors-rgb);
$utilities-text-colors: map-loop($utilities-colors, rgba-css-var, "$key", "text");
$utilities-bg-colors: map-loop($utilities-colors, rgba-css-var, "$key", "bg");

@import "bootstrap";
I discovered this on an SO question and here's the working code demo

Whereas in 5.0.2 one could simply follow the example in the docs...
@import "functions";
@import "variables";
@import "mixins";

$custom-colors: (
  "custom-color": #df711b
);

$theme-colors: map-merge($theme-colors, $custom-colors);

This doesn't work entirely for $utilities-text-colors, you will be missing .text-white etc.

These map-merges inside _utilities.scss and _variables.scss really makes for a mess.

isaumya · 2021-09-13T13:32:26Z

I know @tomsommer,
I had to spend a few hours to solve that issue in v5.1.1 and here is what I come up with and it works perfectly.

@import "functions";

// Overwrite your variables
$custom-color1: red !default;
$custom-color2: blue !default;

$min-contrast-ratio: 3;
$link-decoration: none;

// Import the bootstrap variables
@import "variables";

$extra-theme-colors: (
	"gray-dark":   $gray-800,
	"custom-color1": $custom-color1
);

$extra-general-colors: (
	"custom-color2": $custom-color2
);

// Run map-merge() to mer our custom maps with the default Bootstrap maps
$colors: map-remove( $colors, "gray-dark" );
$colors: map-merge( $colors, $extra-general-colors );

$theme-colors: map-merge($theme-colors, $extra-theme-colors );

// ---------- MOST IMPORTANT ---------------
// Extra stuffs we need to do for generating the proper theme color classes (.bg-*, .text-*)
$theme-colors-rgb: map-loop($theme-colors, to-rgb, "$value");

$utilities-text: map-merge($theme-colors, $utilities-text);
$utilities-text-colors: map-loop($utilities-text, rgba-css-var, "$key", "text");

$utilities-bg: map-merge($theme-colors, $utilities-bg);
$utilities-bg-colors: map-loop($utilities-bg, rgba-css-var, "$key", "bg");

// And then continue importing the rest
@import "mixins";
@import "utilities";
// and so on...

This will work. Try and enjoy. :)
Honestly, I really wish I can go back to the Boostrat v5.0 days without all these complexities around adding own custom colors.

Fun fact: I faced the same text-white issue and then figured this out. :(

tomsommer · 2021-09-13T17:35:33Z

The "problem" goes even beyond the maps.

Modifying anything in _variables.scss that depends on anything else is cumbersome. Even adding an extra element to $spacers requires you to manually set $spacer: 1rem; before doing anything, even though it's a default, because you cannot change $spacers with a map-merge() after _variables.scss is included, because $gutters and $negative-spacers depends on $spacers (just an example, it's the same with many other things, even $theme-colors), and so these won't be changed. It's just really a mess to keep track of.

Say I do $color-contrast-dark: $red; after including _variables.scss, I have to trust $color-contrast-dark wasn't used for anything dynamic in _variables.scss otherwise things don't fit anymore.

Really something to think about how to make easier, my two cents. Or maybe we are just limited by the !default abilities of scss.

mdo · 2021-09-13T20:07:42Z

Yeah, this was definitely a shortcoming of Sass we didn’t fully explore at the time. It’s something we’ll 100% have to revisit in v6, but until then, I want to make sure we consider the best options and ship something that’s functional and as easy to document/explain as possible.

What do folks think of that PR I opened to separate out Sass maps? I might need to include more maps there like $spacers it sounds like, but I’m hoping the principle of it helps. We might also need to smooth out the utilities map merges if the latest comments here are right.

WilliamStam · 2021-09-13T20:15:57Z

I like the idea of splitting it to its own files. But would rather say that it should be split in such a way that if you don't need colours then don't include it (spaces, colours, et al)

I honestly prefer "more" files vs larger files in cases like this.

If the pr fixes the maps thing then I'm 100% behind it. Just gotten bitten again with a .bg-white suddenly disappearing on update again and used many short words again. (Just had to add the stuff in my custom variables file as per above again)

mdo · 2021-09-14T03:57:44Z

Here's what the diff will look like when importing and customizing Bootstrap after #34942 is merged. Taking the example above, we add a custom variable, put that in it's own map, and then map-merge it with $theme-colors. Since our $theme-colors map is now in a new stylesheet partial, the downstream reassigned maps will be updated properly.

  // Functions come first
  @import "functions";

  // Optional variable overrides here
+ $custom-color: #df711b;
+ $custom-theme-colors: (
+   "custom": $custom-color
+ );

  // Variables come next
  @import "variables";

+ // Optional Sass map overrides here
+ $theme-colors: map-merge($theme-colors, $custom-theme-colors);
+
+ // Followed by our default maps
+ @import "maps";
+
  // Rest of our imports
  @import "mixins";
  @import "utilities";
  @import "root";
  @import "reboot";
  // etc

Here's a quick output of a debug test I did. As you can see, it outputs the correct keys for all maps that consume $theme-colors.

@import "../scss/functions";

$custom-color: #df711b;
$custom-theme-colors: (
  "custom": $custom-color
);

@import "../scss/variables";

$theme-colors: map-merge($theme-colors, $custom-theme-colors);

@import "../scss/maps";

@debug "The following three maps should be the same, ending with the custom key.";
@debug map.keys($theme-colors);
@debug map.keys($theme-colors-rgb);
@debug map.keys($utilities-colors);
@debug "";
@debug "The following two maps should be the same: including custom and ending in black, white, and body.";
@debug map.keys($utilities-text-colors);
@debug map.keys($utilities-bg-colors);

➜ ~/work/bootstrap (split-vars-maps-import) npm run css-test

> [email protected] css-test /Users/mdo/work/bootstrap
> sass --style expanded --source-map --embed-sources --no-error-css test/index.scss:test/output.css

test/index.scss:35 Debug: The following three maps should be the same, ending with the custom key.
test/index.scss:36 Debug: "primary", "secondary", "success", "info", "warning", "danger", "light", "dark", "custom"
test/index.scss:37 Debug: "primary", "secondary", "success", "info", "warning", "danger", "light", "dark", "custom"
test/index.scss:38 Debug: "primary", "secondary", "success", "info", "warning", "danger", "light", "dark", "custom"
test/index.scss:40 Debug: 
test/index.scss:41 Debug: The following two maps should be the same: including custom and ending in black, white, and body.
test/index.scss:42 Debug: "primary", "secondary", "success", "info", "warning", "danger", "light", "dark", "custom", "black", "white", "body"
test/index.scss:43 Debug: "primary", "secondary", "success", "info", "warning", "danger", "light", "dark", "custom", "black", "white", "body"

tomsommer · 2021-09-14T05:32:26Z

It's certainly better, and certainly an improvement, but you have to ask where the limit go:

You can't really include $spacers in this, then you would have to include anything that uses another variable in their value. Imagine changing $small-font-size after loading _variables.scss, you wouldn't get the result you imagine.

The problem is that people actually change $theme-colors, and they do it in a way that merges with the default $theme-colors - this is not really correct, at least in the way scss !default works. But you can't really propagate $theme-colors your self without loading all the colors first, and you can't do that without loading _variables.scss.

As a quick-fix, the PR is fine, but it really is something that needs a deep think. I think Tailwind has solved all this with Webpack?

mdo · 2021-09-14T06:04:18Z

I think $spacer/$spacers work, and related base variables and maps. Here's the output to an updated version of the above test where I set $spacers: 2rem, imported variables next, then compiled the debug test.

test/index.scss:40 Debug: The following spacers should be doubled the default values.
test/index.scss:41 Debug: Default: 0, 0.25rem, 0.5rem, 1rem, 1.5rem, 3rem
test/index.scss:42 Debug: Updated: 0, 0.5rem, 1rem, 2rem, 3rem, 6rem

The main issue seems to be updating maps that get re-used.

tomsommer · 2021-09-14T06:11:31Z

The point is if you do

@import "../scss/variables";

$spacers: map-merge($spacers, (
6: $spacer * 6,
));

You end up with a similar problem of $gutters and $negative-spacers not being updated.

WilliamStam · 2021-09-14T06:39:07Z

just checking, adding in a "primary" into the custom-theme map would then change the primary';s colour right? this isnt just for "extending" it?

// variables.scss
$custom-color: #ff0000;
$custom-theme-colors: (
  "primary": $custom-color
);

// styles.css (the output)
.text-primary {
    color: #ff0000
}
.bg-primary {
    background: #ff0000;
}

this would mean this changes right?

@import "../variables"; // my custom variables
@import "./node_modules/bootstrap/scss/bootstrap.scss"; // all of bootstrap

would have to bring in the separate bootstrap files into our main style.scss then?

mdo · 2021-09-14T15:33:07Z

If you just want to change an existing key's value in $theme-colors, you can override it vs using map-merge with a custom map.

@import "../scss/functions";

$primary: purple;

@import "../scss/variables";
@import "../scss/maps";
// etc

// Test for it
@debug "Test: Primary should be purple instead of #0d6efd (blue).";
@debug "Variable is " + $primary;
@debug "Theme colors map value is " + map.get($theme-colors, "primary");

test/index.scss:29 Debug: Test: Primary should be purple instead of #0d6efd (blue).
test/index.scss:30 Debug: Variable is purple
test/index.scss:31 Debug: Theme colors map value is purple

Looking at writing some tests for the spacers and more to see what we'd need to do.

mdo · 2021-09-15T02:26:29Z

@tomsommer Yes, the same does apply there. I misunderstood your earlier point I think and was only looking to see if spacers are updated if you change the $spacer value. That update does happen, but yes, the reassigned maps do not. I'm checking out the viability of moving those maps to _maps.scss as well.

tomsommer · 2021-09-15T06:57:59Z

The only way to solve this everywhere is to never modify variables after including _variables.scss, but of course that takes away some of the ease of Bootstrap.

See #34756 (comment) :)

mdo · 2021-09-16T01:18:40Z

The maps.scss file doesn't exist yet. The discussions here are around how to improve the situation in our next release.

Look up higher to the comments that suggest customizing the map and re-declaring the additional maps.

morkeleb · 2021-09-20T11:27:14Z

I'm not sure if this helps but I'm posting it here incase someone else tries the same thing.
I tried @mdo 's solution from PR #34942

$theme-colors: map-merge($theme-colors, $custom-theme-colors);
$theme-colors-rgb: map-loop($theme-colors, to-rgb, "$value");
$utilities-colors: map-merge($utilities-colors, $theme-colors-rgb);
$utilities-text-colors: map-loop($utilities-colors, rgba-css-var, "$key", "text");
$utilities-bg-colors: map-loop($utilities-colors, rgba-css-var, "$key", "bg");

and that breaks for example text-white as its no longer generated from the utilities after I recreated the maps.

WilliamStam · 2021-10-06T14:53:03Z

so is @morkeleb 's post this the "fix" till 5.2?

some how (and im not sure if its just me doing something silly) setting $component-active-bg: $primary; in my variables file

@import "./node_modules/bootstrap/scss/functions";
@import "./node_modules/bootstrap/scss/variables";
@import "./node_modules/bootstrap/scss/mixins";

// all my custom variables
$component-active-bg: $primary;

$theme-colors-rgb: map-loop($theme-colors, to-rgb, "$value");
$utilities-text: map-merge($theme-colors, $utilities-text);
$utilities-text-colors: map-loop($utilities-text, rgba-css-var, "$key", "text");
$utilities-bg: map-merge($theme-colors, $utilities-bg);
$utilities-bg-colors: map-loop($utilities-bg, rgba-css-var, "$key", "bg");

results in the checkboxes being the default blue.
$form-check-input-checked-bg-color: $component-active-bg !default; in the bootstrap variables file doesnt update either.

(again this could just be me being stupid)

have to add


$component-active-bg: $primary;
$form-check-input-checked-bg-color: $primary;
$form-check-input-checked-border-color: $primary;

to my variables file.

tomsommer · 2021-10-06T16:45:45Z

@WilliamStam You should declare $component-active-bg before anything and hardcode the color (not relying on $primary). That should work

MrStonebender · 2021-10-28T06:10:44Z

I know @tomsommer, I had to spend a few hours to solve that issue in v5.1.1 and here is what I come up with and it works perfectly.

@import "functions";

// Overwrite your variables
$custom-color1: red !default;
$custom-color2: blue !default;

$min-contrast-ratio: 3;
$link-decoration: none;

// Import the bootstrap variables
@import "variables";

$extra-theme-colors: (
	"gray-dark":   $gray-800,
	"custom-color1": $custom-color1
);

$extra-general-colors: (
	"custom-color2": $custom-color2
);

// Run map-merge() to mer our custom maps with the default Bootstrap maps
$colors: map-remove( $colors, "gray-dark" );
$colors: map-merge( $colors, $extra-general-colors );

$theme-colors: map-merge($theme-colors, $extra-theme-colors );

// ---------- MOST IMPORTANT ---------------
// Extra stuffs we need to do for generating the proper theme color classes (.bg-*, .text-*)
$theme-colors-rgb: map-loop($theme-colors, to-rgb, "$value");

$utilities-text: map-merge($theme-colors, $utilities-text);
$utilities-text-colors: map-loop($utilities-text, rgba-css-var, "$key", "text");

$utilities-bg: map-merge($theme-colors, $utilities-bg);
$utilities-bg-colors: map-loop($utilities-bg, rgba-css-var, "$key", "bg");

// And then continue importing the rest
@import "mixins";
@import "utilities";
// and so on...

This will work. Try and enjoy. :) Honestly, I really wish I can go back to the Boostrat v5.0 days without all these complexities around adding own custom colors.

Fun fact: I faced the same text-white issue and then figured this out. :(

Not entirely sure if this is relevant here specifically, but I hope it is. While the solution from @isaumya works, it only works if the values in your custom color map are rgb or hex only, with no alpha value. If you have something like...

$custom-colors: (
    "primary25":     rgba($primary, .25)
// where $primary was previously defined, of course.
);

And you try to merge that into $theme-colors via the quoted method, any key in the color map with a value in rgba won't pass all the way through to becoming a bg- or text- class. (in this example, 'bg-primary25' just... didn't exist in the resulting css)

So if anyone is using rgba values in their theme-colors map, they just... won't work. Even with this fix. You have to scrub those all out, replace them with the base rgb or hex value, and then use the 'opacity' classes in your html to achieve the same result.

(And I guess maybe add custom opacity values via that utility, if needed?)

arcanisgk · 2022-04-11T15:05:08Z

I don't know if what I did was stupid...

first imported everything with:

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

then I make my changes, customizations, example:

$aliceblue:#F0F8FF;
$antiquewhite:#FAEBD7;
$aqua:#00FFFF;
$aquamarine:#7FFFD4;
$azure:#F0FFFF;
$beige:#F5F5DC;
$bisque:#FFE4C4;
$blanchedalmond:#FFEBCD;
$blueviolet:#8A2BE2;
$brown:#A52A2A;

$custom-colors: (
  "aliceblue": $aliceblue, 
  "antiquewhite": $antiquewhite, 
  "aqua": $aqua, 
  "aquamarine": $aquamarine, 
  "azure": $azure, 
  "beige": $beige, 
  "bisque": $bisque, 
  "blanchedalmond": $blanchedalmond, 
  "blueviolet": $blueviolet, 
  "brown": $brown
);

@each $color, $value in $custom-colors {

  .bg-#{$color} {
    background-color: $value !important;
  }

  .text-#{$color} {
    color: $value !important;
  }

}

$theme-colors: map-merge($theme-colors, $custom-colors);

once I have already merged; I return import to get the css output.

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

I do this twice already because for some unknown reason it wouldn't let me get the customized bg and text.

mdo added css v5 labels Aug 26, 2021

mdo mentioned this issue Sep 9, 2021

Wrong RGB values being created from theme colours #34919

Closed

mdo mentioned this issue Sep 9, 2021

Problem with creating automated utility bg and text class with custom colors in v5.1.0 #34734

Closed

mdo mentioned this issue Sep 9, 2021

Move reassigned Sass maps for colors to another stylesheet #34942

Merged

2 tasks

mdo mentioned this issue Oct 15, 2021

Custom theme colors map-loop to Buttons/Text Color/Bg Color removing out-the-box Bootstrap classes #35201

Closed

mdo mentioned this issue Oct 27, 2021

Media Queries differ between node sass and dart sass #35275

Closed

3 tasks

mdo mentioned this issue Nov 1, 2021

Added new colors to $theme-colors but related classes are not created for text and background colors #35297

Closed

3 tasks

XhmikosR closed this as completed in #34942 Nov 15, 2021

mdo mentioned this issue Feb 10, 2022

Background classes not being created with custom maps #35815

Closed

3 tasks

Updated .bg-* and .text-* utilities break when CSS variables are not enabled in v5.1.0 #34756

Updated .bg-* and .text-* utilities break when CSS variables are not enabled in v5.1.0 #34756

Comments

dgsiegel commented Aug 16, 2021

WinterSilence commented Aug 17, 2021

iatek commented Aug 17, 2021 • edited Loading

Kopyov commented Aug 18, 2021

Pythagus commented Aug 19, 2021

gigadie commented Aug 24, 2021 • edited Loading

gigadie commented Aug 24, 2021

WilliamStam commented Aug 24, 2021 • edited Loading

mdo commented Aug 24, 2021

WilliamStam commented Aug 24, 2021

mdo commented Sep 9, 2021 • edited Loading

isaumya commented Sep 9, 2021

mdo commented Sep 9, 2021

Kopyov commented Sep 9, 2021

WilliamStam commented Sep 9, 2021

mdo commented Sep 9, 2021

dgsiegel commented Sep 9, 2021

mdo commented Sep 9, 2021

dgsiegel commented Sep 9, 2021

mdo commented Sep 9, 2021

dgsiegel commented Sep 10, 2021 • edited Loading

tomsommer commented Sep 10, 2021 • edited Loading

isaumya commented Sep 13, 2021 • edited Loading

tomsommer commented Sep 13, 2021 • edited Loading

mdo commented Sep 13, 2021

WilliamStam commented Sep 13, 2021

mdo commented Sep 14, 2021 • edited Loading

tomsommer commented Sep 14, 2021

mdo commented Sep 14, 2021

tomsommer commented Sep 14, 2021 • edited Loading

WilliamStam commented Sep 14, 2021 • edited Loading

mdo commented Sep 14, 2021

mdo commented Sep 15, 2021

tomsommer commented Sep 15, 2021 • edited Loading

mdo commented Sep 16, 2021

morkeleb commented Sep 20, 2021

WilliamStam commented Oct 6, 2021

tomsommer commented Oct 6, 2021

MrStonebender commented Oct 28, 2021

arcanisgk commented Apr 11, 2022

iatek commented Aug 17, 2021 •

edited

Loading

gigadie commented Aug 24, 2021 •

edited

Loading

WilliamStam commented Aug 24, 2021 •

edited

Loading

mdo commented Sep 9, 2021 •

edited

Loading

dgsiegel commented Sep 10, 2021 •

edited

Loading

tomsommer commented Sep 10, 2021 •

edited

Loading

isaumya commented Sep 13, 2021 •

edited

Loading

tomsommer commented Sep 13, 2021 •

edited

Loading

mdo commented Sep 14, 2021 •

edited

Loading

tomsommer commented Sep 14, 2021 •

edited

Loading

WilliamStam commented Sep 14, 2021 •

edited

Loading

tomsommer commented Sep 15, 2021 •

edited

Loading