/**
 * insta/header — navigation overlay (menu panel) block styles.
 *
 * Scoped to `.ib-header.is-style-<name>` so a header without the style, and every other block on
 * the page, are untouched. The panel's CONTENTS are core/navigation's own inner blocks — these
 * rules only arrange them.
 *
 * Core still owns the shell unconditionally (`position:fixed; inset:0`, flex column, overflow,
 * z-index) and adds `disable-default-overlay` when a custom overlay part is used. These styles work
 * either way: they set the box, not the plumbing.
 */

/* ─────────────────────────────────────────────────────────────────────────────
 * Menu — side panel
 *
 * MEASURED on the source (oshinewptheme.com/v62) at 1440 / 768 / 390 with the menu OPEN:
 *   panel   400 × 100vh at every width, position:fixed, right:0, padding 40px, background #fff
 *   links   28px / 36px line-height, constant across widths
 *
 * The width is a CONSTANT 400px in the source, not a viewport fraction — at 768 it is still 400
 * (27.78vw would be 213), and at 390 the source's panel starts at x = -10, i.e. it OVERFLOWS the
 * viewport by 10px. `min(25rem, 100%)` reproduces it exactly at 768 and above and caps it at 390
 * instead of overflowing. That is a deliberate 10px deviation from the source at the smallest
 * width: a horizontal overflow is a defect to inherit, not a design to reproduce.
 * ───────────────────────────────────────────────────────────────────────────── */
.ib-header.is-style-overlay-side-panel .wp-block-navigation__responsive-container.is-menu-open {
	box-sizing: border-box;
	inline-size: min(25rem, 100%);
	inset-inline-end: 0;
	inset-inline-start: auto;
	padding: 2.5rem;
}

/* MAKE THE HEIGHT CHAIN REACH THE CONTENT.
 *
 * Core nests the content two wrappers deep — `__responsive-close` > `__responsive-dialog` >
 * `__responsive-container-content` (navigation.php:805-808) — and gives neither wrapper a height.
 * `block-size: 100%` on the content alone therefore resolves against `auto` and does nothing:
 * measured, the content stayed 356px tall inside a 920px panel, so `space-between` had almost
 * nothing to distribute and the social row sat at y=338 instead of 894.
 *
 * The panel itself is already a flex column (core, unconditional), so each wrapper only needs to be
 * a flex item that grows and a flex column in turn. `min-block-size: 0` because a flex item's
 * automatic minimum is its content size, which would otherwise stop it shrinking to the panel.
 */
.ib-header.is-style-overlay-side-panel .wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__responsive-close,
.ib-header.is-style-overlay-side-panel .wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__responsive-dialog {
	display: flex;
	flex: 1 1 auto;
	flex-direction: column;
	min-block-size: 0;
}

/* The panel's own content column fills it and distributes three bands; core leaves it height-auto at
 * flex-start, so everything packs against the top of a 920px panel — measured on the build as
 * logo 96 / link1 146 / social 394 / legal 436 against the source's 40 / 355 / 894 / 933.
 *
 * Core hard-sets `justify-content: flex-start` here at (0,3,0) — three classes, its `:where()`
 * contributing nothing — so NO block attribute can win. Overriding it is why this is a style rule
 * rather than an attribute on the block.
 *
 * `padding-top: 0` removes core's `calc(2rem + 24px)` (=56px). That reserve exists to keep content
 * clear of the close button, but the button is ALREADY `position:absolute; top:0; right:0` in core
 * (style.css:645) and absolute resolves against the padding box — so it already sits at the panel's
 * own 2.5rem inset, and the reserve only pushed every element down by 56px. The button stays exactly
 * where core puts it; nothing here repositions it.
 *
 * MEASURED bands on the source @1440 (identical at 768/390 but for the x origin):
 *   logo  y=40  h=225  flex-start
 *   nav   y=265 h=449  center
 *   foot  y=714 h=246  flex-end   (social row + legal line)
 */
.ib-header.is-style-overlay-side-panel .wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__responsive-container-content {
	block-size: 100%;
	display: flex;
	flex-direction: column;
	inline-size: 100%;
	justify-content: space-between;
	padding-top: 0;
}

/* The link list is where the distribution actually happens, because core puts EVERY inner block in
 * it as an `<li>` — logo, links and the social row are siblings in one `ul`. (The legal line is the
 * exception: it renders as a `<p>` sibling of the `ul`, so `space-between` on the content above
 * already pins it to the bottom.)
 *
 * `justify-content` cannot express this: it distributes all six items identically, which centred the
 * logo at y=334 instead of leaving it at 40. AUTO MARGINS can — the first item takes all the free
 * space after it and the last takes all the space before it, so with both set the links in between
 * end up centred in what remains. Core sets `justify-content: flex-start` here in the same (0,3,0)
 * rule as the content, which is why this rule has to exist at all.
 *
 * Targets, source @1440: logo 40 · link1 355 · social 894 · legal 933.
 */
.ib-header.is-style-overlay-side-panel .wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__container {
	flex: 1 1 auto;
}

.ib-header.is-style-overlay-side-panel .wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__container > :first-child {
	margin-block-end: auto;
}

.ib-header.is-style-overlay-side-panel .wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__container > :last-child {
	margin-block-start: auto;
}

/* MOTION — the panel travels LEFT → RIGHT into its right-anchored position.
 *
 * DIRECTION: the panel enters from the RIGHT EDGE and slides left into place — the conventional
 * hamburger drawer, and exactly what the source does (`translate: 100% 0` -> `0 0`, home.css:285-286).
 *
 * `100%` is a percentage of the ELEMENT's own width, which is the right unit here: the panel is
 * right-anchored (inset-inline-end: 0), so shifting it by one panel-width parks it flush off the
 * right edge at any viewport width, and the travel is the panel's own 400px.
 *
 * ⚠ DO NOT SWAP THE UNIT FOR A VIEWPORT ONE. An earlier revision briefly entered from the left with
 * `-100%`, which resolves against the ELEMENT (400px) rather than the viewport and so parked the
 * panel 400px left of its resting place — still INSIDE the screen on a wide viewport (measured: it
 * began at x=640 at 1440, the dead centre, and worsened with width while looking correct at 390
 * where the panel is as wide as the screen). Entering from the left needs `-100vw`; entering from
 * the right needs `100%`. The unit is not interchangeable — it depends on which edge you park at.
 *
 * Timing is the source's 0.7s cubic-bezier over the source's own 400px travel, so the motion reads
 * exactly as the source does.
 *
 * WHY @starting-style. Core's closed container is `display: none`
 * (block-library/navigation/style.scss) and only `.is-menu-open` makes it `display: flex`. A
 * transition cannot run from `display:none`, so `@starting-style` supplies the pre-open value the
 * ENTRY transition starts from. Nothing here toggles display itself, so a browser that ignores the
 * rule still opens and closes the panel correctly — it simply does so instantly.
 *
 * ENTRY ONLY — THE EXIT IS DELIBERATELY INSTANT. Animating it needs `display .25s allow-discrete`
 * to hold the panel visible while it leaves, and that MEASURABLY GLITCHES: core scopes the whole
 * panel box — `inline-size`, `inset-inline-end`, `position: fixed` — to `.is-menu-open` (and so do
 * the rules above), so the moment core removes that class the element snaps back to its in-flow
 * size and position and only then slides. Measured with allow-discrete at 1440: x ran
 * 0 → -641 → -1200 → -1405 over 250ms instead of the 400px it should travel. A clean instant close
 * beats a 250ms glitch. Making the exit animate means moving the box onto the base container so it
 * survives the class removal — a change to the rules above, not to this block.
 */
.ib-header.is-style-overlay-side-panel .wp-block-navigation__responsive-container {
	translate: 100% 0;
	transition: translate 0.7s cubic-bezier(0.645, 0.045, 0.355, 1);
}

.ib-header.is-style-overlay-side-panel .wp-block-navigation__responsive-container.is-menu-open {
	translate: 0 0;
}

@starting-style {
	.ib-header.is-style-overlay-side-panel .wp-block-navigation__responsive-container.is-menu-open {
		translate: 100% 0;
	}
}

/* SUPPRESS CORE'S OWN OPEN ANIMATION — this is what made the slide look unsmooth.
 *
 * Core runs, on every open (style.css:453 + :490-493, inside `@media not (prefers-reduced-motion)`):
 *
 *   @keyframes overlay-menu__fade-in-animation {
 *     0%  { opacity: 0; transform: translateY(0.5em) }
 *     to  { opacity: 1; transform: translateY(0) }
 *   }
 *   .wp-block-navigation__responsive-container.is-menu-open {
 *     animation: overlay-menu__fade-in-animation 0.1s ease-out; animation-fill-mode: forwards;
 *   }
 *
 * That is core's treatment for a panel that simply APPEARS, and it fights a slide: for the first
 * 100ms of our 700ms travel the panel also fades up from opacity 0 and jumps 8px VERTICALLY, so the
 * motion starts as a diagonal pop and only then settles into the horizontal glide. Measured against
 * the live source, which runs no animation at all on its panel (`animation-name: none`, transitions
 * only), this was the whole difference — the easing curve already matched frame for frame.
 *
 * Core's rule is (0,2,0); this is (0,3,0), so it wins without !important. Only the ANIMATION is
 * dropped — the panel's final opacity is 1 either way, so nothing here affects the closed state or
 * a browser that never runs the animation.
 */
.ib-header.is-style-overlay-side-panel .wp-block-navigation__responsive-container.is-menu-open {
	animation: none;
}

@media (prefers-reduced-motion: reduce) {
	.ib-header.is-style-overlay-side-panel .wp-block-navigation__responsive-container {
		transition: none;
	}
}

/* BACKDROP — the page dims behind the panel. MEASURED ON THE LIVE SOURCE, ABSENT FROM THE GOLDEN.
 *
 * oshinewptheme.com/v62 renders a second fixed element alongside the panel (`div.open`), captured
 * with document.getAnimations() during the open at 1440:
 *   box         position:fixed, 0,0 1440x1024 (full viewport)
 *   background  rgba(0, 0, 0, 0.8)
 *   z-index     100000   (the panel itself is 100001, i.e. the scrim sits directly beneath it)
 *   transition  opacity 0.5s cubic-bezier(0.645, 0.045, 0.355, 1), visibility likewise
 *
 * The approved mockup has NO backdrop at all — no scrim element, no dimming rule. That omission is
 * why the slide read as unsmooth even once the easing matched the source frame for frame: a white
 * panel crossing a bright, undimmed page has nothing to separate it from what is behind it. The
 * dim is doing as much of the work as the movement.
 *
 * WHY A PSEUDO-ELEMENT ON THE HEADER, not on the panel. Core sets `overflow: auto` on
 * `.is-menu-open`, which clips any child that extends past the 400px panel — a scrim placed there
 * would be cropped to the panel and scroll with it. `.ib-header` is `position: relative; z-index: 100`,
 * so it establishes the stacking context the panel lives in: a fixed pseudo-element here paints
 * above the page but below the panel's own 100000, which is exactly the source's ordering.
 *
 * `html.has-modal-open` is CORE's own signal — it sets that class while an overlay is open
 * (style.css, `html.has-modal-open{overflow:hidden}`), so no extra JS is needed to know the state.
 * Driving `visibility` rather than `display` keeps the element in the tree so the fade can run in
 * both directions without @starting-style, and `pointer-events: none` keeps the closed scrim from
 * ever intercepting a click.
 */
.ib-header.is-style-overlay-side-panel::before {
	background-color: rgba(0, 0, 0, 0.8);
	content: "";
	inset: 0;
	opacity: 0;
	pointer-events: none;
	position: fixed;
	visibility: hidden;
	z-index: 1;
}

@media not (prefers-reduced-motion) {
	.ib-header.is-style-overlay-side-panel::before {
		transition: opacity 0.5s cubic-bezier(0.645, 0.045, 0.355, 1),
			visibility 0.5s cubic-bezier(0.645, 0.045, 0.355, 1);
	}
}

html.has-modal-open .ib-header.is-style-overlay-side-panel::before {
	opacity: 1;
	visibility: visible;
}