/**
 * Drupal core button vocabulary (TS-5130, epic TS-5127).
 *
 * The theme dresses Bootstrap's vocabulary (.btn, .btn-primary) and nothing
 * else. Drupal core emits its OWN classes for every Form API action and for
 * action links: .button, .button--primary, .button--danger. Those received
 * only a hover transition, so server-rendered actions rendered as plain
 * text. That is why the filming-space action row looked like prose, and it
 * would recur on every new server-rendered page. Rather than each page
 * patching its own buttons, teach the theme core's vocabulary once.
 *
 * Colours here deliberately reuse the CURRENT theme variables rather than
 * the new design tokens. A core-vocabulary button and a Bootstrap button
 * frequently sit in the same action row, so they must match; repainting the
 * estate onto the tokens is a later ticket that moves both together.
 *
 * Specificity is kept to a single class so that any existing, more specific
 * rule still wins and no current button changes appearance.
 */

/* Shared shape. Mirrors .btn.btn-primary's metrics so the two vocabularies
   are indistinguishable when they sit side by side. */
.button:not(.btn) {
  display: inline-block;
  padding: 10px 18px;
  border-radius: 10px;
  font-size: 14px;
  font-weight: 600;
  /* 1.5, matching .btn.btn-primary's computed value. This said 1.2 while
     claiming to mirror it, so a Form API action sat 4.2px shorter than a
     Bootstrap button in the same row. */
  line-height: 1.5;
  text-align: center;
  text-decoration: none;
  cursor: pointer;
  transition: background-color 120ms ease, color 120ms ease, border-color 120ms ease;
}

/* Default: outlined. A bare .button is a secondary action (Cancel, a
   sideways link), so it reads as an action without competing with the
   primary one beside it. */
.button:not(.btn) {
  background-color: #ffffff;
  color: var(--primary-color);
  border: 2px solid var(--primary-color);
}

.button:not(.btn):hover,
.button:not(.btn):focus-visible {
  background-color: var(--primary-color);
  color: #ffffff;
  text-decoration: none;
}

/* Primary: filled. */
.button--primary:not(.btn) {
  background-color: var(--primary-color);
  color: #ffffff;
  border-color: var(--primary-color);
}

.button--primary:not(.btn):hover,
.button--primary:not(.btn):focus-visible {
  /* The theme's established hover-darken for brand purple. */
  background-color: #481e4d;
  border-color: #481e4d;
  color: #ffffff;
}

/* Danger. Solid for now so it matches the Bootstrap danger buttons already
   on screen. The agreed hazard tape-tab treatment lands with the component
   work, which changes both vocabularies together. */
.button--danger:not(.btn) {
  background-color: #c62828;
  color: #ffffff;
  border-color: #c62828;
}

.button--danger:not(.btn):hover,
.button--danger:not(.btn):focus-visible {
  background-color: #a61b1b;
  border-color: #a61b1b;
  color: #ffffff;
}

/* Disabled state, which Drupal applies to form actions during submission. */
.button:not(.btn):disabled,
.button:not(.btn).is-disabled {
  opacity: 0.6;
  cursor: not-allowed;
}

@media (prefers-reduced-motion: reduce) {
  .button:not(.btn) {
    transition: none;
  }
}

/* CORRECTION, live regression 2026-07-29.
 *
 * Every rule here is scoped :not(.btn). Drupal adds its own classes to a
 * submit while the form ALSO carries Bootstrap ones, so a real button on
 * live read:
 *
 *   class="... w-100 mb-3 button js-form-submit form-submit btn btn-primary"
 *
 * .btn.btn-primary won the background at two classes of specificity, but
 * only the bare .button rule here set a colour, so the label came out
 * purple on a purple fill and vanished. The earlier check confirmed
 * .btn.btn-primary beats .button--primary and stopped there; it missed that
 * an element can carry BARE .button alongside a Bootstrap fill.
 *
 * An element using the Bootstrap vocabulary already has a complete
 * treatment. Ours applies only where core's vocabulary stands alone.
 */