/* =============================================================================
   SITE SEARCH
   -----------------------------------------------------------------------------
   Two surfaces, one component: the header control and the panel it opens. The
   /search page's own field is here too, because a visitor who lands on that
   page and one who opens the panel are looking at the same control and it must
   not be two.

   WHAT IS NOT HERE, DELIBERATELY: the result row. A result is a .row-item, the
   same component every other list on the site uses, so it inherits the hover
   fill, the stretched link and the reduced-motion rule from sdeira-sections.css
   rather than carrying a second definition that drifts. Only the panel's own
   scroll container is styled below.

   No borders anywhere: separation is tonal, which is the system's one answer.
   ========================================================================== */

/* ---- The header control ---------------------------------------------------
   It is the language control's twin, geometry and all - they sit next to each
   other in the bar and anything less than the same numbers drifts the moment
   either is retuned. .lang's own rules are in the two chrome stylesheets, so
   the shared values are restated here rather than reached for across files.

   COLOUR IS PART OF "geometry and all", and it was the one number this file
   left out. `color: inherit` on a control that sits inside a transparent bar
   over a photograph resolves to the document ink, so the glyph painted
   #414042 on a dark header - measured on the English homepage and on all 32
   generated pages, beside a language control that was rgba(255,255,255,.84).
   The four states below are .lang's four, restated for the same reason the
   geometry is. */
.nav-search {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  /* 44, not the 36 this was: the icon controls in the bar are one set and an
     odd box out puts uneven air between the glyphs (measured 28px on one side
     of this control and 32px on the other). 44 is also the WCAG 2.5.8 target
     the burger beside it already carries. Stated here rather than in the
     homepage sheets because this file loads after them and would otherwise
     win - and because it is the one file that owns this control on all 33
     pages that have it. */
  min-inline-size: 44px;
  min-block-size: 44px;
  padding: 0;
  border: 0;
  border-radius: var(--r);
  background: transparent;
  color: rgba(255, 255, 255, .84);
  cursor: pointer;
  transition: color var(--dur-fast) var(--ease-out),
    background var(--dur-fast) var(--ease-out);
}

.nav-search:is(:hover, :focus-visible) {
  color: var(--brand-white);
  background: rgba(255, 255, 255, .12);
}

/* The bar goes opaque and light past the scroll threshold. Written against
   #hd, the header's id on every page that carries this control, because the
   homepage sheets key this off `header.scrolled` and the sub-page sheet off
   `#hd.scrolled` - the id matches both without stating the pair. */
#hd.scrolled .nav-search {
  color: var(--muted);
}

#hd.scrolled .nav-search:is(:hover, :focus-visible) {
  color: var(--accent-strong);
  background: var(--accent-wash);
}

.nav-search:focus-visible {
  outline: 3px solid var(--brand-razeen);
  outline-offset: 2px;
}

/* ---- The panel ------------------------------------------------------------
   Fixed, full-viewport, and it IS the backdrop - a click that lands on it
   rather than on the sheet is a click outside, which is what the script tests.
   A separate backdrop element would be a second thing to keep in step with the
   panel's own open state. */
.site-search {
  position: fixed;
  /* Above the header (#hd z-index 1000) and the assistant (1001-1002) so the
     opened search overlay and its backdrop always cover the whole viewport and
     no part of the sheet can sit behind the header. Below the mobile drawer
     (1101), which the search JS closes before opening anyway. */
  z-index: 1080;
  inset: 0;
  display: grid;
  justify-items: center;
  align-content: start;
  /* Top gutter is header-height-aware: the sheet never starts under where the
     header sits. The header covers the top of the viewport; the token is
     --header-logo-height (72px) plus the bar's own gap. */
  padding: max(clamp(72px, 12vh, 140px), calc(var(--header-logo-height) + 28px)) clamp(16px, 4vw, 40px) 40px;
  background: rgba(var(--image-overlay-rgb), .86);
  opacity: 0;
  transition: opacity var(--dur-base) var(--ease-out);
}

/* THE CLOSED PANEL MUST NOT BE ON THE PAGE AT ALL.
   The script closes it with `panel.hidden = true`, and the attribute's whole
   meaning comes from the browser's own `[hidden] { display: none }` - which is
   a user-agent rule, so the `display: grid` above beat it. The panel therefore
   stayed laid out on every page that has search: position: fixed, inset: 0,
   z-index 120, and merely transparent.

   Nothing looked wrong. But a full-viewport layer over the document swallows
   the pointer, so text could not be SELECTED anywhere on those 33 pages - drag
   across a paragraph and the mousedown landed on the panel instead. That was
   the reported symptom, and it is why the Arabic homepage was unaffected: it
   has no search panel to cover it.

   Restated here rather than relying on the UA rule, because any author
   `display` on this selector would silently defeat it again. */
.site-search[hidden] { display: none; }

/* The panel's toggleable rows also set their own display (.site-search-start
   and .site-search-results are both .row-list, which declares display: grid).
   The homepage's sdeira-v2 sheet forces [hidden] off with !important, but
   subpages do not load that sheet, so on subpages the author display rule was
   beating the UA [hidden] { display:none } and the "Start here" links stayed
   visible over the live results. Same treatment as .site-search above, stated
   here so the shared search hides its own rows on every page. */
.site-search-start[hidden],
.site-search-start-title[hidden],
.site-search-results[hidden],
.site-search-empty[hidden] {
  display: none;
}

.site-search.is-open { opacity: 1; }

/* The sheet enters from above rather than fading in place: the control that
   opened it is in the header, so the panel arrives from where it was asked for.
   translate only - nothing here resizes, so the pointer never chases it. */
.site-search-sheet {
  inline-size: min(100%, 720px);
  max-block-size: calc(100dvh - clamp(112px, 16vh, 180px));
  display: flex;
  flex-direction: column;
  min-block-size: 0;
  padding: clamp(18px, 2vw, 26px);
  border-radius: var(--r);
  background: var(--surface-raised);
  overflow-y: auto;
  overscroll-behavior: contain;
  transform: translate3d(0, -12px, 0);
  transition: transform var(--dur-base) var(--ease-out);
}

.site-search.is-open .site-search-sheet { transform: none; }

/* ---- The field, on both surfaces ------------------------------------------
   The panel's field and the results page's field are one rule. The box is the
   sunken surface and the input inside it is transparent, the same arrangement
   the assistant's composer and the form fields use: one visible surface, the
   control drawn on it, no outline. */
.site-search-field,
.search-field {
  display: flex;
  align-items: center;
  gap: 12px;
  flex: 0 0 auto;
  padding: 10px 14px;
  border-radius: var(--r);
  background: var(--surface-sunken);
  transition: background-color var(--dur-fast) var(--ease-out);
}

.site-search-field:focus-within,
.search-field:focus-within {
  background: var(--surface-sunken-strong);
  outline: 2px solid var(--accent);
  outline-offset: 2px;
}

.site-search-field > i.ph,
.search-field > i.ph { color: var(--icon); }

.site-search-field input,
.search-field input {
  flex: 1 1 auto;
  min-inline-size: 0;
  padding: 8px 0;
  border: 0;
  outline: none;
  background: transparent;
  color: var(--ink);
  caret-color: var(--accent);
  font: inherit;
  font-size: var(--type-action);
}

/* Safari draws its own clear button inside type=search and it lands on the
   wrong surface. The close control is the panel's own. */
.site-search-field input::-webkit-search-decoration,
.site-search-field input::-webkit-search-cancel-button,
.search-field input::-webkit-search-decoration,
.search-field input::-webkit-search-cancel-button { appearance: none; }

.site-search-close {
  display: grid;
  place-items: center;
  flex: 0 0 auto;
  inline-size: 32px;
  block-size: 32px;
  padding: 0;
  border: 0;
  border-radius: var(--r);
  background: transparent;
  color: var(--icon);
  cursor: pointer;
  transition: background-color var(--dur-fast) var(--ease-out),
    color var(--dur-fast) var(--ease-out);
}

.site-search-close:is(:hover, :focus-visible) {
  background: var(--surface-raised);
  color: var(--ink);
}

.site-search-close:focus-visible {
  outline: 3px solid var(--brand-razeen);
  outline-offset: 2px;
}

/* ---- Count, results, empty state ------------------------------------------ */
.site-search-count,
.search-count {
  margin: 14px 0 0;
  color: var(--label);
  font-size: var(--type-meta);
}

/* The search panel has a useful first state: established C5 route rows, not a
   second button system or an empty dialog. They disappear as soon as a query
   is present, leaving the existing live-result flow unchanged. */
.site-search-start-title {
  margin: 18px 0 0;
  color: var(--ink);
  font-size: var(--type-label);
  line-height: var(--leading-label);
}

.site-search-start {
  margin-block-start: 10px;
}

.site-search-start .row-item {
  background: var(--surface-sunken);
}

/* The panel's list is what scrolls, not the sheet: the field and the count stay
   put while the results move under them. min-block-size: 0 on the flex child is
   what actually lets it shrink - without it a long list pushes the sheet past
   its own max height instead of scrolling inside it. */
.site-search-results {
  flex: 1 1 auto;
  min-block-size: 0;
  margin-block-start: 12px;
  overflow-y: auto;
  overscroll-behavior: contain;
  /* MEASURED, NOT DEFENSIVE. .row-list is display: grid, and this is the same
     element - so the moment the flex parent gave it a definite height, its auto
     rows stopped sizing to their content and were distributed across that
     height instead: eight rows at exactly 588/8 = 64.8px each, with every row's
     title and description overflowing a box two-thirds too short. The list
     looked like eight empty labels. align-content: start is what stops the
     distribution; grid-auto-rows keeps each row on its own content whatever the
     container's height turns out to be. */
  align-content: start;
  grid-auto-rows: min-content;
}

.site-search-empty,
.search-empty {
  margin: 18px 0 0;
  color: var(--muted);
  font-size: var(--type-body);
}

/* ---- The results page -----------------------------------------------------
   The FIELD is measured, the RESULTS are not. A search field wider than about
   720px reads as a form the page is built around rather than as a control, and
   nobody types a line that long; a result row is a card and takes the section's
   own width like every other list on the site. Capping both would have left the
   results in a narrow column with half the section empty beside them. */
.search-panel { display: grid; }

.search-panel .search-field { max-inline-size: 720px; }

.search-results { margin-block-start: clamp(20px, 2.4vw, 32px); }

/* Four ways on rather than a dead end, per the spec's No Results section. It is
   the shared row list, so the suggestions answer the pointer exactly like the
   results they replace. */
.search-suggestions { margin-block-start: clamp(20px, 2.4vw, 32px); }

@media (max-width: 720px) {
  .site-search { padding-block-start: 64px; }
  .site-search-sheet { max-block-size: calc(100dvh - 96px); }
}

@media (prefers-reduced-motion: reduce) {
  /* Clear the stacked bar on a phone: the sheet opens above the header (z-index
     1080) but still wants its own air below the very top edge, sized from the
     header-height token rather than a fixed value. */
  .site-search { padding-block-start: calc(var(--header-logo-height) + 24px); }
  .site-search-sheet { max-block-size: calc(100dvh - 96px); }
}

  .site-search-sheet { transform: none; }


/* ---- Result rows on the panel's own ground --------------------------------
   The sheet is --surface-raised and so is .row-item's default, so the rows
   arrived invisible: the right colour on the wrong ground, which looks like
   working code and reads as a broken list. The sheet is a raised surface, so
   its rows step DOWN, exactly as .pad--raised already makes them do inside a
   section. Stated here rather than by adding .pad--raised to the sheet, which
   would also drag that ground's padding and section rules onto a panel. */
.site-search-results .row-item { background: var(--surface-sunken); }
/* .site-search-results .row-item::before { --wipe-fill: var(--surface-sunken-strong); } */
/* ---- Search results page: current design-system rhythm --------------------
   Scoped to the page's own classes (.search-panel, .search-field,
   .search-results); the header panel (.site-search-*) is unchanged. The field
   is capped like every content control; results are full-width cards; on
   small screens the submit button becomes a full-width tap target below the
   field so the control never wraps awkwardly around a narrow input. */
.search-panel {
  display: grid;
  padding-block-start: clamp(16px, 2vw, 24px);
}

@media (max-width: 720px) {
  .search-panel .search-field {
    flex-wrap: wrap;
  }
  .search-panel .search-field .btn {
    inline-size: 100%;
    justify-content: center;
  }
}

/* The type label leads the row on this surface. In a result set the visitor is
   scanning for WHAT a thing is as much as what it is called - it is the one
   thing the spec names for these rows - so it sits above the title rather than
   under the description where the shared component puts it. */
.site-search-results .row-item-meta,
.search-results .row-item-meta {
  order: -1;
  color: var(--accent-text);
}