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

[scottl]

I was hoping that was the case re. widgets being scoped.   From what I have gathered it's ServiceNow hardcoding these styles specifically for the script and compile errors which are displayed to the developer when the page fails to load in a Service Portal.   And this is what concerns me as I'm encountering a lot of issues in the CSS, where ServiceNow have overridden several default styles of bootstrap to fix their own portal issues, rather than add them to the portal theme's CSS style sheet. It needs to be entirely disconnected from bootstrap and other custom portals, otherwise what's the point of advertising bootstrap if it's nerfed.

A perfect example of this is the attachment icon and text in the catalog item.   Remove the text, leaving only the icon and the add attachment event doesn't even fire in iOS.   It's just poorly implemented, not only from the HTML level, it's also the CSS and how they target the event in Javascript without the foresight that maybe they're building a platform that others can use as it "says on the box".   Businesses don't want to be beta testers for products they pay huge licence fees for and it becomes hard as a consultant to tell a client that we have to rewrite or build work arounds due to limitations they thought worked "out of the box".   The GlideRecord issue in client scripts is another example.

[rbearry]

Related to this post, in Istanbul, anyone else notice that CSS files in the portal's theme are being cached and changes don't take until clearing with /cache.do?

Am I missing some documentation on this behavior somewhere?