Horizon

text-box-trim / text-box-edge Chrome · Safari · Firefox

Trims the half-leading above the cap line and below the baseline, so text sits flush in its box. The highlight shows the line box; on the right it hugs the actual letters.

On the site: this cleanly fixes the optical-centering I hand-tuned with magic-number padding on the XP title bars, and ends the long Safari <h2> baseline saga. Now shipped in all three: Chrome 133, Safari 18.2, Firefox 149.

Your browser doesn't support it yet, so the two samples above look identical.

contrast-color() Safari + Firefox

Auto-picks a legible (black/white) text color for a given background. Top label in each swatch is naive fixed-white; bottom is contrast-color(). watch it flip to black on the light chips.

On the site: everywhere I currently eyeball a text color to sit on a colored bevel, this derives it from the OKLCH background. Funny twist: here Chrome is the laggard (arriving ~m147); Safari and Firefox already shipped it. Needs a static fallback color until Chrome lands.

Your browser doesn't support it yet, so the "auto" labels fall back to black.

anchor positioning / position-area + position-try Chrome · Safari · Firefox

Tether one element to another in pure CSS: give the target an anchor-name, point a popover at it with position-anchor, and place it with position-area (a 3×3 grid around the anchor: top center, bottom span-right…). No getBoundingClientRect(), no scroll/resize listeners, no JS coordinate loop. The killer feature is position-try-fallbacks: when the chosen side would overflow, the browser flips to the opposite side on its own. Click a button below: the left popover sits above (and flips below if it runs out of room near the top of the viewport); the right one asks for the right edge and flips inline when crowded.

On the site: this is already live here in a small dose: the keyboard-focus path of the homepage tooltip tags the focused element with anchor-name: --xp-tip and the .xp-tooltip.anchored rule uses position-anchor to tether it, so Tab-navigating the photo grid gets a properly-placed Fuji-LCD popover with no cursor to follow. It wins everywhere I'd otherwise reach for JS positioning: a future /coffee slot-picker dropdown, the artist popovers, any menu, all could anchor + auto-flip in CSS. It does not replace the pointer-following --x/--y loop (anchors attach to elements, not the cursor), so the two coexist: cursor-tracking for mouse, anchored for keyboard. Now cross-engine: Chrome 125, Safari 26, Firefox 147 (position-anchor FF 151), WebKit support #167.

Your browser doesn't anchor yet, the popovers above still open (native Popover API), they just fall back to a fixed corner of the demo box instead of tethering + flipping. Chrome 125+, Safari 26+, or Firefox 147+ shows the real behavior.

scroll-driven animations animation-timeline: scroll() / view() Chrome · Safari · Firefox

Tie a CSS animation's playback to scroll position instead of the clock: no scroll listener, no requestAnimationFrame, no JS at all. scroll() tracks a scroller's offset; view() tracks an element crossing the scrollport. Scroll the box below: the XP progress strip fills via a named scroll-timeline, and each row fades up on its own view-timeline as it enters view.

On the site: this retires any scroll-position JS I'd otherwise hand-write (a reading-progress strip on /garage long-reads, or lazy fade-up reveals for the 3×3 photo grid) in pure CSS that the compositor runs off the main thread (no jank competing with the cursor-tooltip --x/--y loop). It's the rare frontier feature that's already cross-browser (Chrome 115, Safari 26, Firefox 110+; WebKit standards-position support, #152), so it could graduate to the homepage today, strictly as decoration, gated behind @supports and prefers-reduced-motion, because the content must read fine with the animation pinned to its end state.

Your browser doesn't support animation-timeline yet, the progress strip sits at a fixed third and the rows just stay visible instead of revealing on scroll.

popover=hint Chrome 133 · Safari/FF positive

A third popover type, sitting between auto and manual, purpose-built for tooltips. A hint popover is light-dismissed (click outside, Esc) and won't force-close an open auto popover the way another auto would, so a hover-tip can float over a menu without nuking it. Open each below and click elsewhere to feel the difference:

On the site: the live cursor-tooltip (#xp-tooltip in index.html) is declared popover="manual" and driven entirely by a JS pointerover/pointermove loop that writes --x/--y and calls showPopover()/hidePopover(). Switching it to hint would buy native light-dismiss, but the site only has one tooltip and it already manages its own lifecycle, so the win is marginal: I'd still run the same JS to follow the cursor and pick the content. hint really pays off in the multi-popover case (a tip that coexists with an open menu) the homepage doesn't have. Filed as "safe to adopt, low value here."

Your browser doesn't support popover="hint", the middle button falls back to auto semantics (the attribute parses to the default), so it behaves like the first one. To try it in older Chrome, enable chrome://flags#enable-experimental-web-platform-features.

field-sizing : content Chrome · Safari

Lets a form control size itself to its content instead of a fixed rows/cols or magic-number height. A <textarea> auto-grows line by line as you type and shrinks back when you delete; an <input> hugs its value. Type into both fields below: the left one is a stock textarea pinned at rows="2", the right one tracks the text (min-height/max-height keep it from collapsing or running off the card).

single-line input that hugs its value:

On the site: this is the native kill-switch for the classic input/scrollHeight auto-resize handler: the JS pattern that listens on input, zeroes the height, reads scrollHeight, and writes it back every keystroke. The coffee booker benefits most directly: cal/'s "Your info" message box on the booking form can drop its resize script entirely and just say field-sizing: content; max-height: 9em on the sunken XP textarea, with the layout reflowing for free. Now shipped in Chrome 123 and Safari 26.2 (Firefox not yet), so it can graduate to the live booking form, not just the garage. Pair it with a static rows attribute as the fallback height and there's nothing to feature-detect.

Your browser doesn't support field-sizing yet, the right-hand textarea behaves exactly like the left (fixed rows="2", scrolls), and the email input keeps its default width. The rows attribute is the graceful fallback.

View Transitions / document.startViewTransition() Chrome · Safari · no Firefox

Wrap a DOM mutation in document.startViewTransition(cb) and the browser snapshots before + after, then cross-fades (or morphs, for same-named elements) between them: an animated state change with no manual tweening, no double-buffering, no FLIP math. Same-document is shipped in Chrome 111 and Safari 18; the cross-document @view-transition { navigation: auto } variant (Chrome 126, Safari 18.2) animates whole navigations. Firefox ships neither. Tap the toggle: the panel below has its own view-transition-name, so only it animates:

Live, self-contained: the swap is a real startViewTransition() call, gated so unsupported browsers still toggle instantly (just without the morph).

On the site: the photo grid fits most obviously. Reshuffling the random 9, or expanding a thumbnail to its full-res /images/full/ view, could morph the clicked frame into place by sharing a view-transition-name instead of a hard cut. But the cross-document nav cross-fade was deliberately removed site-wide: the @view-transition { navigation: auto } opt-in softened the McMaster-Carr-style instant snap that the eager Speculation-Rules prerender exists to deliver. A 200ms fade on top of a zero-latency prerendered page is a regression, not a polish. So the rule here is: same-document morphs on opt-in interactions = yes; automatic navigation cross-fade = no, it fights the prerender. (A leftover @view-transition line still sits in xpChromeCss() in _worker.js with a stale "mirrors the homepage" comment, the homepage no longer opts in, so that block is dead and worth pruning.)

Your browser doesn't support document.startViewTransition (Firefox, today), the toggle still works, it just swaps the panel instantly with no cross-fade. That instant-swap is the graceful fallback: the feature is purely a progressive enhancement.

appearance: base-select / customizable <select> Chrome · Safari TP/flag

For two decades the <select> popup has been a sealed OS widget: you got the trigger, never the list. appearance: base-select opts the control into a fully styleable model: the popup becomes real DOM you can theme, ::picker(select) and ::picker-icon are addressable, and each <option> can hold arbitrary markup. The select below is a true native control (keyboard, typeahead, form value all intact) reskinned into an XP combobox with alternating Outlook-Express rows, a blue-gradient highlight, a rotating drop-arrow, and a color swatch inside every option. Open it:

Velvia Classic Chrome Velvia Acros Nostalgic Neg. Classic Neg.

On the site: this natively answers the future cal/ booking dropdowns (timezone, slot length, meeting type): today those would mean a hand-rolled JS listbox to escape the un-styleable OS popup, or a system widget that shatters the XP illusion. base-select lets one real <select> carry the bevel, the alternating rows, and inline swatches/icons while keeping full keyboard + form semantics for free. But it is Chrome-shipped only (~m135); Safari and Firefox render the native widget, so it is strictly progressive enhancement until it lands cross-engine (WebKit standards-position: support, #386, positive, not yet shipped).

Your browser doesn't support appearance: base-select yet, the dropdown above falls back to your OS's native <select> widget (which is exactly the intended graceful degradation). To try the XP-themed version, open this page in Chrome 135+.

corner-shape + superellipse() Chrome · Safari TP/flag

A second axis for border-radius. The radius sets where a corner's two endpoints sit; corner-shape sets the curve drawn between them: round (the default), bevel (a flat cut), notch (a square step in), scoop (concave bite), or squircle / superellipse(k) for the Apple-style continuous curve. Every box below shares the same border-radius: 18px; only the keyword differs. Resolved via WebKit standards-positions #229.

On the site: this natively replaces the clip-path: polygon() hack on the title-bar icon, and any time I'd reach for an SVG mask to cut a corner. A real squircle on the .window and photo-frame corners reads more 2006-Aqua than the flat border-radius arc does, and it stays a live border (shadow, outline, focus ring all follow the new shape) instead of a clip that eats the box-shadow. Chrome 139 only: Safari and Firefox haven't shipped it, so it can't graduate to the homepage yet; it needs a plain border-radius fallback (which every box above already degrades to).

Your browser doesn't support corner-shape yet, all six boxes above fall back to identical plain rounded corners, and the framed window keeps ordinary rounded tabs. To try it in Chrome 139+: no flag needed; older Chrome via chrome://flags#enable-experimental-web-platform-features.

scheduler.yield() / main-thread responsiveness Chrome-only · FF positive

WebKit: unstated A promise you await in the middle of a long task: it hands the main thread back to the browser to service pending input/paint, then resumes your loop, and crucially resumes at the front of the queue, not the back like setTimeout(0). So you stay responsive without losing your turn to unrelated work. It's shipped in Chrome (no flag), so the demo below is live: the concept, then a real measured run, then the code.

// today on the site: cold-KV tracklist fallback builds ~50 rows
// in one go, blocking input on a slow phone.
for (const t of tracks) renderTrackRow(t);   // one long task

// with scheduler.yield(), guarded so it ships everywhere:
const yieldNow = (window.scheduler && scheduler.yield)
  ? () => scheduler.yield()
  : () => new Promise(r => setTimeout(r, 0));  // fallback

let i = 0;
for (const t of tracks) {
  renderTrackRow(t);
  if (++i % 8 === 0) await yieldNow();   // breathe every 8 rows,
}                                        // resume at front of queue

On the site: the offender is the client-side Spotify tracklist fallback (the cold-KV path that renders full-fidelity rows: artist links, cover art, tooltip wiring). Today that's one synchronous burst. scheduler.yield() would let it chunk while keeping taps and scroll alive, without the back-of-queue penalty of a setTimeout(0) shim. It graduates to the homepage trivially because it's a guarded enhancement (typeof check, same-shape fallback), so Safari and Firefox just take the plain loop.

Your browser doesn't expose scheduler.yield(), the live demo below still runs and stays responsive, it just takes the setTimeout(0) fallback path instead. To get the real primitive: Chrome 129+, shipped, no flag.

HTML-in-Canvas / ctx.drawElement() Chrome flag · WICG early

WebKit: no position Draws a live, laid-out DOM subtree straight into a 2D canvas with ctx.drawElement(el, x, y) (and the WebGL twin texElement2D). The element keeps real text layout, fonts, and accessibility, unlike foreignObject+SVG, it isn't tainted, doesn't silently drop styles, and can be composited, transformed, and post-processed pixel-by-pixel. Below: a real XP title bar on the left, rasterized into the canvas on the right and tilted: one source of truth, two surfaces.

On the site: this is the only sanctioned way to take the hand-built XP chrome (the title bars, the contact-sheet photo frames, the Fuji LCD tooltip) and run it through canvas effects (a tilt, a CRT scanline pass, a drop-shadow bake) without re-drawing any of it in canvas primitives or shipping an html2canvas-style screenshotting library. Picture a one-off "rendered on a 2006 CRT" hero, or baking a share-card OG image of the live now-playing list. But it is a single-engine flag with no WebKit position, so it stays a garage toy: the homepage cannot depend on it for anything Safari/Firefox visitors need to see.

const el  = document.getElementById("hic-source");
const ctx = canvas.getContext("2d");

// tilt the whole surface, then rasterize the LIVE element into it
ctx.translate(20, 14);
ctx.transform(1, 0.06, -0.10, 1, 0, 0);   // slight skew
ctx.drawElement(el, 0, 0);                 // <- the new primitive

// from here it's normal canvas: ctx.filter, getImageData, WebGL texElement2D…

Your browser doesn't support drawElement yet, the canvas shows a placeholder instead of the live rasterization. Enable chrome://flags#canvas-draw-element in Chrome Canary to see it for real.

CSS Masonry / Grid Lanes Safari 26 ships · Chrome flag

Lays tiles of uneven height into columns, each new tile dropping into the shortest column so the bottom edge stays ragged and the gaps close: the Pinterest / contact-sheet look, but native. After years of a syntax fight (a grid-template-rows: masonry shorthand vs. a separate display: masonry), it has converged into Grid Lanes: masonry expressed inside CSS Grid so you keep grid-template-columns, gaps, and (eventually) subgrid. Safari 26 shipped it as display: grid-lanes (on by default); Chrome keeps it behind the experimental flag. The grid below is real grid-lanes where the engine supports it (you, on Safari 26) and falls back to a CSS multi-column mockup elsewhere: the mockup reads down-then-across, true masonry packs into the shortest lane.

Live in Safari 26 (display: grid-lanes, on by default). In Chrome it's behind chrome://flags#enable-experimental-web-platform-features (the #css-grid-lanes-layout entry). Everywhere else: the mockup above.

/* today on aadhar.sh — rigid, every frame the same box */
.photos {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  gap: 8px;
}
.photos img { aspect-ratio: 1; object-fit: cover; } /* crops the Fuji frames */

/* tomorrow — Grid Lanes (NOT shipped; syntax still settling) */
.photos {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  display: grid-lanes;           /* Safari 26 ships this; grid-template-rows:masonry is the spec form */
  gap: 8px;
}
.photos img { height: auto; }    /* native aspect ratio preserved, no crop */

On the site: the homepage photo grid is a hard 3×3 of square-cropped thumbnails: portrait Fuji frames get center-cropped and tall Leica shots lose their composition. Masonry would let each thumbnail keep its native aspect ratio (the orientation-corrected width/height already in metadata.json) and pack with no crop and no row-height gridlock. Until it ships in two engines it stays here: the live grid keeps cropping, because a Canary-flag layout that falls back to a broken stack for every real visitor is exactly what this page exists to avoid shipping.

Your browser can't show real masonry yet, nothing ships it by default in mid-2026. The grid above is a CSS multi-column approximation, not the live feature; enable the Canary / Safari TP flags above to drive the genuine layout.

JPEG XL image/jxl Safari ships · Chrome removed · Firefox no

The format the photo pipeline actually wants: smaller than AVIF at the high quality end (where this site lives), genuinely progressive (a low-res preview paints from the first few KB, then sharpens), and it can losslessly re-wrap an existing JPEG ~20% smaller with the original bytes recoverable. No live decode below: Chrome (my daily driver) can't decode JXL, and there's no .jxl asset on the site, so this is an honest mock plus the wiring it'd take. WebKit: support (shipped)

Bars are illustrative (matched perceptual quality, photographic content), not measured on these specific shots.

• Progressive by default: the Fuji-grain photos paint a blurry frame from the first KB and resolve as bytes arrive, instead of AVIF's all-or-nothing decode.
• Lossless JPEG transcode: cjxl in.jpg out.jxl shrinks the existing jpegli output ~20% and is byte-reversible, so no quality decision to re-litigate.
• High-fidelity sweet spot: at the q82-ish quality this site targets, JXL keeps grain and tonal gradients that AVIF starts to smear.

<!-- add jxl ABOVE avif; browser picks the first type it claims to support.
     Safari takes jxl, Chrome/FF skip to avif, ancient takes the jpg src. -->
<picture>
  <source type="image/jxl"  srcset="/images/<stem>.jxl?v=11">
  <source type="image/avif" srcset="/images/<stem>.avif?v=11">
  <img src="/images/<stem>.jpg?v=11" loading="lazy" decoding="async">
</picture>

# pipeline: one more encode step after the jpegli stage in add-photos.sh
cjxl --lossless_jpeg=1 <stem>.jpg <stem>.jxl   # byte-reversible re-wrap
# OR re-encode from the 1200px source for max ratio:
cjxl -q 90 -e 7 <stem>.png <stem>.jxl

On the site: a third tier above AVIF in every photo-grid <picture>, plus a cjxl step in add-photos.sh after the jpegli encode and another stem format in holding/images/ (120 stems × 3 formats). But the <picture> type-fallback decode trap from the CLAUDE.md gotcha applies double here: the format split is wildly uneven: only Safari decodes it, Chrome dropped it in 2023 (a Canary #enable-jxl-image-format decode flag is returning), Firefox has never shipped it. So for now it'd only ever serve to Safari while tripling the asset count and KB on disk. Not a graduation candidate until Chrome ships decode again non-flagged; it stays parked here as the format I'd adopt the day that happens, given the SOOC originals already live in R2 to re-encode from.

Nothing to decode live regardless of your browser, this card is a static mock by design. To actually view a .jxl today you need Safari 16.4+; in Chrome enable chrome://flags#enable-jxl-image-format in a recent Canary.

HDR adaptive tone-mapping / AGTM · #hdr-agtm Chrome flag · not shipped

A gain-map HDR image carries two things: a normal SDR base picture, plus a per-pixel gain map that says how much extra luminance each spot should gain on a display with headroom. Adaptive Global Tone Mapping (AGTM, SMPTE ST 2094-50) lets the image author ship a tone-mapping curve so the same file renders correctly across a dim laptop, a bright phone, and a 1600-nit XDR panel: the highlights bloom on capable screens and fold back gracefully on SDR ones, instead of either clipping to flat white or being globally dimmed. This is the next rung above the P3 wide-gamut already used on the photo grid: P3 buys wider color, HDR buys brighter highlights.

Can't be shown live here. It needs a real gain-map asset, an HDR-capable display, and the experimental flag all at once, and a screenshot would just be SDR pixels lying about it. So the cells below are an honest mockup of the idea, not real HDR: left, an SDR ramp whose sun clips to paper-white; right, the same scene with the specular headroom the gain map would restore. The bar shows where the SDR ceiling sits and the hatched region is the extra headroom AGTM maps into.

# today: SOOC -> sips resize -> jpegtran rotate -> cjpegli q82 -> avifenc CQ30
#         single SDR-tonemapped AVIF + JPG, P3-tagged.

# with AGTM: keep the SDR base, ALSO author a gain map + 2094-50 curve.
#   X-T5 / Leica raw already holds the highlight data cjpegli throws away.
avifenc --gainmap hdr.avif base.jpg -o photo-hdr.avif   # gain-map AVIF
# OR ultra-HDR JPEG (libultrahdr) for the universal <img> fallback:
ultrahdr_app -m 0 -i base.jpg -g gainmap.jpg -o photo-uhdr.jpg

<picture>
  <source type="image/avif" srcset="/images/<stem>-hdr.avif?v=N">
  <img src="/images/<stem>.jpg?v=N">  <!-- SDR base = the fallback -->
</picture>
/* gate the glow so SDR panels never see a washed-out frame: */
@media (dynamic-range: high) { .photos img { /* let it bloom */ } }

On the site: this doesn't replace anything, it's a forward-look for the photo grid. The gain-map base layer is the existing SDR JPG/AVIF, so the fallback is free and the pipeline is purely additive: one extra encode step in add-photos.sh, no new client JS. It pairs with the @media (color-gamut: p3) upgrades already in the stylesheet via a sibling @media (dynamic-range: high) gate, so SDR visitors keep the exact frame they have now. Honest blockers: AGTM is a Chrome flag (#hdr-agtm), not shipped anywhere by default, and naive HDR photos in a feed are a known eye-searing UX problem, so it stays in the garage until it ships cross-engine and the curves can be tuned to glow, not blind.

Your browser / display reports no HDR headroom (dynamic-range: high is false), so even a real AGTM asset would render as its plain SDR base, which is exactly the graceful fallback that makes this safe to ship. The two cells above are a mockup either way.

Declarative routing / route-matching Chrome flag · building blocks cross-browser

The pitch: declare your app's URL space once as a set of URLPattern route rules, then let CSS style whichever route is currently active: an "active nav tab" with zero JavaScript and no per-link aria-current bookkeeping. The routing flag itself is Chrome-only and still unrated, but it's assembled from two shipped, cross-engine primitives: URLPattern (WebKit #61: support) and the Navigation API (WebKit #34: support).

// TODAY, cross-browser: URLPattern + Navigation API, ~a dozen lines of JS.
// This is what aadhar.sh would actually use right now.
const routes = [
  { id: "home",   p: new URLPattern({ pathname: "/" }) },
  { id: "garage", p: new URLPattern({ pathname: "/garage/:rest*" }) },
  { id: "photo",  p: new URLPattern({ pathname: "/images/full/:file" }) },
];
navigation.addEventListener("navigate", (e) => {
  const url = new URL(e.destination.url);
  const hit = routes.find(r => r.p.test(url));
  document.documentElement.dataset.route = hit ? hit.id : "404";
});
/* CSS picks up the active route via the data-attribute: */
[data-route="garage"] .nav-garage { font-weight: bold; }

<!-- TOMORROW (Chrome flag #route-matching, not cross-browser): -->
<!-- routes declared in markup; CSS styles the active one directly,  -->
<!-- no navigate listener, no data-attribute plumbing.              -->
<a href="/garage/" class="nav-tab">garage</a>
/* :route-active { font-weight: bold; }  (sketch syntax) */

On the site: this is overkill today: aadhar.sh is deliberately one handwritten file per page, with routing that lives in route() at the top of _worker.js, not in the client. There's no SPA and no active-nav state to track. But it's the right thing to watch if the garage ever grows a shared client-side nav: the cross-browser half (URLPattern + Navigation API) could already replace any hand-rolled location.pathname string-matching with declared patterns, and the CSS half (once it ships in more than one engine) would let the active garage tab style itself with no JS at all. Strictly a forward-look while it's Chrome-flag-only.

Your browser is missing the building blocks (URLPattern or the Navigation API), so even the JS-today version above wouldn't run. The mock tab-bar is static either way, no engine ships the declarative CSS side yet. To try the flag in Chrome: chrome://flags#route-matching.

<install> element / Web Install API Chrome flag · Safari opposes

A declarative install affordance: drop an <install> element (or call navigator.install()) and the browser paints a real "install this app" button wired to the same flow as the omnibox install icon, no beforeinstallprompt event plumbing, no stashing the deferred prompt, no custom button that has to guess whether the app is already installed. It can also point at a different origin's manifest, so one site can offer to install another.

There is no live demo here on purpose: it sits behind chrome://flags#web-app-installation-api in Chromium only, and WebKit opposes the design (oppose, #463), so it cannot graduate under this page's "two engines" rule. Below is the markup it would take, and a faux-XP render of the button it would mint:

<!-- declarative: browser paints + wires the button -->
<install
  manifest="/manifest.webmanifest"
  installtext="Install aadhar.sh"></install>

// or imperative, behind the same flag:
const result = await navigator.install();   // current-origin app
await navigator.install("https://aadhar.sh", manifestUrl); // cross-origin

// what it REPLACES today (the imperative dance):
let deferred;
addEventListener("beforeinstallprompt", e => {
  e.preventDefault(); deferred = e; showMyButton();
});
myButton.onclick = async () => {
  deferred.prompt();
  await deferred.userChoice;   // and you still guess "already installed?"
};

On the site: aadhar.sh isn't a PWA: no manifest beyond the favicon, no service-worker install story for the homepage itself (sw.js only caches /images/* and the garage pages). So there is nothing to wire up yet. The honest read is that this is a forward-look for a hypothetical "add aadhar.sh / the coffee booker to your dock" affordance, and even then, because WebKit opposes, it would be a Chrome-only enhancement layered on top of a manual fallback button, exactly the situation the cursor-tooltip and interestfor cards describe. Stays in the garage.

Your browser doesn't expose the Web Install API, the mockup above is a dead button. To try it: Chromium with chrome://flags#web-app-installation-api enabled.

CSS Carousel ::scroll-marker · ::scroll-button Chrome 135

A scroll-snap strip that grows its own prev/next buttons and dot markers in pure CSS: scroll-marker-group on the scroller mints a ::scroll-marker per item, :target-current lights the active dot, and ::scroll-button(left/right) page it. No JS, no library, no scroll listener. Drag, click a dot, or use the buttons:

On the site: the photo grid could become a swipeable contact sheet with a Luna dot-strip underneath, the markers and arrows are the browser's, not mine. Gated behind @supports (scroll-marker-group: after); where it's missing the same markup is just a plain scroll-snap rail (still swipeable, minus the dots and arrows).

Your browser doesn't mint ::scroll-marker yet, the strip above still scroll-snaps and swipes, it just has no dots or arrow buttons.

Invoker Commands command / commandfor Chrome 135 · Safari 26

A button that drives another element declaratively: commandfor points at a target, command says what to do (toggle-popover, show-modal, close…), the sibling of interestfor, but for clicks instead of hover. Zero JavaScript wired below:

Show details ▾

On the site: the caption-bar minimize/close and any future booking dialog in cal/ become declarative: markup is the behavior, so there's less inline JS to ship and nothing to rehydrate.

Your browser doesn't parse command/commandfor yet, the button above is inert (no fallback handler is wired, on purpose).

@scope scoped styles + donut Chrome 118 · Safari 17.4

Style a subtree without a naming convention, and stop the styles at an inner boundary: the "donut." @scope (.card) to (.inner) applies between the two. Proximity wins over specificity, so a closer scope beats a more-specific selector. Live:

On the site: every page is one file of inline CSS, so a stray .controls or .title-bar rule leaks into demo windows (it just bit me wiring the garage prototypes). @scope fences a component's styles to its own block: no BEM, no prefixes.

Your browser doesn't support @scope, the inner line below the hole inherits nothing special; both paragraphs look the same.

Custom Highlight API CSS.highlights · ::highlight() Chrome · Safari · Firefox

Paint arbitrary text ranges: no wrapper <span>s, no DOM mutation. Build Ranges, hand them to a Highlight, register it in CSS.highlights, and style via ::highlight(name). The two phrases below are lit without touching the markup:

This site is modeled after the recent wave of resto-mod cars, where you take a beloved chassis and formula and modernize it while retaining its soul.

On the site: a code viewer could syntax-highlight without wrapping every token in a tag: cheaper DOM, and search-term highlighting that never disturbs the text it marks.

Your browser lacks the Custom Highlight API, the sentence above renders with no emphasis (the text is identical, just unpainted).

hidden=until-found + scroll-to-text Chrome 102 · Safari 26

Content that is collapsed but still findable: hidden="until-found" hides a region, yet in-page find (Ctrl/⌘-F) and #:~:text= deep links will auto-expand it, fire beforematch, and scroll it into view. Try it: search this page for aircooled:

● Found me. This line was hidden="until-found", collapsed in the layout, but the browser searched inside it anyway and revealed it. The aircooled keyword lived here the whole time.

On the site: long /garage write-ups could ship fully collapsed yet stay Ctrl-F-able and deep-linkable, honest with crawlers (the text is really in the DOM) while keeping the page short.

Your browser doesn't support hidden=until-found, the line above stays hidden and find-in-page can't reveal it.

relative color syntax oklch(from …) Chrome 119 · Safari 16.4 · FF 128

Derive a color from another color: pull out its l c h channels and recombine them. One base, every tint, shade, and hue-rotation computed from it. All five chips below descend from the same leftmost Luna blue.

On the site: the hover/active/border shades of every bevel are currently hand-picked OKLCH values. This computes them from one token: change the base, the whole bevel set follows.

Your browser doesn't support relative color syntax, the derived chips fall back to the base blue.

@property / registered custom props Chrome · Safari · Firefox

Registering a custom property with a syntax type makes it animatable. The gradient angle below is a <angle> custom prop being keyframed: impossible with a plain unregistered variable (the browser can't interpolate an untyped string).

On the site: lets the OKLCH palette tokens (and the --ab avatar hue over on serendipity) transition smoothly instead of snapping.

Your browser doesn't support @property, the gradient sits static (the angle can't animate).

@starting-style + transition-behavior: allow-discrete Chrome 117 · Safari 18 · FF 129

Animate an element as it appears from display: none: no JS, no double-rAF hacks. @starting-style gives the entry its "before" values; allow-discrete lets display itself participate in the transition so the exit animates too. Toggle it:

Toggle box

On the site: the cursor tooltips and any popover could ease in/out instead of hard-cutting, with zero animation JS.

Your browser doesn't support it, the box snaps in and out with no transition.

light-dark() Chrome 123 · Safari 17.5 · FF 120

One declaration, both schemes: color: light-dark(black, white) resolves by the element's color-scheme. The two panels share the exact same background + color rules, only their color-scheme differs.

On the site: a single XP "High Contrast"/dark variant becomes a one-token flip instead of a parallel stylesheet.

Your browser doesn't support light-dark(), both panels fall back to unstyled colors.

declarative shadow DOM <template shadowrootmode> Chrome · Safari 16.4 · FF 123

A shadow root written in markup: the parser attaches it with no JavaScript. The pill below is a component whose styles are fully encapsulated (a page-level span rule can't touch them) and whose label is <slot>-projected from the light DOM.

On the site: the XP window chrome is copy-pasted across ~6 files. As a DSD <xp-window> it'd be defined once, encapsulated, and still render on first paint with JS off.

Your browser doesn't support declarative shadow DOM, you see the raw light-DOM text ("rendered server-side…") instead of the styled pill.

<model> element Safari 26 (Testable)

A native, declarative 3D viewer: <model src="scene.usdz"> with built-in orbit/zoom and AR hand-off, no WebGL/three.js. Currently a WebKit prototype (the "HTML <model> element" flag in your Safari 26 screenshot). No live model is loaded here, just the placeholder it would occupy:

On the site: a SOOC lens or a camera body could spin in 3D in the photo tooltip, declaratively, the way <video> handles motion.

Your browser doesn't expose HTMLModelElement, the element is inert here (placeholder only).

CloseWatcher API Chrome 120 · Safari 26

One abstraction for "close requests": Esc on desktop and the Android back gesture, so custom UI (sidebars, lightboxes) dismisses the same way native dialogs do. Open the panel, then press Esc:

Open panel

On the site: the full-res photo lightbox could register a CloseWatcher so Esc and mobile back both dismiss it, with the platform managing the stack.

Your browser lacks CloseWatcher, the demo falls back to a manual Esc key listener.

HTML switch control <input type=checkbox switch> Safari 17.4 · Apple-led

A native toggle switch: just a switch attribute on a checkbox. Same form semantics, switch affordance, no ARIA plumbing. Shipped in Safari (the "HTML switch control" flag in your screenshot); not yet in Chromium/Gecko, where it degrades to a normal checkbox:

On the site: a real switch for any future toggle (sound on/off, reduced motion) instead of a faux-CSS slider.

Your browser ignores the switch attribute, you see a standard checkbox above (the graceful fallback).

if() & sibling-index() / CSS Values 5 Chrome 137+ · flag

Two bleeding-edge CSS primitives: if() for inline conditionals (style()/media() queries as values) and sibling-index(), which yields an element's position among its siblings, so a staggered animation needs no per-item variables. Each row below delays by sibling-index() × 90ms (reload to replay):

• row one
• row two
• row three
• row four
• row five

On the site: the photo grid or tracklist could cascade in on load with one rule, and if() could fold tiny media-query overrides inline.

Your browser doesn't support sibling-index(), the delay resolves to 0, so all rows appear at once (no stagger).

scroll-state container queries @container scroll-state(stuck) Chrome 133 · others no

Style an element by its scroll condition, e.g. whether a position: sticky header is currently stuck. The header below turns Luna-blue the moment it pins to the top. Scroll the inner box:

On the site: the page title bar could shed its shadow / tighten when it sticks, declaratively, no scroll listener.

Your browser doesn't support scroll-state queries, the sticky header stays grey even when pinned.

reading-flow / reading-order Chrome 137 · others no

Decouples focus order from source order for flex/grid. The three links below are reordered visually with order (DOM is 1-2-3, you see 2-3-1). With reading-flow: flex-visual, Tab follows what you see (left to right) not the DOM. Tab through them:

On the site: lets CSS-driven responsive reordering stay keyboard-accessible without ARIA gymnastics: the long-standing tension between visual and focus order, resolved.

Your browser doesn't support reading-flow, Tab follows DOM order (1→2→3) regardless of the visual shuffle.

Document Picture-in-Picture Chrome 116 · others no

An always-on-top window you fill with arbitrary HTML, not just a video frame. Click below to pop this box into a floating mini-window (close it to bring it home):

Pop out ↗

On the site: pop the now-playing tracklist into a floating window that survives tab-switching: a literal always-on-top Outlook-Express widget.

Your browser lacks documentPictureInPicture, the button is disabled.

Temporal / the date/time rewrite FF 139 · Safari TP · Chrome flag

The long-awaited replacement for Date: immutable objects, first-class time zones and calendars, no more month-zero footguns. Live output from Temporal.Now.zonedDateTimeISO() in your browser:

On the site: photo "uploaded" stamps and serendipity event times become zone-correct and DST-safe without a date library.

Your browser doesn't expose Temporal yet, the box above says so.

The long tail: independent engines

"The platform" isn't only Chromium, Gecko, and WebKit. Two teams are building new engines largely from scratch, a useful reminder that the frontier above is the front, and most of the web runs well behind it. Both are pre-release and racing toward baseline, not chasing 2026 CSS, so on the features on this page they're mostly "not yet." Status as of mid-2026: check the live links, this moves fast.

The point: these two are why "ship to baseline, prototype the frontier" is the right discipline. To support the independent, indie-web engines, I lean on what's broadly shipped, not what's newest in one browser. Good deep-dive comparison: Browser Engines 2026.