@humanforest/slidev-theme 0.1.0

package/components/BrowserFrame.vue

@@ -0,0 +1,484 @@
+<script setup>
+/*
+  Desktop browser chrome — the deck's port of the design system's FBrowserFrame. A neutral
+  macOS/Safari window: traffic lights, one centred address pill, a new-tab glyph, wrapping a live
+  screen at a real display aspect.
+
+  ★★ NO CC-LICENSED ART HERE, AND THAT IS THE DIFFERENCE FROM DeviceFrame. A phone needs a photoreal
+  render of hardware, which is where the Wikimedia CC BY-SA vectors come in. A window is DRAWN, from
+  deck tokens, and owes nobody anything — so this file imports nothing. The traffic-light colours are
+  taken verbatim (#ff5f57 / #febc2e / #28c840): they are macOS's own, and a Forest-tinted
+  approximation would read as a mistake rather than as a window.
+
+  Redrawn rather than imported because FBrowserFrame.vue is written in Nuxt UI's semantic classes —
+  bg-default, bg-elevated, border-default, text-muted, text-dimmed — which this deck does not have.
+
+  ★★ THE PORT WENT WRONG TWICE, IN OPPOSITE DIRECTIONS, AND BOTH ARE WORTH RECORDING.
+
+  First it was too little: the structure was right but it lost the shadow the original carries, and
+  it kept the original's 12px lights beside the DECK'S type. Jose: "where's the shadow? and the
+  traffic light buttons are too small compared with the url displayed."
+
+  Then, reading "the frame should look like actual chrome of a browser", it was rebuilt as GOOGLE
+  CHROME — a tab strip, back/forward/reload, a menu. Wrong word, wrong browser, and wrong instinct:
+  "chrome" is the generic term for a window's furniture, and the instruction was to match what the
+  design system already draws, which is Safari's single bar. Inventing a richer window made the deck
+  disagree with the system it is a specimen OF.
+
+  So this is the original's ARRANGEMENT — lights, one centred address field, a new-tab glyph — at the
+  deck's scale, with its shadow.
+
+  ★★ AND ITS FINISH IS DELIBERATELY NOT THE ORIGINAL'S, WHICH IS A DIVERGENCE WORTH NAMING. Ported
+  literally it came out dated — Jose: "not like a real safari browser, not very modern" — and he was
+  right: FBrowserFrame draws a BORDERED RECTANGLE for the address field on a heavy grey slab, which
+  is macOS circa 2015. Current Safari is a capsule with a soft fill and no border, on a toolbar that
+  sits close to the page, under a wide low shadow.
+
+  A mock is judged on whether it reads as the thing it is imitating, so the finish follows Safari and
+  not the package. The arrangement still follows the package, so the two are the same window. If the
+  design system is refreshed, this is the direction it should take rather than the other way round.
+
+  ★★ THE WHOLE BAR IS SIZED FROM THE WINDOW, NOT FROM THE DECK'S TYPE RAMP, and that is what makes
+  it read as a browser rather than as a deck component shaped like one. Set from
+  `--type-deck-caption-size` the bar came out 125px tall on a 1080px window — 11.6% of its width,
+  where Safari's is about 4% — a chunky slab that no amount of finish would have fixed.
+
+  So the bar's type is `width * 0.022` and every metric in it is `em`. The window is a PICTURE of a
+  browser, and a picture keeps its subject's proportions; DeviceFrame makes the same move for the
+  same reason, rendering its screen at true logical points and scaling the whole thing. At 1080 wide
+  that is 24px text — smaller than the deck's caption, and still legible from the back of a room.
+
+  ★ THE LIGHTS ARE SIZED IN `em`, WHICH IS THE ACTUAL FIX rather than a bigger number. In the design
+  system the lights are 12px and the URL is 12px — one to one, and it reads correctly because both
+  are at a web page's scale. The port kept the 12 and inherited the deck's 36px caption type, so the
+  lights came out a third the height of the text beside them. Tying them to `em` makes the
+  relationship the thing that is preserved, so neither scale can drift from the other again.
+*/
+import { computed } from 'vue';
+import { assetUrl } from '../assetUrl.js';
+
+const RATIOS = { '16:10': 16 / 10, '16:9': 16 / 9 };
+
+const props = defineProps({
+  /**
+   * What the address bar shows. Unset with a `src`, it is that URL's own host — so a window pointed
+   * at a real page cannot caption itself with somebody else's address, which a literal default of
+   * `'forest.bike'` would have let it do silently.
+   */
+  url: { type: String, default: '' },
+  /**
+   * A LIVE PAGE to put in the screen, as a URL — rendered in an `<iframe>` at the window's own size.
+   *
+   * ★★ SLIDEV SUPPORTS THIS OUT OF THE BOX and this prop is not a re-implementation of it: the
+   * upstream theme ships `layout: iframe`, `iframe-left` and `iframe-right`, which give a URL a
+   * whole slide or half of one. This deck has its own nine layouts and none of them is that, and an
+   * iframe with no chrome around it is a rectangle of somebody else's website rather than a picture
+   * of a website — so the frame is what makes it read. A raw `<iframe>` in the slot still works
+   * anywhere, and is the escape hatch for a case this prop does not cover.
+   *
+   * ⚠ A LIVE PAGE IS A NETWORK DEPENDENCY ON A SLIDE. It draws nothing offline, it can change under
+   * the deck between rehearsal and the room, and `slidev export` renders whatever the site serves at
+   * export time. Where the page is the ARGUMENT rather than the illustration, `image` is the honest
+   * choice — a capture says what it said when it was taken. Reach for `src` when the point is that
+   * the thing is real and current.
+   *
+   * It is LIVE in every sense by default — see `interactive` below.
+   */
+  src: { type: String, default: '' },
+  /**
+   * Whether a `src` page can be scrolled and clicked.
+   *
+   * ★★ TRUE, BECAUSE `src` ALREADY MEANT "I WANT THE REAL THING". This was frozen at first, on the
+   * reasoning that a deck is a picture of a product — and that is the argument for `image`, not for
+   * a prop whose whole purpose is that the page is current. Somebody who reaches for `src` has asked
+   * for the site; handing them a still of it that happens to cost a network request is the surprise.
+   * Jose, on the first cut: "it is not interactable? at least scrollable?"
+   *
+   * ⚠ THE ONE REAL COST IS KEYBOARD FOCUS. Slidev advances on arrow keys and space, and a focus
+   * inside the frame takes those with it — click the page, and the next arrow scrolls the site
+   * rather than turning the slide. Clicking the slide outside the frame gives it back. Scrolling and
+   * clicking are otherwise free: Slidev does not scroll slides, and the frame's `sandbox` denies
+   * top-navigation, so a link inside cannot move the deck out from under the presenter.
+   *
+   * Pass `false` for a page that must sit still — a slide left on screen unattended, or one where a
+   * stray scroll would leave the audience looking at the middle of somebody's footer. It is set with
+   * `inert` as well as `pointer-events`, so the frozen frame is out of the focus order too.
+   */
+  interactive: { type: Boolean, default: true },
+  /**
+   * The screen's shape.
+   *
+   * ★ TWO VALUES, AND THE RESTRAINT IS THE DESIGN SYSTEM'S OWN: "the two shapes a desktop actually
+   * comes in". This port briefly offered 4:3 and 3:2 as well, which is a specimen of a monitor
+   * nobody has — and the frames package states why in its own comment: a hand-picked height drifts
+   * into ratios no display uses, which makes a mock's reflow decisions untestable against anything
+   * real. A phone gets its shape from a device registry; a desktop gets it from this pair.
+   */
+  ratio: {
+    type: String,
+    default: '16:10',
+    // Repeated inline: defineProps() is hoisted out of setup() at build time, so this validator
+    // cannot close over the RATIOS const above — that compiles in dev and breaks a production build.
+    validator: (r) => ['16:10', '16:9'].includes(r),
+  },
+  /**
+   * How wide to draw the window, in canvas pixels. Unset, it takes the room it is given — as wide as
+   * that room allows, or narrower where the room is too short for a window that wide.
+   *
+   * ★★ IT USED TO NEED ONE, AND THAT WAS THE DEFECT RATHER THAN THE CONTRACT. The SCREEN's height is
+   * derived from the width and the ratio, so a full-width window on the 1728px content band is 1080
+   * of screen plus its bar — the whole canvas and then some — and every caller had to compute a
+   * width that fit. deck-template's slide 25 did not, and hung 367px off the bottom until the audit's
+   * canvas pass could see it again.
+   *
+   * The wrapper now caps itself against the room's HEIGHT (see `.deck-browser-room` below, and the
+   * hosts that give it one in base.css), so an unset width is a working default rather than a trap.
+   * Pass one only to draw the window SMALLER than its room on purpose — a figure at a chosen size,
+   * not a fit correction.
+   */
+  width: { type: Number, default: 0 },
+  /** Draw the window on the dark register, for a mock of a dark-mode page. */
+  dark: { type: Boolean, default: false },
+  /**
+   * A screenshot to fill the screen with, as a URL — the same one-rule convention the layouts use for
+   * their figures. Cropped with `object-fit: cover`, so a capture taken at some other shape is
+   * trimmed rather than squashed. The slot wins for anything that is not a still.
+   */
+  image: { type: String, default: '' },
+  /** Alt text for `image`, and the accessible title of a `src` frame. */
+  alt: { type: String, default: '' },
+});
+
+/*
+  The host, with `www.` dropped — what a browser's own address field shows and what somebody reading
+  a slide from the back of a room can actually take in. Wrapped because `new URL()` throws on a bare
+  host ('forest.bike'), which is exactly what a caller writing an address rather than a source would
+  pass; the empty string then falls through to the literal default below.
+*/
+const hostOf = (u) => {
+  try { return new URL(u).host.replace(/^www\./, ''); } catch { return ''; }
+};
+const address = computed(() => props.url || hostOf(props.src) || 'forest.bike');
+</script>
+
+<template>
+  <div class="deck-browser-room" :style="{ '--deck-browser-screen-ratio': String(RATIOS[ratio] ?? RATIOS['16:10']) }">
+    <div class="deck-browser-fit" :style="width ? { width: `${width}px` } : undefined">
+      <div class="deck-browser" :class="dark ? 'deck-dark is-dark' : ''">
+        <div class="deck-browser-bar">
+          <span class="deck-browser-lights" aria-hidden="true">
+            <i style="background: #ff5f57" /><i style="background: #febc2e" /><i style="background: #28c840" />
+          </span>
+          <span class="deck-browser-url">
+            <svg class="deck-browser-glyph" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2.2" stroke-linecap="round" stroke-linejoin="round" aria-hidden="true">
+              <rect x="4" y="10.5" width="16" height="11" rx="2.5" /><path d="M8 10.5V7a4 4 0 0 1 8 0v3.5" />
+            </svg>
+            <span class="deck-browser-url-text">{{ address }}</span>
+          </span>
+          <!-- The new-tab glyph the original carries, and the reason the address pill sits optically
+               centred: it balances the lights on the other side. -->
+          <svg class="deck-browser-glyph deck-browser-plus" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2.2" stroke-linecap="round" aria-hidden="true">
+            <path d="M12 5v14M5 12h14" />
+          </svg>
+        </div>
+
+        <div class="deck-browser-screen">
+          <img v-if="image" :src="assetUrl(image)" :alt="alt" class="deck-browser-media" draggable="false">
+          <!--
+            `loading="lazy"` because a deck mounts more slides than it shows. This book sets
+            `preload: false`, so only the neighbours are built — but a deck that does not would
+            otherwise fetch every live page in it the moment it opens, and lazy defers an off-screen
+            frame in either case.
+
+            `sandbox="allow-scripts"` and nothing else: measured against forest.bike, scripts alone
+            render the page identically to an unsandboxed frame, and withholding `allow-same-origin`
+            gives it an opaque origin — no cookies, no storage — while the default denial of
+            top-navigation, forms, popups and downloads means an embedded page cannot move the deck
+            out from under the presenter. `referrerpolicy` keeps the deck's own URL out of the
+            embedded site's logs.
+          -->
+          <iframe
+            v-if="src"
+            class="deck-browser-live"
+            :class="interactive ? '' : 'is-frozen'"
+            :src="assetUrl(src)"
+            :title="alt || `A live view of ${address}`"
+            :inert="!interactive"
+            loading="lazy"
+            sandbox="allow-scripts"
+            referrerpolicy="no-referrer"
+          />
+          <slot />
+        </div>
+      </div>
+    </div>
+  </div>
+</template>
+
+<style scoped>
+/*
+  ★ THE SHADOW IS THE ORIGINAL'S, not a new idea: FBrowserFrame carries
+  `drop-shadow(0 25px 45px rgba(0,0,0,.28))` and the first port simply dropped it, leaving the window
+  flat on the slide. It is also the only drop shadow in this theme, and that is right — every other
+  object here is OF the page, where a window is a picture of something in front of it.
+
+  A box-shadow rather than a filter: the frame is a plain rounded rectangle, so the cheaper property
+  does the same job, and a filter would establish a containing block for anything positioned inside.
+*/
+/*
+  ★★ A CONTAINER, SO THE CHROME SCALES WITH THE WIDTH IT IS ACTUALLY DRAWN AT.
+
+  The bar's type was `width * 0.022` as an inline style, which only exists when a caller passes
+  `width`. Put in a split's figure cell the window takes the CELL's width and that prop is absent —
+  so it fell back to the deck's 36px caption and the chrome came out chunky again, the same defect
+  in a new place.
+
+  `container-type: inline-size` here and `cqw` inside means the proportion holds however the width
+  arrives: an explicit prop, a grid cell, a figure column. The wrapper exists because an element
+  cannot query itself — the window has to be the container's CHILD to read `cqw`.
+*/
+/*
+  ★★ AND A SECOND WRAPPER OUTSIDE IT, WHICH IS THE ROOM RATHER THAN THE WINDOW.
+
+  Two boxes because they answer two different questions and each needs its own container. `-fit` is
+  the WINDOW's width, and the chrome queries it. `-room` is the space the window was given, and the
+  fit box queries THAT — a box cannot query itself, so the height the cap is computed from has to
+  come from one level up.
+
+  The room only knows its height where something outside gives it one; base.css names the three
+  hosts that do (`.slidev-layout > `, split's figure cell, stack's band), makes it a size container
+  there and caps the fit box against `100cqh` of it. Everywhere else there is no cap at all and the
+  window behaves as it always did — width-driven, uncapped — which is the right answer inside a grid
+  cell that has a caption under it and no height to spare.
+*/
+.deck-browser-room {
+  display: flex;
+  flex-direction: column;
+  justify-content: center;
+  align-items: center;
+  width: 100%;
+}
+.deck-browser-fit {
+  /*
+    THE BAR'S TYPE, PUBLISHED — because two elements need it and they resolve it against DIFFERENT
+    containers. `.deck-browser` uses it as `font-size`, where `cqw` is the fit box: the width the
+    window is actually drawn at, which is the whole point of the container below. The cap uses it
+    here, where `cqw` is the ROOM: wider than or equal to the window, so the height it reserves for
+    the bar is never an under-estimate. One declaration, two correct readings.
+  */
+  --deck-browser-chrome: clamp(14px, 2.2cqw, 30px);
+  /*
+    ★★ WHAT THE WINDOW ADDS ABOVE AND BELOW ITS SCREEN, WHICH IS THE ONE NUMBER THE FIT MATHS NEEDS.
+
+    `max-height` does not travel back through `aspect-ratio` — a box at `width: 100%` with a ratio
+    and a height cap keeps its width and simply loses its shape (measured: 500x300 in a 500x300 room
+    where 480x300 was wanted). So the cap has to be a MAX-WIDTH, and a max-width has to know how much
+    of the room the screen does not get.
+
+    2.1 is an upper bound on the bar's own height in `em`, not its exact height: the bar is 2.02em of
+    padding and pill plus a 1px border, so it measures 2.05em at the type's 30px ceiling and 2.09em
+    at its 14px floor. The 2px is the window's own border, top and bottom. Rounding UP is what makes
+    the whole expression safe — over-reserving leaves a few pixels of room unused, under-reserving
+    hangs the window off the slide, and only one of those is a defect.
+
+    ponytail: a constant restating a height CSS computes. The bar is not pinned to it deliberately —
+    a pinned height would clip the bar's own contents silently, where an under-reserve fails loudly
+    in scripts/deckAudit.ts's canvas pass. If the bar is ever retuned past 2.1em, that gate is what
+    says so; raise the number then.
+  */
+  --deck-browser-frame-h: calc(2.1 * var(--deck-browser-chrome) + 2px);
+  container-type: inline-size;
+  width: 100%;
+}
+.deck-browser {
+  display: flex;
+  flex-direction: column;
+  width: 100%;
+  overflow: hidden;
+  /* 2.2cqw is the same factor the inline style used, expressed against the real width. The clamp is
+     a floor and a ceiling for the extremes: a thumbnail-sized window still needs legible chrome, and
+     a full-bleed one should not grow toolbar type without limit. Declared one level up so the fit
+     box can reserve the bar's height from the same expression — see `--deck-browser-chrome`. */
+  font-size: var(--deck-browser-chrome);
+  /*
+    ★★ THE WINDOW'S OWN CORNER, NOT THE DECK'S CARD RADIUS. This was `--deck-radius-card`, which is
+    `--deck-radius * 6` — the radius a CARD takes in this deck, and far rounder than any window has.
+    Jose: "keep the rounded corners of the component, dont force a slide doctrine corner radius."
+
+    He is right, and the reason is what this component is. A card is furniture the deck owns, so it
+    takes the deck's radius; a browser window is a PICTURE OF SOMETHING ELSE, and its corner is a
+    fact about macOS the same way the traffic-light colours are. Overriding it makes the mock read
+    as a Forest card with a toolbar drawn on it.
+
+    ★ AND IT IS THE CURRENT macOS CORNER, NOT THE OLD ONE. 0.55em landed at ~11px, which is Big Sur's
+    radius and the `rounded-xl` the design system's frame uses — and reads dated next to a machine
+    running anything recent, where windows are visibly rounder. Jose: "use a proper corner radius,
+    like how the newest macos do." 0.9em is about 20px on a 940px window, which is the modern shape.
+
+    In `em` so it scales with the window like every other metric in the chrome — the corner is a fact
+    about the subject, and it has to survive being drawn at any size.
+  */
+  border-radius: 0.9em;
+  border: 1px solid var(--deck-border);
+  background: var(--deck-bg);
+  /*
+    ★ TIGHTER AND FAINTER THAN THE DRAFT, AND IN `em` SO IT SCALES WITH THE WINDOW.
+
+    It was `0 40px 80px -24px / 0.30` plus a contact layer — which read as a spread-out haze under the
+    frame rather than as a window sitting on the page. Jose: "less prominent, not that spread out,
+    more subtle." The blur is roughly halved and the opacity cut, so it separates the window from the
+    slide without announcing itself from the back of a room.
+
+    In `em` for the same reason every other metric here is: the shadow is part of the object, and a
+    fixed 40px under a window drawn at 900 reads differently from the same 40px under one drawn at
+    1400. Two layers still — a broad ambient one and a short contact one, which is what a real window
+    casts — just quieter.
+  */
+  box-shadow: 0 0.55em 1.1em -0.35em rgb(0 0 0 / 0.16), 0 0.1em 0.3em -0.12em rgb(0 0 0 / 0.10);
+}
+
+.deck-browser-bar {
+  display: flex;
+  align-items: center;
+  /* The address pill was setting the bar's height through its own line box — 71px on a 1000px
+     window, 7.1% where Safari's toolbar is about 4%. A tight line-height hands the height back to
+     the padding, which is the thing that was tuned. */
+  line-height: 1.15;
+  gap: 1em;
+  padding: 0.36em 0.7em;
+  /*
+    Close to the page, not a slab on top of it. The original's `bg-elevated/60` reads as a second
+    surface; a modern toolbar is barely separated from the content — a hairline and a couple of
+    percent of tint, which is what keeps the window feeling like one object.
+  */
+  border-bottom: 1px solid color-mix(in oklab, var(--deck-border), transparent 40%);
+  background: color-mix(in oklab, var(--deck-bg), var(--deck-fg) 3%);
+  color: var(--deck-fg-muted);
+  font-family: var(--font-sans);
+}
+/* One `em` each, so the lights and the address text keep the design system's one-to-one relationship
+   at whatever size this bar is set. See the note at the top — this is the whole fix. */
+/*
+  ★ HALF AN `em`, AND THE FIRST em-BASED NUMBER WAS STILL WRONG. Tying the lights to the type fixed
+  the relationship but 0.9em then made them huge — Jose: "after scaling the traffic light buttons are
+  huge compared to the other things". Measured against the real thing rather than guessed again:
+  macOS draws a 12px light in a 52px toolbar, so a light is about 23% of the bar's height. At 0.9em
+  on a 48px bar these were 20px — 42%, nearly double. 0.5em lands at 11px, which is 23%.
+
+  The lesson is that the type was the wrong thing to size them against: `em` is only the MECHANISM
+  that keeps them in step. The proportion they actually owe is to the BAR.
+*/
+.deck-browser-lights {
+  display: flex;
+  flex: none;
+  gap: 0.34em;
+}
+.deck-browser-lights i {
+  display: block;
+  width: 0.5em;
+  height: 0.5em;
+  border-radius: var(--deck-radius-full);
+}
+/*
+  `margin-inline: auto` with a max width, exactly as the original does it: the pill is centred in the
+  BAR rather than in the space left over, which is what keeps it centred under the window's own
+  midline whether or not the URL is long.
+*/
+.deck-browser-url {
+  display: flex;
+  align-items: center;
+  justify-content: center;
+  gap: 0.42em;
+  width: 100%;
+  max-width: 22em;
+  min-width: 0;
+  margin-inline: auto;
+  padding: 0.18em 1em;
+  /*
+    A CAPSULE WITH A FILL, NOT A BORDERED RECTANGLE. The border is what dated the port: current Safari
+    draws the field as a soft capsule that sits INSIDE the toolbar rather than as a control drawn on
+    top of it, and an outline around it reads as a text input from a decade ago.
+  */
+  border-radius: var(--deck-radius-full);
+  background: color-mix(in oklab, var(--deck-bg), var(--deck-fg) 7%);
+}
+.deck-browser-url-text {
+  overflow: hidden;
+  /* Smaller than the bar's own type. Safari sets the address in a size below the rest of the
+     toolbar's, and at parity the URL was the loudest thing in the window — the address is a label,
+     not a headline. Applied to the TEXT rather than the pill so the field's own geometry, which is
+     tuned in `em`, does not shift with it. */
+  font-size: 0.82em;
+  text-overflow: ellipsis;
+  white-space: nowrap;
+}
+.deck-browser-glyph {
+  flex: none;
+  width: 0.9em;
+  height: 0.9em;
+  opacity: 0.6;
+}
+.deck-browser-plus {
+  width: 1.1em;
+  height: 1.1em;
+}
+
+.deck-browser-screen {
+  /* From the ratio prop, as a custom property rather than an inline `aspect-ratio`, because the fit
+     box one level up needs the same number to turn a height cap into a width. */
+  aspect-ratio: var(--deck-browser-screen-ratio);
+  min-height: 0;
+  overflow: hidden;
+  background: var(--deck-bg);
+  color: var(--deck-fg);
+}
+/* The screen is a fixed shape and a capture is whatever shape it was taken at, so it is cropped
+   rather than distorted. `video` included — `<SlidevVideo>` is what carries one into a print export,
+   where a plain `<video>` prints blank. */
+/*
+  The live page fills the screen at the window's own size, so the site lays out for the width the
+  window is drawn at — a 1000px window gets a desktop page and a narrow one gets what a narrow
+  browser gets, which is the whole reason to embed a page rather than photograph one.
+
+  A white ground rather than the deck's, so a page that has not painted yet reads as a blank page
+  rather than as a cream panel with a toolbar.
+*/
+.deck-browser-live {
+  display: block;
+  width: 100%;
+  height: 100%;
+  border: 0;
+  background: #fff;
+}
+/* `interactive: false`. `inert` on the element already blocks pointer events and focus in every
+   browser that ships it; this is the same statement in CSS, for the one that does not. */
+.deck-browser-live.is-frozen {
+  pointer-events: none;
+}
+.deck-browser-screen :deep(img),
+.deck-browser-screen :deep(video),
+.deck-browser-screen :deep(picture),
+.deck-browser-media {
+  display: block;
+  width: 100%;
+  height: 100%;
+  object-fit: cover;
+}
+/*
+  ★★ DARK IS NEUTRAL, NOT FOREST, AND THAT IS THE ONE PLACE THIS COMPONENT LEAVES THE REGISTER.
+
+  `.deck-dark` re-points every `--deck-*` role, which is the deck's one dark mechanism and is why
+  there are no per-colour rules here. But its ground is `--forest-950` — a dark GREEN — and a browser
+  window rendered in it comes out a green window. Jose: "for dark dont use the green, use the neutral
+  palette." A window is a picture of macOS, not a Forest surface: its dark mode is grey.
+
+  So the class is still applied — every text and border role should take its dark mapping, and
+  anything slotted into the screen themes correctly — and only the three GROUNDS are re-pointed onto
+  the neutral ramp. `--deck-fg` and friends are left alone, because deck.css already resolves those
+  through `--neutral-*` rather than through the forest hue.
+*/
+.deck-browser.is-dark {
+  --deck-bg: var(--neutral-900);
+  --deck-border: var(--neutral-700);
+}
+</style>