@import "tailwindcss";
@import "dropzone/dist/dropzone.css";
/* Through this entry, not an esbuild import from application.js: esbuild's
   own build script (package.json) writes to app/assets/builds/application.css
   too, and a CSS import from a JS entry point would make it emit its own
   file over Tailwind's output at that same path. */
@import "@fnix/lexxy-mathjax/styles";
@plugin "@iconify/tailwind4";

@plugin "flyonui" {
  themes: light --default, dark --prefersdark, gourmet;
}

/* Required for FlyonUI's JS components (overlay/drawer, dropdown, …): the first
   registers their custom variants such as `overlay-open:`, the second scans the
   classes FlyonUI applies from JS at runtime (e.g. the overlay backdrop).
   Without these the drawer's slide transition is never generated, so closing it
   fires no `transitionend` and FlyonUI never removes the backdrop. */
@import "flyonui/variants.css";
@source "../../../node_modules/flyonui/dist/index.js";

@plugin "flyonui/theme" {
  name: gourmet;
  font-family: "Rubik";
}

@layer utilities {
  @media (any-hover: hover) and (min-width: 640px) {
    .reader-edit-action {
      opacity: 0;
    }

    .group:hover .reader-edit-action,
    .reader-edit-action:focus-visible {
      opacity: 1;
    }
  }
}

/* Reserves a lazy reader image's box before it loads, so the panel doesn't
   reflow once it does. Two overrides, both required — confirmed live (a
   figure's img sat at 0×0 with only the first rule, and only the width/
   height attributes themselves, until the second rule was added):

   1. lexxy sets `img { inline-size: auto }` under .lexxy-content,
      unlayered. That's an explicit author declaration, so it always beats
      the width attribute app/views/active_storage/blobs/_blob.html.erb
      sets on the img to reserve its box — width= is only a presentational
      hint, which loses to any real CSS rule regardless of layering.

   2. Overriding just the img isn't enough, because lexxy also sets
      `:where(.attachment) { inline-size: fit-content }` on the *figure*
      wrapping it — sized to fit its content, i.e. the img. Before the img
      loads it has no natural size, and its own width is a percentage (see
      #1), which doesn't contribute to a fit-content calculation — so the
      figure collapses to 0 width, which then makes the img's `width: 100%`
      100% of 0. Forcing the figure to fill its container instead breaks
      that circularity: with a definite width to resolve against, the
      browser can size the still-unloaded img from its width/height HTML
      attributes (which it maps internally to an aspect-ratio) once at
      least one axis is definite — no explicit `aspect-ratio` CSS needed.

   Both left unlayered (not folded into @layer utilities above) so they
   outrank lexxy's on layer precedence rather than relying on specificity —
   an unlayered declaration always wins over a layered one regardless of
   selector weight. The blob partial pairs this with a per-image inline
   style="max-width: …px" so the image still can't stretch past its own
   render width or upscale past the original.

   position: relative is redundant with lexxy's own `:where(.attachment)`
   rule today, but declared here explicitly rather than left implicit: the
   blob partial's skeleton placeholder positions itself absolute/inset-0
   against this element, and that would silently break if lexxy ever
   dropped its own declaration. */
.lexxy-content .attachment--preview {
  inline-size: 100%;
  position: relative;
}

.lexxy-content .attachment--preview img {
  width: 100%;
}

/* MathJax v4's displayOverflow defaults to "overflow" — a display equation
   wider than its box is left to overflow rather than scaled or
   line-broken. Without this, that overflow escapes onto the reader panel
   (app/views/documents/show.html.erb's overflow-y-auto panels), scrolling
   the whole panel — including the surrounding text — sideways instead of
   just the equation. div[data-latex], not .lexxy-math--display: the
   package's own README names the tag as the only reliable display signal,
   and content from Datalab (lib/datalab/markdown.rb) stores the plain
   lexxy-math class without the --display modifier. */
.lexxy-content div[data-latex] {
  overflow-x: auto;
}

/* Maps @fnix/lexxy-mathjax's equation editor dialog (--lexxy-math-* custom
   properties, styles/lexxy-mathjax.css) onto this app's actual Gourmet theme
   tokens, so the dialog reads as part of the app rather than a foreign popup.
   Layered, unlike the overrides above: these don't compete with anything —
   nothing else in the app sets a --lexxy-math-* name, so there's no cascade
   fight to win by staying unlayered.

   --lexxy-math-backdrop-color mirrors FlyonUI's own overlay scrim exactly
   (bg-base-300/60, built by HSOverlay at flyonui's overlay plugin) rather than
   approximating it, so this dialog's backdrop matches every other overlay in
   the app. --lexxy-math-dialog-shadow mirrors FlyonUI's .modal-content shadow
   recipe (also tinted by base-300) for the same reason.

   --lexxy-math-input-radius uses --radius-box (0.75rem), not --radius-field
   (2rem, what every other input/textarea/btn in the app actually uses) —
   2rem pill-rounding reads wrong on a multi-row textarea at that aspect
   ratio, and --radius-box keeps the textarea/preview/buttons the same shape
   as the dialog they sit inside.

   Canvas/CanvasText/Field/FieldText — the package's own defaults — are CSS
   system colors that already track OS/browser dark mode on their own. This
   app doesn't use that: dark mode is declared in the theme plugin config
   below but never wired to a toggle, and data-theme="gourmet" is hardcoded
   on <html> (see layouts/application.html.erb) — so every property below
   resolves to a fixed Gourmet token instead, matching how the rest of the
   app is built rather than adding dark-mode logic nothing else here has. */
@layer utilities {
  :root {
    --lexxy-math-backdrop-color: color-mix(in oklab, var(--color-base-300) 60%, transparent);
    --lexxy-math-dialog-bg: var(--color-base-100);
    --lexxy-math-dialog-border-color: var(--color-base-300);
    --lexxy-math-dialog-radius: var(--radius-box);
    --lexxy-math-dialog-shadow:
      0 20px 25px -5px color-mix(in oklab, var(--color-base-300) 20%, transparent),
      0 8px 10px -6px color-mix(in oklab, var(--color-base-300) 20%, transparent);
    --lexxy-math-text-color: var(--color-base-content);
    --lexxy-math-muted-color: color-mix(in oklab, var(--color-base-content) 70%, transparent);
    --lexxy-math-input-bg: var(--color-base-100);
    --lexxy-math-input-text-color: var(--color-base-content);
    --lexxy-math-input-border-color: var(--color-base-300);
    --lexxy-math-input-radius: var(--radius-box);
    --lexxy-math-focus-color: var(--color-primary);
    --lexxy-math-focus-content-color: var(--color-primary-content);
    --lexxy-math-error-color: var(--color-error);
  }
}