/*
 * wakefly/mega-menu-panel — the one scoped stylesheet this block needs.
 *
 * Loaded through block.json's `style`/`editorStyle`, so it is enqueued only on a page that
 * renders the block and it is unaffected by the SCRIPT_DEBUG style.css/style.min.css split
 * in functions.php. Same convention as blocks/alert-band/style.css.
 *
 * THREE ELEMENTS, AND ONLY ONE OF THEM PAINTS. The unit contract measures the chain
 * root-last at 1440x900 and 1024x768 (identical at both; the panel does not exist below
 * 992px):
 *
 *   1. div.main-navigation-item-collapse — 500x741, THE ONLY ELEMENT THAT PAINTS.
 *      position absolute, z-index 1000, background #fff, border-top 3px solid #1c3aa9,
 *      box-shadow 0 4px 8px rgba(0,0,0,.1), radius 0, padding 0, margin 0, left 0 (right 0
 *      on the last navigation item). In WordPress this is core/navigation's own
 *      <ul class="wp-block-navigation__submenu-container">, and NONE OF IT IS IN THIS FILE:
 *      the source paints that chrome on every dropdown, not only on one holding this block,
 *      so it belongs to core/navigation and lives in
 *      assets/css/blocks/core-navigation.css. See the ELEMENT 1 note below.
 *   2. div.main-navigation-dropdown — 500x738, transparent, static. It paints nothing and
 *      exists only to re-style the widget inside it. It has no counterpart in the block
 *      model and none is invented.
 *   3. div.navigation-menu-dropdown-content — THIS UNIT'S OWN ROOT, 500x738, transparent,
 *      static, z-index auto, radius 0, padding 0, colour #333, 16px/24px. It has no CSS
 *      rule anywhere in the source's stylesheets — grepped, zero hits. So the ground, the
 *      rule and the shadow must NOT be repeated on the panel; the root carries the width
 *      and nothing else, and render.php emits that from the panelWidth attribute.
 *
 * WHERE 500px COMES FROM: the source's collapse is shrink-to-fit between min-width 300px
 * and max-width 600px and the widest thing in it is the Image widget's fixed
 * `$image-component-width` = 500px. Content-derived, stable at both desktop viewports, not
 * a breakpoint — which is why it is an instance attribute rather than a number here.
 *
 * NO ACTIVE-COLUMN HIGHLIGHT EXISTS, and none is written. All 19 measured descendants
 * compute background rgba(0,0,0,0) and colour rgb(51,51,51); what reads as a column head is
 * that one item has children and its children are indented and smaller. The only state
 * style in the source is :hover, background $light (#f8f9fa) with the colour unchanged.
 *
 * WHAT THIS UNIT'S CONTENT LOOKS LIKE IS NOT HERE. Every visible thing in the panel is an
 * inner block carrying its own measured attributes — core/list at 1rem/700/uppercase with
 * 24px block padding, its nested list at 0.875rem with 12px of extra indent, core/image at
 * aspect-ratio 1 with 24px block margin, core/accordion at headingLevel 5. Those are
 * serialised by whatever places the panel, not declared here.
 */

/*
 * BORDER-BOX, SCOPED TO THIS BLOCK. Same reasoning and the same measurement that put this
 * rule at the top of blocks/alert-band/style.css: neither core nor this theme sets a global
 * box-sizing reset, and core's own `* { box-sizing: border-box }` ships inside the block
 * library stylesheet, which is conditional on which blocks core knows are on the page.
 */
.wp-block-wakefly-mega-menu-panel,
.wp-block-wakefly-mega-menu-panel *,
.wp-block-wakefly-mega-menu-panel *::before,
.wp-block-wakefly-mega-menu-panel *::after {
	box-sizing: border-box;
}

/*
 * ELEMENT 1 — THE CONTAINER — IS NOT STYLED HERE ANY MORE, AND THAT IS THE CORRECTION.
 *
 * This file used to carry the container's ground, 3px rule, shadow, z-index, offset,
 * padding and margin, every one of them scoped with
 * `:has( > .wp-block-wakefly-mega-menu-panel )` on the reasoning that Area 1's plain link
 * submenu "is not this unit". Measurement disproves the premise: the source's three
 * dropdowns are chrome-identical, and it is the CONTAINER that paints them whatever widget
 * is inside — which is what this file's own preamble above already says, and what
 * units/mega-menu-panel.yml's `behaviour` says twice. Area 1 was therefore left with none of
 * it (200x93, z-index 2, `0px none`, no shadow, against a source 300x143 with all four)
 * while Areas 2 and 3 had all of it, from a stylesheet named after a block Area 1 does not
 * contain.
 *
 * The rules now live once, on the block that owns the element, in
 * assets/css/blocks/core-navigation.css. They were NOT copied there — a second copy of four
 * declarations is the defect this repo keeps paying for. Nothing about the container is in
 * this file.
 *
 * WHAT STAYS THIS BLOCK'S: the width it contributes, and how its own content is laid out.
 */

/*
 * ELEMENT 3 — THIS BLOCK'S OWN ROOT. It paints nothing, so the only declarations here are
 * the two the measurement gives (padding 0, margin 0) and the list-style reset the <li>
 * needs: it is a list item only because core's <ul> wrapper requires one — see render.php's
 * header — and the panel is not a bullet. The 24px lives on each child wrapper, which is
 * what stops core's navigation item padding (navigation/style.css:219-222, 0.5em 1em)
 * reintroducing it here.
 *
 * THE WIDTH IS A CUSTOM PROPERTY NOW, NOT AN INLINE `width`, and the change is what lets the
 * panel exist inside the drawer at all. render.php emits `--wf-panel-width` from panelWidth;
 * this file spends it on desktop only. An inline `width: 500px` could not be undone below
 * 992px without `!important`, and 500px inside a 400px drawer is not a panel, it is an
 * overflow. Where the attribute is empty — Area 3, whose width is content-derived and grows
 * when an accordion opens — no custom property is emitted and `auto` is what the container's
 * own min/max-width clamp then acts on.
 */
.wp-block-wakefly-mega-menu-panel {
	margin: 0;
	padding: 0;
	list-style: none;
}

@media (min-width: 992px) {
	.wp-block-wakefly-mega-menu-panel {
		width: var(--wf-panel-width, auto);
	}
}

/*
 * THE TOP-LEVEL LIST IS A FLEX ROW OF TWO CELLS, and this is the rule that makes it one.
 *
 * WHY IT IS BUILT NOW, HAVING BEEN REPORTED AS A GAP BEFORE. The earlier reading treated
 * this as layout — a flex row the source has and the build does not — and declined it on
 * the grounds that core/list declares no layout support (block.json: typography, spacing,
 * color; no `layout`, no `__experimentalLayout`), so honouring it means hand-written CSS
 * for a core block. That reasoning was right about the mechanism and wrong about the
 * stakes. Stacked, the list reads:
 *
 *     Utility 1
 *       Utility 1-1
 *       Utility 1-2
 *     Search
 *
 * — four items down one 500px column, and the only thing separating a child from a sibling
 * is 12px of indent on the nested list. A visitor cannot tell that Search is a SIBLING of
 * Utility 1 rather than a third child of it. That is the menu's information architecture
 * being misstated, not a box being the wrong shape, and it is the same class of defect as
 * a heading level that lies about nesting. Measured in the source: ul 500x142, two li at
 * 142px and 112px side by side; measured here before this rule: ul 500x138, two li at 500px
 * stacked.
 *
 * THE OBJECTION IT WAS DECLINED ON IS ANSWERED BY THE SELECTOR, NOT WAIVED. "One core block
 * rendering unlike every other instance of itself" is a real cost, and the child combinator
 * is what bounds it: this reaches ONLY a list that is a direct child of this block. Every
 * other core/list on the site — including the one inside Area 3's accordion panel, which is
 * not a direct child — is untouched and keeps core's own stacking. It is the same scoping
 * discipline assets/css/blocks/core-post-title.css uses with `card-cta`: name the one place
 * the rule is true rather than the block it happens to be written on.
 *
 * SCOPED BY STRUCTURE, NOT BY A STRING. `> .wp-block-list` is core's own class on the
 * element; no selector here depends on a menu label or an aria-label, both of which are
 * translated and would stop matching on a localised install with no error.
 *
 * ALIGN-ITEMS: FLEX-START so the shorter cell does not stretch to the taller one's height
 * and inherit a hover target it has no content for. NO `gap`: the source's two cells are
 * 142px and 112px in a 500px box and nothing measured the space between them, so the cells
 * size to their content and the remainder stays where the source leaves it.
 *
 * ≥992px ONLY, AND THAT IS THE SOURCE'S OWN BOUNDARY. Until now this rule needed no query,
 * because the panel was display:none below 992 — which is the bug fixed at the foot of this
 * file. The two "columns" are ul.navigation-menu-items being display:flex / flex-direction:
 * row ABOVE 992px (components/_navigation.scss:21-29, .navigation-stacked), as
 * units/mega-menu-panel.yml's `behaviour` records in exactly those words; below it the same
 * list stacks, which is also the only thing that fits a 400px drawer.
 */
@media (min-width: 992px) {
	.wp-block-wakefly-mega-menu-panel > .wp-block-list {
		display: flex;
		flex-direction: row;
		align-items: flex-start;
	}
}

/*
 * THE PANEL'S LINKS ARE BLOCK-LEVEL AND PADDED, WHICH IS THREE FIXES IN ONE DECLARATION.
 *
 * The source's a.navigation-menu-item-link is `display: block` with `padding: 10px 20px`,
 * and its rows measure 44 / 41 / 41. This build's were bare inline <a> at padding 0, 19 / 16
 * / 16 — a 75px shortfall down one column against a 76px shortfall on the whole panel. The
 * same declaration also supplies the 20px indent the top-level links were missing entirely
 * (they started flush against the container's left edge), and it makes the :hover highlight
 * below possible at all.
 *
 * WHAT IS NOT THE DEFECT HERE, so it is not chased: those anchors carry no class of the
 * source's, and they cannot. core/list-item declares `"className": false` in its supports
 * (wp-includes/blocks/list-item/block.json:25), so core is incapable of emitting one, and
 * the anchors themselves are inline rich-text links for which core has no block. This repo's
 * standing convention is that class names need not match the source; the inline unpadded
 * anchor was the defect and the missing class never was.
 *
 * SCOPED TO A LIST ITEM'S OWN ANCHOR, `li > a`, so it reaches the four link rows and not, for
 * instance, a caption's link inside the accordion panel's image.
 *
 * THE :hover HIGHLIGHT, WHICH THIS FILE PREVIOUSLY REPORTED AS A DELIBERATE GAP. The reason
 * given was exact and is now spent: "a.navigation-menu-item-link is block-level there … this
 * build's anchors are inline and the same declaration would paint a text-width strip instead
 * of a row." They are block-level now, so the row is the right shape and the rule is built.
 * #f8f9fa is Bootstrap's $gray-100, which _main-navigation.scss:111-118 uses as $light and
 * which this project does not override (units/mega-menu-panel.yml `behaviour`); the colour is
 * unchanged on hover, and it is NOT in this theme's palette, so it is written as a literal
 * rather than invented as a token — adding a palette entry is wp-theme-scaffold's call.
 *
 * THE SUB-ITEM INDENT IS THE ANCHOR'S OWN padding-left, WHICH IS WHERE THE SOURCE PUTS IT:
 *
 *     .main-navigation-dropdown .navigation-menu-subitems .navigation-menu-item-link {
 *         font-size: .875rem; padding-left: 2rem }
 *
 * and ul.navigation-menu-subitems itself measures `padding: 0px`. Both sides therefore start
 * a sub-item's text 32px in — but only the source's sub-item anchor is as WIDE as its parent
 * (129px, measured on both rows at 1440x900), so its hover strip runs the full row. An indent
 * spent on the <ul> instead narrows the anchor and insets the strip by the same amount.
 * font-size stays a block attribute: `small` is 0.875rem on this theme's ladder exactly.
 */
.wp-block-wakefly-mega-menu-panel .wp-block-list li > a {
	display: block;
	padding: 10px 20px;
	text-decoration: none;
}

.wp-block-wakefly-mega-menu-panel .wp-block-list .wp-block-list li > a {
	padding-left: 2rem;
}

.wp-block-wakefly-mega-menu-panel .wp-block-list li > a:hover,
.wp-block-wakefly-mega-menu-panel .wp-block-list li > a:focus-visible {
	background-color: #f8f9fa;
}

/*
 * AREA 3'S ACCORDION HEADINGS ARE THE SAME SHAPE AND THE SAME SHORTFALL. The source's
 * .accordion-button is `padding: 16px 20px` and its rows measure 52px; core's own toggle is
 * `padding: var(--wp--preset--spacing--20, 1em) 0` (accordion-heading/style.css:14), which on
 * this theme's scale is 4px 0 and measured 32px a row. The 20px also lines the headings up
 * with the panel's links, which start at the same inset.
 */
.wp-block-wakefly-mega-menu-panel .wp-block-accordion-heading__toggle {
	padding: 16px 20px;
}

/*
 * AND ITS DISCLOSURE INDICATOR IS THE SAME IDEA AS THE TRIGGER'S: A CHEVRON THAT ROTATES.
 *
 * The source draws it once, on .accordion-button, from the accordion's own custom properties
 * (frontend/dist/styles/main.css as served, read 2026-09-08):
 *
 *     --bs-accordion-btn-icon-width: 1.25rem;
 *     --bs-accordion-btn-icon-transform: rotate(-180deg);
 *     --bs-accordion-btn-icon-transition: transform 0.2s ease-in-out;
 *     .accordion-button:after { background-image: var(--bs-accordion-btn-icon);
 *         width/height: var(--bs-accordion-btn-icon-width); margin-left: auto }
 *     .accordion-button:not(.collapsed):after {
 *         background-image: var(--bs-accordion-btn-active-icon);
 *         transform: var(--bs-accordion-btn-icon-transform) }
 *
 * Core's own indicator is a literal "+" in a real 24x24 DOM element — a text node, not an
 * icon, and a second idea inside a menu whose other disclosure is a chevron. The heading
 * blocks in patterns/header.php therefore set `showIcon: false`, which stops core rendering
 * that span at all, and the glyph is drawn here the way the source draws it. Both data URIs
 * are the source's own, the second being the copy it fills #fff for the painted state.
 *
 * `[aria-expanded="true"]` is core/accordion's open marker, the same attribute the outer
 * trigger uses; Bootstrap's is the absence of `.collapsed`. 20px is 1.25rem, and it is what
 * makes the header 52px tall against a 19.2px line box — the source's own measurement.
 */
.wp-block-wakefly-mega-menu-panel .wp-block-accordion-heading__toggle::after {
	content: "";
	flex-shrink: 0;
	width: 20px;
	height: 20px;
	margin-left: auto;
	background-image: url("data:image/svg+xml;charset=utf-8,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 16 16' fill='%23333'%3E%3Cpath fill-rule='evenodd' d='M1.646 4.646a.5.5 0 0 1 .708 0L8 10.293l5.646-5.647a.5.5 0 0 1 .708.708l-6 6a.5.5 0 0 1-.708 0l-6-6a.5.5 0 0 1 0-.708z'/%3E%3C/svg%3E");
	background-repeat: no-repeat;
	background-size: 20px;
	transition: transform 0.2s ease-in-out;
}

.wp-block-wakefly-mega-menu-panel
	.wp-block-accordion-heading__toggle[aria-expanded="true"]::after {
	transform: rotate(-180deg);
}

/*
 * AN EXPANDED ACCORDION HEADER IS A SOLID BLUE ROW WITH ITS LABEL AND CHEVRON REVERSED OUT,
 * AND IT WAS TRANSPARENT HERE.
 *
 * MEASURED ON BOTH ORIGINS AT 1440x900, Area 3 driven open and then "Mega Child 2" clicked:
 * the source's expanded `button.accordion-button` (Bootstrap drops `.collapsed`) computes
 * backgroundColor rgb(28, 58, 169) and color rgb(255, 255, 255) on a 298x52 box; the build's
 * `button.wp-block-accordion-heading__toggle[aria-expanded="true"]` computed
 * rgba(0, 0, 0, 0) and rgb(51, 51, 51).
 *
 * THE SOURCE'S RULE IS BOOTSTRAP'S OWN, WITH THIS PROJECT'S TWO OVERRIDES ON IT. Its
 * `.accordion` block declares `--bs-accordion-active-bg: #1c3aa9` and
 * `--bs-accordion-active-color: #fff`, and `.accordion-button:not(.collapsed)` resolves both
 * (frontend/dist/styles/main.css as served). #1c3aa9 is theme.json's `bright-blue` slug
 * exactly — the same one the panel's own 3px top rule and the outer trigger's open tab
 * resolve to — so it is read through the preset custom property rather than restated as hex.
 *
 * THE CHEVRON IS THE THIRD PART AND IS DECLARED SEPARATELY IN THE SOURCE TOO:
 * `--bs-accordion-btn-active-icon` is the same 16-viewBox glyph filled `%23fff` instead of
 * `%23333`. The rotation above is already unconditional on this attribute, so only the fill
 * changes here.
 *
 * NO `box-shadow`. Bootstrap's open rule also sets `inset 0 -1px 0` in the border colour, and
 * it is deliberately not reproduced: measured on the source, an expanded header computes
 * `boxShadow: none`, because a header that has just been clicked is also focused and
 * `.accordion-button:focus` resolves `--bs-accordion-btn-focus-box-shadow`, which this
 * project sets to `none`. Copying the declaration would paint a line the source does not.
 *
 * (0,3,0) with the attribute, against core/accordion's own heading rules at (0,1,0) — one
 * class more than it needs, no !important.
 */
.wp-block-wakefly-mega-menu-panel
	.wp-block-accordion-heading__toggle[aria-expanded="true"] {
	background-color: var(--wp--preset--color--bright-blue);
	color: var(--wp--preset--color--white);
}

.wp-block-wakefly-mega-menu-panel
	.wp-block-accordion-heading__toggle[aria-expanded="true"]::after {
	background-image: url("data:image/svg+xml;charset=utf-8,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 16 16' fill='%23fff'%3E%3Cpath fill-rule='evenodd' d='M1.646 4.646a.5.5 0 0 1 .708 0L8 10.293l5.646-5.647a.5.5 0 0 1 .708.708l-6 6a.5.5 0 0 1-.708 0l-6-6a.5.5 0 0 1 0-.708z'/%3E%3C/svg%3E");
}

/*
 * AND THE ROWS ARE CONTIGUOUS, SEPARATED BY A HAIRLINE RATHER THAN BY A GAP.
 *
 * MEASURED AT 1440x900, Area 3 open, both items shut. Source: the accordion is 300x107 with
 * `div.accordion-item` boxes of 300x54 and 300x53 and headers at y 111 and 164 — 53 apart,
 * which is the 52px header plus ONE border. Build before this rule: 300x128, items 300x52
 * each and headers at y 117 and 193 — 76 apart, a 24px `blockGap` where the source has a 1px
 * line. The same missing border is the whole of why the source's buttons measure 298 and the
 * build's 300: the item's left and right borders take a pixel each off the content box.
 *
 * THE SOURCE'S RULE, AND ITS COLOUR IS ALREADY A SLUG HERE. Bootstrap's
 * `.accordion-item { border: var(--bs-accordion-border-width) solid
 * var(--bs-accordion-border-color) }` computes 1px solid rgb(222, 226, 230) — measured on the
 * source's own items — and #dee2e6 is theme.json's `light-gray`. `border-radius` is not set:
 * the build measures 0 and so does the source, because this project's `--bs-border-radius`
 * resolves to 0 on these items.
 *
 * WHY THIS IS CSS AND NOT A BLOCK ATTRIBUTE, given core/accordion-item declares
 * `__experimentalBorder` with colour, width and style and the ladder says take the rung
 * above. Because the source's second declaration is POSITIONAL —
 * `.accordion-item:not(:first-of-type) { border-top: 0 }` — and a block attribute can only
 * state a border on the two items that exist in patterns/header.php today. The rule has to
 * hold for the third item an editor adds, and `:not(:first-of-type)` is the rule while a pair
 * of hand-written `style.border` payloads would be the sample.
 *
 * THE GAP ITSELF IS NOT HERE. It is `core/accordion`'s own `spacing.blockGap`, set to 0 as a
 * block attribute in patterns/header.php, which is the rung above and needs no CSS.
 */
.wp-block-wakefly-mega-menu-panel .wp-block-accordion-item {
	border: 1px solid var(--wp--preset--color--light-gray);
}

.wp-block-wakefly-mega-menu-panel .wp-block-accordion-item:not(:first-of-type) {
	border-top: 0;
}

/*
 * THE PANEL RENDERS AT EVERY WIDTH, AND THE RULE THAT USED TO STOP IT WAS A REAL,
 * USER-FACING FAILURE — the most serious thing this file has carried.
 *
 * What stood here was `@media (max-width: 991.98px) { .wp-block-wakefly-mega-menu-panel {
 * display: none } }`, on the reading that the source has no panel below 992px. That reading
 * is half right and the half it got wrong is the half that matters. The source has no
 * DESKTOP DROPDOWN below 992px; what it has instead is div#headerOffcanvas, a drawer
 * carrying all three areas WITH THEIR FULL CONTENT — A1 367x140, A2 367x665, A3 367x107 at
 * 768. This rule deleted the content and left core to open the container around it:
 *
 *     at 390, tapping Area 2 or Area 3 opened a 200x0 box — nothing at all;
 *     at 768, they opened as a 200x3 sliver, the 3px being the container's own top rule.
 *
 * Area 1, which was never in this stylesheet's scope, rendered correctly inline the whole
 * time. That is the tell: the drawer was working and this rule was emptying two of the three
 * things in it.
 *
 * WHY REMOVING IT IS ENOUGH, AND WHY NO MECHANISM HAD TO BE INVENTED. Inside core's overlay,
 * core renders every submenu container `position: static; visibility: visible; height: auto;
 * width: auto; min-width: 200px; border: none` and transparent
 * (wp-includes/blocks/navigation/style.css, the `.is-menu-open …
 * .has-child .wp-block-navigation__submenu-container` rule). So the drawer already carries
 * every area's full content, stacked and always open, which is exactly what the source's
 * offcanvas does — one inner-block tree rendered in two places, instead of the source's two
 * copies of the menu in the markup. The remaining half of the boundary — that the desktop
 * bar itself must be gone from 992px down rather than from 600px down, which is core's
 * hard-coded overlay breakpoint — is core/navigation's own business and is answered in
 * assets/css/blocks/core-navigation.css, not here.
 *
 * WHAT THIS FILE STILL DOES AT THE BOUNDARY is confine the two things that ARE desktop-only
 * to ≥992px: the panel's fixed width, and its top-level list being a flex row. Both are
 * queried where they are written, above.
 */