/**
 * @file
 * Base styling: makes the widget take the colours of whatever surrounds it.
 *
 * Tom Select's own stylesheet assumes a white page. It sets `background: #fff`
 * on the control and the dropdown and `color: #303030` as a literal on three
 * selectors at once. On Gin in dark mode that produced a white box with the
 * theme's light grey text inherited into it - measured 1.5:1, effectively
 * unreadable, while the native select beside it sat correctly on #3b3b3f.
 *
 * Fixing only the colour, as an earlier version of this file did, makes it
 * worse rather than better: light text then sits on a background that is still
 * white. Both have to move together.
 *
 * Every colour resolves through a three-step chain, most specific first:
 *
 * 1. `--btx-ts-*`, which a site or theme sets to say exactly what it wants.
 * 2. The theme's own token. `--body-bg` and friends are what `burtronix_base`
 *    and everything under it already style Chosen with, so taking them means
 *    the widget tracks each site's palette without this file knowing any site.
 * 3. A CSS system colour, `Field` and `FieldText`, which follow `color-scheme`.
 *    Gin sets `color-scheme: dark`, so these resolve to a dark field surface
 *    and light text with no theme knowledge at all.
 *
 * Step 3 is a floor, not a target: measured 2026-08-22, `Field` resolves to
 * rgb(59, 59, 59) in Chromium and rgb(43, 42, 51) in Firefox, neither of which
 * is Gin's rgb(59, 59, 63). It keeps an unstyled widget legible; the per-theme
 * files are what make it match.
 */

.ts-wrapper .ts-control,
.ts-wrapper.single.input-active .ts-control {
  background: var(--btx-ts-surface, var(--body-bg, Field));
  color: var(--btx-ts-text, var(--body-color, FieldText));
  border-color: var(--btx-ts-border, var(--border-color, color-mix(in srgb, currentColor 60%, transparent)));
}

/**
 * Colours only, and no geometry. That division is deliberate.
 *
 * A front end's control geometry is the theme's and cannot be guessed from
 * here. Measured on `now__energize` 2026-08-22: `burtronix_base` sets the
 * Chosen control from Bootstrap's own `$input-font-size`, and `nowmedia2024`
 * then overrides it to `--font-size-sm` for the Now brands. A module that
 * restated either would be right on some sites and wrong on the rest.
 *
 * So the front-end block belongs beside the Chosen block it replaces, in the
 * `burtronix_theme` package at
 * `theme/burtronix_base/scss/_main/base/_form.scss`, and each brand theme keeps
 * whatever override it already has. The admin themes are the module's business
 * because Claro and Gin are Drupal's, not a client's - and those are handled by
 * deferring to the theme's own chrome below rather than by restating it.
 */

/**
 * The typed text: the vendor stylesheet pins its colour to a dark grey, and
 * the browser gives the input its own font rather than the control's.
 *
 * The colour half is obvious. The font half is not, and it is what made the
 * control change size when it took focus: an `<input>` does not inherit font
 * from its parent unless told to, so the `.item` shown when idle and the
 * `<input>` shown when focused were set in different sizes and measured
 * differently. On `now__energize` /search 2026-08-28 the item was 12px on an
 * 18px line and the input 13px on 19.5px, so the control went 27.5px to 29px
 * on focus and moved the whole filter row by 2px every time a list opened.
 *
 * `font: inherit` fixes the cause without naming a size, which matters because
 * the size belongs to the theme - `nowmedia2024` narrows these controls to
 * `--font-size-sm` and `burtronix_base` does not. An earlier note in this file
 * reasoned about line height and concluded a stated height was the only fix.
 * It was reasoning about the wrong property.
 */
.ts-wrapper .ts-control > input {
  color: inherit;
  font: inherit;
}

/**
 * Where the theme has already drawn the box, stop drawing a second one.
 *
 * Tom Select copies the original select's classes onto its wrapper, so on
 * Claro and Gin the wrapper arrives carrying `form-element` and wearing the
 * theme's own input chrome. Measured on Gin 2026-08-22: the wrapper was
 * already an exact match for a real text input - background, colour, border
 * and 8px radius all identical - while `.ts-control` painted its own 36px box
 * with a second border inside that 52px one.
 *
 * So the fix is to take the inner box away rather than to restate the theme's
 * values, which is what the Chosen module does for the same two themes and for
 * the same reason. It costs nothing to track a theme that changes its mind.
 *
 * Keyed on the theme having actually painted the wrapper, rather than on a
 * theme name and rather than on the class alone. The class was the first
 * version of this test and it was wrong in one direction that matters: a front
 * end may class its selects `form-element` and still paint nothing, and
 * `bur__stageafrica` does exactly that. Stripping the control there took the
 * box away and put nothing back, so the widget had no surface at all - which
 * is the same fault as the see-through dropdown below and has the same cause.
 *
 * `btx-ts-painted` is added by the behaviour from the wrapper's computed
 * background at attach time. Where the theme paints, this fires and the
 * theme's chrome shows through; where it does not, this does not fire and the
 * rules above draw the box instead.
 */
.ts-wrapper.form-element.btx-ts-painted .ts-control,
.ts-wrapper.form-element.btx-ts-painted.single.input-active .ts-control {
  background: none;
  border: 0;
  border-radius: 0;
  box-shadow: none;
  color: inherit;
  font: inherit;
  padding: 0;
  min-height: 0;
}

/**
 * A single select is one line, however narrow the theme has made it.
 *
 * Tom Select lays the control out as a wrapping flex row and gives its input
 * `min-width: 7rem`, which is right for a multi-select - the chosen items are
 * meant to wrap onto new lines as they accumulate. On a single select there is
 * only ever one item, and that same rule is a fault: pick a value whose text
 * plus 7rem exceeds the control, and the input drops to a second line, so the
 * box doubles in height for as long as it holds focus and snaps back on blur.
 * Measured on Gin's status filter 2026-08-28, where the control is 65px wide:
 * choosing "Blocked" took it from 24px to 48px and the wrapper from 40 to 64.
 *
 * So on a single select the row does not wrap and the input may shrink to
 * nothing. Nothing is lost by that - the item is the value, the input is only
 * the search field, and it grows back the moment the item is cleared for a
 * search. Deliberately not scoped to `.form-element`: a narrow front-end
 * select meets this too, and a wide one is unaffected either way.
 */
.ts-wrapper.single .ts-control {
  flex-wrap: nowrap;
}

.ts-wrapper.single .ts-control > input {
  min-width: 0;
}


/**
 * A note on the Firefox open-and-grow fault, which is not fixed here.
 *
 * The branding repository found that opening a Tom Select control grew it from
 * 36px to 38px in Firefox and not in Chromium: nothing declares a line height
 * on the control's input, so it takes `normal`, which is the font's own metric
 * rather than a number the CSS names - 18px in Chromium and 20px in Firefox at
 * the same size. Two obvious fixes do not work. Setting `line-height` on the
 * input does nothing, because the vendored stylesheet pins it to
 * `line-height: inherit !important`; setting it on the control does nothing
 * either, because Firefox ignores an author line height on a text input.
 * Stating the box height is what worked there.
 *
 * Measured here 2026-08-22, on Gin admin and on the `burtronix_base` front end,
 * in both engines, opened and closed: no jump, 36px throughout. So there is
 * nothing to correct, and a stated height would be a guess at a size the theme
 * owns. It is recorded because it is a real fault with a non-obvious cause, and
 * because a theme with a different font may yet meet it - at which point the
 * fix is `min-height` and not `height`, since Drupal has multi-selects that
 * grow with their chosen items.
 */

/* The dropdown is a floating surface, so it needs an opaque background rather
   than a transparent one - it sits over page content, not in the form flow.
   No margin, radius or shadow override: Tom Select opens the list 4px clear of
   the control and casts a small shadow, and both are what tell the eye the
   list is above the control rather than beside it. Flattening them was a
   measured mistake in the branding repository. */
.ts-dropdown {
  background: var(--btx-ts-drop, var(--btx-ts-surface, var(--body-bg, Field)));
  color: var(--btx-ts-text, var(--body-color, FieldText));
  border-color: var(--btx-ts-border, var(--border-color, color-mix(in srgb, currentColor 60%, transparent)));
}

.ts-dropdown .option {
  color: inherit;
}

/**
 * The group heading, which the vendor stylesheet pins to a white bar.
 *
 * Tom Select styles `.optgroup-header` with its own light background and dark
 * text, on the same assumption as the rest of its sheet - that the page is
 * white. Any select Drupal renders with `<optgroup>` therefore had light bars
 * across a dark list: the permission filter on `/admin/people` has one per
 * module, so most of that dropdown was the wrong colour. Reported 2026-08-28.
 *
 * Same chain as everything else, and `transparent` for the background so the
 * heading sits on the list rather than on a bar of its own - the weight and
 * the spacing are what separate it, which is what the rest of the admin does.
 */
.ts-dropdown .optgroup-header {
  background: transparent;
  color: var(--btx-ts-text, var(--body-color, FieldText));
  font-weight: 700;
  opacity: .75;
}

.ts-wrapper.form-element .ts-dropdown .optgroup-header {
  color: inherit;
}

/**
 * On a themed wrapper the dropdown takes the wrapper's colours outright.
 *
 * Tom Select builds the dropdown as a child of the wrapper, so `inherit` here
 * resolves to whatever chrome the theme has already put on the wrapper - which
 * is exactly what the list should be wearing, and needs no theme's token names.
 * Measured on Gin 2026-08-22, in both engines: without it the dropdown fell
 * back to the system colour and missed the control beside it; with it,
 * background, text and border match the wrapper exactly.
 *
 * Scoped to a wrapper the theme has actually painted, which is not the same
 * question as whether it carries `form-element`. This rule was keyed on the
 * class alone until 2026-08-28, on the stated assumption that a front end
 * never classes its selects that way. `bur__stageafrica` does: its search
 * filters carry `form-select form-element` with no background, so the list
 * inherited `transparent` and the options floated over the page with the
 * content legible through them. The behaviour reads the wrapper's computed
 * background once at attach and adds `btx-ts-painted` when there is one, so
 * the two cases separate on the fact rather than on a proxy for it.
 *
 * The text colour is not conditional. A colour always resolves to something,
 * a background may resolve to nothing, and that difference is the whole bug.
 */
.ts-wrapper.form-element .ts-dropdown {
  color: inherit;
}

.ts-wrapper.form-element.btx-ts-painted .ts-dropdown {
  background-color: inherit;
  border-color: inherit;
}

/**
 * And take only the colour, never the picture.
 *
 * `background: inherit` was the first version of the rule above, and it
 * inherited the whole shorthand - `background-image` included. Gin draws its
 * drop-down arrow as an SVG data URI on the select's own box, at
 * `100% 50%`; the list is a child of that box, so it inherited the arrow and
 * painted a second one over itself, right-aligned and vertically centred.
 * On the three-row status filter that put a chevron beside the middle row and
 * made "Active" look like it opened a submenu. Reported 2026-08-28.
 */
.ts-wrapper .ts-dropdown {
  background-image: none;
}

/* The highlighted row. Derived from the surrounding text colour rather than
   stated, so it stays visible on a surface this file cannot know the colour of.
   Tom Select's own value is a pale blue that disappears on a dark dropdown. */
.ts-dropdown .active {
  background: var(--btx-ts-highlight, color-mix(in srgb, currentColor 18%, transparent));
  color: inherit;
}

/* An option Tom Select has disabled. It writes `aria-disabled`, while its own
   stylesheet styles `[data-disabled]`, which it writes on a disabled optgroup -
   so without this rule a disabled option looks live and merely fails to
   respond. Carried from the branding repository, which found the same gap. */
.ts-dropdown .option[aria-disabled="true"] {
  opacity: .5;
  cursor: default;
}

/* A select that has opted out keeps its native appearance. */
select.tom-select-disable {
  display: inline-block;
}

/* Right to left, carried over from Chosen because it costs three lines. */
.tom-select-rtl .ts-control,
.tom-select-rtl .ts-dropdown {
  direction: rtl;
  text-align: right;
}