DEV Community

OnePassApps
OnePassApps

Posted on Edited on

The OnePassApps Stylesheet: 403 Custom Properties, Container Queries and Forced Colours

I work on OnePassApps, the team behind app.onepassapps.com. This post is a byte-level read of the stylesheet the live site actually serves - the one file every page on the site is painted with. No design documents and no memory: a plain HTTPS GET of the home page, then of the stylesheet that page links to, with a browser User-Agent and no JavaScript.

The file

The live home page links two stylesheets. The first, /shell-fallback.css, is 3,054 bytes and is the pre-JavaScript fallback that puts the first pixels on screen. The second, /assets/index-B_evf03w.css, is the real one: 242,648 bytes of CSS, served with a one-year immutable cache header, an ETag, and no Last-Modified. The same page also preloads three JavaScript chunks as modules.

403 CSS custom properties

The bundle declares 403 CSS custom properties and references them 2,885 times with var(). They are not a token system in the abstract - they cluster into families with obvious names:

  • brand and surface: brand, brand-edge, brand-glow, brand-ink, canvas, paper, pane, raised
  • ink scale: ink-1, ink-2, ink-3, ink-disabled, plus color-ink-1 through color-ink-4
  • control sizing: control-xs, control-sm, control-md, control-lg, hit-min
  • motion: dur-instant, dur-fast, dur-base, dur-slow, dur-reveal, paired with ease-out, ease-in-out, ease-spring, ease-settle
  • layout: gutter, measure, hero-pad, dialog-pad, and a container scale from container-sm up to container-3xl

That last group is the useful one for anyone writing their own stylesheet against this design: the sizes are named, not magic numbers repeated through rules.

Fonts: one family, 7 files, served from our own host

There are 14 font-face blocks, every one of them for the same family, Inter Variable, declared as a variable font with a weight axis from 100 to 900 and font-display set to swap. Each block carries its own unicode-range declaration, and together they point at 7 woff2 files - the Latin, Latin Extended, Greek, Greek Extended, Cyrillic, Cyrillic Extended and Vietnamese subsets, 218,512 bytes in total.

Two things follow. The fonts are not loaded from Google Fonts or any third-party origin - they come off the same host as the CSS, so a reader's browser makes no request to a font CDN. And the page does not preload them: the document head contains no font preload link at all, so the first paint does not wait on a font file.

How the theme is chosen

The stylesheet contains zero occurrences of the prefers-color-scheme media feature, so the operating system's dark-mode setting cannot switch this site's colours on its own. The choice is made in the application code instead: the JavaScript reads the operating system preference with matchMedia, resolves it to a light or dark theme, and applies it through the class selectors the stylesheet already understands - the stylesheet carries the dark and light variable sets, and the page toggles between them.

In other words the theme is a decision the app makes, with the system preference available as an input, rather than a rule the reader's laptop imposes.

Container queries, not just breakpoints

The stylesheet uses 65 container-query rules across 13 named containers - banner, diff, dtstatus, filelist, icongrid, main, not, pane, present, reactions, tile-meta, tints and toolgrid - alongside 23 distinct media conditions across 61 media blocks.

The media conditions are the accessibility surface, and they are worth reading closely:

  • forced-colors: 6 block(s), so the site keeps working when the operating system forces its own palette
  • prefers-contrast: 2 block(s), so a reader who asks for more contrast gets it
  • prefers-reduced-motion: 10 block(s), split between a reduce case and a no-preference case
  • pointer and hover capability: 15 block(s) covering coarse and fine pointers and hover-capable devices
  • width: 26 block(s) on viewport width in pixels and in rem, the rem ones ranging from 40rem up to 100rem

So the layout is built to be read on a phone and on a desktop, with a mouse and with a keyboard, with motion switched off, and with the operating system forcing colours it did not choose.

The rest of the accounting

  • 28 feature-query blocks - the site asks what the browser supports before using it
  • 5 cascade layers, named base components properties theme utilities - so specificity does not have to be fought with important flags
  • 3 keyframe animations, named spin toolpass-startup-ready-in tp-image-ready
  • 40 color-mix() calls - colours composed out of existing tokens instead of hand-picked hex values
  • 120 hex literals, 66 of them unique - a small literal palette, with everything else derived from it

Why this is worth a look

The interesting part is not that a stylesheet exists. It is that this one keeps its decisions in named variables, derives its colours, supports forced colours and reduced motion, and serves its fonts from its own host. Every one of those is a decision you can check, and this post checked them by reading the bytes the server sent - no browser required.

The tools themselves are on the OnePassApps home page, and the per-app walkthroughs are in the app guides.

I work on OnePassApps, so all of the above is a measurement of our own build rather than a review of someone else's.

Top comments (0)