/* Shared mobile-overflow safety net — one canonical set of guardrails sitewide, loaded via
   <link rel="stylesheet" href="/shared-layout-safety.css">. Added 2026-08-03 (see docs/BACKLOG.md's
   "Mobile layout overflow bug" entry) after confirming 0/118 HTML pages declared `overflow-wrap`
   anywhere and 62/118 had no `overflow-x:hidden` on `body` — a single long unbreakable string
   (an email, a job title, an org name) was enough to blow out the whole viewport width on mobile
   instead of wrapping, forcing pinch-zoom to recover.

   Same zero-specificity pattern as /shared-select.css: written with :where() so it never wins a
   fight against a real page-specific rule, even a plain `body { ... }` or `img { ... }` already on
   the page — this file only fills a gap, it never overrides an intentional per-page choice. That's
   what makes it safe to link into every page unconditionally rather than an opt-in per file.

   This file does NOT fix the separate structural min-width/flex-stacking bug in control rows like
   organizacion/miembros.html's `.member-role`/`.btn-approve-small` (two children whose combined
   min-width can't shrink to fit a 390px viewport regardless of overflow-wrap) — that's a real
   component-layout decision, tracked separately in docs/BACKLOG.md, not a missing-CSS-property gap
   this stylesheet is meant to paper over. */

:where(body) {
  overflow-x: hidden;
}

/* Text-bearing elements that can receive variable-length or user-generated content (names, emails,
   job titles, headlines, paragraphs) — allow a long unbreakable run of characters to wrap onto a
   new line instead of forcing the container (and the viewport) wider than it should be. */
:where(p, span, div, a, li, td, th, h1, h2, h3, h4, h5, h6, label, button, blockquote, figcaption) {
  overflow-wrap: break-word;
}

/* Media and embeds should never exceed their container's width on a narrow viewport, regardless of
   the element's own width/height attributes. */
:where(img, svg, video, iframe, table) {
  max-width: 100%;
}

/* Browser autofill ("remembered value" styling, Safari/Chrome) paints its own near-black text
   color and a light yellow/blue background over a field, overriding this site's own `color`/CSS
   variables entirely — a real bug, found 2026-08-11 (seeker/editar.html's newly-redesigned Skills/
   Education cards, reported by Samuel as "why are these fonts showing in black?"). Confirmed via a
   real computed-style check that the page's own CSS was already correct (`color: rgb(244,248,255)`,
   i.e. --white) — the browser's autofill paint was winning anyway, a sitewide gap: 0 files anywhere
   in this codebase neutralized `-webkit-autofill` before this fix, so any dark-themed input/
   textarea/select on any of the 364+ pages linking this stylesheet could be hit, not just the one
   page that surfaced it.

   Fixed via the standard cross-browser trick: -webkit-text-fill-color forces the text color back
   (plain `color` does not work against autofill, this is the one property that does), and a giant
   inset box-shadow fakes a solid background since the browser's autofill background paint can't be
   removed, only visually covered. #15223C approximates this site's common dark input/card surface
   tone (`body`'s own background is #0D1826, #15223C is already the most common card/surface tone
   layered on top of it sitewide) — not a per-page pixel-perfect match, impractical for one shared
   rule across many slightly different surface shades, but far closer than the browser's default
   light autofill background and eliminates the actual bug (illegible near-black text).

   :where() isn't used here unlike the rest of this file: :-webkit-autofill styling requires
   !important to reliably beat the user-agent's own autofill stylesheet — this isn't fighting a
   page-specific rule (which :where()'s zero-specificity trick is for), it's fighting the browser's
   native autofill paint, which nothing less forceful reliably overrides across Chrome/Safari. */
input:-webkit-autofill,
input:-webkit-autofill:hover,
input:-webkit-autofill:focus,
textarea:-webkit-autofill,
textarea:-webkit-autofill:hover,
textarea:-webkit-autofill:focus,
select:-webkit-autofill,
select:-webkit-autofill:hover,
select:-webkit-autofill:focus {
  -webkit-text-fill-color: var(--white, #F4F8FF) !important;
  -webkit-box-shadow: 0 0 0 1000px #15223C inset !important;
  box-shadow: 0 0 0 1000px #15223C inset !important;
  caret-color: var(--white, #F4F8FF);
  transition: background-color 5000s ease-in-out 0s;
}

/* Firefox's own autofill styling hook is the unprefixed `:autofill` pseudo-class (78+), a
   genuinely different selector from `:-webkit-autofill` above, not just a vendor-prefix
   duplicate — 2026-08-20, found while investigating a real "black text" report with no browser
   named, so fixed defensively rather than left unconfirmed. Kept as its OWN rule block rather
   than merged into the selector list above: an unrecognized pseudo-class inside a plain
   (non-:is()/:where()) comma-separated selector list can invalidate the WHOLE rule in a strict
   parser, so combining `:-webkit-autofill` and `:autofill` in one list risks breaking the
   already-working Chrome/Safari fix above for the sake of covering Firefox too. No `-webkit-`
   properties here (Firefox doesn't use them) — `color` is the property that actually wins
   against Firefox's autofill paint, unlike Chrome/Safari where only `-webkit-text-fill-color`
   does. */
input:autofill,
input:autofill:hover,
input:autofill:focus,
textarea:autofill,
textarea:autofill:hover,
textarea:autofill:focus,
select:autofill,
select:autofill:hover,
select:autofill:focus {
  color: var(--white, #F4F8FF) !important;
  box-shadow: 0 0 0 1000px #15223C inset !important;
  caret-color: var(--white, #F4F8FF);
}