/**
 * Global base styles
 * ------------------
 * Restores the foundation the previous parent theme used to provide and the
 * current boltpress parent no longer does: global body/heading typography and
 * a content container for generic pages rendered by the parent templates
 * (page.php / single.php / archive.php / index.php), e.g. /apie-mus/.
 *
 * Without this, inherited text falls back to the browser serif default and
 * generic-page content (`main.site-main`) runs edge-to-edge with no width
 * constraint. Pages with their own layout (home, contact, search, WooCommerce)
 * are excluded so this never double-wraps them.
 *
 * Uses the legacy token names (resolved by token-compat.css) with hardcoded
 * fallbacks matching the design tokens, so it also holds up if the design
 * system is disabled. Loads after token-compat.css but before component CSS so
 * components keep overriding it.
 */

/* ---- Global base typography ---------------------------------------
 * A FAITHFUL restore of what boltpress 1.0.0's generator emitted for this site
 * (see the compiled design-tokens.css). Declaration-for-declaration, no additions:
 * the whole point is that swapping the parent is a pixel no-op.
 *
 * In particular there is NO line-height here. 1.0.0 emitted line-height NOWHERE
 * (zero occurrences in its compiled output), so a `body { line-height: 1.5 }` would
 * be inherited by every element that doesn't set its own — WooCommerce cart /
 * my-account / notices, widget and comment text — and reflow them ~15% taller. That
 * is a redesign, not a bridge. Prose line-height is set on .entry-content below,
 * where it is scoped and intentional.
 */
body {
	font-family: var(--font-family-body, "DM Sans", sans-serif);
	font-size: var(--font-size-base, 16px);
	font-weight: var(--font-weight-normal, 400);
	color: var(--color-text, #777e90);
	background-color: var(--color-background, #ffffff);
}

/* Heading scale, per level, matching 1.0.0 exactly. The colour comes from the
 * PER-LEVEL --color-headings-h1..h6 tokens (not --color-headings-general): all six
 * are #252a36 today, so it renders identically, but using the general token would
 * silently swallow any future per-level colour edit made in the admin.
 *
 * The load-bearing surfaces are the WooCommerce-default <h3> inside
 * .woocommerce-billing-fields (form-checkout.php calls
 * do_action('woocommerce_checkout_billing') and we ship no form-billing.php) and
 * editor-authored h4/h5/h6 inside .entry-content — without a size they fall to UA
 * defaults (h3 20px -> 18.72px, h4 18px -> 16px).
 *
 * No margin-bottom and no .h1-.h6 class variants: 1.0.0 emitted the former only from
 * a spacing.md token this site does not have, and the latter have zero usage here. */
h1, h2, h3, h4, h5, h6 {
	font-family: var(--font-family-heading, "DM Sans", sans-serif);
	font-weight: var(--font-weight-bold, 700);
}
h1 { font-size: var(--font-size-3xl, 30px);  color: var(--color-headings-h1, #252a36); }
h2 { font-size: var(--font-size-2xl, 24px);  color: var(--color-headings-h2, #252a36); }
h3 { font-size: var(--font-size-xl, 20px);   color: var(--color-headings-h3, #252a36); }
h4 { font-size: var(--font-size-lg, 18px);   color: var(--color-headings-h4, #252a36); }
h5 { font-size: var(--font-size-base, 16px); color: var(--color-headings-h5, #252a36); }
h6 { font-size: var(--font-size-sm, 14px);   color: var(--color-headings-h6, #252a36); }

/* LOAD-BEARING. The old parent pinned every paragraph to 16px. Without this, blog
 * paragraphs inherit .militra-post-content's 19px (single-post.css) — its own `p`
 * rule sets only margin-bottom — which re-typesets every post. Restored so the
 * parent upgrade stays a visual no-op. */
p, .wp-block-paragraph {
	font-size: var(--font-size-base, 16px);
}

/* Global link colour. The old parent painted every bare <a>; the new parent emits
 * only :root vars, so links the child never paints (WooCommerce cart / my-account
 * body links, notice links, comment and widget links) revert to UA blue.
 * Specificity 0,0,1 — every component rule, and `.entry-content a` below, still win. */
a,
.wp-block-navigation-item__content {
	color: var(--color-links-initial, #797979);
}
a:hover,
.wp-block-navigation-item__content:hover {
	color: var(--color-links-hover, #252a36);
}

/* Brand text-selection highlight. Background ONLY — the old parent never set `color`
 * here (it had no white colour token), and token-compat.css DOES define --color-white,
 * so adding `color: var(--color-white)` would be a behaviour change, not a restore. */
::selection {
	background-color: var(--color-primary, #ff7544);
}

/* Global form controls. The old parent supplied these; the new parent supplies nothing.
 * The load-bearing half is border / radius / font-size / font-family plus the label
 * rule: without them, WooCommerce login+register on /paskyra/, the review form and the
 * shipping calculator render as UA-default inset 13px Arial boxes.
 *
 * No padding and no label margin-bottom: the old parent emitted neither (spacing.sm /
 * spacing.xs do not exist in this token set). Copied verbatim so the upgrade is a pixel
 * no-op. All selectors are 0,0,1 — every child class-scoped rule still wins. */
input[type="text"],
input[type="email"],
input[type="password"],
input[type="url"],
input[type="tel"],
input[type="number"],
input[type="search"],
textarea,
select {
	font-size: var(--font-size-base, 16px);
	font-family: var(--font-family-body, "DM Sans", sans-serif);
	border-radius: var(--border-radius-md, 15px);
	border: 1px solid var(--color-border, #000000);
	width: 100%;
	box-sizing: border-box;
}

input[type="text"]:focus,
input[type="email"]:focus,
input[type="password"]:focus,
input[type="url"]:focus,
input[type="tel"]:focus,
input[type="number"]:focus,
input[type="search"]:focus,
textarea:focus,
select:focus {
	border-color: var(--color-primary, #ff7544);
	outline: none;
}

label {
	font-weight: var(--font-weight-medium, 500);
	display: block;
}

/* ---- Generic-page content layout ---------------------------------- *
 * Targets parent-template pages only (e.g. /apie-mus/, rendered by the parent's
 * page.php). Excludes every template that owns its own layout:
 *   .home / .page-template-front-page  -> front-page.css (full-bleed)
 *   .search                            -> search.css
 *   .woocommerce / .woocommerce-page   -> shop / category / product CSS
 *   .site-main.contact-page            -> contact-page.css
 *   .site-main.militra-blog            -> blog-archive.css (own shell + container)
 *   .site-main.militra-single          -> single-post.css (own 1360px journal spread)
 *
 * The last two exclusions are LOAD-BEARING. The child's own home/index/archive/
 * page-naujienos templates emit `class="site-main militra-blog"` and single.php emits
 * `class="site-main militra-single"` — none of which is a WooCommerce or search body
 * class, so without these :not()s this rule matches them too. It would then clamp the
 * journal spread to 1264px (single-post.css explicitly needs 1360px: 704 prose +
 * 2x240 rail + 2x64 gutter + 2x24 padding), starving the TOC/related rails from ~240px
 * to ~168px, and would add 48px/24px padding to the blog listing that its own shell
 * already handles. Both templates would visibly change the moment the bridge came on.
 */
body:not(.home):not(.page-template-front-page):not(.search):not(.woocommerce):not(.woocommerce-page) .site-main:not(.contact-page):not(.militra-blog):not(.militra-single) {
	max-width: var(--header-width-max, 1264px);
	margin-left: auto;
	margin-right: auto;
	padding: var(--spacing-12, 48px) var(--spacing-8, 24px) var(--spacing-16, 64px);
	box-sizing: border-box;
}

body:not(.home):not(.page-template-front-page):not(.search):not(.woocommerce):not(.woocommerce-page) .site-main:not(.contact-page) .entry-header {
	margin-bottom: var(--spacing-6, 18px);
}

body:not(.home):not(.page-template-front-page):not(.search):not(.woocommerce):not(.woocommerce-page) .site-main:not(.contact-page) .entry-title {
	font-size: var(--font-size-4xl, 36px);
	font-weight: var(--font-weight-bold, 700);
	color: var(--color-headings-h1, #252a36);
	margin: 0 0 var(--spacing-4, 16px);
	line-height: var(--line-height-tight, 1.25);
}

body:not(.home):not(.page-template-front-page):not(.search):not(.woocommerce):not(.woocommerce-page) .site-main:not(.contact-page) .entry-content {
	font-size: var(--font-size-base, 16px);
	line-height: var(--line-height-relaxed, 1.75);
	color: var(--color-text, #777e90);
}

body:not(.home):not(.page-template-front-page):not(.search):not(.woocommerce):not(.woocommerce-page) .site-main:not(.contact-page) .entry-content > * {
	margin-top: 0;
	margin-bottom: var(--spacing-4, 16px);
}

body:not(.home):not(.page-template-front-page):not(.search):not(.woocommerce):not(.woocommerce-page) .site-main:not(.contact-page) .entry-content h2 {
	font-size: var(--font-size-2xl, 24px);
	margin-top: var(--spacing-8, 24px);
}

body:not(.home):not(.page-template-front-page):not(.search):not(.woocommerce):not(.woocommerce-page) .site-main:not(.contact-page) .entry-content h3 {
	font-size: var(--font-size-xl, 20px);
	margin-top: var(--spacing-6, 18px);
}

body:not(.home):not(.page-template-front-page):not(.search):not(.woocommerce):not(.woocommerce-page) .site-main:not(.contact-page) .entry-content a {
	color: var(--color-primary, #ff7544);
	text-decoration: underline;
}

body:not(.home):not(.page-template-front-page):not(.search):not(.woocommerce):not(.woocommerce-page) .site-main:not(.contact-page) .entry-content img {
	max-width: 100%;
	height: auto;
	border-radius: var(--border-radius-md, 15px);
}

body:not(.home):not(.page-template-front-page):not(.search):not(.woocommerce):not(.woocommerce-page) .site-main:not(.contact-page) .entry-content ul,
body:not(.home):not(.page-template-front-page):not(.search):not(.woocommerce):not(.woocommerce-page) .site-main:not(.contact-page) .entry-content ol {
	padding-left: var(--spacing-6, 18px);
}

/* ---- Button compatibility ---------------------------------------- *
 * Two changes the boltpress parent made to its button CSS API broke child
 * buttons:
 *   (a) it renamed its button classes .boltpress-btn-* -> .bp-btn-*, so the
 *       child's .boltpress-btn-primary/secondary CTAs (used as <a> in the hero
 *       and buy-now) lost all appearance and render as default blue links;
 *   (b) its generated design-tokens.css now paints EVERY bare <button> as a
 *       primary button — including `button:hover { background:#ff7544 }`
 *       (specificity 0,1,1), which beats a child custom button's base
 *       `.x { background:transparent }` (0,1,0) ON HOVER, so hovering a
 *       quantity arrow / checkout tab / toggle turns it into an orange pill.
 */

/* (a) Restore the child's primary/secondary button look (matches the parent's
 *     current .bp-btn-* design). Applies whether the element is <a> or <button>. */
.boltpress-btn-primary,
.boltpress-btn-secondary {
	display: inline-flex;
	align-items: center;
	justify-content: center;
	gap: var(--spacing-2, 8px);
	text-decoration: none;
	border: none;
	border-radius: var(--border-radius-md, 15px);
	font-family: var(--font-family-body);
	font-size: var(--font-size-base, 16px);
	font-weight: var(--font-weight-medium, 500);
	line-height: 1;
	cursor: pointer;
	transition: background-color 0.3s, color 0.3s;
}
.boltpress-btn-primary {
	background-color: var(--color-secondary, #ff8c63);
	color: #ffffff;
}
.boltpress-btn-primary:hover {
	background-color: var(--color-primary, #ff7544);
	color: #ffffff;
}
.boltpress-btn-secondary {
	background-color: var(--color-background, #ffffff);
	color: var(--color-accent, #252a36);
	border: 1px solid #e6e8ec;
}
.boltpress-btn-secondary:hover {
	background-color: var(--color-accent, #252a36);
	color: #ffffff;
}

/* (b) Stop the parent's generic <button> paint (esp. :hover) from bleeding onto
 *     the child's non-primary UI buttons. The `.x:hover` selectors are
 *     specificity 0,2,0, which beats the parent's `button:hover` (0,1,1).
 *     Genuine action buttons (.button, place_order, add-to-cart, buy-now,
 *     coupon, search/login submit) are intentionally NOT listed — they keep the
 *     primary look. */
/* Non-hover half. The parent's `button {}` rule is (0,0,1) and DOES paint
 * border-radius (its $prop_map covers background-color/color/border/border-radius/
 * padding/font-size/font-weight), so the radius reset belongs HERE — it is what keeps
 * genuinely square buttons (.tab-button, .search-tab, .faq-question, .show-more-btn,
 * .reset-variations) square. At (0,1,0) any component that declares its own radius
 * still wins, because base.css prints before the component CSS. */
.quantity-btn,
.tab-button,
.search-tab,
.product-tab-toggle,
.mobile-filter-toggle,
.menu-toggle,
.militra-nav-btn,
.product-action-btn,
.faq-question,
.show-more-btn,
.reset-variations,
.profile-close,
.search-close,
.minicart-close,
.mobile-menu-close,
.mobile-filter-close,
.remove,
.remove_from_cart_button {
	background-color: transparent;
	border-radius: 0;
}

/* Hover half. ONLY background-color needs beating: the parent's `button:hover` (0,1,1)
 * emits background-color/color/border/transform/transition — and NEVER border-radius
 * (its $hover_map has no radius key).
 *
 * So do NOT repeat `border-radius: 0` here. At (0,2,0) it would beat each component's
 * own base `.x { border-radius: ... }` (0,1,0) and square the button ON HOVER — which
 * is visible on every button that has a painted hover background or shadow: the 44x44
 * wishlist/compare buttons, the orange 48x48 mobile filter toggle, and the profile /
 * search / mobile-filter close chips. */
.quantity-btn:hover,
.tab-button:hover,
.search-tab:hover,
.product-tab-toggle:hover,
.mobile-filter-toggle:hover,
.menu-toggle:hover,
.militra-nav-btn:hover,
.product-action-btn:hover,
.faq-question:hover,
.show-more-btn:hover,
.reset-variations:hover,
.profile-close:hover,
.search-close:hover,
.minicart-close:hover,
.mobile-menu-close:hover,
.mobile-filter-close:hover,
.remove:hover,
.remove_from_cart_button:hover {
	background-color: transparent;
}

/* (c) .variation-btn — the product size/attribute swatches.
 *     The parent's `button:hover` (0,1,1) beats `.variation-btn` (0,1,0), so the swatch
 *     took a #ff7544 background on hover. The child's own hover rule
 *     `.variation-btn:hover:not(.disabled):not(.selected)` (0,4,0) sets
 *     `color: var(--color-primary)` but NO background — so the label went orange ON
 *     orange and became literally invisible, on every variable product. The parent's
 *     `border: none` also stripped the 1px outline.
 *
 *     Deliberately a SEPARATE rule, not appended to the (b) list above: that list only
 *     neutralizes background-color, while these swatches also need their colour and
 *     their 1px outline restated.
 *
 *     border-width MUST be restated: the parent's `border: none` is a SHORTHAND, so it
 *     also resets border-width to its initial `medium` (~3px) at (0,1,1), which beats
 *     `.variation-btn { border: 1px solid }` (0,1,0). Restoring style alone would bring
 *     the border back at 3px and reflow the swatch row on hover.
 *
 *     No border-radius and no border-color here: the child's (0,4,0) rule keeps the
 *     orange hover border, and .selected keeps its own. */
.variation-btn:hover {
	background-color: var(--color-background, #ffffff);
	color: var(--color-headings-general, #252a36);
	border-width: 1px;
	border-style: solid;
}

/* Colour swatches use a 2px ring. Same specificity (0,2,0) as the rule above, so this
 * MUST stay after it. */
.variation-btn--color:hover {
	border-width: 2px;
}

/* (d) The parent's `button:hover` ALSO sets `color: #ffffff` at (0,1,1), which beats a
 *     child button's base `.x { color: ... }` at (0,1,0). Every button in the (b) list
 *     that declares its own `:hover { color: ... }` (0,2,0) is already safe. These two
 *     do not, so restate their colour at (0,2,0):
 *       - .faq-question sets `color:#252A36` only in its base rule, and its own :hover
 *         sets background alone -> /kontaktai/ FAQ questions turn WHITE on white and
 *         vanish under the cursor.
 *       - .mobile-menu-close sets `color: var(--color-text)` and its <svg> strokes with
 *         `currentColor` -> the close X turns white on the white overlay.
 *
 *     Do NOT instead add `color: inherit` to the (b) list: it would land at (0,2,0) on
 *     the `.x:hover` half and override each component's own base colour, turning hovered
 *     FAQ text inherited grey rather than its intended #252A36. */
.faq-question:hover {
	color: #252A36;
}
.mobile-menu-close:hover {
	color: var(--color-text, #777e90);
}

/* (e) Tab underlines. The parent's `button:hover { border: none }` (0,1,1) is a
 *     SHORTHAND: it beats `.tab-button { border-bottom: 3px solid transparent }` (0,1,0)
 *     and resets style -> none (so the used border-width collapses to 0), width ->
 *     medium, and colour -> currentcolor.
 *
 *     On hover that made the whole tab row jump 3px (checkout) / 2px (search) under the
 *     cursor, and the ACTIVE tab's orange underline vanished: `.tab-button.active` (0,2,0)
 *     re-supplies border-bottom-COLOR only, and a style of `none` renders nothing no
 *     matter what colour it is.
 *
 *     All THREE longhands must be restated. Restoring style+width alone would unmask the
 *     colour reset and give every hovered NON-active tab a dark underline (currentColor,
 *     from the component's own `:hover { color: ... }`) — a different regression. The
 *     transparent colour is therefore scoped `:not(.active)` (0,3,0), so the active tab
 *     keeps its orange from `.tab-button.active` without depending on the source order of
 *     two equal-specificity (0,2,0) rules living in different files. */
.tab-button:hover {
	border-bottom-style: solid;
	border-bottom-width: 3px;
}
.tab-button:hover:not(.active) {
	border-bottom-color: transparent;
}

.search-tab:hover {
	border-bottom-style: solid;
	border-bottom-width: 2px;
}
.search-tab:hover:not(.active) {
	border-bottom-color: transparent;
}

/* (f) .related-nav-btn — the related-products carousel arrows. Kept OUT of the (b) list
 *     because they need their fill and icon colour restated, not just neutralized.
 *
 *     Their own hover rule is `:hover:not(:disabled)` (0,3,0), and these arrows are
 *     disabled in the common case (prev is disabled at load; next is disabled whenever
 *     the related products already fit the grid — i.e. usually, on desktop). A
 *     disabled+hovered arrow therefore falls through to the parent's
 *     `button:hover { background-color:#ff7544; color:#ffffff }` (0,1,1), which beats the
 *     component's base `.related-nav-btn { background; color }` (0,1,0) — so the
 *     currentColor chevron went white-on-white and the button lost its fill.
 *
 *     Restate fill, colour and radius at (0,2,0). The ENABLED hover still wins from
 *     single-product.css at (0,3,0), so its orange lift is unchanged. */
.related-nav-btn:hover {
	background-color: var(--color-background, #ffffff);
	color: var(--color-text, #777e90);
	border-radius: var(--border-radius-md, 15px);
}
