Backdrop-blur Utility

[crftwrk]

Glass effects using backdrop-filter are widely used in modern UI design. Happy to see this already in the v6 dialog/offcanvas backdrop. While Bootstrap provides the Utilities API to generate custom utilities, it may now be time to include a backdrop-blur utility by default.

I'm currently using this (v5), which results in a small CSS output:

Demo: https://codepen.io/craftwerkberlin/pen/bNwqLMN

// Add a custom backdrop-blur utility
$utilities: map-merge(
  $utilities,
  (
    "blur": (
      property: (
        backdrop-filter,
        -webkit-backdrop-filter
      ),
      class: bd-blur,
      values: (
        1: blur(5px) saturate(180%),
        2: blur(10px) saturate(180%),
        3: blur(15px) saturate(180%),
        4: blur(20px) saturate(180%),
        5: blur(25px) saturate(180%),
      )
    )
  )
);

This creates a new utility bd-blur-{1-5} that can be used in combination with other (v6) bg utilities (color, opacity), for example bg-white fg-white bg-10 bd-blur-5. It can be used in sticky navbars, card overlays, or anywhere one layer overlaps another.

If this is of interest, I’d be happy to fine-tune it and work on a PR. Let me know what you think.

[pricop]

Your utility doesn't just blur, it also applies a strong saturate() filter, which feels very opinionated (it increases the colors underneath quite a lot, and could hurt accessibility), so that particular bit would have to disappear if this is to be introduced, as some of us have generated additional filter utilities, for example bd-filter-saturate, bd-filter-invert, bd-filter-grayscale, etc.

I'd love to see backdrop blur being added out of the box, but the main problem that I currently see is that the CSS size of Bootstrap v6 currently sits at 275kb~, it has almost doubled from 144kb~ in v4 (90%~ increase), which is pretty significant, and increased by about 45kb from v5 (20%~ increase).

Loading times might actually become a problem if Bootstrap's CSS continues to grow in size, as most of the people will just hotload Boostrap from a CDN URL.

Perhaps there's a good way to shave off some CSS from other parts to make room for new utilities.

Or maybe this is the perfect case of just using the API...

I'm personally using the following backdrop filter map (which maps to Tailwind's defaults), and as a suggestion/feedback I'd like to suggest using multiples of 4px (or just .25rem) instead of 5px.

Something like 4px, 8px, 12px, 16px, 24px, 48px (large blur option is desired, especially for large overlays on big screens).

"bd-filter-blur": (
    property: backdrop-filter,
    class: bd-filter-blur,
    values: (
        null: blur(8px),
        none: blur(0),
        sm: blur(4px),
        md: blur(12px),
        lg: blur(16px),
        xl: blur(24px),
        2xl: blur(40px),
        3xl: blur(64px),
    )
),

[crftwrk]

Your utility doesn't just blur, it also applies a strong saturate() filter, which feels very opinionated (it increases the colors underneath quite a lot, and could hurt accessibility)

Yes, as I mentioned, this is just a rough example to have something to discuss. This needs to be fine-tuned, your example looks better than mine!

CSS size of Bootstrap v6 currently sits at 275kb~, it has almost doubled from 144kb~

Yes, that's high. Just thinking out loud, components like Card and Alert can be completely built using existing utility classes.

[pricop]

I thought of this myself many times...

While it's true that some components could be rebuilt using CSS classes, in Bootstrap's case that would be a bad idea.

Bootstrap is a design system. Components such as alert and card are a core part of Bootstrap and they are what it makes it so strong.

The moment we turn <div class="alert theme-secondary"></div> into <div class="class="p-3 bg-subtle-secondary text-secondary border border-secondary rounded"> we lose the ability to easily customize the components if we change our mind later about our design system later on.

Currently if I want to change my UI's spacing to be a bit more loose, all I have to do is to modify a few CSS/SCSS vars, and I'm done, that doesn't work with utility classes.

Not only that, but now you'd have to remember what spacing each component is supposed to be, so we'd also lose the ability to easily be consistent.

This would be a nightmare when working across multiple projects because now you can't use the component class anymore, but you'd have to either remember the exact CSS properties for the said component instead.

And lastly, but not least, semantics... Bootstrap thrives in this area, is very easy to understand by someone that's not familiar with CSS. So someone that's just getting started is going to have a hard time understanding what those classes even are.

I wish to see more utility classes added (especially backdrop-filter blur, because I'm making use of this myself too, haha), but I could understand why it might not happening.

There are areas where we could remove/reduce some of the code (e.g: for components display: grid; we can combine properties such as align-items: center and justify-content: center with just: place-items: center;, same thing with paddings, borders, margins, etc.).

I'm curious what's the official take on the CSS size getting bigger.

[crftwrk]

I totally agree with your reasoning on why prebuilt components are more useful here.

I'm curious what's the official take on the CSS size getting bigger.

It can only get smaller when removing code which means less functionality. I remember @mdo mentioning concerns about file size when it reached around 200 KB in v5.3 with dark mode.

On the other hand, 275kb CSS size is smaller than a 1920x1280 png from Unsplash, compressed by TinyPNG. Webservers and browsers are incredible fast and functionality needs code/size.

I see blowing up code everywhere. Most time I work with WordPress and there are (popular) plugins that care about nothing and ships 800kb+ CSS files. Once loaded, these assets are cached anyway.

Given that, I don’t think an increase from ~144 KB in v4 to ~275 KB in v6 is a major issue in 2026 anymore.

Checked the code from your example, this results in tiny 444 bytes minified CSS on top. Does this additional size really matter?

[pricop]

444 bytes is not that much. I'd personally love to see bd-filter-blur being added.

Wordpress plugins are notoriously known for being very poorly optimized. Just because others are practicing, doesn't mean we should too.

There's a very big distinction to be made here between a 300kb image, and a 300kb CSS size.

Because the browser requires the CSS code to paint the page, a large CSS size can cause layout shifts, FOUC (flash of unstyle content), and even impact Core Vitals, which could potentially hurt SEO performance, while images can just be lazy loaded after the content has been painted.

[mdo]

Regarding file size, one of the more difficult things here is CSS variables. It'll be interesting to review all those and how we generate them moving forward. One little thing I'm doing that we could do more of is the null values in our defaults()—those get removed automatically by Sass at compile time. There are plenty of default values we could loop over to and fallback to global tokens.

We also need some first class Purge CSS or something. Maybe even a leaner default build could be considered. Few options ahead of us.