Height and Width Specifiers 1-100

Currently bootstrap only supports .h- and .w- with the values of 25, 50, 75, 100, auto.

I’m proposing we allow all .h- and .w- values from 1-100 (and auto) to allow greater control over how tall / wide something is.

The current implimentation of this is:

// _variables.scss

// This variable affects the `.h-*` and `.w-*` classes.
$sizes: () !default;
// stylelint-disable-next-line scss/dollar-variable-default
$sizes: map-merge(
  (
    25: 25%,
    50: 50%,
    75: 75%,
    100: 100%,
    auto: auto
  ),
  $sizes
);

// _sizing.scss

// Width and height

@each $prop, $abbrev in (width: w, height: h) {
  @each $size, $length in $sizes {
    .#{$abbrev}-#{$size} { #{$prop}: $length !important; }
  }
}

.mw-100 { max-width: 100% !important; }
.mh-100 { max-height: 100% !important; }

// Viewport additional helpers

.min-vw-100 { min-width: 100vw !important; }
.min-vh-100 { min-height: 100vh !important; }

.vw-100 { width: 100vw !important; }
.vh-100 { height: 100vh !important; }

I believe this can be improved upon by just having one function as such

// height and width
@each $abbrev, $prop in (h: height, w: width) {
  $size: 1;
  $increment: 1;
  // loop until 100
  @while $size < 101 {
    .#{$abbrev}-#{$size} { #{$prop}: #{$size}% !important; }

    $size: $size + $increment;
  }

  // auto
  .#{$abbrev}-auto { #{prop}: auto !important; }

  // max 100
  .m#{$abbrev}-100 { max-#{$prop}: 100% !important; }

  // view 100
  .v#{$abbrev}-100 { #{$prop}: 100v#{$abbrev} !important; }

  // view min 100
  .min-v#{$abbrev}-100 { min-#{$prop}: 100v#{$abbrev} !important; }
}

This does generate many more css properties, going from 16~ to 208~. If this is not wanted, the loop can have smaller increments like 5 or 10 by changing the $size and $increment variables

[mktcode]

Gotya! Thanks.

😉

[ffoodd]

Not that much, and even if it is, that’d be another reason to not land new utilities for millions of websites when a single person asked for it.

Our main way to decide if we add things or not is how much a feature is requested (RTL support e.g. was asked several dozen times) and on top of that, how easy it is for anyone to implement it by themselves.

Regarding utilities, since it’s very easy in v5 to add one through our utility API, we’ll more likely encourage people to add them in their build rather than adding it to our core and delivering it to projects which don’t need it.