/**
 * WooCommerce checkout (shortcode-based, not Blocks) polish -- fixes for
 * a set of layout issues the customer's own theme/WooPayments defaults
 * don't get right on this site, measured live 2026-09-06 on /penztar/.
 * Scoped to elements WooCommerce/WooPayments itself renders (not
 * Breakdance-authored), so this lives in its own stylesheet rather than
 * being hand-placed in the page builder.
 *
 * Known NOT fixable from here: the Stripe card field and the Apple/
 * Google Pay/Link wallet buttons render inside a cross-origin Stripe
 * iframe -- their own internal colors/shape/corners can't be reached by
 * page CSS at all, only Stripe's own JS-side "appearance" API could
 * change them, which this plugin doesn't expose a filter for.
 */

/* WooCommerce's own checkout markup (labels, table cells, the Select2
   picker) falls back to a generic "system-ui" font stack instead of
   picking up the site's actual Breakdance font -- confirmed live,
   2026-09-06: body computes to "Montserrat, sans-serif" but billing
   labels, .variation dt/dd, and the Select2 text all computed to
   system-ui. Hardcoded rather than "inherit" -- inherit was tried first
   and made it worse (billing labels computed to "Times New Roman"
   instead), because form-associated elements like <label> get their own
   browser-default font treatment that breaks the normal inheritance
   chain up to body in a way plain `inherit` can't reliably escape. */
.woocommerce-checkout,
.woocommerce-checkout input,
.woocommerce-checkout select,
.woocommerce-checkout label,
.woocommerce-checkout table,
.woocommerce-checkout th,
.woocommerce-checkout td,
.woocommerce-checkout dl,
.woocommerce-checkout dt,
.woocommerce-checkout dd,
.woocommerce-checkout .select2-container,
.woocommerce-checkout .select2-container *,
.woocommerce-checkout .select2-results,
.woocommerce-checkout .select2-results * {
	font-family: Montserrat, sans-serif !important;
}

/* Apple Pay / Google Pay / Link buttons stacked above the separator,
   not side by side with it -- WooPayments renders the buttons element
   and the "— VAGY —" paragraph as two siblings; forcing the wrapper to
   a column flex stacks them regardless of the children's own display. */
.wcpay-express-checkout-wrapper {
	display: flex !important;
	flex-direction: column !important;
	align-items: center !important;
	gap: 8px !important;
}

#wcpay-express-checkout-button-separator {
	margin: 0 !important;
}

/* The "Van kuponod? Kattints ide a kód megadásához" prompt at the top
   of the page is replaced by a single always-visible field above the
   total (see .hrc-coupon-form below and the accompanying JS, which
   relocates WooCommerce's own coupon <form>), so the original toggle
   is dropped entirely rather than restyled, 2026-09-07. */
.woocommerce-form-coupon-toggle {
	display: none !important;
}

/* WooCommerce's own coupon form, relocated by JS to sit directly above
   the total row -- restyled as a compact, narrower field (not full
   width) with a separate square icon button OUTSIDE it, matching the
   other checkout inputs' own square-cornered style (border-radius:0,
   border rgb(125,129,136), confirmed live from #billing_email
   2026-09-07) rather than a pill shape. align-items:flex-start (not
   center/stretch) is deliberate: WooCommerce injects its inline error
   message as a <span> INSIDE .form-row-first, right after the input,
   which grows that cell's height -- with center/stretch alignment the
   button re-centers on the taller row and visibly drifts down when an
   error appears (confirmed live 2026-09-07); flex-start anchors the
   button to the input's own top edge regardless, so it never moves.
   The button itself is untouched functionally (still the same
   type="submit", name="apply_coupon" WooCommerce's own checkout.js
   already listens on), only its visible content changes to an SVG
   icon via JS. */
.hrc-coupon-form {
	display: flex !important;
	flex-wrap: nowrap !important;
	align-items: flex-start !important;
	gap: 8px;
	width: 100%;
	margin: 0 0 12px !important;
	padding: 0 !important;
	/* This form still carries WooCommerce's own "woocommerce-form-coupon"
	   class, which the theme gives a bordered, rounded-corner card look
	   by default (border AND a soft drop-shadow, same Breakdance "card"
	   component style already found on .woocommerce-checkout-payment) --
	   confirmed live 2026-09-08, both showed as an unwanted outer box/
	   halo around the input+button pair. */
	border: none !important;
	border-radius: 0 !important;
	box-shadow: none !important;
}

.hrc-coupon-form .form-row {
	margin: 0 !important;
	padding: 0 !important;
}

.hrc-coupon-form .form-row-first {
	flex: 1 1 auto;
	/* Without this, the flex item's default min-width:auto keeps it at
	   its content's intrinsic width (stretched by the long error-message
	   span appended inside it), which left no room for the button on
	   the same line despite flex-shrink:1 -- confirmed live 2026-09-07,
	   the row silently wrapped to two lines instead of shrinking. */
	min-width: 0;
	width: auto !important;
}

/* Height/padding/border/font matched exactly to the other checkout
   inputs (e.g. #billing_email: height 57px, padding 20px, border 1px
   solid rgb(125,129,136)) -- confirmed live 2026-09-08, the customer
   flagged the coupon field as visibly shorter/thinner than the rest. */
.hrc-coupon-form .form-row-first input {
	width: 100%;
	box-sizing: border-box;
	height: 57px;
	padding: 20px !important;
	border: 1px solid rgb( 125, 129, 136 ) !important;
	border-radius: 0 !important;
	font-family: Montserrat, sans-serif !important;
	font-size: 12px !important;
	background: #fff;
}

/* The site's own focus rule for every other input (.input-text:focus)
   already switches BOTH border-color and box-shadow to the accent
   orange -- but our own border rule above carries !important (needed
   to beat that same theme styling at rest), which also blocked that
   rule's border-color change specifically, leaving only the box-shadow
   half to turn orange on focus. Confirmed live 2026-09-08: gray border
   + an orange glow read as a muddy halo instead of the other fields'
   clean solid-orange border. Matching the color explicitly here (same
   var the theme itself uses) restores the clean look. */
.hrc-coupon-form .form-row-first input:focus {
	border-color: var( --hrc-accent, #FF6A3B ) !important;
}

.hrc-coupon-form .form-row-last {
	flex: 0 0 auto;
	width: auto !important;
}

/* !important throughout: this button also carries WooCommerce's own
   "button" class, which the theme styles (background/color) with its
   own !important rule of at least equal specificity -- confirmed live
   2026-09-08, without !important here the button rendered with the
   theme's default black/white instead of a borderless, orange icon. */
.hrc-coupon-form button[name="apply_coupon"] {
	/* Chrome's native `appearance:button` UA styling paints its own
	   subtle background/border/shadow independently of the author
	   styles below -- confirmed live 2026-09-08, this was the actual
	   source of the button still looking like it sat in a bordered/
	   shadowed white box despite background/border/box-shadow all
	   already being reset here. */
	appearance: none !important;
	-webkit-appearance: none !important;
	-moz-appearance: none !important;
	display: flex !important;
	align-items: center;
	justify-content: center;
	flex: 0 0 57px;
	width: 57px !important;
	height: 57px !important;
	padding: 0 !important;
	margin: 0 !important;
	border: none !important;
	border-radius: 0 !important;
	background: none !important;
	box-shadow: none !important;
	outline: none !important;
	color: var( --hrc-accent, #FF6A3B ) !important;
	cursor: pointer;
}

.hrc-coupon-form button[name="apply_coupon"] svg {
	width: 42px !important;
	height: 42px !important;
}

/* WooCommerce/theme's own inline validation message (a <span> appended
   after the input inside .form-row-first, confirmed live 2026-09-07 --
   not the usual top-of-page .woocommerce-error list). Forced to its
   own line under the input rather than left to wrap inline. */
.hrc-coupon-form .coupon-error-notice {
	display: block;
	margin-top: 6px;
	font-family: Montserrat, sans-serif;
	font-size: 12px;
	color: #8a1f1f;
}

.hrc-coupon-form .clear {
	display: none;
}

/* Applied coupon(s): WooCommerce's own tr.cart-discount row (native
   markup, inside the order table) is hidden and its info rebuilt here
   as a small removable chip under the coupon field instead -- matches
   the customer's own cart-page remove icon (a bare "×" character,
   confirmed live 2026-09-08 from .remove_from_cart_button: font-size
   20px, color rgb(120,126,139), no background/border) rather than a
   custom icon. The remove link itself is the SAME native
   <a class="woocommerce-remove-coupon"> WooCommerce's own checkout.js
   already binds AJAX removal to -- only relabeled to "×", not rebuilt,
   so removing a coupon here keeps working through WooCommerce's own
   logic. */
.hrc-coupon-chips {
	display: flex;
	flex-wrap: wrap;
	gap: 8px;
	margin: 0 0 12px;
}

.hrc-coupon-chip {
	display: flex;
	align-items: center;
	gap: 8px;
	background: rgb( 249, 251, 252 );
	border: 1px solid rgb( 209, 213, 219 );
	padding: 6px 8px 6px 12px;
	font-family: Montserrat, sans-serif;
	font-size: 12px;
	color: var( --hrc-text, #152427 );
}

.hrc-coupon-chip-remove {
	appearance: none;
	-webkit-appearance: none;
	display: block;
	border: 0;
	background: none;
	padding: 0;
	font-size: 20px;
	line-height: 10px;
	color: rgb( 120, 126, 139 );
	text-decoration: none;
	cursor: pointer;
}

.hrc-coupon-chip-remove:hover {
	color: #8a1f1f;
}

/* Order summary table: right-align the subtotal column, let the table
   use its full available width, and stop the variation detail values
   ("Ø 67,1 mm") from wrapping mid-word in the narrower product column.
   table-layout:fixed is required here -- with the default "auto" layout,
   width:100% is only a MINIMUM, and long cell content (the csomagautomata
   picker's own selected-option text) was stretching the whole table (and
   with it, the entire order-summary column) past its own container,
   confirmed live 2026-09-06. Fixed layout makes 100% an actual cap and
   wraps/clips content instead. */
.woocommerce-checkout-review-order-table {
	width: 100% !important;
	table-layout: fixed !important;
}

/* The table's own "border" (see the .hrc-card comment further down) is
   a box-shadow inset on thead/tbody, not a real border -- confirmed
   live on an actual iPhone (2026-09-07) that this 1px inset box-shadow
   doesn't render at all in iOS Safari. Putting a real `border` directly
   on the <table> was the first attempt, but border-collapse:collapse
   (set natively on this table) resolves the table's own border against
   its cells' own explicit "0px none" borders at the shared edge, and in
   practice -- despite "none" normally losing that conflict per spec --
   it rendered on no browser at all, not just iOS, once this was live
   (confirmed live 2026-09-07). A plain wrapper div sidesteps the table
   border model entirely, the same way .hrc-card does for the shipping
   card; the accompanying JS creates it once around the table. */
.hrc-order-table-wrap {
	border: 1px solid rgb( 209, 213, 219 );
	border-radius: 4px;
	overflow: hidden;
}

/* The table's own native thead/tbody box-shadow (the original border
   trick that doesn't render on iOS) is still active underneath the new
   wrapper above -- left alone it now draws a second, redundant border
   just inside the wrapper's real one, confirmed live 2026-09-07. Only
   the wrapper's border should show. */
.woocommerce-checkout-review-order-table thead,
.woocommerce-checkout-review-order-table tbody {
	box-shadow: none !important;
}

.woocommerce-checkout-review-order-table th.product-total,
.woocommerce-checkout-review-order-table td.product-total,
.woocommerce-checkout-review-order-table tr.cart-subtotal td,
.woocommerce-checkout-review-order-table tr.order-total td {
	width: 130px;
	text-align: right !important;
	padding-left: 12px !important;
	/* Explicit, not left to whatever default padding-right the browser/
	   WooCommerce otherwise applies here -- that turned out to only be
	   ~2px on this column (vs. ~13px on the product-name column's left),
	   so "RÉSZÖSSZEG" sat almost flush against the card's right edge
	   instead of matching "TERMÉK"'s inset on the left. Confirmed live,
	   2026-09-06 via a text-range measurement (not the cell's own box,
	   which reported the padding correctly but the rendered text still
	   didn't respect it). */
	padding-right: 12px !important;
	box-sizing: border-box !important;
}

/* Only the actual price VALUES need to stay on one line -- the column
   header text ("RÉSZÖSSZEG") is longer than any price and was getting
   clipped by the 100px column when nowrap applied to it too, confirmed
   live 2026-09-06. Letting the header wrap onto two lines if it must
   costs nothing visually; a clipped column header would have. */
.woocommerce-checkout-review-order-table td.product-total,
.woocommerce-checkout-review-order-table tr.cart-subtotal td,
.woocommerce-checkout-review-order-table tr.order-total td {
	white-space: nowrap !important;
}

.woocommerce-checkout-review-order-table dl.variation {
	display: grid;
	grid-template-columns: auto auto;
	column-gap: 6px;
	row-gap: 2px;
	margin: 6px 0 0;
}

.woocommerce-checkout-review-order-table dl.variation dt,
.woocommerce-checkout-review-order-table dl.variation dd {
	margin: 0;
	white-space: nowrap;
}

.woocommerce-checkout-review-order-table dl.variation dd p {
	margin: 0;
	white-space: nowrap;
}

/* Keeps "Egyedi központosító gyűrű × 4" on one line -- the text and the
   quantity are a bare text node + a <strong>, not their own wrappable
   unit, so the accompanying JS (CheckoutStyling::maybe_enqueue) wraps
   them in this span on first render; this just styles that wrapper. */
.hrc-product-name-line {
	white-space: nowrap;
	display: block;
}

/* The shipping-method and csomagautomata rows (WooCommerce/Foxpost's own
   responsive th|td pairs) kept getting squeezed to their original table
   column width no matter what display override was applied to the row/
   cells -- table-layout:fixed (needed above to stop the table itself
   overflowing) assigns column widths per cell position regardless,
   confirmed live 2026-09-06. The accompanying JS physically moves these
   two rows' actual content out of the table into these plain, non-table
   wrapper divs instead of fighting that further; this just styles them
   to look like a natural continuation of the same card. */
.hrc-wide-row {
	width: 100%;
	padding: 8px 0;
}

.hrc-wide-row-label {
	font-weight: 700;
	margin-bottom: 6px;
}

.hrc-wide-row-content {
	width: 100%;
}

/* The grand total ("Összeg") row is relocated the same way (so it ends
   up below shipping/csomagautomata instead of stuck above them at its
   original in-table position), but should keep looking like a normal
   label-left/amount-right total line, not the stacked layout the other
   two wide rows use. Horizontal padding matches the price column's own
   padding-right above (12px) so the amount's right edge lines up with
   "Részösszeg"/"Összeg" in the table -- confirmed via text-range
   measurement, 2026-09-07. */
.hrc-total-row {
	display: flex;
	justify-content: space-between;
	align-items: baseline;
	padding: 12px 12.944px 0;
	border-top: 1px solid #e5e2df;
	box-sizing: border-box;
}

.hrc-total-row .hrc-wide-row-label {
	margin-bottom: 0;
	font-family: Montserrat, sans-serif;
	font-weight: 700;
	font-size: 17px;
}

.hrc-total-row .hrc-wide-row-content {
	width: auto;
	white-space: nowrap;
	font-size: 1.08em;
}

/* Shared "card" look matching the order-summary table's own border,
   confirmed live 2026-09-07: the table itself has border:none -- its
   visible rounded-border box actually comes from box-shadow insets set
   on <thead> (left/top/right) and <tbody> (all 4 sides), both with
   border-radius:4px. A plain border/radius on an ordinary div is a
   simpler way to reproduce the identical look (same color, same
   radius) without needing the box-shadow workaround a table needs. */
.hrc-card {
	border: 1px solid rgb( 209, 213, 219 );
	border-radius: 4px;
	overflow: hidden;
	background: #fff;
	margin-top: 8px;
}

/* Matches the order-summary table's own <thead> exactly: same
   background, font, size, weight, case, tracking and padding,
   confirmed live 2026-09-07. !important throughout because this class
   also gets added directly onto the payment gateway's own <label>
   (see .hrc-payment-header below), which carries its own more specific
   native font-size/weight from the theme/WooCommerce -- confirmed live,
   a plain class-level rule lost to that native styling on the label
   even though it applied fine on the shipping card's own plain divs. */
.hrc-card-header {
	background: rgb( 243, 244, 246 ) !important;
	color: rgb( 21, 36, 39 ) !important;
	font-family: Montserrat, sans-serif !important;
	font-weight: 500 !important;
	font-size: 12.8px !important;
	text-transform: uppercase !important;
	letter-spacing: 1px !important;
	padding: 12.944px !important;
	margin: 0 !important;
	display: block !important;
	box-sizing: border-box !important;
}

.hrc-card-section {
	padding: 12px 12.944px;
}

.hrc-card-section .woocommerce-shipping-methods {
	margin-top: 0;
}

/* A second header inside the same card (csomagautomata, stacked below
   shipping) needs its own top border to visually separate it from the
   section above -- the outer .hrc-card border only wraps the whole
   thing once. Its background is a shade lighter than the other headers
   (rgb(249,251,252) vs rgb(243,244,246)) at the customer's request, so
   it reads as visually secondary/nested rather than a second identical
   header. */
.hrc-card-section + .hrc-card-header {
	border-top: 1px solid rgb( 229, 231, 235 );
	background: rgb( 249, 251, 252 ) !important;
}

/* Reuses the payment method's own <label> as a matching gray header
   bar directly on top of its .payment_box, so the pair reads as one
   card the same way the order-summary table and the new shipping card
   do. border-radius on .payment_box is switched from the previous 12px
   to the shared 4px so the two visually belong together, and its own
   top border is dropped since the header's bottom edge already
   supplies that line. */
.hrc-payment-header {
	cursor: pointer;
	border-radius: 4px 4px 0 0;
	border: 1px solid rgb( 209, 213, 219 );
	border-bottom: 1px solid rgb( 209, 213, 219 );
	/* li.wc_payment_method is display:flex (confirmed live, 2026-09-07),
	   so the label -- a flex item -- shrinks to its own text width
	   instead of filling the row; same fix as the shipping-method list
	   items above. */
	flex: 1 1 auto !important;
	width: auto !important;
	/* Even at full flex width the label still only spanned
	   ul.payment_methods, which sits inset inside the actual visible
	   card (.woocommerce-checkout-payment has padding:24px plus its own
	   1px border) -- confirmed live, 2026-09-07. Negative margins pull
	   the header out to that outer card's own edge (same radius, 4px,
	   so the corners still line up) instead of stopping short of it;
	   -25px, not -24px, since the outer wrapper's own 1px border sits
	   outside its padding box too. */
	margin: -25px -25px 0 -25px !important;
}

/* This box sits with a real ~15px gap below the header (WooCommerce's
   own default spacing, confirmed live 2026-09-07 -- they aren't flush
   like thead/tbody), so it needs all four corners rounded, not just
   the bottom two, and its own border color/width need to match the
   other cards (rgb(209,213,219), 1px) instead of the theme's own
   slightly different native gray (rgb(229,231,235)). */
.hrc-payment-header + .payment_box {
	border-radius: 4px !important;
	border: 1px solid rgb( 209, 213, 219 ) !important;
}

.woocommerce-shipping-methods {
	margin: 8px 0 0;
	padding: 0;
}

/* This site's own base styles already force li to display:flex
   (confirmed live, 2026-09-06 -- not something this stylesheet sets) --
   working with that instead of fighting it, rather than assuming a plain
   list item box. */
.woocommerce-shipping-methods li {
	list-style: none;
	margin: 0 0 8px;
	display: flex !important;
	align-items: baseline !important;
}

.woocommerce-shipping-methods li input {
	flex: none;
	margin: 0 8px 0 0;
}

/* flex:1 1 auto makes the label actually stretch to the row's full width
   instead of shrink-wrapping its own text (the flex default) -- without
   this the floated price below only reached the right edge of the
   label's own (too narrow) box, not the row's, confirmed live 2026-09-06. */
.woocommerce-shipping-methods li label {
	flex: 1 1 auto;
	display: block;
	overflow: hidden; /* new block formatting context so the float below is scoped to this label, not the whole row */
}

/* Floats reliably keep "name left, price right, same line" without the
   flex-wrap approach's tendency to push the whole price (or even break
   it mid-number) onto its own line when the label text is long --
   confirmed live, 2026-09-06. */
.woocommerce-shipping-methods li label .woocommerce-Price-amount {
	float: right;
	white-space: nowrap;
	padding-left: 8px;
}

/* Csomagautomata (Select2) picker + the address confirmation block that
   Foxpost's own script inserts after a locker is picked: both full
   width under their own label, not squeezed sideways. The real culprit
   was max-width:220px (from Select2's/Foxpost's own CSS) capping the
   box regardless of the width:100% Select2 itself sets inline -- found
   by comparing computed width vs computed max-width live, 2026-09-06. */
.select2-container,
.select2-container .select2-selection {
	width: 100% !important;
	max-width: 100% !important;
}

/* Payment method boxes (Stripe and any other active gateway): swap the
   default flat gray for a pale orange tint on-brand with the rest of
   the site, and make sure the inner form actually fills the box instead
   of leaving an unexplained gap on the right. */
.payment_box {
	background: color-mix( in srgb, var( --hrc-accent, #FF6A3B ) 6%, white ) !important;
	border-radius: 12px !important;
	display: block !important;
}

#wc-stripe-upe-form,
.wc-stripe-upe-element {
	width: 100% !important;
}

/* The payment section's own outer wrapper (.woocommerce-checkout-payment,
   a Breakdance "card" component) carries its own soft native drop
   shadow on top of its border -- confirmed live 2026-09-07, this is
   what read as a mismatched "shadow" behind the Hitelkártya/Bankkártya
   card next to the other, shadow-less cards above it. Dropped so this
   card is flat-bordered like the rest. */
.woocommerce-checkout-payment {
	box-shadow: none !important;
}

/* Hides the small payment-gateway card-brand icon WooCommerce/Stripe
   renders inline after the label text -- the header should read as
   plain text, matching the other cards' headers. */
.hrc-payment-header img {
	display: none !important;
}

/* --- Cart page ("Kosár összesen") ------------------------------------- */

/* Both only matter when a live shipping-rate calculation could still
   change the price shown -- this site uses fixed shipping costs, so
   the customer asked to drop them entirely rather than have them
   flash into view (both come with an inline style="display:none" that
   some WooCommerce/carrier-plugin script un-hides once a method is
   selected). */
.woocommerce-shipping-destination,
.shipping-calculator-button {
	display: none !important;
}

/* Right-aligns the Subtotal amount so its right edge lines up with the
   shipping prices in the card below (and the total further down) --
   confirmed live 2026-09-08, this row's own td defaults to text-align
   left with no matching right padding, off by ~170px from the shipping
   price column's own inset. 12.944px matches .hrc-card-section's own
   right padding so the two line up exactly. */
.cart_totals table.shop_table tr.cart-subtotal td {
	text-align: right !important;
	padding-right: 12.944px !important;
	box-sizing: border-box;
}

/* This row's own native border-bottom (the theme's default shop_table
   row divider) was the only content left in this table once shipping/
   pickup/total got relocated into the card below it -- confirmed live
   2026-09-08, that leftover border read as an unwanted line between
   Subtotal and the new card. */
.cart_totals table.shop_table tr.cart-subtotal {
	border-bottom: none !important;
}

/* --- Checkout: "Mobilszám" field ---------------------------------------- */

/* Same inline-error look as .coupon-error-notice above, reused for the
   phone field's own format error ("A megadott mobilszám nem
   megfelelő."). */
.hrc-phone-error {
	display: block;
	margin-top: 6px;
	font-family: Montserrat, sans-serif;
	font-size: 12px;
	color: #8a1f1f;
}

.hrc-phone-invalid {
	border-color: #8a1f1f !important;
}