/* ============================================================
   OberBuilt Analysis Engine — shared button component
   ------------------------------------------------------------
   `.oae-btn` and its four modifiers were being used in ten
   templates — 19 usages across the upload preflight gate, the
   verdict share panel, the verdict PDF CTA, the credit-grant
   thank-you page, the shares list, the credits balance and
   history tabs, the notification preferences tab, the
   notifications inbox, and the one-click unsubscribe handler —
   and NOTHING IN THE REPOSITORY DEFINED THEM. Every one of those
   buttons rendered as whatever the active theme happened to do
   with a bare <button> or <a>, which is why they look like Divi
   buttons on some surfaces and like plain text on others.

   This file is the definition. It is enqueued alongside
   tokens.css from Assets::ensureTokens(), because that is the
   single choke point every surface already passes through — a
   per-surface enqueue would have to be added in ten places and
   would be forgotten on the eleventh.

   ---------- WHY THE SELECTORS ARE DOUBLED ----------
   `.oae-btn` alone is (0,1,0) and would LOSE to the documented
   `.oae-shell button` reset (0,1,1) that every app-shell page
   carries — the same trap oae-bell.css hit and documented, where
   an unmatched bell action "would lose the reset and render as
   unstyled chrome text". `.oae-btn.oae-btn` repeats the class to
   reach (0,2,0) without introducing a parent scope, so this
   component works identically inside .oae-shell, inside a
   WooCommerce My Account tab, and inside a bare Divi page.
   It is deliberately not (0,3,0): a per-surface rule at (0,2,0)
   plus a state still needs to be able to win.

   ---------- COLOUR ----------
   Every value is a token, and only tokens the theme's own
   light-mode remap actually covers. On WooCommerce My Account
   pages the active theme re-points 16 of the plugin's colour
   tokens at a light palette scoped to `.woocommerce-account`,
   so a button built from --oae-color-primary / --oae-fg-1 /
   --oae-border renders correctly light there and dark
   everywhere else with no extra rules. Three tokens are NOT
   covered by that remap — --oae-color-surface-alt,
   --oae-color-warn and --oae-fg-on-danger — so none of them is
   used here. See oae-inbox.css for the full note.
   ============================================================ */

.oae-btn.oae-btn {
  /* The Divi gotcha: without an explicit appearance reset a plugin
     <button> inherits theme chrome or loses all of it and renders
     as bare text. tokens.css guarantees a clean slate; this paints
     on it. */
  appearance: none;
  -webkit-appearance: none;
  box-sizing: border-box;
  display: inline-flex;
  align-items: center;
  justify-content: center;
  gap: var(--oae-spacing-sm);
  min-height: var(--oae-touch-target);
  padding: var(--oae-spacing-sm) var(--oae-spacing-lg);
  border: 1px solid transparent;
  border-radius: var(--oae-radius);
  font-family: var(--oae-font-heading);
  font-size: var(--oae-text-body);
  font-weight: 700;
  line-height: var(--oae-line-height-tight);
  letter-spacing: 0.01em;
  text-align: center;
  text-decoration: none;
  cursor: pointer;
  transition: background-color var(--oae-motion-duration) var(--oae-motion-ease),
              border-color var(--oae-motion-duration) var(--oae-motion-ease),
              color var(--oae-motion-duration) var(--oae-motion-ease);
}

/* Default (no modifier) reads as secondary rather than as nothing, so a
   `.oae-btn` that ships without a modifier is still a visible button. */
.oae-btn.oae-btn {
  background: transparent;
  color: var(--oae-fg-1);
  border-color: var(--oae-border-control);
}

.oae-btn.oae-btn--primary {
  background: var(--oae-color-primary);
  color: var(--oae-fg-on-primary);
  border-color: transparent;
}

.oae-btn.oae-btn--secondary {
  background: transparent;
  color: var(--oae-fg-1);
  border-color: var(--oae-border-control);
}

/* Ghost is the lowest-emphasis variant: no border at all, so it reads as a
   link that happens to be a button. Still gets the full touch target. */
.oae-btn.oae-btn--ghost {
  background: transparent;
  color: var(--oae-color-primary);
  border-color: transparent;
  padding-inline: var(--oae-spacing-md);
}

.oae-btn.oae-btn--danger {
  background: var(--oae-color-danger);
  color: var(--oae-fg-on-danger);
  border-color: transparent;
}

/* ---------- States ---------- */

.oae-btn.oae-btn--primary:hover {
  background: var(--oae-color-primary-hover);
}

.oae-btn.oae-btn--secondary:hover,
.oae-btn.oae-btn:hover {
  border-color: var(--oae-border-control-strong);
  background: var(--oae-color-primary-wash);
}

.oae-btn.oae-btn--ghost:hover {
  background: var(--oae-color-primary-tint);
}

/* Danger hover darkens via filter rather than a second red token: there is
   exactly ONE danger colour in this system by design (see the "Danger: ONE
   red" note in tokens.css) and adding a hover variant would reopen that. */
.oae-btn.oae-btn--danger:hover {
  filter: brightness(1.08);
}

/* Disabled must not rely on colour alone either — opacity plus the
   not-allowed cursor plus the removed hover give three signals, and the
   attribute itself carries the semantics for assistive tech. */
.oae-btn.oae-btn[disabled],
.oae-btn.oae-btn[aria-disabled="true"] {
  opacity: 0.55;
  cursor: not-allowed;
  filter: none;
}

.oae-btn.oae-btn[disabled]:hover,
.oae-btn.oae-btn[aria-disabled="true"]:hover {
  background: inherit;
  border-color: inherit;
}

/* Busy state for buttons that fire a request and disable themselves. */
.oae-btn.oae-btn[aria-busy="true"] {
  cursor: progress;
}

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