/**
 * @file
 * Visual styles for buttons.
 *
 * Drupal's Form API renders its buttons as `<input type="submit">`, carrying
 * the `button` class and, when the form says so, `button--primary` /
 * `button--danger` (\Drupal\Core\Render\Element\Button::preRenderButton).
 * None of that markup can be routed through the `button` SDC: an `<input>`
 * cannot hold the icon span and label span the component renders, and
 * swapping the control for a `<button>` would change what core's own
 * form-submit and AJAX JavaScript binds to. So these controls are painted
 * here, from the same design tokens the component uses, rather than being
 * rebuilt as it - the same call file.css and feedback-dialog.css already
 * make for the controls core hands them.
 *
 * The recipe is `button`'s size `base` (h-11, px-4, text-sm/medium,
 * rounded-base, 1px border, shadow-xs) in its `secondary` and `primary`
 * variants. `secondary` is the resting state, because that is what a
 * `button` with no modifier means in Drupal - the form's ordinary action; a
 * form says which of its buttons leads by setting `#button_type: primary`,
 * and only then does the primary rule take over. Anything the design has no
 * variant for - `button--danger`, for one - falls through to `secondary`
 * rather than being invented here.
 *
 * Buttons the theme renders itself through the SDC are excluded by
 * `:not([data-component-id])`: the component's own Tailwind utilities live
 * in css/style.css, which loads after this file, so they would win anyway -
 * the guard states the boundary instead of relying on that order.
 *
 * Every rule below carries exactly two classes' worth of specificity, so
 * `button--primary` wins over the resting fill on being written later. The
 * one exception is the `display` rule, and it says why it is one.
 *
 * @see web/themes/custom/dkg_theme/components/button/button.twig
 */

/*
 * The side margins carry the same `:not([data-component-id])` guard every
 * other rule in this file does, and for the same reason: a button the theme
 * draws through the SDC is spaced by whatever lays it out - the listing
 * card's header sets a `gap`, the dialog's button pane sets its own - and a
 * 1em margin written for a button standing in running text adds 14px to
 * each of those on every control after the first. Without the guard it
 * showed on the open cases listing and nowhere else, that being the one
 * listing offering two bulk actions.
 *
 * The guard has to be on the margin, not on a reset somewhere downstream:
 * this stylesheet is unlayered, so no Tailwind utility can take a margin
 * back off, and the element utilities that used to do it here stopped
 * matching when the buttons became `<button>` rather than `<input>`.
 */
.button:not([data-component-id]),
.image-button:not([data-component-id]) {
  margin-right: 1em;
  margin-left: 1em;
}
.button:not([data-component-id]):first-child,
.image-button:not([data-component-id]):first-child {
  margin-right: 0;
  margin-left: 0;
}

/*
 * The box, plus the secondary fill. Height is fixed rather than derived from
 * padding, for the reason button.twig gives: Figma draws its 1px stroke
 * inside the frame, so a bordered and a borderless button only line up in a
 * row when the border is inside the stated height.
 */
.button:not([data-component-id]) {
  box-sizing: border-box;
  align-items: center;
  justify-content: center;
  gap: 0.375rem;
  height: 2.75rem;
  padding: 0 1rem;
  border: 1px solid var(--color-border);
  border-radius: var(--radius-base);
  background-color: var(--color-surface-secondary);
  box-shadow: 0 1px 2px 0 rgb(0 0 0 / 5%);
  color: var(--color-body);
  font-size: 0.875rem;
  font-weight: 500;
  line-height: 1.25rem;
  white-space: nowrap;
  text-decoration: none;
  cursor: pointer;
  transition: background-color 150ms, color 150ms;
  appearance: none;
}

/*
 * `display` on its own, so it can carry the `:not(.js-hide)` guard the rest
 * of the file must not: core's "hidden while JavaScript is on" utility
 * (`.js-hide.js-hide { display: none }`, system/css/components/js.module.css)
 * has the same specificity as the selector above and ships in the `base`
 * asset group, which loads before this file's `component` group - so a
 * `display` declared there would win and reveal every button core, or this
 * theme, meant to keep out of sight. Not hypothetical: the file widget's
 * upload submit and the "Remove selected" submit behind the design's
 * per-file trash control are both `js-hide`n buttons.
 *
 * `js-show`, the mirror utility, needs no such guard - nothing on this site
 * puts it on a button.
 *
 * @see \Drupal\dkg_theme\Hook\FormHooks::preprocessFileManagedFile()
 */
.button:not([data-component-id]):not(.js-hide) {
  display: inline-flex;
}

.button:not([data-component-id]):hover,
.button:not([data-component-id]):focus-visible {
  background-color: var(--color-tertiary-medium);
  color: var(--color-fg-brand);
}
.button:not([data-component-id]):focus-visible {
  box-shadow: none;
  outline: 2px solid var(--color-tertiary);
  outline-offset: 2px;
}

.button--primary:not([data-component-id]) {
  border-color: transparent;
  background-color: var(--color-brand);
  color: var(--color-white-alternating);
}
.button--primary:not([data-component-id]):hover,
.button--primary:not([data-component-id]):focus-visible {
  background-color: var(--color-brand-strong);
  color: var(--color-white-alternating);
}
.button--primary:not([data-component-id]):focus-visible {
  outline-color: var(--color-brand-medium);
}

/* `is-disabled` is core's own class for a button disabled from JavaScript,
   which carries no `:disabled` pseudo-class of its own. */
.button:not([data-component-id]):disabled,
.button:not([data-component-id]).is-disabled {
  border-color: var(--color-border);
  background-color: var(--color-disabled);
  box-shadow: 0 1px 2px 0 rgb(0 0 0 / 5%);
  color: var(--color-fg-disabled);
  cursor: not-allowed;
  pointer-events: none;
}

/*
 * The search form's trailing control - the "Search" button joined to the
 * query field's trailing edge in the site header and on the results page.
 *
 * Painted here rather than from utilities on the component's own wrapper,
 * because those utilities lose. Tailwind emits them inside
 * `@layer utilities` while every rule in this file is unlayered, and an
 * unlayered normal declaration beats a layered one whatever its
 * specificity - so the resting `.button` paint above took the fill, the
 * radius and the height, and the control rendered as an ordinary secondary
 * button with all four corners rounded next to a field it should be joined
 * to.
 *
 * Three classes' worth of specificity is what puts these declarations ahead
 * of this file's own two-class rules. The radius is the mirror of the
 * field's `rounded-l-base`, and `height: auto` with `align-self: stretch`
 * is what makes the button take the field's 46px rather than the 44px the
 * box above fixes it at - the design joins them into one shape, and a
 * button 2px short of the field leaves a notch at the bottom.
 *
 * @see web/themes/custom/dkg_theme/components/search-form/search-form.twig
 */
.dkg-search-submit .button:not([data-component-id]) {
  align-self: stretch;
  height: auto;
  border-color: transparent;
  border-radius: 0 var(--radius-base) var(--radius-base) 0;
  background-color: var(--color-brand);
  color: var(--color-white-alternating);
}
.dkg-search-submit .button:not([data-component-id]):hover,
.dkg-search-submit .button:not([data-component-id]):focus-visible {
  background-color: var(--color-brand-strong);
  color: var(--color-white-alternating);
}
.dkg-search-submit .button:not([data-component-id]):focus-visible {
  outline-color: var(--color-brand-medium);
}