/**
 * My Account — login/register, dashboard sidebar + panels, and WC's
 * native address/account forms. Ported from the approved review mockup
 * (docs/mockups-account.html) for the markup this theme fully owns;
 * WooCommerce's own edit-address and edit-account forms are intentionally
 * NOT template-overridden (see woocommerce/myaccount/ — only
 * navigation.php, orders.php, view-order.php, and my-account.php are
 * overridden) so their real save/validation/nonce logic stays exactly
 * what WooCommerce ships — this section themes them via their own
 * stable core classes instead.
 *
 * @package WholesaleTheme
 */

/* .breadcrumbs now lives in base.css (global) — see that file's
 * comment; this was a duplicate of the same rule. */

/* ---------------- Shared field styles (also used by the Wholesale
   application form) ---------------- */
.field label,
.woocommerce-address-fields__field-wrapper label,
.woocommerce-EditAccountForm label {
	display: block;
	font-size: 11px;
	text-transform: uppercase;
	letter-spacing: .03em;
	font-weight: 700;
	margin-bottom: 6px;
	color: #444;
}
.field input,
.field textarea,
.woocommerce-address-fields__field-wrapper input,
.woocommerce-address-fields__field-wrapper select,
.woocommerce-address-fields__field-wrapper textarea,
.woocommerce-EditAccountForm input,
.woocommerce-EditAccountForm select,
.woocommerce-EditAccountForm textarea {
	width: 100%;
	border: 1px solid #ccc;
	padding: 10px 12px;
	font-size: 13.5px;
	font-family: inherit;
	margin-bottom: 16px;
}
/* Custom arrow for the Country/State dropdowns — at the time this was
   written, no existing custom-select convention existed elsewhere in
   this theme to reuse (the Shop page's sort dropdown originally kept
   the browser's native arrow deliberately). That's since changed: the
   Shop page's sort dropdown now has its own fully custom trigger + list
   (shop.css's `.custom-select*` rules, built by shop-filters.js),
   because its OPEN options list — unlike this fallback <select>, which
   Select2 replaces anyway (see the note below) — couldn't be restyled
   at all on mobile. This one stays as its own minimal chevron: flat,
   matching the site's monochrome line-icon style, no border-radius,
   consistent with every other input here.
   NOTE: WooCommerce automatically enhances Country/State selects with
   Select2 (wc-country-select.js, bundled with WC core) — this hides the
   real <select> entirely and replaces it with its own generated markup,
   confirmed via live DevTools inspection. The rule below is a fallback
   only (covers the brief flash before Select2's JS runs, and any select
   Select2 doesn't touch) — the actual visible styling for Country/State
   is the .select2-container block further down. */
.woocommerce-address-fields__field-wrapper select,
.woocommerce-EditAccountForm select {
	appearance: none;
	-webkit-appearance: none;
	background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' width='12' height='8' viewBox='0 0 12 8'%3E%3Cpath d='M1 1l5 5 5-5' fill='none' stroke='%23111' stroke-width='1.6' stroke-linecap='round' stroke-linejoin='round'/%3E%3C/svg%3E");
	background-repeat: no-repeat;
	background-position: right 14px center;
	padding-right: 38px;
	cursor: pointer;
}
/* Select2's own generated markup — the part actually visible for
   Country/State. Matches the same border/font/height convention as
   every other input in this form, plus the same chevron used above. */
.select2-container {
	display: block;
	width: 100% !important;
	margin-bottom: 16px;
}
.select2-container--default .select2-selection--single {
	border: 1px solid #ccc;
	border-radius: 0;
	height: auto;
	padding: 10px 12px;
	background: #fff;
}
.select2-container--default .select2-selection--single .select2-selection__rendered {
	line-height: normal;
	padding: 0;
	font-size: 13.5px;
	font-family: inherit;
	color: inherit;
}
.select2-container--default .select2-selection--single .select2-selection__arrow {
	height: auto;
	top: 50%;
	right: 14px;
	transform: translateY(-50%);
}
.select2-container--default .select2-selection--single .select2-selection__arrow b {
	border: 0;
	width: 12px;
	height: 8px;
	margin: 0;
	background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' width='12' height='8' viewBox='0 0 12 8'%3E%3Cpath d='M1 1l5 5 5-5' fill='none' stroke='%23111' stroke-width='1.6' stroke-linecap='round' stroke-linejoin='round'/%3E%3C/svg%3E");
	background-repeat: no-repeat;
	background-position: center;
}
.select2-container--open .select2-selection--single { border-color: #111; }
.select2-dropdown { border: 1px solid #111; border-radius: 0; }
.select2-search--dropdown .select2-search__field { border: 1px solid #ccc; padding: 8px 10px; font-size: 13px; font-family: inherit; }
.select2-results__option--highlighted[aria-selected] { background: #111 !important; color: #fff !important; }
.field textarea { min-height: 90px; resize: vertical; }
.field .optional { text-transform: none; font-weight: 400; color: #999; }
.field-row { display: grid; grid-template-columns: 1fr 1fr; gap: 14px; }

.btn-sm { padding: 8px 14px; font-size: 11px; }
/* .btn-block moved to base.css (2026-09-07) — it's used on several
   pages outside My Account (Get Custom Quote, Get Quote) where this
   stylesheet never loads; see base.css's comment for the full story. */

/* ---------------- Login / Register (WooCommerce's own default markup)
   ----------------
   v92.11 (2026-09-07, user request: "shouldn't they be on two different
   pages?"): Sign In and Register are now two separate views of this one
   page, switched by a `?register=1` query var (see my-account.php's own
   docblock for the full design and why a query var, not a new WordPress
   Page). WooCommerce's own form-login.php still renders BOTH forms every
   time — untouched, nonces and all — so this just hides whichever one
   isn't the current view, by class on the wrapper:
   .b2b-login-gate.b2b-view-login hides Register,
   .b2b-login-gate.b2b-view-register hides Login. Scoped through
   WooCommerce's real #customer_login ID (confirmed against WooCommerce's
   own GitHub source: <div class="u-columns col2-set" id="customer_login">,
   present only on this template) so it can never reach the Address Book
   overview page, which reuses the same u-columns/col2-set classes on a
   completely different wrapper (see that section's own rules further
   down).

   This retires the two-column CSS grid this page used to need for the
   old side-by-side layout, and with it, v92.10's float/width reset for
   that grid — that whole fight with WooCommerce core's own
   `.col2-set .col-1 { float:left; width:48%; }` only ever existed
   because two forms were being shown side by side. With only one form
   ever visible now, it just needs the plain centered-box treatment
   below — the same treatment the bare (registration-disabled) case
   already used, and the same one the h2 rule beneath it already assumes
   (see that rule's own v92.7 history for why the heading is targeted as
   a sibling of the form, never a descendant).

   Real regression found 2026-09-07 (v92.12), reported live by the user
   (screenshots: the visible column sitting hard against the left edge
   instead of centered, on Sign In, Register, and the Checkout-redirect
   login page alike): hiding the OTHER column was never enough on its
   own — WooCommerce core's own woocommerce-layout.css still applies
   `float:left;width:48%` / `float:right;width:48%` to `.col-1`/`.col-2`
   regardless of which one this rule hides, since that core rule matches
   on class alone. v92.10 already reset this once, for the old
   side-by-side case; removing that reset when v92.11 retired the grid
   was the mistake — the VISIBLE column still needed it just as much,
   only now on its own rather than paired with a sibling. Restored
   below, unconditionally (harmless on the hidden column, since
   display:none already takes it out of layout). */
.b2b-login-gate.b2b-view-login #customer_login.u-columns .u-column2,
.b2b-login-gate.b2b-view-register #customer_login.u-columns .u-column1 {
	display: none;
}
.b2b-login-gate #customer_login.u-columns .u-column1,
.b2b-login-gate #customer_login.u-columns .u-column2 {
	float: none;
	width: auto;
}
.woocommerce-ResetPassword {
	/* Added 2026-09-07 (v92.9) — WooCommerce's own Lost Password request
	   form AND its Reset Password form both use this one class (confirmed
	   against WooCommerce's own templates/myaccount/form-lost-password.php
	   and form-reset-password.php source), so one addition here covers
	   both screens of that flow. See my-account.php's own docblock for
	   why this flow needed a real code fix, not just styling, to even
	   render in the first place. Kept as its own fully-bordered box (v92.9
	   values, split out 2026-09-08/v92.15 from the shared rule below) —
	   this screen has no "Create an account" toggle under it, so unlike
	   Login/Register its box never needs to stay visually open at the
	   bottom.
	   v92.17: top margin dropped 60px -> 20px — this screen now gets its
	   own "Lost Password" <h2> above it (my-account.php), matching Login/
	   Register's own heading, and that heading already owns the full 60px
	   gap via `.b2b-login-gate h2` below; this box (or the notice-
	   standalone piece above it, when present) only needs the smaller gap
	   under the heading, same as `.woocommerce-form-login`/`-register`
	   already do. Bottom margin unchanged at 60px — no toggle link follows
	   this box the way Login/Register's does. */
	max-width: 420px;
	margin: 20px auto 60px;
	border: 1px solid var(--ink, #111);
	padding: 36px;
}
/* v92.21 (2026-09-14, user request): Lost Password's own CONFIRMATION
   screen (?reset-link-sent=true after a successful submit) is rendered
   via WooCommerce's own myaccount/lost-password-confirmation.php —
   confirmed against WooCommerce's real source (v3.9.0), that template
   is a bare wc_print_notice() (its default wide bordered
   .woocommerce-message bar) plus one entirely unstyled paragraph,
   neither ever wrapped in this flow's established bordered box. Themed
   override (woocommerce/myaccount/lost-password-confirmation.php)
   drops that default bar and puts both lines in this box instead, so
   the two Lost Password screens — request, then confirmation — read
   as one continuous design instead of a styled box suddenly giving way
   to raw browser-default text. Kept as its own class rather than
   reusing .woocommerce-ResetPassword directly so its two paragraph
   rules below can't collide with that class's own p:first-child rule
   just underneath (the PRE-submit screen's instructional paragraph,
   which needs different styling — see that rule's own comment). Box
   values intentionally match .woocommerce-ResetPassword exactly. */
.b2b-lost-password-confirmation {
	max-width: 420px;
	margin: 20px auto 60px;
	border: 1px solid var(--ink, #111);
	padding: 36px;
}
.b2b-lost-password-confirmation p:first-child {
	color: #111;
	font-weight: 700;
	font-size: 13.5px;
	margin: 0 0 12px;
}
.b2b-lost-password-confirmation p:last-child {
	color: #666;
	font-weight: 400;
	font-size: 13.5px;
	margin: 0;
}
/* v92.17: the plain WooCommerce-generated instructional paragraph
   ("Lost your password? Please enter your username or email address...")
   had no styling at all before this — rendering as plain black
   browser-default text. This is exactly the "hint" category of copy the
   sitewide convention (v92.16) exists for, so it now matches
   .wholesale-state-box p / .b2b-box-hint: gray, regular weight, small. */
.woocommerce-ResetPassword > p:first-child {
	color: #666;
	font-weight: 400;
	font-size: 13.5px;
	margin: 0 0 20px;
}
/* Lost Password's own template (form-lost-password.php) has no
   "form start" hook the way Login/Register's do (confirmed against its
   real source) — nothing to add our own notice/hint markup literally
   inside its <form> without forking it. Falls back to the same
   sibling-plus-border-extension technique v92.15 already uses at the
   BOTTOM of the Login/Register box for the "Create an account" link:
   printed as a sibling right before WC_Shortcode_My_Account::
   lost_password() (my-account.php), this piece owns the box's top
   border/padding, and the ResetPassword box itself drops ITS top
   border/padding so the seam between them is invisible — same
   `.has-notice` class my-account.php only adds when there's actually
   something to show, so a plain Lost Password visit keeps its normal,
   single, unbroken box exactly as before.
   v92.17: top margin dropped 60px -> 20px — this piece is now always
   preceded by the new "Lost Password" <h2> above it, which already owns
   the full 60px gap via `.b2b-login-gate h2` (zero bottom margin of its
   own); matches the exact same 20px-under-the-heading treatment
   `.woocommerce-ResetPassword` itself just got above, for the same
   reason. */
.b2b-box-notice-standalone {
	max-width: 420px;
	margin: 20px auto 0;
	border: 1px solid var(--ink, #111);
	border-bottom: none;
	padding: 20px 36px 0;
}
.b2b-box-notice-standalone .b2b-box-notice { margin: 0 0 16px; }
.has-notice .woocommerce-ResetPassword {
	margin-top: 0;
	border-top: none;
	padding-top: 20px;
}
/* Real placement gap found 2026-09-08 (v92.15), reported live: the
   "Don't have an account? Create one" / "Already have an account? Sign
   In" toggle link was rendering as a separate, unboxed line BELOW the
   bordered login/register box, when the user asked for it inside the
   box, right after the Log In/Register button. WooCommerce's own
   form-login.php renders the box's heading (<h2>) and the <form> itself
   as siblings inside one column div core controls — forking that
   template just to add one paragraph inside the form is the exact
   reimplementation risk this project avoids throughout (see
   my-account.php's own docblock), and the toggle link itself is printed
   by THIS theme's own my-account.php, entirely outside that WooCommerce
   markup, so it can't be moved into the DOM the widget/heading occupy
   either.
   Fix: rather than one shared border wrapping both elements, the form's
   own box drops its bottom border/padding/margin (stays open at the
   bottom) and the toggle link picks up matching border/padding right
   where the form left off (no top border of its own, so the seam
   between them is invisible) — visually reading as one continuous box
   that contains the fields, the Lost-Password link, the widget (if
   present), the submit button, AND the toggle link, in that order, with
   no visible seam between the button and the toggle text right below
   it. Same box identity (max-width/border color) as .woocommerce-
   ResetPassword and .b2b-verify-confirm elsewhere on this page — only
   split into two touching pieces instead of one. */
.woocommerce-form-login,
.woocommerce-form-register {
	max-width: 420px;
	margin: 60px auto 0;
	border: 1px solid var(--ink, #111);
	border-bottom: none;
	padding: 36px 36px 20px;
}
.b2b-login-gate h2 {
	font-size: 18px;
	text-transform: uppercase;
	letter-spacing: .03em;
	text-align: center;
	margin: 60px 0 0;
}
/* The form itself used to own the full 60px top gap (margin: 60px auto)
   — now the heading above owns it, so the form only needs a small gap
   below the heading. Longhand margin-top only: leaves the original
   rule's own left/right: auto (horizontal centering) and bottom: 60px
   untouched — this rule's higher specificity (.b2b-login-gate
   .woocommerce-form-login vs. plain .woocommerce-form-login) means it
   wins without needing !important.

   Real bug found 2026-09-07 (v92.12), reported live: .woocommerce-
   ResetPassword used to be included here too, on the assumption every
   view in this box has its own h2 owning the top gap the same way Sign
   In/Register do — but neither the Lost Password request screen nor the
   Reset Password screen renders one (WooCommerce's own templates put
   only an explanatory paragraph there, no heading), so that box was
   left with just this rule's 20px, sitting almost flush against the
   site header. Removed below so it falls back to the base rule's full
   60px top margin instead. */
.b2b-login-gate .woocommerce-form-login,
.b2b-login-gate .woocommerce-form-register {
	margin-top: 20px;
}
.woocommerce-form-login label,
.woocommerce-form-register label,
.woocommerce-ResetPassword label {
	display: block;
	font-size: 11px;
	text-transform: uppercase;
	letter-spacing: .03em;
	font-weight: 700;
	margin-bottom: 6px;
	color: #444;
}
.woocommerce-form-login input,
.woocommerce-form-register input,
.woocommerce-ResetPassword input {
	width: 100%;
	border: 1px solid #ccc;
	padding: 10px 12px;
	font-size: 13.5px;
	font-family: inherit;
}
.woocommerce-form-login .form-row,
.woocommerce-form-register .form-row,
.woocommerce-ResetPassword .form-row { margin: 0 0 16px; }
/* Real bug found 2026-09-07 (v92.12), reported live: the "Username or
   email" field on the Lost Password request screen rendered squeezed to
   under half the box's width, even though the input itself already has
   width:100% above. Root cause is the same class of bug as the u-column
   float case further up: WooCommerce's own form-lost-password.php wraps
   that one field in `.form-row-first` — a class core WooCommerce CSS
   sizes to roughly half width for FIRST/LAST paired fields (e.g. a
   First Name / Last Name row) — but this form only ever uses one field,
   with no `.form-row-last` partner, so nothing here had ever reset it.
   The input's own width:100% was only ever 100% of that shrunken box.
   Reset directly rather than chasing the exact core rule's selector.
   v92.18 (2026-09-08, reported live again): the plain reset above wasn't
   actually winning — confirmed live, input still rendering at roughly
   half the button's width. Same root cause category as the Reset
   Password button fix a few versions ago (v92.3, then v92.17): a
   WooCommerce core CSS rule for `.form-row-first` is either tied or
   ahead on specificity and wins the cascade regardless of this rule's
   own 2-class selector. `!important` added — same fix, same reasoning,
   third time this exact category of conflict has shown up on this
   project, not worth re-diagnosing the exact competing selector again. */
.woocommerce-ResetPassword .form-row {
	width: 100% !important;
	float: none !important;
}
.woocommerce-form-login__rememberme { font-size: 12.5px; display: flex; align-items: center; gap: 6px; margin-bottom: 16px; }
.woocommerce-form-login__rememberme input { width: auto; }
/* Real layout gap found 2026-09-07 (v92.12), reported live: WooCommerce's
   own form-login.php renders this link AFTER the remember-me/submit
   row, at the very bottom of the form — not the industry-standard spot
   right under the Password field, which is where the user asked for
   it. Rather than fork WooCommerce's own template just to move one
   paragraph (the exact reimplementation risk this project has avoided
   throughout — see my-account.php's own docblock), this reorders it
   visually with flexbox: .woocommerce-form-login becomes a flex column.
   v92.12's first attempt pushed this link to order 1 and the remember-
   me/submit row to order 2, leaving Username/Password at the default
   order 0 — but a third-party login-security widget (e.g. Cloudflare
   Turnstile) hooks into WooCommerce's own `woocommerce_login_form`
   action, which fires at one fixed point in the template: right after
   Password, right before the remember-me/submit row. That widget also
   sits at the default order 0, so it rendered BETWEEN Password and this
   link instead of after it — confirmed live 2026-09-07 via screenshot
   after the quote-flow redirect.
   REFINED (v92.14): rather than needing to know the widget's class at
   all, only the elements the requirement is actually about get an
   explicit order — Username and Password both move to a shared
   negative order (tied to each other, so their own relative order is
   untouched), and this link sits at an order between that and the
   default 0. The widget, any hidden fields, and the remember-me/submit
   row are left completely alone at the default order — their relative
   order among themselves (widget, then remember-me/submit) is already
   correct as WooCommerce renders it. Final sequence: Username →
   Password → Lost your password? → widget (if present) → remember-me/
   submit. WooCommerce's own field/nonce/submit markup and POST handling
   are completely untouched — only the visual position of one already-
   rendered link (and two field rows, relative to it) moves. */
.woocommerce-form-login { display: flex; flex-direction: column; }
.woocommerce-form-login .form-row.form-row-wide { order: -2; }
.woocommerce-LostPassword { order: -1; text-align: right; font-size: 11.5px; margin: -6px 0 18px; }
.woocommerce-LostPassword a { text-decoration: underline; color: #666; }
/* ---------------- Register field order + Confirm Password (v92.16,
   2026-09-08, user request) ----------------
   Requested final sequence: Email → Password → Confirm Password → a
   thin gray divider → Company Name/Contact Name/Phone → the login-
   security widget (if present) → Register button. WooCommerce's own
   register form (confirmed against its real source) renders Email then
   Password (both class `form-row-wide`, indistinguishable by class
   alone — same constraint as Login's Username/Password) then
   `do_action('woocommerce_register_form')`, which is where this
   theme's own Company Name/Contact Name/Phone AND Confirm Password
   (class-registration.php) both render — Confirm Password specifically
   renders FIRST within that hook so both its real DOM order and its
   flex order agree, needing no positional trickery of its own, unlike
   Email/Password which are WooCommerce's own markup and can't have a
   class added to them, so they're targeted the same positional way
   Login's fields already are. Company Name/Contact Name/Phone and the
   widget/submit row are left at the default order 0, completely
   untouched — their relative order among themselves is already correct
   as WooCommerce and the widget's own hook render them. */
.woocommerce-form-register { display: flex; flex-direction: column; }
.woocommerce-form-register p.form-row-wide:nth-of-type(1) { order: -4; } /* Email (WooCommerce's own field, no class to hook a selector to). */
.woocommerce-form-register p.form-row-wide:nth-of-type(2) { order: -3; } /* Password (native field, shown once "auto-generate password" is off). */
.b2b-reg-confirm-password { order: -2; }
.b2b-reg-divider {
	order: -1;
	border: 0;
	border-top: 1px solid #ddd;
	margin: 4px 0 20px;
}
/* ---------------- In-box notices/hints (v92.16, 2026-09-08, user
   request) ----------------
   Both a real error (wrong password, failed robot-check, a required
   field left blank) and a guidance message ("please log in to check
   out") used to print in WooCommerce's default wide bordered bar above
   the "Login"/"Register" heading. Moved inside the already-bordered
   box instead — stacking a second bordered box inside this one looked
   wrong — as plain text with no border/background of its own. Severity
   is communicated by weight/color, never by red (this site's sitewide
   grayscale-only UI-color policy, see single-product.css's v87.4
   history): a hint matches the established light-gray descriptive-text
   style (.wholesale-state-box p elsewhere on this page), an error is
   darker and bolder but still small, never colored. Rendered via
   WooCommerce's own `woocommerce_login_form_start` / `_register_
   form_start` hooks (my-account.php) — a genuine flex child of the
   form already, first in DOM among the fields that matter here, but
   given an order more negative than anything else in either form so it
   always renders first regardless. */
.b2b-box-notice { order: -10; font-size: 12.5px; text-align: center; margin: 0 0 20px; }
.b2b-box-hint { color: #666; font-weight: 400; }
.b2b-box-error { color: #111; font-weight: 700; }
.woocommerce-form-login__submit,
.woocommerce-form-register__submit,
.woocommerce-Button.button {
	display: block !important;
	width: 100% !important;
	text-align: center;
	background: #111 !important;
	color: #fff !important;
	border: 1px solid #111 !important;
	padding: 12px 20px !important;
	font-size: 12.5px;
	text-transform: uppercase;
	letter-spacing: .03em;
	font-weight: 700;
	cursor: pointer;
}
/* v92.17 (2026-09-08, user request): the Reset Password button — real
   class confirmed against WooCommerce's own form-lost-password.php
   source as `woocommerce-Button button`, which already matches the
   `.woocommerce-Button.button` selector above by class name — still
   rendered as a small, unstyled default button live, not the full-width
   black treatment Log In/Register get. Since the class DOES match, this
   is the same category of bug already root-caused once on this project
   (v92.3, Checkout's Place Order button): a WooCommerce core stylesheet
   rule for buttons wins over this theme's plain-class selector on
   specificity/cascade grounds that are fragile to chase exactly (and can
   shift between WC versions), not worth re-litigating class-by-class a
   second time. Same fix applied there: `!important` on the properties
   that actually matter for this look (box model + color), so it wins
   unconditionally regardless of which WC core rule was competing. */
.woocommerce-form-login__submit:hover,
.woocommerce-form-register__submit:hover,
.woocommerce-Button.button:hover {
	background: #fff !important;
	color: #111 !important;
}

/* ---------------- Email Verified confirmation (v92.11) ----------------
   Its own view inside .b2b-login-gate, shown instead of the login/
   register form when a visitor lands back here from the verification
   email's link (my-account.php's top-level $just_verified check — see
   that block's own docblock for why this has to work whether or not
   WooCommerce already auto-logged the visitor back in). Boxed and
   centered to match the login/register box above — same wrapper, same
   width — so switching views on this page never visually jumps. */
.b2b-verify-confirm {
	max-width: 420px;
	margin: 60px auto;
	border: 1px solid var(--ink, #111);
	padding: 36px;
	text-align: center;
}
.b2b-verify-confirm h2 {
	font-size: 18px;
	text-transform: uppercase;
	letter-spacing: .03em;
	margin: 0 0 14px;
}
.b2b-verify-confirm p {
	font-size: 13.5px;
	color: #666;
	margin: 0 0 22px;
}
.b2b-verify-confirm .btn {
	display: inline-block;
	background: #111;
	color: #fff;
	border: 1px solid #111;
	padding: 12px 28px;
	font-size: 12.5px;
	text-transform: uppercase;
	letter-spacing: .03em;
	font-weight: 700;
	text-decoration: none;
	cursor: pointer;
}
.b2b-verify-confirm .btn:hover { background: #fff; color: #111; }

/* ---------------- Sign In / Register switch link (v92.11, moved inside
   the box in v92.15) ----------------
   Plain-text link that swaps views — "Don't have an account? Create
   one" on Sign In, "Already have an account? Sign In" on Register
   (my-account.php builds the href with add_query_arg()/
   remove_query_arg()). Through v92.14 this sat as its own unboxed line
   below the form; the user asked for it inside the box, right after the
   submit button instead. Now picks up the border/padding the form left
   open at its own bottom (see .woocommerce-form-login/.woocommerce-form-
   register above) — no top border of its own, so the two pieces read as
   one continuous box with no visible seam right where the button ends
   and this text begins. */
.b2b-auth-toggle {
	max-width: 420px;
	margin: 0 auto 60px;
	border: 1px solid var(--ink, #111);
	border-top: none;
	padding: 0 36px 28px;
	text-align: center;
	font-size: 12.5px;
	color: #666;
}
.b2b-auth-toggle a {
	text-decoration: underline;
	color: #111;
	font-weight: 700;
}

/* ---------------- Dashboard layout ---------------- */
.dash-layout { display: grid; grid-template-columns: 220px 1fr; gap: 36px; padding: 30px 0 60px; align-items: start; }
.dash-sidebar { border: 1px solid var(--line, #ddd); }
.dash-user-box { padding: 16px; border-bottom: 2px solid #111; }
.dash-user-box .name { font-weight: 700; font-size: 13.5px; }
.dash-user-box .name .prefix { font-weight: 400; font-size: 11px; text-transform: uppercase; letter-spacing: .03em; color: #888; display: block; margin-bottom: 3px; }
/* .dash-user-box .company removed in v92.17 — the second line it styled
   (billing_company) was dropped from navigation.php in favor of a single
   First + Last Name line; see that file's own comment for why. */
.dash-nav-link {
	display: block;
	width: 100%;
	text-align: left;
	padding: 13px 16px;
	font-size: 12.5px;
	text-transform: uppercase;
	letter-spacing: .03em;
	font-weight: 600;
	border-bottom: 1px solid var(--line, #ddd);
	color: var(--ink, #111);
}
.dash-sidebar .dash-nav-link:last-child { border-bottom: 0; }
.dash-nav-link:hover { background: var(--bg-soft, #f7f7f7); }
.dash-nav-link.active { background: #111; color: #fff; }

.woocommerce-MyAccount-content h2 {
	font-size: 19px;
	text-transform: uppercase;
	border-bottom: 2px solid #111;
	padding-bottom: 12px;
	margin-bottom: 22px;
}

.verify-banner {
	border: 2px solid #111;
	background: var(--bg-soft, #f7f7f7);
	padding: 14px 18px;
	font-size: 13px;
	margin-bottom: 24px;
	display: flex;
	justify-content: space-between;
	align-items: center;
	gap: 12px;
	flex-wrap: wrap;
}
.verify-banner strong { display: block; margin-bottom: 2px; }
.verify-banner button { background: none; border: 0; text-decoration: underline; font-size: 12px; font-weight: 700; white-space: nowrap; cursor: pointer; }

/* ---------------- Order History ---------------- */
.order-table { width: 100%; border-collapse: collapse; }
.order-table th { text-align: left; font-size: 10.5px; text-transform: uppercase; letter-spacing: .04em; color: #888; border-bottom: 2px solid #111; padding: 0 0 10px; }
.order-table td { border-bottom: 1px solid #eee; padding: 14px 10px 14px 0; font-size: 13px; vertical-align: middle; }
.order-table tr.clickable { cursor: pointer; }
.order-table tr.clickable:hover { background: var(--bg-soft, #f7f7f7); }
.order-number-link { font-weight: 700; text-decoration: underline; }
.view-details-link { font-size: 11.5px; text-decoration: underline; color: #666; }
.status-badge { display: inline-block; font-size: 10.5px; text-transform: uppercase; letter-spacing: .03em; font-weight: 700; padding: 3px 9px; border: 1px solid #111; white-space: nowrap; }
.status-badge.filled { background: #111; color: #fff; }

/* Order Tracking — order-table row link + view-order.php detail section.
 * See includes/class-order-tracking.php. */
.tracking-link { display: block; margin-top: 6px; font-size: 11px; text-decoration: underline; color: #666; }
.tracking-link:hover { color: #111; }
.tracking-section p { margin: 0 0 4px; font-size: 13px; }
.tracking-status { color: #444; }
.tracking-status .description { color: #999; font-size: 11.5px; }

/* ---------------- Pagination (shared naming with the Shop page) ---------------- */
.pagination { display: flex; justify-content: center; gap: 6px; margin-top: 36px; flex-wrap: wrap; }
.pagination a, .pagination span { border: 1px solid #ddd; padding: 8px 13px; font-size: 13px; min-width: 36px; text-align: center; }
.pagination .current { background: #111; color: #fff; border-color: #111; font-weight: 700; }
.pagination .arrow { font-weight: 700; }

/* ---------------- Order Detail ---------------- */
.back-link { display: inline-block; margin-bottom: 16px; font-size: 12.5px; text-decoration: underline; color: #666; }
.order-detail-header { display: flex; justify-content: space-between; align-items: baseline; flex-wrap: wrap; gap: 10px; margin-bottom: 6px; }
.order-detail-header h2 { border: 0; padding: 0; margin: 0; }
.order-detail-meta { font-size: 12.5px; color: #666; margin-bottom: 20px; }
.detail-grid { display: grid; grid-template-columns: 1fr 320px; gap: 32px; align-items: start; }
.detail-section { border: 1px solid var(--line, #ddd); padding: 18px; margin-bottom: 16px; }
.detail-section h4 { font-size: 11px; text-transform: uppercase; letter-spacing: .03em; color: #888; margin: 0 0 10px; }
.detail-line-item { display: flex; gap: 10px; padding: 10px 0; border-bottom: 1px solid #f2f2f2; font-size: 12.5px; }
.detail-line-item:last-child { border-bottom: 0; }
.detail-line-item .thumb { width: 44px; height: 44px; background: #f2f2f2; border: 1px solid #ddd; flex-shrink: 0; overflow: hidden; }
.detail-line-item .thumb img { width: 100%; height: 100%; object-fit: cover; }
.detail-line-item .info h5 { font-size: 12.5px; margin: 0 0 2px; }
.detail-line-item .info .meta { font-size: 11px; color: #888; }
.detail-line-item .line-price { margin-left: auto; font-weight: 700; white-space: nowrap; }
.shipping-address { font-size: 13px; line-height: 1.6; }
.detail-summary-row { display: flex; justify-content: space-between; font-size: 13px; padding: 6px 0; }
.detail-summary-row.total { border-top: 2px solid #111; margin-top: 8px; padding-top: 10px; font-weight: 800; }

/* ---------------- Saved Carts ---------------- */
.saved-cart-row { display: flex; justify-content: space-between; align-items: center; border: 1px solid var(--line, #ddd); padding: 16px 18px; margin-bottom: 12px; }
.saved-cart-row .name { font-weight: 700; font-size: 13.5px; margin-bottom: 3px; }
.saved-cart-row .meta { font-size: 12px; color: #888; }
.saved-cart-actions { display: flex; gap: 8px; }

/* ---------------- Delete-confirm modal (v80, 2026-09-04) ----------------
   #b2bConfirmModal, woocommerce/myaccount/my-account.php — .modal-overlay/
   .modal-box/.modal-close/.modal-box h3 live in base.css (shared with
   every other modal in the theme); this is just the button row this
   modal's two actions need, which no other account content required
   until now. */
.confirm-modal-actions { display: flex; gap: 10px; margin-top: 18px; }
.confirm-modal-actions .btn { flex: 1; margin-top: 0; }

/* ---------------- Wholesale Account ---------------- */
.wholesale-state-box { border: 1px solid var(--ink, #111); padding: 28px; text-align: center; }
.wholesale-state-box h3 { text-transform: uppercase; font-size: 15px; margin: 0 0 10px; }
.wholesale-state-box p { color: #666; font-size: 13.5px; max-width: 440px; margin: 0 auto 18px; }
.wholesale-perks { text-align: left; max-width: 380px; margin: 0 auto 22px; font-size: 13px; list-style: none; padding: 0; }
.wholesale-perks li { margin-bottom: 6px; padding-left: 1.4em; position: relative; }
.wholesale-perks li::before { content: "\2713"; position: absolute; left: 0; }
.wholesale-form { text-align: left; max-width: 420px; margin: 0 auto; }

/* ---------------- WooCommerce's native Company Info (billing address)
   and Account Settings forms — styled via their own core classes,
   template logic untouched. ---------------- */
.woocommerce-address-fields__field-wrapper,
.woocommerce-EditAccountForm { max-width: 640px; }
.woocommerce-address-fields__field-wrapper > .form-row,
.woocommerce-EditAccountForm > .form-row { margin-bottom: 0; }
.woocommerce-address-fields__field-wrapper .form-row-first,
.woocommerce-address-fields__field-wrapper .form-row-last,
.woocommerce-EditAccountForm .form-row-first,
.woocommerce-EditAccountForm .form-row-last {
	display: inline-block;
	width: 48%;
}
.woocommerce-address-fields__field-wrapper .form-row-last,
.woocommerce-EditAccountForm .form-row-last { float: right; }
.woocommerce-EditAccountForm fieldset { border: 1px solid var(--line, #ddd); padding: 16px; margin: 20px 0; }
.woocommerce-EditAccountForm legend { font-size: 12px; text-transform: uppercase; letter-spacing: .03em; font-weight: 700; padding: 0 6px; }
.woocommerce-address-fields p:last-child,
.woocommerce-EditAccountForm p:last-child { margin-top: 20px; }

/* Submit buttons — targeted by [type="submit"] rather than an exact
   class name. WooCommerce's own edit-address/edit-account submit
   button class list has genuinely varied across versions (confirmed by
   checking multiple WC core source snapshots while investigating this),
   so matching on the one thing that's actually stable — it's the
   form's only submit button — is more robust than chasing an exact
   class string a second time. */
.woocommerce-address-fields button[type="submit"],
.woocommerce-EditAccountForm button[type="submit"] {
	display: inline-block;
	background: #111;
	color: #fff;
	border: 1px solid #111;
	padding: 12px 20px;
	font-size: 12.5px;
	text-transform: uppercase;
	letter-spacing: .03em;
	font-weight: 700;
	cursor: pointer;
}
.woocommerce-address-fields button[type="submit"]:hover,
.woocommerce-EditAccountForm button[type="submit"]:hover { background: #fff; color: #111; }

/* Field hint/description text (e.g. Account Settings' "This will be how
   your name will be displayed..." under Display name). NOT
   <p class="description"> as WC's general documentation/older versions
   suggest — confirmed via live DevTools inspection that this specific
   WC version (11.0.1) uses an accessibility-pattern span instead:
   <span id="account_display_name_description"><em>...</em></span>,
   linked to its input via aria-describedby. Matched on the [id$="_description"]
   suffix rather than a hardcoded field name, since any other field
   using the same WC pattern would get an ID built the same way.
   Matches .b2b-matrix-note (single-product.css) exactly, per the
   project's established tip-text convention — including overriding the
   browser's default italic <em> styling, which was fighting that. */
.woocommerce-EditAccountForm span[id$="_description"],
.woocommerce-address-fields span[id$="_description"] {
	display: block;
	font-size: 11px;
	color: #999;
	margin-top: 8px;
	margin-bottom: 16px;
	font-style: normal;
}
.woocommerce-EditAccountForm span[id$="_description"] em,
.woocommerce-address-fields span[id$="_description"] em {
	font-style: normal;
}

/* ---------------- WooCommerce's native Address Book overview
   (myaccount/my-address.php — shown after successfully saving Company
   Info, since WC redirects back to this overview rather than the edit
   form). Previously entirely unstyled, causing Billing/Shipping to
   float without any grouping or alignment. ---------------- */
.woocommerce-Addresses.col2-set {
	display: grid;
	grid-template-columns: 1fr 1fr;
	gap: 24px;
	margin-top: 8px;
}
.woocommerce-Address {
	border: 1px solid var(--line, #ddd);
	padding: 18px;
}
/* WooCommerce's own bundled default CSS (still loaded — never
   dequeued) sets width:48%/float:left directly on these same boxes via
   a 3-class selector (.woocommerce .col2-set .col-1, confirmed live via
   DevTools). float is a no-op on a grid item, but width isn't — so
   explicitly reset both here with higher specificity (5 classes total,
   ancestor + child) rather than leave it to chance.
   Also forcing explicit grid-column/grid-row/justify-self/order on each
   box specifically (rather than relying on default auto-placement) —
   confirmed live via DevTools that even after the float/width reset
   above took effect, the two boxes were still rendering in swapped
   left/right positions, on two different rows, and narrower than their
   grid track, despite the container correctly computing display:grid.
   Rather than keep chasing whichever WC rule indirectly causes that,
   this makes placement and sizing explicit and immune to it. */
.woocommerce-Addresses.col2-set.addresses .woocommerce-Address {
	float: none;
	width: auto;
	justify-self: stretch;
	order: 0;
}
.woocommerce-Addresses.col2-set.addresses .u-column1.woocommerce-Address {
	grid-column: 1;
	grid-row: 1;
}
.woocommerce-Addresses.col2-set.addresses .u-column2.woocommerce-Address {
	grid-column: 2;
	grid-row: 1;
}
.woocommerce-Address-title {
	display: flex;
	justify-content: space-between;
	align-items: baseline;
	gap: 10px;
	margin: 0 0 10px;
	border-bottom: 1px solid var(--line, #ddd);
	padding-bottom: 8px;
}
.woocommerce-Addresses .woocommerce-Address-title h2 {
	font-size: 11px;
	text-transform: uppercase;
	letter-spacing: .03em;
	color: #888;
	margin: 0;
	border: 0;
	padding: 0;
}
.woocommerce-Address-title .edit {
	font-size: 11.5px;
	text-decoration: underline;
	color: #666;
	white-space: nowrap;
}
.woocommerce-Address address {
	font-style: normal;
	font-size: 13px;
	line-height: 1.6;
}

/* ---------------- Responsive ---------------- */
@media (max-width: 900px) {
	.dash-layout { grid-template-columns: 1fr; }
	.detail-grid { grid-template-columns: 1fr; }
	.field-row { grid-template-columns: 1fr; }
	.woocommerce-Addresses.col2-set { grid-template-columns: 1fr; }
	.woocommerce-Addresses.col2-set.addresses .u-column2.woocommerce-Address { grid-column: 1; grid-row: 2; }
	.woocommerce-address-fields__field-wrapper .form-row-first,
	.woocommerce-address-fields__field-wrapper .form-row-last,
	.woocommerce-EditAccountForm .form-row-first,
	.woocommerce-EditAccountForm .form-row-last {
		width: 100%;
		float: none;
	}
}

@media (max-width: 600px) {
	/*
	 * ---- Order History table -> one card per order (mobile-audit "My
	 * Account" pass, 2026-09-15) ----
	 * Same table -> block reflow technique already used for the Single
	 * Product page's .pricing-matrix (single-product.css) — this table
	 * had no mobile treatment at all, and a real <table> doesn't reflow
	 * on its own. Found via Playwright: below 600px this table's own
	 * min-content width (~406px, from six columns of unwrapped
	 * order#/date/status-badge/total/action text) was forcing the ENTIRE
	 * .dash-layout grid to blow out to that same width, since both grid
	 * items share one `1fr` column track and CSS Grid's default
	 * `min-width: auto` lets a descendant's min-content grow the track
	 * past the viewport — so this wasn't just the table overflowing, it
	 * was pushing the sidebar and every other dashboard panel off-screen
	 * with it. <thead> is hidden since each cell now carries its own
	 * visible label via `data-label` (orders.php) rendered through
	 * `::before { content: attr(data-label) }`. Desktop keeps the real
	 * table, completely untouched — nothing here loads above 600px.
	 *
	 * Known tradeoff, accepted rather than solved here (same as
	 * .pricing-matrix): hiding <thead> removes the table's native
	 * row/column semantics for screen readers along with it — flagging
	 * it rather than leaving it undocumented.
	 */
	.order-table,
	.order-table tbody,
	.order-table tr,
	.order-table td {
		display: block;
		width: auto;
	}
	.order-table thead {
		display: none;
	}
	.order-table tr {
		border: 1px solid #111;
		margin-bottom: 12px;
	}
	.order-table tr:last-child {
		margin-bottom: 0;
	}
	.order-table td {
		display: flex;
		align-items: center;
		justify-content: space-between;
		gap: 12px;
		border: 0;
		border-bottom: 1px solid #eee;
		padding: 9px 12px;
		text-align: right;
	}
	.order-table td:last-child {
		border-bottom: 0;
	}
	.order-table td::before {
		content: attr( data-label );
		font-weight: 700;
		text-transform: uppercase;
		font-size: 10.5px;
		letter-spacing: 0.03em;
		color: #888;
		text-align: left;
	}
	/* Order # is the card's own header/identity, not a label/value row —
	   no ::before label needed, matches .pricing-matrix .size-cell's own
	   same treatment for the same reason. */
	.order-table td:first-child {
		display: block;
		text-align: left;
		padding: 12px 12px 9px;
		font-size: 14px;
	}
	.order-table td:first-child::before {
		content: none;
	}
	/* Actions (Reorder + Track Package) and View Details: these are
	   calls to action, not label/value data, so — same reasoning as the
	   Order # cell above — no ::before label either. Block, full width,
	   left-aligned, so the Reorder button doesn't fight the row's own
	   flex centering. */
	.order-table td.order-actions-cell,
	.order-table td.order-view-cell {
		display: block;
		text-align: left;
	}
	.order-table td.order-actions-cell::before,
	.order-table td.order-view-cell::before {
		content: none;
	}
	.order-table td.order-actions-cell .reorder-btn {
		margin-right: 12px;
	}

	/*
	 * ---- Saved Carts / Saved Quotes rows: guard against a long name
	 * pushing the Load/Delete actions off-screen ----
	 * .saved-cart-row is a plain `justify-content: space-between` flex
	 * row with no wrap — fine for the short sample names used while
	 * building this, but a real saved cart/quote name is free text a
	 * user typed, and flex items default to `min-width: auto`, so a
	 * long, unbreakable-enough name could in principle stretch this row
	 * past the viewport the same way the order table just did. Stacking
	 * name/meta above actions on mobile removes that risk entirely
	 * rather than relying on the name column happening to be short.
	 */
	.saved-cart-row {
		flex-direction: column;
		align-items: stretch;
		gap: 12px;
	}
	.saved-cart-actions {
		justify-content: flex-end;
	}
}