Overriding Bootstrap Styles in Service Portal

[tmgarcia]

Is there any way to override Bootstrap CSS styles (not scss variables) on a theme or portal level in Service Portal? The way things are currently being built out, your portal's Theme styles are compiled and included, then any Portal CSS variables, then Bootstrap itself, and then you have any CSS include files. Obviously this order makes sense so that you can override Bootstraps SCSS variables (e.g. $link-color), since SASS doesn't have variable hoisting, but this also means that any CSS styles you have defined in your theme or Portal CSS gets overriden when Bootstrap's is coming afterwards. Is there anywhere that you can include SCSS code that will be loaded in after Bootstrap?

Essentially what I'm looking for is to accomplish a style ordering of

Base Theme styles > Portal Specific styles > Bootstrap styles > Overrides

For a specific example, say I want h1 to have a specific font-family and I want h2 to have a completely different font family. Bootstrap doesn't have separate SCSS variables I can override, it just sets every h# font family in one style, so where can I set this that it will be defined portal wide?

It could be done within page or widget specific styles, but that'd mean a lot of repetition and loss of re-usability for what should be simple global styles like h1s and h2s. It could be done in CSS includes since those do seem to come in after the SCSS compiled code, but it'd be preferable to do it somewhere that will still compile down SCSS code so I can reference variables. (As a side note, I'd so love to see SCSS includes become a thing in the future)

Edit: Here's a clearer example of what I'm talking about, from one of my replies down below (copied here for visibility)

Here's a hopefully more clear, concrete example of what is going on, keeping in mind that it is hypothetical, I am not literally storing every single font family in a separate variable, that's silly.

My Theme SCSS

$h1-font-family: Roboto Slab Thin, sans-serif;
$h2-font-family: Roboto Slab Light, sans-serif;
h1 {
         font-family: $h1-font-family;
}
h2 {
         font-family: $h2-font-family;
}

Bootstrap's scss (Included in the same file after my theme css)

h1,h2,h3,h4,h5,h6,
.h1, .h2, .h3, .h4, .h5, .h6 {
         font-family: $headings-font-family;/* This will now override my two separate header font family stylings */
         font-weight: $headings-font-weight;
         line-height: $headings-line-height;
         color: $headings-color;
}

The point, as this hopefully conveys, is that not every Bootstrap style can be overridden by overriding one of their SCSS variables. Some styles have to be overridden with actual style definitions, but still needing SCSS functionality. Like in this example, what I would have to do, what I'm looking for with this question, is to somehow be able to put this section of code

h1 {
         font-family: $h1-font-family;
}
h2 {
         font-family: $h2-font-family;
}

after that Bootstrap's scss section of code, so that it overrides their styling while still being able to reference SCSS variables.

Message was edited by: Taylor Garcia

[nathanfirth · Accepted solution]

Why not just increase the "specificity"? You could even do something like "html > body h1" or similar to increase the specificity to override Bootstrap. Or you could use !important;

Link: Specificity - CSS | MDN

[tmgarcia]

You know, I think I've been avoiding that route in an effort to stick to some existing scss styling rules we've got internally, but at this point, and with the weird front-end edge case SNow has already presented as a whole, increasing specificity is probably my best option. I do hope that I'll at least be able to keep fixes as general as your example there with scoping in as far as html > body so things don't get too crazy, but we'll see. Having sass support out of the box alone has saved me   time as is, with luck I can put some of this extra time to good use here.

Thank you so much Nathan for your help and patience with my admittedly convoluted question! Seriously, your assistance and knowledge sharing all over this community has saved me from more headaches than I can count.

[nathanfirth]

No worries, thank you... just glad I can help

[scottl]

I have a similar issue, where in my custom portal I'm having default bootstrap styles being intentionally overridden by a complied CSS file.

.../styles/scss/sp-bootstrap.scss?portal_id=xxxxxx

Yet I cannot find anywhere where it's being set, even thou i've not set these custom styles in my own portal.   Part of the file...

/**

* override bootstrap CSS and adding a few extra classes

**/

.alert-warning{

        ....colors are custom...

}

.alert-success{

        ....colors are custom...

}

This is exactly the issue I was talking about yesterday nathanfirth and reinforces my previous post that the way CSS is brought in and how CSS is being advised to be hardcoded directly into widgets, and is causing development and maintaining issues, esp. on non out of the box portals.   Surely a bespoke portal shouldn't need to reset the native bootstrap styles back to the defaults in the theme CSS because it's hardcoded somewhere in a mysterious widget, or in some magical hidden file.   However, maybe I'm missing something?

Any idea on where I can turn these complied overrides off?

[nathanfirth]

I don't think your issue is in widgets, as the CSS in widgets is scoped to just that widget and should not leak into global scope.

The compiled version of bootstrap is not completely stock. It's bootstrap + Servicenow styles + CSS utility classes. Then on top of that you get themes and any custom styles.