.xtool-wc-notice {
	padding: 16px;
	text-align: center;
	background: #F2EDE7;
	border: 1px dashed #D4CEC7;
	border-radius: 8px;
	color: #8A8680;
	font-size: 13px;
}

/*
 * form.cart is NOT just "quantity + button" - for a VARIABLE product it's
 * WooCommerce's own outer form wrapping BOTH the attribute-selector
 * table.variations AND the quantity/button area together. Making form.cart
 * itself a flex row (a real bug caught and fixed live, reported as the
 * qty+button block "jumping up" beside/above the Color attribute row once
 * Full Width forced flex-wrap:nowrap) put the attributes table and the
 * qty+button div side by side as flex siblings instead of stacked - it
 * only ever looked right before by accident, because the default
 * flex-wrap:wrap happened to push them onto separate lines.
 *
 * Real fix: flex only ever applies to the actual "quantity + button" box -
 * `.woocommerce-variation-add-to-cart` for a variable product (WooCommerce's
 * own real, dedicated wrapper for exactly this), or form.cart itself ONLY
 * when it has no variations table at all (a simple product, where
 * form.cart directly IS just quantity + button, nothing else to protect
 * against).
 */
.xtool-wc-add-to-cart form.cart:not(:has(table.variations)),
.xtool-wc-add-to-cart .woocommerce-variation-add-to-cart {
	display: flex;
	align-items: center;
	gap: 14px;
	flex-wrap: wrap;
}

.xtool-wc-add-to-cart .quantity {
	margin: 0;
}

/* ─── Quantity Stepper ────────────────────────────────────────────────────
   WooCommerce's own woocommerce_quantity_input() renders a bare native
   number input with no +/- buttons at all (those are usually added by a
   theme's own JS, if at all) - wc-add-to-cart.js wraps it in this pill and
   inserts 2 real <button>s that only ever set the SAME native input's own
   .val() + trigger('change'), never touching cart/submission logic. */
.xtool-qty-stepper {
	display: inline-flex;
	align-items: center;
	border: 2px solid #1A1814;
	border-radius: 999px;
	overflow: hidden;
	height: 52px;
	background: #fff;
	box-sizing: border-box;
}

.xtool-qty-stepper input.qty {
	border: none !important;
	background: none !important;
	box-shadow: none !important;
	text-align: center;
	width: 40px;
	flex: 0 0 auto;
	-moz-appearance: textfield;
	font-size: 15px;
	font-weight: 600;
	color: inherit;
	padding: 0 !important;
	height: 100%;
}

.xtool-qty-stepper input.qty::-webkit-outer-spin-button,
.xtool-qty-stepper input.qty::-webkit-inner-spin-button {
	-webkit-appearance: none;
	margin: 0;
}

.xtool-qty-stepper__btn,
.xtool-qty-stepper__btn:hover,
.xtool-qty-stepper__btn:focus,
.xtool-qty-stepper__btn:active {
	background: none !important;
	border: none !important;
	box-shadow: none !important;
	outline: none !important;
	cursor: pointer;
	font-size: 18px;
	line-height: 1;
	width: 44px;
	height: 100%;
	display: flex;
	align-items: center;
	justify-content: center;
	color: inherit;
	flex-shrink: 0;
	padding: 0;
}

.xtool-wc-add-to-cart .button {
	display: inline-flex;
	align-items: center;
	justify-content: center;
	white-space: nowrap;
	flex: 1 1 auto;
	text-align: center;
	border-width: 0;
}

/* "Full Width" Style switch - keeps the Quantity Stepper and button on the
   SAME row (confirmed directly - a first version stacked them into 2 rows
   instead, reported live as the button "jumping down" to its own line,
   which wasn't wanted). The Quantity Stepper keeps its own natural/fixed
   width (its default flex-grow:0), `flex-wrap:nowrap` guarantees they
   never wrap onto 2 lines even on a narrow column, and the button's own
   flex-basis is forced to 0 (instead of the base rule's `auto`) so it
   claims 100% of whatever space is left next to the stepper, rather than
   sizing from its own text first and only growing from there.
   Same not(:has(table.variations)) / .woocommerce-variation-add-to-cart
   pairing as the base rule above, for the same reason - a real, confirmed
   live bug (reported as the qty+button block jumping up beside/above the
   Color attribute row) came from applying `flex-wrap:nowrap` to the WHOLE
   form.cart on a variable product, which also contains the attributes
   table as a flex sibling, not just quantity+button. */
.xtool-wc-add-to-cart--full-width form.cart:not(:has(table.variations)),
.xtool-wc-add-to-cart--full-width .woocommerce-variation-add-to-cart {
	flex-wrap: nowrap;
}
.xtool-wc-add-to-cart--full-width .button {
	flex: 1 1 0;
}

/* AJAX Add to Cart states - loading (request in flight), a brief "added"
   pulse on success, and a brief error tint if the request itself failed
   (a real WooCommerce error, e.g. no variation selected, redirects to the
   product page instead - this state is only for a genuine network/request
   failure). */
.xtool-wc-add-to-cart--ajax-loading .button {
	opacity: .6;
	cursor: progress;
	pointer-events: none;
}
.xtool-wc-add-to-cart .button.is-added {
	background-color: #2e7d32 !important;
	border-color: #2e7d32 !important;
	transition: background-color .2s, border-color .2s;
}
.xtool-wc-add-to-cart--ajax-error .button {
	background-color: #b3261e !important;
	border-color: #b3261e !important;
}

/* ─── Product Images: zoom trigger icon ──────────────────────────────────
   WooCommerce's own built-in "zoom" corner button (.woocommerce-product-
   gallery__trigger) shows a magnifying-glass sprite pulled from its own
   bundled image file - if the active theme doesn't fully enqueue WC's
   default styles (a common theme customization), that sprite silently
   404s, leaving a bare, oddly-placed unstyled box exactly like the one
   reported live via screenshot. Replaced with a plain dependency-free
   inline SVG data URI instead - never depends on any external file loading
   correctly, and a clean, deliberately-designed icon either way.

   Same broken-theme-styles root cause also meant `position: absolute`
   itself (normally WooCommerce's OWN default CSS, not ours) was missing
   too - reported live via a SECOND screenshot showing the icon sitting in
   plain document flow above the image instead of overlaid on its corner,
   since a bare `top`/`right` with no `position` set does nothing at all.
   Declared explicitly here rather than assumed inherited from WooCommerce's
   own (apparently unreliable, on this theme) default stylesheet. The
   containing-block ancestor is hardened the same way, for the same
   reason - an absolutely-positioned child with no genuinely positioned
   ancestor falls back to positioning against the page itself. */
.woocommerce-product-gallery,
.woocommerce-product-gallery__wrapper,
.woocommerce-product-gallery__image {
	position: relative;
}

.woocommerce-product-gallery__trigger {
	position: absolute !important;
	z-index: 2 !important;
	width: 36px !important;
	height: 36px !important;
	top: 16px !important;
	right: 16px !important;
	left: auto !important;
	bottom: auto !important;
	border-radius: 50% !important;
	background-color: rgba(255, 255, 255, 0.9) !important;
	background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24' fill='none' stroke='%231A1814' stroke-width='2' stroke-linecap='round'%3E%3Ccircle cx='11' cy='11' r='7'/%3E%3Cpath d='M21 21l-4.35-4.35'/%3E%3C/svg%3E") !important;
	background-repeat: no-repeat !important;
	background-position: center !important;
	background-size: 16px 16px !important;
	box-shadow: 0 1px 4px rgba(0, 0, 0, 0.15) !important;
	text-indent: -9999px !important;
	overflow: hidden !important;
}

/* ─── Product Images: Thumbnail baseline (ALL positions, including the
   default "Below Main Image") ─────────────────────────────────────────────
   Same root cause as the zoom-icon fix above: this theme doesn't reliably
   supply WooCommerce's own default gallery CSS, so without an explicit
   base rule here the thumbnail nav rendered as a bare, unstyled numbered
   list (each thumbnail full-width, stacked vertically with a "1. 2. 3."
   marker) instead of a compact row of images - reported live via
   screenshot. This is genuinely a gap in the earlier "Thumbnail Position"
   pass, which only ever styled the Left/Right column layouts below and
   the separate Detached-widget target, never the plain default case. */
.xtool-wc-images .flex-control-nav,
.xtool-wc-images .flex-control-thumbs {
	display: flex;
	/* nowrap + horizontal scroll (not wrap) - Thumbnail Columns is meant to
	   fit exactly N thumbnails across the row at a fixed, even size; any
	   MORE images than that scroll/swipe into view (native browser
	   scrolling, no JS needed) instead of dropping to a second row, which
	   would silently ignore the whole point of choosing a column count.
	   scroll-snap makes that swipe land cleanly on a thumbnail boundary
	   rather than stopping mid-image. */
	flex-wrap: nowrap;
	overflow-x: auto;
	-webkit-overflow-scrolling: touch;
	scroll-snap-type: x proximity;
	gap: 10px;
	margin: 16px 0 0;
	padding: 0;
	list-style: none;
}

/* Scrollbar Style: Hidden (default) - the row still scrolls/swipes exactly
   the same either way, this purely hides the browser's own scrollbar
   underneath it, reported live as looking out of place next to the rest
   of a clean product page. `scrollbar-width` (Firefox) has no vendor-
   prefixed equivalent; `::-webkit-scrollbar` (Chrome/Safari/Edge) needs
   its own separate rule since it isn't a standard property at all. */
.xtool-wc-images--scrollbar-hidden .flex-control-nav,
.xtool-wc-images--scrollbar-hidden .flex-control-thumbs {
	scrollbar-width: none;
}

.xtool-wc-images--scrollbar-hidden .flex-control-nav::-webkit-scrollbar,
.xtool-wc-images--scrollbar-hidden .flex-control-thumbs::-webkit-scrollbar {
	display: none;
	height: 0;
}

/* Disable Hover Zoom - the real teardown happens in JS (wc-product-
   gallery.js's bindDisableZoom(), calling jQuery.zoom's own documented
   `zoom.destroy` API every time WooCommerce (re)builds the gallery) so the
   effect never actually engages in the first place; this is pure defense-
   in-depth in case a `.zoomImg` overlay div still momentarily exists for
   any reason (e.g. a WooCommerce/theme version whose own gallery-init
   timing doesn't line up with our own event listener). Never touches
   `data-large_image`/`_width`/`_height` or any other data the lightbox
   also depends on - see the JS file's own comment for why an earlier,
   attribute-stripping version of this feature broke the lightbox's own
   Prev/Next navigation entirely. */
.xtool-wc-images--zoom-disabled .zoomImg {
	display: none !important;
}

/* Mouse Drag to Scroll - requested directly ("mình muốn có thể dùng chuột
   kéo slider"). The row already scrolls natively via a touch swipe
   (overflow-x:auto above); this just gives a desktop mouse the same
   ability. `user-select:none` stops the drag from also highlighting text/
   images as a selection, and `-webkit-user-drag:none` on the thumbnail
   images stops the browser's own native "drag this image" ghost from
   competing with the custom drag. `.is-dragging` turns off scroll-snap for
   the duration of the drag only - snapping to the nearest thumbnail mid-
   drag would otherwise fight the mouse's own scrollLeft writes and feel
   jittery; it re-enables the instant the drag ends. */
.xtool-wc-images--thumb-drag .flex-control-nav,
.xtool-wc-images--thumb-drag .flex-control-thumbs {
	cursor: grab;
	user-select: none;
	-webkit-user-select: none;
}

.xtool-wc-images--thumb-drag .flex-control-thumbs li img {
	-webkit-user-drag: none;
	user-drag: none;
}

.xtool-wc-images--thumb-drag .flex-control-nav.is-dragging,
.xtool-wc-images--thumb-drag .flex-control-thumbs.is-dragging {
	cursor: grabbing;
	scroll-snap-type: none;
}

/* Navigation Arrows - direct answer to "khi ở ảnh cuối bên trái mình
   không thể chọn ảnh tiếp theo được nữa phải kéo thanh trượt qua" (once at
   the edge, reaching a partly-visible thumbnail needed manually dragging
   the scroll strip). wc-product-gallery.js wraps the real thumbnail-nav
   element in `.xtool-thumb-nav-wrap` (position:relative) and appends these
   2 buttons as real siblings - each one just calls the row's own native
   scrollBy() by exactly one visible row's width, landing cleanly on a
   thumbnail boundary via the scroll-snap already set above. Nothing about
   Flexslider/the gallery's own click-to-switch-image behavior is touched. */
.xtool-thumb-nav-wrap {
	position: relative;
}

.xtool-thumb-arrow,
.xtool-thumb-arrow:hover,
.xtool-thumb-arrow:focus,
.xtool-thumb-arrow:active {
	position: absolute;
	top: 50%;
	transform: translateY(-50%);
	z-index: 2;
	width: 30px;
	height: 30px;
	border-radius: 50%;
	background: #fff !important;
	color: #1A1814 !important;
	border: 1px solid #E5E0D8 !important;
	box-shadow: 0 1px 4px rgba(0, 0, 0, 0.15) !important;
	display: flex;
	align-items: center;
	justify-content: center;
	font-size: 16px;
	line-height: 1;
	padding: 0;
	cursor: pointer;
}

.xtool-thumb-arrow--prev {
	left: -6px;
}

.xtool-thumb-arrow--next {
	right: -6px;
}

.xtool-thumb-arrow[disabled] {
	opacity: 0.35;
	cursor: default;
	pointer-events: none;
}

.xtool-wc-images .flex-control-thumbs li {
	/* Width is computed from the Thumbnail Columns control (--xtool-thumb-
	   columns) and the real Gap value (--xtool-thumb-gap, kept in sync
	   with the row's own real `gap` property by the same control) so
	   exactly N thumbnails always fit edge-to-edge across the row,
	   regardless of how many total images the product has - the fixed-
	   px-width approach tried earlier could only ever coincidentally match
	   a chosen column count, never actually enforce it. */
	width: calc((100% - (var(--xtool-thumb-columns, 4) - 1) * var(--xtool-thumb-gap, 10px)) / var(--xtool-thumb-columns, 4));
	/* aspect-ratio (not a fixed height) - the Aspect Ratio control below
	   overrides this per-instance; "Original" sets it to `auto`, which a
	   plain <li> (not a replaced element) has no natural ratio for, so it
	   correctly falls through to auto/content-based height instead - the
	   child img's own height:100% below then itself resolves to `auto`
	   too (a percentage height against an indefinite containing-block
	   height computes to auto, per spec), landing on the photo's own real
	   proportions with zero extra CSS needed for that case specifically. */
	aspect-ratio: 1 / 1;
	flex: 0 0 auto;
	overflow: hidden;
	scroll-snap-align: start;
}

.xtool-wc-images .flex-control-thumbs li img {
	display: block;
	width: 100%;
	height: 100%;
	/* object-fit:cover - the img's own natural aspect ratio (whatever the
	   real product photo happens to be) previously left gaps of the box's
	   own gray background showing around it instead of filling the box
	   edge-to-edge, reported live via screenshot as "không được hiển thị
	   full box". Cropping to fill is what every reference thumbnail-row
	   design (Bob's Red Mill, ASOS) actually does. A no-op for the
	   "Original" ratio above, where there's no smaller/different box to
	   crop into in the first place. */
	object-fit: cover;
	cursor: pointer;
	border: 2px solid transparent;
	box-sizing: border-box;
}

.xtool-wc-images .flex-control-thumbs li img.flex-active {
	border-color: #1C1C1E;
}

/* ─── Product Images: Thumbnail Position ─────────────────────────────────
   Pure CSS reflow of WooCommerce's own real gallery markup - no DOM
   restructuring, same "wrap, never reimplement" principle already used for
   the WC Cart/Checkout Split layout elsewhere in this codebase. Both
   .flex-control-nav and .flex-control-thumbs are targeted together since
   WooCommerce's own Flexslider init applies both classes to the same
   generated thumbnail-nav element. */
.xtool-wc-images--thumbs-left .woocommerce-product-gallery,
.xtool-wc-images--thumbs-right .woocommerce-product-gallery {
	display: flex;
	align-items: flex-start;
	gap: 12px;
}

.xtool-wc-images--thumbs-left .woocommerce-product-gallery {
	flex-direction: row-reverse;
}

.xtool-wc-images--thumbs-right .woocommerce-product-gallery {
	flex-direction: row;
}

.xtool-wc-images--thumbs-left .woocommerce-product-gallery__wrapper,
.xtool-wc-images--thumbs-right .woocommerce-product-gallery__wrapper {
	flex: 1 1 0;
	min-width: 0;
}

.xtool-wc-images--thumbs-left .flex-control-nav,
.xtool-wc-images--thumbs-left .flex-control-thumbs,
.xtool-wc-images--thumbs-right .flex-control-nav,
.xtool-wc-images--thumbs-right .flex-control-thumbs {
	flex: 0 0 auto;
	display: flex !important;
	flex-direction: column;
	flex-wrap: nowrap;
	width: auto;
	margin: 0;
	padding: 0;
	list-style: none;
}

/* Stack Below on Tablet/Mobile - a side-by-side thumbnail column rarely
   fits a narrow screen well, so this reverts to the same plain stacked
   layout the "Below Main Image" choice already uses, regardless of the
   Left/Right choice above. */
@media (max-width: 767px) {
	.xtool-wc-images--thumbs-stack-mobile.xtool-wc-images--thumbs-left .woocommerce-product-gallery,
	.xtool-wc-images--thumbs-stack-mobile.xtool-wc-images--thumbs-right .woocommerce-product-gallery {
		flex-direction: column;
	}

	.xtool-wc-images--thumbs-stack-mobile .flex-control-nav,
	.xtool-wc-images--thumbs-stack-mobile .flex-control-thumbs {
		flex-direction: row !important;
		flex-wrap: wrap;
		width: 100% !important;
	}
}

/* Detach Thumbnails - hides the thumbnail row only in ITS ORIGINAL
   location; wc-product-gallery.js moves the real DOM node elsewhere on the
   page, so this rule naturally stops applying to it the moment it's no
   longer a descendant of this wrapper (CSS re-evaluates on current DOM
   position, not where an element used to be). */
.xtool-wc-images--thumbs-detached .flex-control-nav,
.xtool-wc-images--thumbs-detached .flex-control-thumbs {
	display: none !important;
}

/* ─── Product Gallery Thumbnails (detached, separate widget) ───────────── */
.xtool-wc-gallery-thumbs-target .flex-control-nav,
.xtool-wc-gallery-thumbs-target .flex-control-thumbs {
	display: flex;
	flex-wrap: wrap;
	gap: 10px;
	margin: 0;
	padding: 0;
	list-style: none;
}

.xtool-wc-gallery-thumbs-target .flex-control-thumbs li {
	width: 72px;
	aspect-ratio: 1 / 1;
	overflow: hidden;
}

.xtool-wc-gallery-thumbs-target .flex-control-thumbs li img {
	display: block;
	width: 100%;
	height: 100%;
	object-fit: cover;
	cursor: pointer;
	border: 2px solid transparent;
	box-sizing: border-box;
}

.xtool-wc-gallery-thumbs-target .flex-control-thumbs li img.flex-active {
	border-color: #1C1C1E;
}

.xtool-wc-gallery-thumbs-target__empty {
	font-size: 12px;
	color: #8A8680;
}