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) ...

VS Code Planning mode

After the introduction of Plan mode in Visual Studio , it now also found its way into VS Code. Planning mode, or as I like to call it 'Hannibal mode', extends GitHub Copilot's Agent Mode capabilities to handle larger, multi-step coding tasks with a structured approach. Instead of jumping straight into code generation, Planning mode creates a detailed execution plan. If you want more details, have a look at my previous post . Putting plan mode into action VS Code takes a different approach compared to Visual Studio when using plan mode. Instead of a configuration setting that you can activate but have limited control over, planning is available as a separate chat mode/agent: I like this approach better than how Visual Studio does it as you have explicit control when plan mode is activated. Instead of immediately diving into execution, the plan agent creates a plan and asks some follow up questions: You can further edit the plan by clicking on ‘Open in Editor’: ...

The art of simplicity

Search This Blog