Intl API & CSS Layers: Web Standards Quietly Solving Real Problems

Frameworks ship. Analytics tags fire. Data layers get argued over in Slack threads that go nowhere. But every so often, a quiet update to a web standard removes an entire category of fragile workaround — and almost nobody notices until someone on the team embarrasses themselves in a code review.

This week, two such updates deserve more attention than they’re getting: the JavaScript Intl API’s unit localisation capabilities, and the CSS cascade layer system that makes !important largely obsolete. Neither is flashy. Both will save you debugging time you didn’t budget for.

The Intl API Already Does What Your Custom Formatter Does — Better

If your team is running any kind of e-commerce or transactional experience across Southeast Asia, you almost certainly have a currency formatting utility somewhere in your codebase. Possibly several, slightly inconsistent versions of it, written by different developers at different points in the product’s life.

As Stefan Judis highlights, JavaScript’s native Intl.NumberFormat handles this natively — and with a precision that most hand-rolled formatters quietly get wrong. Formatting 123456789 as Japanese Yen produces ￥123,456,789, with the symbol correctly positioned before the number. The same value in German Euros produces 123.456.789,00 €, with the symbol after. That symbol placement isn’t arbitrary — it follows locale convention, and getting it wrong erodes trust with users who notice these things immediately.

Beyond currency, Intl handles physical units: speed, file size, distance — all formatted to locale convention. French users, for instance, render kilobytes as kilooctets. If your product surfaces file sizes, storage limits, or data usage (relevant for any app operating in markets with data-conscious users), this matters.

The practical implication for teams running multilingual campaigns or storefronts across Thailand, Vietnam, Indonesia, and the Philippines: audit your existing formatting utilities. The Intl API is available across all modern browsers with no dependency overhead. Replacing custom formatters with it reduces bundle weight and eliminates an entire class of locale-specific bugs that only surface in QA — or worse, in production.

Why !important Is a Red Flag in Any Shared Stylesheet

Every team that has scaled a design system past a certain point has the same scar: someone added !important to fix an urgent visual bug, it worked, it shipped, and six months later three other developers are adding their own !important declarations to override the first one. At that point, specificity is no longer a system — it’s a negotiation.

CSS-Tricks contributor Saleh Mubashar lays out the practical alternatives clearly. Cascade layers (@layer) are the structural answer: they let teams define explicit ordering of style precedence — base styles, component overrides, theme customisations — without relying on specificity arms races. A utility layer defined last in the layer order wins without a single !important in sight.

For teams managing design tokens across marketing pages, app interfaces, and third-party embeds simultaneously, this is architecturally significant. Shopee and Lazada merchant storefronts, for example, often involve injected stylesheets from multiple sources — brand assets, platform UI, promotional overlays. Without layer management, specificity conflicts are nearly inevitable. With layers, the cascade becomes predictable and auditable.

Beyond layers, selector specificity tricks (using :where() to zero out specificity, or :is() to keep it flat) and deliberate rule ordering give teams granular control without the nuclear option. The discipline pays off most when onboarding new engineers: a stylesheet that explains its own priority logic is one that doesn’t require tribal knowledge to maintain.

---

Multi-Column CSS Gets a Practical Upgrade in Chrome 145

Less immediately urgent but worth tracking: Chrome 145 ships column-height and column-wrap properties for multi-column layout, as covered by CSS-Tricks. Previously, multi-column content that overflowed its container would extend horizontally — requiring horizontal scroll, which is broadly considered a UX failure outside of specific carousel or timeline contexts.

With column-wrap, overflow wraps into a new row below, reverting to vertical scroll. This sounds minor until you consider content-heavy mobile interfaces: product comparison tables, feature lists, long-form editorial — all contexts where multi-column layouts make visual sense on desktop but have historically been avoided on mobile due to overflow behaviour.

For Southeast Asian markets where mobile-first isn’t a design philosophy but a demographic reality — Statista’s regional data consistently shows smartphone web usage above 70% in markets like Indonesia and the Philippines — removing a layout pattern from the “desktop only” bucket has real practical value. Teams building responsive content templates should flag this for inclusion in their component library once Chrome 145 reaches sufficient regional penetration.

Implementation Priorities if You’re Triaging This Now

If you’re a frontend lead looking at a sprint backlog, here’s how to sequence these:

1. Intl audit first. Search your codebase for custom currency and number formatting functions. Evaluate whether Intl.NumberFormat can replace them — it usually can. This has the clearest ROI and the lowest risk of regression.
2. CSS layer refactor as a design system initiative. Don’t try to retrofit layers into an existing stylesheet overnight. Start with new components, establish your layer order in the design system documentation, and migrate legacy !important declarations incrementally during scheduled refactors.
3. Multi-column CSS as a progressive enhancement. Log it, test it in Chrome 145, and build the component. Don’t block on it — cross-browser adoption will take a few quarters.

The throughline here is predictability. The Intl API makes locale formatting predictable. Cascade layers make style precedence predictable. Predictable systems are faster to debug, easier to QA, and — critically — easier to hand off when your team scales or turns over.

---

Key Takeaways

• Audit custom currency and unit formatters against Intl.NumberFormat — native localisation handles symbol placement and locale conventions your hand-rolled code likely gets wrong in edge cases.
• Introduce CSS @layer declarations in your next design system component as a structural alternative to specificity hacks; it pays compound interest as the codebase grows.
• Chrome 145’s column-wrap property reopens multi-column layout as a viable mobile pattern — worth prototyping now for content-heavy templates before broader rollout.

The standards bodies aren’t moving fast, but they are moving in useful directions. The question worth sitting with: how much of your current frontend complexity exists because you built around limitations that the platform has since resolved?

---

At grzzly, we work with digital and growth teams across Southeast Asia to build frontend architectures that hold up under the pressure of multilingual rollouts, platform integrations, and the kind of tracking requirements that make engineers and marketers argue in Slack. If your web stack has accumulated more workarounds than you’d like to admit, that’s usually the right moment to talk. Let’s talk