Best practice for placing navbar menu blocks?

I am in the same boat. Currently migrating from bootstrap 3 to 5.

I notice in bootstrap 5.x we have css like so:

@media (min-width: 992px)
.navbar-expand-lg .navbar-toggler {
display: none;
}

This is not great css imo because .navbar-toggler is dependent on there being a parent being .navbar-expand-lg.

In Drupal I can see this class is added in bootstrap_barrio_preprocess_page in bootstrap_barrio.theme

e.g.

  // Define navigation toggle size.
  switch (theme_get_setting('bootstrap_barrio_navbar_toggle')) {
    case 'navbar-toggleable-xl':
      $variables['navbar_attributes']['class'][] = 'navbar-expand-xl';
      break;

    case 'navbar-toggleable-lg':
      $variables['navbar_attributes']['class'][] = 'navbar-expand-lg';
      break;

This is also where background classes and colours are defined e.g.

  // Define navigation color scheme.
  $variables['navbar_top_attributes']['class'][] = theme_get_setting('bootstrap_barrio_navbar_top_color');
  $variables['navbar_attributes']['class'][] = theme_get_setting('bootstrap_barrio_navbar_color');

  // Define navigation background classes.
  $variables['navbar_top_attributes']['class'][] = theme_get_setting('bootstrap_barrio_navbar_top_background');
  $variables['navbar_attributes']['class'][] = theme_get_setting('bootstrap_barrio_navbar_background');

Also part of the implementation here is dependent on navbar toggle being being available. Here I can see that in web/themes/contrib/bootstrap_barrio/templates/layout/page.html.twig we have:

         {% if page.primary_menu or page.header_form %}
                <button class="navbar-toggler collapsed" type="button" data-bs-toggle="{{ navbar_collapse_btn_data }}" data-bs-target="#CollapsingNavbar" aria-controls="CollapsingNavbar" aria-expanded="false" aria-label="Toggle navigation"><span class="navbar-toggler-icon"></span></button>
                <div class="{{ navbar_collapse_class }}" id="CollapsingNavbar">
                  {% if navbar_offcanvas %}
                    <div class="offcanvas-header">
                      <button type="button" class="btn-close text-reset" data-bs-dismiss="offcanvas" aria-label="Close"></button>
                    </div>
                    <div class="offcanvas-body">
                  {% endif %}
                  {{ page.primary_menu }}
                  {% if page.header_form %}
                    <div class="form-inline navbar-form justify-content-end">
                      {{ page.header_form }}
                    </div>
                  {% endif %}
                  {% if navbar_offcanvas %}
                    </div>
                  {% endif %}
                </div>
              {% endif %}

In other words, responsive navigation can only take place in these 2 regions!

Certainly with Bootstrap 3 it is possible to switch the navigation to work from any block or region. That is not currently the case here which is not great.

Ok just looking again at the barrio ui for this I can see under under navbar_structure we can set the background colours from various options including transparent.

Uploading screenshots showing variations in regions as defined by bootstrap, bootstrap implementation, barrio, and barrio_sass implementation

Ok what I am seeing is that in my_barrio_sass theme I am seeing flexbox is being applied, via navbar.scss.

In bootstrap barrio this does not seem to be the case.

Ok I have reworked this somewhat to:

load and compile scss from bootstrat_barrio.
before doing so make sure we have the following missing variables defined e.g.

//missing variables
$border-color: black;
$border-width: 0;
$spacer: 0;
$input-height: 1rem;
$orange: #ffac07;
$gray-200: #222222;
$gray-300: #333333;
$gray-700: #777777;
$black: #000;
$list-group-item-padding-y: 1rem;
$list-group-item-padding-x: .5rem;
$line-height-base: 1.5;
$line-height-sm: 1.5;
$line-height-lg: 1.5;
$headings-line-height: 1.5;
$border-radius-lg: 1rem;

make sure this and typography scss is included first.

This helps to ensure that the sun theme is consistent with the base theme. This is important because the css(scss) and html(twig tremplates) are designed to work together in a drupal specific manner.

Then I have the option to manually import additional components css etc such as grid and navbar from bootstrap. I will probably have to make some adjustments etc in order to get working with the child theme. These could be contributed to the boostrap_sass theme in a tried and tested manner

Now I am at least getting something that more closely resembles the base theme out of the box. Please see attached screen shot. There still some differences still to the footer that I probably need to still figure out.

Rather than re-defining all the here you can also do something like this:

/* IMPORTS */
// functions
@import "../node_modules/bootstrap/scss/functions";
// variables
@import "../node_modules/bootstrap/scss/variables";
// @import "variables-dark";
@import "../node_modules/bootstrap/scss/variables-dark";
//@import "maps";
@import "../node_modules/bootstrap/scss/maps";
// mixins
@import "../node_modules/bootstrap/scss/mixins";
//@import "utilities";
@import "../node_modules/bootstrap/scss/utilities";

// add bootstrap version etc

@import "../node_modules/bootstrap/scss/mixins/banner";
@include bsBanner("");

// Layout & components
// @import "root";
@import "../node_modules/bootstrap/scss/root";
@import "../node_modules/bootstrap/scss/reboot";
@import "../node_modules/bootstrap/scss/type";
@import "../node_modules/bootstrap/scss/images";
@import "../node_modules/bootstrap/scss/containers";
@import "../node_modules/bootstrap/scss/grid";
@import "../node_modules/bootstrap/scss/tables";
@import "../node_modules/bootstrap/scss/forms";
@import "../node_modules/bootstrap/scss/buttons";
@import "../node_modules/bootstrap/scss/transitions";
@import "../node_modules/bootstrap/scss/dropdown";
@import "../node_modules/bootstrap/scss/button-group";
@import "../node_modules/bootstrap/scss/nav";
@import "../node_modules/bootstrap/scss/navbar";
@import "../node_modules/bootstrap/scss/card";
@import "../node_modules/bootstrap/scss/accordion";
@import "../node_modules/bootstrap/scss/breadcrumb";
@import "../node_modules/bootstrap/scss/pagination";
@import "../node_modules/bootstrap/scss/badge";
@import "../node_modules/bootstrap/scss/alert";
@import "../node_modules/bootstrap/scss/progress";
@import "../node_modules/bootstrap/scss/list-group";
@import "../node_modules/bootstrap/scss/close";
@import "../node_modules/bootstrap/scss/toasts";
@import "../node_modules/bootstrap/scss/modal";
@import "../node_modules/bootstrap/scss/tooltip";
@import "../node_modules/bootstrap/scss/popover";
@import "../node_modules/bootstrap/scss/carousel";
@import "../node_modules/bootstrap/scss/spinners";
@import "../node_modules/bootstrap/scss/offcanvas";
@import "../node_modules/bootstrap/scss/placeholders";

// Helpers
@import "../node_modules/bootstrap/scss/helpers";

// Utilities
@import "../node_modules/bootstrap/scss/utilities/api";

From what I can see most of them do seem to be required, and the order is also important. My feeling is therefore that either the templates that come with bootstrap/barrio_sass starter theme need to be improved and/or the css needs to be overridden or rewritten to be a little more drupal friendly out of the box, because as is, it can be a struggle to get working for you as expected without having to deconstruct what is going on.

Just to follow up on my previous comments, If you find your self over-riding css that derives from barrio bootstrap, it is possible is to simply copy any scss components across to your subtheme and reference them there from say import.scss. Then you can simply uncomment the @import "barrio"; there. This means you are not compiling scss for components that you don't really want or need.

Alternatively you could also just reference all the bootstrap barrio components as per above e.g.

@import "../../../contrib/bootstrap_barrios/css/components/variables";
...

and again, just comment out the one you don't really need.

less is more.

Just wanted to update you on my approach. After first seeing how the Barrio theme behaves and comparing it to Bootstrap and Bootswatch themes, it seems to me the implementation is somewhat complicated by the fact that Drupal spits things out in different blocks and regions, where as the nav is really a single component.

From what I can see barrio supports adding two menu items together (main, user) and also provides a responsive nav that collapses etc with the option to collapse or us the off-canvas methods.

However this is still some way short of the bootstrap implementation that also includes the site name/logo as part of the nav. The nav collapses on small viewports but the logo/site name should still be viewable and be juxtaposed to the toggle-collapse button.

My approach to this was also add support for site_branding in a new region, which I called top_header_nav

Why trying not to break the existing setup I also decided to add a new variable group. e.g.

   switch (theme_get_setting('my_theme_navbar_top_nav_offcanvas')) {
    case 'offcanvas-collapse':
      $variables['navbar_top_nav_offcanvas'] = TRUE;
      $variables['navbar_top_nav_collapse_class'] = "offcanvas offcanvas-end";
      $variables['navbar_top_nav_collapse_btn_data'] = "offcanvas";

Also update the settings form to support this settings. e.g.

  // Navbar Top Nav behaviour.
  $form['components']['navbar_top_nav_behaviour'] = [
    '#type' => 'details',
    '#title' => t('Navbar Top Nav behaviour'),
    '#collapsible' => TRUE,
    '#collapsed' => TRUE,
  ];
  
  $form['components']['navbar_top_nav_behaviour']['my_theme_navbar_top_nav_offcanvas'] = [
    '#type' => 'select',
    '#title' => t('Default/Bootstrap Offcanvas Collapse'),
    '#default_value' => theme_get_setting('my_theme_navbar_top_nav_offcanvas'),
    '#options' => [
      'offcanvas-collapse' => t('Offcanvas'),
    ],
    '#empty_option' => t('Default'),
  ];

I decided to abstract this away from template and do most of the work in region, which also resulted in having to re-add variables using hook_region update and also hook_preprocess_region. This also required adding some templates having to be added or adjusted.

the end result is a something that I believe is much closer to the bootstrap examples given. Please see screen shots. It would be great if Barrio supported something similar as I am sure others would like more of a turn key solution, rather than having to enter a process of deconstruction that can be extremely time consuming.

Looking at this second time around, I think it depends a little on how you want your navigation to work, but if you want the default bootstrap type navigation, I think a sensible default is:

1. Add Site Branding to header region
2. Add Main navigation and user account menu to Primary navigation

One benefit of this approach is that all the menu items should be responsive.

That said, once you do that there are a few things you can do to get it to appear like bootstrap should.

I have attached two screen shots that show what it looks like and how it actually looks.

A couple of issues I see include:

1. user menu items contrast makes them invisible - this can easily be fixed by applying the correct class to the user menu e.g. navbar-nav. Not sure what benfit if any nav class has?
2. There are some incongruities between drupal and bootstrap namely
- Bootstrap theme does not include logo and strapline
- Bootstrap has support for a single nav with a nested ul.nav and form element, while drupal has 3 navs nested if wanting to add both user and main nav eg. one outer 2 inner

Couple of changes I would make

1. in templates/navigation/menu--account.html.twig

change

      <div{{ attributes.addClass('nav')|without('id') }}>

to

      <div{{ attributes.addClass('navbar-nav')|without('id') }}>

2. I would also remove these overrides from style.scss

.menu--main li a {
    color: $primary-shade;
}

.menu--account li a {
    color: $primary-shade;
}

Also an explanation somewhere on how to set up the main menu would be useful as the block names ar enot that intuitive.

Another difference I notice is boostrap uses the me-auto utility class, not justify-content-end.

One more thing i noticed is that in the menu we have items like with classes like

 nav-link--user

and

 nav-link--user-logout

and for home links

 nav-link--

My feeling is this could be bem syntax I don't think this is intentional and actually having

 nav-link-user

and

 nav-link-user-logout

and for home links

 nav-link-home

make more sense.

With that I mind I have made a couple of amendments:

e.g.

in templates/navigation/menu--account.html.twig and templates/navigation/menu--main.html.twigI have added:

        {% set active = item.url.toString() | clean_class %}
        {% if active == "-" %}
          {% set active = active ~ "home" %}
        {% endif %}

and changed:

            'nav-link-' ~ item.url.toString() | clean_class,

to be 'nav-link' ~ active,

Couple of other things I noticed.

1. Positioning of logo site name and slogan is using inline block! This is odd as the container uses flex box here.
2. Also site name has vertical align top setting

Not sure but I think could site name and slogan could be in the same column, which might make more use of the available space. Alternatively I guess it is fairly trivial to switch this off from the block ui and output separately if required.

This shows how this component could look to makes use of space to accommodate logo, site name and slogan, with out display: inline-block

mobile first

probably still makes sense to hide slogan for small viewports

Just to follow up on this colours are still wrong. See attached screenshots taken from bootstrap and bootswatch and see how the compare

@2dareis2do - I'd break down some of your suggestions that are more objective fixes vs personal preferences into their own issues and provide a merge request (or patch file).

On another note, it sounds like Barrio is still putting it's own variables in front of the bootstrap ones. That bugged me when I tried it years ago and I stopped using it. How hard is it to just bypass all those and use Bootstrap? Trying to deal with two layers (especially when referring to bootstrap docs) was frustrating - I guess it makes it easier to have support for different versions, but I have to keep both layers in my head and it just adds complexity.

I think it makes sense to break down into smaller changes. Anything that makes using barrio easier to set up and theme sounds good to me.

One thing I noticed is that Bootstrap typically variables use !default when assigning variables. My understanding is this means that barrio variables can still be loaded before bootstrap variables and still trump the default ones.

With regards to css variables, I would recommend creating own namespace by using $variable-prefix e.g.

// Prefix for :root CSS variables

<code>$variable-prefix:             bs- !default; // Deprecated in v5.2.0 for the shorter `$prefix`
$prefix:                      $variable-prefix !default;

some thing like

$variable-prefix:             bb- ; // Deprecated in v5.2.0 for the shorter `$prefix`

This can also be overridden to suit. I guess this is a little complicated as not everyone might compile their scss or use bootstrap_sass when using barrio.

My feeling is that each theme should have its own namespace and this seems to logically extend to the use of css variables. Certainly this is supported by bootstrap.

My feeling is that each theme should have its own namespace and this seems to logically extend to the use of css variables. Certainly this is supported by bootstrap.

I'd disagree on this, but it's a subjective thing.

Boostrap already has it's own variables, and those are essentially namespaced to whatever theme is using them (it's not like there's going to be two themes active at the same time causing conflicts). It seems far easier to just copy the entire bootstrap _variables.scss and edit it, or just cherry pick ones to a custom one that I want to edit and have the old one load in the backgound than to have another set of variables sitting on top of them. I can just add my own variables as needed in there. I've built multiple sites (Drupal and otherwise) using Zurb Foundation in this manner and it works perfectly fine.

If I'm using say, $brand-primary, that isn't going to show up in any of the bootsrap docs - so I need to remember how that and other barrio specific variables interact with the cascade. As someone who is just going to use one version of bootstrap at a time, I don't really want to have to bother with that. :)

I have been playing around with Radix, it's an interesting approach but not quite what I need (introducing more complexity than value, for me). I was considering Barrio, but I feel I'd have the same frustrations I did a few years ago. I'll probably just go with the vanilla bootstrap 5 on here and make a sass subtheme and just use prepros or codekit or something to make up for the lack of npm build chain. UI Suite looks really interesting, but is probably still a bit immature.

It seems far easier to just copy the entire bootstrap _variables.scss and edit it, or just cherry pick ones to a custom one that I want to edit and have the old one load in the backgound than to have another set of variables sitting on top of them.

I disagree. We are already including _variables.scss and _variables.scss from node_modules in import.scss

e.g.

// 3. Include remainder of required Bootstrap stylesheets (including any separate color mode stylesheets)
@import "../node_modules/bootstrap/scss/variables";
@import "../node_modules/bootstrap/scss/variables-dark";

and we have custom variables that are called earlier.

// 2. Include any default variable overrides here
// variables
@import "variables";

That seems like a good approach to me as Bootstrap will likely be updated over time so we avoid using a stale copy. If you don't want this to change you can choose to lock to a specific version of Bootstrap in your package.json. That also gives you the option to override the ones you want in your theme.

One thing we are missing though is our own _variables-dark

Also, there are some compile options that might also make sense to make configurable from the theme, (although perhaps not as we still have to compile the scss manually).

e.g.

// Options
//
// Quickly modify global styling by enabling or disabling optional features.

$enable-caret: true;
$enable-rounded: false;
$enable-shadows: true;
$enable-gradients: true;
$enable-transitions: true;
$enable-reduced-motion: true;
$enable-smooth-scroll: true;
$enable-grid-classes: true;
$enable-container-classes: true;
$enable-cssgrid: true;
$enable-button-pointers: true;
$enable-rfs: true;
$enable-validation-icons: true;
$enable-negative-margins: true;
$enable-deprecation-messages: true;
$enable-important-utilities: false;

$enable-dark-mode: true;
$color-mode-type: media-query; // `data` or `media-query`

When enabling some of these option, some may require additional config scss to be compiled iirc. Ideally I would like to support for all these options to be easily enabled or disabled to suit as they are supported by bootstrap. I think that would have more value than being able to simply override a handful of variables from the UI including brand primary and secondary colors. If we do need to override them, they should probably be bootstrap defaults to begin with.

Things like this are unnecessary in variables.scss:

$gray-100: #f8f9fa;

when we already have this in node_modules

e.g.

$gray-100: #f8f9fa !default;

I would prefer if the UI showed the available colours that were available.

With that in mind I have created the style_guide (admin) module which allows you to preview the front end theme form the backend. This allows you to preview all your components.

Your point regarding use of variables is a fair one. Just because we can doesn't necessary mean we should. That said I am doing this myself on my own site. Certainly we should definitely avoid using hard coded variable names e.g.. --bs-variable-name etc for those that want to use this feature. Certainly I have worked on sites that have been updated over time and it was useful to namespace the new theme to avoid conflicts with the existing theme which was also being loaded on the same page.

$brand-primary does look like a barrio variable. I am not sure why this has been created?

One other thing. To simplify the theme, why not just import bootstrap from node_modules

e.g.

// 1. import bootstrap
@import "../node_modules/bootstrap/scss/bootstrap";

I've never had issues upgrading between framework versions, either use an override variables file like the one included. (easy now that there's !default), or just... run a diff between the master variables.scss file between versions and copy over the changes if you want to have a single variables file where you can see all of them at once. I found that seeing everything I could change was useful when learning a new framework, though that's a bit more work on minor releases etc. No need to lock yourself on a version forever.

$brand-primary does look like a barrio variable. I am not sure why this has been created?

Having Barrio specific variables that sometimes take the place of bootstrap variables was annoying (and why I'm not using it now after taking another quick look at it). I'll make my own variables as well (and just keep them inline with whatever SCSS framework I'm using) but that's extending on top of it, not trying to insert myself into how it flows.

To simplify the theme, why not just import bootstrap from node_modules

I also skeptical about needing to load bootstrap from the parent theme. Radix just loads it from node_modules, which makes more sense to me. It could also be done as a Drupal library through composer which also feels appropriate. Having to manually update them in the parent theme feels a bit old-fashioned.

The Bootstrap 5 theme just loads ALL of Boostrap from the master theme (@import one file that gets all the rest), I've broken that down into individual bootstrap files loaded from the subtheme so I can comment out ones I'm not using etc.

I would also consider adding the option of copying barrio.scss and dependent components to subtheme.

I think it makes sense to have templates to override from a parent theme suited for bootstrap along with scss - anything that breaks you can figure out in testing but you're still getting value from the stuff you haven't overriden. One annoying thing about the non-semantic class names in bootstrap is if for example I want to change menu behaviour I need to fork a template vs just making a CSS change (.justify-content-md-between to .justify-content-md-end), enough of those and updating a theme does get more fragile.

FYI, I'm just using the Bootstrap5 parent theme. It's less clever and hence IMO easier to work with, especially as someone that's very comfortable in SCSS.

Just to follow up on this, while talking about the header, it might make sense to talk about the footer as well.

In style.scss we have:

.site-footer {
    background: $accent-shade !important;
}

Why?

Looking at bootswatch theme the footer has no colour. if we did want to add a colour, we can do similar the the header e.g. add bg-primary

@erugan,

I also skeptical about needing to load bootstrap from the parent theme

Bootstrap needs to be loaded from node_modules in order to compile. My point is that why not just load the whole lot with one file rather than requesting a gazillion files that also need to be loaded in a certain order. I think this can be easily simplified.

$brand-primary does look like a barrio variable. I am not sure why this has been created?

Sorry I think I meant boostrap variable here. It has been created for barrio implementation afaict. Bootstrap has bg-primary etc

Bootstrap needs to be loaded from node_modules in order to compile. My point is that why not just load the whole lot with one file rather than requesting a gazillion files that also need to be loaded in a certain order. I think this can be easily simplified.

It helps with cutting down rendered file size / performance. If you are only using half the modules, no need to render that CSS. Tools like noCSS (iirc) etc exist that will automatically strip out unused styles, but I don't feel as comfortable with them on a complex Drupal site than a simpler static site generator etc.

You could hide all of those particular scss imports behind a generic _load_bootstrap partial, but if you are editing scss variables you can't just toss them on top a single pre-rendered file.

Looking at bootswatch theme the footer has no colour. if we did want to add a colour, we can do similar to the header e.g. add bg-primary class

Or just use CSS with bootstrap color variables. I personally find it more annoying to jump around config and template files to change a color somewhere vs just having nicely laid out stylesheets, but both are valid approaches and there are certainly people (many or most even) that feel differently. :)

It helps with cutting down rendered file size / performance. If you are only using half the modules, no need to render that CSS. Tools like noCSS (iirc) etc exist that will automatically strip out unused styles, but I don't feel as comfortable with them on a complex Drupal site than a simpler static site generator etc.

Actually bootstrap does say it recommends the second approach, but either is valid.

https://getbootstrap.com/docs/5.0/customize/sass/

Or just use CSS with bootstrap color variables. I personally find it more annoying to jump around config and template files to change a color somewhere vs just having nicely laid out stylesheets, but both are valid approaches and there are certainly people (many or most even) that feel differently. :)

It's a neat trick but it is not something I use myself. It looks like that is why the additional variables have been created and from what I can see are attached to the html tag as additional attributes.

e.g. color

  // Color settings
  if (theme_get_setting('bootstrap_barrio_enable_color')) {
    $variables['#attached']['library'][] = 'bootstrap_barrio/colors';
    // CSS variables
    $gray200 = '#e9ecef';
    $gray800 = '#343a40';
    $white = '#fff';
    $pc = theme_get_setting('bootstrap_barrio_base_primary_color') ?? '#2F3C7E';
    $pcrgb = _hex2rgb( $pc );
    $pcd = _color_luminance($pc, -0.15);
    $bc = '#000';
    $pct = _getContrastColor($pc, $white, $bc);
    $sc = theme_get_setting('bootstrap_barrio_base_secondary_color') ?? '#FBEAEB';
    $scrgb = _hex2rgb( $sc );
    $scd = _color_luminance($sc, -0.15);
    $sct = _getContrastColor($sc, $white, $gray800);
    $colors = [
      'white' => $white,
      'black' => '#000',
      'gray-200' => $gray200,
      'gray-800' => $gray800,
      'primary' => $pc,
      'secondary' => $sc,
    ];
    $color = _get_color(theme_get_setting('bootstrap_barrio_body_color') ?? 'gray-800', $colors);
    $colors['base'] = $color;
    $bg = _get_color(theme_get_setting('bootstrap_barrio_body_bg_color') ?? 'white', $colors);
    $h1 = _get_color(theme_get_setting('bootstrap_barrio_h1_color') ?? 'base', $colors);
    $h2 = _get_color(theme_get_setting('bootstrap_barrio_h2_color') ?? 'base', $colors);
    $h3 = _get_color(theme_get_setting('bootstrap_barrio_h3_color') ?? 'base', $colors);
    $styles = [
      "--bs-primary:$pc;",
      "--bb-primary-dark:$pcd;",
      "--bb-primary-light:$pct;",
      "--bs-primary-rgb:$pcrgb;",
      "--bs-secondary:$sc;",
      "--bb-secondary-dark:$scd;",
      "--bs-secondary-rgb:$scrgb;",
      "--bs-link-color:$pc;",
      "--bs-link-hover-color:$pcd;",
      "--bs-body-color:$color;",
      "--bs-body-bg:$bg;",
      "--bb-h1-color:$h1;",
      "--bb-h2-color:$h2;",
      "--bb-h3-color:$h3;",
    ];
    $variables['html_attributes']->setAttribute('style', implode('', $styles));
  }

Then in html.html.twig we have

<html{{ html_attributes }}>
  <head>
    <head-placeholder token="{{ placeholder_token }}">
    <title>{{ head_title|safe_join(' | ') }}</title>
    <css-placeholder token="{{ placeholder_token }}">
    <js-placeholder token="{{ placeholder_token }}">
  </head>
  <body{{ attributes }}>...

Ok so it looks like the main purpose of this is to apply custom colours from the ui. However, in order to use any of the Bootswatch themes, a much undersold feature here, in order to work properly, surely we need to remove these custom variables.

At seems to me that there is a heavy cost for this design decision, (which I and you do not use).

I have attached screenshot without overrides ($pc $sc) etc that uses solar theme

This is how I have reworked the header and in particular the site_branding including logo, site name and site slogan.

{% set attributes = attributes.addClass('site-branding') %}
  {% if site_logo or site_name %}
    <a href="{{ path('<front>') }}" title="{{ 'Home'|t }}" rel="home" class="navbar-brand">
      {% if site_logo %}
        <img src="{{ site_logo }}" alt="{{ 'Home'|t }}" class="img-fluid" />
      {% endif %}
    </a>
    <div>
      {% if site_name %}
        <a href="{{ path('<front>') }}" title="{{ site_slogan }}" rel="home" class="navbar-brand">
            {{ site_name }}
        </a>
      {% endif %}
      {% if site_slogan %}
        <span class="site-name-slogan navbar-brand d-none d-xxl-block">
          {{ site_slogan }}
        </span>
      {% endif %}
      </div>
  {% endif %}

The benefit of this is it means that site_branding items can still be spaced out using flexbox (at least on wider viewports). Also each item can be hidden or shown using blocks ui.

One thing do like about this theme is how the drupal logo (svg) is using shadow to render on different colour backgrounds.

Screenshot using Pulse theme.

If just loading @import "../node_modules/bootstrap/scss/bootstrap";

it is important that @import "variables"; is loaded beforehand. Otherwise it is compiled with the default values.

e.g.

$enable-dark-mode: true;
$color-mode-type: media-query;