/* ==========================================================================
   THE NOTICE COMPONENT
   16 September 2026.

   One element, `.oo-notice`, with a TIER and a TONE. `inc/notices.php` renders
   it and every surface that has something to tell a customer calls that rather
   than writing a paragraph of its own.

   WHY THIS FILE EXISTS AT ALL, rather than another block in `order.css`. The
   same component has to be on the menu page, which loads `order.css`, and on
   Orderable Pro's checkout, which loads `checkout.css` instead -- the two files
   never load together, so anything they both need is written twice and drifts.
   The pause banner is the proof: it was an amber box in `order.css` with four
   hex literals in it, and on the checkout it was the same four literals again.

   WHERE IT LOADS, AND WHY THAT IS NOT A RACE. `inc/notices.php` enqueues it
   after `oo-order` on the menu and after `oo-checkout` on the checkout, and on
   the checkout it also names `orderable-checkout-pro` as a dependency when that
   handle is registered. Pro's sheet reaches every element on the page --
   `body.woocommerce-checkout * { font-size: 16px; line-height: 1.4 }` and two
   dozen more document-level rules -- and a rule that matches an element
   directly beats anything it inherits, so the order this sheet prints in is the
   whole of whether it works. Stating the dependency makes WordPress's own sort
   answer it; the alternative was `!important` on every line, which is what the
   demo sheets had to do because an mu-plugin cannot enqueue from inside Pro's
   own action.

   THE FOUR TIERS. The tier is a fact about the message's behaviour and not a
   choice of colour, which is the whole of what Ryan settled on 16 September
   2026 after looking at MUI's alert, Stripe's declined-card banner and Slack's
   and Drive's toasts:

     1  --feedback   something just happened and it can be dismissed. A neutral
                     white card, the tone in the glyph and nowhere else, ink
                     text. A shadow when it floats over the page and none when
                     it sits in the flow.
     2  --guidance   said inline, next to the thing it is about. Ink text, no
                     fill, glyph optional. The field notices and the resolver
                     line already were this; they carry the class now and
                     nothing else about them changed.
     3  --state      true right now, and it leaves when the state does. The
                     tinted alert, and NO close button, because closing it would
                     be a lie.
     4  --block      the customer is about to lose something. Filled, white
                     text, white glyph. Three messages and no more: the refused
                     order, the declined card, and a payment that failed on the
                     order-received page.

   Ryan on why the fills are not everywhere: they are "overly distracting for
   many of our purposes". And on the border: "Subtle border wins ... maybe a
   really subtle outline would improve contrast from the white page."

   THE TONES ARE DERIVED FROM THREE COLOURS. A site skin redeclares
   `--oo-notice-amber`, `--oo-notice-green` and `--oo-notice-red` and gets its
   own tints and borders, because those are `color-mix()` of the tone and not
   values typed out four times. The ground is the tone 9% into white and the
   border is the tone 25% into that ground.

   THE TEXT COLOUR CANNOT BE DERIVED AND IS NOT PRETENDING TO BE. It is the tone
   walked down in HSL lightness until APCA reads Lc 75 on its own tint, which is
   the bar for body text at this size (`fleet/guard-verdicts.txt`, "Contrast"),
   and CSS has no function for "dark enough to read". So the three values below
   are the defaults a skin inherits until it overrides them, and
   `shotter/contrast.mjs --pair` is what checks a skin that does.

   THE GLYPH TAKES THE DARKENED TONE AND NEVER THE RAW ONE. Measured: #ffcc00 on
   its own #fffae8 tint is WCAG 1.45:1 and APCA Lc +20.5 -- a shape you cannot
   see. So the glyph is the same colour as the text beside it on all four
   tints, and only tier 4 reverses it to white.

   INFO IS THE CLIENT'S OWN COLOUR. `--oo-brand` is `--oo-accent-chosen` and
   falls back to `--oo-ink`, so an unbranded site's information tone is its
   near-black and a branded one's is the restaurant's colour. It is not a fixed
   blue, and it is not WordPress's link blue: `inc/color-tokens.php` refuses
   GeneratePress's own default.
   ========================================================================== */

:root {
	/* The three a skin redeclares. */
	--oo-notice-amber: #ffcc00;
	--oo-notice-green: #006b2e;
	--oo-notice-red: #b8001f;

	/* And the fourth, which is the site's own. */
	--oo-notice-info: var(--oo-brand, var(--oo-ink, #16181c));

	/* AND THE FIFTH, WHICH IS NEWS AND NOT A SEVERITY -- DECLARED, AND USED BY
	   NOTHING (25 September 2026, stood down 26 September).

	   It was made for the sold-out band and held it for one day. Ryan asked for
	   grey looking at a band drawn in Sonora's cyan, which was never a tone
	   this system had chosen but the kind/tone collision `assets/notices.js`
	   records; having seen the amber the band was designed in on 16 September
	   he put it back: "I feel like the sold out alert should be an orange
	   warning alert, but it was cyan before and now it's grey. Is it not
	   considered a warning?"

	   IT IS KEPT BECAUSE THE ARGUMENT FOR IT WAS SOUND AND ONLY THE CASE WAS
	   WRONG. Every one of the four tones above says something about how the
	   ORDER is going; this is the one that says a thing happened and nothing
	   else, and the next message that is genuinely none of the four should have
	   it rather than borrow a severity it does not mean.

	   IT IS THE PAGE'S INK AND IT IS NEVER `--oo-brand`. That is the whole
	   rule and it is why this is a token rather than a literal: a skin
	   redeclares its ink, the tint, the border and the text follow, and there
	   is no path by which a client's colour reaches this tone. */
	--oo-notice-grey: var(--oo-ink, #16181c);

	/* Derived: the ground is the tone 9% into white, the border the tone 25%
	   into that ground. Written out per tone rather than through a loop
	   because CSS has no loop, and written with the mix rather than with the
	   answer so a redeclared tone carries its own tint with it. */
	--oo-notice-amber-tint: color-mix(in srgb, var(--oo-notice-amber) 9%, #fff);
	--oo-notice-amber-border: color-mix(in srgb, var(--oo-notice-amber) 25%, var(--oo-notice-amber-tint));
	--oo-notice-green-tint: color-mix(in srgb, var(--oo-notice-green) 9%, #fff);
	--oo-notice-green-border: color-mix(in srgb, var(--oo-notice-green) 25%, var(--oo-notice-green-tint));
	--oo-notice-red-tint: color-mix(in srgb, var(--oo-notice-red) 9%, #fff);
	--oo-notice-red-border: color-mix(in srgb, var(--oo-notice-red) 25%, var(--oo-notice-red-tint));
	--oo-notice-info-tint: color-mix(in srgb, var(--oo-notice-info) 9%, #fff);
	--oo-notice-info-border: color-mix(in srgb, var(--oo-notice-info) 25%, var(--oo-notice-info-tint));
	--oo-notice-grey-tint: color-mix(in srgb, var(--oo-notice-grey) 9%, #fff);
	--oo-notice-grey-border: color-mix(in srgb, var(--oo-notice-grey) 25%, var(--oo-notice-grey-tint));

	/* Not derived. Read the note above before changing one of these: each is
	   the tone darkened until APCA reads Lc 75 on its own tint. */
	--oo-notice-amber-text: #7d6400;
	--oo-notice-green-text: #00662c;
	--oo-notice-red-text: #a0001b;
	/* THE INFO TEXT IS THE BRAND DARKENED, AND THE RAW BRAND IS NOT SAFE. The
	   other three tones have a value that was walked down by hand; info cannot,
	   because its tone is whatever colour the restaurant uses. Measured on
	   bench-a on 16 September 2026 with the accent set to a worked blue,
	   #1e85be: used raw as the text on its own 9% tint it reads APCA Lc +60.0
	   and WCAG 3.66:1, which is under both bars. At 70% into black -- #155d85 --
	   the same pair reads Lc +77.0 and 6.42:1, and the reference bench's
	   near-black brand is unmoved by the same mix in any way a reader would
	   notice.

	   IT IS A DEFAULT AND NOT A GUARANTEE. A restaurant whose colour is a pale
	   yellow will still need to set this token itself, and
	   `shotter/contrast.mjs --pair` is the thing that says so; a skin's three
	   tone colours are checked that way on the bench before it ships. */
	--oo-notice-info-text: color-mix(in srgb, var(--oo-notice-info) 70%, #000);

	/* THE GREY TEXT IS DERIVED THE SAME WAY THE INFO TEXT IS, and for the same
	   reason: its tone is a token a skin may move, so it cannot be a value
	   walked down by hand. The mix only ever DARKENS, and the ink is the
	   darkest thing on the page to begin with, so the pair cannot come out
	   under the bar the way a raw brand could -- on the reference bench
	   #16181c on its own 9% tint reads APCA Lc +101 and WCAG 15.6:1. */
	--oo-notice-grey-text: color-mix(in srgb, var(--oo-notice-grey) 70%, #000);

	/* Tier 4 fills in the deep red Ryan picked out of the H series. */
	--oo-notice-block: var(--oo-notice-red);
	--oo-notice-block-text: #fff;

	/* Tier 1 is a neutral card. */
	--oo-notice-card: var(--oo-ground, #fff);
	--oo-notice-card-border: #e3e6ea;
	--oo-notice-card-text: var(--oo-ink, #1f2328);

	/* Shape. The padding is the demo's, unchanged. */
	--oo-notice-radius: 4px;
	--oo-notice-pad-y: 12px;
	--oo-notice-pad-x: 14px;
	--oo-notice-size: 0.9375rem;
	--oo-notice-weight: 500;
	--oo-notice-lead-weight: 700;
	--oo-notice-lh: 1.45;
	--oo-notice-gap: 10px;
	--oo-notice-icon-size: 20px;
	--oo-notice-shadow: 0 6px 24px rgba(0, 0, 0, .14);
}

/* ---------------------------------------------------------------- the tones

   A tone class sets the four tone variables and NOTHING ELSE. What a tier does
   with them is the tier's business: the state tier paints all four, the
   guidance tier reads only the text colour and only for its glyph, and the
   feedback tier reads only the text colour and only for its glyph. That is
   what lets `.oo-notice--guidance.oo-notice--red` be added to a field notice
   without changing one pixel of it. */

.oo-notice--amber {
	--oo-tone: var(--oo-notice-amber);
	--oo-tone-tint: var(--oo-notice-amber-tint);
	--oo-tone-text: var(--oo-notice-amber-text);
	--oo-tone-border: var(--oo-notice-amber-border);
}

.oo-notice--green {
	--oo-tone: var(--oo-notice-green);
	--oo-tone-tint: var(--oo-notice-green-tint);
	--oo-tone-text: var(--oo-notice-green-text);
	--oo-tone-border: var(--oo-notice-green-border);
}

.oo-notice--red {
	--oo-tone: var(--oo-notice-red);
	--oo-tone-tint: var(--oo-notice-red-tint);
	--oo-tone-text: var(--oo-notice-red-text);
	--oo-tone-border: var(--oo-notice-red-border);
}

.oo-notice--info {
	--oo-tone: var(--oo-notice-info);
	--oo-tone-tint: var(--oo-notice-info-tint);
	--oo-tone-text: var(--oo-notice-info-text);
	--oo-tone-border: var(--oo-notice-info-border);
}

/* The fifth. News: something changed, and the colour says only that. */
.oo-notice--grey {
	--oo-tone: var(--oo-notice-grey);
	--oo-tone-tint: var(--oo-notice-grey-tint);
	--oo-tone-text: var(--oo-notice-grey-text);
	--oo-tone-border: var(--oo-notice-grey-border);
}

/* --------------------------------------------------------------- the layout

   TWO COLUMNS, AND THE SENTENCE HANGS FROM ITS OWN FIRST WORD. Ryan, 16
   September 2026, on the demo: "It feels inconsistent that the text wraps under
   the glyph for the added to cart message." It did. The demo carried the glyph
   on a float for the toast and on an absolute box with a padded gutter for the
   alerts, and a float is only out of the way while the text is beside it -- the
   second line runs back underneath. A grid column cannot be run under.

   The icon column is the glyph's own width and the text column takes the rest.

   ALIGNED ON THE BASELINE AND NOT ON THE TOP EDGE, SINCE 26 SEPTEMBER 2026.
   Ryan, of a Sonora shot of the sold-out band: "I want alert messages to have
   padding such that the icon is vertically aligned with the text of a one line
   message. I thought this was already the case, did something happen?" It was
   the case, and something did.

   `align-items: start` is only as good as the assumption under it -- that the
   icon cell's line box and the text's first line box are the same height, so
   that starting them together centres one on the other. On 25 September the
   sentence gained a link with a tap target (`.oo-notice__remove`, 6px of
   padding above and below), the first line box grew to about 28px, the icon
   cell stayed at 21.75px against the top of the row, and the glyph sat 3.1px
   high. Measured on bench-a at 390 and at 1280, on main before and after that
   change: 0.88px before, -3.12px after.

   A BASELINE CANNOT DRIFT LIKE THAT. Both cells are one line of the same type,
   so aligning their baselines puts the glyph -- which is `vertical-align:
   middle` on its own baseline -- on the optical middle of the first line of
   text, whatever else that line happens to contain. The link's own margins are
   corrected too (see `.oo-notice__remove`), so this is the belt as well as the
   braces: the next thing that grows a line box will not move the glyph either.

   `baseline` AND NOT `first baseline`. They mean the same thing for a grid item
   and the short spelling is the one every browser this project supports has
   had since grid shipped. */

.oo-notice--feedback,
.oo-notice--state,
.oo-notice--block {
	display: grid;
	grid-template-columns: var(--oo-notice-icon-size) 1fr;
	column-gap: var(--oo-notice-gap);
	align-items: baseline;
	padding: var(--oo-notice-pad-y) var(--oo-notice-pad-x);
	border-radius: var(--oo-notice-radius);
	font-size: var(--oo-notice-size);
	font-weight: var(--oo-notice-weight);
	line-height: var(--oo-notice-lh);
	list-style: none;
}

/* ------------------------------------------- A NOTICE IN THE FLOW HAS AIR
   ABOVE IT (16 September 2026)

   Ryan: "The coupon messages don't have any spacing above them." Both of them.
   "Coupon code applied successfully." is drawn at the end of
   `form.checkout_coupon`, directly under the chip block; "Coupon has been
   removed." is drawn in the same place with the chip block empty, so it lands
   directly under the field. Neither had a margin: the tiers above give a
   notice PADDING, which is the air INSIDE the box, and a box with padding and
   no margin still has its top edge against whatever is above it.

   IT IS THE TIER AND NOT THE COUPON, because the coupon is only where it was
   noticed. Every tier that draws a box draws it in the flow somewhere -- the
   state tier under the review table when a dish sells out, the block tier
   under the payment methods when an order is refused -- and each would have
   arrived flush the first time anybody looked at it. One rule, on the
   condition that actually distinguishes the two cases: `:not(.oo-toast)`,
   because the toast is the one that floats and its distance from the top of
   the viewport is its layer's business.

   `--oo-s3` AND NOT `--oo-s2`, and the neighbours are why. `.oo-coupon-applied`
   -- the chip block this card sits under -- takes `margin-top: var(--oo-s3)`
   from the field row above it (`checkout.css`), so s3 is the step that column
   already uses between one block and the next. s2 is the step a LINE under a
   field takes (`.oo-notice--field` below), which is a smaller relationship: a
   sentence hanging off a control rather than a card sitting after one.

   THE THREE MESSAGES THAT PLACE THEMSELVES KEEP DOING SO, AND EACH ONE HAD TO
   BE MADE TO. Being later in this file is not enough and the first draft of
   this block said it was: document order only breaks a tie between rules of
   EQUAL specificity, and `:not()` contributes the specificity of its argument,
   so the rule below is (0,2,0) while `.oo-pausebanner` was (0,1,0). It would
   have given the pause banner a 12px top margin it has never had, in the one
   place a margin is wrong -- the banner is dropped into the service bar's flex
   row, where the row's own gap is the spacing.

   So the two that are ours carry `.oo-notice` as well, which makes them
   (0,2,0) and later in the file, and the vendor's missing-field block on the
   checkout was already heavier than this ((0,4,1), because it has to line up
   with the form's columns and clear the back link). */
.oo-notice--feedback:not(.oo-toast),
.oo-notice--state:not(.oo-toast),
.oo-notice--block:not(.oo-toast) {
	margin-top: var(--oo-s3, 12px);
}

/* A GUIDANCE LINE THAT DOES CARRY A GLYPH (28 September 2026). The tier has
   no grid of its own because its first users had no glyph; the gift-card
   rule line and the percentage-code refusal under the promo field do, and
   without this the glyph sat on a line by itself above the sentence
   (measured on bench-a at 390). Opt-in by class, so no other guidance line
   moves: the same two columns and baseline the boxed tiers use, no box. */
.oo-notice--guidance.oo-notice--glyphline {
	display: grid;
	grid-template-columns: var(--oo-notice-icon-size) 1fr;
	column-gap: var(--oo-notice-gap);
	align-items: baseline;
}

/* A notice with no glyph keeps the single column it always had. The field
   notices and the resolver line are the whole of this case, and "nothing else
   changes" for them is a promise this line keeps. */
.oo-notice--noicon {
	display: block;
	grid-template-columns: none;
}

.oo-notice__body {
	min-width: 0;
}

/* `hidden` STILL HIDES, AND IT STOPPED ON 16 SEPTEMBER 2026 UNTIL THIS LINE.
   The browser's own `[hidden] { display: none }` is a USER-AGENT rule, and an
   author declaration beats one whatever the specificity -- so the moment the
   tiers above started setting `display`, three elements that are rendered
   always and hidden when they have nothing to say stopped being hidden. The
   minimum note is the one that caught it: a bench crop of an empty amber box
   with a cart glyph in it and no sentence, sitting under the service pills of a
   shop with nothing to say about a minimum.

   The three are the minimum note (WooCommerce's cart fragments replace it by
   selector, so it has to exist while it is empty), the service-bar note and the
   order-details sheet's copy of it (the switch script reveals them without a
   round trip). Two classes here, and four on the checkout, because Pro's own
   weight is three. */
.oo-notice[hidden] {
	display: none;
}

/* WHAT HAPPENED IN BOLD, WHAT TO DO ABOUT IT PLAIN AFTER IT -- Stripe's shape,
   which is the one Ryan pointed at. `inc/notices.php` promotes the message's
   own first sentence rather than printing a word in front of it; the argument
   for that is in `oo_notice_split_lead()`. */
.oo-notice__lead {
	font-weight: var(--oo-notice-lead-weight);
}

/* -------------------------------------------------- the glyph, on the first
   line of text and not on the middle of the box

   Ryan, the same day: "It would look good if the glyph was vertically aligned
   with the first line of text." On a one-line notice those are the same place
   and on a three-line notice they are not, which is where the demo showed it.

   HOW IT IS DONE WITHOUT A MAGIC NUMBER. The cell carries a zero-width space,
   so it has a line box built from the text's own font and line-height and
   therefore the text's own baseline. The glyph is an inline-block in that line
   box with `vertical-align: middle`, which CSS defines as the box's vertical
   midpoint against the parent's baseline plus half the parent's x-height. That
   is the x-height centre of the first line, computed from the font's metrics.
   A `top: 14px` would have been right in one typeface and wrong in the client
   theme's -- the benches run two different faces, which is how this was caught.

   CARRIED AS A MASK, NOT AS A FILL. A data URI with a colour baked into it
   needs one copy per tone and a third for the white reverse, and the copies
   drift. `mask-image` over `background-color: currentColor` is one copy per
   glyph that takes whatever colour the text beside it has.

   EVERY QUOTE INSIDE THE URI IS PERCENT-ENCODED. A double quote closes the
   `url("...")`; a single quote is legal but stops the value being reusable
   unquoted, and these same URIs are read back out of this file by the demo
   sheet builder and written into inline style attributes. */

.oo-notice__icon {
	display: block;
	width: var(--oo-notice-icon-size);
	font-size: inherit;
	line-height: inherit;
	/* The glyph can stand a hair proud of its line box; nothing may clip it. */
	overflow: visible;
}

.oo-notice__icon::before {
	content: "\200B";
}

.oo-notice__icon::after {
	content: "";
	display: inline-block;
	vertical-align: middle;
	width: var(--oo-notice-icon-size);
	height: var(--oo-notice-icon-size);
	background-color: currentColor;
	-webkit-mask-repeat: no-repeat;
	mask-repeat: no-repeat;
	-webkit-mask-position: center;
	mask-position: center;
	-webkit-mask-size: contain;
	mask-size: contain;
	-webkit-mask-image: var(--oo-notice-glyph);
	mask-image: var(--oo-notice-glyph);
}

/* THE EIGHT GLYPHS, AND THERE IS NO NINTH. Material Symbols Outlined, Google's
   own artwork at 24px in its `0 -960 960 960` box. The glyph names the SUBJECT
   wherever the message has one -- Ryan: "pause and stop shouldn't be warning
   icons, they should just be pause and stop icons" -- and falls back to the
   severity only where it does not. A generic amber warning triangle is not
   here because every amber message in this system names its own subject, so it
   would never be reached; the clock is amber's fallback instead.
   `oo_notice_glyphs()` in `inc/notices.php` is the list PHP may ask for. */

.oo-notice__icon--pause { --oo-notice-glyph: url("data:image/svg+xml,%3Csvg%20xmlns=%27http://www.w3.org/2000/svg%27%20viewBox=%270%20-960%20960%20960%27%3E%3Cpath%20d=%27M520-200v-560h240v560H520Zm-320%200v-560h240v560H200Zm400-80h80v-400h-80v400Zm-320%200h80v-400h-80v400Zm0-400v400-400Zm320%200v400-400Z%27/%3E%3C/svg%3E"); }

.oo-notice__icon--schedule { --oo-notice-glyph: url("data:image/svg+xml,%3Csvg%20xmlns=%27http://www.w3.org/2000/svg%27%20viewBox=%270%20-960%20960%20960%27%3E%3Cpath%20d=%27m612-292%2056-56-148-148v-184h-80v216l172%20172ZM480-80q-83%200-156-31.5T197-197q-54-54-85.5-127T80-480q0-83%2031.5-156T197-763q54-54%20127-85.5T480-880q83%200%20156%2031.5T763-763q54%2054%2085.5%20127T880-480q0%2083-31.5%20156T763-197q-54%2054-127%2085.5T480-80Zm0-400Zm0%20320q133%200%20226.5-93.5T800-480q0-133-93.5-226.5T480-800q-133%200-226.5%2093.5T160-480q0%20133%2093.5%20226.5T480-160Z%27/%3E%3C/svg%3E"); }

.oo-notice__icon--location-on { --oo-notice-glyph: url("data:image/svg+xml,%3Csvg%20xmlns=%27http://www.w3.org/2000/svg%27%20viewBox=%270%20-960%20960%20960%27%3E%3Cpath%20d=%27M536.5-503.5Q560-527%20560-560t-23.5-56.5Q513-640%20480-640t-56.5%2023.5Q400-593%20400-560t23.5%2056.5Q447-480%20480-480t56.5-23.5ZM480-186q122-112%20181-203.5T720-552q0-109-69.5-178.5T480-800q-101%200-170.5%2069.5T240-552q0%2071%2059%20162.5T480-186Zm0%20106Q319-217%20239.5-334.5T160-552q0-150%2096.5-239T480-880q127%200%20223.5%2089T800-552q0%20100-79.5%20217.5T480-80Zm0-480Z%27/%3E%3C/svg%3E"); }

.oo-notice__icon--shopping-cart { --oo-notice-glyph: url("data:image/svg+xml,%3Csvg%20xmlns=%27http://www.w3.org/2000/svg%27%20viewBox=%270%20-960%20960%20960%27%3E%3Cpath%20d=%27M223.5-103.5Q200-127%20200-160t23.5-56.5Q247-240%20280-240t56.5%2023.5Q360-193%20360-160t-23.5%2056.5Q313-80%20280-80t-56.5-23.5Zm400%200Q600-127%20600-160t23.5-56.5Q647-240%20680-240t56.5%2023.5Q760-193%20760-160t-23.5%2056.5Q713-80%20680-80t-56.5-23.5ZM246-720l96%20200h280l110-200H246Zm-38-80h590q23%200%2035%2020.5t1%2041.5L692-482q-11%2020-29.5%2031T622-440H324l-44%2080h480v80H280q-45%200-68-39.5t-2-78.5l54-98-144-304H40v-80h130l38%2080Zm134%20280h280-280Z%27/%3E%3C/svg%3E"); }

.oo-notice__icon--sell { --oo-notice-glyph: url("data:image/svg+xml,%3Csvg%20xmlns=%27http://www.w3.org/2000/svg%27%20viewBox=%270%20-960%20960%20960%27%3E%3Cpath%20d=%27M856-390%20570-104q-12%2012-27%2018t-30%206q-15%200-30-6t-27-18L103-457q-11-11-17-25.5T80-513v-287q0-33%2023.5-56.5T160-880h287q16%200%2031%206.5t26%2017.5l352%20353q12%2012%2017.5%2027t5.5%2030q0%2015-5.5%2029.5T856-390ZM513-160l286-286-353-354H160v286l353%20354ZM260-640q25%200%2042.5-17.5T320-700q0-25-17.5-42.5T260-760q-25%200-42.5%2017.5T200-700q0%2025%2017.5%2042.5T260-640Zm220%20160Z%27/%3E%3C/svg%3E"); }

.oo-notice__icon--check-circle { --oo-notice-glyph: url("data:image/svg+xml,%3Csvg%20xmlns=%27http://www.w3.org/2000/svg%27%20viewBox=%270%20-960%20960%20960%27%3E%3Cpath%20d=%27m424-296%20282-282-56-56-226%20226-114-114-56%2056%20170%20170Zm56%20216q-83%200-156-31.5T197-197q-54-54-85.5-127T80-480q0-83%2031.5-156T197-763q54-54%20127-85.5T480-880q83%200%20156%2031.5T763-763q54%2054%2085.5%20127T880-480q0%2083-31.5%20156T763-197q-54%2054-127%2085.5T480-80Zm0-80q134%200%20227-93t93-227q0-134-93-227t-227-93q-134%200-227%2093t-93%20227q0%20134%2093%20227t227%2093Zm0-320Z%27/%3E%3C/svg%3E"); }

.oo-notice__icon--info { --oo-notice-glyph: url("data:image/svg+xml,%3Csvg%20xmlns=%27http://www.w3.org/2000/svg%27%20viewBox=%270%20-960%20960%20960%27%3E%3Cpath%20d=%27M440-280h80v-240h-80v240Zm68.5-331.5Q520-623%20520-640t-11.5-28.5Q497-680%20480-680t-28.5%2011.5Q440-657%20440-640t11.5%2028.5Q463-600%20480-600t28.5-11.5ZM480-80q-83%200-156-31.5T197-197q-54-54-85.5-127T80-480q0-83%2031.5-156T197-763q54-54%20127-85.5T480-880q83%200%20156%2031.5T763-763q54%2054%2085.5%20127T880-480q0%2083-31.5%20156T763-197q-54%2054-127%2085.5T480-80Zm0-80q134%200%20227-93t93-227q0-134-93-227t-227-93q-134%200-227%2093t-93%20227q0%20134%2093%20227t227%2093Zm0-320Z%27/%3E%3C/svg%3E"); }

.oo-notice__icon--error { --oo-notice-glyph: url("data:image/svg+xml,%3Csvg%20xmlns=%27http://www.w3.org/2000/svg%27%20viewBox=%270%20-960%20960%20960%27%3E%3Cpath%20d=%27M508.5-291.5Q520-303%20520-320t-11.5-28.5Q497-360%20480-360t-28.5%2011.5Q440-337%20440-320t11.5%2028.5Q463-280%20480-280t28.5-11.5ZM440-440h80v-240h-80v240Zm40%20360q-83%200-156-31.5T197-197q-54-54-85.5-127T80-480q0-83%2031.5-156T197-763q54-54%20127-85.5T480-880q83%200%20156%2031.5T763-763q54%2054%2085.5%20127T880-480q0%2083-31.5%20156T763-197q-54%2054-127%2085.5T480-80Zm0-80q134%200%20227-93t93-227q0-134-93-227t-227-93q-134%200-227%2093t-93%20227q0%20134%2093%20227t227%2093Zm0-320Z%27/%3E%3C/svg%3E"); }

/* Named on `:root` as well, for the one rule that cannot reach it through a
   class: the payment failure on the receipt page. */
:root { --oo-icon-error-glyph: url("data:image/svg+xml,%3Csvg%20xmlns=%27http://www.w3.org/2000/svg%27%20viewBox=%270%20-960%20960%20960%27%3E%3Cpath%20d=%27M508.5-291.5Q520-303%20520-320t-11.5-28.5Q497-360%20480-360t-28.5%2011.5Q440-337%20440-320t11.5%2028.5Q463-280%20480-280t28.5-11.5ZM440-440h80v-240h-80v240Zm40%20360q-83%200-156-31.5T197-197q-54-54-85.5-127T80-480q0-83%2031.5-156T197-763q54-54%20127-85.5T480-880q83%200%20156%2031.5T763-763q54%2054%2085.5%20127T880-480q0%2083-31.5%20156T763-197q-54%2054-127%2085.5T480-80Zm0-80q134%200%20227-93t93-227q0-134-93-227t-227-93q-134%200-227%2093t-93%20227q0%20134%2093%20227t227%2093Zm0-320Z%27/%3E%3C/svg%3E"); }

/* ======================================================= TIER 1 -- FEEDBACK

   Something just happened and it can be dismissed. A NEUTRAL CARD, with the
   tone in the glyph and nowhere else: a green wash behind "added to your cart"
   is louder than the event deserves, and Slack, Drive and MUI's own snackbar
   all arrived at the same answer. The shadow is on the toast alone, because the
   toast is the one that floats; the coupon line sits in the flow beside the
   chip and a shadow there would be a card pretending to hover. */

.oo-notice--feedback {
	background: var(--oo-notice-card);
	color: var(--oo-notice-card-text);
	border: 1px solid var(--oo-notice-card-border);
	box-shadow: none;
}

.oo-notice--feedback .oo-notice__icon,
.oo-notice--guidance .oo-notice__icon {
	color: var(--oo-tone-text, currentColor);
}

/* ======================================================= TIER 2 -- GUIDANCE

   ALMOST NOTHING, AND THAT IS THE FINDING. The field notices and the resolver
   line under the time field are already inline ink text with no fill, sitting
   against the thing they are about. The system's job with them is to name them
   and leave them alone, so that the next person reading the markup can see that
   the decision was taken rather than missed. The one rule above gives a glyph
   its tone where a guidance notice is given one; none of today's are.

   The three classes below are the ones the router paints a field line with, and
   two of them are WooCommerce's own. Styling all three identically is what
   makes the vendor's line and ours indistinguishable to a customer, which is
   what lets the router leave the vendor's alone where it got there first. This
   block moved here from `order.css` and `checkout.css`, which had a copy each. */

/* `--field` AND NOT A BARE `.oo-notice`, and the distinction is the whole
   reason the resolver line is untouched. This block used to hang off
   `.oo-notice`, which at the time meant one thing: the line the router paints
   under a field. `.oo-notice` is the component now and every message on the
   site carries it, so the same three declarations would have reached the
   resolver line and moved its size and its margin by a pixel or two -- which is
   exactly the "nothing else changes" this tier is supposed to keep.
   `assets/notices.js` puts `--field` on what it draws. */
.oo-notice--field,
.coupon-error-notice,
.checkout-inline-error-message {
	display: block;
	margin-top: var(--oo-s2, 8px);
	margin-bottom: 0;
	font-size: .875rem;
	line-height: 1.4;
}

/* THE KIND IS ITS OWN FAMILY, `--kind-<kind>`, AND IT IS NOT A TONE (25
   September 2026). These three classes used to be spelt `--error`, `--success`
   and `--info`, which put the kind of a WooCommerce notice into the same
   namespace as the four tone classes above -- and `.oo-notice--info` IS one of
   them. A `state` + `amber` entry painted by `paintInline()` came out wearing
   the info tone, because the kind class is declared later at equal specificity
   and later wins. On oobase the info tone is the ink and nobody saw it; on
   Sonora it is `--oo-brand` and the sold-out band was teal. */
.oo-notice--field.oo-notice--kind-error,
.coupon-error-notice,
.checkout-inline-error-message {
	color: var(--oo-error, #d92d20);
}

.oo-notice--field.oo-notice--kind-success,
.oo-notice--field.oo-notice--kind-info {
	color: var(--oo-ink, #1f2328);
}

.oo-notice--field a {
	color: inherit;
	text-decoration: underline;
}

/* A control the router has marked. `has-error` is WooCommerce's own class name,
   set by its handler and by ours, so a site that already styles it keeps its
   own treatment. */
[data-oo-invalid] {
	border-color: var(--oo-error, #d92d20);
}

/* ========================================================== TIER 3 -- STATE

   True right now, and it leaves when the state does. The standard tinted
   alert: a pale tint of the tone as the ground, the tone darkened for the text,
   a 1px border of the tone mixed into the tint, 4px corners. No close button --
   there is nothing to close, because the message is not an event that happened,
   it is the page's condition. */

.oo-notice--state {
	background: var(--oo-tone-tint);
	color: var(--oo-tone-text);
	border: 1px solid var(--oo-tone-border);
	box-shadow: none;
}

/* ========================================================== TIER 4 -- BLOCK

   The customer is about to lose something. Filled, white, and used for three
   messages: the order that was refused, the card that was declined, and a
   payment that failed on the order-received page. Ryan on why this is not the
   treatment everywhere: the strong fills are "overly distracting for many of
   our purposes". */

.oo-notice--block {
	background: var(--oo-notice-block);
	color: var(--oo-notice-block-text);
	border: 0;
}

.oo-notice--block .oo-notice__icon {
	color: var(--oo-notice-block-text);
}

.oo-notice--block a {
	color: var(--oo-notice-block-text);
}

/* ------------------------------------------------------- the vendor's list

   WooCommerce's missing-field block, seen only when `assets/notices.js` never
   arrived. THE VENDOR'S OWN `<li>`s ARE KEPT: each one names a field and the
   customer needs all of them, so the wrapper is dressed as a state notice and
   the list is left inside it. Pro's checkout sheet gives that `<ul>` a glyph on
   `::before` and gives each link a colour of its own; both are named here
   rather than inherited, because an element a vendor rule matches directly
   does not inherit from us. */

.oo-notice--state > .oo-notice__body > ul,
.oo-notice--state > .oo-notice__body > ul li {
	margin: 0;
	padding-left: 0;
	list-style: none;
	color: inherit;
	background: none;
}

.oo-notice--state > .oo-notice__body > ul li + li {
	margin-top: var(--oo-s1, 4px);
}

.oo-notice--state > .oo-notice__body > ul li::before {
	content: none;
}

.oo-notice--state > .oo-notice__body a {
	color: inherit;
	text-decoration: underline;
}

/* ---------------------------------------------------------------- the toast

   The toast is a feedback card that floats, or a block that floats. Its LAYER
   -- the fixed strip under whatever is stuck to the top of the viewport -- is
   still declared in `order.css` and `checkout.css`, because the offset is
   measured from each page's own chrome and the two pages do not agree about
   what is at the top of them. What is here is the card itself.

   `.oo-toast` CARRIES `.oo-notice` FROM 16 SEPTEMBER 2026: `assets/notices.js`
   puts the tier and tone classes on the element it builds and gives it an icon
   cell, so the toast is the component rather than a second thing that looks
   like it. The old `border-left: 3px solid` in the tone is gone with the rest
   of the stripe -- Ryan, 15 September: "I don't love the left stripe." */

.oo-toast {
	pointer-events: auto;
	opacity: 0;
	transform: translateY(-8px);
	transition: opacity .18s ease, transform .18s ease;
}

.oo-toast.is-in {
	opacity: 1;
	transform: translateY(0);
}

/* THREE COLUMNS ON A TOAST, because the dismiss button is a column too and it
   must not be what the sentence wraps under either. */
.oo-toast.oo-notice {
	grid-template-columns: var(--oo-notice-icon-size) 1fr auto;
	box-shadow: var(--oo-notice-shadow);
}

.oo-toast.oo-notice--noicon {
	display: grid;
	grid-template-columns: 1fr auto;
}

.oo-toast .oo-notice__body {
	flex: 1 1 auto;
}

.oo-toast .oo-notice__body a {
	color: inherit;
	text-decoration: underline;
}

/* A real 24px control with a real square, for the same reason the coupon chip's
   remove button is one: GeneratePress styles a bare `button` with padding of
   its own, so the element and its width are both named. */
/* AND THE DISMISS BUTTON IS PINNED TO THE TOP OF THE ROW. It is a 24px square
   with no text in it, so it has no baseline of its own; a grid that aligns on
   baselines would synthesise one from its bottom edge and hang the button off
   the sentence. `start` is what it always effectively had. */
.oo-toast button.oo-toast__close {
	align-self: start;
	display: inline-flex;
	align-items: center;
	justify-content: center;
	flex: none;
	width: 24px;
	min-width: 24px;
	height: 24px;
	padding: 0;
	border: 0;
	border-radius: 999px;
	background: none;
	color: currentColor;
	opacity: .55;
	font-size: 1rem;
	line-height: 1;
	cursor: pointer;
}

.oo-toast button.oo-toast__close:hover,
.oo-toast button.oo-toast__close:focus-visible {
	opacity: 1;
}

/* TRAPS.md's keyboard entries are about rings that are clipped or absent; this
   one is inside a fixed element with its own ground, so the ring is the page's
   own and nothing crops it. */
.oo-toast button.oo-toast__close:focus-visible {
	outline: 2px solid var(--oo-focus-ring, #16181c);
	outline-offset: 2px;
}

@media (prefers-reduced-motion: reduce) {
	.oo-toast {
		transition: none;
		transform: none;
	}

	.oo-toast.is-in {
		transform: none;
	}
}

/* ====================================================== THE MESSAGES, BY NAME

   Everything above is the component. What follows is the handful of places
   where a message's own class still has to say something about where it sits on
   the page -- and nothing about what colour it is. The four literal-coloured
   message classes the inventory found are gone: `.oo-pausebanner`,
   `.oo-minnote` and `.oo-sheet__note` all read their colour from the tone now,
   and `assets/order.css` no longer mentions one. */

/* The pause banner is dropped into the service bar's flex row ahead of the
   pills, so it needs a full-width basis and an order; the same two lines it has
   always had, kept in `order.css` beside the row they are about. Here it needs
   only the gap under it, which the component's `padding` does not give. */
/* `.oo-notice` IS ON THE SELECTOR FOR WEIGHT, not for meaning: it makes this
   (0,2,0), the same as the in-flow margin rule above, and this one is later. */
.oo-notice.oo-pausebanner {
	margin: 0 0 var(--oo-s3, 12px);
}

/* The minimum note sits under the pills and is refreshed through WooCommerce's
   cart fragments, which replace the whole element -- including its glyph. */
/* Weight, for the reason the pause banner's selector gives. */
.oo-notice.oo-minnote,
.oo-notice.oo-alcoholnote {
	margin: 0;
}

/* The out-of-zone pair on the checkout. The refusal is the state and the prompt
   after it is guidance, which is why they are two elements: "we do not deliver
   there" is a fact about the address and "pickup is available" is a thing the
   customer can do, and one line in one colour made the second look like part of
   the first. Both print inside the vendor's own rate `<li>`; the rule that gave
   them their size and their muted grey moved here out of `checkout.css` with
   them. */
body.woocommerce-checkout .oo-svc__note,
body.woocommerce-checkout .oo-svc__prompt {
	display: block;
	margin-top: var(--oo-s1, 4px);
}

/* THE INK AND NOT THE MUTED GREY, AND THE GROUND IS WHY. These two print
   inside the vendor's own rate `<li>`, and a CHOSEN rate's row is not white:
   Orderable Pro paints it `#dbdbdb`. Measured on bench-a, 16 September 2026,
   with `shotter/contrast.mjs`: `--oo-muted` there is `#555555` and reads APCA
   Lc +64.8 at 14px/400, under the Lc 75 body bar, while the ink reads +81.8.
   On the unselected white row the grey was fine, which is why it had never been
   caught -- the line only goes grey-on-grey once a customer picks delivery,
   which is the one time they are being asked to do something about it.
   Everything about the line except its colour is unchanged. */
body.woocommerce-checkout .oo-svc__note.oo-notice--guidance,
body.woocommerce-checkout .oo-svc__prompt,
/* THE WAIT NOTE IN THE ORDER SUMMARY, THE SAME GREY-ON-GREY. The ASAP row
   ("Ready about 12:30 pm, which is about 35 minutes from now") is a guidance
   notice inside the summary table, whose panel is the theme's grey and whose
   text inherited the theme's muted tone: Lc 63.7 on Sonora, under the 75 bar,
   and only while the shop is open, because the closed-shop sentence in the
   same row is a state-tier notice with its own tinted panel. 20 Sep 2026. */
body.woocommerce-checkout tr.oo-asap-note .oo-notice--guidance,
body.woocommerce-checkout tr.oo-asap-note .oo-asap-note__text {
	color: var(--oo-ink, #1f2328);
	font-size: .875rem;
	line-height: 1.4;
}

/* The service note under the pills, and the same sentence again in the
   order-details sheet. One tone between them, because they are one message
   written twice and a customer who opens the sheet should not meet a second
   colour for the answer they have already read. `.oo-sheet__note` carried a
   `#b42318` of its own until today; it reads the tone now. */
.oo-servicebar__note,
.oo-sheet__note {
	color: var(--oo-tone-text, var(--oo-error, #d92d20));
}

/* ============================================ ON ORDERABLE PRO'S CHECKOUT

   EVERY RULE BELOW IS A SPECIFICITY ANSWER AND NOT A SECOND DESIGN. Nothing
   here says anything the component has not already said; each one repeats a
   declaration at a weight that beats what Pro's `checkout-pro.min.css` says
   about the same element. The PREAMBLE this brief was written against puts it
   plainly: that sheet reaches every element on a theme-chrome checkout, and a
   rule matching an element directly beats anything it inherits.

   WHAT PRO SAYS, MEASURED OUT OF ITS OWN FILE RATHER THAN GUESSED AT:

     body.woocommerce-checkout *        font-family, font-size:16px,
                                        line-height:1.4            (0,1,1)
     body.woocommerce-checkout strong   font-weight:400, color:#000 (0,1,1)
     body.woocommerce-checkout a        color:#000                  (0,1,1)
     body.woocommerce-checkout          color:#706f79               (0,1,0)
     ...  .woocommerce-error            all:unset, a green fill, a left rule,
                                        14px/28px padding           (0,2,1)
     :root ... .woocommerce-error       padding-left:56px           (0,3,1)

   So the component's own `(0,1,0)` selectors lose on the checkout however late
   this file prints -- and it does print late, which is the other half and is
   what keeps the count of these rules down to one block. `:root body...` is
   `(0,3,1)`, which is the level Pro's most specific rule reaches.

   ONE `!important`, AND IT IS ANSWERING ONE. `.woocommerce-error a` is
   `color:#fff!important` in Pro's sheet, and an `!important` in a vendor
   stylesheet cannot be beaten by specificity or by document order at all. Every
   other rule here wins on the merits. */

:root body.woocommerce-checkout .oo-notice[hidden] {
	display: none;
}

/* AND THE SAME ON THE CHECKOUT, which is the surface Ryan's shot came from.
   This block exists because Pro dequeues and re-declares; it has to carry the
   baseline with it or the fix is on the menu and nowhere else. */
:root body.woocommerce-checkout .oo-notice--feedback,
:root body.woocommerce-checkout .oo-notice--state,
:root body.woocommerce-checkout .oo-notice--block {
	display: grid;
	grid-template-columns: var(--oo-notice-icon-size) 1fr;
	column-gap: var(--oo-notice-gap);
	align-items: baseline;
	padding: var(--oo-notice-pad-y) var(--oo-notice-pad-x);
	border-radius: var(--oo-notice-radius);
	font-size: var(--oo-notice-size);
	font-weight: var(--oo-notice-weight);
	line-height: var(--oo-notice-lh);
	list-style: none;
}

:root body.woocommerce-checkout .oo-notice--state {
	background: var(--oo-tone-tint);
	color: var(--oo-tone-text);
	border: 1px solid var(--oo-tone-border);
}

:root body.woocommerce-checkout .oo-notice--feedback {
	background: var(--oo-notice-card);
	color: var(--oo-notice-card-text);
	border: 1px solid var(--oo-notice-card-border);
}

:root body.woocommerce-checkout .oo-notice--block {
	background: var(--oo-notice-block);
	color: var(--oo-notice-block-text);
	border: 0;
}

:root body.woocommerce-checkout .oo-toast.oo-notice {
	grid-template-columns: var(--oo-notice-icon-size) 1fr auto;
	box-shadow: var(--oo-notice-shadow);
}

:root body.woocommerce-checkout .oo-toast.oo-notice--noicon {
	grid-template-columns: 1fr auto;
}

/* THE GLYPH ITSELF, INSIDE THE VENDOR'S BLOCK. Pro declares
   `body.woocommerce-checkout .woocommerce-error ::before, ... ::after { all: unset }`
   -- a DESCENDANT selector, so it reaches every pseudo-element of everything
   inside that block, the icon cell's included, and `all: unset` takes the mask,
   the size and the `content` with it. Measured on bench-a, 16 September 2026:
   the missing-field block rendered with its icon column, its padding and no
   glyph in it. It is `(0,2,1)`; this is `(0,3,2)`.

   Declared for every notice on the checkout rather than for that block alone,
   because the next vendor rule of this shape will be aimed somewhere else. */
:root body.woocommerce-checkout .oo-notice__icon::before {
	content: "\200B";
}

:root body.woocommerce-checkout .oo-notice__icon::after {
	content: "";
	display: inline-block;
	vertical-align: middle;
	width: var(--oo-notice-icon-size);
	height: var(--oo-notice-icon-size);
	background-color: currentColor;
	background-image: none;
	-webkit-mask-repeat: no-repeat;
	mask-repeat: no-repeat;
	-webkit-mask-position: center;
	mask-position: center;
	-webkit-mask-size: contain;
	mask-size: contain;
	-webkit-mask-image: var(--oo-notice-glyph);
	mask-image: var(--oo-notice-glyph);
	position: static;
	float: none;
	margin: 0;
	padding: 0;
	border: 0;
	left: auto;
	top: auto;
}

/* The two cells take the notice's type, not the page's. Pro's `*` rule would
   otherwise give the icon cell a 16px/1.4 line box while the text beside it
   reads 15px/1.45, and the glyph would sit a pixel or two off the first line --
   which is the exact thing this component was asked to get right. */
:root body.woocommerce-checkout .oo-notice__icon,
:root body.woocommerce-checkout .oo-notice__body {
	font-size: inherit;
	font-family: inherit;
	line-height: inherit;
}

:root body.woocommerce-checkout .oo-notice__icon {
	display: block;
	width: var(--oo-notice-icon-size);
}

/* `body.woocommerce-checkout strong { font-weight: 400 }` would un-bold every
   lead phrase on the page, and `body.woocommerce-checkout *` would set it in
   16px on a line built for 15px.

   THE SIZE IS THE HALF THAT WAS MISSING, and it showed up as a millimetre.
   Measured on bench-a, 16 September 2026: the icon cell's baseline and the text
   cell's were the same to two decimal places on the menu and TWO PIXELS apart
   on the checkout, because the lead was the first inline box in that line and
   Pro had given it 16px over a 1.4 line-height. A taller inline box makes a
   taller line box and drops the baseline under it, and the glyph -- aligned to
   the icon cell's own baseline -- stayed where it was. The alignment read
   -1.64px on the checkout against -0.07px on the menu until this line. */
:root body.woocommerce-checkout .oo-notice__lead {
	font-weight: var(--oo-notice-lead-weight);
	font-size: inherit;
	font-family: inherit;
	line-height: inherit;
	color: inherit;
}

:root body.woocommerce-checkout .oo-notice--block a,
:root body.woocommerce-checkout .oo-notice__body a,
:root body.woocommerce-checkout .oo-toast__text a {
	color: inherit;
	text-decoration: underline;
}

/* THE ACTION INSIDE THE SENTENCE IS THE ONE CONTROL ON THE BAND, and it is
   drawn as what it is: the same words, underlined, in the tone's own text
   colour, with a tap target the sentence does not otherwise have.

   Ryan, 25 September 2026: the words "Remove it" / "Remove them" become the
   link, so the one control is on the page at every width and no words are
   added. A button here would be a second thing to look at in a band that is
   already one sentence; a link that is only underlined is a 12px-tall target
   in the middle of a line of text.

   `padding-block` AND NO SIDE PADDING. The words are inside a sentence, so any
   horizontal padding opens a gap before "to continue." that reads as a typo.
   The vertical padding grows the hit box without moving a single glyph: an
   inline-block on a 1.45 line-height at the notice's own size is about 22px,
   and 6px above and below clears WCAG 2.2's 24px minimum for a target in a
   line of text. `-2px` of vertical margin takes the growth back off the line
   box so the band does not get taller for it.

   EVERY PROPERTY ON THE ELEMENT THAT CARRIES THE WORDS, the rule this project
   keeps for the checkout: Orderable Pro's `body.woocommerce-checkout *` sets a
   size and a line-height on every element there, and a value inherited from
   the notice would lose to it.

   AND IT IS MATCHED BY THE TIER, NOT BY A CLASS OF ITS OWN. `assets/notices.js`
   rebuilds a notice out of an allowlist when it moves one, and a class is
   deliberately NOT on that list -- a message that carried styling into a box it
   was not written for is the fault the allowlist exists for. So the server's
   `oo-notice__remove` survives only on the copy nobody moved, and the selector
   that has to work everywhere is the state tier's own body: the tinted band is
   the only notice in this system with a link in its sentence. A field line's
   link, which is tier 2, keeps its plain treatment. */
:root body.woocommerce-checkout .oo-notice--state .oo-notice__body a,
.oo-notice--state .oo-notice__body a {
	display: inline-block;
	/* THE MARGIN CANCELS THE PADDING EXACTLY, SINCE 26 SEPTEMBER 2026. An
	   inline-block contributes its MARGIN box to the line box, so `-2px`
	   against 6px of padding still grew the first line by 8px -- which is what
	   pushed the text down and left the glyph sitting high in Ryan's shot. At
	   -6px the margin box is the words' own box, the line box is exactly what
	   it would be without the link, and the padding is still there: it is the
	   hit area, and a margin does not take a hit area away. */
	margin-block: -6px;
	padding-block: 6px;
	color: inherit;
	font-size: inherit;
	font-weight: inherit;
	line-height: inherit;
	text-decoration: underline;
}

/* Pro paints the missing-field block a solid green with a left rule, resets it
   with `all: unset` first, and gives it a 56px left padding for a glyph of its
   own that it then blanks. All of it is undone here; the list inside is the
   vendor's and is kept. */
/* IT LINES UP WITH THE COLUMNS AND IT CLEARS THE BACK LINK. Two measurements
   at 1280 on bench-a, 16 September 2026, both from taking Pro's own margins off
   and putting nothing back. `--oo-checkout-inset` is the 2em Pro gives the two
   checkout columns, which `.oo-backlink` and the summary strip already read, so
   a full-width block was the only thing on the page not lined up with the form.
   And above 992px `.oo-backlink` is `height: 0` with the link absolutely
   positioned inside it -- deliberately, so it takes no vertical space -- so a
   block with no top margin slides underneath it and "Back to menu" was printed
   over the first line of the notice. */
:root body.woocommerce-checkout .woocommerce-error.oo-notice {
	position: static;
	margin: var(--oo-s6, 24px) var(--oo-checkout-inset, 2em) var(--oo-s5, 20px);
	clear: both;
}

:root body.woocommerce-checkout .woocommerce-error.oo-notice::before,
:root body.woocommerce-checkout .woocommerce-error.oo-notice::after {
	content: none;
}

:root body.woocommerce-checkout .woocommerce-error.oo-notice ul,
:root body.woocommerce-checkout .woocommerce-error.oo-notice li {
	margin: 0;
	padding: 0;
	list-style: none;
	color: inherit;
	background: none;
	float: none;
	display: block;
	font-size: inherit;
	line-height: inherit;
}

:root body.woocommerce-checkout .woocommerce-error.oo-notice li + li {
	margin-top: var(--oo-s1, 4px);
}

/* The one `!important` in this file, answering Pro's. */
:root body.woocommerce-checkout .woocommerce-error.oo-notice a {
	color: inherit !important;
	display: inline;
	float: none;
	line-height: inherit;
}

/* ========================================== THE PAYMENT THAT FAILED

   `.woocommerce-thankyou-order-failed` IS TIER 4 AND IS NOT RENDERED BY
   `oo_notice()`, which is the one message in the system that is not. It is
   printed inside WooCommerce's `checkout/thankyou.php`, and overriding that
   whole template to reach one paragraph would put the receipt page's markup in
   this plugin's hands for the sake of a glyph. So the class is given the block
   tier's appearance here, and the sentence stays WooCommerce's own with no lead
   promoted -- which is the honest half-answer rather than a rewrite of the
   vendor's receipt.

   Its glyph is on `::before`, and a `::before` is the thing the component
   stopped using everywhere else: it is a grid item here, in the icon column, so
   the sentence beside it still cannot wrap underneath it. */

.woocommerce-thankyou-order-failed {
	/* The same air above it as every other in-flow notice, for the same
	   reason, and named here because this one is not `.oo-notice` and so is
	   not reached by the rule that gives the others theirs. */
	margin-top: var(--oo-s3, 12px);
	display: grid;
	grid-template-columns: var(--oo-notice-icon-size) 1fr;
	column-gap: var(--oo-notice-gap);
	align-items: start;
	padding: var(--oo-notice-pad-y) var(--oo-notice-pad-x);
	border: 0;
	border-radius: var(--oo-notice-radius);
	background: var(--oo-notice-block);
	color: var(--oo-notice-block-text);
	font-size: var(--oo-notice-size);
	font-weight: var(--oo-notice-weight);
	line-height: var(--oo-notice-lh);
}

/* THE ONE GLYPH PLACED BY ARITHMETIC RATHER THAN BY THE FONT. Everywhere else
   the icon cell holds a zero-width space and the glyph is `vertical-align:
   middle` against its baseline, which lands on the first line's x-height centre
   whatever the typeface. A `::before` cannot hold both the space and the glyph
   -- there is no second pseudo-element inside it -- so this one is centred in a
   box one line-height tall, which is the line box's middle and sits a pixel
   above the x-height's. It is the receipt page's payment failure, it is not
   rendered by `oo_notice()`, and it is the only place in the system where that
   pixel is spent. */
.woocommerce-thankyou-order-failed::before {
	content: "";
	display: block;
	width: var(--oo-notice-icon-size);
	height: calc(var(--oo-notice-size) * var(--oo-notice-lh));
	background-color: currentColor;
	background-image: none;
	-webkit-mask: var(--oo-icon-error-glyph) no-repeat center / var(--oo-notice-icon-size);
	mask: var(--oo-icon-error-glyph) no-repeat center / var(--oo-notice-icon-size);
}

.woocommerce-thankyou-order-failed a {
	color: inherit;
	text-decoration: underline;
}

/* THE TOP-OF-CHECKOUT SLOT. An empty element the router appends into, printed
   by `fk_order_notice_checkout_slot()` above the checkout form at every width.

   IT COSTS NOTHING WHEN IT IS EMPTY, which is every checkout that has no news
   about the whole order -- almost all of them. `:empty` is exact here: the
   element is printed with no whitespace inside it, so it matches until the
   router puts a notice in, and the moment it does the slot takes the same air
   the pause banner takes above it. A slot with a fixed margin would be a gap at
   the top of every checkout in the fleet for the sake of a sentence almost
   nobody sees.

   AND `display: none` IS THE ONE WAY IT MUST NOT BE HIDDEN. `anchorFor()` in
   `assets/notices.js` declines any anchor with no `offsetParent`, which is
   exactly what `display: none` produces -- so the first spelling of this rule
   hid the slot, the router declined it, and the sentence went back to being a
   toast at BOTH viewports. Measured on bench-a, 23 September 2026. An empty
   `div` with no margin already occupies nothing; taking the margin away is the
   whole of "costs nothing", and the box has to stay laid out to be an anchor.

   NO BOX OF ITS OWN. The notice inside it is the `.oo-notice` component and
   carries its own tier, tone, padding and glyph; the slot is a position, not a
   container with an appearance. */
.oo-checkout-top {
	/* IT LINES UP WITH THE COLUMNS AND IT CLEARS THE BACK LINK (25 September
	   2026), which is the answer `.woocommerce-error.oo-notice` above has had
	   since 16 September and this slot never got. Ryan's Sonora shot: a band
	   the full width of the page, wider than either column, with "Back to
	   menu" printed across its first line. "Also the styling is messed up
	   figure it out."

	   THE SIDE INSET IS PRO'S OWN COLUMN INSET. `--oo-checkout-inset` is the
	   2em Pro gives the two checkout columns; `.oo-backlink` and the summary
	   strip already read it, so a full-bleed slot was the one thing on the
	   page not lined up with the form.

	   AND THE TOP MARGIN IS THE PHONE'S. Below 992px `.oo-backlink` takes its
	   own height in the flow, so the ordinary `--oo-s3` between two blocks is
	   all this needs; the clearance rule is in the media query below. */
	margin-top: var(--oo-s3, 12px);
	margin-bottom: var(--oo-s3, 12px);
	margin-inline: var(--oo-checkout-inset, 2em);
}

.oo-checkout-top:empty {
	margin-top: 0;
	margin-bottom: 0;
}

/* ABOVE 992px THE BACK LINK HAS NO HEIGHT TO CLEAR, so the slot has to clear
   it itself. `assets/checkout.css` gives `.oo-backlink` `height: 0` with its
   link absolutely positioned at `top: 0` -- deliberately, so the link costs no
   vertical space -- and anything after it with an ordinary margin slides
   underneath. `--oo-s6` is the same number `.woocommerce-error.oo-notice` uses
   for the same reason and it is measured against the link's own line box:
   24px against a 22.4px line box at 1280 on the bench, which is the link
   cleared by 1.6px and nothing wasted. */
@media (min-width: 992px) {
	.oo-checkout-top {
		margin-top: var(--oo-s6, 24px);
	}

	.oo-checkout-top:empty {
		margin-top: 0;
	}
}