/**
 * Every template's <main> is a plain "Group" block with no explicit layout,
 * so WordPress's global block-gap spacing gives it a margin-top by default
 * (the same spacing it'd insert between two ordinary stacked blocks) even
 * though its actual previous sibling is the site header, not page content.
 * That shows up as a visible, unintentional-looking gap of bare page
 * background between the header and wherever the template's own content
 * starts. Every template wants the header to sit flush against its
 * content, so this is a global fix rather than a per-template one.
 */
main.wp-block-group {
	margin-top: 0;
}

/**
 * Global button micro-interaction: theme.json already swaps the button's
 * background color on :hover (styles.elements.button), but with no
 * transition and no motion it just snaps, which reads as inert rather than
 * responsive. A lift + shadow + eased color swap makes every button on the
 * site (not just this one landing page) feel like it's actually reacting
 * to the pointer.
 */
.wp-element-button {
	transition: transform 0.2s ease, box-shadow 0.2s ease, background-color 0.2s ease, opacity 0.2s ease;
}

.wp-element-button:hover {
	transform: translateY(-2px);
	box-shadow: var(--wp--preset--shadow--medium, 0 6px 16px rgba(0, 0, 0, 0.15));
}

.wp-element-button:active {
	transform: translateY(0);
	box-shadow: none;
}

/**
 * Global horizontal-scrollbar safety net.
 *
 * The landing page patterns' "full width" sections bleed edge-to-edge using
 * a `width: 100vw; margin-left: calc(50% - 50vw)` trick (see .omega-landing
 * > .alignfull in landing-pages.css) - the only technique that actually
 * escapes their wrapping constrained group. `vw` units are defined against
 * the browser's OUTER viewport (the one a vertical scrollbar carves into),
 * while `%` and a page's actual content box are measured against the
 * INNER, scrollbar-excluded width. Whenever the page is tall enough to show
 * a normal (non-overlay) scrollbar - the common case on Windows/Linux
 * desktop browsers - `100vw` ends up a scrollbar's-width (~15-17px) wider
 * than the page can actually show, so every full-bleed section overshoots
 * the right edge by that amount and the page gains its own tiny but real
 * horizontal scrollbar. Clipping it here is the standard fix: it only ever
 * trims that harmless few-pixel overshoot and never affects vertical
 * scrolling or any intentional full-bleed visual.
 *
 * clip, not hidden: per the CSS Overflow spec, an element with overflow-x
 * set to anything other than visible while overflow-y is visible computes
 * overflow-y as auto instead - and that promotion happens even when
 * overflow-y: visible is written out explicitly, so there's no combination
 * of hidden/visible that avoids it. With overflow-y silently forced to
 * auto on both html AND body, each became its own independently scrollable
 * box - two real, separate scrollbars stacked at the page edge instead of
 * the usual single one. overflow: clip is exempt from that promotion
 * rule entirely (it never creates a scroll container to begin with), so
 * pairing it with an untouched overflow-y is what actually gets back to
 * plain single-scrollbar document scrolling.
 */
html,
body {
	overflow-x: clip;
}

/**
 * Page-level content width override.
 *
 * Set via the "Page Width" control in the editor sidebar (Page > Summary).
 * Overrides the content-size custom property that the constrained layout
 * support reads to center each direct child of the post content area, so
 * changing it widens every child at once instead of requiring a per-block
 * alignment change.
 */
.wp-block-post-content.has-omega-content-width-wide {
	--wp--style--global--content-size: var(--wp--style--global--wide-size);
}

.wp-block-post-content.has-omega-content-width-full {
	--wp--style--global--content-size: 100%;
}

/**
 * Shop archive product cards (templates/archive-product.html).
 *
 * The grid itself (columns, responsiveness) is handled entirely by
 * WooCommerce's own wc-block-product-template CSS via the "columns"
 * attribute on the woocommerce/product-collection block - no custom
 * grid/flex rules needed here. This only styles the visual card wrapped
 * around each product's image/title/price/button.
 *
 * That block combination (product-collection + product-template) is also
 * required, not optional: WooCommerce's Add to Cart button only receives
 * its product ID via the data-wp-context that woocommerce/product-template
 * puts on each item's <li>. An earlier version of this template used the
 * generic core/query + core/post-template instead, which looked identical
 * but never set that context - so the button rendered and looked clickable,
 * but silently did nothing on click, since it had no product ID to act on.
 */
.omega-product-card {
	height: 100%;
	transition: transform 0.2s ease, box-shadow 0.2s ease;
}

.omega-product-card:hover,
.omega-product-card:focus-within {
	transform: translateY(-4px);
	box-shadow: var(--wp--preset--shadow--medium);
}

.omega-product-card .wc-block-components-product-image img,
li.wc-block-product .wc-block-components-product-image img {
	transition: transform 0.3s ease;
}

.omega-product-card:hover .wc-block-components-product-image img,
li.wc-block-product:hover .wc-block-components-product-image img {
	transform: scale(1.04);
}

.omega-product-card .wc-block-components-product-image,
li.wc-block-product .wc-block-components-product-image {
	overflow: hidden;
}

/*
 * The theme's global button padding (theme.json's styles.elements.button,
 * 0.75rem top/bottom) is sized for a standalone CTA - inside this compact
 * card it reads as oversized next to the image/title/price above it.
 * Scoped to the card so every other button on the site (hero CTAs, footer
 * "Contact us", newsletter signup, ...) keeps the normal global size.
 */
.omega-product-card .wc-block-components-product-button__button,
li.wc-block-product .wc-block-components-product-button__button {
	padding-top: 0.45rem;
	padding-bottom: 0.45rem;
}

/**
 * Card background for WooCommerce's own Product Template output wherever
 * it ISN'T already wrapped in the theme's .omega-product-card group (e.g.
 * the "Trending Products" tabs on the landing pages, built in
 * includes/patterns/pattern-helpers.php).
 *
 * This deliberately styles WooCommerce's own native per-product <li> via
 * plain CSS rather than adding a wrapping block around product-template's
 * children: nesting an extra block there breaks the Product Collection
 * block's own server-side rendering (it silently double-renders every
 * product instead of once) - a real WooCommerce Blocks limitation, not a
 * theme bug, confirmed by reverting that approach after it duplicated the
 * whole Trending Products grid. Pure CSS on the existing element carries
 * none of that risk.
 *
 * :not(:has(.omega-product-card)) excludes the Shop archive's own cards
 * (templates/archive-product.html), which already wrap their content in a
 * .omega-product-card group with this exact same background/padding/radius
 * - without this guard, that page would get the same treatment twice
 * (once from its own group, once from this <li>), doubling the padding and
 * nesting one rounded card inside another.
 */
li.wc-block-product:not(:has(.omega-product-card)) {
	background: var(--wp--preset--color--surface);
	border-radius: 12px;
	box-shadow: var(--wp--preset--shadow--soft);
	padding: var(--wp--preset--spacing--s) var(--wp--preset--spacing--s) var(--wp--preset--spacing--m);
	overflow: hidden;
	transition: transform 0.2s ease, box-shadow 0.2s ease;
}

li.wc-block-product:not(:has(.omega-product-card)):hover,
li.wc-block-product:not(:has(.omega-product-card)):focus-within {
	transform: translateY(-4px);
	box-shadow: var(--wp--preset--shadow--medium);
}

/**
 * The product image (WooCommerce's own woocommerce/product-image block)
 * leaves its <img> as an ordinary inline element sized by its own
 * intrinsic aspect ratio, rather than filling the box drawn around it -
 * on a non-square source photo that meant the image rendered narrower
 * than its own card (visible whitespace either side) and, combined with
 * object-fit:cover on a mismatched box, at least one product effectively
 * disappeared. Forcing the image itself to fill the container (block,
 * 100%/100%, cover) makes every photo actually act as a fill container
 * regardless of its native size/aspect ratio. A shorter fixed height here
 * (down from the ~310-480px this was rendering at) is also most of what
 * was making the whole card feel oversized.
 */
.omega-product-card .wc-block-components-product-image,
li.wc-block-product .wc-block-components-product-image {
	height: 200px;
}

/*
 * The <a> WooCommerce wraps the image in is an inline element by default,
 * which sizes to its own content (the image) instead of stretching to
 * fill this box - leaving the image nothing real to resolve its own
 * width:100%/height:100% against, so it fell back to a small intrinsic
 * size instead. Making the link a block-level fill container breaks that
 * circular reference.
 */
.omega-product-card .wc-block-components-product-image > a,
li.wc-block-product .wc-block-components-product-image > a {
	display: block;
	width: 100%;
	height: 100%;
}

.omega-product-card .wc-block-components-product-image img,
li.wc-block-product .wc-block-components-product-image img {
	/*
	 * !important is required here: WooCommerce's product-image block
	 * writes aspect-ratio directly onto the <img> tag's own style
	 * attribute (style="object-fit:cover;aspect-ratio:3/4;"), and an
	 * inline style beats any external stylesheet rule regardless of
	 * selector specificity. Without overriding it explicitly, the image
	 * keeps sizing itself from its own 3:4 aspect ratio instead of
	 * filling this fixed-height box, which is what let the box and the
	 * image visibly disagree in size (one product's photo effectively
	 * vanished because of it).
	 */
	display: block !important;
	width: 100% !important;
	height: 100% !important;
	aspect-ratio: auto !important;
	/*
	 * contain, not cover: cover fills the box completely but crops
	 * whichever edge doesn't match the box's proportions - fine for a
	 * uniform photoshoot, but this catalog's product photos vary widely
	 * in shape (a perfume bottle vs. a full pair of jeans), so cropping
	 * was cutting real product content off. contain always shows the
	 * whole photo, letterboxed on the card's own background instead.
	 */
	object-fit: contain !important;
}

/**
 * Hover Colors (Row/Stack/Grid, Columns, Column blocks).
 *
 * Set via the "Hover Colors" panel in the block Inspector (Styles tab, see
 * assets/js/editor.js). Each color is written inline as a CSS custom
 * property on the block that set it; whichever of the three is left unset
 * falls back to the theme-wide default in theme.json (settings.custom.hover).
 */
.has-omega-hover-color {
	transition: color 0.2s ease, background-color 0.2s ease, border-color 0.2s ease, box-shadow 0.2s ease;
}

.has-omega-hover-color:hover {
	color: var(--omega-hover-text-color, var(--wp--custom--hover--text-color));
	background-color: var(--omega-hover-bg-color, var(--wp--custom--hover--background-color));
	border-color: var(--omega-hover-border-color, var(--wp--custom--hover--border-color));
	box-shadow: var(--omega-hover-shadow, var(--wp--custom--hover--shadow));
}

/**
 * Block Link (Row/Stack/Grid, Columns, Column blocks).
 *
 * Set via the "Link" panel in the block Inspector (see assets/js/editor.js).
 * The URL is rendered as a full-cover overlay <a> - see hooks.php,
 * add_block_link_overlay() - so the whole block is one click target without
 * wrapping its own markup (which may already contain a link or button) in
 * an outer <a>, which would be invalid nested-<a> HTML.
 */
.omega-has-block-link {
	position: relative;
}

.omega-has-block-link > .omega-block-link {
	position: absolute;
	inset: 0;
	z-index: 1;
}

.omega-has-block-link > .omega-block-link:focus-visible {
	outline: 2px solid var(--wp--preset--color--primary, #0d6efd);
	outline-offset: 2px;
}

/* Anything inside that needs its own click target stays reachable above the overlay. */
.omega-has-block-link a:not(.omega-block-link),
.omega-has-block-link button {
	position: relative;
	z-index: 2;
}

/* Editor canvas only - the overlay above is a front-end-only render_block transform. */
.editor-styles-wrapper .is-omega-linked-block {
	outline: 1px dashed var(--wp--preset--color--primary, #0d6efd);
	outline-offset: 2px;
}

/**
 * Text Style toolbar popover (Paragraph, Heading, List, Quote, etc. blocks).
 *
 * Content of the "Text Style" toolbar button's popover - see
 * assets/js/editor.js. Renders in wp-admin's own document (a Popover, not
 * the editor iframe canvas), so this only needs to reach that context, not
 * .editor-styles-wrapper.
 */
.omega-toolbar-popover {
	display: flex;
	flex-direction: column;
	gap: 16px;
	padding: 16px;
	min-width: 260px;
	/*
	 * The Text Style popover has grown to 11 fields (Bold/Italic through
	 * Padding/Margin) - tall enough on a short browser window to run past
	 * the bottom of the viewport. WordPress's Popover component repositions
	 * itself to stay on screen but doesn't cap an oversized content div's
	 * own height, so without this the last few fields (Box Width, Padding,
	 * Margin) could render past the visible viewport edge with no
	 * scrollbar - silently inaccessible rather than visibly cut off.
	 */
	max-height: min(70vh, 560px);
	overflow-y: auto;
}

.omega-toolbar-popover__row {
	display: flex;
	gap: 8px;
}

/**
 * Site header (parts/header.html).
 */
.site-header .site-navigation a {
	transition: color 0.15s ease, opacity 0.15s ease;
}

.site-header .site-navigation a:hover {
	opacity: 0.8;
}

/* Bigger, easier to tap hamburger toggle, with a hover/focus affordance. */
.site-header .wp-block-navigation__responsive-container-open,
.site-header .wp-block-navigation__responsive-container-close {
	padding: 10px;
	border-radius: 6px;
	transition: background-color 0.15s ease;
}

.site-header .wp-block-navigation__responsive-container-open:hover,
.site-header .wp-block-navigation__responsive-container-open:focus,
.site-header .wp-block-navigation__responsive-container-close:hover,
.site-header .wp-block-navigation__responsive-container-close:focus {
	background-color: rgba(255, 255, 255, 0.12);
}

/* Mobile menu overlay: roomier, centered links that are easy to scan/tap. */
.site-header .wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__responsive-container-content {
	display: flex;
	align-items: center;
}

.site-header .wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation-item {
	width: 100%;
	text-align: center;
}

.site-header .wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation-item__content {
	font-size: 1.25rem;
	padding: 0.75em 0;
}

.site-header .wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation-item__content:hover {
	color: var(--wp--preset--color--primary);
}

/**
 * Site footer (parts/footer.html).
 */
.footer-link-list {
	list-style: none;
	margin: 0;
	padding: 0;
}

.footer-link-list li {
	margin: 0 0 0.6em;
}

.footer-link-list a,
.footer-link-list a:visited {
	color: var(--wp--preset--color--button-text);
	text-decoration: none;
	opacity: 0.85;
	transition: color 0.15s ease, opacity 0.15s ease;
}

.footer-link-list a:hover,
.footer-link-list a:focus {
	color: var(--wp--preset--color--primary);
	opacity: 1;
	text-decoration: underline;
}

.footer-social a {
	transition: opacity 0.15s ease, transform 0.15s ease;
}

.footer-social a:hover {
	opacity: 0.8;
	transform: translateY(-2px);
}

.site-footer__bottom-bar {
	border-top: 1px solid rgba(255, 255, 255, 0.15);
}

.site-footer__bottom-bar p {
	margin: 0;
	opacity: 0.75;
}

/**
 * Checkout "please log in" notice (woocommerce/checkout/form-checkout.php).
 * Shown instead of WooCommerce's plain-text message when guest checkout and
 * new-account registration are both disabled, so a guest has no other way
 * to complete their order.
 */
.omega-checkout-auth-notice {
	box-sizing: border-box;
	max-width: 30rem;
	margin: 3rem auto;
	padding: 2.75rem 2.25rem;
	text-align: center;
	background: var(--wp--preset--color--surface);
	border: 1px solid rgba(255, 255, 255, 0.1);
	border-radius: 14px;
	box-shadow: 0 24px 48px -24px rgba(0, 0, 0, 0.4);
	animation: omega-checkout-auth-notice-in 0.35s ease both;
}

@keyframes omega-checkout-auth-notice-in {
	from {
		opacity: 0;
		transform: translateY(8px);
	}
	to {
		opacity: 1;
		transform: translateY(0);
	}
}

.omega-checkout-auth-notice__icon {
	display: inline-flex;
	align-items: center;
	justify-content: center;
	width: 60px;
	height: 60px;
	margin: 0 auto 1.25rem;
	border-radius: 50%;
	background: var(--wp--preset--color--background);
	color: var(--wp--preset--color--primary);
	box-shadow: 0 0 0 6px color-mix(in srgb, var(--wp--preset--color--primary) 14%, transparent);
}

.omega-checkout-auth-notice .omega-checkout-auth-notice__title {
	margin: 0 0 0.625rem;
	font-size: var(--wp--preset--font-size--large);
	font-weight: 600;
	line-height: 1.3;
	color: var(--wp--preset--color--heading) !important;
}

.omega-checkout-auth-notice .omega-checkout-auth-notice__message {
	max-width: 25rem;
	margin: 0 auto 2rem;
	color: var(--wp--preset--color--body-text) !important;
	opacity: 0.85;
	line-height: 1.6;
}

.omega-checkout-auth-notice__actions {
	display: flex;
	flex-wrap: wrap;
	justify-content: center;
	gap: 0.75rem;
}

.omega-checkout-auth-notice__button {
	box-sizing: border-box;
	display: inline-block;
	text-decoration: none;
	font-weight: 500;
	cursor: pointer;
	transition: transform 0.15s ease, background-color 0.15s ease, color 0.15s ease;
}

.omega-checkout-auth-notice__button:hover,
.omega-checkout-auth-notice__button:focus-visible {
	transform: translateY(-1px);
}

.omega-checkout-auth-notice__button--secondary {
	padding: 0.75rem 1.5rem;
	border-radius: 6px;
	border: 1px solid var(--wp--preset--color--primary);
	color: var(--wp--preset--color--primary);
	background: transparent;
}

.omega-checkout-auth-notice__button--secondary:hover,
.omega-checkout-auth-notice__button--secondary:focus-visible {
	background: var(--wp--preset--color--primary);
	color: var(--wp--preset--color--button-text);
}

@media (max-width: 400px) {
	.omega-checkout-auth-notice {
		padding: 2.25rem 1.5rem;
	}

	.omega-checkout-auth-notice__actions {
		flex-direction: column;
	}

	.omega-checkout-auth-notice__button {
		width: 100%;
	}
}

/**
 * Blog sidebar layout (see includes/customizer/sidebar.php).
 *
 * Every template that can show the sidebar (category.html, archive.html,
 * search.html, index.html, home.html, single.html, page.html) uses the same
 * two-column markup with these two className hooks. Which side the sidebar
 * sits on and whether it shows at all is NOT baked into the static template
 * markup - it is resolved per-request in PHP (sidebar.php's
 * should_show_sidebar() / get_sidebar_position()) and expressed here purely
 * via body classes and a CSS custom property, so one theme_mod change (or a
 * per-page override from the editor's Page Settings panel) affects every
 * template at once without editing template files.
 */
/**
 * Float-based layout, deliberately NOT flexbox: flexbox keeps both columns
 * the same fixed height/width for the sidebar's entire run, with no way
 * for main to reclaim full width once the sidebar's own (usually shorter)
 * content ends - a float is the only CSS mechanism that does that, since a
 * float only occupies horizontal space for the vertical range its own
 * content actually needs; normal-flow content beside it narrows only
 * where the float is still present, and reclaims full width the moment it
 * scrolls past the float's bottom edge.
 *
 * The real trade-off: that per-line reflow only works reliably for plain
 * inline content (paragraphs, headings, inline images) - a "box" block
 * with its own background color, border, or explicit width (a WooCommerce
 * product grid, a colored Group section, an alignwide/alignfull landing
 * page section) renders as one rectangle at its own declared width
 * regardless of the float, so it can visually intrude under/behind the
 * floated sidebar wherever the two geometrically overlap. Text inside
 * still avoids the overlap; the box's own background/border doesn't. This
 * is a real limitation of float-based layout everywhere it's used, not
 * something this theme can fully paper over in CSS - pages that are nothing
 * but plain paragraphs (a typical blog post) get a clean result; pages
 * built from boxed/colored sections (this theme's landing patterns,
 * WooCommerce archive grids) may show the sidebar visually cutting into
 * those sections where they overlap it.
 *
 * WordPress auto-generates a per-instance flex layout stylesheet for any
 * "flex" layout `wp:columns` block that doesn't declare fixed per-column
 * widths (a ".wp-container-core-columns-is-layout-<hash>{flex-wrap:nowrap}"
 * rule scoped to this exact block) - `display:block` here overrides that
 * back to normal flow so the float rules below actually apply; the
 * !important matches that generated rule's own specificity + load-order
 * advantage, the same reasoning documented in background_color.php for
 * the equivalent theme.json-generated-rule problem.
 */
.omega-sidebar-layout {
	display: block !important;
}

.wp-block-column.omega-sidebar-layout__aside {
	float: right;
	width: var(--omega-sidebar-width, 30%) !important;
	margin-left: var(--wp--preset--spacing--l, 2rem);
}

.wp-block-column.omega-sidebar-layout__main {
	width: 100% !important;
}

body.omega-sidebar-pos-left .wp-block-column.omega-sidebar-layout__aside {
	float: left;
	margin-left: 0;
	margin-right: var(--wp--preset--spacing--l, 2rem);
}

/*
 * Without this, a page whose main content is SHORTER than the floated
 * sidebar would let whatever comes next (the footer) rise up into the
 * still-floated sidebar's remaining height, since floats don't contribute
 * to their normal-flow parent's own height. This forces
 * .omega-sidebar-layout's own bottom edge to always include the taller of
 * the two columns, the same guarantee flexbox gave for free before.
 */
.omega-sidebar-layout::after {
	content: "";
	display: table;
	clear: both;
}

/**
 * Neutralizes the landing patterns' viewport-relative "Full Width" bleed
 * (.omega-landing > .alignfull in landing-pages.css: width:100vw;
 * margin-left:calc(50% - 50vw)) whenever a page combines a landing pattern
 * with the sidebar. That 100vw math only produces the correct result when
 * .omega-landing sits centered across the FULL browser window with equal
 * margins either side - the whole reason it can "reach the true viewport
 * edge" at all. Once the sidebar shrinks main to ~70% width and pushes it
 * to one side, the same math instead overflows straight through the
 * sidebar column, overlapping or hiding its content depending on z-order.
 * There's no way to keep a genuine full-bleed section AND a sidebar
 * occupying screen space at the same time - this sacrifices the bleed on
 * exactly the pages where both are present, falling back to simply
 * filling the main column's own available width, same as a normal block.
 * Scoped to .omega-sidebar-layout__main specifically so every other page
 * using these same landing patterns without a sidebar keeps the real
 * full-bleed effect untouched.
 */
body.omega-sidebar-visible .omega-sidebar-layout__main .omega-landing > .alignfull {
	width: 100% !important;
	max-width: 100% !important;
	margin-left: 0 !important;
	margin-right: 0 !important;
}

body.omega-sidebar-hidden .wp-block-column.omega-sidebar-layout__aside {
	display: none !important;
	float: none !important;
}

body.omega-sidebar-hidden .wp-block-column.omega-sidebar-layout__main {
	width: 100% !important;
}

.omega-sidebar-layout__aside .widget + .widget {
	margin-top: 2rem;
}

.omega-sidebar-layout__aside .widget-title {
	margin-top: 0;
}

/**
 * Hide the sidebar entirely on mobile, regardless of position/width - a
 * narrow phone screen has no room for a floated sidebar sitting beside
 * main content at all. 599px matches the theme's other mobile breakpoint
 * (includes/core/responsive_styles.php's BREAKPOINTS['mobile']), so this
 * switches over at the same point as every other responsive rule on the
 * site.
 */
@media (max-width: 599px) {
	.wp-block-column.omega-sidebar-layout__aside {
		display: none !important;
		float: none !important;
	}

	.wp-block-column.omega-sidebar-layout__main {
		width: 100% !important;
	}
}

/**
 * Group "Content Position" (Custom Size panel, assets/js/editor.js) -
 * vertically positions a plain Group's content within the Height it's been
 * given. Flex column rather than flow, so the children need an explicit
 * width: a flex item with auto side margins (every child of a constrained
 * layout) would otherwise shrink to its content instead of filling the row.
 */
.omega-valign-center,
.omega-valign-bottom {
	display: flex;
	flex-direction: column;
}
.omega-valign-center { justify-content: center; }
.omega-valign-bottom { justify-content: flex-end; }
.omega-valign-center > *,
.omega-valign-bottom > * {
	width: 100%;
	box-sizing: border-box;
	flex-shrink: 0;
}

/**
 * Columns with a Height and "Align middle/bottom": once the columns wrap
 * (stacked on mobile), the default align-content:stretch splits the height
 * between each stacked row, spreading the columns apart instead of keeping
 * them together at the chosen position.
 */
.wp-block-columns.are-vertically-aligned-center { align-content: center; }
.wp-block-columns.are-vertically-aligned-bottom { align-content: flex-end; }

/**
 * "Fixed background" (core's background-image panel - Group, and Column/
 * Columns via includes/core/blocks.php add_background_support()). Touch
 * browsers either ignore background-attachment:fixed (iOS) or size the
 * image against the whole viewport and blow it up (Android), so they get a
 * normal scrolling background instead.
 */
@media (hover: none) {
	[style*="background-attachment:fixed"] {
		background-attachment: scroll !important;
	}
}