v5: Improve customization by allowing manually setting calculated variables in styles

Hello!

We can have cases when we need to change specific style property, but we can’t do this because this property value set up in Bootstrap library as calculated formula. The idea is to create separate variables for these cases and precalculate it in default values of these variables.

The same was done in this issue and PR, but only for button component: https://github.com/twbs/bootstrap/issues/28899 https://github.com/twbs/bootstrap/pull/29444

The idea is to follow this practice in all components.

Example

Before:

@mixin list-group-item-variant($state, $background, $color) {
  .list-group-item-#{$state} {
    // ...
    background-color: darken($background, 5%);
    // ...
  }
}

After:

@mixin list-group-item-variant($state, $background, $color, $background-hover: darken($background, 5%)) {
  .list-group-item-#{$state} {
    // ...
    background-color: $background-hover;
    // ...
  }
}

The same can be done not only for colors, but for calculated unit values:

Before:

.card-subtitle {
  margin-top: -$card-spacer-y / 2;
}

After:

// In variables:
$card-subtitle-spacer: -$card-spacer-y / 2 !default;

// In styles:
.card-subtitle {
  margin-top: $card-subtitle-spacer;
}

Benefits

• Allows to customize more properties and if you don’t need - just keep default calculation of the value
• Allows to transform it to CSS variable usage by setting e.g. $background-hover: var(--bs-background-hover); (if we have background-color: darken($background, 5%); we can’t do this)

Drawbacks

• More variables to support
• Longer migration guide (probably)

What do you thik about this? Should I do a PR?

[septatrix]

I really like this idea though I think it will be most useful for colors (and therefore theming). The majority of people is unlikely to tinker with margins. Instead there is an abundance of people wanting to tweak and adjust colors.

Introducing this for parameters unrelated to colors is certainly nice however it needs to be carefully evaluated what properties are of relevance and as @mdo pointed out where some distinctions are over-engineered and superfluous.

Where I cannot wait for this feature however are colors. Bundled with css custom properties this allows many great new opportunities while still being backwards compatible. Many components calculate colors based on the SCSS color map and this map also gets exported as css variables. However as lightening and darkening of these colors is necessary the components do not use the css variables themself. Changing them therefore has no effect but they only grant the ability to match one’s own css to the bootstrap colors.

Most variables are however already defined inside variables.scss. Some of these are already exposed as css variables and actually used by components (tables, some gutters, breadcrumb divider). Expanding the usage of this pattern seems to be a goal of the bootstrap authors and I expect more components to adopt this behaviour for v5.1 (as I do not expect any substantial features for the next beta(s)) as it is backwards compatible. What I am really excited for however would the adoption of this pattern for colors. This would enable many possibilities of changing things during the runtime (e.g. dark and light theme).

[ydmitry]

Personally, I’m still interested in these changes, I think better not to do this for sizes, only for colors and do small PRs as you said

If I’m only one contributor for this issue I need to know target dates for beta to check if I can contribute