Bootstrap: Use custom properties (CSS variables) in bootstrap

Created on 25 May 2018 · 75Comments · Source: twbs/bootstrap

I like sass variables and they're great during buildtime. But projects that need a microfrontend architecture (i.e. webcomponents) tend not to rebuild components. They rather reuse existing components and provide the style context to it.

Using CSS variables will allow to provide runtime configuration for styling, such as colors. CSS variables can work in conjunction of SASS.
I'm happy with a few the first couple of CSS variables in bootstrap, but as already mentioned they're only exposed and not used by bootstrap itself. This means, if a project likes to override these CSS variables at runtime, there's no effect with the bootstrap components themself.

Is there anything against going into the CSS variable direction? Browser support is really great and the fallback option will keep non-supported browsers happy.

I understand this is a big change though. It woudl work like this:

Intialize CSS vars. We use use double-double fallback to ensure we have a fallack and do not need to repeately add the fallback everywhere.

:root {
    --primary: var(--primary-color, #{$primary});
}

Then for each and every component that uses the primary color, we could use the --primary variable instead. For example on a button, it would go like this (just a few lines that i'm using in my sandbox project, so its not so relevant to bootstrap sources):

.btn {
    &-primary {
        background-color: var(--primary);
        border-color: var(--primary);
        &:hover,
        &:not(:disabled):not(.disabled):active {
            background-color: var(--primary-darken);
            border-color: var(--primary-darken);
        }
    }
}

This would allow to change the color at runtime.

css feature v4

Source

tobi-or-not-tobi

👍75 🎉19 ❤18

Most helpful comment

@mdo has been a long trip with Bootstrap and being grateful for your work, but I believe you are being stubborn on this one.

CSS Variables are 100% supported on green browsers and the global usage is quite enough for saying that we should start embracing the technology.

Keeping v5 without major updates shouldn’t be the goal, like I said Bootstrap has been breaking changes every major release and everyone is aware of that.

I do not believe that the rearchitecture has to be that bad, specially that must of the source code is well known and written so far.

Progressive enhancement always exists and we could slowly upgrade the framework to be 100% CSS variables with all the good practices in the future.

Sorry, but I can see any valid point for not doing it. I would take the initiative of written the spec of the changes and the roadmap and implement it if you want.

I don’t want to create another Bootstrap and having to deal with marketing the framework. I would love to see you change your mind.

Just put in perspective the implications of not doing this agains your thoughts right now.

yordis on 9 Jul 2018

👍30

All 75 comments

Bootstrap supports IE10 & IE11 which don't support CSS Variables (Custom Properties), I'm afraid we can't do this right now.

MartijnCuppens on 26 May 2018

Understood that support for IE10/11 still is important. What about introducing a fallback. We could have a mixin that would generate both the fallback as well as the custom property.

@mixin customProperty($name, $value) {

    // fallback for older browser who do not support custom properties / css variables
    #{$name}: #{$value};

    // create a css variable (this might override the variable on any of the ancestor elements)
    --#{$name}: #{$value};

    // use the css variable on the property
    #{$name}: var(--#{$name}, #{$value});
}

Alternatively we could use postcss but I'm personally not so much in favor of that since it doesn't allow to use those properties outside the root scope.

tobi-or-not-tobi on 29 May 2018

👍12

Could you provide a demo of how you would use that mixin?

MartijnCuppens on 29 May 2018

Hi @MartijnCuppens,
I'd use it like this:

In a selector call the mixin:

.any-selector {
  @include customProperty('color', #{$primary});
}

This would give the following output, with $primary set to #ffffff;

.any-selector {
  color: #ffffff
  --color: #ffffff;
  color: var(--color, #ffffff);
}

In addition, we could make the fallback optional, by introducing a sass variable.

btw, it's just a quick example.

tobi-or-not-tobi on 29 May 2018

Hmm, and what is the benefit of that? Aren't you always overwriting the variable?

MartijnCuppens on 29 May 2018

Custom properties will give a lot of benefits to the code base (you might want to have a look at https://www.youtube.com/watch?v=2an6-WVPuJU), but in the context of this ticket I'm mainly interesting in extendibility. Especially for projects that run in the cloud and should allow to override some variables (i.e. primary color) without a rebuild of the code.

Besides extensibility (which is big word for just configuring the vars), it also allows for easy upgradability.

tobi-or-not-tobi on 30 May 2018

Hi @tobi-or-not-tobi I love CSS variables, but @MartijnCuppens has a good point, since they are not supported on IE11, it'd be a huge effort to change every declaration to be a mixin, not to mention that we the sass abstraction would get too far away from real CSS in my opinion.

I know this will not solve your usecase, but the first step we are taking towers custom properties is exposing our color pallet as CSS variables:
https://github.com/twbs/bootstrap/blob/v4-dev/scss/_root.scss

@mdo Maybe we can add using css variables as an idea for v5?

andresgalante on 30 May 2018

Thanks @andresgalante. I'm aware of the variables being exposed (and that's great), but it unfortunately doesn't allow to override them at runtime. The compatibility concerns make sense though.

tobi-or-not-tobi on 30 May 2018

👍3

What about using something like that: https://github.com/malyw/css-vars. Abstraction not too far from CSS, and there is option to generate and load separate file for browsers which do not support CSS variables.

normux on 30 May 2018

I'm afraid we can't just use a mixin to mimic the exact behaviour of CSS variables. Also bootstrap uses a lot of darken() and lighten() sass functions, which can't be applied to CSS variables. There is also the color-yiq function which determines the text color based on the background-color of buttons (that's why the text color of the warning button is dark on the bootstrap docs) which won't work anymore.

If we find a solution for this, we could think about generously implementing them in v5 only if IE support is dropped.

(btw, sorry for being the party pooper here 😉)

MartijnCuppens on 30 May 2018

👍1

The lack of darken, lighten and color-yig like functions in vanilla CSS doesn't need to be a show stopper here imho. Those functions can and should still be used at build time, and could be in addition exposed as color variants, i.e. --primary-darken.

Library consumers can configure those variants at _build time_ as they're used to, but in case they want to use runtime configuration (or extend without rebuilding), they will be responsible for configuring those custom properties technique that suits them. Javascript comes to mind, but even existing HSL color system would already work. Whenever CSS color-mod comes around, it will be more convenient.

(btw, sorry for being so persistent here 😉 – I understand the concerns, but want to think in solutions before dropping the whole idea altogether)

tobi-or-not-tobi on 31 May 2018

👍3

@NormSukhrob I guess we first need to wait whether bootstrap wants to move into this direction or not. Then the technical implementation can be done, personally I think using an external dependency for such a small thing is a bit of an overkill, but its good inspiration.

tobi-or-not-tobi on 1 Jun 2018

It was just an example of some flexible solution.

CSS variables great modern feature, and as most popular frontend library, bootstrap shouldn't escape usage of it. IMHO

As suggested, developers could have a choice using vars in runtime or just in build time. Yes, some workarounds or better solutions will be needed, like your suggestion using *-darken or with additional *-darken, *-lighten maps which can be by default computed from darken() and lighten() functions for build time option in separate computed variables file, which can be different for runtime and build time usages. Even for build time usage it will give more control over colors for devs.

I believe, nowadays, with a popularity of frameworks like angular, react and etc., flexibility and dynamic features in great demand.

Hope, bootstrap team will make steps toward CSS variables.

P.S. and very hope that we will not have to wait v5))))))

normux on 1 Jun 2018

👍2

Replacing lighten() and darken() in SASS could be done with using hsl() colors.

See https://developer.mozilla.org/en-US/docs/Web/CSS/color_value#hsl()

And it works from IE8 onwards. https://msdn.microsoft.com/en-us/library/hh781508(v=vs.85).aspx#colors

herbalite on 3 Jun 2018

👍3

@andresgalante would be this part of v4 or actually v5 I am saying because of the label v4 that you added.

For this to be able to make it into production we need to drop support for IE, which I totally support, because few of us still care about IE shouldn't mean we need to be lock down in time until they want to convert or take business decisions (we still having marquee tags in the core browser cores, we will never get there if we wait for them).

yordis on 5 Jun 2018

No plans to rearchitect all of the codebase to do this. It'd be a significant investment and involve rewriting just about everything.

mdo on 9 Jul 2018

👎8

Like every single version of Boostrap that you break backwards compatibility and because you rearchitect everything.

Don’t take it personally but it is the truth.

So I don’t see how you could use that argument to be honest. Specially that you don’t need to rearchitect that much (progressive enhancement exists)

yordis on 9 Jul 2018

👍3

@yordis Last time I rewrote everything, it took me over three years to do it :). My hope for v5 was not to fundamentally change the project, but to do a less disruptive change. My point isn't that this cannot happen, but it would take a breaking change (aka, major) release to do it and a lot of time.

mdo on 9 Jul 2018

@mdo do I get it right that the vision is that CSS custom properties are not for Bootstrap?

The runtime configurability of CSS custom properties over build-time configurability are huge, imho. Webapps are going to change with smaller reusable webcomponents, using view encapsulation that _cannot_ be controlled with a global css. Cloud native applications prefer configurability over extensibility.

Imagine we would change the primary color for an app with a large number of webcomponents. Without CSS custom properties, it means that we need to rebuild and redeploy all the webcomponents (assuming primary color is used everywhere) and clients can no longer use the cached components (which is so important . Moreover, the components are not reusable as the CSS is baken into the component.

Using CSS custom properties is going to make a much better story. Web components can be reused by multiple apps; CSS custom properties _do_ pass the encapsulated shadow DOM by design; changing CSS custom properties do not require a new build, deployment and the components do not need to be evicted from caches.

tobi-or-not-tobi on 9 Jul 2018

👍21