/*
Small custom stylesheet for the handful of things theme.json can't express
(it only covers block *supports* -- color, spacing, typography -- not
arbitrary selectors like `summary::marker` or CSS techniques like masks).
*/

/* Single source of truth for every full-bleed section's left/right inset
(header, footer, and the hero/section patterns) -- they all just use
"align":"full" and get this same padding, instead of each one repeating its
own padding-left/right value. Deliberately NOT done via theme.json's
"useRootPaddingAwareAlignments" + root spacing.padding: that only escapes
correctly for elements that are DIRECT children of .wp-site-blocks, so
patterns nested inside <main>/post-content's own "constrained" layout ended
up capped at that container's contentSize/wideSize instead of the true
viewport edge once the screen got wider than that cap -- header/footer (true
direct children) stayed edge-to-edge, so the two drifted out of alignment on
wide screens. The width:100vw + negative-margin trick below sizes every
.alignfull element off the viewport directly, ignoring ancestor width caps
entirely, so it can never drift regardless of nesting or screen size. */
.alignfull {
	box-sizing: border-box;
	width: 100vw;
	max-width: 100vw;
	margin-left: calc(50% - 50vw);
	margin-right: calc(50% - 50vw);
	padding-left: var(--wp--preset--spacing--30);
	padding-right: var(--wp--preset--spacing--30);
}

/* Guaranteed left/right inset for plain (non-full-bleed) page content --
WP's "constrained" layout (used by post-content) only caps a *max* width and
centers it with auto margins, so below that cap (contentSize/wideSize) there
is no side margin at all: a plain text page narrower than that cap sits
flush against the browser edge. Padding directly on <main> gives every
template a floor that holds at any viewport width. Hero/section patterns
still bleed past this edge-to-edge via the ".alignfull" rule above, which
sizes off the viewport directly and ignores this (or any) ancestor padding. */
main.wp-block-group {
	box-sizing: border-box;
	padding-left: var(--wp--preset--spacing--30);
	padding-right: var(--wp--preset--spacing--30);
}

/* Header's total rendered height, computed rather than measured: 1.5rem
top padding + 1.5rem bottom padding (see header.html), plus the tallest
element in the row between them. That's the "Termin buchen" button, not
the site-brand text -- theme.json gives buttons 1rem top/bottom padding
(spacing--20) around a line box at the global body font-size (1.0625rem)
and line-height (1.6), i.e. 1rem + 1rem + (1.0625rem * 1.6) = 3.7rem.
Total: 1.5rem + 1.5rem + 3.7rem = 6.7rem. Kept as one variable so the hero
section below can size itself off the same number -- if the header's
padding, button padding, or font-size ever changes, this is the one place
to update. */
:root {
	--site-header-height: 6.7rem;
}

/* Below 600px the ".header-cta" button is hidden (see the header CTA rule
further down) and the nav collapses to just the hamburger icon, so the
button no longer sets the row's height -- the tallest element instead
becomes the site-brand text at font-size--large (1.75rem), giving a line
box of 1.75rem * 1.6 = 2.8rem. Header height there: 1.5rem + 1.5rem + 2.8rem
= 5.8rem. Without this override, the hero's "100vh - header" calc would
keep subtracting the taller desktop figure, leaving a gap the size of the
difference at the bottom of the mobile hero. */
@media (max-width: 599px) {
	:root {
		--site-header-height: 5.8rem;
	}
}

/* --- Logo ---------------------------------------------------------------
The logo file (assets/logo.svg) is a single-color icon. Rather than keeping
two copies of it (one white for the header, one green for the footer), it's
applied as a CSS mask: the element's own background-color shows through the
icon's shape, so the same file recolors for free just by changing
`color`/`background-color` per context, the same way an icon font would. */
/* The logo sits inside an <a> for the home link, and theme.json's global
link color (green, turning gray on :hover) would otherwise win over the
surrounding text color -- making the logo blend into the green header by
default and only show up on hover once the color actually changed. Forcing
it back to the parent's color keeps it visible all the time. */
.site-logo-link,
.site-logo-link:hover {
	color: inherit;
}

/* Same problem, same fix, for the site title text itself: theme.json's
global link style sets its own :hover color (the muted tertiary tone),
which otherwise fights the brightness-filter hover effect below -- the text
would shift to that darker color at the same time the filter tries to
brighten it, so the brightening barely reads. Neutralizing color here
leaves the header's brightness filter as the only visible hover effect,
matching the logo. */
.site-brand .wp-block-site-title a:hover {
	color: inherit;
}

/* Logo + site name highlight together as a single unit on hover -- set on
the shared parent so the logo mask and the site-title link fade/brighten
together as one, rather than needing separate rules for each.
The two contexts need opposite treatments: the header is light text on the
dark green background, so fading it toward transparent would just look
darker/grayer -- a brightness boost is what actually reads as "lit up"
there. The footer is dark green text on a light background, where the
usual opacity fade reads correctly as a subtle dim. */
header .site-brand:hover {
	filter: brightness(1.3);
}

footer .site-brand:hover {
	opacity: 0.7;
}

.site-logo {
	display: inline-block;
	width: 1em;
	height: 1em;
	flex-shrink: 0;
	background-color: currentColor;
	-webkit-mask-image: url(../logo.svg);
	mask-image: url(../logo.svg);
	-webkit-mask-repeat: no-repeat;
	mask-repeat: no-repeat;
	-webkit-mask-position: center;
	mask-position: center;
	-webkit-mask-size: contain;
	mask-size: contain;
}

/* Open/close height animation lives entirely in accordion.js (a pure-CSS
attempt -- transitioning `grid-template-rows` between an "auto 0fr" and
"auto 1fr" track -- turned out not to animate reliably here in practice,
particularly on close, since the browser's own instant `display:none` on
the content wins the moment the `open` attribute is removed). The JS
instead animates the `<details>` element's own `height` with the Web
Animations API, and controls exactly when the `open` attribute flips, so
closing gets the same treatment as opening. */
.wp-block-details {
	/* accordion.js measures/animates this element's own `height`. Without
	border-box, the CSS `height` it sets excludes this padding and border,
	so the box would render taller than the number the script just measured
	-- part of what caused the animation to over/undershoot. */
	box-sizing: border-box;
	border-top: 1px solid var(--wp--preset--color--contrast);
	padding: 1rem 0;
}

/* Closing rule under the last item -- each item only draws the line above
itself, so without this the bottom of the last item would be open. */
.wp-block-details:last-of-type {
	border-bottom: 1px solid var(--wp--preset--color--contrast);
}

.wp-block-details summary {
	list-style: none;
	cursor: pointer;
	display: flex;
	align-items: baseline;
	justify-content: space-between;
	gap: 1rem;
}

.wp-block-details summary::-webkit-details-marker {
	display: none;
}

/* A single "+" rotated 45deg reads as "x" -- animating the rotation instead
of swapping the character (the previous "+"/"-" text swap, an instant,
unanimatable content change) makes the marker itself feel like part of the
same smooth open/close motion as the content. */
.wp-block-details summary::after {
	content: "+";
	font-size: var(--wp--preset--font-size--large);
	line-height: 1;
	flex-shrink: 0;
	transition: transform 0.3s ease;
}

/* Keyed off ".is-marker-open" (toggled by accordion.js) rather than the
`[open]` attribute: accordion.js deliberately keeps `open` true for the
whole shrink animation (see that file), so a selector tied to `[open]`
would leave the marker showing "x" for the entire close instead of
flipping back to "+" the moment the user clicks. */
.wp-block-details.is-marker-open summary::after {
	transform: rotate(45deg);
}

/* --- Header: sticky ------------------------------------------------------
The sticky rule targets `.wp-block-template-part` (WordPress's own wrapper
around every template part), not `.site-header` itself: a sticky element
is confined to its immediate parent's box, and that wrapper is exactly as
tall as the header with no extra room -- sticky on the inner element alone
would have nowhere to "stick" and just scroll away with the page. */
.wp-block-template-part:has(.site-header) {
	position: sticky;
	top: 0;
	z-index: 100;
}

/* --- Hero: fills the viewport height left over below the header ---------
Section height = 100vh - header height, so header + hero always add up to
exactly one viewport -- except on short viewports, where that remainder
would shrink below a usable size, so `max()` floors it at 500px instead
(the hero then simply pushes the header + hero total past 100vh rather
than continuing to compress). `box-sizing: border-box` keeps the hero's own
vertical padding inside that height instead of adding to it -- otherwise
the section would render taller than the calculated remainder. */
.page-hero {
	padding-top: var(--wp--preset--spacing--30) !important;
	padding-bottom: var(--wp--preset--spacing--30) !important;
	height: max(500px, calc(100vh - var(--site-header-height)));
	box-sizing: border-box;
	overflow: hidden;
}

.page-hero .wp-block-heading {
	margin-top: var(--wp--preset--spacing--50);
}

/* The image column stretches to the hero's full (fixed) height, and the
image itself scales *within* that height instead of rendering at its
natural size -- object-fit: contain shrinks it proportionally when it's
taller than the available space (this is the "scaled down if larger"
behavior) without upscaling or distorting smaller images. Every ancestor
between the hero and the <img> needs an explicit height for a percentage
height to resolve at all -- percentages against an auto-height parent are
ignored. */
.page-hero .wp-block-columns,
.page-hero .wp-block-column {
	height: 100%;
}

.page-hero .wp-block-image {
	height: 100%;
	display: flex;
	justify-content: center;
	margin: 0;
}

.page-hero .wp-block-image img {
	height: 100%;
	width: auto;
	max-width: 100%;
	object-fit: contain;
}

/* Below 782px, wp:columns stacks the hero's text and image into two rows
instead of side by side (see wp-includes/blocks/columns/style.css) -- the
desktop rules above give both stacked columns 100% of the hero's fixed
height each, which would double up and overflow. Reset that here and give
the image its own capped, viewport-relative height instead: full width,
cropped (object-fit: cover) rather than letterboxed, since "full width" and
uncropped/contain don't both fit an arbitrary source image's aspect ratio. */
@media (max-width: 781px) {
	/* The fixed "100vh - header" (or 500px-floored) height above is sized for
	the desktop side-by-side layout; stacked on mobile, that same box has to
	fit padding + heading + paragraph + button + the image below, which on
	small enough viewports (iPhone SE and similar) adds up to more than the
	fixed height -- with overflow: hidden, the excess (the image, being last)
	just gets clipped instead of pushing the section taller. Auto height lets
	the section grow to fit everything it actually contains. */
	.page-hero {
		height: auto;
		overflow: visible;
	}

	.page-hero .wp-block-columns,
	.page-hero .wp-block-column {
		height: auto;
	}

	/* A definite height (not "auto" + max-height) is required here: percentage
	heights only resolve against a containing block with a specified size, so
	with max-height alone the img's own "height: 100%" below would compute as
	auto -- rendering at its natural aspect ratio instead of the boxed size
	object-fit needs to do its cropping, and any overflow would just get
	clipped from the top down by this element's own overflow: hidden rather
	than cropped evenly via object-position. */
	.page-hero .wp-block-image {
		height: 40vh;
		width: 100%;
		overflow: hidden;
	}

	.page-hero .wp-block-image img {
		width: 100%;
		height: 100%;
		max-width: none;
		object-fit: cover;
		/* Explicit rather than relying on the (same) default: crops evenly off
		the top and bottom to keep the subject centered, instead of anchoring
		to the image's top edge and only losing detail off the bottom. */
		object-position: center;
	}
}

/* Keeps the brand (logo + site title) and the nav row each on a single
line, and stops the two from stacking onto separate lines on narrower
desktop widths -- wp:group's flex layout wraps by default once its
children can't fit side by side, which would otherwise break the header
into two rows instead of just letting the row scroll/clip. */
.site-header .wp-block-group {
	flex-wrap: nowrap;
}

.site-header .site-brand,
.site-header .wp-block-site-title,
.site-header .wp-block-navigation-item {
	white-space: nowrap;
}

/* --- Header CTA (desktop) ------------------------------------------------
Hidden below 600px -- that's the nav block's own built-in breakpoint for
collapsing into the hamburger/overlay (see wp-includes/blocks/navigation
style), where the mobile-menu's own copy of this CTA (inside the overlay)
takes over instead. Margin-left gives it breathing room from the nav links
since it sits right after them in the same flex row. */
.site-header .header-cta {
	display: none;
}

@media (min-width: 600px) {
	.site-header .header-cta {
		display: flex;
		margin-left: var(--wp--preset--spacing--20);
	}
}

/* --- Navigation: thinner text, more breathing room between items --------
Mirrors the wp:navigation block's own "style" attribute (see header.html)
so the look holds even if a WP version ignores that block support. */
.wp-block-navigation {
	font-weight: 300;
}

.wp-block-navigation .wp-block-navigation-item {
	margin-inline: var(--wp--preset--spacing--20);
}

/* Smaller screens: the wider item margins above are for the open desktop
row: inside the overlay menu, items stack vertically, so a large inline
margin would just misalign them off-center instead of adding vertical
rhythm. Reset to the overlay's own vertical spacing there. */
.wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation-item {
	margin-inline: 0;
}

@media (max-width: 480px) {
	.site-header {
		padding-left: var(--wp--preset--spacing--20) !important;
		padding-right: var(--wp--preset--spacing--20) !important;
	}
}

/* --- Mobile menu overlay -------------------------------------------------
Core vertically *centers* the dialog within the fullscreen overlay (it's a
column flexbox, so that's `justify-content`, not `align-items`), and its
close button sits flush at top:0/right:0 with no inset of its own -- so it
never lines up with the padded header above it. Rather than detaching
either icon from the document with `position: fixed` (which fights the
header's own sticky/shrink behaviour and the nav block's own
`position: relative`), both icons stay in their normal, core-default
position (open: a static flex child of the header row; close: absolute
within the dialog) -- only the close button's top/right *values* change,
to the same spacing tokens the header uses for its own padding. (A
containing block for an absolutely positioned child is measured to the
padding box's *outer* edge, not its inner one, so padding on the dialog
itself wouldn't have insetted the close button -- the offset has to be set
directly on the button.) `justify-content: flex-start` anchors the dialog
to the top of the screen, under the header, instead of centering it, so
the menu reads as dropping from the top nav bar rather than floating in
the middle of the screen. */
.wp-block-navigation__responsive-container.is-menu-open {
	justify-content: flex-start;
}

/* Scoped to ".is-menu-open": ".wp-block-navigation__responsive-dialog" is
part of the nav block's markup at all times, not just while the overlay is
open -- on desktop, where the container renders inline in the header
instead of as a fullscreen dialog, an unscoped rule here would still add
this padding around the inline nav row, growing it enough to wrap onto a
second line. Restricting it to the open overlay state keeps the desktop
row unaffected.
2.2rem sits between the "30" (2rem) and "40" (4rem) spacing tokens -- no
exact preset for it, so it's a literal value here rather than a token. */
.wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__responsive-dialog {
	padding: 2.2rem var(--wp--preset--spacing--30) var(--wp--preset--spacing--20);
}

.wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__responsive-container-close {
	top: 2.2rem;
	right: var(--wp--preset--spacing--30);
}

@media (max-width: 480px) {
	.wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__responsive-dialog {
		padding-left: var(--wp--preset--spacing--20);
		padding-right: var(--wp--preset--spacing--20);
	}

	.wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__responsive-container-close {
		right: var(--wp--preset--spacing--20);
	}
}

/* Generous margin around the menu text so nothing sits flush against the
screen edge or the close icon above it. `align-items: center` centers the
logo, the link list, and the CTA button as a group (they're all direct
flex children of this column) -- `text-align: center` on top of that keeps
each link's own text centered within its shrink-to-fit box.
`!important` on both: this selector is identical to one of core's own (see
the ".../responsive-container-content { align-items: var(...) }" rule), so
without it the outcome depends on which stylesheet happens to load last. */
.wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__responsive-container-content {
	padding: var(--wp--preset--spacing--40) 0 0;
	gap: var(--wp--preset--spacing--30);
	align-items: center !important;
	text-align: center !important;
}

/* Bigger, easier-to-hit link text once the menu is a full-screen overlay --
the desktop inline row stays at its own (thinner, smaller) size.
The list itself (".../navigation__container", the <ul>) shrink-wraps to its
*widest* item rather than filling the column, so each <li> was only ever
centered relative to that widest sibling, not the menu as a whole -- the
shorter "Kontakt" link sat noticeably left of "Über mich" above it, both
left-edge-aligned rather than each centered on its own. Stretching the list
and each item to the full column width, then centering *within* that width
via `justify-content`, centers every link on the same axis as the logo and
CTA button instead. */
.wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__container {
	width: 100%;
}

.wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation-item {
	width: 100%;
	justify-content: center;
}

.wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation-item .wp-block-navigation-item__content {
	font-size: var(--wp--preset--font-size--large);
	justify-content: center;
	text-align: center;
	width: 100%;
}

/* Booking CTA: lives inside the nav block (so it's part of the same menu
content) but only makes sense once that content is the full-screen mobile
overlay -- in the desktop inline row it would just be a second button
floating next to two links. Hidden by default, shown (and given room to
breathe from the links above it) only inside the open overlay. */
.wp-block-navigation .wp-block-buttons {
	display: none;
}

.wp-block-navigation__responsive-container.is-menu-open .wp-block-buttons {
	display: flex;
	margin-top: var(--wp--preset--spacing--20);
}

/* Logo mark: same hide-on-desktop/show-in-overlay treatment as the CTA
above, sized up from the 1em it inherits in the header (see custom.css'
"Logo" section) since here it's a standalone mark rather than sitting next
to the site title text. */
.wp-block-navigation .nav-logo {
	display: none;
}

.wp-block-navigation__responsive-container.is-menu-open .nav-logo {
	display: flex;
	font-size: var(--wp--preset--font-size--xx-large);
}

/* Overrides core's built-in 0.1s fade (barely perceptible) with a slower
fade-plus-slide so opening the menu reads as a deliberate motion. The
extra ".site-header" ancestor in the selector out-specifies core's own
rule regardless of stylesheet load order. The slide (translateY) animates
the *content* wrapper rather than the outer ".is-menu-open" container so
it doesn't interfere with anything positioned relative to the container
itself (the container's own inset:0/fixed positioning). */
@keyframes site-header-nav-fade-in {
	from {
		opacity: 0;
	}
	to {
		opacity: 1;
	}
}

@keyframes site-header-nav-slide-in {
	from {
		opacity: 0;
		transform: translateY(-0.75rem);
	}
	to {
		opacity: 1;
		transform: translateY(0);
	}
}

@media not (prefers-reduced-motion) {
	.site-header .wp-block-navigation__responsive-container.is-menu-open {
		animation: site-header-nav-fade-in 0.35s ease-out;
	}

	.site-header .wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__responsive-container-content {
		animation: site-header-nav-slide-in 0.35s cubic-bezier(0.16, 1, 0.3, 1);
	}
}

/* --- Columns block: "Reversed stack on mobile" style variation ------------
Registered in functions.php (register_block_style). Core already stacks
wp:columns into a single vertical column below 782px (see the "Below 782px"
comment above); this just flips the order of that stack for the specific
instances where the second column should end up on top on mobile instead of
below -- editors pick it per-block from the block's Styles panel, no markup
reordering needed. Scoped to the same max-width:781px breakpoint core uses
for stacking, since flipping direction before that would break the desktop
side-by-side row. */
@media (max-width: 781px) {
	.wp-block-columns.is-style-stack-reverse {
		flex-direction: column-reverse;
	}
}

/* --- Button block: "Link" style variation ---------------------------------
Registered in functions.php (register_block_style) as a secondary option
next to core's own "Outline" style. Strips the button's background/border
down to plain underlined text in the theme's link color, for CTAs that
shouldn't compete visually with the primary (filled) button. */
.wp-block-button.is-style-link .wp-block-button__link {
	background: none;
	color: var(--wp--preset--color--primary);
	padding-left: 0;
	padding-right: 0;
	text-decoration: underline;
}

.wp-block-button.is-style-link .wp-block-button__link:hover {
	color: var(--wp--preset--color--tertiary);
}

.mobile-only {
  display: none;
}

@media (max-width: 600px) {
  .mobile-only {
    display: block;
  }
}