/*
 * Account - the section shell.
 *
 * WHAT THIS PAGE USED TO BE. Five headings and five EDD panels stacked in one
 * 696px column: 3,431px of document on a phone for an account with nothing in
 * it, of which 1,677px was a profile form that never reflowed at any width and
 * 701px of THAT was a billing address. The first heading, "Your Downloads",
 * captioned nothing at all, because edd/user-downloads returns an empty string
 * for a customer with no purchases. Every panel ran its queries on every visit
 * whether or not anyone scrolled to it.
 *
 * WHAT IT IS NOW. A nav of three sections - Recent downloads, Orders, Profile -
 * each carrying the number of things in it, and exactly ONE section rendered per
 * request. Not hidden - not rendered: inc/account.php drops the other two in
 * `pre_render_block`, before their blocks query anything. The section is in the
 * URL as `?view=<slug>`, so a section is linkable and the back button walks
 * back out of it.
 *
 * THE RAIL IS A SETTINGS RAIL. The current section is marked by a 2px indicator
 * and a weight change, not by a filled black pill - the same "you are here" the
 * rest of this site already speaks, defined in
 * assets/blocks/sparklestock-category-tabs.css. Identity is not in the rail at
 * all; it is one muted line above the grid. Both changes have their argument at
 * the rules that make them, `.f32-account-identity` and the Section nav block.
 *
 * An empty section keeps its place in the nav with a 0 badge. Knowing a section
 * exists costs one row of nav; it used to cost a screen of scrolling.
 *
 * There were five sections. Passes and Subscriptions were a 0 badge over a
 * sentence apologising for 97% of customers, so the pass list moved into the
 * Library and edd/subscriptions moved into Orders above the order history. The
 * card rules that styled the Passes panel went with it; nothing on this page
 * renders `.f32-passes` any more.
 *
 * The 900px breakpoint below is the site header's, not a new one. Above it the
 * nav is a sidebar; below it the header stacks and this nav becomes a
 * horizontal scroller, which is the same width at which the header stops being
 * sticky - see assets/css/site-header.css. What crosses that breakpoint is the
 * EDGE the indicator sits on, not the control: a left rule above, a bottom rule
 * below, the same tab either way.
 *
 * This page takes the `plain` header variant, so its header is one row and
 * site-header.css publishes 88px rather than 134px as --f32-header-height. The
 * rail's sticky offset reads that variable and needs no knowledge of which
 * header rendered.
 *
 * Loaded on the account page only, per f32_is_account().
 *
 * @package F32
 */

/* ---------------------------------------------------------------------------
 * Alerts - what is left of the login block when somebody is signed in
 * ------------------------------------------------------------------------ */

/*
 * THE GREETING IS GONE FROM HERE AND SO ARE ITS FOUR RULES. It was a name, an
 * address and a log out link printed above the layout by
 * f32_account_greeting(), and it needed a `max-width` rule of its own to stop
 * starting 242px to the right of the nav underneath it - a measure kept in step
 * by hand between a stylesheet and a block that renders outside the thing it
 * had to line up with.
 *
 * That is exactly the misalignment the redesign was called for, and it is not
 * fixed by a better number: edd/login is a child of `main` and CANNOT be inside
 * the dashboard, because a logged-out visitor needs the login form it renders
 * instead. So the identity moved inside the dashboard group, where it is a child
 * of the same constrained parent as the grid it has to line up with - see
 * `.f32-account-identity` below - and the block is left printing only the one
 * thing it must (EDD's error and success notices; the reason is in
 * f32_account_greeting()).
 *
 * The measure rule survives for those notices, at the same two classes and for
 * the same reason: `main` carries `f32-panel`, so an alert left at the group's
 * content size would sit narrower than everything it is warning about.
 */
.wp-block-group > .f32-account-alerts {
	max-width: var(--wp--custom--layout--panel);
}

/*
 * ...and the logged-OUT half of the same block, put back to the reading measure.
 *
 * `main` on this page carries `f32-panel`, so every one of its children takes the
 * 1180px panel - which is what the page needs, because the rail, the cards and
 * the page's own H1 all have to line up along one left edge. edd/login is the one
 * child that renders something different depending on who is asking. Logged in it
 * is a notice or nothing at all. Logged out it is a two-field login form, and a
 * two-field form 1180px wide is not a measure, it is an accident: the labels sit
 * at one end of the screen and the button at the other.
 *
 * `#edd-blocks-form__login` is the ID EDD's BLOCK markup emits, not the legacy
 * shortcode's `#edd_login_form` - the distinction is verified against the live
 * page in the header of assets/blocks/edd-login.css, and the wrong one of the two
 * is a rule that never matches anything. The ID also exists only while nobody is
 * logged in, because f32_account_greeting() replaces the block's whole output
 * once they are.
 *
 * The value is theme.json's global content size rather than 696px, for the same
 * reason the rule above reads the panel property rather than 1180px.
 */
#edd-blocks-form__login {
	max-width: var(--wp--style--global--content-size);
}

/* ---------------------------------------------------------------------------
 * Shell
 * ------------------------------------------------------------------------ */

/*
 * .f32-account is injected by f32_account_shell() as the dashboard group's only
 * child, and that is structural rather than incidental. Core's constrained
 * layout writes `margin-left: auto !important` for every direct child of the
 * group; auto inline margins on a grid item switch stretching off and shrink it
 * to its content, so a nav and a panel placed as two children of the group
 * would each collapse. One child absorbs that rule as intended - a centred
 * block at the group's 1180px measure - and the grid inside it is somewhere
 * core's layout CSS cannot reach.
 */
.f32-account {
	/*
	 * Padding rather than a margin. Core's layout writes `margin-block-start`
	 * for the children of a constrained group at one class of specificity, and
	 * this element is one of those children - a margin here would be a coin
	 * toss decided by stylesheet order.
	 */
	padding-block-start: var(--wp--preset--spacing--40, 1rem);
}

@media (min-width: 900px) {
	.f32-account {
		display: grid;
		grid-template-columns: minmax(0, 13rem) minmax(0, 1fr);
		gap: var(--wp--preset--spacing--60, 2.25rem);

		/*
		 * Without this the nav track stretches to the height of the panel and
		 * the sticky rule below has nothing to stick within: a grid item that
		 * is already as tall as its container never scrolls past its own
		 * boundary.
		 */
		align-items: start;
	}
}

/* ---------------------------------------------------------------------------
 * The rail - the section nav, as one grid child
 * ------------------------------------------------------------------------ */

/*
 * `.f32-account__side` is injected by f32_account_shell() and now wraps one
 * thing: the nav. It held the identity card as well until that card's border
 * turned out to be a patch for the grouping itself - see
 * `.f32-account-identity` above.
 *
 * The wrapper stays rather than the nav becoming the grid child directly,
 * because it is what `position: sticky` is applied to below and because a second
 * rail item (a support link, a "switch account") would otherwise re-open the
 * question this file just closed. It costs one element and no rules.
 */
.f32-account__side {
	min-width: 0;
}

/*
 * ONE TOP EDGE, AND THIS IS THE RULE THAT GUARANTEES IT.
 *
 * The rail's first child is the nav's first link, which starts at the grid row's
 * top. The panel's first child is the section's `<h2>`, and core's flow layout
 * gives every child of a flow container a `margin-block-start` - so without this
 * the heading starts 24px below the rail and the two columns read as two pages.
 *
 * Zeroing it here rather than in the template because the template does not know
 * it is the first thing in a column; the shell does. Two classes to clear core's
 * `:root :where(.is-layout-flow) > *` at 0,1,0.
 */
.f32-account .f32-account__panel > :first-child {
	margin-block-start: 0;
}

/*
 * THE PANEL'S HEADING IS READ AND NOT SEEN, and this is the whole of that change.
 *
 * It used to print the section's name directly under an H1 reading "Account" and 57px
 * from the nav item that had just been clicked, which is the same word three times in
 * 130px. f32_account_page_header_title() moved the name up into the H1, so the panel
 * has nothing left to say that the page has not said louder.
 *
 * HIDDEN RATHER THAN REMOVED FROM THE TEMPLATE, and the reasons are in
 * f32_account_section_heading(): the panel keeps an accessible name, the document keeps
 * its heading order, and f32_account_section_body() decides whether a panel rendered
 * anything by stripping the first heading - a rule that needs the heading to be there.
 *
 * THE SECOND RULE IS NOT OPTIONAL. This takes the h2 out of flow, so the panel's next
 * child becomes the first thing a reader sees while remaining the SECOND child in the
 * markup - and core's flow layout gives every child but the first a 24px
 * `margin-block-start`. Without the reset the panel would start 24px below the rail and
 * the two columns would read as two pages, which is the exact fault the `:first-child`
 * rule above this exists to prevent. Two classes plus an element clears core's
 * `:root :where(.is-layout-flow) > *` at 0,1,0.
 */
.f32-account__panel .f32-account-section__heading {
	position: absolute;
	width: 1px;
	height: 1px;
	margin: -1px;
	padding: 0;
	overflow: hidden;
	clip-path: inset(50%);
	white-space: nowrap;
}

.f32-account__panel .f32-account-section__heading + * {
	margin-block-start: 0;
}

/*
 * The identity line. Name, address, log out - above the grid, not inside it.
 *
 * IT USED TO BE A BORDERED CARD AT THE TOP OF THE RAIL, and the border is the
 * whole reason it is not one any more. The rule that drew it justified itself
 * like this: "without an edge the name and address read as the first two items
 * of the nav". True, and the wrong repair. Identity and navigation are unrelated
 * facts; they only needed separating because they had been put in one container,
 * so the edge was chrome bought to undo a grouping. Take identity out of the
 * rail and there is nothing left to separate it from.
 *
 * It is a child of the dashboard group now, which is what lines its left edge up
 * with `.f32-account` under it: both are children of the same constrained group
 * and both take its 1180px measure. No margin has to be kept in step by hand -
 * which is the fault the greeting had before it moved into the rail, and the one
 * this arrangement finally closes rather than relocating.
 *
 * `margin-block: 0` at two classes, to beat core's flow layout at 0,1,0. The
 * distance to the grid below is owned by `.f32-account`'s padding-block-start,
 * for the same reason that rule is padding rather than margin - see it above.
 */
.wp-block-group > .f32-account-identity {
	display: flex;
	flex-wrap: wrap;
	align-items: baseline;
	gap: 0.125rem 0.6875rem;
	margin-block: 0;
	color: var(--wp--preset--color--muted, #6b7280);
	font-size: 0.78125rem;
	line-height: 1.5;
}

.f32-account-identity__name {
	color: var(--wp--preset--color--primary, #000000);
	font-size: 0.8125rem;
	font-weight: 600;
}

/*
 * `break-all` and not `break-word`, and only here. An address has no spaces to
 * break at, and on a 390px phone a long one would otherwise push this line wider
 * than the panel under it. It is the one string on this page where breaking
 * mid-word is better than the alternative.
 */
.f32-account-identity__email {
	word-break: break-all;
}

/*
 * Quiet, and still a real control. No negative margin trick is needed here: the
 * line is horizontal, so the link's own words are already on the baseline its
 * neighbours sit on, and padding would only push the line taller.
 */
.f32-account-identity__logout {
	color: inherit;
	text-decoration: underline;
	text-underline-offset: 0.2em;
}

.f32-account-identity__logout:hover,
.f32-account-identity__logout:focus {
	color: var(--wp--preset--color--primary, #000000);
}

/*
 * THE PASS, AND IT IS THE REASON THIS LINE IS WORTH THE ROW IT COSTS.
 *
 * A name, an address and a log out link are three things the customer already knows,
 * which is why this line read as something printed before the page rather than as part
 * of it. The pass is the one fact on it they might actually want, and it came here from
 * the Recent downloads caption, where it was a property of one list on one of three
 * views. See f32_account_identity_html().
 *
 * The `price` pair is not decoration and is not a new decision: it is the same
 * green-on-green the nav's current count already inverts to, and the same pair the
 * account card's own "Included with your pass" pill wore before this lifted it off the
 * rows. One meaning, one colour, three places.
 *
 * `#065f46` is a literal for the same reason it is one in the nav rule above - theme.json
 * carries `price` as a background and no matching foreground - and it is the same literal,
 * so the two cannot drift.
 */
.f32-account-identity__pass {
	border-radius: var(--wp--custom--border-radius--sm, 4px);
	padding-inline: 0.375rem;
	background: var(--wp--preset--color--price, #d1fae5);
	color: #065f46;
	font-size: 0.6875rem;
	font-weight: 500;
	line-height: 1.1875rem;
}

/* ---------------------------------------------------------------------------
 * Section nav - the settings rail
 *
 * ONE VOCABULARY AT BOTH WIDTHS, AND THAT IS THE POINT OF THE REWRITE.
 *
 * What it replaced: a pill. The current section was a filled black slab with a
 * `9999px` radius, and below 900px every section became a pill in a horizontal
 * scroller. That is two different controls for one job, swapping at a
 * breakpoint - and it cost a `mask-image` patch to fade a row that, measured at
 * 390px, did not overflow: `scrollWidth 331 = clientWidth 331`, with 24px of
 * "Profile" faded to transparent to announce content that was not there. Both
 * the pill and the patch are gone.
 *
 * What it is now: a rule and a weight. A hairline runs the length of the list
 * and the current item thickens its own 2px segment of it to `primary`, exactly
 * the indicator assets/blocks/sparklestock-category-tabs.css already defines for
 * every other tab strip on this site (`--ss-tabs-indicator-size: 2px`, muted to
 * primary, 500 to 600). The account page had been the one place inventing a
 * second answer to "which one am I on".
 *
 * ACROSS 900px THE RULE ROTATES AND STAYS A RULE - left edge above, bottom edge
 * below. The base here is the phone row; the column is the min-width block. So
 * there is no species change at the breakpoint, nothing to fade, and the counts
 * can stay at both widths: a text label plus a 22px chip is far narrower than
 * the pill was, and the three sections measure comfortably inside a 390px row.
 *
 * THE CURRENT ITEM ALSO CHANGES WEIGHT, which the shipped rail did not do -
 * `.is-current` set background, border-color and color and left the type
 * identical, so the state was carried entirely by fill. Weight is the redundant,
 * non-chromatic half of that cue.
 * ------------------------------------------------------------------------ */

.f32-account-nav__list {
	display: flex;
	margin: 0;
	padding: 0;
	list-style: none;

	/*
	 * The phone layout is the base. The row scrolls if it has to - and unlike
	 * the pills it replaced, it usually does not have to. No mask: a scroller
	 * that overflows shows a real scrollbar, and one that does not should say
	 * nothing at all.
	 */
	overflow-x: auto;
	gap: 1rem;
	border-block-end: 1px solid var(--wp--preset--color--border-subtle, #e0e0e0);
	scrollbar-width: thin;
}

.f32-account-nav__item {
	flex: 0 0 auto;
	margin: 0;
}

.f32-account-nav__link {
	display: flex;
	align-items: center;
	gap: 0.5rem;

	/*
	 * The -1px pulls the indicator onto the list's own hairline rather than
	 * under it, so the current segment replaces that 1px instead of sitting
	 * beside it.
	 *
	 * The distance BETWEEN tabs is the list's `gap`, not a margin here, and
	 * that is worth a line: a trailing margin on the last tab is 16px of
	 * scrollable width with nothing in it, and measured at 390px the row is
	 * decided by a handful of pixels - 164 + 78 + 46 for the three labels
	 * leaves 37px for two gaps inside a 325px scroller. `gap` spends it twice
	 * instead of three times, and the row fits without one.
	 */
	margin: 0 0 -1px 0;
	padding: 0.625rem 0;
	border: 0;
	border-block-end: 2px solid transparent;
	border-radius: 0;
	background: none;
	color: var(--wp--preset--color--muted, #6b7280);
	font-size: 0.9375rem;
	font-weight: 400;
	line-height: 1.3;
	text-decoration: none;
	white-space: nowrap;
	transition: color 0.15s ease, border-color 0.15s ease;
}

/*
 * Hover previews the indicator in a lighter grey rather than underlining the
 * link, which is the same choice - and the same reasoning - as
 * `--ss-tabs-indicator-hover` in the category tabs sheet: an underline would
 * compete with the thing it is previewing.
 */
.f32-account-nav__link:hover,
.f32-account-nav__link:focus {
	border-block-end-color: var(--wp--preset--color--border-strong, #d1d5db);
	color: var(--wp--preset--color--primary, #000000);
}

.f32-account-nav__link.is-current {
	border-block-end-color: var(--wp--preset--color--primary, #000000);
	color: var(--wp--preset--color--primary, #000000);
	font-weight: 600;
}

/*
 * The count. `border-radius--sm`, and the category strip's count now reads the
 * same token - it carried a hardcoded 5px, which was a literal in that file
 * where 4px is a token in theme.json. This comment used to ask for that
 * convergence and name the tabs sheet as the place to make it; the change
 * landed there, so the two counts are one decision now.
 */
.f32-account-nav__count {
	min-width: 1.375rem;
	padding-inline: 0.375rem;
	border-radius: var(--wp--custom--border-radius--sm, 4px);
	background: var(--wp--preset--color--subtle, #f5f5f5);
	color: #9ca3af;
	font-size: 0.71875rem;
	font-weight: 500;
	line-height: 1.1875rem;
	text-align: center;
}

/*
 * The active count inverts to the price green, which is the one palette colour
 * this site already uses to mean "this is the number that matters" - the same
 * inversion the category tabs make, for the same reason.
 */
.f32-account-nav__link.is-current .f32-account-nav__count {
	background: var(--wp--preset--color--price, #d1fae5);
	color: #065f46;
}

@media (min-width: 900px) {
	.f32-account__side {
		/*
		 * Pinned under the site header, which is itself sticky at this width
		 * and publishes its stuck height as --f32-header-height. That number
		 * is no longer one constant: the account page takes
		 * the `plain` header variant, whose header is one row, and
		 * assets/css/site-header.css publishes the shorter height for any page
		 * with no browse row. The fallback keeps the rail from disappearing
		 * under the header if that ever stops being true.
		 *
		 * No z-index: the rail has its own grid column and never overlaps the
		 * panel.
		 *
		 * The rail is ONE child again - the nav - since the identity moved out
		 * of it. Nothing here can come unstuck from anything else.
		 */
		position: sticky;
		top: calc(var(--f32-header-height, 0px) + 1.5rem);
	}

	.f32-account-nav__list {
		flex-direction: column;
		gap: 0;
		overflow-x: visible;

		/*
		 * The hairline rotates with the list. The rule the current item
		 * thickens is the same rule at both widths; only its edge changes.
		 */
		border-block-end: 0;
		border-inline-start: 1px solid var(--wp--preset--color--border-subtle, #e0e0e0);
	}

	.f32-account-nav__link {
		justify-content: space-between;
		gap: 0.625rem;
		margin: 0 0 0 -1px;
		padding: 0.5625rem 0 0.5625rem 0.9375rem;
		border-block-end: 0;
		border-inline-start: 2px solid transparent;
	}

	.f32-account-nav__link:hover,
	.f32-account-nav__link:focus {
		border-block-end-color: transparent;
		border-inline-start-color: var(--wp--preset--color--border-strong, #d1d5db);
	}

	.f32-account-nav__link.is-current {
		border-block-end-color: transparent;
		border-inline-start-color: var(--wp--preset--color--primary, #000000);
	}
}

/* ---------------------------------------------------------------------------
 * Panel
 * ------------------------------------------------------------------------ */

/*
 * The one section that rendered. Its heading and its panel are spaced by core's
 * flow layout at the theme's 24px block gap, which is why the headings in
 * page-account.html no longer carry margins of their own: they used to state
 * the distance to the NEXT section, and there is no next section any more.
 *
 * IT IS ALSO THE QUERY CONTAINER FOR EVERY CARD LIST INSIDE IT, and that is the
 * one number on this page nothing else can supply. Measured on staging: the
 * panel is 854.06px at a 899px viewport and 611.97px at 901px, because the nav
 * becomes a 13rem sidebar at 900px and takes 244px of the measure with it
 * (208px track + a 2.25rem gap). The panel therefore gets NARROWER as the
 * viewport gets WIDER, once, by 242px - so a viewport media query adding a
 * column is guaranteed to add it at the exact width the room disappeared. Every
 * `@container f32-account-panel` block below is keyed to this element instead,
 * which is the same answer assets/blocks/sparklestock-downloads-library.css
 * reached for the same card, one level in.
 *
 * ONE CONTAINER RATHER THAN ONE PER LIST. The Orders panel emits a wrapper we
 * own (`.f32-account-orders`) and the Subscriptions panel does not - its `<ul>`
 * is a direct child of EDD's `.edd-blocks__subscriptions` div - so naming this
 * element is what lets both lists ask the same question without one of them
 * being keyed to a plugin's class. Any future panel gets it for free.
 *
 * `container-type: inline-size` applies `contain: layout style inline-size`, and
 * all three were checked against what actually renders in here rather than
 * assumed. INLINE-SIZE: the panel is a grid item at `minmax(0, 1fr)` above 900px
 * and a block in normal flow below it, so its inline size is definite either
 * way and nothing can collapse. LAYOUT: it becomes the containing block for
 * positioned descendants, and the only two on this page are the profile form's
 * visually-hidden legend and the downloads library's visually-hidden label, both
 * 1px and clipped. STYLE: nothing here uses counters or quotes. The nav's
 * `position: sticky` is OUTSIDE the panel and is unaffected.
 */
.f32-account__panel {
	min-width: 0;
	container-type: inline-size;
	container-name: f32-account-panel;
}

/* ---------------------------------------------------------------------------
 * Orders panel - the account-card list
 * ------------------------------------------------------------------------ */

/*
 * ONE LIST OF CARDS. f32_account_render_orders() emits
 * `<ul class="f32-account-orders__list">`, filled with the
 * `<li class="account-card">` that assets/css/account-card.css draws.
 *
 * IT USED TO BE TWO. `.f32-subscriptions__list` shared both rules below until
 * the subscriptions block stopped drawing cards; it emits
 * `<div class="f32-plan-list">` now (inc/account-cards-subscriptions.php) and
 * assets/css/account-plan.css sizes it, at one column, for a reason that file
 * states. Both halves of the dead selector are gone rather than left as a
 * comment - a rule that sizes a class nothing emits is a rule the next reader
 * has to disprove before they can trust the one beside it.
 *
 * THE LIST IS THE CALLER'S, NOT THE CARD'S. account-card.css:21-27 states that
 * boundary outright: `AccountCard\render()` returns one `<li>` and never the
 * `<ul>` around it, so the column count, the gutter and the breakpoints are the
 * arrangement of many cards rather than anything about a card. The downloads
 * library keeps its own copy of exactly this rule in its own stylesheet for the
 * same reason, at a different column count. This one is the account's.
 *
 * ONE COLUMN IS THE FLOOR AND THE SECOND IS THE ENHANCEMENT, so a renderer with
 * no container query support gets a single-column grid at every width -
 * degraded, never broken. The reverse ordering would hand a phone a desktop
 * grid. `minmax(0, 1fr)` rather than a bare `1fr` in either branch: `1fr` is
 * `minmax(auto, 1fr)` and floors at its content's minimum size, so one product
 * title carrying a long unbreakable token would widen its own track and squeeze
 * the other. `__name` sets `overflow-wrap` against the same hazard from inside
 * the card; this is the half that protects the card NEXT to it.
 *
 * `padding: 0` and `list-style: none` are stated because this is a `<ul>` and
 * the UA gives it both. `margin: 0` is stated at TWO classes rather than one:
 * core's flow layout writes `margin-block-start` for the children of a flow
 * container at `:root :where(.is-layout-flow) > *`, which is 0,1,0, and a
 * single-class rule would tie with it and be settled by whichever stylesheet the
 * page happens to print last. `.f32-account__panel` is always the ancestor - it
 * is the shell's own element, injected by f32_account_shell() - so the scope
 * costs nothing and doubles as the guarantee that nothing outside this page can
 * match. 0,2,0 throughout.
 *
 * 20px gutter, taken from the downloads library rather than reinvented: it sits
 * between `spacing--40` (16px) and `spacing--50` (24px) and takes neither,
 * because the gutter is a gap between objects on one surface and not a step in
 * the page's vertical rhythm. Two grids of the same card on the same page
 * separated by two different numbers would be a difference the customer can see
 * and nobody can explain. assets/css/account-plan.css takes the same 20px for
 * the plan list beside it.
 */
.f32-account__panel .f32-account-orders__list {
	display: grid;
	grid-template-columns: minmax(0, 1fr);
	gap: 20px;
	margin: 0;
	padding: 0;
	list-style: none;
}

/*
 * ...AND A LEDGER LIST IS ONE SURFACE, WHICH IS THE OTHER HALF OF THAT SENTENCE.
 *
 * The rule above arranges cards as OBJECTS: a 20px gutter between things that each
 * carry their own edge. That is right for a grid of three and it is what both account
 * lists did until now. A ledger is not a grid of objects, it is a LIST OF ROWS - the
 * order history and the download history are both "the same kind of thing, many times,
 * newest first" - and a list of rows separated by 20px of page grey is a list whose
 * reader has to re-establish the alignment on every row. Measured on staging before
 * this rule: seven deliveries cost 958px of panel at 1180px and 1447px on a phone, of
 * which 120px was gutter and 14 painted edges were border.
 *
 * SO THE EDGE MOVES UP ONE LEVEL. The list takes the shell - `surface.object`'s own
 * line, radius and fill, read through the same four tokens `.account-card` and
 * `.f32-plan` read, so the account still cannot disagree with itself about what an
 * object looks like - and the card gives its edge up for a hairline between siblings.
 * The card half of the swap is in assets/css/account-card.css's Ledger section, at the
 * rule that states `border: 0`; NEITHER HALF IS CORRECT ALONE. Without this rule the
 * rows lose their boxes and float on the page grey; without that one the list draws a
 * box around a column of boxes.
 *
 * `overflow: hidden` IS LOAD-BEARING AND NOT TIDINESS. The ledger's item disclosure is
 * full-bleed by negating the card's inline inset, and its dividers used to be clipped
 * to the corner radius by `.account-card`'s own `overflow: hidden`. The radius is here
 * now, so the clip has to be here too, or the first and last rows paint square corners
 * outside a rounded box.
 *
 * 0,3,0 - the panel plus both list modifiers - over the base rule's 0,2,0. Both
 * modifiers are named rather than `--ledger` alone, because that is the compound
 * assets/css/account-card.css keys every one of its ledger rules to and a list wearing
 * one without the other is not a shape either file draws.
 */
.f32-account__panel .f32-account-orders__list--rows.f32-account-orders__list--ledger {
	overflow: hidden;
	gap: 0;
	border: var(--wp--custom--surface--object--line, 1px solid #e0e0e0);
	border-radius: var(--wp--custom--surface--object--radius, 16px);
	background: var(--wp--custom--surface--object--fill, #ffffff);
}

/*
 * THE SECOND COLUMN, AND WHY THERE IS NEVER A THIRD.
 *
 * This was derived twice. The orders list and the subscriptions card list were
 * sized separately - an order card carries more text than a subscription card,
 * and a customer usually has many orders and one subscription - and arrived at
 * the same two numbers by two different routes. BOTH arithmetics are kept below
 * even though only the orders half is still applied, because the second is the
 * independent confirmation of the first: two different worst-case strings put
 * the floor and the ceiling in the same place. Measured on this store's own
 * strings in Inter, which is what the panel actually renders.
 *
 * THE FLOOR IS THE CARD'S, NOT EDD'S, and it is a HARD one: `.account-card` sets
 * `overflow: hidden` and `.account-card__download` sets `white-space: nowrap`, so
 * a control whose label is wider than the card is not wrapped, it is CLIPPED.
 * That floor is 14 + 14 body padding + 16 + 16 pill padding + the widest label:
 *
 *   Orders        28 + 32 + 116.78px  "View Order Details"       = 176.78px
 *   Subscriptions 28 + 32 + 155.02px  "Update payment method"    = 215.02px
 *
 * (Both at 13px/600, which is what the card sets. "Complete Purchase" is 122.87
 * and "Cancel subscription" 125.48, so neither list's worst case moves.)
 *
 * THE CEILING IS THE META LINE, and it is what stops the count at two. The card
 * puts its badge and its facts on one flex row that WRAPS rather than truncates,
 * which is right on a phone and is a loss on a desktop panel that had the room:
 *
 *   Orders        28 + (97.57 + 3.96 letter-spacing + 18 pill padding)
 *                    + 8 gap + 256.69  "Order 299287 - date - total"  = 412.2px
 *   Subscriptions 28 + (112.70 + 4.40 + 18) + 8 + 271.86
 *                    "$249.00 / year - next payment ..."              = 443.0px
 *
 * The panel is 936px at its widest - 1180px page measure less the 244px the nav
 * sidebar takes - so three order cards plus two gutters would need 3 x 412.2 +
 * 40 = 1276.6px and get 936. A third track would put EVERY order card's meta
 * onto two lines. Two tracks give (936 - 20) / 2 = 458px each, which clears both
 * ceilings, and it is also exactly the 460px the orders caller's own `sizes`
 * hint claims for the artwork - see f32_account_orders_thumb(), which says in
 * words that this list is drawn two across where the library is drawn three.
 *
 * 560px IS THE BREAKPOINT because 2 x 270 + 20 = 560, and 270px is the width at
 * which the downloads library already draws this same card two across. It clears
 * the harder of the two hard floors (215.02px) by 55px, and it is the same
 * number the `sizes` hint switches to `50vw` at, so the grid and the image
 * request change shape at the same moment. Below it a single 16:9 band is the
 * most page height a phone spends and the place that height buys the most, which
 * is account-card.css's own argument for having no compact-row fallback.
 *
 * `auto-fill` was considered and cannot express this. It has no cap: to give two
 * columns at a 555px panel the floor must be at most (555 - 20) / 2 = 267.5px,
 * and to withhold a third at 936px it must exceed (936 - 40) / 3 = 298.67px.
 * Those are not both satisfiable at any gutter under 207px. The rule that fixes
 * EDD's own grid below uses `auto-fill` because it is a track-sizing correction
 * to markup this theme does not own; this list is ours and can say two.
 *
 * 0,2,0, for the reason the base rule states. A container query changes nothing
 * about specificity - the condition gates whether the rule is applied, not how
 * heavily it weighs.
 */
@container f32-account-panel (min-width: 560px) {
	/*
	 * Two-across is for the CARD arrangement only. A `--rows` list is a table in
	 * spirit - dates, totals and statuses that only compare when they line up -
	 * and folding it into two ~458px columns un-lines them all; the Rows section
	 * in account-card.css assumes the full panel width its foot rule measures.
	 */
	.f32-account__panel .f32-account-orders__list:not(.f32-account-orders__list--rows) {
		grid-template-columns: repeat(2, minmax(0, 1fr));
	}
}

/*
 * The orders pager, and with it THE ACCOUNT'S ONE PAGER DESIGN - stated here and
 * again, declaration for declaration, in
 * assets/blocks/sparklestock-downloads-library.css.
 *
 * THE MARKUP, READ OFF THE RUNNING FUNCTION RATHER THAN ASSUMED. Both pagers are
 * `paginate_links( 'type' => 'plain' )` on WP 7.0.4 - this one through
 * f32_account_orders_pager(), the library's through that block's render.php - and
 * the output was rendered on staging before a selector here was touched: `<a
 * class="page-numbers">` per page, `<a class="prev page-numbers">` and `.next` at
 * the ends, `<span aria-current="page" class="page-numbers current">` for the page
 * you are on, `<span class="page-numbers dots">&hellip;</span>` for the gap. THE
 * CURRENT PAGE IS A SPAN, which is why every rule below names `a` AND `span`: a
 * pager resized for anchors alone would leave the one item the customer is looking
 * for at the old height, in the middle of the row, and nothing would error. The
 * library sheet's `.cur`/`.ell` went with this pass - they were mockup spellings for
 * a pager that has been core's since it shipped, so they matched nothing, and
 * carrying them would have made the two blocks differ over a difference that is not
 * real.
 *
 * TWO FILES, AND THEY CANNOT HONESTLY BE MADE ONE. account.css is enqueued for the
 * account page and nowhere else (f32_enqueue_account_styles); the library sheet is
 * enqueued by the block, wherever the block renders (f32_get_block_asset_list). Fold
 * the library's copy in here and its pager loses its paint the day the block is
 * placed on any other page; fold this one into the library sheet and the orders
 * pager depends on a block that need not be on the request. A third sheet, enqueued
 * by both paths, is the real fix and it costs a handle in functions.php - which this
 * pass does not own, so it is reported rather than done. Until then the duplication
 * is deliberate and it is held BY HAND: the two blocks are the same declarations in
 * the same order and each names the other. Change one, change both.
 *
 * A 44px TARGET THAT STILL DRAWS A 28px PILL, which is the decision this rewrite
 * exists for. This panel already insists on 2.75rem for everything a customer taps -
 * see the action hierarchy below, where `a.edd-submit` states that floor for Update
 * payment method, Renew now, Cancel subscription and View Order Details - and the
 * pager was 27px. 27 passes WCAG 2.5.8 at AA on the spacing exception, which is
 * exactly why this is a judgment and not a bug; but a pager is a dense row of small
 * adjacent targets, which is where a mis-tap costs the most, and it sits two elements
 * away from controls this same panel insists are 44px. A panel that enforces a floor
 * for its buttons and exempts its pager has two rules and one reason.
 *
 * IT DOES NOT FOLLOW THAT THE PAINT GROWS. Forty-four-pixel pills, one per page
 * number, would put a row of buttons under a list of cards and out-shout "View Order
 * Details", which is the thing on this screen a customer is actually meant to press.
 * So the BOX is the target and a PSEUDO-ELEMENT is the paint, and the arithmetic is
 * exact: the box is min 2.75rem in both axes with 18px of inline padding, `::before`
 * is inset 8px on all four sides, so the pill is 44 - 8 - 8 = 28px tall and its
 * inline padding is 18 - 8 = 10px a side. That is `padding: 4px 10px` - what this
 * pager has always drawn - one pixel taller. The hit area grows by 63% in height and
 * the ink does not move.
 *
 * `gap` GOES TO 0 AND THAT IS THE ONE VISIBLE CONSEQUENCE. The 8px that used to sit
 * between the pills is now inside the boxes, twice; restating it on top would put the
 * numbers 24px apart and turn a sequence into a scatter. At 0 the boxes touch
 * exactly, so no two targets overlap - the failure that would otherwise steal a tap
 * for the neighbouring page - and the pills read 16px apart where they read 8.
 *
 * THE CURRENT PAGE IS MARKED THREE WAYS AND ONLY ONE OF THEM IS COLOUR: the filled
 * pill, which is a luminance step and survives greyscale and every kind of colour
 * blindness; `font-weight: 600` against a `400` now STATED on the links rather than
 * inherited, so the delta cannot be erased by whatever the panel's body weight
 * becomes; and core's `aria-current="page"`, for anyone not looking at pixels at all.
 *
 * SPECIFICITY. The base rule is 0,2,1 - two classes and the element - which clears
 * theme.json's `:root :where(a:where(:not(.wp-element-button)))` at 0,1,0 and its
 * `:hover` underline at 0,2,0, the second on the element term alone; the hover rules
 * are 0,3,1 and the current-page rules 0,3,0, `[aria-current]` scoring as a class so
 * both spellings tie with each other and both beat the base. The comment this
 * replaces called the base 0,3,0 by counting the element as a class: same winner,
 * wrong arithmetic, and this file has already been bitten twice by a tie nobody
 * expected.
 *
 * THE SUBSCRIPTIONS PANEL IS STILL DELIBERATELY ABSENT from these selectors. It pages
 * through `edd_pagination()`, which emits `#edd_subscriptions_pagination` and is
 * styled by edd-recurring's own stylesheet, and f32_account_subscription_pager()
 * only draws it when the block is given a `number` attribute, which the account
 * template does not. A third pager on this account would be a third design; if that
 * attribute is ever set, it joins this rule rather than gaining one.
 */
.f32-account__panel .f32-account-orders__pager {
	display: flex;
	flex-wrap: wrap;
	justify-content: center;
	align-items: center;
	gap: 0;
	margin-block-start: var(--wp--preset--spacing--40, 1rem);
	color: var(--wp--preset--color--muted, #6b7280);
	font-size: 13.5px;
	font-variant-numeric: tabular-nums;
}

/*
 * `position: relative` AND `z-index: 0`, and the second half is not decoration. The
 * pill is a `z-index: -1` pseudo, and a negative-z child paints behind its nearest
 * STACKING CONTEXT's background rather than behind its own parent's:
 * `.f32-account__panel` is `container-type: inline-size`, which applies layout
 * containment and therefore IS a stacking context, so a bare `z-index: -1` would put
 * every pill behind whatever that element and anything between paints. `z-index: 0`
 * on the positioned link makes the link its own stacking context, and the pill can
 * then only ever be behind the link's own text.
 */
.f32-account__panel .f32-account-orders__pager a,
.f32-account__panel .f32-account-orders__pager span {
	position: relative;
	z-index: 0;
	display: inline-flex;
	align-items: center;
	justify-content: center;
	min-width: 2.75rem;
	min-height: 2.75rem;
	padding-inline: 1.125rem;
	color: var(--wp--preset--color--muted, #6b7280);
	font-weight: 400;
	text-decoration: none;
}

.f32-account__panel .f32-account-orders__pager a::before,
.f32-account__panel .f32-account-orders__pager span::before {
	content: "";
	position: absolute;
	z-index: -1;
	inset: 0.5rem;
	border-radius: var(--wp--custom--border-radius--sm, 4px);
}

.f32-account__panel .f32-account-orders__pager a:hover {
	color: var(--wp--preset--color--primary, #000000);
	text-decoration: none;
}

.f32-account__panel .f32-account-orders__pager a:hover::before {
	background: var(--wp--preset--color--subtle, #f5f5f5);
}

.f32-account__panel .f32-account-orders__pager .current,
.f32-account__panel .f32-account-orders__pager [aria-current] {
	color: var(--wp--preset--color--contrast, #ffffff);
	font-weight: 600;
}

.f32-account__panel .f32-account-orders__pager .current::before,
.f32-account__panel .f32-account-orders__pager [aria-current]::before {
	background: var(--wp--preset--color--primary, #000000);
}

/* The ellipsis is a gap in a sequence, not a control. It keeps the 44px row height so
   the numbers stay on one line, and gives up the width claim only - a target floor on
   something nobody can press is 44px of dead row between two pages. */
.f32-account__panel .f32-account-orders__pager .dots {
	min-width: 0;
	padding-inline: 0.125rem;
}

/*
 * The ring traces the PILL, not the target. `outline-offset: -0.375rem` puts it 6px
 * inside the 44px box, which is 2px outside the 8px-inset pseudo on every side - the
 * same 2px every other focus ring in this file sits at. Left at the shared `+2px` it
 * would float 10px clear of the paint and read as a rectangle drawn around nothing.
 */
.f32-account__panel .f32-account-orders__pager a:focus-visible {
	outline: 2px solid var(--wp--preset--color--accent, #1473e6);
	outline-offset: -0.375rem;
}

/* ---------------------------------------------------------------------------
 * Orders panel - EDD's card grids, which are now the FALLBACK
 * ------------------------------------------------------------------------ */

/*
 * READ THIS BEFORE DELETING ANYTHING IN THIS SECTION OR THE NEXT.
 *
 * The two card lists above have replaced EDD's on the LIST screens, so it is now
 * obvious and wrong to conclude that the rules below match nothing. Every one of
 * them was checked against the live DOM on staging before this note was written,
 * and all three keep a live half:
 *
 *   .edd-blocks__subscriptions-grid   Emitted from TWO views, not one.
 *                                     views/subscriptions.php:25 is the list and
 *                                     is replaced; views/subscription/transactions.php:23
 *                                     is the DETAIL screen's transactions grid,
 *                                     which f32_account_render_subscriptions()
 *                                     hands straight back to EDD on
 *                                     `?action=details`. Measured there:
 *                                     `grid-template-columns: 460px 460px` in a
 *                                     936px panel, which is this rule working.
 *
 *   .edd-blocks__orders-grid          Emitted only by the order-history callback,
 *                                     which IS the one we replace - and which
 *                                     f32_account_render_orders() still delegates
 *                                     to for a logged-out visitor, for a customer
 *                                     pending verification, and whenever the
 *                                     blocks plugin is not active. That last case
 *                                     is designed for, not hypothetical:
 *                                     inc/account-cards.php refuses to swap the
 *                                     callback without the plugin precisely so
 *                                     EDD's panel is the fallback.
 *
 *   a.edd-blocks-subscriptions__subscription-action--details
 *                                     Comes only from views/subscription/link.php,
 *                                     which only views/subscriptions.php requires
 *                                     - the list. Confirmed present on the list
 *                                     today and absent from the detail screen. It
 *                                     therefore renders ONLY on the delegated
 *                                     fallback above, and that is exactly when it
 *                                     is needed: without it, a store whose blocks
 *                                     plugin is deactivated gets "Subscription
 *                                     Details" as body text again, which is the
 *                                     defect the next section was written to fix.
 *
 *   a.edd-submit                      Zero on the list, two on the detail screen
 *                                     (All Subscriptions and Cancel), both 44px.
 *
 * So nothing here is dead. What changed is WHEN each fires: these are now the
 * rules that keep EDD's own screens - the detail view, the payment-method form,
 * and every delegated request - looking like the rest of this account. Deleting a
 * rule that still fires is worse than leaving one that does not.
 *
 * BORROWED SELECTORS, AND AN UPGRADE RISK. Every class named in this section and
 * the next belongs to easy-digital-downloads-pro and edd-recurring, and either
 * plugin may rename or drop one in any release. Each rule is therefore written
 * so that the class going away makes the rule stop MATCHING rather than
 * half-apply: nothing below is load-bearing for the page's structure, and the
 * failure mode of every one of them is "the panel looks the way EDD ships it".
 * If a section of this panel ever reverts to plugin defaults, look here first.
 *
 * THE BUG. EDD renders both card lists as `<div class="... edd-blocks__columns">`
 * - Loader::get_classes() (edd-recurring) and Helpers\get_block_classes()
 * (EDD Pro) both append that class whenever the block's `columns` attribute is
 * above 1, and its default is 2. order-history's stylesheet then sizes the class
 * as:
 *
 *     @media (min-width: 600px) { .edd-blocks__columns { grid-template-columns: repeat(2, 50%) } }
 *
 * 50% is half the CONTAINER, and `gap` is added BETWEEN those two tracks rather
 * than taken out of them. Measured at 1280px: panel 936px, tracks 468 + 468,
 * gap 16 - 952px of grid in a 936px box, and the second card's right edge lands
 * 16px past the panel's. Exactly the gap, at every width above 600px.
 * `.edd-blocks__subscriptions-grid` is the same markup carrying the same class
 * and overhangs identically; it is masked today only because this customer has
 * one subscription. edd-recurring ships its own copy of that rule saying
 * `repeat(2, 1fr)`, which is correct - it just loses to order-history's on
 * source order, both being one class.
 *
 * This is a track-sizing correction and nothing else. No overflow clipping - a
 * clip would hide the symptom and keep the 952px grid - and no restyling of
 * EDD's cards.
 *
 * WHY NOT `repeat(2, minmax(0, 1fr))`. A fixed count needs a breakpoint, and
 * this panel's width is not a function of the viewport. At 899px the nav is a
 * horizontal scroller above the panel and the panel is the full ~810px measure;
 * at 901px the nav becomes a 13rem sidebar and the panel drops to ~566px. A
 * viewport media query would therefore add a second column at the moment the
 * panel got NARROWER. `auto-fill` reads the container and needs no breakpoint.
 *
 * The minimum still has to be a DEFINITE length, which is the thing a bare `1fr`
 * gets wrong: `1fr` is `minmax(auto, 1fr)`, and an automatic minimum grows to fit
 * the widest unbreakable run in the track - one long licence key or file name in
 * a card and the track pushes the grid wide again, which is this same bug one
 * level down. `min(100%, 22rem)` is definite at every width.
 *
 * 22rem IS a new number and it is derived, not chosen. EDD's card is
 * `padding: 1rem` and its label/value rows are
 * `repeat(auto-fit, minmax(150px, 1fr))` with a 1rem gap, so a card needs
 * 150 + 16 + 150 + 32 = 348px before its own insides collapse to one column.
 * 22rem is 352px, the first whole rem above that: below it the grid drops to a
 * single full-width column rather than shipping two cards that have already
 * collapsed internally.
 *
 * `auto-fill`, not `auto-fit`: auto-fit collapses the empty track, so the
 * customer with one subscription would see that card jump from half width to
 * full width. That is a layout change, and this is a bug fix.
 *
 * At 1280px this now computes to 2 tracks of (936 - 16) / 2 = 460px plus one
 * 16px gap = 936px, which is the panel.
 *
 * Two classes deep because one would tie with `.edd-blocks__columns` at 0,1,0
 * and be settled by whichever stylesheet the page prints last - which is exactly
 * how edd-recurring's correct rule lost in the first place.
 */
.f32-account__panel .edd-blocks__orders-grid,
.f32-account__panel .edd-blocks__subscriptions-grid {
	grid-template-columns: repeat(auto-fill, minmax(min(100%, 22rem), 1fr));
}

/* ---------------------------------------------------------------------------
 * Orders panel - subscription actions
 * ------------------------------------------------------------------------ */

/*
 * THREE WEIGHTS FOR NO REASON, and where each came from. On the subscriptions
 * LIST, edd-recurring's views/subscription/link.php renders
 *
 *     <div class="edd-blocks-subscriptions__subcription-actions">     <- EDD's typo
 *       <a class="edd-blocks-subscriptions__subscription-action--details">
 *
 * and the plugin's own `.edd-blocks-subscriptions__subscription-actions` rule
 * cannot reach it, because the wrapper is missing an `s`. That is the whole
 * reason "Subscription Details" arrives as body text. On the DETAIL view,
 * views/subscription/actions.php renders its links with `edd-submit` and they
 * read as buttons. Same panel, same kind of link, two accidents.
 *
 * ONE TREATMENT, TWO WEIGHTS, AND WHAT IT MEANS.
 *
 *   Solid danger - the action that CHANGES something. Only Cancel today; the
 *                  rule is keyed on the role, not on the word.
 *   Outline       - every move BETWEEN views: Subscription Details, All
 *                   Subscriptions, and the further actions edd-recurring adds
 *                   when the subscription supports them (Update Payment Method,
 *                   Renew, Reactivate).
 *
 * Cancel is the primary action of the detail screen and it does not get quieter:
 * it was a button and it is still a button, at the same size as its siblings,
 * and it gains a fill the rest of the panel does not have. `danger` is not a
 * one-off here - it is the theme's alarm token, spent in the same breath on
 * `.edd_errors.edd-alert-error` and `#edd-discount-error-wrap` in checkout.css
 * and on the danger tone in account-card.css. It is deliberately NOT coral:
 * coral is the BRAND colour and was retired from destructive duty when the
 * semantic tokens landed in theme.json. What changes is that weight now carries
 * information: filled means this alters your account, outlined means this only
 * moves you.
 *
 * Subscription Details is the primary action of the LIST screen and the first
 * thing a customer is meant to do anywhere in this panel - read the subscription
 * before deciding anything about it. It is outlined rather than filled because it
 * repeats once per card, and a column of solid pills would out-shout the
 * subscription data the cards exist to show. All Subscriptions is the same
 * treatment because it is the same kind of thing, a move between two views; its
 * old button weight was the part that made Cancel look ordinary.
 *
 * Placement is left to EDD. The typo'd list wrapper gets no flex rule here: on
 * the day EDD spells it correctly the plugin's own `justify-content: flex-end`
 * starts applying, and a rule of ours keyed to the misspelling would be dead
 * code that nobody could find. Weight was the defect; weight is the fix.
 *
 * SPECIFICITY. WordPress 7.x writes `:root :where(a:where(:not(.wp-element-button)))`
 * at 0,1,0 for `elements.link` colour and its `:hover` underline, and EDD writes
 * `.edd-blocks-subscriptions__subscription-actions .edd-submit` at 0,2,0. The
 * base rule below is 0,2,1 and clears both, and every state rule is higher again.
 * Both the link colour and the hover underline are restated explicitly rather
 * than left to inherit.
 *
 * `a` IS LOAD-BEARING in these selectors, not decoration. The profile editor's
 * Save button in this same panel is `<input class="edd_submit edd-submit">`, and
 * it belongs to forms.css. The element qualifier is what keeps this section off
 * it. The `.f32-account__panel` scope is what keeps it off EDD markup anywhere
 * else on the site.
 *
 * WHICH HALF FIRES WHERE, now that the card lists exist. `a.edd-submit` is the
 * detail screen and the payment-method form, verified: two of them there and none
 * on the list. `--details` is the delegated fallback list only. The section head
 * above has the measurements and the reason neither may be removed. The account
 * card draws its own controls through assets/css/account-card.css and matches
 * nothing here, which is deliberate - the two files state the SAME hierarchy in
 * two vocabularies, because one of them is EDD's markup and one of them is ours,
 * and a customer who lands on the detail screen from a card must not feel the
 * seam.
 */
.f32-account__panel a.edd-submit,
.f32-account__panel a.edd-blocks-subscriptions__subscription-action--details {
	display: inline-flex;
	align-items: center;
	justify-content: center;

	/*
	 * A 44px target. These are the only controls in the panel a customer taps on
	 * a phone, and the type they carry is smaller than forms.css's page-level
	 * submits, so the height is stated rather than left to padding.
	 */
	min-height: 2.75rem;
	padding: 0.5rem 1.25rem;
	border: 1px solid var(--wp--preset--color--muted, #6b7280);
	border-radius: var(--wp--custom--border-radius--full, 9999px);
	background: var(--wp--preset--color--contrast, #ffffff);
	color: var(--wp--preset--color--primary, #000000);
	font-size: 0.9375rem;
	font-weight: 500;
	line-height: 1.25;
	text-align: center;
	text-decoration: none;
	transition: background 0.15s ease, border-color 0.15s ease;
}

/*
 * `muted` rather than the `border-subtle` the nav pills use. A control's boundary
 * has to clear 3:1 against its own background to be seen at all; #6b7280 on white
 * is 4.8:1 and #e0e0e0 is 1.5:1. The nav pills can afford the softer line because
 * they sit in a list that reads as a list; a lone pill in a card cannot.
 */
.f32-account__panel a.edd-submit:hover,
.f32-account__panel a.edd-submit:focus,
.f32-account__panel a.edd-blocks-subscriptions__subscription-action--details:hover,
.f32-account__panel a.edd-blocks-subscriptions__subscription-action--details:focus {
	border-color: var(--wp--preset--color--primary, #000000);
	background: var(--wp--preset--color--subtle, #f5f5f5);
	color: var(--wp--preset--color--primary, #000000);
	text-decoration: none;
}

.f32-account__panel a.edd-submit:focus-visible,
.f32-account__panel a.edd-blocks-subscriptions__subscription-action--details:focus-visible {
	outline: 2px solid var(--wp--preset--color--accent, #1473e6);
	outline-offset: 2px;
}

/*
 * The one destructive control. `edd-subscription-cancel` is edd-recurring's own
 * class, printed as `edd-subscription-<key>` from get_subscription_actions() - so
 * this rule names the ROLE the plugin assigned, not the label, and it keeps
 * working if the store renames the button through
 * `recurring_cancel_button_text`, which it can.
 *
 * If that key is ever renamed, Cancel falls back to the outline pill above: still
 * a button, still the same size, still louder than the plain link it is today.
 * Degrading to "a control that reads as a control" is the point of writing the
 * fill as an addition rather than as the base.
 *
 * THE FILL IS `danger`, NOT `coral`, AND THAT IS THE WHOLE POINT OF THIS RULE.
 * Coral #ee383a is the BRAND colour - it is in the logo, in the brand furniture,
 * and on reversible brand hovers such as the filter chip in archive-download.css.
 * It was doing destructive duty here only because it was the reddest thing in the
 * palette, which is an accident of the palette and not a decision. A colour cannot
 * mean "this is us" and "this cancels your subscription" on the same page. So
 * coral is RETIRED FROM DESTRUCTIVE DUTY and the semantic token `danger` #b91c1c
 * carries it, alongside `success` and `warning` added to theme.json at the same
 * time. `danger-light` #fee2e2 is its wash.
 *
 * THE INK FLIPS WITH IT, and it has to. The old note here reasoned from coral:
 * black on #ee383a is 5.26:1 and white is 3.99:1, so ink stayed `primary`. Deep
 * crimson inverts that arithmetic - black on #b91c1c is 3.25:1 and FAILS AA, white
 * is 6.47:1 and passes comfortably. So the ink is `contrast`, and this is now the
 * white-on-red the shape always suggested.
 *
 * THE HOVER MIX IS RECOMPUTED. It still brightens rather than darkens, for the
 * opposite reason to before: darkening #b91c1c would take white ink further from
 * the AA floor for large-ish text only, and there is no darker palette red to
 * reach for anyway. `color-mix(in srgb, danger 80%, danger-light)` is
 * rgb(199, 68, 68), and WHITE ON THAT IS 4.84:1 - over the 4.5:1 floor, verified,
 * with the endpoint `danger-light` reachable if the mix ever moves. Both endpoints
 * are palette colours.
 */
.f32-account__panel a.edd-submit.edd-subscription-cancel {
	border-color: var(--wp--preset--color--danger, #b91c1c);
	background: var(--wp--preset--color--danger, #b91c1c);
	color: var(--wp--preset--color--contrast, #ffffff);
}

.f32-account__panel a.edd-submit.edd-subscription-cancel:hover,
.f32-account__panel a.edd-submit.edd-subscription-cancel:focus {
	border-color: color-mix(in srgb, var(--wp--preset--color--danger, #b91c1c) 80%, var(--wp--preset--color--danger-light, #fee2e2));
	background: color-mix(in srgb, var(--wp--preset--color--danger, #b91c1c) 80%, var(--wp--preset--color--danger-light, #fee2e2));
	color: var(--wp--preset--color--contrast, #ffffff);
}

/* ---------------------------------------------------------------------------
 * Recent downloads - the way back to the shop
 * ------------------------------------------------------------------------ */

/*
 * The one link under the history, and the whole of the panel's answer to
 * browsing. inc/account-recent-downloads.php states why the panel stopped being
 * a catalogue; this is the sentence that keeps that from stranding anybody.
 *
 * Two classes for the margin, per note 2 in assets/css/account-card.css: core's
 * flow layout writes `margin-block-start` at 0,1,0 and a single class would tie.
 */
/*
 * THE CAPTION THAT USED TO SIT HERE IS GONE. It read "7 deliveries, all included with
 * your pass" and it was two facts, neither of which belonged above this list: the count
 * was the nav badge written out as a sentence, and the pass is a property of the ACCOUNT
 * and is now a chip on the identity line. inc/account-recent-downloads.php carries the
 * argument at the panel's own sprintf.
 */

.f32-account__panel .f32-account-downloads__more {
	margin: 20px 0 0;
	font-size: 0.875rem;
}

/* ---------------------------------------------------------------------------
 * Empty states
 * ------------------------------------------------------------------------ */

/*
 * No section heading may stand over nothing. Downloads is the section this was
 * written for - it is the default view and the only one whose block renders a
 * bare empty string - but f32_account_section_chrome() applies the rule to any
 * section that comes back empty, so the guarantee is structural.
 */
.f32-account-empty {
	padding: var(--wp--preset--spacing--60, 2.25rem);
	border: 1px dashed var(--wp--preset--color--border-subtle, #e0e0e0);
	border-radius: var(--wp--custom--border-radius--lg, 16px);
	text-align: center;
}

.f32-account-empty__text {
	max-width: 44ch;
	margin: 0 auto var(--wp--preset--spacing--50, 1.5rem);
	color: var(--wp--preset--color--muted, #6b7280);
}

.f32-account-empty__text:last-child {
	margin-bottom: 0;
}

.f32-account-empty__cta {
	display: inline-block;
	text-decoration: none;
}

/*
 * THE SUBSCRIPTIONS PANEL'S EMPTY STATE HAS NO RULE HERE, AND THAT IS THE FIX.
 *
 * There was one: `.f32-account__panel .f32-subscriptions__empty` redrew the box
 * above and the ink below it on the bare `<p>` that
 * f32_account_subscriptions_empty() used to emit, so that a customer with no
 * orders AND no subscriptions - who gets both empty states stacked in this one
 * section - would not be shown two idioms. It has been deleted, because that
 * function now emits the shell itself: `.f32-account-empty` with a single
 * `.f32-account-empty__text` and no CTA, which is f32_account_orders_empty()'s
 * markup less its button. `.f32-account-empty__text:last-child` above already
 * takes the bottom margin off exactly that shape, so the three rules at the top
 * of this section draw it with nothing added.
 *
 * The note is kept where the rule was because the temptation will come back. A
 * stylesheet that reproduces a component it could have USED cannot be kept in step
 * with it - the copy here could not even carry `__text`'s `max-width: 44ch`, since
 * on one element the border would have clamped with the sentence - and the first
 * edit to the real shell would have left the two boxes differing by whatever that
 * edit was. If a third panel ever needs an empty state, it emits the shell too.
 */

/* ---------------------------------------------------------------------------
 * Profile form
 * ------------------------------------------------------------------------ */

/*
 * These rules are here rather than in forms.css on purpose. forms.css states
 * what a control looks like across the four form families this site has; the
 * pairing below is the shape of one particular form, and putting it in the
 * shared file would make every other form's single-column layout a thing that
 * has to be defended.
 *
 * EDD wraps each field in `<p id="edd_profile_*_wrap">`, so the fieldset can be
 * a two-column grid and the fields that deserve a full row can claim one. The
 * legend is not a grid item - a fieldset renders it outside its anonymous
 * layout box - so it needs no placement.
 *
 * 600px, and this one IS a new number: it is the width at which two ~150px
 * fields plus their labels stop being narrower than the text they hold. It is
 * a property of this form, not of the site's furniture, which is why it does
 * not reuse 900.
 */
/*
 * THE FORM'S OWN APPEARANCE LIVES HERE NOW, AND IT IS NOT A DUPLICATE OF forms.css.
 *
 * WHAT WAS WRONG. The profile editor rendered as browser default: small system-font
 * labels run together with unstyled boxes. Nothing was missing from the markup and
 * nothing was wrong with the rules - the STYLESHEETS THAT CARRIED THEM WERE NOT ON
 * THE PAGE. Both of them are attached to a BLOCK: assets/css/forms.css through
 * f32_get_form_block_list() and assets/blocks/edd-login.css through
 * f32_get_block_asset_list(), each hung on `edd/login` by wp_enqueue_block_style(),
 * which with wp_should_load_block_assets_on_demand() true enqueues from a
 * `render_block` filter. The profile editor is a SHORTCODE inside a section this
 * page switches with `pre_render_block` (inc/account.php), so what arrives depends
 * on a block that has nothing to do with the form. edd-login.css says as much in
 * its own header - "a hook of convenience rather than ownership" - and the
 * convenience is what ran out.
 *
 * SO THE RULES MOVE TO THE SHEET THAT CANNOT MISS. assets/css/account.css is
 * enqueued by f32_enqueue_account_styles() on `wp_enqueue_scripts` for every
 * request to /account/, whatever renders inside it. A form that only this page
 * shows is drawn by this page's stylesheet, which is the same answer
 * f32_enqueue_account_styles() reaches for the account card one file away.
 *
 * WHY NOT theme.json. Asked, and the answer is that it cannot be asked: `elements`
 * accepts button, link, heading, h1-h6, caption and cite. THERE IS NO `input`
 * ELEMENT in the theme.json schema, so a site-wide base field style is not a thing
 * a block theme can declare - the platform's own answer for form controls is still
 * a stylesheet. Nothing below is therefore duplicating something theme.json should
 * own, and neither checkout.css nor the header search is touched: every selector
 * here is scoped to `#edd_profile_editor_form`, an id that exists on exactly one
 * form on this site.
 *
 * THE VALUES ARE THE CHECKOUT'S, on purpose - `border-subtle` for the edge,
 * `border-radius--md` for the box, one palette for the ink - because a customer
 * who changes their address here and pays there must not meet two field idioms.
 * The one number that is not the checkout's is `min-height: 2.75rem`: 44px is the
 * tap target this theme states for every control a customer touches on a phone
 * (assets/css/account-card.css's download pill, the panel's edd-submit pills
 * above), and the checkout's fields reach it through padding rather than by
 * saying so.
 */

/*
 * The fieldset separators. assets/blocks/edd-login.css states these too, at the
 * same specificity and the same values, for the requests where it does arrive -
 * identical declarations, so which of the two wins is a question with no
 * consequences.
 */
/*
 * THE FORM IS GIVEN A MEASURE, AND THIS FILE HAS ALREADY WRITTEN THE ARGUMENT ONCE.
 *
 * Read `#edd-blocks-form__login` at the top of this stylesheet: "`main` on this page
 * carries `f32-panel`, so every one of its children takes the 1180px panel ... a
 * two-field form 1180px wide is not a measure, it is an accident: the labels sit at one
 * end of the screen and the button at the other." Every word of that is true of this
 * form and it was never applied to it. Measured on staging: the Profile panel is 936px
 * at a 1180px viewport, and "New Password" and "Re-enter Password" are two 936px boxes
 * holding twelve characters each.
 *
 * SAME VALUE AND FOR THE SAME REASON - theme.json's global content size rather than a
 * literal 696px, so a store that changes its reading measure moves both forms together
 * and neither can be left behind. The one difference from the login form is WHERE the
 * cap is stated: that one is an ID on the block wrapper, this one is the `<form>`, which
 * is the outermost element this stylesheet is allowed to name (the shortcode's wrapper
 * is EDD's and carries no id we own).
 *
 * IT CANNOT UNDO THE TWO-COLUMN GRID BELOW, and that is a fact about the query rather
 * than about the number. The pairing further down this file is `@media (min-width: 600px)`
 * - a VIEWPORT query - so it asks nothing about how wide this form is and cannot be
 * answered differently by narrowing it. First/Last Name still pair on a desktop and still
 * stack on a phone. At 696px the two halves are ~340px each, which is wider than the two
 * ~150px fields the 600px threshold was derived from, so the pairing is also still right
 * on the merits and not merely still switched on.
 *
 * 1,0,1 - an ID and a tag - which is what every rule in this section is written at and
 * for the reason the field rule below records: forms.css reaches these elements at
 * 0,2,2 and only the ID clears it.
 */
/*
 * AND IT IS AN OBJECT, WHICH IT WAS THE ONLY SECTION NOT TO BE.
 *
 * Recent downloads and Orders both present their contents inside a card - the
 * `surface.object` shell, drawn by `.account-card` and `.f32-plan`. Profile
 * presented bare fields on the page background, so the one section that asks the
 * customer to TYPE was the one with no edge around what they were typing into,
 * and the three panels read as three different kinds of page.
 *
 * The four tokens rather than four values, exactly as account-card.css and
 * account-plan.css read them, so this panel cannot drift from the other two: a
 * store that restyles its objects restyles this form with them.
 *
 * THE CARD IS THE FORM, not the panel. It would have been easier to wrap the
 * whole 936px panel and leave the fields at their measure inside it, and that is
 * the wrong shape: it draws a box most of which is empty, and it says the object
 * is the panel when the object is the form. Applying the shell to the element
 * that already carries the measure keeps one box around one thing.
 *
 * WHICH ALSO MEANS THE MEASURE IS UNCHANGED AND STAYS ARGUED FOR ABOVE. The
 * fields lose the shell's padding from each side - 696 becomes 664 of content -
 * and a 664px password field is a measure for the same reason a 696px one was.
 * What this must NOT become is a reason to widen the form to match its siblings'
 * 936px: the note above is right, a form is a reading and entry measure, and the
 * two panels beside it are lists of rows, which are not.
 */
#edd_profile_editor_form {
	max-width: var(--wp--style--global--content-size, 696px);
	padding: var(--wp--custom--surface--object--pad, 1rem);
	border: var(--wp--custom--surface--object--line, 1px solid #e0e0e0);
	border-radius: var(--wp--custom--surface--object--radius, 16px);
	background: var(--wp--custom--surface--object--fill, #ffffff);
	box-shadow: var(--wp--custom--surface--object--shadow, none);
}

/*
 * A FIELDSET'S `padding-top` DOES NOT GO WHERE IT LOOKS LIKE IT GOES, and that one
 * fact is the whole of this rule.
 *
 * WHAT WAS WRONG. This carried `padding: 1.5rem 0 0`, written to open space between
 * the separator and the legend under it. HTML's rendering rules say the used value
 * of a fieldset's `padding-top` is ZERO and the padding is applied to an anonymous
 * content box instead - a box the rendered legend is NOT inside. So the 1.5rem
 * landed UNDER the legend, on top of the legend's own 1rem `margin-bottom`.
 *
 * WHAT THE CUSTOMER SAW, and it is what was reported: "Name" sat 1rem above its
 * first field, because the first fieldset zeroed the padding, while "Billing
 * address" and "Password" sat 2.5rem above theirs. Measured on staging before the
 * fix: 16px against 40px. Three headings of one kind, drawn two ways, by a rule
 * that looked like it treated them identically. Dropping the padding is the whole
 * repair - all three are 16px now, which is the legend's `margin-bottom` and the
 * one value that was already right.
 *
 * NOTHING ABOVE THE HEADING MOVES. The space BETWEEN sections was never the
 * padding's: it is `margin-top` here, and it still measures 24px between every
 * pair of fieldsets.
 *
 * `border-top` IS DECLARED AND DOES NOT PAINT, and that is stated rather than
 * quietly removed because it is a separate defect from the one being fixed, it
 * predates this edit, and removing it changes nothing on screen. A fieldset draws
 * its top border with a GAP where the rendered legend sits, and the legend rule
 * below is `display: block; width: 100%` - so the gap is the full width and there
 * is no line left to draw. It has never appeared on this form. Restoring a visible
 * separator means drawing it somewhere other than the fieldset's own border, which
 * is a decision about how this form should look and not a bug fix.
 */
#edd_profile_editor_form fieldset {
	border: 0;
	border-top: 1px solid var(--wp--preset--color--border-subtle, #e0e0e0);
	margin: var(--wp--preset--spacing--50, 1.5rem) 0 0;
	padding: 0;
}

#edd_profile_editor_form fieldset:first-of-type {
	border-top: 0;
	margin-top: 0;
}

/*
 * The submit fieldset holds three hidden inputs and a button. Its separator would
 * draw a rule immediately under the password fieldset's own with nothing but the
 * button between them, so it keeps the space and loses the line.
 *
 * IT STATES ITS OWN PADDING because it has no legend, which is the one case where
 * a fieldset's padding behaves the way the rule above wrongly assumed for all
 * three: with no rendered legend the anonymous content box is the only child, so
 * the padding simply opens space over the button. It used to inherit that 1.5rem
 * from the base rule; the base rule no longer has it, and the button must not move
 * because two OTHER fieldsets were being repaired.
 */
#edd_profile_editor_form #edd_profile_submit_fieldset {
	border-top: 0;
	padding-top: var(--wp--preset--spacing--50, 1.5rem);
}

/*
 * The legend names a group of fields; it is not a heading in the document - the
 * section's own h2 is - so it is sized between the two rather than at either.
 */
#edd_profile_editor_form legend {
	display: block;
	width: 100%;
	margin: 0 0 var(--wp--preset--spacing--40, 1rem);
	padding: 0;
	font-size: 1.0625rem;
	font-weight: 600;
	line-height: 1.3;
}

/*
 * EDD wraps every field in a `<p>`, which is what lets the grid below pair them.
 * The margin is the form's vertical rhythm and the flex column is what puts a
 * label 6px over its control without either of them owning a margin.
 *
 * An id and a tag is 1,0,1, which is deliberate: core's flow layout writes
 * `margin-block-start` inside `:where()` at 0,1,0 and a bare tag selector would
 * lose to it.
 */
#edd_profile_editor_form p {
	display: flex;
	flex-direction: column;
	gap: 6px;
	margin: 0 0 var(--wp--preset--spacing--40, 1rem);
}

#edd_profile_editor_form p:last-child {
	margin-bottom: 0;
}

/*
 * `#edd_profile_submit_wrap` is that same `<p>` holding three `type="hidden"`
 * inputs and the button. A hidden input is still a flex ITEM - it has no box, but
 * the column's `gap` counts it - so the wrap would open three gaps above the
 * button. `align-items: flex-start` also keeps the button at its own width rather
 * than stretched across the form.
 */
#edd_profile_editor_form #edd_profile_submit_wrap {
	align-items: flex-start;
	gap: 0;
	margin-top: var(--wp--preset--spacing--40, 1rem);
}

#edd_profile_editor_form #edd_profile_submit_wrap input[type="hidden"] {
	display: none;
}

/*
 * THE `<br>` RULE THAT USED TO SIT HERE IS GONE, AND SO IS WHAT IT WAS HIDING.
 *
 * It hid every `<br>` inside this one wrap, and its comment blamed EDD for writing them
 * after its hidden inputs. EDD writes none. wpautop wrote them - all fourteen in this
 * form, not the three under the submit button - because core/shortcode's render callback
 * is `wpautop( $content )` and get_the_block_template_html() had already expanded the
 * shortcode into the raw template before do_blocks() ran, so the paragraph filter was
 * handed a finished form. The same pass split the primary-email `<p>` in half, which no
 * CSS here could have repaired.
 *
 * f32_account_shortcode_without_wpautop() in inc/account.php now short-circuits the block,
 * so there is no `<br>` left to hide and the label-to-control distance is the `gap: 6px`
 * this stylesheet asks for a few rules up. It was 34.4px on staging before that.
 */

#edd_profile_editor_form label {
	color: var(--wp--preset--color--primary, #000000);
	font-size: 0.875rem;
	font-weight: 500;
	line-height: 1.3;
}

/*
 * THE FIELD. `select` is listed out beside the typed inputs rather than folded
 * into an `:is()` for the reason assets/css/forms.css states at its own first
 * rule: `:is()` takes the weight of its heaviest argument. Written this way every
 * selector here is 1,1,1 - attribute selectors count in the CLASS column - which
 * clears forms.css's 0,2,2 (`form:is(...) :is(input[type=...])`) on ID weight alone.
 * The ID is load-bearing: drop it and 0,1,1 LOSES to that 0,2,2, so it stays on the requests
 * where both files are present.
 *
 * `font-size: 1rem` and not `inherit`: 16px is the floor under which iOS zooms the
 * viewport on focus, and this form is eight fields deep on a phone.
 */
#edd_profile_editor_form input[type="text"],
#edd_profile_editor_form input[type="email"],
#edd_profile_editor_form input[type="password"],
#edd_profile_editor_form input[type="tel"],
#edd_profile_editor_form input[type="url"],
#edd_profile_editor_form select {
	box-sizing: border-box;
	width: 100%;
	min-height: 2.75rem;
	padding: 0.5rem 0.875rem;
	border: 1px solid var(--wp--preset--color--border-subtle, #e0e0e0);
	border-radius: var(--wp--custom--border-radius--md, 8px);
	background: var(--wp--preset--color--contrast, #ffffff);
	color: var(--wp--preset--color--primary, #000000);
	font-family: inherit;
	font-size: 1rem;
	line-height: 1.5;
	transition: border-color 0.15s ease;
}

/*
 * A control's edge has to clear 3:1 against the page to be seen at all, and
 * `border-subtle` #e0e0e0 is 1.5:1. That is the right trade at REST, where the box
 * is read together with its label and the checkout makes the same pattern; it is
 * the wrong one the moment the customer is asking which box they are in.
 * `border-strong` #d1d5db answers the pointer and `accent` #1473e6 the focus, with
 * the ring doing the rest.
 */
#edd_profile_editor_form input[type="text"]:hover,
#edd_profile_editor_form input[type="email"]:hover,
#edd_profile_editor_form input[type="password"]:hover,
#edd_profile_editor_form select:hover {
	border-color: var(--wp--preset--color--border-strong, #d1d5db);
}

#edd_profile_editor_form input:focus-visible,
#edd_profile_editor_form select:focus-visible {
	border-color: var(--wp--preset--color--accent, #1473e6);
	outline: 2px solid var(--wp--preset--color--accent, #1473e6);
	outline-offset: 1px;
}

/* ---------------------------------------------------------------------------
 * The three selects, as a customizable select
 * ------------------------------------------------------------------------ */

/*
 * WHAT THIS FIXES. Everything above styles the CLOSED control, and until now that
 * was all a theme could style: the open list was the operating system's, in the
 * system font, at the system size, with no relation to the 44px white box that
 * opened it. The native chevron also sat hard against the right edge, because a
 * classic select draws it outside the padding box.
 *
 * `appearance: base-select` hands both to CSS. Everything in this block is inert in
 * a browser without support - the rules do not parse, the control stays exactly the
 * classic one the rules above paint - so this is an enhancement with no fallback to
 * write. Firefox is still prototyping the API, so the `@supports` guard is not
 * hypothetical bookkeeping.
 *
 * THE PATTERN IS NOT NEW HERE. The header's category dropdown does this already -
 * sparklestock/product-search, src/blocks/product-search/style.scss in the
 * sparklestock-blocks plugin, whose skin is assets/blocks/sparklestock-product-
 * search.css - and so does the archive sort dropdown at the end of
 * assets/css/archive-download.css. This block reuses their structure (control as a
 * flex box, icon pushed to the trailing edge, checkmark re-ordered to the end) and
 * their tokens, so the two dropdowns a customer meets read as one system.
 *
 * `#edd_profile_editor_form select` and not `.edd-select`: the country field is
 * rebuilt by EDD's AJAX when the country changes, and the replacement carries
 * whatever classes EDD chose that day. The form ID plus the bare tag catches every
 * select in the form, including the one that does not exist yet, and keeps the 1,0,1
 * weight the field rules above depend on.
 */
@supports (appearance: base-select) {
	#edd_profile_editor_form select,
	#edd_profile_editor_form select::picker(select) {
		appearance: base-select;
	}

	/*
	 * The closed control keeps every value the rule above gives it - height,
	 * border, radius, 16px Inter - and only becomes a flex box, which is what
	 * lets the chevron be placed instead of drawn by the platform.
	 *
	 * `padding-inline-end` is stated again at the same 0.875rem the shorthand
	 * sets, as the anchor for the note that matters: the chevron's breathing
	 * room is the CONTROL's padding plus `margin-inline-start: auto` on the
	 * icon. The old native arrow had neither and touched the border.
	 */
	#edd_profile_editor_form select {
		display: flex;
		align-items: center;
		gap: 0.5rem;
		padding-inline-end: 0.875rem;
		text-align: start;
		cursor: pointer;
	}

	/*
	 * A base-select button is a real box, so its `min-content` is zero and a long
	 * country name would otherwise stretch the grid column. Truncated honestly
	 * with an ellipsis rather than clipped mid-glyph by the control's edge.
	 */
	#edd_profile_editor_form select selectedcontent {
		flex: 1;
		min-width: 0;
		overflow: hidden;
		white-space: nowrap;
		text-overflow: ellipsis;
	}

	#edd_profile_editor_form select::picker-icon {
		margin-inline-start: auto;
		color: var(--wp--preset--color--muted, #6b7280);
		transition: rotate 0.18s ease;
	}

	#edd_profile_editor_form select:open::picker-icon {
		rotate: 180deg;
	}

	/*
	 * The popup is the closed control's own surface: white, the same hairline,
	 * the same `md` radius, and the theme's `lg` shadow - the value the archive
	 * sort picker already uses, so the two popups sit at the same elevation.
	 *
	 * `max-height` is load-bearing on ONE of these three fields. The country list
	 * is about 200 options; without a ceiling the picker is taller than the
	 * screen. 60vh keeps it inside the viewport on a phone.
	 */
	#edd_profile_editor_form select::picker(select) {
		box-sizing: border-box;
		max-height: min(20rem, 60vh);
		overflow-y: auto;
		padding: 0.25rem;
		border: 1px solid var(--wp--preset--color--border-subtle, #e0e0e0);
		border-radius: var(--wp--custom--border-radius--md, 8px);
		background: var(--wp--preset--color--contrast, #ffffff);
		box-shadow: var(--wp--preset--shadow--lg, 0 8px 24px rgba(0, 0, 0, 0.12));
	}

	/*
	 * One option row reads as one row of the same control: 16px, the same
	 * horizontal padding as the field, and the smaller radius inside the larger
	 * one. 0.5rem of vertical padding gives a ~40px target, which is the floor
	 * for a finger.
	 */
	#edd_profile_editor_form select option {
		display: flex;
		align-items: center;
		gap: 0.5rem;
		padding: 0.5rem 0.875rem;
		border-radius: var(--wp--custom--border-radius--sm, 4px);
		font-size: 1rem;
		line-height: 1.5;
		cursor: pointer;
	}

	#edd_profile_editor_form select option:hover,
	#edd_profile_editor_form select option:focus {
		background: var(--wp--preset--color--subtle, #f5f5f5);
	}

	#edd_profile_editor_form select option:checked {
		font-weight: 600;
	}

	/*
	 * The checkmark goes to the trailing edge so every label starts on the same
	 * x. It is not in the accessibility tree - `:checked` carries that meaning -
	 * so moving it is presentation only. Accent, because a check is the one
	 * interactive mark in the popup.
	 */
	#edd_profile_editor_form select option::checkmark {
		order: 1;
		margin-inline-start: auto;
		color: var(--wp--preset--color--accent, #1473e6);
	}

}

/*
 * The additional-address list, which is the only field wrap whose control is a
 * `<ul>` - it would otherwise take the browser's list indent inside a flex column.
 * Each address is drawn as the same box the fields are, because it is the same
 * kind of thing: one value the customer owns, with a control beside it.
 */
#edd_profile_editor_form .edd-profile-emails {
	display: flex;
	flex-direction: column;
	gap: 6px;
	margin: 0;
	padding: 0;
	list-style: none;
}

#edd_profile_editor_form .edd-profile-email {
	display: flex;
	align-items: center;
	justify-content: space-between;
	gap: 0.75rem;
	min-height: 2.75rem;
	padding: 0.5rem 0.875rem;
	border: 1px solid var(--wp--preset--color--border-subtle, #e0e0e0);
	border-radius: var(--wp--custom--border-radius--md, 8px);
	font-size: 0.9375rem;
}

/*
 * Remove is destructive, and destructive is `danger` here for the reason the
 * subscription cancel pill above states in full: coral is the BRAND colour and was
 * retired from destructive duty when the semantic tokens landed.
 */
#edd_profile_editor_form .edd-profile-email .actions a {
	color: var(--wp--preset--color--danger, #b91c1c);
	font-size: 0.875rem;
}

/*
 * SAVE CHANGES - the one action this form has, and the only control on it a
 * customer taps. So it takes the shape every other action in this panel takes: a
 * 44px pill at `border-radius--full`, which is the account card's download control
 * and the edd-submit pills above.
 *
 * `accent` #1473e6 under white is 4.53:1 and clears the 4.5:1 AA floor; the hover
 * moves to `action` #1d4ed8, which is 7.44:1 - so the control gets DARKER and safer
 * under the pointer rather than lighter. Both are palette colours.
 *
 * `input[type="submit"]` rather than the id on its own because forms.css paints
 * `input[type="submit"]` at 0,2,2 when it is present (attribute selectors weigh as
 * classes); an id and an attribute is 1,1,1 and settles it on ID weight without an
 * `!important` and without either file having to
 * know which of them printed last.
 */
#edd_profile_editor_form input[type="submit"] {
	display: inline-flex;
	align-items: center;
	justify-content: center;
	min-height: 2.75rem;
	padding: 0 1.5rem;
	border: 1px solid var(--wp--preset--color--accent, #1473e6);
	border-radius: var(--wp--custom--border-radius--full, 9999px);
	background: var(--wp--preset--color--accent, #1473e6);
	color: var(--wp--preset--color--contrast, #ffffff);
	font-family: inherit;
	font-size: 0.9375rem;
	font-weight: 600;
	line-height: 1.25;
	cursor: pointer;
	transition: background 0.15s ease, border-color 0.15s ease;
}

#edd_profile_editor_form input[type="submit"]:hover,
#edd_profile_editor_form input[type="submit"]:focus {
	border-color: var(--wp--preset--color--action, #1d4ed8);
	background: var(--wp--preset--color--action, #1d4ed8);
	color: var(--wp--preset--color--contrast, #ffffff);
}

#edd_profile_editor_form input[type="submit"]:focus-visible {
	outline: 2px solid var(--wp--preset--color--accent, #1473e6);
	outline-offset: 2px;
}

/*
 * The notices EDD prints above the form, which arrive whether or not any EDD
 * stylesheet did. An unstyled div reading "Success: Your profile has been edited
 * successfully" is indistinguishable from a paragraph of the page, and it is the
 * only confirmation this form gives that a password change took.
 */
.f32-account__panel .edd_success,
.f32-account__panel .edd_errors {
	margin: 0 0 var(--wp--preset--spacing--40, 1rem);
	padding: 0.75rem 1rem;
	border: 1px solid var(--wp--preset--color--border-subtle, #e0e0e0);
	border-radius: var(--wp--custom--border-radius--md, 8px);
	font-size: 0.9375rem;
}

/*
 * #15803d is a LITERAL and it is checked rather than assumed: theme.json has
 * `danger` and `danger-light` but NO `success` token - the comment further up this
 * file that says otherwise is describing the danger trio only. So the success
 * notice names the colour it needs here, once, and the day a `success` preset
 * lands this is the one place that changes.
 */
.f32-account__panel .edd_success {
	border-color: color-mix(in srgb, #15803d 25%, transparent);
	background: color-mix(in srgb, #15803d 8%, var(--wp--preset--color--contrast, #ffffff));
}

.f32-account__panel .edd_errors {
	border-color: color-mix(in srgb, var(--wp--preset--color--danger, #b91c1c) 25%, transparent);
	background: var(--wp--preset--color--danger-light, #fee2e2);
	color: var(--wp--preset--color--danger, #b91c1c);
}

@media (min-width: 600px) {
	#edd_profile_editor_form #edd_profile_personal_fieldset,
	#edd_profile_editor_form #edd_profile_address_fieldset {
		display: grid;
		grid-template-columns: repeat(2, minmax(0, 1fr));
		column-gap: 1rem;
	}

	/*
	 * Everything pairs except the fields that would be cramped by half a row.
	 * Personal: First/Last pair, display name and the email list do not.
	 * Address: City/ZIP and Country/State pair, the two address lines do not.
	 */
	#edd_profile_editor_form #edd_profile_display_name_wrap,
	#edd_profile_editor_form #edd_profile_primary_email_wrap,
	#edd_profile_editor_form #edd_profile_emails_wrap,
	#edd_profile_editor_form #edd_profile_billing_address_line_1_wrap,
	#edd_profile_editor_form #edd_profile_billing_address_line_2_wrap {
		grid-column: 1 / -1;
	}
}

/* ---------------------------------------------------------------------------
 * Billing address - what used to be a disclosure
 * ------------------------------------------------------------------------ */

/*
 * FIVE RULES USED TO SIT HERE. Four drew a <details>/<summary> around the billing
 * address fieldset; the fifth hid that fieldset's own legend so the summary could
 * be the visible label instead.
 *
 * The disclosure was bought with a measurement - "701px of a 1,677px form is an
 * address, on a store that ships nothing" - taken on a form that had 280px of
 * wpautop line breaks in it. edd_templates/shortcode-profile-editor.php carries
 * the argument in full and no longer emits the wrapper.
 *
 * NOTHING REPLACES THEM, and that is the point: the address fieldset is a direct
 * child of the form again, so the separator above it and the legend it now shows
 * come from `#edd_profile_editor_form fieldset` and `... legend` further up this
 * file - the same two rules that draw the Name and Password fieldsets. Three
 * fieldsets, one treatment, no rule of its own.
 *
 * Verified on staging rather than assumed, because those two rules are DUPLICATED
 * in assets/blocks/edd-login.css and that sheet is keyed to the edd/login block,
 * which f32_account_greeting() empties on any request with no alerts on it - so on
 * an ordinary profile view it is not on the page at all. The separators still draw,
 * from here. Nothing in this section depends on that block rendering.
 */


/* ==========================================================================
   Why a download was refused

   Printed by f32_account_pass_limit_notice_html() when a capped pass sends
   somebody here from a download they could not have. Gold rather than red: this
   is not an error the customer made, it is the plan working as sold, and a
   danger colour would read as "something has gone wrong with your account".

   No hover state, no shadow - it is a statement, not a surface. See the header
   of assets/css/surface.css.
   ========================================================================== */

.f32-account-notice {
	margin-block: var(--wp--preset--spacing--20) var(--wp--preset--spacing--30);
	padding: 0.875rem 1rem;
	border-radius: var(--wp--custom--border-radius--md, 8px);
	background: var(--wp--preset--color--gold-light, #fff4ca);
	border: 1px solid var(--wp--preset--color--gold, #ffe996);
}

.f32-account-notice__title {
	margin: 0;
	font-weight: 600;
	font-size: 0.875rem;
	line-height: 1.4;
	color: var(--wp--preset--color--primary, #000);
}

.f32-account-notice__body {
	margin: 0.375rem 0 0;
	font-size: 0.8125rem;
	line-height: 1.55;
	color: var(--wp--preset--color--primary, #000);
}