/* Berezin Web Services — VoidAuth branding. Managed by tf-vps install.sh.
 * Local edits are OVERWRITTEN on the next provision; change the template instead. */

/* Self-hosted Google Sans (subset: Latin + Cyrillic + Hebrew, ~29 KB/weight).
 * Served same-origin from this branding dir to satisfy `font-src 'self'`.
 * font-display:swap so a slow font never blocks the login text from painting. */
@font-face {
  font-family: 'Google Sans';
  src: url('googlesans-regular.woff2') format('woff2');
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}
@font-face {
  font-family: 'Google Sans';
  src: url('googlesans-medium.woff2') format('woff2');
  font-weight: 500;
  font-style: normal;
  font-display: swap;
}
@font-face {
  font-family: 'Google Sans';
  src: url('googlesans-bold.woff2') format('woff2');
  font-weight: 700;
  font-style: normal;
  font-display: swap;
}

/* Make the DEFAULT 'system' theme mode actually follow the OS preference.
 *
 * This is a WORKAROUND FOR AN UPSTREAM BUG (voidauth/voidauth#539), not a
 * preference: VoidAuth's theme is built on CSS light-dark(), which selects its
 * branch from the element's used `color-scheme` — NOT from the
 * prefers-color-scheme media query. Upstream declares color-scheme only inside
 * `body.dark` / `body.light`, and 'system' mode (the default) applies NEITHER
 * class, so nothing declares it, the used value falls back to `normal`, and
 * light-dark() always picks the LIGHT branch. A dark-mode visitor gets a light
 * login page. Verified in a browser with prefers-color-scheme emulated.
 *
 * Declaring both keywords opts the page in to OS-driven selection. The explicit
 * body.dark / body.light overrides keep working: they set a SINGLE keyword on a
 * more specific element, which still wins (also verified). Safe to leave in place
 * even after the upstream fix lands — it becomes redundant, not conflicting. */
:root {
  color-scheme: light dark;
}
