Bootstrap 5 - Show/hide images on specific breakpoints

I'm working on upgrading an existing application from Bootstrap 4 to Bootstrap 5. I used the occasion to clean up the CSS logic. One thing I had in the original application was an image in the header that should be cropped on smaller screens.

This how the header looks like on bigger screens:

And this is on smaller screens:

The trick I used originally was by using a media queries:

However with the upgrade to Bootstrap 5 I would try to achieve the same thing using the built-in grid system and breakpoints.

Breakpoints

Breakpoints are the building blocks of responsive design in Bootstrap. You can use them to control when your layout can be adapted at a particular viewport or device size.

Bootstrap includes six default breakpoints, sometimes referred to as grid tiers, for building responsively. These breakpoints can be customized if you’re using our source Sass files.

Breakpoint	Class infix	Dimensions
X-Small	None	<576px
Small	`sm`	≥576px
Medium	`md`	≥768px
Large	`lg`	≥992px
Extra large	`xl`	≥1200px
Extra extra large	`xxl`	≥1400px

Show/hide images

To show/hide images on certain breakpoints we need to set a combination of the following classes on your image tags:

SCREEN SIZE            CLASSES
---------------------------------------------------
hidden on all          d-none
hidden only on xs      d-none d-sm-block
hidden only on sm      d-sm-none d-md-block
hidden only on md      d-md-none d-lg-block
hidden only on lg      d-lg-none d-xl-block
hidden only on xl      d-xl-none d-xxl-block
hidden only on xxl     d-xxl-none
hidden below sm        d-none d-sm-block
hidden below md        d-none d-md-block
hidden below lg        d-none d-lg-block
hidden below xl        d-none d-xl-block
hidden below xxl       d-none d-xxl-block
---------------------------------------------------
visible on all         d-block
visible only on xs     d-block d-sm-none
visible only on sm     d-none d-sm-block d-md-none
visible only on md     d-none d-md-block d-lg-none
visible only on lg     d-none d-lg-block d-xl-none
visible only on xl     d-none d-xl-block d-xxl-none
visible only on xxl    d-none d-xxl-block
visible below sm       d-sm-none
visible below md       d-md-none
visible below lg       d-lg-none
visible below xl       d-xl-none
visible below xxl      d-xxl-none

In our specific example, we want to show one image only on xl or higher dimensions and show the other image only when the dimension is smaller then xl. Here is how I did this in html:

Podman– Command execution failed with exit code 125

After updating WSL on one of the developer machines, Podman failed to work. When we took a look through Podman Desktop, we noticed that Podman had stopped running and returned the following error message: Error: Command execution failed with exit code 125 Here are the steps we tried to fix the issue: We started by running podman info to get some extra details on what could be wrong: >podman info OS: windows/amd64 provider: wsl version: 5.3.1 Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM Error: unable to connect to Podman socket: failed to connect: dial tcp 127.0.0.1:2655: connectex: No connection could be made because the target machine actively refused it. That makes sense as the podman VM was not running. Let’s check the VM: >podman machine list NAME ...

Cache stampede: when our cache turned against us

While investigating some performance issues, we ran into an ASP.NET Core API that cached a fairly expensive aggregation query for 60 seconds. Under normal load, that was fine: one request rebuilds the cache, everyone else reads from it. Under peak load, dozens of requests would arrive in that same expiry window, all see a cache miss, and all fire the same expensive query in parallel. The database didn't like that. That was the moment when our caching layer stopped helping and started hurting. A burst of requests comes in at the same time, all miss the cache, and all go hammer the database or the downstream API at once. That's a cache stampede . The cache was supposed to protect our backend, and for a few hundred milliseconds it did the opposite. Why this happens IMemoryCache.GetOrCreate (and its async sibling) looks like it protects you, but it doesn't add any locking on its own. Look at the naive version: public async Task<Report> GetReportAsync(string key) ...

A complex system designed from scratch never works

A few years ago, I worked as an architect on a big mainframe rewrite. I still count it as one of my failures. Not because the technology was wrong, but because I couldn't convince the management team to simplify the approach. Years later, the organization is still struggling to get the new system up and running. I left the project at the time, because I couldn't put my name behind an approach that would take very long and cost a lot of money without a working system to show for it along the way. Gall’s Law That memory keeps coming back to me, because it's a textbook case of Gall's Law playing out in real life. Gall's Law , from John Gall's Systemantics , states it plainly: A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works, and it cannot be patched to make it work. You have to start over with a simple system that works. What does that mean in practice,...

The art of simplicity

Search This Blog