/*SECTION - Dropdown */

/* The <span> autocomplete.js injects around each search input, and the element
   that actually carries the panel's stacking position -- .aa-dropdown-menu
   inside it is `position: relative` with no z-index of its own, so it has
   nothing to stack with.

   `!important` here is not a shortcut and cannot be designed around. Algolia
   runs `v.autocomplete.getWrapper().style.zIndex = 1e4` on every
   `autocomplete:redrawn` event -- an inline style, re-applied on each keystroke
   -- and 10000 loses to the 999999 Forethought inline-styles onto its iframe.
   An !important author declaration is the one thing in the cascade that outranks
   a non-important inline style, and nothing we could do to the inline value
   itself would survive the next redraw.

   Both wrappers get it. There is one per input, so two on every page
   (header.hbs:95 and :126), and the closed one is `display: none` -- where a
   z-index is inert, not wrong. See --z-index-above-vendor-widget in
   css-brand-tokens.css for why the number is what it is. */
.algolia-autocomplete {
  z-index: var(--z-index-above-vendor-widget) !important;
}

/* TWO THINGS TO KNOW BEFORE EDITING ANY OF THIS.

   1. **Algolia's own stylesheet is not loaded.** The <link> for
      algoliasearch.zendesk-hc.min.css is commented out at
      document_head.hbs:293-297, so this theme owns the panel outright -- there
      is no vendor baseline underneath to override, and nothing here is fighting
      anything. It also means every piece of behaviour that stylesheet
      implemented has to be implemented here or it simply does not happen; the
      category grouping below is one that was not, and the duplicate "PAB / PAB /
      PAB" Joy screenshotted on 2026-10-22 was the result.

   2. **There IS a runtime-injected <style>, and it wins on load order.** The
      bundle calls `insertCss(templates.autocomplete.css({color, highlightColor}))`
      during init, from the `color: '#222222'` and `highlightColor: '#56215D'`
      arguments at document_head.hbs:315-316. All four rules it emits are plain
      `color` declarations:

        .aa-article-hit--highlight                      { color: #222222 }
        .aa-article-hit--section                        { color: #222222 }
        .aa-article-hit--title .aa-article-hit--highlight { color: #56215D }
        .aa-article-hit--title .aa-article-hit--highlight::before
                                                        { background-color: #56215D }

      Injected by JS, so it lands after this file no matter what; (0,2,0) at
      best, so specificity alone will not beat it either. Do not reach for
      `!important` -- those two arguments are interpolated raw into the template,
      so `highlightColor: 'var(--brand-text)'` is a valid edit and keeps the
      value on the token tier. The ::before rule is inert on its own: the
      `content` and positioning that made it a tint block lived in the stylesheet
      that is commented out, and a ::before with no `content` never generates a
      box.

   EVERY HIT IS `__xs`, ALWAYS. `_sizeModifier(w)` returns "xs" below 400px and
   "sm" below 600px, measured from `input.getBoundingClientRect().width` once at
   init. The navbar field is 256px by design and cannot grow -- it is `flex: 0 1
   auto` and the cluster has no room for 400px in either band (see the budget
   table in the "Header search" section of css-page-header.css), so a wider
   preferred width would just be shrunk back below the threshold. The mobile
   field initialises inside a closed .kb-search-row at width 0, which is also
   "xs". So `__sm` is unreachable: four `.aa-article-hit__sm ...` rules were
   deleted from this block on 2026-10-22 as dead code, and the surviving
   selectors are written bare rather than `__xs`-qualified, because the modifier
   carries no information. */

/* The panel. Deliberately the same floating-card recipe as the mobile nav
   flyout at css-page-header.css:751 -- surface, 1px soft border, --radius-sm,
   and the four --shadow-floating-* tokens assembled by hand. Codex has exactly
   one composite shadow that survives the self-referential-var cycle described in
   css-brand-tokens.css:510, and this is the second thing in the theme to use it.
   An autocomplete panel and a nav flyout are the same kind of object, so they
   should be indistinguishable.

   **The width is the field's, and there is no declaration here that says so.**
   That is the point rather than an omission: autocomplete.js inline-styles the
   wrapper <span> to the input's width and leaves the panel a static block inside
   it, so a panel with no inline-size of its own simply fills the wrapper and
   tracks the field at every breakpoint, desktop (~254px) and mobile (full row)
   alike. One behaviour, nothing to keep in sync.

   It was `min-inline-size: 26.25rem` with `max-inline-size: calc(100vw - 3rem)`
   until 2026-10-22 -- deliberately wider than the field, because at field width
   article titles wrap to two lines. Joy took the question to her team and they
   chose to constrain it, and the trade they accepted is worth writing down so it
   is not rediscovered as a bug: the text column goes from ~378px to ~212px, or
   roughly 55 characters to 31, and real titles in this index run 35-57
   characters -- so most rows now take two lines and the panel is about 40%
   taller than it was wide-and-short. Long category paths lose the most, since
   they are capped to one line: "Installing and Configuring / Microsoft PABs"
   truncates around "Micr...". What is bought is alignment -- the panel no longer
   overhangs the Support Tools button, and its right edge is predictable at every
   viewport instead of depending on where the header cluster happens to sit.

   The gutter cap went with the floor rather than being left as a safety net. It
   could only ever bind if the panel were wider than the viewport minus both page
   gutters, and the panel is now exactly as wide as an input that sits inside
   those gutters -- so it was unreachable by construction, and an unreachable
   declaration with a comment explaining when it applies is worse than no
   declaration. */
.aa-dropdown-menu {
  margin-block-start: 0.5rem;
  /* No padding here on purpose -- the inset the rows sit in is on
     .aa-suggestions, inside the scroll container. See the note there. */
  background: var(--neutral-bg);
  /* Stated rather than inherited, which is what lets this panel come off the
     legacy dark-mode patch list in css-utilities.css:1476. A card that floats
     over arbitrary content should not depend on what it happens to be nested in
     for its ink, and the hit title below deliberately sets no colour of its own
     so that this is the single place it is decided. */
  color: var(--neutral-text);
  border: var(--border-width-regular) solid var(--neutral-border-soft);
  border-radius: var(--radius-sm);
  box-shadow: 0 var(--shadow-floating-y-offset) var(--shadow-floating-blur)
    var(--shadow-floating-spread) var(--shadow-floating-color);
  font-family: var(--brand-font-family-sans);
  /* Was --step-1, a step *above* body copy, which is why the panel read as
     oversized against the 256px field it hangs off. */
  font-size: var(--step-0);
  text-align: start;
  /* THE SCROLL CONTAINER, AND IT HAS TO BE THIS ELEMENT -- because this is the
     element autocomplete.js writes scrollTop to, in _ensureVisible, and it
     writes to no other. Measured here with ten hits open, 2026-10-22: 446px of
     scrollport against 707px of rows, which is this cap doing its job.

     The cap lived on .aa-dataset-articles for about a day, and the result was
     that arrowing down moved .aa-cursor out of the clipped child while the
     panel sat still -- the highlighted row simply vanished, because every
     scrollTop call landed on an element with no overflow. So this much is
     necessary. It is not sufficient, and that took three rounds to establish:
     _ensureVisible is itself broken, in the bundle, and reads this element's
     height through a camelCase css() lookup that its own Zepto resolves to NaN.
     The full derivation is in document_head.hbs beside the listener that
     replaces it; the short version is that no value written here was ever going
     to be read, so do not go looking for the bug in this rule again.

     Two notes that were here, both now corrected by that measurement:
     - The menu's padding being 0 is NOT load-bearing for the vendor's maths.
       It reads height() + padding, so in principle padding would skew it, but
       the padding term is exactly the one that NaNs, so it is moot. The inset
       stays on .aa-suggestions for the focus-ring reason alone -- see the note
       there, which stands on its own.
     - The menu is NOT `position: absolute` and is NOT the rows' offsetParent.
       Measured `static`, with the rows' offsetParent being
       .algolia-autocomplete: the integration runs the library in appendTo mode,
       where the wrapper is absolutely positioned and appended to the body and
       the menu is left in flow inside it. Positioning things in between is
       therefore harmless now, since nothing depends on .position() any more.

     `min()` so the cap is the smaller of 60% of the viewport and 28rem -- the
     vh half protects short windows, the rem half stops a tall monitor rendering
     a panel too long to scan. overscroll-behavior keeps a trackpad flick inside
     the list instead of scrolling the page behind it once the list ends. */
  max-block-size: min(60vh, 28rem);
  overflow-y: auto;
  overscroll-behavior: contain;
}

/* The list, and the padded box the rows actually sit in. 0.25rem on all four
   sides is Codex's `p-1` on the element it calls .kb-search-viewport, and this
   is the element in the same position: Codex nests
   panel > div.overflow-y-auto > div.kb-search-viewport.p-1 > options, which maps
   onto .aa-dropdown-menu > .aa-dataset-articles > .aa-suggestions >
   .aa-suggestion one for one.

   The inset is doing real work rather than being air -- the rows are rounded, so
   it is what stops a hover fill colliding with the panel's own corner radius,
   and it is what the rows' focus ring is drawn into at exactly 2px offset + 2px
   width.

   **Which is why it is here and not on the panel, where it started.** The panel
   is the scroll container, and `overflow-y: auto` makes the computed overflow-x
   `auto` too -- a `visible` value on one axis cannot survive a non-visible value
   on the other. An outline is ink overflow, not scrollable overflow, so it does
   not push the scroll region out; a scroll container just clips it. Padding on
   the panel sits outside its own scroll box, so the ring's left and right edges
   would have been cut off flush against the rows, and a row would have looked
   like it had a ring on two sides. Padding inside the scroller is padding the
   ring can be drawn into.

   That is the whole reason, and it is enough. A second one was claimed here on
   2026-10-22 -- that autocomplete.js measures the menu as height() + padding,
   so a padded menu would skew its keyboard scrolling -- and it turned out to be
   void: that padding term is the one the bundle resolves to NaN. See the note
   on .aa-dropdown-menu. */
.aa-suggestions {
  padding: 0.25rem;
}

/* One row, and the direct counterpart of Codex's .kb-option-item +
   .kb-option-item-flush pair, which Joy pulled from DevTools on 2026-10-22.
   Theirs reads:

     .kb-option-item {
       align-items: center;  border-radius: var(--radius-sm);
       color: var(--text-color-neutral);  cursor: pointer;  display: flex;
       font-family: var(--font-family-secondary);
       font-size: var(--font-size-sm);
       font-weight: var(--font-weight-regular);
       gap: calc(var(--spacing) * 2);  line-height: 1.4;  position: relative;
     }
     .kb-option-item-flush {
       padding-block: calc(var(--spacing) * 2);   -- resolves to 0.5rem
       padding-inline: calc(var(--spacing) * 4);  -- resolves to 1rem
     }

   Most of it is already satisfied one level up and is deliberately not restated:
   `color`, `font-family` and `font-size` are on the panel, where they are
   decided once. The two typographic ones are closer matches than they look --
   --font-family-secondary *is* Inter (see the mapping at style.css:104), and
   --font-size-sm is 14px, which is exactly what --step-0 clamps to at its
   minimum. So the rows are already at Codex's size without going near the
   --step--1 accessibility floor (css-root.css:128).
   `display: flex` / `align-items: center` / `gap` are not carried over, and
   should not be: a Codex option is one line of icon-plus-label laid out
   horizontally, whereas an Algolia hit is a stacked category header over a
   title. Copying the flex row would put them side by side. `position: relative`
   anchors absolutely positioned children Codex has and we do not.

   Inline padding belongs here and not on .aa-article-hit--content, which is a
   descendant of .aa-article-hit--line and so does not span the category header
   above it -- the fill has to cover the whole row or the header sits in a notch.
   The rounding is what makes the 0.25rem of panel padding read as intentional,
   and it is why the dividers that were briefly here on 2026-10-22 are gone:
   Codex puts no rule between its options. Separation is the fill on the row you
   are pointing at, plus the category header between groups.

   The inline padding is 0.75rem rather than Codex's 1rem, and that is the one
   place the panel's width change reaches into the rows. Codex's 16px a side is
   8% of the 420px panel this was built against and 13% of the 254px one it
   became, which is 32px of a column that now has ~212px of text in it and is
   wrapping most titles to two lines. Spending a fifth of the gain on padding to
   match a number exactly would be matching the wrong thing -- Codex's rows are
   wide and single-line, and the intent of `p-4` there is breathing room, not a
   constant. 0.75rem keeps the proportion and gives the text back 8px. */
.aa-suggestion {
  border-radius: var(--radius-sm);
  cursor: pointer;
  line-height: var(--leading-body-0);
  padding-block: 0.5rem;
  padding-inline: 0.75rem;
  transition: background-color var(--motion-duration-control) var(--ease-in-out);
}

/* Pointer hover, matching Codex's
   `:not([data-keyboard-nav]):not([data-suppress-hover]) .kb-option-item:hover`
   -- same token, same role. Their two guard attributes are a refinement we
   cannot reproduce and are not missing much by losing: Codex suppresses pointer
   hover while the user is navigating by keyboard, so the cursor resting over row
   three cannot compete with the arrow keys sitting on row one. Algolia sets no
   equivalent flag, so both states can be visible at once here.

   This rule and the one below replace `.aa-suggestion.aa-cursor
   .aa-article-hit--content:hover`, which required the pointer to be over the row
   the *keyboard* had also landed on -- true almost never, so arrowing through the
   list highlighted nothing at all. Its companion
   `.aa-article-hit--content:focus` went too: that element is a <div> with no
   tabindex and has never been focusable, and its `border: var(--clr-black)` was
   not a valid border shorthand -- a bare colour with no width or style is
   dropped at parse time. */
.aa-suggestion:hover {
  background-color: var(--neutral-bg-component-soft-hover);
}

/* Keyboard selection. .aa-cursor is Algolia's `[data-highlighted]`, so it takes
   the same fill, and then the ring on top because that is what Codex's own
   keyboard state looks like: its options carry `tabindex="-1"` and are focused
   programmatically as you arrow through them, so they pick up the global
   `:focus-visible` ring as well as the fill.

   Spelled out rather than borrowed from css-reset.css:19, and the reason that
   still applies is the first of the two that used to be given: the reset only
   fires on `:focus-visible`, and this <div> never takes DOM focus -- Algolia
   keeps focus in the input and moves this class instead -- so there is nothing
   to inherit.
   The second reason is spent as of 2026-10-25. The reset used to pair its
   outline with a `border: 2px solid`, and borrowing that here would have added
   2px of border to one row and shunted the list sideways as you arrowed down it.
   That border has left the reset, so the hazard is gone; the outline alone was
   always both Codex's actual ring and the one that cannot move anything.
   `outline-offset: 2px` flat, not the reset's max(2px, 0.15em) -- see the note at
   css-reset.css:14 about components that pin it. At this offset the ring lands
   2px outside the row and so exactly fills the panel's 0.25rem of padding. */
.aa-suggestion.aa-cursor {
  background-color: var(--neutral-bg-component-soft-hover);
  outline: 2px solid var(--form-focus-ring);
  outline-offset: 2px;
}

/* The category, used as a group header over the first hit of each category --
   which is what `__category-first` is for. Both of these rules are restorations:
   Algolia's stylesheet carried `.aa-article-hit .aa-article-hit--category
   { display: none }` plus the `__category-first` exception, and with that file
   commented out the header printed on *every* hit. Three consecutive PAB
   articles rendered "PAB / PAB / PAB", one label per row. */
.aa-article-hit--category {
  display: none;
}

.aa-article-hit__category-first .aa-article-hit--category {
  display: block;
  color: var(--neutral-text-soft);
  font-size: var(--step--1);
  font-weight: var(--font-weight-strong);
  line-height: var(--leading-body--1);
  margin-block-end: 0.25rem;
}

/* Truncation, also a restoration and also load-bearing. `category.title` can be
   a full path -- "Installing and Configuring / Microsoft PABs" is one real
   value -- and with nothing clamping it, it wrapped to four lines in a 256px
   panel. One line and an ellipsis: a group header that is taller than the hit it
   heads is not a header. */
.aa-article-hit--category--content {
  display: block;
  overflow: hidden;
  text-overflow: ellipsis;
  white-space: nowrap;
}

/* The section title, suppressed. Algolia's stylesheet hid this by default and
   revealed it on `__section-first`; the rule that used to be here was
   `.aa-article-hit__section-first .aa-article-hit--section { display: none }` --
   exactly inverted, so the section showed on every row *except* the one it was
   meant to head.
   Hidden outright rather than corrected to match the category above, because a
   category header plus a section header plus a title is three lines of chrome
   per hit in a list whose job is to be scanned. The category already carries the
   path when there is one. Say the word if the section should come back; the fix
   is this rule plus a `__section-first` twin of the category pair above. */
.aa-article-hit--section {
  display: none;
}

/* Regular weight, matching Codex's own autocomplete rows. It was bold, which at
   `__xs` meant every line in the panel was bold and nothing stood out from
   anything -- the group header is what separates the groups now, and the
   highlight is what marks the match. */
.aa-article-hit--title {
  font-weight: var(--font-weight-regular);
  line-height: var(--leading-body-0);
}

/* The body snippet, suppressed -- and this one cannot be fixed by styling it.
   `_nbSnippetWords(w)` returns **0** below 400px, so the bundle requests
   `attributesToSnippet: ["body_safe:0"]` and Algolia returns the matched word
   between two ellipses and nothing else. "... Phish ..." is not a truncation
   bug; it is the entire snippet, and it is the most that can ever arrive while
   the field is narrower than 400px. See the note at the top of this block for
   why it cannot be.
   Confirmed from the wire on 2026-10-22 rather than inferred: a live request
   carried `attributesToSnippet=["body_safe:0"]` and came back with
   `_snippetResult.body_safe.value` of exactly "... Phish ...". */
.aa-article-hit--body {
  display: none;
}

/* The matched text inside a title -- note *text*, not "the letters you typed",
   which is the part that surprises everyone. And the one declaration in this
   block that cannot be settled in this file alone: read it together with
   document_head.hbs:315-316.

   HOW WIDE THE CHIP GETS IS NOT OURS TO DECIDE, AND SHOULD NOT BE MADE OURS.
   The span arrives from the API already wrapped -- the bundled hit template
   renders `[[& _highlightResult.title.value ]]`, unescaped, so whatever Algolia
   marked is what gets filled. Narrowing it is not a CSS problem and it is not a
   config problem either: the autocomplete's search parameters are built inside
   the bundle and merged with nothing from document_head.hbs.

   Joy raised this on 2026-10-22 -- typing "list" chips the whole of "Whitelist"
   -- and the response she captured settles it. Querying "pab" returns:

     title.value   "<span ...>Phish Alert</span> Button (<span ...>PAB</span>)
                    Product Manual"
     matchedWords  ["pab"]

   "Phish Alert" is chipped for a query that shares no letters with it. The index
   carries synonyms (pab <-> phish alert / phish alert button, and evidently
   list <-> whitelist / allowlist), `matchedWords` reports the *query* word
   rather than the rendered one, and Algolia marks the whole matched term because
   the whole term is what matched. Mid-word chipping is the same mechanism seen
   from the side where it looks wrong.

   `templates.autocomplete.article` *is* overridable -- the integration does
   `Object.assign({}, defaults.autocomplete, config.templates.autocomplete)` and
   calls it as a plain `article(hit)` -- so a custom renderer could re-highlight
   `hit.title` against the literal query. Deliberately not done. It would narrow
   "Whitelist" to "White(list)" and in the same pass unmark "Phish Alert"
   completely, since "pab" is not a substring of it. That trades away the one
   case where the highlight explains an otherwise baffling result to tidy up the
   case where it is merely wide. If this is ever revisited, that is the cost to
   beat, and `replaceSynonymsInHighlight` is not a way around it: it swaps which
   word is shown, never the granularity.

   Algolia injects a <style> at init built from those two config arguments, and
   two of its four rules land on this element:

     .aa-article-hit--title .aa-article-hit--highlight          { color: <highlightColor> }
     .aa-article-hit--title .aa-article-hit--highlight::before  { background-color: <highlightColor> }

   Identical selector, identical specificity (0,2,0), appended to <head> after
   every theme stylesheet -- so on `color` the injected rule wins on load order
   no matter what is written here, and chasing it with `!important` would be
   fighting a value we are allowed to simply set. The fix is the argument, which
   is why `highlightColor` is a token over there and why this rule sets only the
   fill. Nothing here collides.
   (The ::before is inert -- its `content` and positioning lived in the
   stylesheet commented out at document_head.hbs:293-297, and a ::before with no
   `content` generates no box. It is listed only so the next person does not go
   looking for the leak.)

   Codex's own treatment is a dark fill with inverted text, and that is what was
   here first. It came off on 2026-10-22, for a reason that is specific to this
   search engine rather than a disagreement with Codex: a Codex chip marks a few
   characters, whereas this one marks whole synonym-matched terms, and
   "Phish Alert Button (PAB) Product Manual" searched for "pab" comes back with
   *two* marked spans covering most of the line. Inverting most of a title is not
   emphasis, it is a second theme. A tint says the same thing at phrase length
   and keeps the title readable as a title.

   --neutral-bg-component-active is the darkest fill in the neutral set that
   still takes ordinary --neutral-text over it, which is the entire constraint:
   anything darker means going back to inverted ink, and inverted ink at phrase
   length is the problem we just left. It clears both surfaces it has to be seen
   against, measured rather than eyeballed:

     light  #c9d7d9 on the #faffff panel             1.47:1
            ... on a hovered row (#e5f2f3)           1.29:1
            --neutral-text (#10171e) over the chip  12.5:1
     dark   #536a80 on the #1e2a35 panel             2.4:1
            --neutral-text (#ffffff) over the chip   5.6:1

   The first pass used --neutral-bg-component-soft-hover, the row hover fill, on
   the theory that the chip should be family with the row it sits on. Joy called
   it on 2026-10-22: #e5f2f3 against #faffff is 1.14:1 and simply cannot be seen.
   Reusing the hover token was wrong in principle too -- a chip the same value as
   the hover fill disappears on exactly the row the pointer is over.
   --neutral-bg-highlight is the trap to avoid next, despite the name: its dark
   tier is #1e2a35, which *is* --neutral-bg in dark mode, so it would be a chip
   that vanishes entirely on half the site. The light tier of the token actually
   used happens to equal --neutral-border-soft, so the chip is the same tone as
   the panel's own edge -- not planned, but it is why it sits comfortably.
   Every neutral-* entry has a real dark-tier value, which the legacy
   --clr-secondary-5 wash that was here before all this did not: that one would
   have stayed near-white on a #1e2a35 panel.

   No underline and no weight change, both deliberate. Weight especially: these
   spans are mid-sentence, so bolding them reflows the title as you type.
   `.aa-article-hit--body .aa-article-hit--highlight` is not here because the
   body snippet itself is display: none above. */
.aa-article-hit--title .aa-article-hit--highlight {
  background-color: var(--neutral-bg-component-active);
  /* Breathing room on the fill only -- inline padding on an inline box does not
     advance the line box, so the chip can be padded without the title shifting
     or the rows changing height. Square, per Joy on 2026-10-22: --radius-sm is
     0.375rem, which on a 14px line is most of the way to a pill, and a rounded
     fill mid-sentence reads as a tag -- a thing you could click -- rather than
     as emphasis on the text it sits on. */
  padding-inline: 0.125rem;
}

/*!SECTION - Dropdown */

/* The `color: var(--clr-neutral-160)` that used to close this rule was deleted
   on 2026-10-30 in Phase 5's legacy sweep. It never painted: both elements that
   carry this class are coloured by a more specific rule. The header's
   magnifying glass sits inside `#kb-mobile-search`, which carries
   `mobile-navbar`, so `.mobile-navbar .search-wrapper .search-button` in
   css-page-header.css reaches it at (0,3,0) with --neutral-icon; and the home
   hero's sparkles glyph is caught by
   `html.home-page #ft-search-spacer .search-button` in css-page-forethought.css
   at (1,2,1). The positioning declarations below are a different matter and are
   live -- the forethought rule overrides `inset-block-start` for the pill but
   nothing else, and `[dir='rtl'] .search-button` further down still corrects
   `inset-inline-start`. */
.search-button {
  position: absolute;
  z-index: 10;
  inset-block-start: 20px;
  inset-inline-start: 24px;
}

[dir='rtl'] .search-button {
  inset-inline-start: 5px;
}

/* SECTION - Header Search — deleted 2026-10-21; it all lives in
   css-page-header.css now

   Everything that was here described the *collapsed* header search: a 38px
   circle that expanded to 30% of the header's width over its siblings on focus,
   in the legacy salmon skin. Joy's call on 2026-10-21 is that the header search
   looks identical on every template, and the shape it takes is the inline Codex
   pill the home page already had -- so the collapsed treatment has no template
   left to appear on. Deleted rather than left to lose the cascade, because
   "losing" was only ever true declaration by declaration and four of these were
   not losing at all:

   - `.header-search:focus-within` painted `box-shadow: 0 0 0 2px #fce1d3`. The
     home-page block overrode that rule's border, radius, fill and z-index but
     never its shadow, and nothing else in the theme sets box-shadow on this
     element -- so the pill took a salmon glow outside Codex's focus ring on the
     one template where it was visible. Worth confirming in preview that it has
     gone.
   - `.search-submit` set `width: calc(var(--size)-10px)`, with no spaces around
     the minus. A declaration holding a var() is only checked once the variable
     is substituted, so this survives parsing and then fails, leaving width at
     its initial `auto`. That was invisible on the <button> it was written for;
     the Font Awesome kit copies an element's classes onto the <svg> it replaces
     it with, so the next element to take this class would render a 300px
     magnifier. header.hbs:145 records the day that happened. The whole rule is
     gone, landmine included.
   - `.expand .aa-input` matched a bare `.expand`, a class article_page.hbs,
     request_page.hbs and four vendor bundles also use. It only ever did
     anything in the header, but nothing stopped it reaching further.
   - `.header-search input#query.aa-input` is the reason the replacement block
     needed `!important` to set the input's padding. It does not any more.

   Also gone: the two `display: none` rules that made the header search differ
   by template -- `.home-page .navbar-search` (hidden because the hero search
   served instead, then re-shown at desktop widths by what is now the "Header
   search" section of css-page-header.css) and
   `.search-results-page .navbar-search` (which left that page with no search
   field at all, its own template renders none) -- plus `.home-page
   .mobile-navbar`, which had already been beaten on load order by
   `.kb-search-row` in css-page-header.css since the mobile search build.

   The second of those came back on 2026-10-22, at the end of the "Header search"
   section of css-page-header.css. It was not making the header differ for no
   reason: the search results page's own search implementation claims this form,
   hides it with an inline style, and swaps Algolia's dropdown -- which the
   `.aa-*` block at the top of this file styles, and which is confirmed live on
   the home page and on article pages -- for Zendesk's unstyled `zd-autocomplete`
   panel. Deleting it is what made that visible. Nothing else in this paragraph
   has changed.

   What the input needs in order to have a box at all moved with it: this file's
   `border: 0`, `padding: 0 1rem` and `width: 100%` were the only rules zeroing
   the UA's own input chrome, and css-reset.css touches none of the three, so
   they are restated in the block rather than dropped.

   Two RTL rules went too. `[dir='rtl'] .search-submit { margin-inline-end }` was
   nudging a control that no longer carries the class, and `[dir='rtl']
   .search-submit input::placeholder-shown` was never valid in the first place --
   placeholder-shown is a pseudo-*class* on the input (`:placeholder-shown`), not
   a pseudo-element, so as written the selector matched nothing in any locale.
   `[dir='rtl'] .search-button` above is unaffected; .search-button is the mobile
   row's and the home hero's glyph, which is live. */
/* !SECTION - Header Search */

.results .form-field {
  display: flex;
}