DEV Community: Hubert SABLONNIÈRE

Down the Rabbit Hole with Claude Code: My Journey to Window Key Switcher

Hubert SABLONNIÈRE — Fri, 08 Aug 2025 14:12:48 +0000

Let me tell you the story of when I finally tried out Claude Code and ended up in a multi-level rabbit hole that led me to create Window Key Switcher, a GNOME Shell extension for keyboard-driven window management.

👋 Hello Claude Code

I've been very skeptical about LLMs and coding agents since they appeared a few years ago. The AI hype cycle, with all its bold claims about replacing developers entirely, and promises of instant app creation, made my eyes roll several times, especially regarding frontend code and accessibility. I hesitated for a long time before diving into these tools, but like any good engineer, I cannot have a strong opinion without basing it on experience. I needed to learn and understand what they could and could not do, which is actually very hard as everything evolves all the time. Sometimes I was disappointed, sometimes I was impressed, but none of the tools I tried really clicked with me to the point of completely reconsidering my workflow.

None of them until I tried Claude Code.

I think it comes down to the fact that Claude Code is a terminal based interface. With VS Code forks like Cursor or Windsurf, I need to open a project and then, my brain automatically goes "I'm in an IDE, I'm supposed to ask the agent to write code". With Claude Code (and competitors like Gemini CLI, Open Code, or Codex), my brain goes "I'm in a terminal, I can do anything I want on my computer". In his Claude Code is My Computer article, Peter Steinberger described something really close to the mind shift I went through recently. Bonus point, Claude Code can connect with WebStorm so I can keep using the IDE I love and know how to use very well.

💰 Level -1: Buying new monitors

Most of the time, when I work at home or at my co-working space, I use two monitors. I have my IDE on my laptop and my browser on a desktop monitor above it. Anytime I need my terminal, I use a single hotkey to show/hide it on the monitor that has the mouse. I've been working like this for years!

Using Claude Code more and more, I started multi-tasking with several terminal tabs opened in parallel. It was so annoying to switch between them, it resurrected an old wish I had: upgrading my monitor setup to 4 monitors. I had this simple (and maybe dumb) thought process: if I had more screen real-estate, I could see different terminal windows at the same time and watch how each Claude Code session is doing while still being able to use my browser, IDE...

That's how I convinced myself to buy two reconditioned portable 15-inch USB-C monitors. They're light, I can bring them on the go. I experimented with using them vertically, something I hadn't really tried before. But now that I had all these terminal windows, I felt the urge to be able to split my terminal windows vertically and/or horizontally.

🔍 Level -2: The terminal emulator quest

First, I tried tmux, again. It wasn't my first attempt with it, but like the last time, I didn't click with the shortcuts. They're too weird and complex for me. Also, I don't need the session system, and the mouse support doesn't really work natively.

So I went looking for a new terminal emulator. I'd been using xfce-terminal since my XFCE days and was still using it after switching back to GNOME. That's when I stumbled upon Ghostty. It provides native window multiplexing with keyboard shortcuts to "split left" or "split down", and it's great.

I've been using it for a few days now and I won't go back to xfce-terminal.

By the way, Ghostty's configuration is done with a config file, no GUI, no wizard. No problem, I told Claude Code:

look for my xfce-terminal custom color palette on my system (no idea where it's stored)
run ghostty +show-config --default --docs to get the list of options and docs about them
use the output to ask me questions as some kind of configuration wizard
create the config file for me

The only problem I have for now with Ghostty is the lack of Linux (with X11) support for a "dropdown mode" (they call it "quick-terminal"). As I described before, I'm addicted to having a single hotkey to show/hide my terminal on the top half of my screen (or fullscreen sometimes).

🔨 Level -2.5: The bash script

I spent an evening trying to hack together a bash script that would mimic a dropdown behavior using xdotool. Again, I asked Claude Code. It worked... more or less. But the window placement was goofy. It comes down to the limits of what xdotool can do vs. a more precise approach. I went to bed with a working but not that satisfying solution.

🚀 Level -3: The GNOME Shell extension

The next morning, I wanted more, I wanted a better and more powerful version of this bash script. That's when I decided to create a GNOME Shell extension. I also acknowledged I was now an official resident of this rabbit hole, but it was fun so I stayed.

I had already built one extension to control my desktop windows with HTTP with my custom slide tool for my HTTP cache talk. But I actually had very little knowledge and experience with GNOME Shell extensions. Back then, I mostly mimicked and adapted an existing extension I saw on GitHub and I remembered going through the API docs was a mess.

I started describing my idea to Claude Code:

Ten hotkeys: Super + number-key
Assign any app to a number
Press the hotkey:
- If the app is not launched, launch it
- If the app is launched, focus the window
- If the app has multiple opened windows, focus the next one like Alt+Tab would do (this was not that simple)
Bonus: highlight the window that was just focused

💩 The first "vibe coded" attempt

I used "plan mode" to create a detailed set of steps with user experience details and code structure instructions. I did a few iterations to refine the plan and once I was satisfied, I told it to go forward. Claude Code took around 9 minutes to build the extension. I was already thinking "great, I'll install it and move on to a real project".

I installed it and it failed. The basics were there, but several details were broken. Also, I forgot to tell it to use Context7, so it targeted an old version of GNOME Shell and it didn't use the latest ESM syntax.

👥 The pair programming sessions

Going deeper into my rabbit hole, I decided to code the extension myself (with Claude Code's assistance, of course), but using the opportunity to learn about the GNOME Shell extension ecosystem I knew very little about.

I already had a similar failed "generate everything in one go" experience on another project. My lack of knowledge and experience on the stack prevented me from being able to fix it myself.

I deleted everything and asked Claude to start a pair programming session with me. The idea was to progress step by step, learning new APIs and techniques along the way, and making sure everything worked before going to the next step.

We started by creating a simple GNOME Shell extension that logs "Hello, world!" when it's enabled and this time, we used Context7!

For reference, here's the GNOME Shell Extensions documentation we used throughout the development process.

Then we focused on the basic moves we needed for the choreography:

Listening to a keyboard shortcut
Reading keyboard shortcuts configurations
Listing opened windows
Focusing a window
Launching a program
Highlighting a window

For some of these, Claude Code proposed multiple alternative options I had to chose from. It found like 5 ways to launch an application. In the end, I never browsed the API docs once and most of the code it produced worked as is.

Once I had working code for these basic moves, I could have gave another chance to the "generate everything in one go" method. Instead, I chose to continue iterating and learning... This allowed me to try different ways to architect the code. I wanted something really clean and organized and mostly used to browser and Node.js projects. I also took some time to automate some tooling for the project.

🎉 A satisfying outcome

In the end, I have a working GNOME Shell extension that does exactly what I wanted. The first time I had the right behavior, I smiled like a child with an ice cream.

Now, I can focus my terminal with one hotkey. I don't really need the dropdown behavior anymore. I don't need to hide it, I just need to focus another application like my browser or my IDE with a single hotkey. I'm still in the "muscle memory shift" phase, I actually did a few Alt+Tabs between my markdown editor and the browser while writing this article.

I pushed the code on GitHub but as I'm writing this, I haven't published it on the GNOME Extensions site yet. I want to take some time to use it for a while first. If you're curious, you can install it locally and test it, please give feedback.

⏭️ The future of this project

I guess, I'll see how I use it in different situations:

on-the-go with laptop only
classic setup with laptop + monitor
new mega setup with laptop + monitor + 2 portable vertical monitors

I also have a few ideas for improvements and next steps:

Try to automate test and run them with GJS and/or Node.js with mocks.
Experiment with having the same app on multiple shortcuts. So if I have 2 terminal windows, I could focus the one I want with just one shortcut. I'm not sure I really need that, and I don't know how I would implement it.
Refine the README and the CONTRIBUTING guidelines.
This project gave me a lot of ideas for other extensions, and even to restart my Window manager HTTP extension and publish it!

🤯 Learning new things

As I already mentioned, I learned a lot on this project:

I have a better understanding of what GNOME Shell extensions can and cannot do with their APIs (keybindings, windows management...).
The GJS JavaScript runtime now supports ESM.
- No more legacy const MyModule = Me.imports.myModule!
Some people created type definitions for GJS and GNOME Shell extensions.
You can't import from node_modules directly, but you can bundle your code before installing your extension.
- I used Zod and bundled with esbuild, and it works great!

In the end, I mostly architected the project myself. Most of the code was generated and then I reworked it to my tastes. Claude Code was a really good pair programming buddy and a GNOME Shell extension know-it-all (once I told it to use Context7 and to look up a few extension repos on GitHub).

I used this project as an opportunity to improve my understanding of LLMs and coding agents I tried to find a good balance between full blind vibe-coding and typing each character in the .js files. I really think my workflow was improved through this process.

⚠️ Struggling with challenges

This should have been a simple project but I stumbled upon a few difficulties along the way:

The iteration cycle is a bit annoying. Each time I want to test the code, I need to build the extension and reload GNOME Shell. I'm used to live-reload in the browser or automatic restarts with Node.js. Even with the scripts I created, it's still a pain.
Listening to keyboard shortcuts is kinda limited but I guess it's for security reasons.
I mentioned there are type definitions for extensions but most people use them in .ts files. I prefer writing .js files with JSDoc and use TypeScript CLI tsc to typecheck. This was a bit harder to understand how to configure.
It took me some time to figure out what I wanted for the window focus cycle behavior.
I almost rage-quitted once I realized someone already made a very similar extension.
- I don't know how I missed it in my early research.
- I'm glad I built my own solution, it's closer to what I need and I learned a lot.

🏁 Conclusion

What started as simply using Claude Code more intensively led to buying monitors, switching to a new terminal emulator, and ultimately building a GNOME Shell extension. It even pushed me to write this article, which is so rare, this blog/site almost became a joke.

Sometimes the best projects come from scratching your own itch, following the rabbit hole wherever it leads, whatever how deep, especially if you learn along the way.

Window Key Switcher might be a simple extension, but it perfectly solves my specific workflow needs. And the journey of building it taught me about an entirely new ecosystem I barely explored before. It also improved my understanding of LLMs and coding agents.

That's the beauty of side projects - they're never just about the end result.

Edit this page on GitHub

A clock based on Cistercian numerals

Hubert SABLONNIÈRE — Wed, 17 Mar 2021 00:39:14 +0000

Let me tell you the story of when I tried Twitch for the first time to live-code a Web Component that displays numbers with Cistercian numerals, so I could build a clock like this:

Yet another side project idea

Back in January 2021, I saw a tweet about Cistercian numerals. I was very intrigued. If you don't know about them, here's the introduction from the Wikipedia page:

The medieval Cistercian numerals, or "ciphers" in nineteenth-century parlance, were developed by the Cistercian monastic order in the early thirteenth century at about the time that Arabic numerals were introduced to northwestern Europe. They are more compact than Arabic or Roman numerals, with a single character able to indicate any integer from 1 to 9,999.

They look like this:

I really like how compact and elegant it is to display a big number with just one symbol, especially when there is some symmetry.

A few days later, I saw a tweet from Andrew Aquino saying he created a React component to display any number with Cistercian numerals. My first reaction was to tweet:

sudo make web-component

I was expecting someone to create a Web Component, so we could all have a standard compatible way to display Cistercian numbers on our websites, even if we don't use React. Instead, out of distaste for sudo, my wonderful colleague Marc-Antoine Perennou created sudo-ng. Nothing happened, so I guess I was left with yet another side project idea. Although this time, I decided to do it live with an audience.

Trying Twitch for the first time

In the pre-pandemic world, I used to give talks at conferences and share my knowledge and passion for Web development. When you code in front of hundreds of people in a conference room, everything is well-prepared and rehearsed many times. There is a kind of illusion of simplicity, but it's the best way to go straight to the point and focus on the new stuff the audience wants to learn about. The minor drawback is that people miss everything that happens in real life when you write code. You read some docs, you make mistakes, you try something, you go back, you get stuck on a silly bug...

Watching someone thinking out loud and writing code without preparation is a wonderful way to learn. You discover new IDE keyboard shortcuts. You learn about some unknown language pattern or feature. It feels a bit like pair-programming with a mentor.

Following a few fellow speakers that got into Twitch during the first lockdown, I decided to create my channel and try the platform for this side project idea.

My main goal was to create a Web Component to display a number with Cistercian numerals and then reuse it to create a clock component that displays three Cistercian numbers: hours, minutes and seconds. Bonus points if I could animate the lines of the symbols.

The live-coding session

If you're interested, I posted a recording of the session on YouTube but beware:

👂 It's in French.
⌛ It's 2 hours long (120 minutes)
💬 The chat is NOT displayed.
😱 I spent way too much time on Inkscape trying to generate the initial SVG design.
🚧 I should have built both components before thinking about animating them.

Despite those, I really enjoyed giving this session. Mistakes were made, but we finished with some kind of achievement. The clock design was a bit clunky, but it worked. It looked like this:

Sorry, your browser doesn't support embedded videos.

If I were to do it again, I would prioritize the different steps, so the progress is more linear for the audience. I would also improve the way I timebox steps, so I would stop insisting on some details. This retrospective analysis reflects the constructive feedbacks I got from audience members afterwards.

As a host, this session was really pleasant to give, and it almost didn't require any preparation. Between 60 and 70 people attended the stream, and some of them really helped me through the chat. Apart from the code and tips, I think I managed to share the fun I had working on this side project.

I really want to do it again with other side projects ideas. I could try more interactivity with the audience through the chat (and maybe some sounds/music). It's very different from what I'm used to with conference talks. The number of interesting information per minute is clearly not the same, but I don't think it's a problem in itself. I think it's just a different way of sharing knowledge with others. A bit slower, more interactive, less magic but definitely more authentic.

Post-stream improvements

After the stream, I decided to improve the project:

Implement the numbers after 99
Fix the positioning of the different lines
Add some animations using the animated line drawing SVG technique

A few weeks after, I added a few more features:

Use CSS custom properties to allow color customization of each lines
Use CSS custom properties to allow line width customization
Add date mode for the clock to display year, month, day before hours, minutes, seconds
Add no-seconds mode for the clock to remove the seconds
Add inline mode for the number, so you can use a number inside a paragraph of text (as featured in this article if you're reading it from my site)
Try to improve the accessibility (any feedbacks on this is welcome)

I published the source on GitHub at hsablonniere/cistercian-numerals if you're curious.

Web Components are awesome!

Because they're exposed as Web Components, you can use them in any Web project, whatever the stack/framework you're using. You can install them from npm but it's not mandatory at all.

As described in the README, you can use these components in your HTML without any npm install, without any build step or bundler. All you need is a <script> tag sourcing a modern smart CDN like jspm:

<!-- put this in <head> -->
<script type="module" src="https://jspm.dev/cistercian-numerals"> </script>

Then you'll be able to use the number component in your HTML like this:

<cistercian-number inline value="12"></cistercian-number>

You'll also be able to use the clock component in your HTML like this:

<cistercian-clock></cistercian-clock>

Because it's just HTML, it's also very easy to integrate in a Markdown document. It's exactly what I'm doing right now with this article, but you need to browse it from my site. Here's the date + time (without seconds) example:

Please see the README for more details about how to use and customize the components.

References & Links

Cistercian numerals on Wikipedia
Recording of the Twitch session on YouTube
Source code on GitHub
- Source code for <cistercian-number> on GitHub
- Source code for <cistercian-clock> on GitHub
JavaScript package on npm
Animated line drawing SVG by Jake Archibald
Lit (formerly LitElement), the library I used to build the Web Components
Web Dev Server, the dev server I use for live preview
Cistercian SVG by Adrian Roselli
p5js based cistercian clock by E. Dronkert
Arduino + dot matrix cistercian clock by Danjovic
Smart watch face cistercian clock by Philip McGeehan
Smart watch face cisterian clock (inspired by my design) by Matthew Felgate
React based cistercian number component by Andrew Aquino
React based cistercian number component by Maciej Ziarkowski
Clairvo, a proof-of-concept font that uses OpenType Layout to implement Cistercian numerals

Thank you

😍 Thank you wonderful people who attended the stream and thank you wonderful reviewers for your time: Alexandre Berthaud.

Edit this page on GitHub

Prevent layout shifts with CSS grid stacks

Hubert SABLONNIÈRE — Tue, 20 Oct 2020 00:00:00 +0000

There are two reasons why people use CSS grid:

😎 CSS is awesome! It's a fact, deal with it.
🛠️ Grid is a great tool to build complex two-dimensional layouts.

I sometimes have a third reason to use CSS grid: prevent layout shifts. I tried to find a fancy acronym for this technique but all I got was ALSGST: "Anti Layout Shift Grid Stacking Technique". I guess I won't be receiving many skill endorsements for "coining tech terms" on my LinkedIn profile so you better send me some suggestions.

Let me explain the technique using real examples. In this article, I'll cover:

The real layout shift problem I faced with a component I worked on.
The limitations of solving it with absolute positioning.
The benefits of solving it with grid.

Wait, what is a layout shift anyway?

A layout shift is what happens when an update in a web page causes something to move significantly. Most of the time, layout shifts occur during page load while the contents progressively renders. For example, when an image with an unspecified height gets inserted in the page, just before the very paragraph you were reading, the text moves away and it gets pretty frustrating. This is also very common when third party scripts (ad services or partnered contents) append new unknown elements in the page.

This article will focus on layout shifts occuring when toggling state on a UI component. I won't cover layout shifts happening during page load.

Let's get some context

I work for Clever Cloud, an IT automation platform. Our clients push their code and we handle the rest for them: build, deploy, host, scale, maintain, recover and so on. When they need to configure their applications, databases and other services, they use our web UI: "the console". I spend most of my time on this project and it looks like this:

What you see in the screenshot above is the overview of my own website, a Node.js application, hosted on our platform. On the right, you can see a pie chart representing the repartition of HTTP response codes returned by the application in the last 24 hours.

When I worked on this component, I tried to keep things simple. I imagined our users would implicitly understand the chart is related to the current application. To unclutter the display, I decided to move some details like the exact number of requests in tooltips, accessible via mouse or touch. With the chart all cleaned up, I faced a problem. How would I explain the following details?

The chart only displays data from the last 24 hours.
Each item in the legend can be clicked to show/hide the different status code categories. Thank you Chart.js!

The available space was too small to add a detailed title at the top or bottom of the chart. So to help our users figure this out, I added an information button ℹ️ in the top right corner. When this button is clicked, the chart is hidden and a short text is displayed instead. It looks like this:

When the close button is clicked, the short text is hidden and the chart displayed again. Implementing this toggle behaviour was not that hard. Let's take a simplified version of the template:

<div class="chart-component">
  <div class="title">
    HTTP response codes <button>toggle chart/info</button>
  </div>
  <div class="chart">
    <!-- chart here -->
  </div>
  <div class="info">
    <!-- short text here -->
  </div>
</div>

In this HTML, I can, when the button is clicked, simply toggle the component state between .chart and .info and hide the appropriate panel with display: none.

Layout shift problems

This approach has one big problem, it is subject to layout shifts.

Why is that?

When I work on such components, I tend to follow what I consider a good practice: don't set a fixed height on the component, let it adapt to its own content. This is even more important in this situation because I have no way to know how much space is needed to display the short text (without scrollbars). The minimum required height will depend on:

The unknown width of the component, which depends on usage context
The length of the short text, which depends on the language (English or French)

The result is, the component height is a bit smaller containing the chart than containing the short text.

The issue is worse in French because the text is a bit longer:

Depending on the situation, this innocent looking height change can have big impacts on the whole layout and the scroll position. This kind of details can drive your users crazy:

Best case scenario, other parts of the layout slightly move.
Worst case scenario: the button under the mouse cursor moves and something else is placed under (hello Twitter search input).

The video below shows what happens when I toggle between states.

Sorry, your browser doesn't support embedded videos.

You can observe a first layout shift when I go from "chart" to "info". The bar chart moves down and the map gets bigger.

Now look what happens when I scroll down the page and go back to the "chart" state. Look carefully at the mouse cursor. Once over the button, I don't move it, yet a simple click triggers a chain reaction:

The height of the component is reduced to display the chart.
The height of the whole page is reduced.
The whole page is scrolled up a bit.
The mouse cursor is no longer above the button and is now above some text.

Now, how can we prevent this layout shift from happening?

The absolute position solution

Before CSS grid, I would have solved this problem with the position CSS property.

First, I would use visibility: hidden instead of display: none to hide the "inactive" panel:

As you can see, with visibility: hidden, the "inactive" panel is hidden but the component computes its own size as if both panels were there. Now, I have a component with a stable height, based on the heights of .chart and .info.

Then, I would use position: absolute on the .chart. Doing this will remove the element from normal flow. This means the component will compute its own size as if .chart was not there. Therefore, the component size would mostly depend on the size of .info, which is exactly what I want.

The only step left is to give .chart exactly the same position and size as .info. Using position: absolute means .chart will be positioned "relative to its closest positioned ancestor". That is, an ancestor with a position different from the default value (static). Most of the time, I use position: relative on the parent to trigger this. In this situation, I would need an additional .wrapper around both panels like this:

<div class="chart-component">
  <div class="title">
    HTTP response codes <button>toggle chart/info</button>
  </div>
  <div class="wrapper">
    <div class="chart">
      <!-- chart here -->
    </div>
    <div class="info">
      <!-- short text here -->
    </div>
  </div>
</div>

Now that I have this HTML, the CSS solution would look like this:

.wrapper {
  /* .wrapper is the closest positioned ancestor of .chart */
  position: relative;
}

.chart {
  /* .chart is removed from normal flow, therefore
     .wrapper has the exact same size (and position) as .info
     because .info is the only child left in the normal flow
     .chart is positioned relatively to .wrapper */
  position: absolute;
  /* same position as .wrapper (thus same position as .info) */
  left: 0;
  top: 0;
  /* same size as .wrapper (thus same size as .info) */
  height: 100%;
  width: 100%;
}

This position: absolute solution helps me achieve my goal. The size of my component will now always depend on the size of .info, even when it's hidden and .chart is visible.

🤔 No more layout shifts when I toggle between states but still a few limitations:

First, I had to add a .wrapper with a position: relative just so I could use position: absolute on .chart. CSS is awesome but it's also tricky to master. If you're still struggling with how the position CSS property works, this approach can be scary but don't worry:

It's OK. You're not alone!
It gets better with time and practice...

Second, I had to assume the component size would only depend on .info. In more complex situations, I could have more than just two panels where I cannot assume which one should guide the size of the whole component.

Now, let's find out how grid can solve this better.

The grid solution

CSS grid are supported in all evergreen browsers now. This means we can rely on the fact that you can place and overlap multiple elements in the same grid area.

What do you mean by grid area?

If you're not familiar with CSS grid, before continuing this article, I would advise you to:

Watch any talk from Rachel Andrew. She's awesome and in this recent video she did with Jason Lengstorf, they explain CSS grid through live coding examples.
Always have the CSS-Tricks Complete Guide to Grid open in a tab.
Practice, practice, practice...

Now that you're more familiar with CSS grid, we can talk about the now famous "Anti Layout Shift Grid Stacking Technique" (sorry). Let's take the initial simple template we had earlier:

<div class="chart-component">
  <div class="title">
    HTTP response codes <button>toggle chart/info</button>
  </div>
  <div class="chart">
    <!-- chart here -->
  </div>
  <div class="info">
    <!-- short text here -->
  </div>
</div>

If we use CSS grid on .chart-component like this:

.chart-component {
  display: grid;
  gap: 1rem;
}

Our component looks like this:

Thanks to the awesome CSS Grid Inspector from Firefox DevTools, we have annotations for columns and rows. We can see that:

.title, .chart and .info are between column 1 and 2
.title is between row 1 and 2
.chart is between row 2 and 3
.info is between row 3 and 4

This is the default behaviour in a simple 1 column grid: children are placed in order. With grid-column and grid-row, we can force an element to be placed in a specific area of the grid.

For example, if we place our two elements in the same area like this:

.chart,
.info {
  grid-column: 1 / 2;
  grid-row: 2 / 3;
}

The result looks like this:

If you are sceptical, remember the appropriate panel will be hidden with a visibility: hidden.

With this technique, we actually told the CSS engine to prepare a grid where the area at column 1 / 2 and row 2 / 3 should adapt to what's inside. In other words: this very area will always be as big as the biggest between .chart and .info. Therefore, the height of the whole component will be the same when toggling between states.

Sorry, your browser doesn't support embedded videos.

😎 No more layout shifts!

Compared to the absolute position solution, we improved the situation:

No need to add a .wrapper
Would work fine with more than two panels
No need to assume which panel needs to guide the whole component size

Now, as a bonus, let me show you another real example where I used this technique.

Preventing horizontal shifts

The previous example was about the height of a component but you can also use this technique with width. If you give another look at the Clever Cloud console overview, in the top right corner, you'll notice a few buttons to control your app's state.

The "Stop app" button has bigger horizontal paddings than the other buttons. This is because, when clicking this very button, the text is replaced with "Click to cancel" for 3 seconds in case you panick changed your mind.

If we didn't use the grid technique; when the button changes its text from "Stop app" to "Click to cancel", the width change would move all the other buttons like this:

On narrow screens, the wrapping of the buttons could trigger a bigger layout shift like this:

Sorry, your browser doesn't support embedded videos.

Thanks to the "Anti Layout Shift Grid Stacking Technique" (please send naming suggestions, I'm dying), no need to assume which state will be larger. Whatever the lengths of the normal text and the cancel text are, the button will always be big enough.

Sorry, your browser doesn't support embedded videos.

😎 No more layout shifts!

I hope this article helped you consider this kind of layout shifts as a potential problem to solve. I also hope you'll find this technique useful in your own projects.

References & Links

About CSS and grid:

CSS position property reference on MDN
CSS Grid Layout support in browsers on Can I use
Let’s Learn CSS Grid! (with Rachel Andrew) on Jason Lengstorf YouTube channel
Complete Guide to Grid on CSS-Tricks
Please consider using Firefox and their awesome CSS Grid Inspector

The pie chart component and the button component are part of Clever Cloud's component library. The code is open-sourced on GitHub and the documentation (with live preview) is published with Storybook.

You can find out more about the components we talked about here:

Charts.js: the JavaScript library used for those charts
<cc-tile-status-codes>: the pie chart component
- Source code
- Docs with live preview
<cc-button>: the button component with "click to cancel"
- Source code
- Docs with live preview

Thank you

😍 Thank you wonderful reviewers for your time: Julien Durillon, Alexandre Berthaud, Anthony Ricaud, Sarah Haïm-Lubczanski, Julien Lengrand-Lambert and Ralf D. Müller.

Edit this page on GitHub