@michaelyagi/shoji 0.1.0-alpha.6

package/dist/esm/index.css

@@ -0,0 +1,475 @@
+/**
+ * Core theme tokens (DESIGN.md §9). Dark is the default theme; `.shoji-light`
+ * overrides to light. No hardcoded colors/sizes elsewhere in JS or CSS —
+ * everything routes through these custom properties.
+ */
+:root {
+  /* .shoji-outer's own page-level z-index — relative to the rest of the
+     host page, not to anything inside the lightbox. Real pages routinely
+     put sticky navbars/sidebars/toast containers at 1000-9999, so this
+     needs real headroom, not the small internal scale below (which only
+     orders backdrop/slides/overlay/toolbar/toast *against each other*,
+     inside the stacking context .shoji-outer's own z-index establishes). */
+  --shoji-z-base: 9000;
+
+  --shoji-z-backdrop: 0;
+  --shoji-z-slides: 10;
+  --shoji-z-overlay: 20;
+  --shoji-z-toolbar: 30;
+  --shoji-z-toast: 40;
+
+  --shoji-color-bg: #0b0b0d;
+  --shoji-color-fg: #f5f5f5;
+  --shoji-color-accent: #4da3ff;
+  --shoji-color-backdrop: rgba(0, 0, 0, 0.92);
+  --shoji-color-toolbar-bg: rgba(20, 20, 22, 0.85);
+  --shoji-color-disabled: rgba(245, 245, 245, 0.35);
+
+  --shoji-focus-ring: 2px solid var(--shoji-color-accent);
+  --shoji-progress: var(--shoji-color-accent);
+
+  --shoji-spacing-sm: 0.5rem;
+  --shoji-spacing-md: 1rem;
+  --shoji-spacing-lg: 1.5rem;
+
+  --shoji-easing: cubic-bezier(0.4, 0, 0.2, 1);
+  --shoji-duration: 300ms;
+  /* Caps how tall the caption box can grow before it scrolls internally —
+     an unbounded caption on a long string would otherwise creep up over a
+     video slide's native control bar underneath it (bottom-left, same
+     corner), silently swallowing scrub/volume/fullscreen clicks with no
+     way to reach them. `min()` also bounds it on a short/wide dialog
+     (mobile landscape), where a `rem`-only cap could still eat most of
+     the available height. */
+  --shoji-caption-max-height: min(8rem, 30%);
+  /* Reserved space at the top of a provider embed (YouTube etc.) so its own
+     hover-revealed title bar never sits under Shoji's toolbar — matches the
+     toolbar's own rendered height (44px button + top/bottom padding).
+     Permanent, not tied to the toolbar's auto-hide state, so the video
+     never resizes as the toolbar fades in/out. HTML5 video has no top-of-
+     player UI at all, so it's untouched. */
+  --shoji-provider-video-top-inset: calc(44px + 2 * var(--shoji-spacing-sm));
+  /* DESIGN.md §2.4 — the gesture engine's own documented default easing for
+     drag-to-navigate/drag-to-close settle animations specifically (a snap
+     tuned for "released mid-motion," distinct from --shoji-easing's
+     open/close/zoom-transition curve). */
+  --shoji-momentum-easing: cubic-bezier(0.2, 0, 0, 1);
+
+  /* System-font stack: no webfont download, renders instantly, looks native
+     (San Francisco / Segoe UI / Roboto) on every platform. */
+  --shoji-font-family:
+    -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, Helvetica, Arial, sans-serif,
+    'Apple Color Emoji', 'Segoe UI Emoji';
+}
+
+.shoji-light {
+  --shoji-color-bg: #fafafa;
+  --shoji-color-fg: #111111;
+  --shoji-color-backdrop: rgba(255, 255, 255, 0.96);
+  --shoji-color-toolbar-bg: rgba(255, 255, 255, 0.9);
+  --shoji-color-disabled: rgba(17, 17, 17, 0.35);
+}
+
+@media (prefers-reduced-motion: reduce) {
+  :root {
+    --shoji-duration: 0ms;
+  }
+}
+
+/* Lightbox structure (DESIGN.md §2.3 slides, §2.6 dialog). Built lazily on first open(). */
+.shoji-outer {
+  display: none;
+  position: fixed;
+  inset: 0;
+  z-index: var(--shoji-z-base);
+}
+
+.shoji-outer.shoji-open {
+  display: block;
+}
+
+.shoji-backdrop {
+  position: absolute;
+  inset: 0;
+  z-index: var(--shoji-z-backdrop);
+  background: var(--shoji-color-backdrop);
+}
+
+.shoji-dialog {
+  position: relative;
+  z-index: var(--shoji-z-slides);
+  display: flex;
+  flex-direction: column;
+  height: 100%;
+  color: var(--shoji-color-fg);
+  font-family: var(--shoji-font-family);
+  outline: none;
+  /* DESIGN.md §2.4 — the gesture engine owns horizontal/vertical drag on
+     this element; without this, touch browsers intercept the same gesture
+     for native scroll/pull-to-refresh/back-navigation before JS ever sees
+     enough movement to lock a direction. Buttons/video inside remain
+     interactive regardless (this is about implicit browser gesture
+     handling, not pointer-events). */
+  touch-action: none;
+}
+
+.shoji-toolbar {
+  position: absolute;
+  inset: 0 0 auto 0;
+  z-index: var(--shoji-z-toolbar);
+  display: flex;
+  justify-content: space-between;
+  padding: var(--shoji-spacing-sm);
+  pointer-events: none;
+  /* Reported from real usage: the Zoom plugin's frequent scale() updates on
+     the photo (a sibling, not a descendant) could show as GPU tile-seam
+     artifacts (thin lines) through the toolbar's own semi-transparent,
+     border-radius buttons — the same class of rendering quirk already noted
+     for progressive image decode. Promoting the toolbar to its own stable
+     compositing layer, decoupled from the photo's repaints, avoids it. */
+  will-change: transform;
+}
+
+/* DESIGN.md §3 — ctx.ui.toolbar(slot, ...) inserts plugin buttons into these;
+   pointer-events re-enabled per-slot (not per-button) so gaps between slots
+   stay click-through even once a slot has content. `flex-wrap: wrap` (not
+   `overflow-x: auto`) is deliberate: several plugins loaded together on a
+   narrow/mobile viewport can add up to more 44px buttons than the width
+   allows (CLAUDE.md's own touch-target size, non-negotiable), and this
+   project treats horizontal scroll as something to design around, not
+   reach for (see the layout plugin's masonry `orientation: 'horizontal'`,
+   which was rebuilt specifically to avoid it) — wrapping to a second row
+   keeps every button reachable by a tap with no sideways scroll gesture
+   anywhere in the lightbox chrome either. */
+.shoji-toolbar-slot {
+  display: flex;
+  flex-wrap: wrap;
+  align-items: center;
+  gap: var(--shoji-spacing-sm);
+  pointer-events: auto;
+  max-width: 45%;
+}
+
+.shoji-toolbar-left {
+  justify-content: flex-start;
+}
+
+.shoji-toolbar-right {
+  justify-content: flex-end;
+}
+
+.shoji-close,
+.shoji-nav,
+.shoji-toolbar-button {
+  appearance: none;
+  border: none;
+  padding: 0;
+  width: 44px;
+  height: 44px;
+  border-radius: 50%;
+  display: flex;
+  align-items: center;
+  justify-content: center;
+  background: rgba(0, 0, 0, 0.4);
+  color: var(--shoji-color-fg);
+  cursor: pointer;
+}
+
+.shoji-close:hover,
+.shoji-nav:hover,
+.shoji-toolbar-button:hover {
+  background: rgba(0, 0, 0, 0.6);
+}
+
+.shoji-close:focus-visible,
+.shoji-nav:focus-visible,
+.shoji-toolbar-button:focus-visible {
+  outline: var(--shoji-focus-ring);
+  outline-offset: 2px;
+}
+
+.shoji-nav {
+  position: absolute;
+  top: 50%;
+  transform: translateY(-50%);
+  z-index: var(--shoji-z-toolbar);
+}
+
+.shoji-nav-prev {
+  left: var(--shoji-spacing-md);
+}
+
+.shoji-nav-next {
+  right: var(--shoji-spacing-md);
+}
+
+.shoji-nav:disabled {
+  opacity: 0.3;
+  cursor: default;
+  pointer-events: none;
+}
+
+.shoji-close[hidden],
+.shoji-nav[hidden],
+.shoji-toolbar-button[hidden] {
+  display: none;
+}
+
+/* DESIGN.md §2.3 — while the active slide's own content is still loading,
+   feature/plugin toolbar buttons (zoom, rotate, fullscreen, autoplay, any
+   custom plugin's own button) dim and stop responding, since they'd
+   otherwise act on content about to be replaced. Deliberately scoped to
+   `.shoji-toolbar-button` only — `.shoji-close`/`.shoji-nav` are different
+   classes, so closing and navigating are never blocked by a slow image.
+   `pointer-events: none` here is the mouse half; Gallery.ts's matching
+   `tabIndex = -1` is the keyboard half (this alone wouldn't stop
+   Enter/Space activating an already-focused button). */
+.shoji-outer.shoji-slide-loading .shoji-toolbar-button {
+  opacity: 0.3;
+  cursor: default;
+  pointer-events: none;
+}
+
+.shoji-slides {
+  position: relative;
+  flex: 1;
+  overflow: hidden;
+}
+
+.shoji-slide {
+  position: absolute;
+  inset: 0;
+  display: flex;
+  align-items: center;
+  justify-content: center;
+  /* transform (translateX per pool offset) is set inline by SlideManager */
+}
+
+.shoji-slide-media {
+  /* Definite size (not max-width/max-height alone) so the img's own
+     percentage-based max-width/max-height below has something concrete to
+     resolve against — otherwise it sizes to the image's natural dimensions
+     instead of being contained, and object-fit: contain never engages. */
+  width: 100%;
+  height: 100%;
+  display: flex;
+  align-items: center;
+  justify-content: center;
+  /* Anchors .shoji-video-play-overlay's absolute positioning to this box
+     specifically, not implicitly to whichever positioned ancestor happens
+     to be next up (currently .shoji-slide, coincidentally the same size —
+     explicit here so that stays true even if that ever changes). */
+  position: relative;
+}
+
+.shoji-slide-img,
+.shoji-slide-video {
+  display: block;
+  max-width: 100%;
+  max-height: 100%;
+  object-fit: contain;
+}
+
+/* max-width/max-height above only ever *cap* size — a real photo is normally
+   bigger than the slide area, so that's correct. A low-res open() placeholder
+   (§2.3) is the opposite case: deliberately small, so it needs to be forced
+   up to fill the frame (blurry, on purpose) instead of rendering at its own
+   tiny natural size. object-fit: contain (inherited above) still letterboxes
+   it within that forced box, just per the thumbnail's own aspect ratio. */
+.shoji-slide-open-placeholder {
+  width: 100%;
+  height: 100%;
+}
+
+/* DESIGN.md §4-video — a provider's embed (an <iframe>, typically) has no
+   natural size Shoji can measure the way a decoded image/video does, so
+   this just fills whatever box it's given; supply item.width/height for a
+   correctly-shaped box (applyAspect() sets aspect-ratio on the slide-media
+   container itself from those), same as any other slide. */
+.shoji-slide-provider-video {
+  width: 100%;
+  height: 100%;
+  box-sizing: border-box;
+  padding-top: var(--shoji-provider-video-top-inset);
+}
+
+.shoji-slide-provider-video[hidden] {
+  display: none;
+}
+
+.shoji-slide-provider-video iframe {
+  display: block;
+  width: 100%;
+  height: 100%;
+  border: 0;
+}
+
+/* A paused video's own play affordance — native browser styling for this
+   varies too much to rely on alone (some show a big centered play icon,
+   some don't). Faint/translucent, same visual language as the toolbar's
+   own round icon buttons, just bigger — a primary, hard-to-miss affordance,
+   not a small chrome control. Deliberately not gated by any GalleryOptions
+   flag (purely presentational — hiding it changes nothing functionally,
+   the video is still clickable either way); a host not wanting it just
+   overrides this selector in their own CSS. */
+.shoji-video-play-overlay {
+  position: absolute;
+  top: 50%;
+  left: 50%;
+  transform: translate(-50%, -50%);
+  width: var(--shoji-video-overlay-size, 64px);
+  height: var(--shoji-video-overlay-size, 64px);
+  border-radius: 50%;
+  border: none;
+  padding: 0;
+  display: flex;
+  align-items: center;
+  justify-content: center;
+  background: var(--shoji-video-overlay-bg, rgba(0, 0, 0, 0.4));
+  color: var(--shoji-video-overlay-color, var(--shoji-color-fg));
+  cursor: pointer;
+}
+
+.shoji-video-play-overlay[hidden] {
+  display: none;
+}
+
+/* DESIGN.md §2.5 — the temporary clone SlideTransition animates the
+   outgoing slide's content out on. Sits above the normal (unpositioned
+   z-index) pool slots by DOM order alone, but z-index is set explicitly
+   here rather than relied on implicitly, matching how every other overlay
+   layer in this file states its stacking intent up front. Not interactive
+   (it's a decorative clone mid-removal) and never receives its own size —
+   it fills `.shoji-slides` exactly like the real `.shoji-slide` it's a
+   snapshot of, so the cloned `.shoji-slide-media` inside it (already
+   `width/height: 100%`) lines up pixel-for-pixel with no extra CSS needed. */
+.shoji-slide-ghost {
+  position: absolute;
+  inset: 0;
+  z-index: 1;
+  pointer-events: none;
+}
+
+.shoji-slide-placeholder {
+  color: var(--shoji-color-disabled);
+}
+
+/* DESIGN.md §2.3 — shown in place of a slide's content while it's still
+   decoding/loading (outside the `preload` window, where nothing was ready
+   ahead of time). CSS-only rotation (no JS-driven layout, per CLAUDE.md);
+   disabled under prefers-reduced-motion the same as every other animation
+   here, rather than left spinning regardless. */
+.shoji-slide-spinner {
+  width: var(--shoji-spinner-size, 40px);
+  height: var(--shoji-spinner-size, 40px);
+  border-radius: 50%;
+  border: var(--shoji-spinner-thickness, 3px) solid var(--shoji-color-disabled);
+  border-top-color: var(--shoji-color-accent);
+  animation: shoji-spin 0.8s linear infinite;
+}
+
+@keyframes shoji-spin {
+  to {
+    transform: rotate(360deg);
+  }
+}
+
+@media (prefers-reduced-motion: reduce) {
+  .shoji-slide-spinner {
+    animation: none;
+  }
+}
+
+/* A normal flex item within .shoji-toolbar-left (not independently
+   positioned) — .shoji-slides still gets the full dialog height either way,
+   no reserved gutter at top or bottom, since the toolbar itself overlays the
+   slides rather than pushing them down. Flowing alongside whatever else is
+   in that slot (e.g. a plugin's ctx.ui.toolbar('left', ...) button) keeps it
+   from overlapping and stealing clicks the way independent absolute
+   positioning did. */
+.shoji-counter {
+  padding: 0.25rem 0.6rem;
+  border-radius: 999px;
+  background: rgba(0, 0, 0, 0.4);
+  font-size: 0.875rem;
+  white-space: nowrap;
+}
+
+.shoji-counter[hidden] {
+  display: none;
+}
+
+.shoji-caption {
+  position: absolute;
+  bottom: var(--shoji-spacing-md);
+  left: var(--shoji-spacing-md);
+  z-index: var(--shoji-z-toolbar);
+  width: fit-content;
+  max-width: calc(100% - 2 * var(--shoji-spacing-md));
+  max-height: var(--shoji-caption-max-height);
+  overflow-y: auto;
+  overscroll-behavior: contain;
+  padding: var(--shoji-spacing-sm) var(--shoji-spacing-md);
+  border-radius: 8px;
+  background: var(--shoji-color-toolbar-bg);
+  text-align: left;
+}
+
+/* A real bug: height-capping the caption (above) still isn't enough on its
+   own — a video that fills most of the dialog leaves little to no
+   letterboxing gap, so even a short caption's opaque background can land
+   directly on the native control bar underneath it (same corner). Letting
+   clicks pass straight through the caption on a video slide (Gallery.ts
+   toggles this class from `item.video`, HTML5 or a provider like YouTube
+   alike) is what actually guarantees the controls stay reachable, not just
+   "usually clear of them." Re-enabled on any real child element so a rich
+   HTML caption's own links/buttons (DESIGN.md §2.1) stay clickable — only
+   a plain-string caption (no element children at all) ever fully passes
+   through. Photo slides are untouched: nothing below them needs protecting,
+   so the caption keeps its normal scrollable/selectable behavior there. */
+.shoji-caption--video {
+  pointer-events: none;
+}
+
+.shoji-caption--video > * {
+  pointer-events: auto;
+}
+
+.shoji-caption[hidden] {
+  display: none;
+}
+
+/* DESIGN.md §2.8 — idle auto-hide. Opacity only, never display:none, never
+   removed from the tab order: a hidden-but-focused control stays interactive,
+   just visually faded (see Gallery's isControlFocused() guard). */
+.shoji-toolbar,
+.shoji-nav,
+.shoji-counter,
+.shoji-caption {
+  transition: opacity var(--shoji-duration) var(--shoji-easing);
+}
+
+.shoji-controls-hidden .shoji-toolbar,
+.shoji-controls-hidden .shoji-nav,
+.shoji-controls-hidden .shoji-counter,
+.shoji-controls-hidden .shoji-caption {
+  opacity: 0;
+  pointer-events: none;
+}
+
+/* !important: wins over any plugin's own cursor styling (e.g. zoom.css's
+   zoom-in/grab affordances) without core needing to know that plugin's
+   selectors — the hidden state means nothing should suggest interactivity. */
+.shoji-controls-hidden,
+.shoji-controls-hidden * {
+  cursor: none !important;
+}
+
+.shoji-live-region {
+  position: absolute;
+  width: 1px;
+  height: 1px;
+  overflow: hidden;
+  clip: rect(0 0 0 0);
+  white-space: nowrap;
+}

package/dist/esm/index.d.ts

@@ -0,0 +1,32 @@
+import { Gallery } from './core';
+export type { GalleryItem, GalleryOptions, GalleryEvents, MediaSource, VideoDescriptor, Unsubscribe, } from './core';
+export type { ShojiPlugin, PluginContext, VideoProviderRenderer } from './core/plugin';
+/**
+ * `new Shoji(el, options)` — the UMD global (CLAUDE.md: "UMD build exposes
+ * exactly one global"). The default export *is* the constructor, not a
+ * namespace object, so `<script src="shoji.js">` usage matches the default
+ * import used by bundler/ESM consumers. Headless/tree-shaking consumers who
+ * want the class as a named import can pull it from the `shoji/core`
+ * subpath instead.
+ *
+ * Official plugins are attached as static properties (`Shoji.Autoplay`) so
+ * the single-file build stays "one global" (CLAUDE.md) while still shipping
+ * every official plugin's code — self-registering, no extra <script> tags —
+ * per CLAUDE.md's single-file distribution requirement. A host opts a
+ * gallery into one with `new Shoji(el, { plugins: [Shoji.Autoplay] })`.
+ * Bundler users who only want to pull in specific plugins' code (tree-shaking
+ * this static attachment away) should import from the `shoji/plugins/*`
+ * subpath instead of this default export.
+ */
+declare const Shoji: typeof Gallery & {
+    Autoplay: import('./core').ShojiPlugin;
+    Layout: import('./core').ShojiPlugin;
+    ActiveThumbnail: import('./core').ShojiPlugin;
+    Fullscreen: import('./core').ShojiPlugin;
+    RotateFlip: import('./core').ShojiPlugin;
+    Video: import('./core').ShojiPlugin;
+    Zoom: import('./core').ShojiPlugin;
+    /** `package.json`'s own version — the single source of truth, read via a named JSON import so a bundler can tree-shake away everything else in package.json (devDependencies, scripts, ...) rather than embedding the whole file. */
+    version: string;
+};
+export default Shoji;

package/dist/esm/index.js

@@ -0,0 +1,24 @@
+import { Gallery } from "./core/index.js";
+import { ActiveThumbnail } from "./plugins/activeThumbnail/index.js";
+import { Autoplay } from "./plugins/autoplay/index.js";
+import { Fullscreen } from "./plugins/fullscreen/index.js";
+import { Layout } from "./plugins/layout/index.js";
+import { RotateFlip } from "./plugins/rotateFlip/index.js";
+import { Video } from "./plugins/video/index.js";
+import { Zoom } from "./plugins/zoom/index.js";
+const version = "0.1.0-alpha.6";
+const Shoji = Object.assign(Gallery, {
+  Autoplay,
+  Layout,
+  ActiveThumbnail,
+  Fullscreen,
+  RotateFlip,
+  Video,
+  Zoom,
+  /** `package.json`'s own version — the single source of truth, read via a named JSON import so a bundler can tree-shake away everything else in package.json (devDependencies, scripts, ...) rather than embedding the whole file. */
+  version
+});
+export {
+  Shoji as default
+};
+//# sourceMappingURL=index.js.map

package/dist/esm/index.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.js","sources":["../../src/index.ts"],"sourcesContent":["import { Gallery } from './core';\nimport { ActiveThumbnail } from './plugins/activeThumbnail';\nimport { Autoplay } from './plugins/autoplay';\nimport { Fullscreen } from './plugins/fullscreen';\nimport { Layout } from './plugins/layout';\nimport { RotateFlip } from './plugins/rotateFlip';\nimport { Video } from './plugins/video';\nimport { Zoom } from './plugins/zoom';\nimport { version } from '../package.json';\n\nimport './styles/shoji.css';\n\nexport type {\n  GalleryItem,\n  GalleryOptions,\n  GalleryEvents,\n  MediaSource,\n  VideoDescriptor,\n  Unsubscribe,\n} from './core';\nexport type { ShojiPlugin, PluginContext, VideoProviderRenderer } from './core/plugin';\n\n/**\n * `new Shoji(el, options)` — the UMD global (CLAUDE.md: \"UMD build exposes\n * exactly one global\"). The default export *is* the constructor, not a\n * namespace object, so `<script src=\"shoji.js\">` usage matches the default\n * import used by bundler/ESM consumers. Headless/tree-shaking consumers who\n * want the class as a named import can pull it from the `shoji/core`\n * subpath instead.\n *\n * Official plugins are attached as static properties (`Shoji.Autoplay`) so\n * the single-file build stays \"one global\" (CLAUDE.md) while still shipping\n * every official plugin's code — self-registering, no extra <script> tags —\n * per CLAUDE.md's single-file distribution requirement. A host opts a\n * gallery into one with `new Shoji(el, { plugins: [Shoji.Autoplay] })`.\n * Bundler users who only want to pull in specific plugins' code (tree-shaking\n * this static attachment away) should import from the `shoji/plugins/*`\n * subpath instead of this default export.\n */\nconst Shoji = Object.assign(Gallery, {\n  Autoplay,\n  Layout,\n  ActiveThumbnail,\n  Fullscreen,\n  RotateFlip,\n  Video,\n  Zoom,\n  /** `package.json`'s own version — the single source of truth, read via a named JSON import so a bundler can tree-shake away everything else in package.json (devDependencies, scripts, ...) rather than embedding the whole file. */\n  version,\n});\n\nexport default Shoji;\n"],"names":[],"mappings":";;;;;;;;;AAuCA,MAAM,QAAQ,OAAO,OAAO,SAAS;AAAA,EACnC;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA;AAAA,EAEA;AACF,CAAC;"}

package/dist/esm/index2.css

@@ -0,0 +1,22 @@
+/* DESIGN.md §4-autoplay — thin progress bar along the bottom edge, tracking
+   time-to-next-advance for timed (image) slides. Hidden during video slides,
+   where the video's own runtime — not a fixed interval — drives advancement. */
+.shoji-autoplay-progress {
+  position: absolute;
+  left: 0;
+  right: 0;
+  bottom: 0;
+  height: 3px;
+  background: rgba(255, 255, 255, 0.15);
+  z-index: var(--shoji-z-toolbar);
+}
+
+.shoji-autoplay-progress[hidden] {
+  display: none;
+}
+
+.shoji-autoplay-progress-bar {
+  height: 100%;
+  width: 0%;
+  background: var(--shoji-progress);
+}