/*
 * Store-wide feedback: errors, successes, and the things WooCommerce tells a
 * shopper on the way through.
 *
 * WHAT WAS BROKEN, because it was two separate bugs wearing one costume.
 *
 * 1. Scope. The only notice rule this theme had lived in components/woo.css
 *    and was written as `.woocommerce-notices-wrapper .woocommerce-error` —
 *    a DESCENDANT of the wrapper. That wrapper is only one of the places
 *    WooCommerce puts notices. The checkout's own validation errors, the ones
 *    a shopper sees most and at the worst possible moment, are returned by
 *    `WC_AJAX::checkout()` as `<div class="woocommerce-NoticeGroup
 *    woocommerce-NoticeGroup-checkout">` and injected into the form by
 *    frontend/checkout.js — never inside `.woocommerce-notices-wrapper`, so
 *    never matched. With `woocommerce_enqueue_styles` filtered to an empty
 *    array (WooCommerce\Support::init()) there is no core stylesheet behind
 *    it either: a failed checkout submission printed browser-default black
 *    text on white, indistinguishable from body copy.
 *
 * 2. Meaning. That one rule painted `.woocommerce-error`,
 *    `.woocommerce-message` and `.woocommerce-info` IDENTICALLY — accent
 *    tint, accent border, accent ink. "Produto adicionado ao carrinho" and
 *    "Seu cartão foi recusado" were the same object on screen, and the only
 *    thing distinguishing them was the sentence itself.
 *
 * THE COLOUR DECISION. This palette has no green and no blue — tokens.css is
 * ink, greys and one red, and it is the only file allowed to hold a hex
 * literal, so inventing a success hue would mean adding a third brand colour
 * the design handoff never specifies. So the split is by ROLE, not by adding
 * a colour: red is reserved for errors alone, and success/info take the
 * neutral ink treatment. This is stricter than convention (a green success
 * banner) and reads better here, because on a page where nothing else is red,
 * an error becomes the only red thing on it.
 *
 * Type is also carried by shape, not colour alone: every notice gets a 4px
 * leading edge in its own colour, so the three kinds stay distinguishable to
 * a shopper who cannot separate the red from the ink (WCAG 1.4.1 — colour is
 * never the only channel).
 *
 * SELECTOR SPELLING. .stylelintrc's frozen selector-class-pattern allows
 * lowercase `woocommerce`-prefixed classes, which covers most of this file.
 * Two do not qualify and go through an attribute selector instead — the
 * precedent components/woo.css set with `[class~="product-remove"]`:
 * `woocommerce-NoticeGroup` carries capitals the pattern does not admit, and
 * `required` has no prefix at all.
 */

/*
 * One list of containers, covering every place WooCommerce emits a notice:
 * the theme's own wrapper, the checkout's AJAX group, and the bare classes
 * that appear inline on the cart, the account pages and the thank-you page.
 */
.woocommerce-notice,
.woocommerce-message,
.woocommerce-info,
.woocommerce-error {
  display: block;
  padding: 14px 16px;
  margin-block: 0 var(--st-grid-gap);
  border: var(--st-border-width) solid var(--st-ink);
  border-inline-start-width: 4px;
  background: var(--st-surface-2);
  color: var(--st-ink);
  font-size: var(--st-size-body-sm);
  line-height: var(--st-lh-body);
  list-style: none;
}

/*
 * Errors, and only errors, are red. --st-accent for the rule (the handoff's
 * own validation colour) over --st-accent-tint, with --st-accent-ink text:
 * tokens.css is explicit that --st-accent is NEVER a body-text colour, and
 * an error message is body text a shopper has to read carefully.
 */
.woocommerce-error,
.woocommerce-notice--error {
  border-color: var(--st-accent);
  background: var(--st-accent-tint);
  color: var(--st-accent-ink);
  font-weight: var(--st-weight-bold);
}

/*
 * WooCommerce renders errors as a <ul> and successes as a <div>/<p>, so an
 * error with two problems in it arrives as two <li>. Indented rather than
 * bulletless: with more than one, the shopper needs to see they are separate
 * items, and `list-style: none` on the container above has already removed
 * the marker the browser would have given them.
 */
.woocommerce-error li {
  margin-block-start: 6px;
}

.woocommerce-error li:first-child {
  margin-block-start: 0;
}

/* The "Voltar ao carrinho"-style link WooCommerce puts inside a notice. */
.woocommerce-error a,
.woocommerce-message a,
.woocommerce-info a {
  color: inherit;
  font-weight: var(--st-weight-extrabold);
  text-decoration: underline;
}

/*
 * The checkout's AJAX error group.
 *
 * It is its own element wrapping the `.woocommerce-error` above, so it
 * contributes spacing only — and scroll-margin, which is the part that
 * matters. WooCommerce's checkout.js calls `scroll_to_notices()` on a failed
 * submission; without this the browser lands the notice at viewport top,
 * underneath the sticky checkout header, and the shopper is scrolled to an
 * error they cannot see. 120px clears the header and its stepper band.
 */
[class~="woocommerce-NoticeGroup"] {
  margin-block-end: var(--st-grid-gap);
  scroll-margin-block-start: 120px;
}

.woocommerce-notices-wrapper {
  scroll-margin-block-start: 120px;
}

/* An empty wrapper still occupies its margin box, leaving a gap above the
   page content on every request that produced no notice at all. */
.woocommerce-notices-wrapper:empty {
  display: none;
}

/*
 * The wrapper's measure.
 *
 * WooCommerce prints `.woocommerce-notices-wrapper` as a direct descendant of
 * `<main>` on the cart, the account pages and anywhere else its shortcode
 * renders — outside every `.st-container` on the page. That was invisible
 * while the notice had no border to see, and obvious the moment it got one:
 * a bordered box running the full width of the window, with the cart's own
 * content indented 24px inside it.
 *
 * Matched as a direct child of `.st-main` (or of the `.woocommerce` div
 * WooCommerce wraps its shortcodes in) rather than globally, because the
 * checkout puts its own wrapper inside `.st-checkout__notices`, which already
 * has the funnel's narrower measure — a blanket rule would widen it back out
 * to 1360px on the one screen that deliberately is not.
 */
.st-main > .woocommerce-notices-wrapper,
.st-main > .woocommerce > .woocommerce-notices-wrapper {
  width: 100%;
  max-width: var(--st-container);
  margin-inline: auto;
  padding-inline: var(--st-gutter);
}

/*
 * Field-level validation.
 *
 * components/field.css has carried `.st-field--error` and `.st-field__error`
 * since Phase 1 — the handoff's spec verbatim ("Erro de validação: borda
 * `2px #ec3013` no campo e mensagem 13 px em `#ae1800` abaixo") — and nothing
 * in this theme has ever emitted either class. WooCommerce marks an invalid
 * field by putting `.woocommerce-invalid` on the row WRAPPER, not on the
 * input, so this translates core's state into the treatment that was already
 * designed and waiting.
 *
 * `.woocommerce-invalid-required-field` is the subset core adds for an empty
 * required field; it always arrives alongside `.woocommerce-invalid`, so
 * matching the general class covers both.
 */
.woocommerce-invalid input,
.woocommerce-invalid select,
.woocommerce-invalid textarea,
.woocommerce-invalid .st-field {
  border-color: var(--st-accent);
}

.woocommerce-invalid label {
  color: var(--st-accent-deep);
}

/*
 * The validated-clean state. Core adds `.woocommerce-validated` as the
 * shopper leaves a field it is happy with; left unstyled the row simply
 * reverts, which reads as "nothing happened" right after an error was shown
 * there. The ink border is the field's own resting treatment made explicit,
 * so correcting a field visibly clears it.
 */
.woocommerce-validated input,
.woocommerce-validated select,
.woocommerce-validated textarea,
.woocommerce-validated .st-field {
  border-color: var(--st-ink);
}

/*
 * The message WooCommerce prints UNDER an invalid field, plus the two other
 * inline notes it can render there.
 *
 * `checkout-inline-error-message` is the checkout's own, and it is the one
 * that mattered most: WooCommerce's checkout.js writes one under every field
 * that failed validation, referenced from the input's `aria-describedby`, so
 * it is what a screen reader reads out and what a sighted shopper reads while
 * correcting the field. Unstyled it rendered at full 16.5px body size in
 * black — eight of them at once after an empty submission, each pushing its
 * neighbours down the grid.
 *
 * All three mirror `.st-field__error` exactly (13px, --st-accent-deep, 6px
 * below the field) — the handoff's own spec, "mensagem 13 px em #ae1800
 * abaixo" — so a theme-rendered message and a WooCommerce-rendered one are
 * the same object to a shopper.
 *
 * `checkout-inline-error-message` carries no `woocommerce` prefix, so it is
 * reached through an attribute selector like the other two exceptions above.
 */
[class~="checkout-inline-error-message"],
.woocommerce-error-message,
.woocommerce-password-hint {
  display: block;
  margin-block: 6px 0;
  color: var(--st-accent-deep);
  font-size: var(--st-size-label);
  font-weight: var(--st-weight-regular);
  line-height: var(--st-lh-tight);
}

/*
 * The required-field asterisk. Core marks it `aria-hidden` and pairs it with
 * visually-hidden "Obrigatório" text, so this is decoration — but decoration
 * that should read as the accent, not as body copy.
 */
.woocommerce-input-wrapper [class~="required"],
.woocommerce-form-row [class~="required"] {
  color: var(--st-accent);
  text-decoration: none;
}

@media (max-width: 599px) {
  .woocommerce-notice,
  .woocommerce-message,
  .woocommerce-info,
  .woocommerce-error {
    padding: 12px 14px;
  }

  [class~="woocommerce-NoticeGroup"],
  .woocommerce-notices-wrapper {
    scroll-margin-block-start: 80px;
  }
}