/* ============================================================================
   forced-colors.css — the Index under a Windows contrast theme
   ----------------------------------------------------------------------------
   Linked with media="(forced-colors: active)", so it is inert for everyone else.

   Same root cause as print.css, one surface over. This site is drawn for one
   canvas — warm white ink on carbon — and several of its indicators are built
   from properties that only survive on that canvas. Forced colors takes the
   canvas away: the user agent overrides color, background-color, border-color,
   fill, stroke and outline-color with the theme's system colors, and it drops
   box-shadow entirely.

   Two things the site depends on do not survive that:

     1. Focus, on the two fields that turned their outline off. The footer
        subscribe field draws its ring with an inset box-shadow — the comment at
        index.html:1481 is explicit that `outline: none` "was deleting the only
        indicator a keyboard reader had on the one field in the footer that asks
        them to do something," and the ring that replaced it is the one property
        forced colors does not render. The search field delegates focus to the
        bar around it via `.omni:focus-within { border-color }` — but every
        border in forced colors is already one system colour, so focus-within
        changes nothing you can see. Both fields end up with no focus indicator
        at all, for the readers most likely to be navigating by keyboard.

     2. The Artifice marks, which do not all face the same way. Forced colors
        does not recolour a raster mark, so on a light contrast theme — White,
        Desert — polarity decides whether a mark is visible, and the site ships
        both polarities:

          lockup.svg (nav)          black artwork, inverted to white in CSS
          logo.svg (footer)         white artwork, no filter
          wb/bb-icon.png            white, measured 255 mean luminance
          wb/bb-overlay.png         white, 255
          studio-artifice-wordmark  white, 250

        One blanket invert would fix four of those and break the fifth. They are
        named individually below.

   The real repair for (2) is upstream: these should be currentColor SVG, which
   is correct on carbon, on paper, on any contrast theme and at any size, and
   would make this whole file's second half unnecessary. Until that asset work
   is done, this is the net.
   ========================================================================== */

/* ---- 1. focus, restored to a property the theme cannot drop --------------- */

/* Highlight is the theme's own focus colour. Using it rather than a literal
   means the ring matches every other focused control on the reader's machine,
   which is the point of a contrast theme. */
.footer-sub__input:focus-visible,
.omni-input:focus-visible,
.omni-input:focus {
  outline: 2px solid Highlight !important;
  outline-offset: 2px !important;
}

/* The bar around the search field drew the state on screen. In forced colors
   the field draws its own, so the bar must not claim to. */
.omni:focus-within {
  border-color: ButtonBorder;
}

/* Two fields, not more. Every other input on the site keeps the user agent's
   own ring, which forced colors draws correctly without help — .sig-field's
   inputs, the login fields, the toolbar search. Only these two set
   `outline: none`, and a blanket rule here would put a second ring on controls
   that already have one, where a doubled outline reads as an error state.
   Checked against every `outline: none` in index.html, radar.html and
   about.html: five occurrences, three of them on .tb-search, whose container is
   display:none at every viewport and never renders. */

/* ---- 2. the marks, on a light contrast theme ----------------------------- */

/* Contrast themes report their polarity through prefers-color-scheme, so this
   is the one branch CSS can make: correct the artwork when the canvas is light,
   leave it alone when the canvas is dark and it already reads.
   forced-color-adjust: none keeps the user agent from re-flattening it. */
@media (prefers-color-scheme: light) {

  /* White artwork on transparency. Invisible over a light Canvas. */
  .mode-icon,
  .overlay-icon,
  .card-ph-mark,
  .footer-mark img,
  .credit__link img {
    filter: invert(1);
    forced-color-adjust: none;
  }

  /* The nav lockup is the exception: it ships black and the screen sheet
     inverts it to white at index.html:1637. On a light canvas that invert is
     what makes it disappear, so it is cancelled rather than added to. */
  .panel-mark img {
    filter: none;
    forced-color-adjust: none;
  }
}

/* Deliberately not here: borders on the cards, the drawer and the nav capsule.
   Forced colors flattens their background tints to Canvas and the hairlines
   holding them apart go with it, so they very likely do run together — but that
   is reasoning, not evidence, and there is no forced-colors surface in this
   sweep's harness to check it against. A guess about how five surfaces look is
   not the same kind of claim as the two above, which follow from the spec and
   from the measured luminance of the files themselves. Left for a pass that can
   see a Windows contrast theme. */