/*
 * Base: reset, document defaults, typography, native form controls.
 *
 * Element selectors only. Nothing here knows about a component or a page — if a
 * rule needs a class, it belongs in layout.css or components.css.
 *
 * MOBILE-FIRST IS NOT A SLOGAN HERE. Every rule in this file is written for a
 * narrow screen and holds at every width; there is not a single max-width media
 * query in the foundation. This product's users are overwhelmingly on phones,
 * and a desktop-first sheet patched with max-width rules is a sheet where the
 * phone gets whatever is left over.
 */

*,
*::before,
*::after {
    box-sizing: border-box;
}

html {
    /* Never px: a user who has set a larger default font size has done so on
       purpose, and a px root silently overrides that decision. */
    font-size: 100%;
    -webkit-text-size-adjust: 100%;
}

body {
    margin: 0;
    background: var(--color-background);
    color: var(--color-text);
    font-family: var(--font-body);
    font-size: var(--font-size-base);
    line-height: var(--line-height-body);

    /* The single most important rule in this file for a Spanish-first product.
       "Responsabilidades", "Requisitos indispensables" and
       "restablecimiento de contraseña" are ordinary words here, and a long word
       in a narrow container is what puts a horizontal scrollbar on a phone.
       Breaking the word is the right trade: the text stays readable and the
       page stays the width of the screen. */
    overflow-wrap: break-word;
    word-break: normal;

    /* Hyphenation earns its keep in a narrow column and not outside one. On a
       phone it lets a long Spanish word split cleanly instead of leaving a
       ragged gap; at desktop width the same rule hyphenates ordinary body copy
       — "tra-bajadores" mid-paragraph — which is just noise. Base is the narrow
       rule, and the wide screen turns it off; that is mobile-first, not a
       max-width patch.

       Note it is `overflow-wrap: break-word` above, not this, that prevents the
       horizontal scrollbar. Hyphenation only makes the break read better. */
    hyphens: auto;
}

@media (min-width: 40em) {
    body {
        hyphens: manual;
    }
}

h1,
h2,
h3 {
    margin: 0 0 var(--space-3);
    line-height: var(--line-height-heading);
    font-weight: var(--font-weight-medium);

    /* Headings are where expansion bites hardest, because they are the largest
       text on the page and the least able to afford an extra line. */
    overflow-wrap: break-word;
}

h1 { font-size: var(--font-size-2xl); }
h2 { font-size: var(--font-size-xl); }
h3 { font-size: var(--font-size-lg); }

p,
ul,
ol {
    margin: 0 0 var(--space-4);
}

/* Long-form text is capped by characters, not pixels, so the measure stays
   comfortable whatever the user's font size is. */
p {
    max-width: var(--measure);
}

a {
    color: var(--color-primary);
    text-decoration: underline;
    text-underline-offset: 0.15em;
}

a:hover {
    color: var(--color-primary-hover);
}

code {
    font-family: var(--font-mono);
    font-size: 0.9em;
    /* A request id is one long unbreakable token; without this it is the one
       string on the page that can still force a horizontal scrollbar. */
    overflow-wrap: anywhere;
}

/* One focus style, defined once, applied to everything focusable. A visible
   focus ring is the difference between a keyboard-usable site and a site that
   technically responds to Tab.

   TWO-TONE SINCE PHASE 2 BLOCK 2A, and not for decoration. Measured against
   every surface this application has, no single colour clears 3:1 on white AND
   on the primary blue AND on the deep blue — a light ring disappears on white,
   a dark one disappears on a blue button. The old single blue ring was 1.25:1
   against the new primary, which is a keyboard trap on the most important
   control on the page.

   A light inner ring plus a dark outer halo. One of the two is always visible,
   whatever it is drawn on. See tokens.css for the measured pairs and
   FocusIndicatorTest for the assertion.

   ─── WHY THE HALO IS !important ────────────────────────────────────────────

   Because it is drawn with `box-shadow`, and `box-shadow` is the one property
   a designed component is most likely to set for its own reasons — elevation.

   This was found during the Block 2A polish pass, on the page, with a
   keyboard. `:focus-visible` is one class of specificity; so is
   `.pbutton--primary`, which sets `box-shadow: var(--shadow-md)` for its drop
   shadow — and it is declared in a stylesheet that loads later, so it won. The
   halo was silently not drawn on the two filled buttons on the site. On the
   blue one the surviving white inner ring still measured 7.99:1 against the
   fill and stayed compliant by luck; on the orange search button it measured
   2.95:1 and did not.

   A focus indicator is precisely the thing component styling must never be
   able to switch off by accident, so it wins outright rather than by
   depending on file order. The elevation shadow is suppressed while a control
   is focused, which is correct — the ring should be the loudest thing on it.

   FocusIndicatorTest measures the TOKENS and could not have caught this: the
   values were right and the cascade threw one of them away. It now also
   asserts this declaration. */
:focus-visible {
    outline: var(--focus-ring-inner-width) solid var(--color-focus-inner) !important;
    outline-offset: 0;
    box-shadow: 0 0 0 calc(var(--focus-ring-inner-width) + var(--focus-ring-outer-width))
        var(--color-focus-outer) !important;
    border-radius: var(--radius-sm);
}

/* ---- native form controls ---------------------------------------------- */

label {
    display: block;
    font-weight: var(--font-weight-medium);
}

input,
button,
select,
textarea {
    /* Controls do not inherit the document font by default, and a form in a
       different typeface from the page it sits in looks like a bug. */
    font: inherit;
    color: inherit;
    max-width: 100%;
}

input[type="email"],
input[type="password"],
input[type="text"],
input[type="search"],
textarea {
    display: block;
    width: 100%;
    padding: var(--space-3);
    border: 1px solid var(--color-border-strong);
    border-radius: var(--radius-sm);
    background: var(--color-background);

    /* 16px minimum. Below it, iOS Safari zooms the viewport on focus and the
       user is left scrolled sideways on a form they were trying to fill in. */
    font-size: max(var(--font-size-base), 1rem);
}

button {
    cursor: pointer;
}

/* ---- motion ------------------------------------------------------------- */

@media (prefers-reduced-motion: reduce) {
    *,
    *::before,
    *::after {
        animation-duration: 0.01ms !important;
        animation-iteration-count: 1 !important;
        transition-duration: 0.01ms !important;
        scroll-behavior: auto !important;
    }

    /* THE COMING-SOON DEFECT, NOT INHERITED. That page sets
       `html { scroll-behavior: smooth }` outside any media query, so a reader
       who asked their operating system for less motion got animated scrolling
       anyway — and an in-page anchor is exactly where motion sensitivity
       matters. This application never sets smooth scrolling at all, and this
       rule is the belt: if a future stylesheet adds it, the preference still
       wins. */
    html {
        scroll-behavior: auto !important;
    }
}