carries `align:full`
plus this theme's plain custom-group convention (no core/columns —
see hero-shop-spotlight/style.css for the same "plain wp:group +
className" pattern used for one-off asymmetric layouts elsewhere in
this theme) so it can bleed to the true viewport edge, matching the
header's own alignfull bars (parts/header.html, dot-utility-bar /
dot-main-nav). Two children: `.dot-myaccount-login__content-col` (just
post-content — the page's own title block was removed per client
request, 2026-07-13, so nothing but the login/register form renders,
rendered by WooCommerce's [woocommerce_my_account]
shortcode) and `.dot-myaccount-login__image-col` (the placeholder
image), turned into a two-track CSS grid below so the image column can
reach the real right edge of the viewport instead of stopping at the
1240px content container like every other section on the site. */
body.dot-myaccount-login main {
display: grid;
grid-template-columns: minmax(0, 1fr) minmax(360px, 42%);
column-gap: clamp(2rem, 5vw, 4rem);
max-width: none;
margin-top: var(--wp--preset--spacing--50);
margin-bottom: 0;
}
/* "Closer to a full-viewport-height app screen than a compact contained
card" (brief). 132px approximates the header's combined height
(.dot-utility-bar's 44px min-height + .dot-main-nav's 72px min-height,
plus hairline borders) so the screen reads as filling the rest of the
viewport without actually measuring the live header via JS. Clamped
between a 560px floor (so short viewports/zoomed text never crush the
form) and a 900px ceiling (so ultra-tall monitors don't stretch the
placeholder image into an absurd column). Grid's default
`align-content: normal` computes to `stretch` for auto-sized tracks, so
the single implicit row — and every item in it — fills this height
automatically; no extra `height`/`align-items` rule needed. Desktop/
tablet only (see breakpoint below) — a phone-width single column form
doesn't want to be stretched to near-viewport height with mostly empty
space beneath it. */
@media (min-width: 700px) {
body.dot-myaccount-login main {
min-height: clamp(560px, calc(100dvh - 132px), 900px);
}
}
/* Content column: flex, capped to a comfortable measure so the
login/register form doesn't stretch edge-to-edge on the wide track next
to it.
BUG FIX (2026-07-22): was `justify-content: center`, vertically centering
the form within the (often much taller-than-its-content) grid row. Per
client report, this put the "Login" heading and fields ~500px down the
page — well below the fold — instead of near the top of the viewport
as intended by the "closer to a full-viewport-height app screen" brief
below. Changed to `flex-start` so the form anchors to the top of the
column (below its own padding-block) regardless of how tall the row
ends up being, matching how the client described wanting this to look.
(This was compounded by a second bug — the image column's own intrinsic
height was inflating the row far past main's intended clamp — fixed
separately in the image-col/image rules below.)
Left inset: match the header logo/nav's ACTUAL rendered left edge, not
`.shell`'s own clamp(1.25rem, 4vw, 3rem) padding-inline. Verified live via
getBoundingClientRect(): `.dot-wordmark` sits at exactly (100vw - 1240px)
/ 2 from the true viewport edge (340px at a 1920px viewport) — NOT that
offset plus `.shell`'s clamp padding. That's because `.dot-main-nav__inner`
/ `.dot-utility-bar .shell` deliberately zero `.shell`'s own padding-inline
(base.css, "Cancel `.shell`'s own padding-inline... in the header", 2026-
07-12) — the header relies solely on the root has-global-padding (fixed
28px) plus centering, and the two symmetric-padding terms happen to cancel
out algebraically, leaving pure `(100vw - 1240px) / 2` once the viewport
is wider than the content size. This grid's `main` carries no
has-global-padding of its own (by design, so the image column can bleed
to the true edge), so the content column has to supply both terms itself:
the same centering offset, floored at the root gutter (28px) for
viewports at/under 1240px + gutter, where centering hasn't kicked in.
Confirmed live: heading/login form left edge now matches `.dot-wordmark`
left edge exactly at 1920px and 1440px.
BUG FIX (2026-07-13): this theme inherits WordPress core's global
`html { box-sizing: border-box } *, *::before, *::after { box-sizing:
inherit }` reset (wp-includes/css/dist/block-library/style.css) — confirmed
live via getComputedStyle. That means the `max-width: 560px` above caps the
ENTIRE border-box, padding included, not just the readable content. At a
1920px viewport the left inset alone is 340px, so 560 - 340 - 48(end
padding) left only ~172px for the heading/inputs — the reported "smushed"
layout (heading wrapping mid-word, ~170px-wide inputs).
Fix: keep the sitewide border-box convention (don't override box-sizing
locally — this element's children, including the login form's inputs/
buttons, would inherit that override too via the `inherit` chain above,
which is a bigger blast radius than this one bug), and instead fold the
two padding expressions into `max-width` itself so the border-box grows to
accommodate them while the actual content measure stays a true 560px
regardless of viewport. Both the padding rules and max-width read from the
same two custom properties so the numbers can't drift apart. */
body.dot-myaccount-login .dot-myaccount-login__content-col {
--dot-myaccount-login-pad-start: max(
var(--wp--style--root--padding-left, 28px),
calc((100vw - var(--wp--style--global--content-size, 1240px)) / 2)
);
--dot-myaccount-login-pad-end: clamp(1.25rem, 4vw, 3rem);
display: flex;
flex-direction: column;
justify-content: flex-start;
max-width: calc(
560px + var(--dot-myaccount-login-pad-start) + var(--dot-myaccount-login-pad-end)
);
padding-inline-start: var(--dot-myaccount-login-pad-start);
padding-inline-end: var(--dot-myaccount-login-pad-end);
padding-block: clamp(2rem, 6vw, 3.5rem);
}
/* The login/register form renders inside core's post-content block
(`.entry-content.wp-block-post-content`), which carries its own
`has-global-padding` class and therefore its own 28px padding-left/right —
stacking on top of the content column's own inset above and pushing the
form 28px further right than the "My account" heading beside it
(confirmed live via getBoundingClientRect: heading at the shell inset,
form 28px further in). That class exists for post-content used as
ordinary full-width page content; here it's nested inside an already-
padded, deliberately narrow (max-width: 560px) column, so its own padding
is pure double-counting. Zeroed the same way `.dot-utility-bar .shell` /
`.dot-main-nav__inner` cancel `.shell`'s padding in the header (base.css)
— one of these two padding sources should win, not both. */
body.dot-myaccount-login .dot-myaccount-login__content-col .entry-content.wp-block-post-content {
padding-inline: 0;
}
/* Image column: a plain grid item, stretched to the row's full height by
the default `align-content: stretch` behavior noted above.
BUG FIX (2026-07-22): "stretched to the row's full height" was never
actually true once a real (portrait, 2400x4267) photo replaced the
placeholder — confirmed live via getBoundingClientRect at 1440x900: the
grid row (main) rendered at ~1105px tall, blowing straight through the
560-900px clamp() on main's min-height (woocommerce-myaccount.css
~line 591), and the login form — vertically centered in that oversized
column, see the content-col fix below — ended up ~500px down the page,
which is exactly the client-reported "login is below the fold" bug.
Root cause: grid row tracks are sized *before* align-content stretch is
applied, using each item's own normal-flow content. The `![]()
` (below)
had `height: 100%`, but percentages can't resolve against an
indefinite/auto-sizing row, so browsers fall back to computing its
height from its intrinsic aspect ratio instead — a 605px-wide portrait
photo at that ratio is ~1076px tall, which is what actually drove the
row (and therefore `main`, and the sibling content-col) to ~1105px,
overriding the intended viewport-based clamp entirely.
Fix: `position: relative` here so the `![]()
` can be pulled out of
normal flow below. Out-of-flow (absolutely positioned) descendants
don't contribute to a grid item's intrinsic content size, so the row
goes back to being sized only by `main`'s own min-height clamp, and the
image just fills whatever height that clamp resolves to. */
body.dot-myaccount-login .dot-myaccount-login__image-col {
position: relative;
min-width: 0;
}
/* Real photo (swapped in 2026-07-13 — was a diagonal-stripe "no photo yet"
placeholder, the same device used for the Shop landing heroes in
blocks/hero-shop-spotlight/style.css, .dot-hero-shop-spotlight__image--
placeholder; that placeholder rule and its --placeholder modifier class
are removed now that a real ![]()
is in templates/page-my-account.html).
BUG FIX (2026-07-22): switched from being a normal-flow grid item sized
via `width/height: 100%` to `position: absolute; inset: 0` filling the
now-`position: relative` column above. See that rule's comment for why:
this photo's own tall intrinsic aspect ratio was inflating the whole
grid row past the intended viewport-based clamp. Taking it out of flow
removes it from the row's intrinsic-size computation entirely, so it
just paints inside whatever box the column ends up being — still
`object-fit: cover` + centered `object-position` to crop rather than
distort, matching how the placeholder's background-color/-image
previously filled the same box. The right edge is flattened (no
border-radius, no border) because that edge is the true viewport edge,
not a card boundary sitting on the page's own background. */
body.dot-myaccount-login .dot-myaccount-login__image {
display: block;
position: absolute;
inset: 0;
width: 100%;
height: 100%;
min-height: 320px;
object-fit: cover;
object-position: center;
border-radius: var(--r-lg) 0 0 var(--r-lg);
border: 1px solid var(--line);
border-right: none;
}
/* Below 700px the image column isn't the point of a narrow-viewport login
screen — drop it (and fall back to a single grid track) so the form is
what visitors scroll to first, full width and unconstrained by the
636px measure cap above. Matches the min-width gate on the tall
min-height rule above, so the two behaviors (drop the image / stop
forcing tall) change together at one breakpoint instead of two. */
@media (max-width: 699px) {
body.dot-myaccount-login main {
grid-template-columns: 1fr;
}
body.dot-myaccount-login .dot-myaccount-login__image-col {
display: none;
}
body.dot-myaccount-login .dot-myaccount-login__content-col {
max-width: none;
padding-inline-end: var(--wp--style--root--padding-right, 28px);
}
}
/* ---- Login form polish ----
Beyond the sitewide baseline above (.woocommerce-Input, .button), this
dedicated screen gets a bit more room to breathe and a stronger sense
of a real "app" surface: taller inputs, a full-width primary action,
and an extra focus glow layered on top of (never replacing) the
sitewide `:focus-visible` outline rule so the accessibility-critical
keyboard-focus indicator is unchanged.
`#customer_login.col2-set` never actually renders on this store today
— that markup only exists when My Account registration is enabled
(woocommerce/templates/myaccount/form-login.php), and it's currently
off, so the shortcode outputs a flat `.woocommerce > h2 + form`
structure with no `#customer_login` wrapper at all (confirmed via the
live DOM, not assumed). The rules below target that real, flat
structure directly. The `#customer_login.col2-set` gap/margin rule
further down this section is left in place, inert, for the day
registration is turned back on — it costs nothing while unmatched. */
body.dot-myaccount-login .woocommerce {
margin-top: clamp(1.5rem, 4vw, 2.5rem);
}
body.dot-myaccount-login .woocommerce > h2 {
margin: 0 0 1.25rem;
font-size: var(--step-1);
font-weight: 800;
letter-spacing: var(--letter-spacing-display);
}
body.dot-myaccount-login #customer_login.col2-set {
gap: clamp(2rem, 5vw, 3rem);
margin-top: clamp(1.5rem, 4vw, 2.5rem);
}
body.dot-myaccount-login .woocommerce-form-login .form-row,
body.dot-myaccount-login .woocommerce-form-register .form-row {
margin-bottom: 1.1rem;
}
body.dot-myaccount-login .woocommerce-Input {
padding: 0.85em 1em;
font-size: var(--step-0);
transition: border-color var(--motion-med) var(--ease),
box-shadow var(--motion-med) var(--ease);
}
/* Supplemental focus glow — deliberately additive to, never a replacement
for, the global 3px --focus outline (this file, "Accessibility: visible
keyboard focus" above). That rule targets `:focus-visible` and must stay
the accessibility-critical indicator; this rule only touches
border-color/box-shadow, never `outline`, so it can't out-specify or
suppress it on keyboard focus regardless of selector specificity. This
is a softer, always-on (mouse or keyboard) tint so the field itself
looks "lit up," matching the more app-like tone the rest of this screen
is going for. `color-mix()` keeps the glow's hue matched to whichever of
the three accessibility-preferences theme variants is active (--accent
flips between jet black and off-white) without a separate override per
variant; unsupported browsers simply skip the box-shadow. */
body.dot-myaccount-login .woocommerce-Input:focus {
border-color: var(--accent);
box-shadow: 0 0 0 4px color-mix(in srgb, var(--accent) 16%, transparent);
}
/* WooCommerce's core form-login.php template puts the "Remember me"
checkbox+label, the login nonce field, AND the submit button all inside
this ONE — there's no separate row for the button.
Flexing the row (needed to align the checkbox with its label) without
accounting for the button squeezed the button and label into a shared
row, which is the confirmed root cause of "Remember" / "me" wrapping
onto two lines — the label was being flex-shrunk to make room for the
button beside it (verified live: label rendered ~83px wide before this
fix). `flex-wrap: wrap` plus giving the button `flex-basis: 100%` and a
later `order` pushes it onto its own full-width line below the
checkbox row instead, so the label keeps its natural (nowrap) width. */
body.dot-myaccount-login .woocommerce-form-login .form-row:has(input[type='checkbox']) {
display: flex;
flex-wrap: wrap;
align-items: center;
gap: 0.75rem 1rem;
}
body.dot-myaccount-login .woocommerce-form-login .form-row:has(input[type='checkbox']) label {
display: flex;
align-items: center;
gap: 0.5rem;
margin-bottom: 0;
white-space: nowrap;
}
/* Submit + "Lost your password?" row: full-width primary button (a bigger,
more deliberate tap target than the sitewide auto-width pill), with the
secondary link given its own line below rather than crowding the
button's trailing edge. `flex-basis: 100%` + `order` (only meaningful
inside the flex row above, harmless no-ops for the register form's
plain-block submit button) is what forces the button onto its own line
under "Remember me" rather than beside it. */
body.dot-myaccount-login .woocommerce-form-login button[type='submit'],
body.dot-myaccount-login .woocommerce-form-register button[type='submit'] {
width: 100%;
padding: 0.85em 1.35em;
font-size: var(--step-0);
margin-bottom: 0.75rem;
}
body.dot-myaccount-login .woocommerce-form-login .form-row:has(input[type='checkbox']) button[type='submit'] {
flex: 1 1 100%;
order: 3;
}
body.dot-myaccount-login .woocommerce-LostPassword {
margin: 0;
font-size: var(--step--1);
}
/* Left-edge alignment bug (2026-07-13): WooCommerce auto-enqueues a
block-theme compat stylesheet (assets/css/twenty-twenty-three.css) for
any active block/FSE theme that doesn't opt out, and that file carries
`.woocommerce-account .woocommerce-form-login { max-width: 516px;
margin: 0 auto; }` — confirmed live via the page's actual matched CSS
rules (document.styleSheets), not assumed. That centers the form at
516px inside this screen's already-narrow 560px content column,
producing a ~22px inset on both sides relative to the "Login" heading
(a sibling `.woocommerce > h2`, unaffected by that compat rule), which
is the reported leftover left-indent. This selector
(`body.dot-myaccount-login .woocommerce-form-login`, specificity 0,2,1)
already outweighs the compat rule's 0,2,0, so it wins regardless of
stylesheet load order — no `!important` needed. Undoing both properties
here rather than overriding just `margin-left` so the form also stops
being artificially narrower than its column. */
body.dot-myaccount-login .woocommerce-form-login {
max-width: none;
margin: 0;
}