/**
 * PFG Navigation — ONE nested list, two presentations, CSS only.
 *
 * Above 1080px this is a horizontal bar whose Prop Firms item opens a flyout
 * panel; below it, the same markup is a two-level push drawer. The switch is
 * 100% media queries. A JS class toggle after hydration would paint the wrong
 * layout first and cost a layout shift on every mobile load.
 *
 * FIVE CONSTRAINTS CARRIED OVER FROM THE BLOCKS THIS REPLACES. Each was found
 * by shipping the bug first; none is gratuitous:
 *
 * 1. The drawer is `position: absolute`, never `fixed`. The header carries a
 *    backdrop-filter, and a filtered element is the containing block for fixed
 *    descendants — a fixed drawer is trapped inside the header's own box
 *    instead of spanning the viewport. The header is sticky, so absolute
 *    positions against it correctly.
 * 2. The header is lifted to z-index 120 while the drawer is open. The sticky
 *    header is itself a stacking context at z-index 50, so a drawer declaring
 *    120 is scoped to that 50 and the mobile tab bar at 96 paints straight over
 *    it. No z-index on the drawer can fix this from the inside.
 * 3. The flyout is anchored to the sticky HEADER, not to its nav item. This
 *    element is deliberately not `position: relative`: anchoring a 1180px panel
 *    to an item sitting around x=528 pushed it hundreds of pixels off the right
 *    edge.
 * 4. This block is ONE flex child of the header, where the thing it replaces
 *    was `display: contents` with its children carrying explicit `order`. That
 *    is why the ordering problem does not come with it — but the block still
 *    needs its own `order` to land where those children did.
 * 5. The drawer hangs from `--hdr-row-h` (the header's LOGO ROW), not from
 *    `top: 100%` (the header's full height). Below 1080px the vertical switcher
 *    becomes a full-bleed band that is itself a flex child of the header, so
 *    "100% of the header" means "below the Futures/Forex/Crypto band" — the
 *    drawer opened parked underneath it with the band eating the top 70px of
 *    the menu. That was never a stacking failure: the drawer is positioned and
 *    the band is not, so the drawer already wins the paint order. It was a
 *    geometry failure, and raising a z-index would have changed nothing.
 *
 * WHICH SURFACE AN ITEM APPEARS ON is a class from the menu, never a label
 * match: `--drawer` is drawer-only, `--bar` is bar-only. Both surfaces show a
 * different subset of the same list.
 */

/* ---- Shared ---- */

.pfg-nav__list,
.pfg-nav__sub,
.pfg-nav__panellist {
	margin: 0;
	padding: 0;
	list-style: none;
}

.pfg-nav__link {
	display: inline-flex;
	align-items: center;
	gap: 5px;
	text-decoration: none;
	white-space: nowrap;
}

.pfg-nav__toggle {
	display: inline-flex;
	align-items: center;
	padding: 0;
	border: 0;
	background: none;
	color: inherit;
	cursor: pointer;
}

.pfg-nav__chev {
	display: inline-flex;
	transition: transform 150ms ease;
}

/* ================= Desktop bar (≥1080px) ================= */

@media (min-width: 1080px) {
	.pfg-nav {
		/* Distance from the nav row's bottom edge to the panel's top edge —
		   the dead band a pointer crosses on its way into an open panel. Fixed
		   across the desktop range: the header is 135 tall and the nav row sits
		   at 19..55 at both 1080 and 1440. */
		--pfg-nav-bridge: 80px;
		/* Constraint 4: one flex child, ordered where the mega item and the
		   primary nav used to sit (they carried order -2 and -1). */
		order: -1;
		display: flex;
		align-items: center;
		/* Basis ZERO, not auto — the mechanism the primary nav used and the one
		   thing that keeps the header one row tall. With `flex-basis: auto` this
		   item demands its full content width, the header (which wraps) has
		   nowhere to put the utility group, and it drops to a second line,
		   pushing the account block to a third: measured 135 -> 195 at 1100.
		   With basis 0 it never demands space, so it yields and its own list
		   scrolls instead. */
		flex: 1 1 0;
		min-width: 0;
	}

	.pfg-nav__list {
		display: flex;
		align-items: center;
		gap: 14px;
		min-width: 0;
		/* The bar scrolls rather than wraps when the header runs out of room,
		   exactly as the primary nav did between 1080 and 1440. */
		overflow-x: auto;
		scrollbar-width: none;
		-ms-overflow-style: none;
		/*
		 * `overflow-x: auto` forces overflow-y to compute to `auto` as well —
		 * the spec does not allow one axis to clip while the other stays
		 * visible. That clipped the hover bridge dead: the list's box ends with
		 * the nav row at y=55, so a bridge hanging below it was cut off, and a
		 * hit test 1px lower already returned the header.
		 *
		 * Padding extends the clip box; the negative margin takes the space
		 * back, so the layout is byte-identical and only the clip region grows.
		 */
		padding-bottom: var(--pfg-nav-bridge, 80px);
		margin-bottom: calc(var(--pfg-nav-bridge, 80px) * -1);
		/*
		 * THE CLIP BOX MUST NOT BE A HIT TARGET.
		 *
		 * The padding above exists only to enlarge the clip region; it paints
		 * nothing. But padding is part of the element's own hit-test box, and
		 * the header is sticky at z-index 50 while the subnav rail below it is
		 * 49 — so this invisible 80px strip (240px while a menu is open) hung
		 * over the sub-navigation and swallowed its hovers and clicks from the
		 * fourth item rightward. Measured on /futures/: `elementFromPoint`
		 * along the subnav's centreline returned UL.pfg-nav__list for the
		 * whole span the list overlaps.
		 *
		 * So the list itself is inert to the pointer and its children opt back
		 * in (the rule after this one). Everything that must catch a pointer —
		 * links, toggles, the hover bridges on `__link::after`, the panel and
		 * its `::before` band, the flyouts — is a descendant of an item and
		 * inherits `auto` from it. The padding box belongs to the list alone,
		 * so no present or future clip-box growth can intercept input again.
		 */
		pointer-events: none;
	}

	.pfg-nav__list > * {
		pointer-events: auto;
	}

	/*
	 * THE SUBMENU NEEDS MORE CLIP BOX THAN THE BRIDGE DOES, BUT ONLY WHILE OPEN.
	 *
	 * The bridge needs 80px. Submenus hang below the list, so at 80px their
	 * lower items were cut off — the same clipping that ate the panel's right
	 * edge, on the axis nobody looked at.
	 *
	 * Why not simply raise --pfg-nav-bridge: that variable is also the height of
	 * the pointer-ACTIVE hover strip under every flyout trigger (it hangs off
	 * the hovered link and catches real events by design), so it must stay
	 * exactly as tall as the dead band it bridges. The clip box has to be big;
	 * the bridge must not be.
	 *
	 * THE OPEN CLIP IS 100vh, NOT A MEASURED CONSTANT. It was 240px, verified
	 * against a six-item More menu — and the day the menus grew to seven items
	 * (submenu bottom 367, clip box bottom 327) the seventh was cut mid-item.
	 * Any constant here is a bet about the tallest menu an editor will ever
	 * build, and it loses silently. 100vh is categorical: a flyout taller than
	 * the viewport is unusable long before it is clipped.
	 *
	 * Two hazards used to force this value small, and both are gone:
	 *   1. The enlarged padding was an invisible strip swallowing pointer
	 *      events over the page — the list is pointer-events: none now (see
	 *      the rule above; the suite pins it), so the padding hit-tests as
	 *      nothing at any size.
	 *   2. Nothing hidden can leak into the enlarged region — every closed
	 *      flyout and the panel are visibility: hidden, not merely clipped.
	 * It also closes a latent bug the constant had: a flyout taller than the
	 * clip made the list a vertically scrollable box with an invisible
	 * scrollbar, so a wheel over the open menu could drag the whole bar.
	 * The padding box now always contains the flyout, so there is nothing to
	 * scroll.
	 *
	 * Why `:has()` rather than a permanent padding: with the strip inert this
	 * is no longer load-bearing for input, but the closed-state box is also
	 * what the layout inspector shows and what future rules inherit around —
	 * the quiet state stays the honest 80px, and the viewport-sized box
	 * exists only while a menu is open. `:has()` is already used for the
	 * drawer below.
	 */
	.pfg-nav__list:has(.pfg-nav__item--sub:hover),
	.pfg-nav__list:has(.pfg-nav__item--sub:focus-within),
	.pfg-nav__list:has(.pfg-nav__toggle[aria-expanded="true"]) {
		padding-bottom: var(--pfg-nav-subclip, 100vh);
		margin-bottom: calc(var(--pfg-nav-subclip, 100vh) * -1);
	}

	/*
	 * ONE CONTROL PER BREAKPOINT — the desktop half of the rule.
	 *
	 * The drawer's checkbox and its label are mobile controls. Their styling
	 * (the clip-path that hides the input, the chevron on the label) lives
	 * entirely inside the max-width:1079px block, so above 1080 they were
	 * inheriting NOTHING and rendering as a default 13x13 checkbox plus a
	 * second chevron beside the toggle button's own — the square and doubled
	 * arrow in the header. Only the button is a desktop control.
	 *
	 * The drawer's back row is the same kind of thing: a second label for the
	 * mobile checkbox, and a flyout that opens on hover has nothing to go back
	 * from.
	 */
	.pfg-nav__state,
	.pfg-nav__push,
	.pfg-nav__back {
		display: none;
	}

	.pfg-nav__list::-webkit-scrollbar {
		display: none;
	}

	.pfg-nav__item {
		display: inline-flex;
		align-items: center;
		flex: 0 0 auto;
	}

	/* Drawer-only rows never appear in the bar. */
	.pfg-nav__item--drawer {
		display: none;
	}

	.pfg-nav__link {
		padding: 7px 11px;
		border-radius: 9999px;
		color: var(--text-2, #C6CBDD);
		font-size: clamp(13px, 0.8vw, 15px);
		transition: color 150ms ease, background 150ms ease;
	}

	.pfg-nav__item:hover > .pfg-nav__link,
	.pfg-nav__item:focus-within > .pfg-nav__link {
		color: var(--text-1, #F2F3F8);
		background: var(--surface-header-btn, #151823);
	}

	/*
	 * WHERE THERE IS A CHEVRON, THE PILL BELONGS TO THE ITEM, NOT THE LINK.
	 *
	 * The chevron is not inside the link. It is a real <button> BESIDE the real
	 * <a> — one control each, which is the whole point of the pair (see the
	 * `.pfg-nav__toggle` note below). So a background painted on the link can
	 * never reach it. The link's box is intrinsic to its own content, the label,
	 * and padding added to its right edge just pushes the sibling button the
	 * same distance further right — the arrow ends up exactly as far outside the
	 * pill as it started. Measured at 1440 with Prop Firms open: pill (the link)
	 * 532.8..617.3, chevron glyph 611.3..626.3, so 9px of the arrow hung off the
	 * pill onto the bare header. The same 9px on More.
	 *
	 * The item is already the box that spans both — 99.5 wide against the link's
	 * 84.5 — and it was painting nothing. So only the paint moves; no layout
	 * property on the item changes.
	 *
	 * `position: relative` IS NOT PART OF THIS AND MUST NOT BE ADDED. The flyout
	 * panel is a DOM descendant of the item and positions against the HEADER;
	 * making the item a containing block drags the panel up onto the nav row.
	 * That is the trap documented at the hover-bridge rule further down, and a
	 * background needs no positioning to paint.
	 */
	.pfg-nav__item--panel,
	.pfg-nav__item--sub {
		/* The link carried the fade; the item has to carry it now, or the pill
		   pops in where it used to arrive over 150ms. */
		transition: background 150ms ease;
	}

	.pfg-nav__item--panel:hover,
	.pfg-nav__item--panel:focus-within,
	.pfg-nav__item--sub:hover,
	.pfg-nav__item--sub:focus-within {
		border-radius: 9999px;
		background: var(--surface-header-btn, #151823);
	}

	/* ...and the link gives its own up, or a second, shorter pill sits inside
	   the first one with a different right edge. Same specificity as the rule
	   above that sets it, so this has to stay below it. */
	.pfg-nav__item--panel:hover > .pfg-nav__link,
	.pfg-nav__item--panel:focus-within > .pfg-nav__link,
	.pfg-nav__item--sub:hover > .pfg-nav__link,
	.pfg-nav__item--sub:focus-within > .pfg-nav__link {
		background: none;
	}

	/* The row glyph and count are drawer furniture. */
	.pfg-nav__icon,
	.pfg-nav__count {
		display: none;
	}

	/* The disclosure button sits against its link, and the pair reads as one
	   control. The button keeps a real hit area — it is the keyboard path to
	   the panel — but it is drawn as the caret the design shows. */
	.pfg-nav__toggle {
		/* Positioned so it paints ABOVE its link. The link is `position:
		   relative` (the hover bridge hangs off it) and the toggle overlaps it
		   by the 6px margin below, so an unpositioned toggle lost that strip to
		   the link: axe measured a 20x29 target, under the 24px minimum of
		   SC 2.5.8. No offset and no stacking order, so nothing moves. */
		position: relative;
		margin-left: -6px;
		/* 11px on the right to match the link's own 11px on the left, so the pill
		   the item now paints has equal insets at both ends: measured 11px from
		   the pill's left edge to the label, 11px from the chevron to the pill's
		   right edge. It was 6px, which read as a clipped pill once the
		   background reached this far. Costs the item 5px of width. */
		padding: 7px 11px 7px 0;
		border-radius: 9999px;
		color: var(--text-2, #C6CBDD);
	}

	.pfg-nav__item:hover > .pfg-nav__toggle,
	.pfg-nav__item:focus-within > .pfg-nav__toggle {
		color: var(--text-1, #F2F3F8);
	}

	.pfg-nav__item:hover > .pfg-nav__toggle .pfg-nav__chev,
	.pfg-nav__item:focus-within > .pfg-nav__toggle .pfg-nav__chev,
	.pfg-nav__toggle[aria-expanded="true"] .pfg-nav__chev {
		transform: rotate(180deg);
	}

	/* ---- The flyout panel ---- */

	.pfg-nav__panel {
		/* Constraint 3: absolute against the sticky header, centred on it. */
		position: absolute;
		top: 100%;
		left: 50%;
		z-index: 60;
		box-sizing: border-box;
		width: min(1180px, calc(100vw - 32px));
		padding: 18px;
		border-radius: 18px;
		background: var(--surface-1, #14171E);
		border: 1px solid var(--wp--preset--color--grid-line, #2A3040);
		box-shadow: 0 24px 60px rgba(0, 0, 0, 0.5);
		opacity: 0;
		visibility: hidden;
		transform: translate(-50%, -6px);
		transition: opacity 180ms ease, transform 180ms ease, visibility 180ms;
	}

	/*
	 * THE BRIDGE HAS TO BE AS WIDE AS THE PANEL, NOT AS WIDE AS THE TRIGGER.
	 *
	 * The link's own bridge (further down) spans the trigger plus 50px — about
	 * 134px. The panel is 1180px, centred on the header. So the bridge only
	 * covered the narrow column directly under the trigger, and the panel closed
	 * the instant the pointer moved diagonally toward the entry it was actually
	 * heading for. Measured: leaving the trigger at (570,37) for the panel's
	 * left column put the pointer at (507,87), which is over the header's auth
	 * buttons, not over anything belonging to the menu. `item:hover` went false
	 * and the menu shut on the first step of the move.
	 *
	 * Straight down worked, which is why this survived a hover-bridge fix that
	 * was verified by walking straight down.
	 *
	 * Hanging the bridge off the PANEL fixes the width for free: the panel is a
	 * DOM descendant of the item, so anything hovering it keeps the item hovered.
	 * It also costs nothing when closed — a `visibility: hidden` element takes no
	 * pointer events, so this band exists only while the menu is open, and never
	 * sits over the page as dead space the rest of the time.
	 *
	 * HEIGHT IS MEASURED AT RUNTIME AND MUST NOT GO BACK TO A CONSTANT.
	 *
	 * This band grows UPWARD from the panel's top edge, so its height is the only
	 * thing deciding whether it stops below the nav row or swallows it. The
	 * distance it has to cover is `panelTop - navRowBottom`, and the header
	 * DECIDES that distance by wrapping: `.pfg-header` is `flex-wrap: wrap`, so
	 * it is two rows and 135px tall while its children do not fit on one line,
	 * and one row and 75px tall once they do. Measured on the homepage, sweeping
	 * the viewport in 20px steps:
	 *
	 *     1080..1480   header 135   panel top 134   gap 78.95px
	 *     1500..1920   header  75   panel top  74   gap 18.95px
	 *
	 * The constant that used to live here was 72px, verified at 1080 and 1440 —
	 * both of them in the wrapped regime, which is why it read as "fixed across
	 * the desktop range" and was not. It was 7px SHORT below 1500, leaving a hole
	 * the diagonal into the panel fell through (the exact path #10 was about), and
	 * 53px TOO LONG at and above 1500, where a 72px band against a 19px gap
	 * reached from y=2 to y=74 and covered the whole nav row. Measured at 1600
	 * with the panel open, `elementFromPoint` along y=37 returned ONE element for
	 * the entire bar — `Prop Firms[525-1101]` — so every sibling trigger was
	 * inside the open panel's bridge. That is precisely the failure the previous
	 * note here predicted: "a band that reached all the way up into the nav row
	 * would paint over the sibling triggers and steal the hover that opens them".
	 * The panel could then never see a leave, so it never closed, and the row
	 * flipped between the sibling and the panel as the panel opened and shut.
	 *
	 * So the store measures it — `panel.offsetTop` minus the item's bottom, both
	 * against the header, which is the panel's `offsetParent` — and publishes it
	 * as `--pfg-nav-gap` on the nav. See `syncNavGap()` in assets/js/list-nav.js.
	 *
	 * THE FALLBACK IS DELIBERATELY THE SMALL REGIME, NOT THE LARGE ONE. With
	 * scripting off nothing measures anything, so the literal here has to be safe
	 * at the SMALLEST gap the header can produce (18.95px). Too short only costs a
	 * diagonal that closes early; too long costs the whole nav row. Those are not
	 * the same size of mistake, so this errs short.
	 */
	.pfg-nav__panel::before {
		content: "";
		position: absolute;
		bottom: 100%;
		left: 0;
		right: 0;
		height: var(--pfg-nav-gap, 16px);
	}

	/* Opens on hover and focus — zero main-thread work, so it cannot
	   contribute to INP — and on the button's own state, which is what a
	   pointer user clicking rather than hovering gets. */
	.pfg-nav__item--panel:hover > .pfg-nav__panel,
	.pfg-nav__item--panel:focus-within > .pfg-nav__panel,
	.pfg-nav__toggle[aria-expanded="true"] ~ .pfg-nav__panel {
		opacity: 1;
		visibility: visible;
		transform: translate(-50%, 0);
	}

	/*
	 * HOVER BRIDGE.
	 *
	 * The panel is `position: absolute; top: 100%` of the HEADER — its
	 * containing block, because the header is sticky — not of the nav item.
	 * So the panel opens at the header's bottom edge while the item it belongs
	 * to ends with the nav row, measured 73px above it. Moving the pointer from
	 * the link to the panel crosses that dead band, `:hover` drops, and the
	 * panel closes before it can be reached.
	 *
	 * The bridge is the item's own width only. A full-width one would cover the
	 * `.pfg-auth` row that occupies the same band, and swallow its clicks
	 * whenever a menu is open. It exists only while the item is hovered or
	 * focused, so it is never in the way otherwise.
	 *
	 * `--pfg-nav-bridge` is a constant rather than a computed value because the
	 * distance is fixed across the whole desktop range: the header is 135 tall
	 * and the nav row sits at 19..55 at both 1080 and 1440.
	 *
	 * It hangs off the LINK, not the item. Putting `position: relative` on the
	 * item makes the item the panel's containing block — the panel is its
	 * descendant — so `top: 100%` stops meaning "below the header" and starts
	 * meaning "below the 36px item". Measured: the panel jumped up to sit 6px
	 * ABOVE the item's own bottom edge. The link is a SIBLING of the panel, so
	 * making it relative moves nothing.
	 */
	.pfg-nav__item--panel > .pfg-nav__link {
		position: relative;
	}

	.pfg-nav__item--panel:hover > .pfg-nav__link::after,
	.pfg-nav__item--panel:focus-within > .pfg-nav__link::after {
		content: "";
		position: absolute;
		top: 100%;
		left: 0;
		/*
		 * Past the toggle button, so the chevron is inside the bridge too — and
		 * NO FURTHER. The toggle starts 6px inside the link's right edge and is
		 * 26px wide (a 15px chevron plus 11px of right padding), so the item ends
		 * exactly 20px past the link: measured at 1440, link 532.81..617.33,
		 * toggle 611.33..637.33, item 532.81..637.33.
		 *
		 * It was -50px, which is 30px past the item and, with the flex `gap: 14px`
		 * between items, 16px into the NEXT item's column — measured, the strip
		 * x 651.33..667.33 under Futures belonged to Prop Firms while Prop Firms
		 * was hovered. That never reached the nav row itself (this band starts at
		 * the row's bottom edge and grows down), so it was not what stuck the
		 * panel open, but it is a sibling's column and this bridge has no business
		 * in it.
		 */
		right: -20px;
		height: var(--pfg-nav-bridge, 80px);
	}

	/*
	 * THE COLUMN COUNT IS EDITORIAL AND UNBOUNDED, SO NOTHING HERE COUNTS.
	 *
	 * This was `repeat(3, …)` with the outer edges tidied by `:first-child` and
	 * `:last-child`, which is correct for exactly three columns and for no other
	 * number. The panel became a `wp_navigation` menu on 2026-09-14, the owner
	 * added two columns, and all three of those decisions failed at once.
	 * Measured at 1440x900 with five columns:
	 *
	 *   - columns 4 and 5 wrapped to an implicit second row, and the second row
	 *     started 18px to the RIGHT of the first. `:first-child` zeroes the
	 *     padding of DOM child 1; the first column of row 2 is DOM child 4 and
	 *     kept its 18px. Heading text at x=149 on row 1, x=167 on row 2;
	 *   - `:last-child` dropped the right padding and the hairline from column
	 *     5, which sits in the MIDDLE of row 2, so the one separator row 2
	 *     needed was the one that was removed;
	 *   - with no row gap and no rule between them the two rows read as one
	 *     broken grid rather than two rows;
	 *   - the panel was 906.03px tall in a 900px viewport. It is absolute
	 *     against a STICKY header, so page scroll does not reveal the bottom:
	 *     the last row of two columns was permanently unreachable, and 19px of
	 *     the panel was additionally cut by `.pfg-nav__list`'s open clip box.
	 *
	 * THREE RULES NOW, NONE OF WHICH KNOWS N.
	 *
	 * 1. `auto-fit` + a minimum, and the minimum is the one number here worth
	 *    arguing about. The grid divides 1178px at a full-width panel, so 228px
	 *    is the largest floor that still fits FIVE tracks (1178/228 = 5.16) —
	 *    and one row is worth more than any other property this layout has:
	 *    five columns on one row measure 525px tall against 906px wrapped, in a
	 *    900px viewport. Height was the failure, and not wrapping is the fix.
	 *
	 *    WHAT 228 DOES NOT BUY, said plainly: it is NOT wide enough for every
	 *    row to stay on one line. The widest, "Expiring within 30 days · 2
	 *    codes", needs 241px and takes two lines at five across. The floor that
	 *    would hold it is 247px (the longest sub-label), which fits only four
	 *    tracks and puts the panel back over the viewport. A wrapped label in a
	 *    narrow column is legible; an unreachable column is not.
	 *
	 *    Below roughly a 1174px viewport the panel is too narrow for five and
	 *    auto-fit drops to four with no rule to change — which is the honest
	 *    answer at that width rather than a bet.
	 *
	 *    `min(…, 100%)` so a panel narrower than one track still yields one
	 *    column instead of overflowing.
	 *
	 * 2. Hairlines drawn on the LEADING edges and clipped, not on trailing
	 *    edges and exempted. Every column carries a top and a left hairline;
	 *    each is pulled 1px out by a negative margin and the grid's own
	 *    `overflow` cuts the ones that land on the grid's edge. The first
	 *    column of EVERY row sits at grid x=0, and every column of row 1 sits
	 *    at grid y=0, so one clip handles all of them at any N and any wrap —
	 *    including a ragged last row, which paints no line into its empty
	 *    cells because there are no cells there to paint.
	 *
	 *    The grid's own -22px/-18px margins cancel the columns' outer padding,
	 *    so column 1's text still starts on the panel's padding edge and the
	 *    last column's still ends on it. Between rows the arithmetic is
	 *    symmetric by construction: 22px of padding below row 1, the hairline,
	 *    22px above row 2.
	 *
	 * 3. A height bound that is MEASURED, NOT TYPED. `100%` in a percentage
	 *    max-height resolves against the containing block, and this panel's
	 *    containing block is the sticky header (see constraint 3 at the top of
	 *    this file) — so `100vh - 100%` is literally "the viewport below the
	 *    header", and it tracks the header if the header ever changes height
	 *    again. The 72px is air: 32px below the panel plus the 2x18px padding
	 *    that a constant would otherwise have to know about, minus the 4px the
	 *    grid's negative margins take back.
	 *
	 *    THE BOUND IS A GUARANTEE, NOT THE MECHANISM. Rule 1 keeps today's five
	 *    columns on one row and 525px tall, so nothing scrolls; the scroll
	 *    exists so that eight columns, or five at a 1080px viewport, degrade to
	 *    a reachable panel instead of an unreachable one. `overflow` goes on
	 *    the GRID and never on the panel: the panel's `::before` is the hover
	 *    bridge and lives at `bottom: 100%`, outside the panel's padding box,
	 *    so any clip on the panel deletes it and the flyout becomes
	 *    unreachable by pointer.
	 */
	.pfg-nav__panel {
		display: flex;
		flex-direction: column;
		max-height: calc(100vh - 100% - 72px);
	}

	.pfg-nav__grid {
		--pfg-nav-col: 228px;
		display: grid;
		grid-template-columns: repeat(auto-fit, minmax(min(var(--pfg-nav-col), 100%), 1fr));
		/*
		 * THE SEAM BETWEEN WRAPPED ROWS, AND NOTHING ELSE (2026-09-16).
		 *
		 * `auto-fit` wraps past four or five columns, and until now the rows met
		 * flush: measured at 1080 with the five-column fallback, row one ended
		 * at y=976 and row two began at y=976, `row-gap: 0`, with the vertical
		 * hairlines stopping dead mid-panel and the wrapped heading floating
		 * unattached beneath them. The `border-top` that used to cover this was
		 * removed on the owner's instruction, correctly — it also drew a rule
		 * across the whole top of the panel, which is what they were looking at.
		 *
		 * A GAP AND NOT A HAIRLINE, AND THAT IS NOT A PREFERENCE. A rule here
		 * has to be painted by something that spans only where columns exist,
		 * and nothing does: a background on this element shows through wherever
		 * the last row is short. Measured on the five-column case at 1080, where
		 * row two holds one column of five — 784x554px of bare grid, 75% of the
		 * row, flooding `--grid-line` across the panel. A `border-top` on the
		 * column paints on the first row too, which is the rule that was just
		 * removed. So the columns' own edges mark the break and the gap makes
		 * it legible.
		 *
		 * IT COSTS NOTHING WHERE NOTHING WRAPS. With one row of columns this
		 * grid has exactly two tracks — the two bands below — and the only
		 * gutter is the one between them, which `.pfg-nav__col` overrides back
		 * to zero. Three-column production, four-column menu 1155 and the
		 * five-column fallback above 1180px all render byte-identical.
		 */
		column-gap: 0;
		row-gap: 28px;
		/*
		 * TWO BANDS PER ROW OF COLUMNS: the headings, then the bodies.
		 *
		 * 4. Every column subgrids onto this pair, so a heading whose sub-label
		 *    wraps makes the band taller for ALL of them and the lists still
		 *    start on one line. Without it the lists stepped: measured at five
		 *    columns, "Every evaluation, priced as published" took two lines in
		 *    a 235.59px track and started that column's list 15px below its
		 *    neighbours'. The three-column panel never showed this because at
		 *    380px nothing wrapped — which is exactly the kind of thing that
		 *    only appears once the count is editorial.
		 *
		 *    Widening the tracks until sub-labels fit was measured and
		 *    rejected: the longest needs a 247px track and the panel has 1178px
		 *    to divide, so five would not fit — and the next sub-label an editor
		 *    types would break the bet anyway. Sub-labels are sentences. They
		 *    wrap, and the band absorbs it.
		 *
		 *    `auto 1fr` and not `auto auto`: the second band takes the leftover
		 *    height so the hairlines run the full depth of the panel rather than
		 *    stopping under the tallest list.
		 *
		 *    Repeated by `grid-auto-rows` rather than declared by
		 *    `grid-template-rows`, because the number of ROWS is as unknown as
		 *    the number of columns. The pair cycles: auto, 1fr, auto, 1fr.
		 */
		grid-auto-rows: auto 1fr;
		margin: -22px -18px;
		/* `min-height: 0` so this flex item may be shorter than its content —
		   without it a flex item's automatic minimum size is its content and
		   the max-height above has nothing to bite on. */
		min-height: 0;
		overflow: hidden auto;
	}

	/*
	 * A COLUMN IS EXACTLY TWO THINGS — a heading and a body — and that is why
	 * `.pfg-nav__body` exists in the markup.
	 *
	 * A subgrid places its children into the tracks it borrows and has NO
	 * implicit tracks in the subgridded axis: a third child is placed in the
	 * LAST track, on top of whatever is already there. Measured before the
	 * wrapper existed — the "By evidence" column's `.pfg-nav__note` landed in
	 * band 2 with the list and painted over it, its top 10px below the list's
	 * own. Pinning the note to the band's end instead would have parked a
	 * footnote 350px under a two-row list.
	 *
	 * So the block wraps the list and the note in one element, the column has
	 * two children, and the note sits where it always sat: directly under the
	 * rows it explains.
	 *
	 * Browsers without `subgrid` drop the declaration and keep `span 2` against
	 * `auto 1fr`, which collapses band 1 and lays the columns out as they were
	 * before this rule — the pre-existing behaviour, not a broken one.
	 */
	.pfg-nav__col {
		display: grid;
		grid-template-rows: subgrid;
		/* Only the ROW axis is borrowed, so this grid still invents its own
		   single column — and an `auto` one is sized by max-content, which a
		   long firm name would push past the track. `minmax(0, 1fr)` is the
		   same guard `min-width: 0` gives the column itself, one level in. */
		grid-template-columns: minmax(0, 1fr);
		grid-row: span 2;
		min-width: 0;
		/*
		 * A SUBGRID INHERITS ITS PARENT'S GUTTER UNLESS IT SAYS OTHERWISE, and
		 * this one has to say otherwise.
		 *
		 * The parent's `row-gap` exists to separate WRAPPED ROWS. Its tracks
		 * cycle `auto 1fr` — heading, body, heading, body — so an inherited
		 * gutter lands between every heading and its own list as well, which is
		 * inside a column and not a seam at all. Measured at 1080 before this
		 * line: the gap between a heading and its body went from 12px to 13px
		 * across all five columns, one pixel of drift bought nowhere.
		 *
		 * Zero here, so the two bands of a column stay welded and only the
		 * boundary BETWEEN columns of different rows opens up. This is also
		 * what makes the parent's gutter free in the single-row case: with two
		 * tracks and one gutter, and that gutter overridden to zero, the grid
		 * measures exactly as it did before the gutter existed.
		 */
		row-gap: 0;
		/*
		 * NO TOP MARGIN, BECAUSE THERE IS NO TOP BORDER. The -1px used to pull
		 * each column up so its own `border-top` collapsed onto the hairline of
		 * whatever sat above it — the panel edge on the first row, the row above
		 * once the columns wrap. With the border gone the offset would just
		 * shift every column up a pixel.
		 */
		margin: 0 0 0 -1px;
		padding: 22px 18px;
		/*
		 * NAMED IN FULL, for the reason the surface-4 note further down gives
		 * about `--surface-2`: `--grid-line` IS DECLARED NOWHERE. theme.json
		 * emits `--wp--preset--color--grid-line`, and the short name resolves
		 * empty on every element in the page (measured on :root and on this
		 * element). Every hairline in this panel has always painted its
		 * hardcoded fallback, and the fallback happens to equal the token — so
		 * it looked right for the wrong reason and a palette change would have
		 * moved nothing. The remaining short-name references in this file are
		 * the same bug and are left for a sweep rather than fixed piecemeal.
		 */
		/*
		 * THE HORIZONTAL HAIRLINE IS GONE (owner, 2026-09-16). It was a
		 * `border-top` here, and because every column carried one they read as a
		 * single rule across the top of the panel.
		 *
		 * The VERTICAL lines stay: those are `border-left`, and with the -1px
		 * left margin two neighbours share one line rather than painting two.
		 * The leftmost column's own left border falls under the panel edge.
		 *
		 * WORTH KNOWING IF THE PANEL EVER GROWS A SECOND ROW. `.pfg-nav__grid`
		 * is `auto-fit, minmax(228px, 1fr)`, so past four or five columns it
		 * wraps — and this border was also the line between those rows. Without
		 * it wrapped rows meet with nothing between them, which is a different
		 * question from the one being answered here and should be looked at
		 * when a fifth column actually exists.
		 */
		border-left: 1px solid var(--wp--preset--color--grid-line, #2A3040);
	}


	.pfg-nav__note {
		margin: 10px 0 0;
		font-size: 12.5px;
		line-height: 1.55;
		color: var(--text-4, #838A9D);
		max-width: 34ch;
	}

	/* A row whose destination does not exist: laid out like a link, styled as
	   inert — never a link into a 404. */

	/* `.pfg-nav__grid--rail` pinned the grid to four columns while a mock news
	   rail rendered. Nothing has emitted that class since the rail was removed,
	   and a rule that hardcodes a column count is now the one thing the grid
	   above is built not to do — so it is gone rather than left as a loaded
	   gun for whoever re-adds a rail. */

	/* Below the desktop breakpoint the header collapses to the mobile nav, which
	   owns firm navigation there; a hover panel has no meaning on touch. */
	@media (max-width: 1079px) {
		.pfg-mega { display: none; }
	}

	@media (prefers-reduced-motion: reduce) {
		.pfg-nav__panel,
		.pfg-nav__caret {
			transition: none;
		}
	}

	/* ---- Panel lists ----
	   Ported from the mega panel: 1px-gapped rows at 14px with 7px padding and a
	   negative inline margin so the hover state bleeds to the column edge.
	   Without these the rows fell back to default anchor metrics and the tallest
	   column drove the panel 134px too tall. */

	.pfg-nav__panellist {
		display: flex;
		flex-direction: column;
		gap: 1px;
	}

	/* `__norow` is the same row without a link: a firm we cover whose review is
	   not published yet. Same box, same type, no hover and no pointer - the
	   menu must not look ragged where a review is pending, and must not offer
	   an affordance that does nothing. data#461. */
	.pfg-nav__panellist a,
	.pfg-nav__panellist .pfg-nav__norow {
		display: flex;
		align-items: center;
		justify-content: space-between;
		gap: 12px;
		padding: 7px 9px;
		margin: 0 -9px;
		border-radius: 8px;
		color: var(--text-2, #C6CBDD);
		text-decoration: none;
		font-size: 14px;
		transition: color 150ms ease, background 150ms ease;
	}

	.pfg-nav__panellist .pfg-nav__norow {
		cursor: default;
		color: var(--text-3, #979CAD);
	}

	/*
	 * THE DEEPER LEVEL HOVERS ONE STEP HIGHER THAN THE BAR.
	 *
	 * surface-4, not surface-2, and named in full. `var(--surface-2, …)` was a
	 * reference to a custom property that IS DECLARED NOWHERE — theme.json emits
	 * `--wp--preset--color--surface-2`, and the short `--surface-2` resolves
	 * empty on every element in the page (measured on :root and on this anchor).
	 * The rule had always been painting its hardcoded fallback, and the fallback
	 * happened to equal the token, so the result looked right for the wrong
	 * reason and a change to the palette would have moved nothing here.
	 *
	 * The fallback stays because theme.json presets are not guaranteed in every
	 * render context, and it MUST track theme.json's surface-4 (#1A1F2C) — if
	 * that palette entry moves, this hex moves with it.
	 */
	.pfg-nav__panellist a:hover,
	.pfg-nav__panellist a:focus-visible {
		color: var(--text-1, #F2F3F8);
		background: var(--wp--preset--color--surface-4, #1A1F2C);
	}

	.pfg-nav__tag {
		flex: 0 0 auto;
		font-size: 11.5px;
		letter-spacing: 0.06em;
		color: var(--text-4, #838A9D);
		font-variant-numeric: tabular-nums;
	}

	.pfg-nav__h {
		display: flex;
		flex-direction: column;
		gap: 2px;
		margin: 0 0 12px;
		/*
		 * Pinned, for the same reason .pfg-footer__label pins its own:
		 * theme.json sets line-height PER ELEMENT, and this label is styled by
		 * class. It was an <h2> until the Wave 3 heading fix demoted it to a <p>
		 * (four panel headings preceded the page's <h1>), and <p> resolves to
		 * 1.7 where h2 resolves to 1.16 — which grew the open panel from 499.19
		 * to 508.75. A label's size must not depend on its tag.
		 */
		line-height: 1.16;
		font-family: var(--wp--preset--font-family--display, "Outfit", sans-serif);
		font-weight: 500;
		font-size: 16px;
		color: var(--text-1, #F2F3F8);
	}

	.pfg-nav__sub-h {
		font-family: var(--wp--preset--font-family--body, "Manrope", sans-serif);
		font-weight: 400;
		font-size: 12.5px;
		color: var(--text-4, #838A9D);
	}

	/* ---- The More submenu ---- */

	/*
	 * TWO THINGS CLIPPED THIS, AND NEITHER WAS THE VIEWPORT.
	 *
	 * `.pfg-nav__list` is `overflow-x: auto` so the bar scrolls instead of
	 * wrapping, and the submenu is positioned inside it. `left: 0` opened it
	 * rightward from an item that is the LAST in the bar, so it ran straight off
	 * the list's right edge and was cut: "How we grade" rendered as "How we g".
	 * Below it, the list's clip box ended 80px down, so the bottom two entries
	 * were gone as well. Two axes, one screenshot, and the horizontal one is the
	 * only one you notice.
	 *
	 * Opening it LEFTWARD from the last item solves the horizontal half without
	 * moving the containing block: the panel now grows back along the bar it
	 * already lives in, so it is inside the clip box by construction rather than
	 * by arithmetic. Measured at 1080/1200/1366/1440/1920 with the bar scrolled
	 * to bring More into reach — the panel sits inside the list's box at every
	 * one.
	 *
	 * Anchoring it to the sticky header instead — the trick the flyout panel
	 * uses to escape this same clip — was tried and is wrong here. The flyout is
	 * 1180px and centred on the header, so the header IS its reference. This
	 * panel is 204px and belongs under a specific trigger, and the nav does not
	 * end where the header ends: measured at 1440, header-anchored put it at
	 * x=1202 while its trigger sat at x=985. Right for that panel, adrift for
	 * this one.
	 */
	.pfg-nav__sub {
		position: absolute;
		top: 100%;
		left: auto;
		right: 0;
		z-index: 60;
		min-width: 190px;
		padding: 6px;
		border-radius: 14px;
		background: var(--surface-1, #14171E);
		border: 1px solid var(--wp--preset--color--grid-line, #2A3040);
		box-shadow: 0 18px 40px rgba(0, 0, 0, 0.45);
		opacity: 0;
		visibility: hidden;
		transition: opacity 150ms ease, visibility 150ms;
	}

	.pfg-nav__item--sub {
		position: relative;
	}

	/*
	 * NO HOVER BRIDGE HERE, deliberately.
	 *
	 * The flyout panel needs one because it hangs off the HEADER's bottom edge,
	 * leaving ~80px of dead space between trigger and panel. This one is
	 * anchored to its own item, so `top: 100%` puts its top edge exactly on the
	 * item's bottom edge — measured, item ends at y=55 and the panel starts at
	 * y=55. There is no gap to cross.
	 *
	 * Adding one anyway would be actively harmful: an 80px invisible strip
	 * starting at the item's bottom would lie directly over the panel's own
	 * links and eat the clicks it was meant to protect.
	 */

	.pfg-nav__item--sub:hover > .pfg-nav__sub,
	.pfg-nav__item--sub:focus-within > .pfg-nav__sub,
	.pfg-nav__toggle[aria-expanded="true"] ~ .pfg-nav__sub {
		opacity: 1;
		visibility: visible;
	}

	/*
	 * DISMISSED BY THE READER. Escape, or the chevron pressed while the panel
	 * is showing, stamps `data-pfg-nav-dismissed` on the item, and that wins
	 * over hover and focus-within until both have left the item (the store in
	 * assets/js/list-nav.js lifts it). Without this a flyout opened by focus
	 * could not be put away without moving focus, which SC 1.4.13 requires.
	 * Same specificity as the open rules above, so it has to stay below them.
	 */
	.pfg-nav__item--panel[data-pfg-nav-dismissed] > .pfg-nav__panel {
		opacity: 0;
		visibility: hidden;
		transform: translate(-50%, -6px);
	}

	.pfg-nav__item--sub[data-pfg-nav-dismissed] > .pfg-nav__sub {
		opacity: 0;
		visibility: hidden;
	}

	.pfg-nav__item[data-pfg-nav-dismissed] > .pfg-nav__toggle .pfg-nav__chev {
		transform: none;
	}

	.pfg-nav__item--child {
		display: block;
	}

	.pfg-nav__item--child > .pfg-nav__link {
		display: flex;
		padding: 8px 10px;
		border-radius: 9px;
		font-size: 13.5px;
	}
}

/* ================= Mobile drawer (≤1079px) ================= */

@media (max-width: 1079px) {
	.pfg-nav {
		/* Constraint 1: ABSOLUTE, never fixed. */
		position: absolute;
		/* Constraint 5: the LOGO ROW, not the whole header. `top: 100%` put the
		   drawer below the full-bleed vertical-switcher band, which is a flex
		   child of the header at this width. Hanging from --hdr-row-h instead
		   lets the drawer cover the band, which is what "the menu is open"
		   should look like. --hdr-row-h is pinned in the theme's components.css
		   next to --hdr-h, the same way that contract is already kept. */
		top: var(--hdr-row-h, 70px);
		left: 0;
		/* Constraint 2's other half: over the cookie notice (90) and the
		   mobile tab bar (96). The header itself is lifted in components.css,
		   or this number is scoped to the header's own 50 and does nothing. */
		z-index: 120;
		/* Deliberately NOT border-box: the drawer this replaces was 330px wide
		   PLUS its 1px right border, so content-box keeps it 331px overall. */
		height: calc(100dvh - var(--hdr-row-h, 70px));
		width: min(330px, 88vw);
		background: var(--surface-1, #14171E);
		border-right: 1px solid var(--wp--preset--color--grid-line, #2A3040);
		overflow: hidden;
		transform: translateX(-101%);
		visibility: hidden;
		transition: transform 240ms cubic-bezier(0.22, 1, 0.36, 1), visibility 240ms;
	}

	/* Opened by the theme's existing burger checkbox, which stays the state
	   holder so the drawer still opens with no JavaScript. The store only
	   mirrors aria-expanded onto it. */
	.pfg-header:has(.pfg-burger:checked) .pfg-nav {
		transform: translateX(0);
		visibility: visible;
	}

	/*
	 * THE LIST SCROLLS. IT MUST NOT ALSO BE THE SLIDER.
	 *
	 * It used to be both — `position: relative` + `overflow-y: auto` + a
	 * `translateX(-100%)` on the open state, with level two absolutely
	 * positioned at `left: 100%` INSIDE it. That combination erased level two
	 * completely, and it is the whole of the blank-drawer bug:
	 *
	 *   - `overflow-y: auto` forces `overflow-x` to compute to `auto` as well;
	 *     the spec does not allow one axis to clip while the other stays
	 *     visible. (The desktop bar hit the same rule twice — see the bridge
	 *     and the More submenu above.)
	 *   - The list was the panel's containing block, both as the nearest
	 *     positioned ancestor and, once open, as a transformed element. Either
	 *     one alone is enough.
	 *   - So the panel sat at 330..660 in a box that clips at 0..330 and was
	 *     clipped out of paint AND out of hit testing. Measured: list
	 *     scrollWidth 660 / clientWidth 330, panel getBoundingClientRect
	 *     (0,70) 330x774 with `visibility: visible`, and `elementFromPoint`
	 *     over every point inside its own box returning `.pfg-nav` itself.
	 *     Correct geometry, correct computed styles, nothing painted — an
	 *     empty drawer.
	 *
	 * The fix is to take the slide off this element. Level one slides by
	 * translating its ROWS; level two hangs off `.pfg-nav` (which is
	 * `position: absolute` here and is never transformed) and slides itself.
	 * A `position: absolute` box whose containing block is an ANCESTOR of a
	 * scroll container escapes that container's clip, so level two is no
	 * longer inside a box that ends at the drawer's right edge.
	 *
	 * Do not put `position: relative` or a transform back on this element.
	 * Either re-captures the panel and the drawer goes blank again.
	 */
	.pfg-nav__list {
		height: 100%;
		overflow-y: auto;
		-webkit-overflow-scrolling: touch;
		padding: 16px 14px calc(24px + env(safe-area-inset-bottom, 0px));
		display: flex;
		flex-direction: column;
		gap: 6px;
	}

	/* Focusable but not drawn — the label beside it is the visible control.
	   Same treatment the drawer's old state checkbox had. */
	.pfg-nav__state {
		position: absolute;
		width: 1px;
		height: 1px;
		margin: -1px;
		padding: 0;
		border: 0;
		clip-path: inset(50%);
		overflow: hidden;
		white-space: nowrap;
	}

	/* The desktop button is not reachable here. */
	.pfg-nav__toggle {
		display: none;
	}

	/*
	 * THE WHOLE ROW DRILLS DOWN, not the last 56px of it.
	 *
	 * This was a 56px right-hand square floated back over the row, and the
	 * comment further down claimed it "covers it, so the whole row opens the
	 * sub-level". It never did, on two counts:
	 *
	 *   - 56 of the row's 302px. Measured at 390: the row spans x 14..316 and
	 *     the label spans 260..316, so 81% of a row wearing a disclosure
	 *     chevron navigated to /firms/ instead of disclosing anything.
	 *   - Even at full width a bare float would not have worked. A
	 *     non-positioned float paints BELOW the inline content of in-flow
	 *     descendants (CSS 2.1 Appendix E, steps 4 vs 7), so the link's icon,
	 *     label and count still took the hits — `elementFromPoint` returned
	 *     `SPAN.pfg-nav__label` right across the middle of the row. That is
	 *     why it only appeared to work in the 56px the link's text could not
	 *     reach, which is exactly the region `padding-right: 56px` reserves.
	 *
	 * So it is a positioned overlay, not a float: `position: relative` puts it
	 * in the positioned-descendant paint step, above every in-flow box in the
	 * row. The negative margin pulls it back over the link it follows; the
	 * link stays in flow and keeps setting the row's height.
	 *
	 * The <a> underneath is unreachable by pointer at this breakpoint, and that
	 * is the intent: a row with a chevron should disclose. Its destination is
	 * not lost — the panel it opens carries a link to /firms/ itself — and the
	 * link stays in the DOM, in the tab order and in the accessibility tree, so
	 * the "link plus adjacent disclosure" pairing assistive tech expects is
	 * intact.
	 *
	 * SINCE #530 IT DISCLOSES IN PLACE. The row no longer leaves the screen
	 * when it opens, so this overlay is also what CLOSES the panel again: it is
	 * the one control, tapped twice. While the panel was a second screen the
	 * row was hidden on open and a separate Back label did the closing.
	 */
	.pfg-nav__push {
		position: relative;
		z-index: 1;
		display: flex;
		align-items: center;
		justify-content: flex-end;
		box-sizing: border-box;
		width: 100%;
		height: 64px;
		margin-top: -64px;
		padding-right: 12px;
		border-radius: 12px;
		color: var(--text-4, #838A9D);
		cursor: pointer;
	}

	/* DOWN, and 180 when open — the shape for an accordion that expands in
	   place, which is now exactly what this row does (data#530).

	   It pointed RIGHT while the panel was a second screen, because a chevron
	   should point the way the row travels and the row travelled sideways.
	   Nothing travels sideways any more, so a right-pointing caret would
	   promise a drilldown that no longer exists. This is the same pair the
	   desktop toggle already uses: natural orientation closed, rotate(180deg)
	   open, one decision at both breakpoints. */
	.pfg-nav__push .pfg-nav__chev {
		transform: none;
	}

	.pfg-nav__state:checked ~ .pfg-nav__push .pfg-nav__chev {
		transform: rotate(180deg);
	}

	/* A focus ring on the hidden checkbox has to show on its visible label. */
	.pfg-nav__state:focus-visible + .pfg-nav__push {
		outline: 2px solid var(--acc, #A79FFF);
		outline-offset: -2px;
	}

	/* Bar-only rows never appear in the drawer. Scoped through .pfg-nav so it
	   out-specifies the .pfg-nav__item display rule further down — equal
	   specificity would lose on source order and leak Comparisons and Privacy
	   into the drawer.

	   A parent with children is exempt: "More" is bar-only as a ROW, but the
	   drawer still shows its children as flat rows, and hiding the <li> would
	   take the whole subtree with it. Its own link and toggle are hidden
	   separately below. */
	.pfg-nav .pfg-nav__item--bar:not(.pfg-nav__item--sub) {
		display: none;
	}

	/* More's children flatten into the drawer as ordinary rows — the drawer
	   has no "More" row today, and its three children are top-level there. */
	.pfg-nav__item--sub > .pfg-nav__link,
	.pfg-nav__item--sub > .pfg-nav__toggle {
		display: none;
	}

	.pfg-nav__sub {
		display: flex;
		flex-direction: column;
		gap: 6px;
	}

	/* NOTHING IN THE DRAWER SLIDES SIDEWAYS ANY MORE.
	   Each row used to be its own slider, because the panel was a second
	   screen and the list could not carry the push itself. The panel is in
	   flow now, so the rows stay where they are and there is no transform
	   here to make a containing block out of. */
	.pfg-nav__item {
		display: block;
		flex: 0 0 auto;
	}

	.pfg-nav__link {
		display: flex;
		align-items: center;
		gap: 11px;
		width: 100%;
		box-sizing: border-box;
		min-height: 64px;
		padding: 0 12px;
		border-radius: 12px;
		color: var(--text-2, #C6CBDD);
		font-size: 15px;
		transition: background 150ms ease, color 150ms ease;
	}

	.pfg-nav__link:hover,
	.pfg-nav__link:focus-visible {
		background: var(--surface-header-btn, #151823);
		color: var(--text-1, #F2F3F8);
	}


	/* A row whose section is do-not-publish: laid out like a link, inert. */
	.pfg-nav__link--dead,
	.pfg-nav__link--dead:hover {
		background: transparent;
		color: var(--text-4, #838A9D);
		cursor: default;
	}

	/* The design's guest block: "Welcome, trader" + a pill CTA, disabled until
	   accounts exist. */

	.pfg-nav__mocknote {
		display: flex;
		align-items: center;
		gap: 7px;
		font-size: 11.5px;
		color: var(--text-4, #838A9D);
	}

	.pfg-nav__label {
		flex: 1 1 auto;
		min-width: 0;
	}

	.pfg-nav__icon {
		display: inline-flex;
		flex: 0 0 auto;
		color: var(--text-4, #838A9D);
	}

	.pfg-nav__count {
		flex: 0 0 auto;
		font-size: 12.5px;
		color: var(--text-4, #838A9D);
		font-variant-numeric: tabular-nums;
	}

	/* The label text stops short of the chevron. The disclosure overlay covers
	   the whole row, so this is about the row not reading as a collision — not
	   about leaving the chevron a hit area of its own. */
	.pfg-nav__item--panel > .pfg-nav__link {
		padding-right: 56px;
	}

	/* ---- The panel, IN FLOW ---- */

	/*
	 * ONE SCREEN, NOT TWO (data#530, owner 2026-09-16).
	 *
	 * This was a push drawer: the panel sat at `left: 100%`, level one slid
	 * out under `translateX(-101%)`, and the reader arrived on a second
	 * screen with a Back affordance as the only way home. #530 asks for the
	 * opposite shape in as many words — "the same links, stacked, on one
	 * screen", market name as a section heading with its pages beneath, All
	 * markets last, "no horizontal scrolling and no nested drilldown".
	 *
	 * So the panel is now an ordinary in-flow disclosure inside its own <li>.
	 * It opens DOWNWARD under the row that owns it, the row stays on screen
	 * and stays the control that closes it again, and the drawer's own list
	 * is the only thing that scrolls. Nothing is off-canvas, so nothing needs
	 * a way back.
	 *
	 * THE CHECKBOX STILL DRIVES IT, unchanged, and that is the point of
	 * keeping it: CSS cannot write attributes, so a <button> here would make
	 * the whole panel unopenable with scripting off. `:has(…:checked)` needs
	 * no script. The store layers role/aria-expanded/aria-controls on top.
	 *
	 * WHAT THE OLD SHAPE'S HAZARD WAS, and why it is gone. The long note that
	 * stood here explained that the panel had to hang off `.pfg-nav` rather
	 * than off the list, because the list is a scroll container whose clip box
	 * ended at the drawer's right edge and erased anything sitting at
	 * `left: 100%`. In flow there is no horizontal offset to be clipped, so
	 * that entire failure mode — and the rule that the list must never be
	 * positioned or transformed — stops being load-bearing here. The list
	 * rule is still worth keeping (see its own note); it is no longer the
	 * difference between a working drawer and a blank one.
	 *
	 * A GRID WITH ONE ROW is how it animates. `height: auto` is not
	 * interpolable and a max-height guess is either a clipped panel or a
	 * lazy-looking ease on a short one; `grid-template-rows: 0fr → 1fr`
	 * measures the content itself. The single grid item is `.pfg-nav__grid`
	 * — `.pfg-nav__back` is `display: none` below and so generates no box.
	 *
	 * `visibility: hidden` IS NOT DECORATION. It is what keeps a collapsed
	 * panel's links out of the tab order with no JavaScript at all; `0fr`
	 * plus `overflow: hidden` would leave fourteen invisible links tabbable
	 * for anyone browsing with scripting off. The store adds `inert` on top,
	 * which also takes them out of the accessibility tree.
	 */
	.pfg-nav__panel {
		display: grid;
		grid-template-rows: 0fr;
		/* ON THE CONTAINER AS WELL AS ON THE ITEM, and not redundantly. The
		   item below carries a hairline top and bottom; a border paints on a
		   zero-height box, so a collapsed panel whose only clip was the item's
		   own `overflow` would still show 2px of rule under the row. Clipping
		   at the container is what makes "collapsed" mean zero pixels. */
		overflow: hidden;
		visibility: hidden;
		transition: grid-template-rows 240ms cubic-bezier(0.22, 1, 0.36, 1), visibility 240ms;
	}

	/* The animated child. `min-height: 0` is what lets a grid item be smaller
	   than its content — without it the track collapses to 0fr and the content
	   overflows it at full height, which is the whole trick failing silently. */
	.pfg-nav__panel > .pfg-nav__grid {
		min-height: 0;
		overflow: hidden;
	}

	/* Driven by the CHECKBOX, not by aria-expanded: CSS cannot write
	   attributes, so keying this off aria-expanded would make the panel
	   impossible to open with scripting off. The checkbox needs no script;
	   the store adds the ARIA on top. */
	.pfg-nav__list:has(.pfg-nav__state:checked) .pfg-nav__panel {
		grid-template-rows: 1fr;
		visibility: visible;
	}

	/* THE WAY BACK IS GONE BECAUSE THERE IS NOWHERE TO COME BACK FROM.
	   It existed because the panel was a second screen with the burger behind
	   it rather than above it, on a device with no Escape key. In flow the row
	   that opened the panel is still on screen, directly above its own
	   sections, and tapping it again closes them — so a second labelled hit
	   area for the same checkbox would be a control for a journey nobody
	   takes.

	   HIDDEN, NOT DELETED. The markup still ships it because the desktop
	   flyout does not use it either and the element costs one <label>; taking
	   it out of render.php is a separate change with its own test to move.
	   `display: none` keeps it out of the tab order as well as out of sight. */
	.pfg-nav__back {
		display: none;
	}

	/*
	 * NOTHING ON THIS ELEMENT BUT THE STACK. No padding, no border, no margin,
	 * and that is a constraint the animation imposes rather than a style
	 * choice.
	 *
	 * `min-height: 0` zeroes an item's CONTENT contribution to a `0fr` track.
	 * It does not zero the item's padding or borders, which are part of the
	 * same border box and go on being 34px of it. Measured with the rules and
	 * the 16px insets on this element: a collapsed panel stood 34px tall and
	 * pushed "How we grade" 34px down the drawer — a visible gap under a row
	 * that is supposed to be shut.
	 *
	 * So every pixel of the expanded block's decoration lives on the sections
	 * instead, where it is inside the content box the track measures and
	 * collapses with it. See .pfg-nav__col below.
	 */
	.pfg-nav__grid {
		display: flex;
		flex-direction: column;
		/* Zero, because each section now carries its own air on both sides of
		   its own rule. A gap here would be a third source of vertical space
		   between two sections that already agree on 16 and 16. */
		gap: 0;
		margin: 0;
		padding: 0;
		border: 0;
	}

	/*
	 * The same hairline the desktop panel draws BETWEEN its columns, turned
	 * through ninety degrees because the columns stack here. Borders over
	 * shadows, and the same --grid-line token, so the drawer's section breaks
	 * and the flyout's column breaks are one decision rather than two.
	 *
	 * Before this the only thing separating "By evidence" from the directory
	 * list above it was 6px of gap and a small caps label, which is why nine
	 * firm rows, a paragraph and three deal rows read as one undifferentiated
	 * column.
	 *
	 * EVERY SECTION, NOT ONLY THE ONES AFTER THE FIRST (#530). This was
	 * `.pfg-nav__col + .pfg-nav__col`, which is right while the panel is a
	 * screen of its own — the first section needs no rule above it when there
	 * is nothing above it. In flow the first section abuts the drawer row that
	 * discloses it, and the last abuts the row after, so the expanded block
	 * has to say where it starts and where it stops or fourteen links read as
	 * a continuation of the four they interrupt.
	 *
	 * ON THE SECTIONS AND NOT ON .pfg-nav__grid, which would be the obvious
	 * place for two rules bounding a block: the grid is the animated item and
	 * its padding and borders survive the collapse. See its note above.
	 */
	.pfg-nav__col {
		min-width: 0;
		padding: 16px 0;
		border-top: 1px solid var(--wp--preset--color--grid-line, #2A3040);
	}

	.pfg-nav__col:last-child {
		border-bottom: 1px solid var(--wp--preset--color--grid-line, #2A3040);
	}

	.pfg-nav__h {
		display: flex;
		flex-direction: column;
		gap: 3px;
		margin: 0 0 10px;
		/*
		 * 12px, which is the rows' own inline padding. It was 6px, so every
		 * section label sat exactly 6px to the LEFT of the names it
		 * introduces — measured at 390: heading text at x=20, row text at
		 * x=26. A label that does not line up with its list reads as a
		 * different column.
		 */
		padding: 0 12px;
		font-size: 10.5px;
		font-weight: 800;
		letter-spacing: 0.14em;
		text-transform: uppercase;
		color: var(--text-label, #828BA6);
	}

	/*
	 * The second line is a subtitle, not a second heading.
	 *
	 * The desktop panel styles this span separately; the drawer never did, so
	 * it inherited the label's caps, 800 weight and 0.14em tracking and "36
	 * firms on record" shouted as loudly as "Directory" — two all-caps lines
	 * above every section, and the source copy's sentence case thrown away by
	 * a text-transform it was never meant to be under. design.md: sentence
	 * case.
	 */
	.pfg-nav__sub-h {
		font-family: var(--wp--preset--font-family--body, "Manrope", sans-serif);
		font-weight: 400;
		font-size: 12px;
		letter-spacing: 0;
		text-transform: none;
		color: var(--text-4, #838A9D);
	}

	/* Desktop gives the list a flex column; the drawer got nothing, so its
	   rows were bare block <li>s. 2px, because the rows carry a 12px radius
	   and a hover fill that needs to not touch its neighbour. */
	.pfg-nav__panellist {
		display: flex;
		flex-direction: column;
		gap: 2px;
	}

	/*
	 * BOTH ELEMENTS, THE WAY THE DESKTOP RULE HAS ALWAYS DONE IT.
	 *
	 * This selector was `a` alone. A firm whose review is not published
	 * renders as `<span class="pfg-nav__norow">` rather than an `<a>` — on
	 * purpose, so a reader never meets a 404 (data#461) — and that span
	 * therefore got NO ROW LAYOUT AT ALL at this breakpoint.
	 *
	 * Measured before the fix, on the same list: the linked row was
	 * display:flex, full column width, 64px tall, its name starting 12px in
	 * and its market tag pushed to the right edge; the unlinked one was
	 * display:inline, 19px tall, its name flush at the column edge and the
	 * tag running straight on after it. Five of the nine directory rows are
	 * unlinked today, interleaved with the four that are not — a 45px height
	 * difference and a 12px indent difference, alternating down the column.
	 * That is the whole of the random vertical rhythm and most of the "hard
	 * to read".
	 *
	 * The desktop rule near the top of this file has covered both since it
	 * was written. This is that rule, one breakpoint later.
	 */
	.pfg-nav__panellist a,
	.pfg-nav__panellist .pfg-nav__norow {
		display: flex;
		align-items: center;
		justify-content: space-between;
		gap: 11px;
		box-sizing: border-box;
		width: 100%;
		/*
		 * 52, not the 64 level one uses. Level one is seven destinations with
		 * icons; this is a fourteen-row directory, and at 64 only nine of
		 * them fit a 390x844 phone with the panel already scrolling 1085 into
		 * 774. 52 clears the 44px touch minimum with room to spare and turns
		 * a stack of buttons back into a list. The vertical padding is what
		 * keeps a name that wraps to two lines off the row's edges.
		 */
		min-height: 52px;
		padding: 7px 12px;
		border-radius: 12px;
		color: var(--text-2, #C6CBDD);
		font-size: 15px;
		text-decoration: none;
	}

	/*
	 * Not a link, not clickable, and it must not wear a link's colour — but
	 * it keeps the row box, because the absence of one was the defect. One
	 * step down the text ramp, no hover, no pointer: the same decision the
	 * desktop panel already made for this element, with the same token, so
	 * the two breakpoints do not disagree about what "pending" looks like.
	 */
	.pfg-nav__panellist .pfg-nav__norow {
		cursor: default;
		color: var(--text-3, #979CAD);
	}

	/* ...and the tag comes with it, so the whole unlinked row sits at one
	   uniform step back rather than being dimmed at the left end only. */
	.pfg-nav__panellist .pfg-nav__norow .pfg-nav__tag {
		color: inherit;
	}

	.pfg-nav__panellist a:hover,
	.pfg-nav__panellist a:focus-visible {
		background: var(--surface-header-btn, #151823);
		color: var(--text-1, #F2F3F8);
	}

	/* A background swap alone is a weak focus indicator here: #151823 differs
	   from the panel's #14171E by single RGB units, which is enough to read
	   as hover and not enough to find with a keyboard. Same ring
	   .pfg-nav__state:focus-visible already draws on its visible label. */
	.pfg-nav__panellist a:focus-visible {
		outline: 2px solid var(--acc, #A79FFF);
		outline-offset: -2px;
	}

	.pfg-nav__firmname {
		flex: 1 1 auto;
		min-width: 0;
	}

	/*
	 * Three to nine characters of all-caps abbreviation at the right edge of
	 * a 290px drawer. Tracking is what makes those legible at this size — the
	 * desktop rule has carried 0.06em since it was written and the drawer's
	 * copy of it dropped both the tracking and the tabular figures. Tabular
	 * matters on the numeric tags (a count, a percentage) so they stop
	 * shifting width row to row.
	 *
	 * text-3 rather than text-4: 6.5:1 on surface-1 against 5.2:1, and this
	 * is the smallest functional text anywhere in the drawer.
	 */
	.pfg-nav__tag {
		flex: 0 0 auto;
		font-size: 12px;
		letter-spacing: 0.06em;
		font-variant-numeric: tabular-nums;
		color: var(--text-3, #979CAD);
	}

	/*
	 * No drawer rule existed for this at all — the desktop one is scoped to
	 * the flyout — so the paragraph fell back to raw <p> metrics: measured
	 * 14.5px set across the full column, flush to the column edge and so 12px
	 * left of every row above it, four lines and 99px tall at 390. Body copy
	 * in a 330px drawer. Same indent as the rows, and the size and leading
	 * the desktop panel already gives it.
	 */
	.pfg-nav__note {
		margin: 4px 0 0;
		padding: 0 12px;
		font-size: 12.5px;
		line-height: 1.55;
		color: var(--text-4, #838A9D);
	}

	/* The drawer and both of its levels move; none of it carries meaning that
	   the end state does not. */
	@media (prefers-reduced-motion: reduce) {
		.pfg-nav,
		.pfg-nav__item,
		.pfg-nav__panel,
		.pfg-nav__chev {
			transition: none;
		}
	}
}