Progressively enhancing Grid Lanes

This post is a follow-up on my previous post. I was wondering whether it’s safe to use Grid Lanes today. I came up with a solution I find okay, but there is a caveat.

Note:
This post contains interactive demos. If you want to see them instead of screenshots, enable the CSS Grid Lanes Layout flag in Edge or Chrome or use Safari 26.4+ or Polypane 29+.

In my last blog post, Your Grid Lanes will likely fail WCAG 2.4.3, I explained how Grid Lanes are inherently inaccessible by default unless you take extra measures. I also concluded that it’s probably only safe to use Grid Lanes with Reading Flow. According to Rachel Andrew, Google Chrome also made sure to first ship Reading Flow and then Grid Lanes. Unfortunately, that’s not what all browsers did. Safari shipped it, but doesn’t support Reading Flow yet.

Is it a big deal?

Now you may think it’s not a big deal because most people won’t use Grid Lanes anyway until all browsers support it, and maybe, when that happens, Safari will also support Reading Flow. The thing is, Grid Lanes share many properties with Grids, and because CSS is beautifully designed, it’s very easy to convert regular grids into Grid Lanes for browsers that support it.

HTML

<div class="grid-lanes">
  <button class="s">1</button>
  <button class="m">2</button>
  <button class="l">3</button>
  <button class="l">4</button>
  <button class="m">5</button>
  <button class="s">6</button>
</div>

In one line, you set the display property to grid, and in the next, you overwrite it with grid-lanes.

CSS

.grid-lanes {
  display: grid;
  display: grid-lanes;
  grid-template-columns: repeat(3, 1fr);
}

.grid-lanes {
display: grid;
grid-template-columns: repeat(3, 1fr);
gap: var(–oli-g-spacing-s);
background: var(–oli-g-colors-background);
@supports (display: grid-lanes) and (reading-flow: grid-rows) {
display: grid-lanes;
reading-flow: grid-rows;
}
}
.grid-lanes-flow { flow-tolerance: infinite;}
.supports-grid-lanes { display: none; }
@supports (display: grid-lanes) {
.supports-grid-lanes { display: block;}
.supports-not-grid-lanes { display: none; }
}
@supports not (display: grid-lanes) {
.supports-not-grid-lanes { display: block; }
}
figure p { margin: 0 !important; }
.focus-btn:focus {outline: 3px solid var(–oli-g-colors-cta)}

Browsers that support it will create Grid Lanes, and those that don’t will just fall back to a regular Grid.

In theory, that’s all you need to create future-proof Grid Lanes. People will use it, and some are actually already doing it. Jeremy Keith, for example, explains how he uses @supports to enhance a gallery built with Flexbox.

Generally, both strategies are fine, but neither addresses the focus order issue you may run into.

An accessible progressive enhancement strategy

Although progressive enhancement is possible by merely repeating the display property, I suggest using Grid Lanes only if the browser supports Grid Lanes and Reading Flow.

.grid-lanes {
  display: grid;
  grid-template-columns: repeat(3, 1fr);

  @supports (display: grid-lanes) and (reading-flow: grid-rows) {
    display: grid-lanes;
    reading-flow: grid-rows;
  }
}

1
 
 
2
 
3
 
 
4
 
5
 
6

If you test this demo in Chromium-based browsers with the feature flag enabled, you will see Grid Lanes, and in Firefox and in Safari, you’ll see a regular grid. Yes, that means Safari users won’t see Grid Lanes even though their browser supports it, but it also means that when browsers ship Reading Flow, they’ll likely have a better, more accessible experience.

That’s a great strategy, but…

The deal breaker

I really like this idea, but unfortunately, Reading Flow is currently scoped to Grid and Flex containers. I wasn’t able to find out whether there are plans to extend the property soon. The only thing you can do in the meantime is test your Grid Lanes with the keyboard and adjust flow-tolerance accordingly.

If you need a more general solution, set flow-tolerance: infinite, but still test with the keyboard.

.grid-lanes {
  display: grid;
  display: grid-lanes;
  grid-template-columns: repeat(3, 1fr);
  flow-tolerance: infinite;
}

Conclusion

I suggest using the strategy that checks for support for both properties. It hinders you from shipping inaccessible layouts in Safari. Once reading-flow is extended, you can create well-balanced Grid Lanes while still maintaining a more or less expected focus order. Reading flow doesn’t solve every problem, because focus can still follow a pretty wild path if the items used differ significantly in size, as described in my previous post.

The more I think about it, the less sympathy I have for Grid Lanes. You create a DOM order that you think makes sense, then you mess it up with CSS. Then, if you’re aware of the problem, you fix it again with CSS. Finally, you have a patched-up layout that may have created other issues you can’t address.

I’m looking forward to Chrome’s, Firefox’s, and Safari’s next moves. Until then, to sum it up, my slightly adjusted recommendations are:

• Always test your Grid Lanes with the keyboard or a screen reader across different screen sizes.
• If you find a mismatch between the DOM and the visual order, increase the flow-tolerance value. You may have to use a high value or even infinite.
• As soon as it’s available and supports Grid Lanes, try using reading-flow instead.
• If that doesn’t work, consider using a regular grid.

My blog doesn’t support comments yet, but you can reply via [email protected].