Use custom properties (CSS variables) in bootstrap

tobi-or-not-tobi commented 6 years ago

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.

MartijnCuppens commented 6 years ago

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

tobi-or-not-tobi commented 6 years ago

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.

MartijnCuppens commented 6 years ago

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

tobi-or-not-tobi commented 6 years ago

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.

MartijnCuppens commented 6 years ago

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

tobi-or-not-tobi commented 6 years ago

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.

andresgalante commented 6 years ago

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?

tobi-or-not-tobi commented 6 years ago

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.

normux commented 6 years ago

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.

MartijnCuppens commented 6 years ago

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 😉)

tobi-or-not-tobi commented 6 years ago

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 commented 6 years ago

@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.

normux commented 6 years ago

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))))))

herbalite commented 6 years ago

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

yordis commented 6 years ago

@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).

mdo commented 6 years ago

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

yordis commented 6 years ago

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)

mdo commented 6 years ago

@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.

tobi-or-not-tobi commented 6 years ago

@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.

yordis commented 6 years ago

@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.

felschr commented 6 years ago

Isn't it possible for you to distribute a 2nd file, something like bootstrap.customproperties.css? This way it doesn't have to brake any existing websites.

Just give us the option.

andrew-mykhalchuk commented 6 years ago

Or use something similar to this polyfill - https://github.com/jhildenbiddle/css-vars-ponyfill. I tested it in one of my recent projects and it worked really well. Possibly even load it only in IE 10/11 only to avoid additional JS in modern browsers.

Hermanya commented 5 years ago

Inspired by this issue, I figured that it's possible to take the existing bootstrap CSS, parse all colors, figure out the color palette and replace all colors with variables. I wrote a blog post about it in a little more detail: https://medium.com/@Hermanhasawish/how-i-repainted-bootstrap-without-sass-d789f41aa74b

piernik commented 5 years ago

@Hermanya Do You have source scss files?

Hermanya commented 5 years ago

@piernik as I replied on medium, I don't have a source scss file, because I'm not relying on scss to generate the color palette. With this css file from my blog post, you can set a bunch of css variables with color codes generated using a tool like https://hermanya.github.io/palette/ or https://palx.jxnblk.com

darkguy2008 commented 4 years ago

I cannot agree more with @yordis on this one. 2020 and Bootstrap isn't using CSS variables yet? It sucks that such an awesome proposal gets closed without any valid reason, considering it's leading most web development being the most used framework everywhere, yet it falls short on features like these.

The implementation should not be too hard, I found these links with great useful info - in fact, I worked on something last night to use CSS variables and so far it's working well. The downside is that I have to specify all overrides in a separace scss file. Sucks but hey, CSS variables are used.

Here's some food for thought: https://codyhouse.co/blog/post/how-to-combine-sass-color-functions-and-css-variables

@Hermanya 's post was greatly useful as well, but it leverages on the postprocessed code to apply the variables. Maybe a post-css-loader can be written or something, but that'd be for webpack users or things like that. IMHO, I think that bootstrap and the browsers are already mature enough to support CSS variables out-of-the-box with just a few changes, as already demonstrated by the codyhouse link.

It'd be great if you guys can change your mind. As Yordis said, I don't want to make another bootstrap and deal with all the stuff around it, but attitudes like these sometimes don't give you much choice. You should listen to your users, to your community, just like Docker just did.

johanlef commented 4 years ago

The color-yiq function seems to be the bottleneck here, since the lightness of var(--color) is unknown when compiling scss. Maybe someone comes up with some magic calc() of hsl values to solve this?

If it can help anyone, I wrote this gist which is an effort to handle custom properties in combination with bootstrap.scss. It’s not perfect yet, so please test this in your environment before use in production. It consists basically of converting your colors to hsl and applying transformations on those values. JS can help you converting hex and rgb to hsl.

Update 2019-03-24: I solved the color-yiq problem in the latest version of my gist (follow my bootstrap import order to make this work!).

dylan-westbury commented 4 years ago

sass variables are not dynamic, css variables are. This is helpful when working on features such as darkmode.

Please allow theming by css variables defined outside of bootstrap.css

MartijnCuppens commented 4 years ago

Let's do this. Not sure what approach we should take, we have lot's of shades of the primary color for example and have to find a way to deal with all these shades.

johanlef commented 4 years ago

I made an attempt here to bypass some bootstrap and sass functions to be able to use custom properties. Basically, I replicated each function which turned out to be problematic* to understand values like hsl(var(--primary-h), var(--primary-s), var(--primary-l)) since they are the easiest to work with in terms of changing the color values using calc(). However, I guess it would be too strict as a requirement to define all color values in hsl, unless there is a way to fix that.

*Problematic functions like lighten, darken, mix and color-yiq expect their params to be color values instead of --var.

MartijnCuppens commented 4 years ago

Relying on lightness might not be the best idea since the palette can be a little unpredictable, see https://codepen.io/joshmcrty/pen/OVZbBr

yordis commented 4 years ago

@MartijnCuppens I would love to help you with the execution of this, but I am not sure how we could sync up and where to start writing a proposal to some execution plan.

We could just open ourselves to random PRs, but it will require a lot of back and forward since multiple people could be conflicting with each other.

Personally, I would replace one-to-one SASS variables per component before tackling big files that may have a huge impact but it would slow the PR review process and harder to prevent bugs.

Related to: #30494

darkguy2008 commented 4 years ago

I agree with @yordis and are also willing to help with this. I don't think changing the variables one-to-one per component is bad. It's actually a good, procedural approach to it.

I have a solution somewhat ready that doesn't require changing variables or overriding functions in bootstrap. I'll share a repo or gist soon :)

ffoodd commented 4 years ago

Be careful there: CSS custom properties are not a replacement for Sass variables.

Sass variables are pre-processed, custom properties are not: this means Sass variables bloat the source code whereas custom properties bloat the generated output, that is bad.
Sass variables can thus be used to customize Bootstrap on build time and deliver static optimized assets, whereas custom properties are applied on runtime in the browser, which is possibly negligible but conceptually bad;
custom properties are inherited, which should be carefully used: extremely powerful, but could lead to style leaks too.

They can be very useful for components variants to prevent duplication in generated output (@MartijnCuppens is using them for Tables in #30466 for example) or to play with some context on runtime (like say, data-* attribute values or whatever).

But replacing font-weight: 300 by font-weight: var(--fw-300); or whatever is a nonsense to me: this is just longer and really benefits from being customized on the Sass-side.

@twbs/css-review I think we should define a clear position about this, before crumbling under custom properties related PR.

MartijnCuppens commented 4 years ago

Be careful there: CSS custom properties are not a replacement for Sass variables.

Indeed! Not planning to convert our whole _variables.scss to custom properties.

This is not going to be an easy job, we got to figure out have to combine the powers of Sass and custom properties.

darkguy2008 commented 4 years ago

@ffoodd While I do agree, if I may chip in, in my case I'm developing an Angular app that heavily uses bootstrap and it allows customization by the user for their different clients, so they can have, in my case, their brand colors in the interface.

Using CSS variables has proven to be really useful in the sense that the app doesn't have to be recompiled to add either "skins" or support a limited color set (and also bloating the source code) and instead use CSS variables for colors only.

I don't think that using them is "bad" at all. I don't see anything wrong with using a CSS variable with font sizes though, if you want to provide an accessibility feature, some users (like my mom) don't know the hotkeys for increasing font size so a small drop-down for changing that without reloading the page (performance-wise, it makes sense!) Is very appreciated. Heck, even Stack Overflow implemented dark mode with a small toggle. The docker docs also do this as well. It would be just natural that bootstrap supports CSS variables in 2020. If Ionic can do it and keep up with the latest trends, why bootstrap can't?

Also, happy to see this is not a proposal anymore but a task :) will share the gist tomorrow!

ffoodd commented 4 years ago

I don't think that using them is "bad" at all.

Neither do I :D But some use cases are — mostly those increasing code bloat and making millions of users downloading too much code, don't you agree?

Bootstrap will (and is starting) to use custom properties, that's a fact. No debate there.

However let me walk through your examples

Branding UI

Branding your app UI is a great idea (done this too) and using custom properties sure is the way to go — I also suggest using an input type=color and localStorage for this ;) — however that's not a Bootstrap feature: what you're suggesting would result in an increased Bootstrap's file size to match your very specific need, thus make every other Bootstrap user load more code without any need for them. We can't do that, obviously.

However using a customized Bootstrap doesn't prevent you from using custom properties as values in _variables.scss, and setting them roughly in _root.scss. Which won't bloat your code that much, given that this is an important feature for your project.

Changing font-size

Relying on a dropdown to change font-size is weird (seriously, Firefox gives you zoom control beside the address bar) but let's go: even for this specific need, custom properties wouldn't be the way to go. Bootstrap completely relies on rem unit (which is fluid) and RFS (which is great ;)): given that this dropdown should zoom in or out your UI, it'd only take you to change the :root font-size.

So using custom properties everywhere would be way much heavier than simply changing root font-size.

Dark mode

Well, this one is probably a very good candidate — you may find somes issues and PRs about dark mode (mostly on a component basis), but will defintely need a deeper reflexion now that we can use custom properties.

We'll have to make this step-by-step, but Bootstrap v5 will keep on using custom properties :)

drsounds commented 4 years ago

I assume the big issue there is no support for color modification like it is in SASS in css3

nextgenthemes commented 4 years ago

Be careful there: CSS custom properties are not a replacement for Sass variables.

Sass variables are pre-processed, custom properties are not: this means Sass variables bloat the source code whereas custom properties bloat the generated output, that is bad.

It's not bad the benefits totally outweigh the few bytes it will add to the CSS.

Sass variables can thus be used to customize Bootstrap on build time and deliver static optimized assets, whereas custom properties are applied on runtime in the browser, which is possibly negligible but conceptually bad;

BS! It's conceptually very good because you no longer have to compile the CSS very time you want to try a new color var.
They work in the browsers' dev tools and its such a pleasure to work with them and not having compile a sass file and refresh the browser in rely on CSS injection listening tools. This is huge!
And even better for not so technical people who do not even know what browser devtools are or what SCSS is. WordPress for example has a live CSS editor. It's not that impressive on its own but with themes that heavily use CSS vars it's a killer feature everyone can dive into color theme creating and see the result live faster than and in browser SCSS compiler ever can do it! I thought about integrating a SCSS in browser compiler into it but when CSS vars in Bootstrap become a reality this is not needed and faster and less complex. @twbs/css-review please never close this again.

custom properties are inherited, which should be carefully used: extremely powerful, but could lead to style leaks too.

I do not understand that styleleaks issue at this point but. Bootstrap already has decided to prefix CSS vars with --bs. The fact that they are inherited is actually very good! It creates new and awesome opportunities to have variations of components ...

They can be very useful for components variants to prevent duplication in generated output (@MartijnCuppens is using them for Tables in #30466 for example) or to play with some context on runtime (like say, data-* attribute values or whatever).

And you know that already. But only highlight bad, badbad ...

One of the best reasons to do basically all vars in CSS would be Dark Mode. It would actually need more CSS then just have separate themes and load a different file based on user dark more setting. But I would prefer a simpler and easier dark mode. With SCSS variables simply switch on dark mode media query.

I am a bit confused how this is supposed to go forward. I looked at https://github.com/twbs/bootstrap/pull/30466 and its seems to be about reducing the variant code, great but why nest the variables on .table. This way they can not be reused elsewhere.

How about simply creating all CSS vars in :root { ? Please do not argue with CSS bloat. Bootstrap was never about being minimalistic with all the utility classes ... Apart from that I do not think it will actually take up that many bytes to do this. It's not bloat if it's actually very useful.

My suggestion would be to simply write over almost all SCSS vars to CSS vars into :root { but maybe keep _variables.scss as it at least for v4 as people rely on SCSS code based on those. For v5 maybe consider actually removing variables that are not needed. What are the issues/blocks?

In v5 _variables.scss lighten() is actually only used 2 times. Darken 5 times. I am sure this can be done with a PostCSS without ever really looking. But the question is, is it really needed? There is a customizer coming. If could actually just calculate those in plain JS and then just print out fixed colors, maybe with a comment like // this is color xxxx darkened xx%.

What about just using split up hsl() colors and then a variable like. --bs-table-hover-color-lightness: 80%; is this possible? Never tried this, may be just overcomplicate things to just keeping both or using postCSS maybe better?

Obviously things to generate the grid need to stay in scss, but I am wondering if many if not almost all SCSS vars can be actually dropped. But maybe its just easier to keep them in case later something is needed in SCSS? The actual CSS calc() can be used to things as well like halving paddings and simple things that BS currently uses SCSS for. This way simple themes are not just about colors and can be prototyped fast. The new customizer can have a limited live preview without having to use an in browser SCSS compiler.

W8, actually there is this Idea out for v5 to create a new flex based grid, maybe no complicated grid generation needed at all in the future. I can see Bootstrap using SCSS basically only for nesting and file organization in the future.

Just thinking out loud here, not proposing anything else than just create all CSS vars in :root{. And actually use them in the other files. What would happen if https://github.com/twbs/bootstrap/pull/30495/files would be PRed again? Another insta rejection? What has changed now?

piernik commented 4 years ago

About different shades of colors. Why not multiple color variations? --bs-blue-100 (almost black), --bs-blue-200, --bs-blue-900 (almost white) and so on. Creating those in scss wouldn't be a problem. Problem with manipulating colors in browser could be easily resolved with javascript. You pick only 500 variant and js would calculate remaining variants. Bootstrap team could create such js library and website owners (if want to privide UI with color customization) can use it.

yordis commented 4 years ago

What would happen if https://github.com/twbs/bootstrap/pull/30495/files would be PRed again? Another insta rejection? What has changed now?

@nextgenthemes they burned me out, took the time to propose something #30494 to end up talking about nonsensical and obvious things; assuming that I am stupid or something?!

Stuck in analysis paralysis and trying to answer all the questions instead of letting the code to answer the questions for them 🤷

Good luck with the adventure.

mdo commented 4 years ago

Tons of progress has been made on Bootstrap's source code outside this issue, so let's not lose site of the fact that we've already implemented tons of CSS variables :). We're doing it because only recently did we fully drop IE11 support in v5; at the start of this issue around two years ago, v5 wasn't even on our radar.

Okay, with that out of the way, here's the other gotcha—v5 will not be a massive departure from v4. As such, Sass is the preprocessor of choice, so for now, this is about finding a balance between Sass and CSS vars. We'll continue to have that mindset through v5, and perhaps in v6 abandon Sass if the stars align.

Addressing some other points raised here:

We won't be using JS to adjust what CSS/Sass can do for us now, so no thanks to the JS modified colors :).
@yordis Your PR was closed because the complete transition from Sass to CSS vars adds at least 1,000 lines of CSS before minification. _variables.scss is 1,200+ lines. Coupled with the goal of making v4 to v5 transitions easier, we're not interested in a full transition at this time.

Moreover, moving the .display- Sass vars to CSS vars comes at the cost of using Sass maps to generate these classes. I'm sure something exists for PostCSS to accomplish this as well, but at this time, a hybrid approach is preferred and more powerful.
We likely could remove all of the lighten() and darken() functions with a little bit of clever engineering. We'll keep looking into that.
CSS vars fallbacks are great—love them overall and just wrote a short blog post about some experiments with them as a way to control global options. It's not perfect, and can't be used in every situation, but it's definitely interesting.
As @MartijnCuppens and @ffoodd have mentioned, we're definitely pushing on using CSS vars for components and utilities where we can. I also think we can do more with color utilities and component modifiers, so expect some changes there as well.

Bottom line is we're hoping to find a balance. Help us out by pointing out where customization without compilation would be a huge boost to your productivity and more. I'd love to keep chipping away at this and keep the project evolving like everyone else would prefer :).

Hope that helps!

Arturace commented 4 years ago

Personally when I think custom css props, I think size and color.

Color, obviously means user selected theming and color blind options (never ran into that personally, but apparently can be an issue).
Size: custom margins, paddings and font-size.

Also, as a random proposition, if css custom properties will be used for coloring, there might be a use for pre-made theming classes, generated through sass (like inverted colors, or dimmer colors).

indigoram89old commented 4 years ago

+1

I need to create ability to switch a theme for the users on the fly. With css variables it will be very simple but now I will to find another solution....

felixfbecker commented 4 years ago

The most impactful step Bootstrap could take towards this in v5 would be removing usages of darken() et al and allowing those to be individual SCSS variables. They can still be defaulted to darken() another SCSS variable, so it should be mostly backwards-compatible, but this would allow us to set all SCSS variables to equivalent CSS variables without the compiler choking on it. Currently we can achieve that for some components, but not for those that use darken(), like buttons.

Of course if eventually Bootstrap moved to CSS vars directly for most things only that would be amazing, but this step would already provide a lot of value.

ghost commented 4 years ago

hey, just have a little idea for but rather global here we have https://github.com/twbs/bootstrap/blob/main/scss/_root.scss#L4

--bs

as prefix does it make sense to make it another variable for prefix

$prefix: "--rtx";

:root {
  @each $color, $value in $colors {
    #{$prefix}-#{$color}: #{$value};
  }

it will be possible to change "brand" prefix potentially may break some functionality but will be more comfortable especially while create own kit and want reuse some bt styles?

i don't know is it comfortable for anybody?

ydmitry commented 4 years ago

The most impactful step Bootstrap could take towards this in v5 would be removing usages of darken() et al and allowing those to be individual SCSS variables. They can still be defaulted to darken() another SCSS variable, so it should be mostly backwards-compatible, but this would allow us to set all SCSS variables to equivalent CSS variables without the compiler choking on it. Currently we can achieve that for some components, but not for those that use darken(), like buttons.

Of course if eventually Bootstrap moved to CSS vars directly for most things only that would be amazing, but this step would already provide a lot of value.

https://github.com/twbs/bootstrap/issues/31538 there is an issue about it, avoiding formulas in styles can help both with customizations and make Bootstrap CSS variables friendly

mdo commented 4 years ago

Just opened a PR for a new Sass variable for the CSS variable prefix: https://github.com/twbs/bootstrap/pull/31684. Good suggestion, @8nix!

mdo commented 4 years ago

@felixfbecker There's a PR at #30622 from @MartijnCuppens that is rewriting some colors work. Still using some tints/shades, but we can likely pare things down further in addition to that PR.

mdo commented 4 years ago

Regarding some CSS vars in components, is this the direction folks are wanting? See #31685 and #30500.

twbs / bootstrap