Stackness
All moves

Reach for native platform features before JavaScript workarounds

by Stackness

Languages & Frameworks

Rather than patching layout problems with JavaScript resize listeners or hand-tuned negative margins, use the browser's own primitives: CSS properties like text-box-trim that read font metrics directly, and new viewport units that solve the mobile 100vh problem natively. The broader practice is auditing where a team reaches for JS or hacks when the platform already has a built-in, more correct answer.

What it is

This move is about defaulting to built-in browser capabilities instead of reaching for JavaScript or hand-tuned CSS hacks. Two concrete examples show the pattern: using the text-box-trim property to control font-metric spacing instead of eyeballed negative margins, and using the new svh, lvh, and dvh viewport units instead of a resize-listener script to fix the mobile 100vh problem.

How to do it

  • When a heading has unexpected extra space above or below the text, stop guessing at negative margin values. Apply text-box-trim: trim-both with text-box-edge: cap alphabetic (or the shorthand text-box: trim-both cap alphabetic) so the browser trims the line box to the actual cap height and baseline instead of leaving room for ascenders and half-leading.
  • When building full-screen sections on mobile, replace the classic JavaScript fix of listening for resize and writing a --vh custom property with native viewport units: use svh for a safe floor that always fits even when browser toolbars are visible, lvh for the fully collapsed UI case, and dvh when you want the box to track the real, current visible height.
  • More broadly, before writing a workaround, check whether the underlying problem is actually a platform primitive answering a question you have not asked yet, such as a unit or property that already encodes the metrics or state you are trying to approximate.
  • Audit existing code for resize listeners, magic-number margins, or other hacks tuned to one browser or one font, and treat them as candidates for replacement once a native equivalent exists.

When it helps

This applies whenever a hack has been tuned to a specific font, browser, or device and breaks the moment any of those change, such as swapping fonts breaking a negative margin, or iOS Safari and Android Chrome handling vh differently depending on scroll position and toolbar state.

Pitfalls

Older workarounds persist partly out of familiarity and habit, not just missing browser support, so teams may keep copy-pasting JavaScript fixes long after a CSS property exists. Also be aware that native features can arrive unevenly across browsers, and some developers genuinely prefer building things themselves because it feels more reasoned or enjoyable, which can work against adopting the platform-native approach even when it would be simpler.

Sources

Tools

CSS