/*
 * The host's own theme: the brand colour, and where the primary actions live.
 *
 * WRITTEN BY HAND, UNLIKE rtl.css. Nothing generates this file and nothing
 * overwrites it.
 *
 * Both halves exist for the same reason as everything else in public/: the
 * configurator is a built artifact, so a colour typed into
 * assets/assets/index-*.css and a button moved in index-*.js survive exactly
 * until the next build is dropped in. Overriding from out here means a new
 * build changes the court and leaves the client's brand and layout alone.
 *
 * Every selector hangs off STRUCTURE — an element name, a Tailwind utility the
 * app already carries — and never off English, so a reworded label cannot break
 * it. What a rebuild CAN break is the utility names themselves; §11 of
 * CLAUDE.md has the check to run.
 */

/* ------------------------------------------------------------------ */
/* 1. The brand colour                                                 */
/*                                                                     */
/* The bundle ships a crimson scale — #831420 and seven tints of it —   */
/* used for every accent: panel headers, the primary button, the active */
/* tab, info badges, focus rings. The client's site is navy, and half a */
/* recolour reads as a bug, so the whole scale moves rather than the    */
/* one class. Anchored on #161b36, which is what they asked for; the    */
/* rest is derived from it.                                            */
/*                                                                     */
/* Two tints are NOT navy, and deliberately. `text-crimson-400` is      */
/* painted on the scene toolbar's `bg-black/25` and `text-crimson-300`  */
/* on white; a dark navy at either size would be a smudge. They get the */
/* light end of the same hue instead, so they stay legible and still    */
/* belong to the palette.                                              */
/*                                                                     */
/* The `--tw-*-opacity` custom property is kept in every value. The app */
/* sets it on the same element (`bg-white/55`, `bg-black/25`), and a    */
/* flat hex here would quietly ignore it.                              */
/* ------------------------------------------------------------------ */

.stellar-app .bg-crimson {
	background-color: rgb(22 27 54 / var(--tw-bg-opacity, 1));
}

.stellar-app .bg-crimson-600,
.stellar-app .hover\:bg-crimson-600:hover {
	background-color: rgb(37 44 82 / var(--tw-bg-opacity, 1));
}

/* Hover has to move AWAY from #161b36, not toward black: the base is already
   dark enough that a darker hover is no feedback at all. */
.stellar-app .hover\:bg-crimson-400:hover {
	background-color: rgb(58 68 122 / var(--tw-bg-opacity, 1));
}

.stellar-app .bg-crimson-100 {
	background-color: rgb(215 219 232 / var(--tw-bg-opacity, 1));
}

.stellar-app .bg-crimson-50,
.stellar-app .hover\:bg-crimson-50:hover {
	background-color: rgb(238 240 246 / var(--tw-bg-opacity, 1));
}

.stellar-app .bg-crimson-25 {
	background-color: rgb(247 248 251 / var(--tw-bg-opacity, 1));
}

.stellar-app .text-crimson,
.stellar-app .hover\:text-crimson:hover {
	color: rgb(22 27 54 / var(--tw-text-opacity, 1));
}

/* On white — the empty-state and toast icons. */
.stellar-app .text-crimson-300 {
	color: rgb(125 136 189 / var(--tw-text-opacity, 1));
}

/* On the scene toolbar's translucent black. Light, or it disappears. */
.stellar-app .text-crimson-400 {
	color: rgb(154 165 216 / var(--tw-text-opacity, 1));
}

.stellar-app .border-crimson,
.stellar-app .hover\:border-crimson:hover,
.stellar-app .focus\:border-crimson:focus {
	border-color: rgb(22 27 54 / var(--tw-border-opacity, 1));
}

.stellar-app .border-crimson-200 {
	border-color: rgb(174 182 208 / var(--tw-border-opacity, 1));
}

.stellar-app .hover\:border-crimson-300:hover {
	border-color: rgb(125 136 189 / var(--tw-border-opacity, 1));
}

.stellar-app .ring-crimson {
	--tw-ring-color: rgb(22 27 54 / var(--tw-ring-opacity, 1));
}

/*
 * The eyebrow above the picker heading is the exception section 3 makes for
 * Submit, one screen earlier: it is not chrome. Navy put it at the same weight
 * as the heading under it and the wordmark over it, and the line that says what
 * the page is for disappeared into the page. It takes the app's own #831420
 * back, so the first screen and the action bar are warm in the same one place.
 *
 * `tracking-[.16em]` occurs exactly ONCE in the bundle and it is on this span —
 * structure, not English, so the rewording in public/app-ar.js and app-en.js
 * cannot reach it. It has to sit after `.text-crimson` above: the two have the
 * same specificity and source order is what decides. Check the utility is still
 * unique after a new build, alongside the eighteen in section 1.
 */
.stellar-app .tracking-\[\.16em\] {
	color: rgb(131 20 32 / var(--tw-text-opacity, 1));
}

/* ------------------------------------------------------------------ */
/* 2. Save / Submit move to the top of the panel                       */
/*                                                                     */
/* THE PROBLEM WAS NOT THE BUTTONS, IT WAS WHERE THE BOTTOM IS. The     */
/* container is 100vh and it starts BELOW the site header and the       */
/* breadcrumb — roughly 135px on the client's theme — so the last 135px */
/* of the app, which is the whole action bar, sits under the fold. The  */
/* customer has to scroll the page to find the one control the page     */
/* exists for, and on a short laptop screen never discovers it at all.  */
/*                                                                     */
/* Moving the bar to the top of the panel makes it independent of the   */
/* container's height: whatever a theme does below the fold, the first  */
/* thing under the panel header is Submit. It is the same one bar — not */
/* a duplicate that has to be kept in sync with the real one, and not a */
/* floating dock over the court — so there is nothing new to click and  */
/* nothing new to translate.                                           */
/*                                                                     */
/* Done with `order` rather than by moving nodes: React owns this tree  */
/* and re-renders it whenever the customer opens a panel or comes back  */
/* from a design. A DOM move would have to be re-applied on every one   */
/* of those, and would race the paint each time. `order` is declarative */
/* and cannot be undone by a re-render.                                */
/* ------------------------------------------------------------------ */

/*
 * Narrow screens: the panel is a bottom sheet with no header of its own —
 * the header is a sibling above it — so the bar goes first, above the tab
 * strip, where it is visible whether the sheet is open or collapsed.
 */
.stellar-app footer {
	order: -1;
}

/*
 * Wide screens: the panel is a column of header / content / bar. The bar goes
 * second, directly under the header. `:not(header):not(footer)` is whatever
 * the middle is at the time — the accordion list, the summary, the enquiry
 * form — so the three states need no rules of their own.
 */
.stellar-app aside > header {
	order: 0;
}

.stellar-app aside > footer {
	order: 1;
}

.stellar-app aside > :not(header):not(footer) {
	order: 2;
}

/*
 * It is no longer the bottom of anything. The rule that separated it from the
 * list above now separates it from the list below, and a short shadow lifts it
 * over content that scrolls under it rather than past it.
 */
.stellar-app footer.border-t {
	position: relative;
	z-index: 2;
	border-top-width: 0;
	border-bottom-width: 1px;
	box-shadow: 0 6px 12px -10px rgb(20 27 55 / 0.45);
}

/*
 * Two equal columns gave a secondary action the same weight as the primary
 * one. Save takes the width of its own label; Submit takes the rest. Logical
 * sizing only — no left, no right — so it is the same rule in Arabic, where
 * the first column lands on the right.
 */
.stellar-app footer.grid-cols-2 {
	grid-template-columns: auto minmax(0, 1fr);
}

/* ------------------------------------------------------------------ */
/* 3. The one action that is not chrome                                */
/*                                                                     */
/* Section 1 moved the whole crimson scale to navy, and for the panel   */
/* headers, the active tab and the info badges that is right: they are  */
/* chrome, and chrome should be the site's own colour.                  */
/*                                                                     */
/* Submit is not chrome. Navy on navy gave the button the same weight   */
/* as the header above it and the outline beside it, and the one        */
/* control the page exists for read as another panel. #831420 — the     */
/* app's own crimson, kept for exactly this — is the only warm thing on */
/* the screen, so the eye lands on it before anything else.             */
/*                                                                     */
/* Scoped to the action bar rather than handed back to `.bg-crimson`,   */
/* which would take the headers with it. Structure, not English: the    */
/* footer holds exactly two buttons, Save then Submit, so `last-child`  */
/* is the primary one in either reading direction.                      */
/* ------------------------------------------------------------------ */

.stellar-app footer.grid-cols-2 > button:last-child {
	background-color: rgb(131 20 32 / var(--tw-bg-opacity, 1));
}

/* Darker on hover, not lighter: #831420 has the room, and the app's own
   crimson-600 is the shade the rest of the build already uses for this. */
.stellar-app footer.grid-cols-2 > button:last-child:hover {
	background-color: rgb(111 17 27 / var(--tw-bg-opacity, 1));
}

/*
 * A keyboard user gets nothing from a colour they cannot see the focus on.
 * The offset keeps the ring outside the fill rather than on top of it, and
 * `:focus-visible` means a mouse click does not leave it behind.
 */
.stellar-app footer.grid-cols-2 > button:focus-visible {
	outline: 2px solid rgb(131 20 32);
	outline-offset: 2px;
}

/* ------------------------------------------------------------------ */
/* 4. The saved / share notice moves to the top of the scene           */
/*                                                                     */
/* Same problem as section 2, and the same shape of answer. The notice  */
/* that carries the share link was pinned to the BOTTOM CORNER OF THE   */
/* VIEWPORT — `fixed bottom-6 left-6` — which is the far end of the     */
/* page from the button that produces it, because section 2 moved Save  */
/* to the TOP of the panel. The customer pressed a control at the top   */
/* of the screen and the confirmation appeared 800px below it, past the */
/* court, in the corner the eye never visits. Several never found it,   */
/* and the link it holds is the whole point of pressing Save.           */
/*                                                                     */
/* It now sits at the top of the scene, on the same band as the action  */
/* bar that opened it: the eye travels sideways, not down. Anchored to  */
/* the app's own box rather than the viewport, which is the section 2   */
/* lesson again — the container is 100vh starting below the site header */
/* and the breadcrumb, so the viewport's edges and the app's edges are  */
/* not the same edges.                                                 */
/*                                                                     */
/* Anchoring to the box also fixes something quieter. `inset-inline-*`  */
/* resolves against the CONTAINING BLOCK's direction, and for a `fixed` */
/* element that is the document — so on an Arabic builder embedded in a */
/* page whose <html> is still LTR, rtl.css's mirrored offset landed on  */
/* the wrong side. Positioned against `.stellar-app`, which rtl.css     */
/* sets `direction:rtl` on itself, start is start in either host.       */
/* ------------------------------------------------------------------ */

.stellar-app {
	position: relative;
}

/*
 * The app's own breakpoint for the side-panel layout, copied exactly — see
 * the `(min-width: 1024px), (orientation: landscape) and (min-width: 640px)`
 * it passes to its media hook. Below it the panel is a bottom sheet, the
 * notice is already centred above it, and there is nothing to fix.
 */
@media (min-width: 1024px), (orientation: landscape) and (min-width: 640px) {

	/*
	 * `pointer-events-auto` appears exactly once in the bundle, on this
	 * element, for the same reason it is here: it is the one thing that
	 * floats. Structure, not English — the message inside it is translated.
	 */
	.stellar-app .fixed.pointer-events-auto {
		position: absolute;
		inset: .75rem auto auto;
		inset-inline-start: .75rem;

		/*
		 * `-translate-x-1/2` centres it on a phone and `md:translate-x-0`
		 * un-centres it here. Dropped outright rather than overridden: it is
		 * no longer centred on anything, and a transform on the box would
		 * make it the containing block for its own descendants.
		 */
		transform: none;

		/*
		 * The panel is the other side of this box, so the notice is measured
		 * against what is left of it: 100% is the app, not the window, and
		 * the bundle's own `w-[min(560px,calc(100vw-32px))]` counted the
		 * panel and the page's scrollbar as space it could use. Widths are
		 * the app's `w-[300px] lg:w-[380px] xl:w-[430px]`.
		 */
		width: min(560px, calc(100% - 300px - 1.5rem));

		/* It arrives while the customer is looking somewhere else on the same
		   band; a short move down says a new thing appeared. */
		animation: stellar-notice-in .18s ease-out both;
	}
}

@media (min-width: 1024px) {
	.stellar-app .fixed.pointer-events-auto {
		width: min(560px, calc(100% - 380px - 1.5rem));
	}
}

@media (min-width: 1280px) {
	.stellar-app .fixed.pointer-events-auto {
		width: min(560px, calc(100% - 430px - 1.5rem));
	}
}

@keyframes stellar-notice-in {
	from {
		opacity: 0;
		transform: translateY(-.5rem);
	}

	to {
		opacity: 1;
		transform: none;
	}
}

@media (prefers-reduced-motion: reduce) {
	.stellar-app .fixed.pointer-events-auto {
		animation: none;
	}
}

/* ------------------------------------------------------------------ */
/* 5. The size sliders                                                 */
/*                                                                     */
/* TWO THINGS WERE WRONG, AND ONLY ONE OF THEM IS A COLOUR.            */
/*                                                                     */
/* The fill and the thumb disagreed in Arabic. A range input is one of */
/* the few controls a browser mirrors by itself, so under `direction:  */
/* rtl` the thumb travels from the right — but the bundle paints the   */
/* filled part of the track with `linear-gradient(to right, …)` and a  */
/* gradient has no reading direction. At 68% the fill reached 68% from */
/* the LEFT and the thumb stood 68% from the RIGHT: the customer       */
/* dragged the handle and watched a bar move the other way.            */
/*                                                                     */
/* tools/build-rtl-css.js could not have caught it. It mirrors         */
/* PROPERTIES that set a left or a right, and this is a keyword inside */
/* a value — so the direction is a custom property here, and rtl.css   */
/* flips that one token. `input.stellar-range` in tools/rtl-head.css   */
/* is (0,2,1) against the (0,2,0) below, which is what lets the flip   */
/* win from the stylesheet that loads FIRST.                           */
/*                                                                     */
/* The colour is section 1 finishing its job. These four declarations  */
/* are not Tailwind utilities — they are hand-written rules on the     */
/* pseudo-elements, which is why the crimson in them survived the      */
/* recolour and left one red control in a navy panel.                  */
/* ------------------------------------------------------------------ */

.stellar-app .stellar-range {
	--stellar-range-fill: rgb(22 27 54);
	--stellar-range-track: rgb(232 232 232);
	--stellar-range-dir: right;
}

/*
 * One rule per vendor pseudo-element, never a list: a selector the browser
 * cannot parse invalidates the WHOLE rule it is in, so grouping these would
 * cost Chrome its track in Firefox and the other way round.
 *
 * `--pct` is the app's own custom property, set inline on the input and
 * inherited down here, so the fill still follows the value the app computes.
 */
.stellar-app .stellar-range::-webkit-slider-runnable-track {
	background: linear-gradient(
		to var(--stellar-range-dir, right),
		var(--stellar-range-fill) 0%,
		var(--stellar-range-fill) var(--pct),
		var(--stellar-range-track) var(--pct),
		var(--stellar-range-track) 100%
	);
}

.stellar-app .stellar-range::-moz-range-track {
	background: linear-gradient(
		to var(--stellar-range-dir, right),
		var(--stellar-range-fill) 0%,
		var(--stellar-range-fill) var(--pct),
		var(--stellar-range-track) var(--pct),
		var(--stellar-range-track) 100%
	);
}

.stellar-app .stellar-range::-webkit-slider-thumb {
	background: var(--stellar-range-fill);
}

.stellar-app .stellar-range::-moz-range-thumb {
	background: var(--stellar-range-fill);
}

/* The bundle rings the thumb in crimson-400. Navy on a navy thumb is no ring
   at all, so this one takes the light end of the scale, like the two tints
   section 1 keeps light for the same reason. */
.stellar-app .stellar-range:focus-visible::-webkit-slider-thumb {
	outline: 2px solid rgb(125 136 189);
}

.stellar-app .stellar-range:focus-visible::-moz-range-thumb {
	outline: 2px solid rgb(125 136 189);
	outline-offset: 2px;
}