@humanforest/slidev-theme 0.1.0

package/slide-top.vue

@@ -0,0 +1,268 @@
+<script setup>
+/*
+  Running chrome, mounted PER SLIDE — the top half. slide-bottom.vue documents why this is a
+  per-slide hook rather than a global overlay switching on layout name; the same reasoning applies
+  here, so it is not restated.
+
+  Two pills, top-left: the page number (always, once chrome is showing at all) and the section —
+  which slide-bottom.vue in Task 4's shape had no way to know, because a slide's section is not
+  something the SLIDE carries. It is the nearest PRECEDING divider's title: derived from the deck's
+  own slide list, not read off this slide's own frontmatter. See ./section.js for the derivation
+  and the two indexing/precedence traps it guards.
+
+  One tile, top-right: the Forest mark. `<Logo variant="mark">` is already self-contained — its own
+  doc comment calls it "the rounded green tile with the white tree" — so no wrapper is needed to
+  make it read as a tile; it already is one.
+
+  Both pills route through BadgeStrip rather than a hand-rolled `<span>` + scoped CSS: BadgeStrip's
+  `.badge-strip-item` already IS "--deck-radius-control, the overline type role, the chip token
+  pair" — the exact three things this step is required to use — because it is the same pill this
+  deck already ships for tags. Reaching for a second, near-identical implementation here would be
+  exactly the drift `backgrounds.js`'s own doc comment warns about: two copies of one shape that can
+  now disagree. Passing BOTH labels as one `items` array (rather than two separate <BadgeStrip>
+  calls) also gets "no pill when section is empty" for free — BadgeStrip already renders one <span>
+  per array entry, so filtering the empty string out of the array IS the "no pill" behaviour,
+  not a v-if bolted on beside it.
+
+  The pill does not take BadgeStrip's own default (`accent-dark`, --forest-950), and that is a
+  MEASURED choice rather than a preference: --deck-bg-accent-dark resolves to var(--forest-950), and
+  .deck-dark's own --deck-bg is ALSO var(--forest-950) — PINNED halves are declared once at :root and
+  are never re-pointed under .dark/.deck-dark, so an accent-dark pill would sit at exactly the ground
+  colour on any dark-register slide that doesn't opt out of chrome: an invisible-edged pill the
+  geometry audit cannot see either way. The chrome takes --deck-accent instead, which moves with
+  the register and reads against both the light ground (--warm-50) and the dark one (--forest-950).
+
+  ★ FIX ROUND 1, CRITICAL 1 — `currentPage` must come from `injectionCurrentPage`, NOT
+  `useNav().currentPage`. `useNav()` is `createSharedComposable` (@slidev/client/composables/
+  useNav.ts:365) — ONE instance shared by the whole app — and its `currentPage` is
+  `currentSlideNo = hasPrimarySlide ? getSlide(params.no)?.no ?? 1 : 1`, a ROUTER value keyed off
+  `route.params.no` (useNav.ts:290-291). That param exists on the normal per-slide route, but NOT
+  on every route Slidev renders a slide through: `@slidev/client/setup/routes.ts` declares the
+  print route as `{ name: 'print', path: '/print' }` — no `:no` — and `apps/deck-template/
+  package.json`'s `export` script runs bare `slidev export`, whose one-piece PDF generator visits
+  exactly that route. On `/print`, `hasPrimarySlide` is false, so `useNav().currentPage` reads `1`
+  for EVERY slide simultaneously — `show` evaluated `1 > 1` as false on every page, and the
+  exported PDF carried no chrome at all. `/overview` is the same shape, param-less.
+
+  `injectionCurrentPage` is what SlideWrapper.vue actually provides PER SLIDE regardless of which
+  route rendered it — `provideLocal(injectionCurrentPage, ref(props.route.no))`
+  (@slidev/client/internals/SlideWrapper.vue:30) — exported from the same `constants.ts` module
+  `injectionFrontmatter` already comes from. `total` and `slides` stay on `useNav()`: those really
+  are deck-wide, not per-route.
+*/
+import { computed, inject } from 'vue';
+import { useNav } from '@slidev/client';
+import { injectionCurrentPage, injectionFrontmatter } from '@slidev/client/constants.ts';
+import deckTokens from '@humanforest/tokens/deck/deck.json';
+import { deriveSection } from './section.js';
+import { chromeShows, coBrandFitted, darkChromeAt, darkChromeParts, darkRegister } from './notch.js';
+import { backgroundStyle } from './components/backgrounds.js';
+
+const { total, slides } = useNav();
+const frontmatter = inject(injectionFrontmatter, {});
+// Falls back to a ref(1), not a bare 1 — this is read as `currentPage.value` everywhere below,
+// and SlideWrapper.vue always provides a real ref in practice; the fallback only matters for a
+// component rendered completely outside a SlideWrapper (never happens in this theme, but inject's
+// own default must still be the same shape as the real value or `.value` throws).
+const currentPage = inject(injectionCurrentPage, computed(() => 1));
+
+// Same opt-out as slide-bottom.vue, and the same slide-1 hide — a cover slide carries no page
+// number worth reading and can never have a divider behind it. The predicate itself lives in
+// ./notch.js now, not because this file needed it moved but because split.vue needs the SAME
+// answer: a panel only cuts a notch when there is actually a mark to seat in it (task-15-brief.md's
+// own named failure case — a notch on a `chrome: false` slide is a hole with nothing in it).
+const show = computed(() => chromeShows(frontmatter, currentPage.value));
+
+/*
+  ★★ THE CHROME OPTS ITSELF INTO THE DARK REGISTER, because nothing else can put it there.
+
+  `deck-dark` lands on `.slidev-layout` — that is where both `class: deck-dark` and the layouts'
+  `dark` prop write it — and SlideWrapper renders this chrome as a SIBLING of the layout, not a
+  descendant. So every --deck-* role inside the chrome kept resolving on the LIGHT register while
+  the slide beside it was dark. Measured on a `dark: true` slide before this: the page pill painted
+  forest-700 with white ink, identical to its light-register self.
+
+  Reading the same frontmatter this component already injects and stamping the class on its own root
+  is the only place the two can be reconciled without moving `deck-dark` onto the page element,
+  which no layout can reach.
+*/
+// Delegated to notch.js: a cover can resolve a dark ground from its VARIANT without saying so in
+// frontmatter, and this row is a sibling of the layout so it cannot read the classes that resolution
+// lands as. See darkRegister() — the same module, and the same reason, as darkChromeParts below.
+const isDarkRegister = computed(() => darkRegister(frontmatter));
+// …and the HALVES. A bleeding `panelDark` panel is dark under one end of this row and light under
+// the other, so the register lands per end rather than on the row. See darkChromeParts().
+const darkParts = computed(() => darkChromeParts(frontmatter).top);
+
+/*
+  ★ THE MIRROR — chrome sits on the TEXT side, the mark sits on the PANEL side.
+
+  Jose: "if text is left or right, the notch position should adapt (and move the page to the other
+  side, along with the confidenciality chip)". `flip` is frontmatter, so this component can read it
+  exactly the way it already reads `chrome` — no new plumbing and no coupling to split.vue, which
+  reads the same key as its own prop and cuts its notch on the opposite side of the slide.
+
+  ★ THAT MIRROR IS GONE. It flipped the row on a `flip: true` split so the mark could sit in the
+  notch cut from the figure's top-left corner. The mark is fixed top-right now and the notch is only
+  cut where it can reach — see the note above hasNotch in ./notch.js for the reasoning and what it
+  cost. What is left here is one arrangement, so this file no longer computes a side at all.
+*/
+// The arrangement is FIXED: pills left, mark right, on every slide. It used to flip on a
+// `flip: true` split so the mark could sit in the notch cut from the figure's top-left corner —
+// see the note above hasNotch in ./notch.js for why that went and what it cost.
+
+
+const section = computed(() => deriveSection(slides.value, currentPage.value));
+// Only the section rides in the BadgeStrip now. The page number is a CIRCLE, which is a different
+// geometry from a text pill (equal on both axes, sized by its own line box rather than by its
+// content's width), so it cannot be one of BadgeStrip's items without either stretching for a
+// 3-digit number or clipping one. It keeps BadgeStrip's tone pair and type role so the two still
+// read as one family — see .deck-page-dot below.
+const sectionLabels = computed(() => [section.value].filter(Boolean));
+
+// ★ THE MARK'S SIZE IS A TOKEN NOW, read rather than restated (task-15-brief.md). It used to be a
+// literal here, on the reasoning that Logo's `size` prop takes a plain number (cover.vue :size="72",
+// end.vue :size="88") and sets an SVG geometry scale rather than a CSS box, so no --deck-* property
+// had the right shape. That reasoning held while this component was the only thing that cared. It
+// no longer is: split.vue cuts a notch sized from this exact number, and a value only one of the two
+// can see is precisely how a cut-out and its occupant drift apart. deck.json is the same generated
+// artefact --deck-chrome-mark is emitted from, so the mark the chrome DRAWS and the mark the notch
+// is CUT FOR cannot disagree — change MARK_PX in scripts/deck.ts and both move.
+const MARK_SIZE = deckTokens.chrome.markPx;
+
+/*
+  ★ CO-BRANDING — `companion:` in a slide's own frontmatter.
+
+  THE OCCUPANT IS COMPUTED, NOT DRAWN AND THEN MEASURED. ./notch.js's coBrand() is a pure function
+  of the frontmatter plus deck.json's own chrome numbers, and split.vue/stack.vue call the SAME
+  function for the same slide — so the box this component draws and the cut those layouts make are
+  the same width by construction, not by two files agreeing to use the same literal. Nothing here
+  reads a rendered size back, which is what lets the mask be correct on the first frame.
+
+  --deck-notch-occupant-w is set INLINE, and ONLY when there is a companion. The escape hatch for
+  the width is a `class:` on the slide overriding the property, and an inline style on this element
+  outranks one. No companion, no declaration, so that override still reaches.
+
+  The HEIGHT never moves — a co-brand lockup shares ONE height
+  (packages/ui/src/logo/FSubLogo.vue's own rule, which sets both halves at the wordmark's height
+  and measures only the gap between them), so a companion's mark is as tall as the Forest mark and
+  only the width grows.
+
+  ⚠ IT IS `object-fit: cover`, NOT `contain`. The square and its corner are the whole point of the
+  pairing, and `contain` letterboxes a non-square source inside that square, which puts the ragged
+  silhouette back. Whatever the file is, it is covered into a mark-sized tile so the two read as one
+  lockup.
+*/
+const companion = computed(() => coBrandFitted(frontmatter, currentPage.value, deckTokens));
+/* The alt text is the author's `companionName`. The fallback is deliberately vague because the
+   theme cannot know what the file depicts — a partner's logo, an app icon, a customer's face — and
+   a specific wrong alt is worse than a generic right one. Name it. */
+const companionLabel = computed(() => frontmatter?.companionName || 'Companion mark');
+// Undefined — not an empty object and not a `null` value — when there is no companion: Vue drops an
+// undefined :style binding entirely, where `{ '--x': null }` still writes an empty declaration.
+const occupantStyle = computed(() =>
+  companion.value ? { '--deck-notch-occupant-w': `${companion.value.occupantPx}px` } : undefined,
+);
+</script>
+
+<template>
+  <div v-if="show" :class="['deck-chrome-top', isDarkRegister ? 'deck-dark' : '']">
+    <!-- The page number LEFT this row (task: "the page number i think it can go at the bottom, other
+         extreme of the confidential chip"). It lives in slide-bottom.vue now, paired against the
+         confidentiality pill across the foot of the slide. What stays here is the section, which is
+         the one label a reader looks UP for — where they are, not how far in. -->
+    <div class="deck-chrome-pills" :class="darkChromeAt(darkParts, 'left') ? 'deck-dark' : ''">
+      <BadgeStrip v-if="sectionLabels.length" :items="sectionLabels" chrome />
+    </div>
+    <!-- The occupant. A BOX, not a bare mark — see .deck-chrome-mark below. Forest always leads,
+         and now so does the position: the mark holds the right-hand end of this row on every slide.
+         The attribute stays rather than being folded into the class, because useNotchCuts.js reads
+         the rendered corner rather than being told one, and a literal is the honest way to say a
+         value no longer varies. -->
+    <MarkPair
+      class="deck-chrome-mark"
+      :class="darkChromeAt(darkParts, 'right') ? 'deck-dark' : ''"
+      data-mark-side="right"
+      :style="occupantStyle"
+      :src="companion?.src ?? ''"
+      :label="companionLabel"
+      :size="MARK_SIZE"
+    />
+  </div>
+</template>
+
+<style scoped>
+.deck-chrome-top {
+  position: absolute;
+  /* task-14-brief.md — chrome is inset --deck-inset-chrome (36px, task-14b-brief.md's revision of
+     the original 40px/one-grid-unit figure) on every edge it touches, uniform with
+     slide-bottom.vue's pill and with the mark's own corner. Was --deck-space-3 (24px) top /
+     grid*2.5 (100px) sides — two different numbers for one kind of content (furniture); now one
+     token, one meaning. See base.css's `.slidev-layout` comment and scripts/deck.ts's INSET
+     comment for the full two-track reasoning this is half of. */
+  top: var(--deck-inset-chrome);
+  left: var(--deck-inset-chrome);
+  right: var(--deck-inset-chrome);
+  display: flex;
+  /* flex-START, not centre. The row is the MARK's height (72), the section pill is 49, so centring
+     put the pill's top at 47.5 — 11.5px below the mark's own 36. Invisible on a bare slide; obvious
+     the moment the pill sits on a stack band, whose top edge is also 36 and gives the eye a hard
+     line to judge against. Reported by eye: "why this sits not at the same level? i think it should
+     be 36 px". Top-aligning makes one shared edge at --deck-inset-chrome for the mark, the pill and
+     any panel or band below them, which is the thing the inset system is for. */
+  align-items: flex-start;
+  justify-content: space-between;
+  /* The band is the MARK's height, floor — so the mark's own top stays at --deck-inset-chrome (the
+     point split.vue and stack.vue cut their notch against) whatever else is in the row. A `min-`,
+     not a fixed height, because the documented escape hatch lets a slide override
+     --deck-notch-occupant-h for a taller occupant, and that one is meant to grow the band. */
+  min-height: var(--deck-chrome-mark);
+  z-index: 20;
+  /* Click-through, like slide-bottom.vue's chrome — this is a running label, never a control. */
+  pointer-events: none;
+}
+/*
+  THE OCCUPANT BOX — the mark's own size, expressed the way the notch reads it.
+
+  This is a wrapper rather than the class on <Logo> itself because the notch and the mark have to
+  agree on ONE box: split.vue cuts `occupant + gap`, reading the same two custom properties this
+  reads, so overriding --deck-notch-occupant-w/-h on a slide resizes the cut and its occupant
+  together — one mark, a forest+companion pair, an image, a content block. The `size` prop still
+  passes the token's own number so the SVG's intrinsic geometry matches the default box; the box is
+  what the notch is measured against.
+
+  `height: 100%; width: auto` on the mark, and the box aligned to its OUTER edge: a wider occupant
+  is wider because it holds MORE, not because the mark stretches. The default is a square box
+  holding a square mark, where none of this is visible — it only matters once the box is not.
+*/
+.deck-chrome-mark {
+  flex: none;
+  /* The row itself — display, alignment and the gap between the two halves — is MarkPair's, which
+     derives that gap from the `size` this component passes. --deck-chrome-pair-gap is still the
+     number both readers of the CUT use: ./notch.js's coBrand() adds it to reach the occupant width
+     and scripts/deck.ts adds it again to prove a forest+companion pair fits the narrowest ratio.
+     MarkPair reads the same two chrome numbers out of deck.json, so the lockup and the cut made for
+     it cannot drift. */
+  width: var(--deck-notch-occupant-w, var(--deck-chrome-mark));
+  height: var(--deck-notch-occupant-h, var(--deck-chrome-mark));
+}
+/* Only 'right' is emitted now. The 'left' rule went with the mirror rather than being left behind
+   as a selector nothing can match. */
+.deck-chrome-mark[data-mark-side='right'] { justify-content: flex-end; }
+/*
+  ★★ THE PARTNER'S TILE IS NOT DRAWN HERE ANY MORE — components/MarkPair.vue draws it, and this
+  component passes the size. The rounded square, the ring in `currentColor`, the `cover` fit and the
+  gap between the two halves were all stated in this file with the chrome's own fixed px tokens;
+  cover.vue then drew the same pair twice more, and its poster — at 120px — inherited a corner and a
+  ring computed for a 72px tile. The geometry is one component's now, derived from `size`, and this
+  file keeps only what is about the CHROME: where the box sits, how wide the notch thinks it is, and
+  which register it is in.
+*/
+
+.deck-chrome-top.deck-dark,
+.deck-chrome-pills.deck-dark,
+.deck-chrome-mark.deck-dark,
+.deck-chrome-confidential.deck-dark {
+  background: transparent;
+}
+</style>