Support for using Bootstrap grid as Sass mixin includes going forward?

[ekirsimae]

I've been using Bootstrap grid in Sass by @including Sass internal mixins such as make-container() make-row() make-col-ready() etc etc. As far as I know this common practice, but it seems this is not a use case that is officially supported by Bootstrap developers judging by issue 4.5.1 Breaking change, removed Mixing make-container-max-widths #31436 and the subsequent discussion at pull request Restore and deprecate make-container-max-widths mixin #31438 :

We removed this to de-dupe our grid containers in our compiled CSS (see #30969) and I wasn't thinking when reviewing that it'd be a breaking change. We're sticking with not using the mixin, but adding the mixin back for others to use.

My current feeling based on this comment is that the other grid mixins will soon follow the same fate and that our current ability to include the mixins in our classes was more coincidental or happy accident rather than design decision. I had a quick look at the way container class generation was now done and it definitely didn't seem to support this use case.

If anybody who knows more about this situation can comment I would appreciate it. Right now I'm happily on v4.5.2 but the deprecation notice is sending a clear message.

[mdo]

make-container-max-widths() was deprecated because it created duplicate classes. There’s no plan to remove any other mixins.

[ekirsimae]

Hmm,

I may be misunderstanding something crucial here. I'm looking at 4.5.2 and my understanding is that this is where the .container max-widths for each breakpoint get generated:

@each $breakpoint, $container-max-width in $container-max-widths {
    .container-#{$breakpoint} {
      @extend .container-fluid;
    }

    @include media-breakpoint-up($breakpoint, $grid-breakpoints) {
        
      %responsive-container-#{$breakpoint} {
        max-width: $container-max-width;
      }

      // Extend each breakpoint which is smaller or equal to the current breakpoint
      $extend-breakpoint: true;

      @each $name, $width in $grid-breakpoints {
        @if ($extend-breakpoint) {
          .container#{breakpoint-infix($name, $grid-breakpoints)} {
            @extend %responsive-container-#{$breakpoint};
          }

          // Once the current breakpoint is reached, stop extending
          @if ($breakpoint == $name) {
            $extend-breakpoint: false;
          }
        }
      }
    }
  }

Specifically as far as I can make out, it works because:

// Returns a blank string if smallest breakpoint, otherwise returns the name with a dash in front.
// Useful for making responsive utilities.
//
//    >> breakpoint-infix(xs, (xs: 0, sm: 576px, md: 768px, lg: 992px, xl: 1200px))
//    ""  (Returns a blank string)
//    >> breakpoint-infix(sm, (xs: 0, sm: 576px, md: 768px, lg: 992px, xl: 1200px))
//    "-sm"
@function breakpoint-infix($name, $breakpoints: $grid-breakpoints) {
  @return if(breakpoint-min($name, $breakpoints) == null, "", "-#{$name}");
}

So we end up with @media definitions in the compiled file like this, where instead of .container-xs we get the plain .container class:

@media (min-width: 992px) {
  .container-lg, .container-md, .container-sm, .container {
    max-width: 960px;
  }

If this correct then before/now I could do:

.my-custom-container {
    @include make-container();
    @include make-container-max-widths();
}

But I don't see a way to do include the new definition in my own classes, at least in my limited understanding of Sass. Again, I might be completely misunderstanding what is happening here and any insight is appreciated.

[mdo]

where instead of .container-xs we get the plain .container class:

You'll never get a xs infix—.container is the same as what you imagine .container-xs to be.

[mdo]

Btw fixed your code blocks in your comment. Use triple backticks on new lines before and after code snippets, not a single backtick in the opening and closing lines.

[ekirsimae]

Bumping... Anybody have any thoughts on this?

Having had some time to think about this myself: it has probably always been a bad idea™ to try to include bootstrap internal mixins in our css. Mixins have never been available for all of bootstrap so I suppose it is fair to say this mode/usecase has never really been supported nor encouraged.

[mdo]

Totally fine to use them! We only changed one mixin's behavior because our compiled CSS was outputting the same grouped selector twice.

[ekirsimae]

@mdo I swear I'm not being purposefully obtuse or argumentative, but I don't feel we're on the same page here about what we are discussing. I might not be communicating it well. Thanks for fixing my post formatting anyway.

where instead of .container-xs we get the plain .container class:

You'll never get a xs infix—.container is the same as what you imagine .container-xs to be.

Right, I'm not saying there should container-xs, which indeed by definition would act the same as .container (100% width up to the specified breakpoint size). I was specifically commenting that the nested loops width @function breakpoint-infix not returning the smallest infix is what generates the plain .container classes (as as in this example for breakpoint lg taken from style.css):

@media (min-width: 992px) {
  .container-lg, .container-md, .container-sm, .container {
    max-width: 960px;
  }

And if this is the case, then I don't see a way to extract the container functionality from that tightly coupled piece of code. I'm left using the deprecated make-container-max-widths() mixin that is no longer used by the bootstrap project itself. In fact it was once removed before it was discovered to some surprise that some projects have in fact used it as an @include in their own scss.

So therefore, I would suggest that it is absolutely reasonable to assume, that this kind of usage of bootstrap

.my-custom-container {
    @include make-container();
    @include make-container-max-widths();
}

is not really supported by the project and never has been. I.e. it has never been the goal of bootstrap to make all or the core of its functionality available as mixins/functions/variables so that they may be easily included in custom class definitions.

Which is fine ultimately, I would just prefer some clarity on this.

[mdo]

I mean I see what you're looking to do, but yes, the make-container-max-widths() mixin generates a list of containers across breakpoints and doesn't extend a single custom container. So instead of .my-custom-container-sm/md/lg/xl/xxl, you'd get .my-custom-container .container-sm/md/lg/xl/xxl right now.

I think we'd have to add another mixin to do what you want, which I'm not opposed to. Would you want to take a crack at that for v4 and v5?

[ekirsimae]

Hey,

Just to clarify: the make-container-max-width() mixin pretty much functions perfectly as it is (for my use case anyway). A more practical example in the BEM style use case:

.header {
  width: 100%;
  background-color: blue;
}

.header__content {
   @include make-container();
   @include make-container-max-widths();
}

And presto, I have a full width blue background for my header, but my content is neatly enclosed in responsive containers and doesn't stretch over the full screen width on larger desktop screens.

The problem then was that the mixin is officially deprecated and according to the deprecation message goes away in v5. This got me wondering if this a use case that is being considered/supported.

[pjoulot]

I am using the mixin the same way as you ekirsimae. I would definitely love having a replacement in v5.

[ekirsimae]

I am using the mixin the same way as you ekirsimae. I would definitely love having a replacement in v5.

Glad to see there are others out there. I'm not personally too invested into this to be honest, but if this is a common enough use case it would be something to consider.