/**
 * Order-received (thank-you) page. WooCommerce's native order-overview list
 * renders on its own light background (Storefront default) while the
 * site-wide dark theme's body text color (--ice-100, near white) never gets
 * overridden inside it — invisible light-on-white until the text is manually
 * selected. Scoped to that box, not its background, since the light box
 * isn't the bug.
 */
.woocommerce-order-overview,
.woocommerce-order-overview li,
.woocommerce-order-overview li strong {
	color: var(--navy-950);
}

/**
 * The order-details TABLE is a different case and is deliberately not given a
 * dark text color here.
 *
 * These pages are WordPress pages, so is_page() is true and page.css loads on
 * them too — and page.css restyles every table for the dark theme with
 * !important (navy-800 panel, cyan-300 headers, ice-200 cells). So this table
 * sits on a DARK surface, not the light Storefront one the rules above were
 * written for, and any navy-950 rule for it is either dead (beaten by
 * !important) or actively harmful.
 *
 * It was the harmful kind. page.css's `td { color: ... !important }` colors the
 * *cell*, which a <strong> inside it does not inherit — so a plain
 * `td strong { color: var(--navy-950) }` here was the only rule targeting those
 * elements directly, and it won. Reported 2026-08-22: the "× 1" quantity and
 * the "Payment cryptocurrency:" label rendered near-black on navy while every
 * other cell was legible, because those two are the only <strong> elements in
 * the table.
 *
 * `inherit` rather than a hardcoded light color on purpose: it takes whatever
 * the cell actually has, so this stays correct on the dark surface today and
 * would not silently re-break if the table ever moved back to a light one.
 */
table.woocommerce-table--order-details td strong,
table.woocommerce-table--order-details .product-quantity,
table.woocommerce-table--order-details .wc-item-meta-label,
table.woocommerce-table--order-details .wc-item-meta dt {
	color: inherit;
}

/* Copy-to-clipboard button, injected next to .shkeeper-payment-address by
   order-received.js. The crypto payment details section itself already
   renders correctly (confirmed during the order #48 test) — not touched
   here, only this new button. */
.altitude-copy-address-btn {
	display: inline-flex;
	align-items: center;
	gap: 6px;
	margin-left: 8px;
	padding: 3px 10px;
	border-radius: 999px;
	border: 1px solid var(--blue-600);
	background: transparent;
	color: var(--cyan-300);
	font-family: var(--font-body);
	font-size: 12px;
	font-weight: 600;
	cursor: pointer;
	vertical-align: middle;
	transition: background .15s ease, color .15s ease;
}
.altitude-copy-address-btn:hover {
	background: var(--blue-600);
	color: #fff;
}
.altitude-copy-address-btn svg {
	width: 13px;
	height: 13px;
}
.altitude-copy-address-btn.is-copied {
	border-color: var(--cyan-400);
	color: var(--cyan-400);
}

/* Per-currency amount note: reassures stablecoin payers that the crypto and
   dollar figures are the same number, and warns volatile-coin payers not to
   recalculate a locked quote. Secondary weight -- it explains the amount
   above it, it isn't competing with it. */
.altitude-crypto-amount-note {
	margin: 4px 0 12px;
	font-size: 13px;
	line-height: 1.5;
	color: var(--slate-500);
	max-width: 46ch;
}

/* QUIET ZONE. The QR spec requires a 4-module white border around the symbol.
   qrcode.js draws its modules edge-to-edge with none, which a phone camera
   tolerates but a wallet's built-in scanner refuses -- the likeliest reason
   order #117 read in the camera app but not in Exodus, at any size. The white
   background plus padding here supplies that border.

   The canvas is also rendered at twice its displayed size (see
   ALTITUDE_CRYPTO_QR_RENDER_SCALE) so module edges stay hard on high-DPI
   screens. Both selectors are needed: qrcode.js draws to a <canvas> and then
   swaps in an <img> of it. */
/* No padding: the generated image already contains the spec's 4-module quiet
   zone (qzone=4), so CSS padding here stacked a second white border on top of
   the first and made the code look lost in a white slab. The background and
   radius stay, so the image's own white margin reads as a rounded tile. */
#shkeeper-payment-qr,
#altitude-account-crypto-qr {
	display: inline-block;
	background: #fff;
	padding: 0;
	border-radius: 8px;
	overflow: hidden;
	line-height: 0;
	cursor: zoom-in;
}
#shkeeper-payment-qr canvas,
#shkeeper-payment-qr img,
#altitude-account-crypto-qr canvas,
#altitude-account-crypto-qr img {
	width: 190px;
	height: 190px;
	max-width: 100%;
	display: block;
}

/* Tap-to-enlarge overlay. The inline code is deliberately modest so it does
   not dominate the page; this is the reliable path when a scanner wants a
   bigger target. */
.altitude-qr-modal {
	position: fixed;
	inset: 0;
	z-index: 99999;
	display: flex;
	align-items: center;
	justify-content: center;
	background: rgba(6, 11, 31, .88);
	padding: 24px;
}
.altitude-qr-modal__inner {
	background: #fff;
	/* Only enough to seat the hint text below the code -- the image supplies
	   its own quiet zone, same as inline. */
	padding: 0 0 18px;
	border-radius: 12px;
	overflow: hidden;
	line-height: 0;
	max-width: 100%;
}
.altitude-qr-modal__inner img {
	display: block;
	width: min(78vw, 78vh, 420px);
	height: min(78vw, 78vh, 420px);
	/* Nearest-neighbour: a QR must keep hard module edges when scaled up.
	   Smooth interpolation is exactly what makes a scaled code unreadable. */
	image-rendering: pixelated;
}
.altitude-qr-modal__hint {
	margin: 14px 0 0;
	text-align: center;
	font-family: var(--font-body);
	font-size: 13px;
	line-height: 1.4;
	color: var(--slate-500);
}