Indonesia Singapore ไทย Pilipinas Việt Nam Malaysia မြန်မာ ລາວ
← Back to Blog

CSS Gap Decorations and What Developers Are Actually Building

CSS gap decorations eliminate a class of layout hacks that quietly inflate your CSS bundle and slow rendering — ship leaner grids now.

Editorial illustration of a developer navigating a web of grid lines and glowing browser windows
Illustrated by Mikael Venne

CSS gap decorations land in Chrome 149, MDN traffic data reveals what developers prioritise, and Three.js glass shaders push rendering boundaries. Here's what matters.

Chrome 149 shipped a CSS feature this week that quietly kills an entire category of layout hacks. Meanwhile, MDN’s public traffic data reveals which parts of the web platform developers are actually reaching for — and a Three.js experiment is asking uncomfortable questions about how far we should push browser rendering in pursuit of delight.

Three signals. One throughline: the gap between what the platform can do and what most production teams are shipping is wider than it should be.

CSS Gap Decorations: The Layout Hack Killer

For years, styling the space between grid or flex items meant one of three ugly paths: pseudo-elements with absolute positioning, transparent borders you’d later regret, or background-color tricks that broke the moment a designer added a border-radius. CSS-Tricks reports that CSS gap decorations are now fully supported in Chrome and Edge starting with version 149 — and the implementation is cleaner than most people expected.

The property lets you style gaps directly, with granular control over intersection behaviour. That means no more nth-child gymnastics to suppress a bottom border on the last row of a card grid. For teams running e-commerce interfaces on Shopee or Lazada-style storefronts — where product grid layouts are rendered server-side and hydrated client-side — this matters beyond aesthetics. Every pseudo-element hack you eliminate is a selector the browser doesn’t have to evaluate during layout recalculation. On mid-range Android devices running Chrome, which represent a substantial share of Southeast Asian mobile traffic, layout recalculation cost is non-trivial.

The immediate implementation move: audit your grid components for any pseudo-element or border-based gap workaround and flag them for migration. Browser support is Chrome/Edge 149+ only for now, so a @supports fence is non-negotiable before shipping to production.

What MDN Traffic Actually Tells Us About Developer Priorities

Bramus van Damme spotted something genuinely useful this week: MDN exposes up-to-date page view data as a public CSV through popularities.mdn.mozilla.net. He used Google AI Studio to build a quick visualiser over it, but the strategic value isn’t the tool — it’s the data.

MDN traffic is a reasonable proxy for where developers are actively confused, learning, or validating their understanding of the web platform. If Flexbox pages consistently outrank Grid pages, that tells you something about what’s actually in production code versus what conference talks celebrate. If fetch documentation is spiking, something in the ecosystem shifted.


For web performance practitioners specifically, this data source is underused. Cross-referencing MDN traffic spikes against Core Web Vitals trends in CrUX data could surface leading indicators: if developers are suddenly reading up on content-visibility or IntersectionObserver, expect to see rendering performance improvements in the wild six to twelve weeks later. That’s a signal worth building a monitoring workflow around, not just a curiosity.

For Southeast Asian teams building multilingual interfaces — where DOM complexity balloons because you’re often rendering two or three language variants conditionally — understanding which layout and rendering APIs developers are actively learning matters for hiring, code review standards, and technical debt prioritisation.

Three.js Glass Shaders: Beautiful, Expensive, and Worth Understanding

Sujen Phea’s Three.js xylophone experiment on Codrops is the kind of thing that makes performance engineers simultaneously impressed and nervous. A scrolling helix of frosted glass bars, each reacting to cursor sweeps with fluid simulation, faked glass entirely in the shader layer using instancing. It’s genuinely stunning.

It’s also a reminder that WebGL rendering on mobile is a different discipline entirely from desktop. Shader-heavy scenes that run at 60fps on a MacBook Pro can drop to 20fps on a mid-range Xiaomi or OPPO device — the market reality for a significant portion of Southeast Asian users. The instancing approach Phea uses is the right instinct for performance: drawing many objects in a single draw call rather than issuing one draw call per bar. But fluid simulations written on the GPU still carry texture sampling costs that vary dramatically across mobile GPU architectures.

The practical takeaway for teams considering WebGL or Three.js for brand experiences isn’t “don’t do this.” It’s: build your performance budget before you build your scene. Define your minimum target device, profile on it early, and treat shader complexity as a first-class constraint alongside polygon count. If your scene isn’t hitting 50fps on a 2023 mid-range Android device, it’s a liability on your Interaction to Next Paint score, not a feature.

Experiments like this also accelerate the ecosystem — the shader techniques Phea documents for faking glass without environment maps will find their way into product UI within 18 months. Understanding the rendering cost now puts you ahead of the curve when a creative director falls in love with frosted glass cards.

Where This Leaves Your Q3 Roadmap

  • Migrate gap workarounds to CSS gap decorations behind a @supports check — the rendering efficiency gains are real, particularly for grid-heavy mobile interfaces on mid-range Android devices common across Southeast Asia.
  • Add MDN’s public popularity CSV to your competitive intelligence stack — cross-reference traffic spikes against CrUX data to identify platform shifts before they surface in your metrics.
  • Establish a mobile GPU performance budget before commissioning any WebGL creative work — shader complexity must be scoped against your actual user device distribution, not a developer’s laptop.

The browser platform is handing teams better primitives every quarter. The question is whether your development workflow is structured to adopt them quickly enough to matter — or whether you’re still writing nth-child hacks for a problem Chrome quietly solved last month.


At grzzly, we work with digital teams across Southeast Asia on exactly this kind of gap between platform capability and production reality — whether that’s performance auditing for mobile-first e-commerce, or helping engineering leads build adoption workflows for new CSS and rendering APIs. If your web stack is carrying technical debt that’s quietly taxing your Core Web Vitals, we’d like to hear about it. Let’s talk

Diesel Grizzly

Written by

Diesel Grizzly

Core Web Vitals, rendering strategies, PWAs, and the relentless pursuit of sub-second load times. Believes that performance is the most underrated conversion optimisation lever in existence.

Enjoyed this?
Let's talk.

Start a conversation