You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Has any thought been put into overriding Bootstrap mixins?
I have a use case, where for example, I want to override the definition of a bootstrap mixin to provide additional styles, or modify existing styles slightly.
The problem with this is that SASS does not use the overridden mixin in certain cases, such as in an @include statement.
For example, I've overriden the color-yiq mixin, and then the button-variant mixin. The button-variant mixin uses the correct (redefined) color-yiq mixin, because it was defined prior to the redefinition of the button-variant mixin.
However, the badge-variant mixin references the previously defined color-yiq mixin, because I have not overridden the badge-variant mixin.
The flow is something like:
color-yiq defined by Bootstrap
button-variant mixin defined by Bootstrap
badge-variant mixin defined by Bootstrap
color-yiq redefined by me
button-variant redefined be me
The output looks like the following (pay attention to the text colour for the btn-warning and badge-warning):
It would seem that the only way around this that I can think of is to redefine every single mixin that uses the color-yiq mixin, which seems massively overkill.
I can't be the only person in the world who would want to override a Bootstrap SASS mixin, surely?
Any ideas?
Reacted by Adam Patterson, César , Egor Pogadaev, Oskar Golde, Mark Woon, Ernest, Jaha Ganiev, Filip Petrovic and Sadegh Barati
I agree, Personally, I don't see why Bootstrap is making my button colour decisions for me.
I have a blue button. Maybe a medium level of blue that I want to have white text.
After updating to the beta, my button text was made #111. When my button is on a dark background I don't feel like the text should be dark. In fact, that's not the point. I should be able to make it green, or red.
My site is minimal so that was the only thing that I ran into issues with.
Just to be clear, the issue here isn't unique to the color-yiq mixin, or button text colours - It was just the first example that I ran into serious issues.
Even if color-yiq is changed/removed/whatever, we still need a way to override any of the Bootstrap mixins with our own definitions and have them be used throughout SASS compilation in perpituity.
There is a way to fix your issues but you must modify bootstrap.scss
In our project we modified bootstrap.scss and after @import "mixins" we added @import "mixins_override";
and if we want for example override something we put in _mixins_override.scss
Yeah, the problem with modifying the core Bootstrap files is that whenever someone pulls Bootstrap from a package manager, it overwrites the files and then we lose our (visually important) changes.
Hence I think the core team need to put some more thought into providing a proper mechanism for overriding mixins.
I ran into the same issue, too. The generated button for my custom color has a black text-color, but I needed white.
@DaleMckeown A good workaround for me is to copy all imports from bootstrap.scss to a custom file in my project structure. Instead of importing only bootstrap.scss like @import "bootstrap/scss/bootstrap";, I now import every part of bootstrap individually:
Please notice the updated paths. On this way, you can include a custom mixin_override.scss like @wojtask9 said, and update bootstrap without losing your changes.
But I look forward to a nicer solution overriding bootstrap's core mixins and functions...
@Sebiworld Thanks for the suggestion. In the absence of a better solution, I've implemented the same thing as you have.
This issue was probably an unintended consequence from the change from LESS to SASS. Let's hope the core team can provide something a bit better in future versions.
Indeed. It is quite opinionated to have this code in a mixin: @if ($yiq >= 150) { @return #111; } @else { @return #fff; }
What about having these two colors available as variables maybe?
I have been trying to override the button-variant mixin. The issue is that when the mixin is redefined using the same name in the custom.scss file, and then the following code is added below the overridden mixin: @each $color, $value in $theme-colors { .btn-#{$color} { @include button-variant($value, $value); } }
...there is duplication of the compiled button css.
This happens when the custom mixin code and the code above is added in custom.scss file after importing bootstrap. Whereas, when this code is added above the import, the default code overwrites the overridden code. And no change is noticed.
I've been trying to implement disabling of the :hover styles when the device doesn't support hover and I wanted to override the mixins too. I ended up overriding all the :hover styling with the non-hovered versions, which sucks. +1 for having some kind of ability to override the mixins.
Reacted by stasiek-sarnecki, Nahuel Soldevilla and Cesar
Activity
adampatterson commentedon Aug 16, 2017
I agree, Personally, I don't see why Bootstrap is making my button colour decisions for me.
I have a blue button. Maybe a medium level of blue that I want to have white text.
After updating to the beta, my button text was made #111. When my button is on a dark background I don't feel like the text should be dark. In fact, that's not the point. I should be able to make it green, or red.
My site is minimal so that was the only thing that I ran into issues with.
DaleMckeown commentedon Aug 16, 2017
Just to be clear, the issue here isn't unique to the
color-yiqmixin, or button text colours - It was just the first example that I ran into serious issues.Even if
color-yiqis changed/removed/whatever, we still need a way to override any of the Bootstrap mixins with our own definitions and have them be used throughout SASS compilation in perpituity.wojtask9 commentedon Aug 16, 2017
There is a way to fix your issues but you must modify
bootstrap.scssIn our project we modified
bootstrap.scssand after@import "mixins"we added@import "mixins_override";and if we want for example override something we put in
_mixins_override.scsspart of our bootstrap.scss
In this way you are able to override only
color-yiqand everything should be OK.Not a nice solution thought :/
DaleMckeown commentedon Aug 16, 2017
Yeah, the problem with modifying the core Bootstrap files is that whenever someone pulls Bootstrap from a package manager, it overwrites the files and then we lose our (visually important) changes.
Hence I think the core team need to put some more thought into providing a proper mechanism for overriding mixins.
Sebiworld commentedon Aug 16, 2017
I ran into the same issue, too. The generated button for my custom color has a black text-color, but I needed white.
@DaleMckeown A good workaround for me is to copy all imports from bootstrap.scss to a custom file in my project structure. Instead of importing only bootstrap.scss like
@import "bootstrap/scss/bootstrap";, I now import every part of bootstrap individually:Please notice the updated paths. On this way, you can include a custom
mixin_override.scsslike @wojtask9 said, and update bootstrap without losing your changes.But I look forward to a nicer solution overriding bootstrap's core mixins and functions...
DaleMckeown commentedon Aug 17, 2017
@Sebiworld Thanks for the suggestion. In the absence of a better solution, I've implemented the same thing as you have.
This issue was probably an unintended consequence from the change from LESS to SASS. Let's hope the core team can provide something a bit better in future versions.
XhmikosR commentedon Aug 17, 2017
/CC @mdo
markwoon commentedon Oct 16, 2017
We're experiencing similar issues here. I'd love to see an official way to override mixins.
adampatterson commentedon Oct 17, 2017
@Sebiworld I take a similar approach, but the main issue I see is structure changes form the framework which has happened in 3.*.
But like I said, I do this as well and mostly to remove styling that I don't use.
I also don't want to rewrite mixens, I think they are the reason Bootstrap is so good.
mdo commentedon Oct 23, 2017
I'd suggest duplicating or augmenting the mixins manually—we've no plans to dive deep into Sass placeholders or anything like that at this point.
adampatterson commentedon Oct 23, 2017
@mdo I think that the biggest issue people had was Bootstrap determining colours for us.
francescozaia commentedon Nov 24, 2017
Indeed. It is quite opinionated to have this code in a mixin:
@if ($yiq >= 150) { @return #111; } @else { @return #fff; }What about having these two colors available as variables maybe?
DaleMckeown commentedon Nov 24, 2017
@francescozaia This has already been done in #24426
It's currently targetted for Beta 3.
vagu71 commentedon May 31, 2019
I have been trying to override the button-variant mixin. The issue is that when the mixin is redefined using the same name in the custom.scss file, and then the following code is added below the overridden mixin:
@each $color, $value in $theme-colors { .btn-#{$color} { @include button-variant($value, $value); } }...there is duplication of the compiled button css.
This happens when the custom mixin code and the code above is added in custom.scss file after importing bootstrap. Whereas, when this code is added above the import, the default code overwrites the overridden code. And no change is noticed.
richardthombs commentedon Jun 6, 2019
I've been trying to implement disabling of the :hover styles when the device doesn't support hover and I wanted to override the mixins too. I ended up overriding all the :hover styling with the non-hovered versions, which sucks. +1 for having some kind of ability to override the mixins.