.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;
}

/* WooCommerce's own core add-to-cart.js appends a "View cart" link right
   after whatever button triggered its own `added_to_cart` event - this
   widget's own `.is-added` checkmark pulse on the button already gives the
   same "it worked" feedback, so the extra text link is redundant and
   visually out of place next to a full-width pill button (matches the same
   already-established fix on Quick Add to Cart / Products Grid). */
.xtool-wc-add-to-cart .added_to_cart {
	/* !important is required here - WooCommerce's own core stylesheet ships
	   `.woocommerce a.added_to_cart { display: inline-block; }`, which beats
	   a plain 2-class selector like this one on specificity alone (2 classes
	   + 1 element type vs. 2 classes), regardless of stylesheet load order.
	   Confirmed live via a computed-style check before adding this. */
	display: none !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;
	/* Explicitly claims horizontal panning for this element - without this,
	   `touch-action` defaults to `auto`, which SHOULD already permit a
	   horizontal swipe here, but leaves the browser free to instead hand a
	   touch-drag starting on this row to a competing ancestor gesture (a
	   theme's own swipeable header/carousel wrapping the gallery, or iOS
	   Safari's own edge-swipe-to-go-back recognizer) if it judges the touch
	   ambiguous. Declaring `pan-x` removes that ambiguity outright: this row
	   owns horizontal drags on itself, unconditionally, while still letting
	   a mostly-vertical touch pass through untouched for normal page scroll. */
	touch-action: pan-x;
	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.

   align-items:stretch (not the original flex-start) is what keeps the
   thumbnail column's own height matched to the main image's real rendered
   height, with zero JS/measurement needed - the column becomes exactly as
   tall as its tallest flex sibling (the main image wrapper), and any
   thumbnails that don't fit in that height simply scroll within it (see
   overflow-y below), instead of the column growing past the image and
   running far down the page. */
.xtool-wc-images--thumbs-left .woocommerce-product-gallery,
.xtool-wc-images--thumbs-right .woocommerce-product-gallery {
	display: flex;
	align-items: stretch;
	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;
}

/* Real bug fix (previously reported live as tiny, broken-looking thumbnails
   extending far down the page): the base thumbnail-row rule above this
   section is built exclusively for the horizontal "Below Main Image" row -
   overflow-x/touch-action:pan-x/scroll-snap-type:x, plus each <li>'s own
   `width: calc(100% of parent / columns)` formula further below, all assume
   a wide, definite-width row. Combined with a column container that was
   left at `width:auto` (shrink-to-fit), a percentage-of-parent <li> width
   inside a shrink-to-fit parent is a circular sizing dependency that
   collapsed every thumbnail down to near-zero size - a classic CSS
   degenerate case, not a rendering glitch. Fixed by giving the column a
   real, definite width (not auto) so nothing here is circular anymore, and
   swapping every horizontal-only property for its vertical equivalent. */
.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;
	/* --xtool-thumb-vert-size (Thumbnail Size control) and, once set,
	   an explicit height from the Visible Thumbnails control both come
	   from Elementor's own per-post generated CSS - these are the plain
	   static-file fallbacks in case that hasn't regenerated yet. */
	width: var(--xtool-thumb-vert-size, 80px);
	overflow-x: hidden;
	overflow-y: auto;
	-webkit-overflow-scrolling: touch;
	touch-action: pan-y;
	scroll-snap-type: y proximity;
	margin: 0;
	padding: 0;
	list-style: none;
}

/* The base <li> width formula (a row's-worth-of-columns calc()) makes no
   sense for a single vertical column - each thumbnail should simply fill
   the column's own fixed width. Same specificity as the base rule
   (.xtool-wc-images .flex-control-thumbs li - 2 classes + 1 element), so
   this wins purely by being declared later in the file, matching the
   convention already used by main_image_gap's own --thumbs-bottom scoping
   above. Restored back to the original row-based formula inside the
   Stack-Below-on-Mobile media query further down, since that mode reflows
   the thumbnails back into a horizontal row. */
.xtool-wc-images--thumbs-left .flex-control-thumbs li,
.xtool-wc-images--thumbs-right .flex-control-thumbs li {
	width: 100%;
}

/* 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.

   Real bug fixed 2026-09-10, reported live as "mobile gallery can't be
   swiped horizontally" - this block's own `flex-wrap: wrap` (rather than
   `nowrap`, which the "Below Main Image" position's own base row rule
   already correctly uses) meant thumbnails simply dropped to a SECOND
   ROW once more than `--xtool-thumb-columns` of them existed, instead of
   overflowing past the row's own edge - with nothing ever exceeding the
   row's own width, there was never anything for overflow-x/touch-action/
   scroll-snap below to actually scroll, matching the reported symptom
   exactly (no swipe possible because there was nothing to swipe to).
   Switched to `nowrap` to match the already-proven "Below Main Image"
   row exactly - the same `--xtool-thumb-columns`-driven li width formula
   below this now correctly means "how many are visible at once before
   needing to scroll", not "how many fit per wrapped row". */
@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: nowrap;
		width: 100% !important;
		overflow-y: visible !important;
		overflow-x: auto;
		touch-action: pan-x;
		scroll-snap-type: x proximity;
	}

	/* Restores the original row-based width formula once stacked back into
	   a horizontal row - the fixed 100% (single-column) width above this
	   media query is only correct for the vertical column layout. `height`/
	   `aspect-ratio` are ALSO forced back here (both !important) - without
	   this, the Left/Right-only "Visible Thumbnails" control's own percent-
	   of-column-height formula (see that control's own comment) would keep
	   applying on mobile too (Elementor's own responsive-control cascade
	   carries a desktop value down to narrower breakpoints unless a
	   tablet/mobile override says otherwise), sizing each thumbnail against
	   the row's own auto/indeterminate height instead of a real column
	   height - a nonsensical mix that could collapse thumbnails to near-
	   zero height on mobile. */
	.xtool-wc-images--thumbs-stack-mobile .flex-control-thumbs li {
		width: calc((100% - (var(--xtool-thumb-columns, 4) - 1) * var(--xtool-thumb-gap, 10px)) / var(--xtool-thumb-columns, 4)) !important;
		height: auto !important;
		aspect-ratio: 1 / 1 !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;
}