/**
 * @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;
}

/* Selected items in a multi-select. Tom Select hard-codes these at `#f2f2f2`
   on `#303030`, so the chip is light whatever it sits on: it fights a dark
   admin, and on a white form it is a near-white block on white, which reads as
   an artefact rather than a value. Measured 2026-08-30 on `bur__stageafrica`,
   where the chip came out `rgb(242, 242, 242)` on a `rgb(27, 27, 29)` control.

   Derived from the surrounding text colour for the same reason the highlighted
   dropdown row above is: a tint of `currentColor` is legible against whatever
   `currentColor` is itself legible on, so one rule serves both schemes and
   needs no media query. */
.ts-wrapper.multi .ts-control > div {
  background: var(--btx-ts-chip, color-mix(in srgb, currentColor 14%, transparent));
  color: inherit;
  border-color: var(--btx-ts-border, color-mix(in srgb, currentColor 30%, transparent));
}

/* The item being dragged or keyboard-selected. Tom Select darkens its own
   chip by a shade; this raises the same tint instead. */
.ts-wrapper.multi .ts-control > div.active {
  background: var(--btx-ts-chip-active, color-mix(in srgb, currentColor 24%, transparent));
  color: inherit;
}

/* Disabled. Tom Select states three greys here, all of them light. */
.ts-wrapper.multi.disabled .ts-control > div,
.ts-wrapper.multi.disabled .ts-control > div.active {
  background: var(--btx-ts-chip, color-mix(in srgb, currentColor 10%, transparent));
  color: inherit;
  opacity: .6;
}


/* The remove control on each selected item in a multi-select.

   Chosen drew one on every item, as `.search-choice-close`, with no setting
   behind it. This module did not, so the migration dropped the affordance
   rather than restyling it and left no way to unpick a wrong choice but the
   keyboard. Restored 2026-08-31 by enabling Tom Select's own `remove_button`,
   which ships in the bundle already loaded - there was nothing to write.

   The part worth writing was the mark. Chosen's was a base64 image with `#555`
   baked into it, which is the same fixed-colour fault as the chips above and
   goes invisible on a dark admin. This is Tabler's `x`, inlined as a mask
   rather than an image, so the ink is `currentColor` and follows the theme for
   free. The plugin's own `&times;` is replaced in the JS by a visually hidden
   label, so the control keeps an accessible name and draws only one mark. */
.ts-wrapper.plugin-remove_button .ts-control .item {
  --btx-ts-remove: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24'%3E%3Cpath fill='none' stroke='%23000' stroke-linecap='round' stroke-linejoin='round' stroke-width='2.5' d='M18 6L6 18M6 6l12 12'/%3E%3C/svg%3E");
}

.ts-wrapper.plugin-remove_button .ts-control .item .remove {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  width: 1.15em;
  height: 1.15em;
  /* The library zeroes the chip's right padding with
     `padding-right: 0 !important`, which leaves the mark flush against the
     chip edge and further from the label than from it. These two margins
     put it back inside the chip and closer to the text it removes, and
     they cancel, so the chip's width is unchanged. */
  margin-inline-start: .1em;
  margin-inline-end: .25em;
  padding: 0;
  border: 0;
  border-radius: 2px;
  /* Tom Select draws a 1px `#d0d0d0` rule between the label and the mark,
     from a selector carrying `:not(.rtl)` - which is why every rule in this
     block is qualified by `.ts-control`, to match that specificity rather
     than lose to it silently. Removed rather than recoloured: Chosen drew no
     divider, and at this size it reads as damage rather than structure. */
  border-left-width: 0;
  color: inherit;
  text-decoration: none;
  opacity: .6;
}

.ts-wrapper.plugin-remove_button .ts-control .item .remove::before {
  content: "";
  width: .7em;
  height: .7em;
  background-color: currentColor;
  -webkit-mask: var(--btx-ts-remove) center / contain no-repeat;
  mask: var(--btx-ts-remove) center / contain no-repeat;
}

/* Hover and keyboard focus share one treatment, derived from the text colour
   for the same reason everything else here is. */
.ts-wrapper.plugin-remove_button .ts-control .item .remove:hover,
.ts-wrapper.plugin-remove_button .ts-control .item .remove:focus-visible {
  background: color-mix(in srgb, currentColor 22%, transparent);
  opacity: 1;
}

/* A disabled widget offers no remove, matching how Chosen behaved. */
.ts-wrapper.plugin-remove_button.disabled .ts-control .item .remove {
  display: none;
}

/* An item being dragged restates the divider colour on its own selector. */
.ts-wrapper.plugin-remove_button .ts-control .item.active .remove {
  border-left-width: 0;
}