CSS Geolocation & Named Features: What Web Devs Miss

The browser is getting smarter about where you are, what you can render, and how to name the things it knows. And most dev teams are still shipping the same conditional JavaScript spaghetti they wrote in 2021.

CSS-Tricks’ latest What’s !important roundup (issue #18) surfaced a cluster of browser primitives that deserve more strategic attention than they’re getting — particularly <geolocation>, ::highlight() syntax improvements, and named-feature(). Individually, each is a neat capability upgrade. Together, they represent a shift in where adaptation logic lives: out of JavaScript, into the cascade.

What <geolocation> Actually Changes for Adaptive UX

The <geolocation> HTML element — distinct from the older JavaScript Geolocation API — gives browsers a declarative way to handle location context at the markup level. The practical upside isn’t just cleaner code; it’s performance. Moving location-dependent rendering decisions earlier in the browser’s parsing pipeline reduces the JavaScript execution cost that typically delays First Contentful Paint on mid-range Android devices.

In Southeast Asia, where a significant portion of users are on sub-$200 handsets running Chrome on 4G with variable signal quality, this is not a minor optimisation. When your location-adaptive content (think: currency switcher, language prompt, nearest store widget) currently fires after a JS bundle resolves, you’re adding 300–600ms to an interaction that users in Bangkok or Jakarta are already waiting on. A declarative approach shortens that chain meaningfully — and it keeps your Interaction to Next Paint scores from quietly degrading as your feature set grows.

Implementation consideration: <geolocation> still requires permission handling, and browser support is progressive. Build with a JavaScript fallback during the rollout window, but don’t let that stop you from restructuring your adaptive logic now.

named-feature(): The Quiet End of Magic Number Media Queries

If you’ve ever inherited a stylesheet with @media (min-width: 1024px) scattered across forty files and no documentation explaining why 1024, you’ll understand immediately why named-feature() matters. The function allows teams to define named, reusable conditions — think of it as variables for your media and feature query logic.

The business case here is maintainability at scale, which directly affects time-to-ship for campaigns and site updates. For a regional brand running localised storefronts across six Southeast Asian markets — each with slightly different breakpoint assumptions, platform conventions, and device targeting — a named feature system means one change propagates correctly instead of requiring a grep-and-pray refactor.

This also matters for design system governance. When your breakpoints and feature conditions are named and centralised, your Figma-to-code handoff stops being a game of telephone. Designers and engineers are referencing the same semantic labels, not arguing about whether 768px means tablet or wide-mobile.

---

::highlight() and the Rendering Layer You’re Probably Ignoring

The ::highlight() pseudo-element — and its improved syntax emerging in recent browser builds — lets developers style custom highlight ranges: search results, annotations, selections, text fragments. This sounds like a niche typographic concern. It’s not.

Consider how Shopee and Lazada handle in-page search highlighting on product description pages. Getting that rendering right — fast, styled consistently, without layout shift — is the difference between a search experience that feels native and one that feels bolted on. Current approaches often involve wrapping matched text in <span> elements via JavaScript, which is both slower and fragile when content is dynamically loaded. ::highlight() offloads that work to the browser’s native paint layer, eliminating the DOM manipulation overhead and the associated Cumulative Layout Shift risk.

For teams building content-heavy experiences — news aggregators, e-commerce PDPs, travel comparison tools — this is worth prototyping now. The syntax is stable enough in Chromium-based browsers that you can ship it with a fallback for Safari and Firefox, using @supports to scope the enhanced styles.

Three.js, WebGL, and the Performance Cost of Visual Ambition

Separately, Codrops published a detailed breakdown of Volatile Nexus, a Three.js experiment combining glass refraction, caustics simulation, cube physics, and spatial audio in a single interactive scene. It’s genuinely impressive work from Frank Reitberger — and it’s a useful stress test for thinking about where immersive WebGL sits in a performance budget.

The caustics rendering alone — simulating the way light bends through glass onto surfaces — is computationally expensive. In the experiment, it’s beautiful. In a production marketing page with a 2.5-second LCP target, it’s a liability unless you’re very deliberate about device-tier detection and graceful degradation. The pattern that works: ship the full WebGL experience to desktop and flagship mobile, detect GPU capability via the WebGL renderer string or a brief benchmark on load, and fall back to a CSS/SVG animation for everything else. Don’t make your hero section a performance cliff.

For Southeast Asian campaigns specifically, where the device spectrum runs from iPhone 15 Pro to three-year-old Redmi devices, a WebGL-first approach without tier detection will tank your mobile Core Web Vitals. The creative ambition is worth pursuing — the implementation just needs the engineering discipline to match it.

Key Takeaways

• Migrate location-adaptive and condition-dependent rendering logic from JavaScript into CSS primitives like <geolocation> and named-feature() to reduce FCP delays on mid-range devices.
• Adopt named-feature() as part of your design system to eliminate magic-number breakpoints and reduce cross-market localisation debt.
• When shipping WebGL or Three.js experiences, implement GPU-tier detection and fallback rendering paths before launch — not as an afterthought when mobile CWV scores surface in Search Console.

The browser’s native capability set is expanding faster than most teams’ CSS literacy. The irony is that the best performance wins right now aren’t coming from new infrastructure or edge configurations — they’re coming from teams who read the spec changelog and actually ship what’s in it. The question worth sitting with: how much of your JavaScript is solving problems the cascade could handle natively, if someone gave it the chance?

---

At grzzly, we work with digital teams across Southeast Asia on exactly this intersection — closing the gap between what modern browsers can do natively and what’s actually in production. If your Core Web Vitals are plateauing or your adaptive UX is still running on JavaScript conditionals, that’s a conversation worth having. Let’s talk