/* ========================================================================== T22 — Register (route customer/account/create, body class customer-account-create) Comp: design/store-theme/03-harvest-food/colors/Wheat/pages/T22 Register.dc.html ONE centred card in a 720px column — unlike T21's two-card row. Uppercase section labels, a 1fr 1fr name row, the newsletter opt-in, a password-strength bar with its state word beside it, and a fit-content CTA. --------------------------------------------------------------------------- THE CENSUS - the STRUCTURALLY SIGNIFICANT elements of the `.form-create-account` subtree. IT IS NOT THE FULL TREE, AND SAYING SO WAS THE DEFECT. Five hand-maintained versions have now been wrong five times: v5 claimed "EVERY child, painted or not... the full tree now" and listed 44 of 65 - missing a fourth hidden input (`assistance_allowed`, a direct child of a `.field.choice` this list DOES describe) and all twelve ``s. The honest scope is the one below, and the full tree is reproduced by COMMAND rather than by hand: document.querySelectorAll('form.form-create-account *').length -> 65 Both S4 and S7 recommend emitting this from the same walk a reviewer runs and diffing it in CI; until that exists, a hand-written tree of a DOM nobody controls will keep drifting, and the fix is to stop claiming completeness rather than to try harder. The header used to say "the visible subtree" while the body listed three non-painting elements; S4 flagged it cannot be both. It is the full tree now, because the sheet STYLES elements that never paint (the two `
`s) and a census excluding them cannot justify those rules. **THIS IS THE SECOND VERSION. THE FIRST WAS WRONG IN FOUR PLACES** while its docblock claimed it had been "taken from the served HTML before a line of this was written" and "derived, not copied" precisely because T21's was wrong three times. S1 counted it live: form.form.create.account.form-create-account > input[type=hidden] (form_key) > fieldset.fieldset.create.info > legend.legend > br <- STYLED at section 3, was MISSING > input[type=hidden] x2 > .field.field-name-firstname.required > label.label > .control > input.input-text > .field.field-name-lastname.required > label.label > .control > input.input-text > .field.choice.newsletter (input.checkbox and label.label are SIBLINGS) > .field.choice (#assistance_allowed_checkbox, "Allow remote shopping assistance") > .field-tooltip.toggle > span.label (clip-rect, id=tooltip-label) > .field-tooltip-action.action-help > .field-tooltip-content > fieldset.fieldset.create.account > legend.legend > br <- STYLED at section 3, was MISSING > .field.required > label.label > .control > input.input-text > .field.password.required > label.label > .control > input.input-text > #password-strength-meter-container > .password-strength-meter > span#password-strength-meter-label > .field.confirmation.required > .field.choice (#show-password, "Show Password") - MISSING FROM v2, found by S3. A painted element THIS SHEET STYLES: the `.field.choice` rule at section 4 makes it a 13px row, and it was not in the list. Third consecutive version of this census to be wrong, and the second to be wrong in exactly the shape the previous reviewer had already named. FOURTH VERSION, FOURTH SET OF ERRORS (S4): it omitted the two `
` elements - which section 3 styles and which this header calls "load-bearing" - plus three hidden inputs. An element the sheet styles and the docblock calls load-bearing, absent from the census, is the census failing its own stated test. Four hand-maintained versions of a DOM nobody controls have drifted four times; S4's suggestion, recorded for whoever acts on it, is to EMIT the census from the same walk a reviewer runs and diff it in CI. > fieldset.fieldset.additional_info (renders EMPTY — 0 children, height 0) > .actions-toolbar > .primary > button.action.submit.primary > .secondary > a.action.back (display:none at EVERY width — see §8) THE FOUR ERRORS, kept because the pattern is the point: the `.field-tooltip` was placed in the WRONG FIELDSET at the WRONG DEPTH (declared as a sibling of `.field.choice` in `create.account`; it is a DESCENDANT of a different `.field.choice` in `create.info`); that `.field.choice` was missing entirely; `fieldset.additional_info` was missing entirely; and `a.action.back` was listed as rendered when it never paints. Worse, the misplacement then SHAPED CODE — `.field-tooltip { margin-left: 8px }` was written for a context the element is not in, and lands acceptably only by luck. --------------------------------------------------------------------------- WHAT BLANK DOES HERE, re-derived from the deployed styles-m/styles-l: .form.create.account { min-width: 600px; width: 50% } >=768 .column:not(.sidebar-main) form .actions-toolbar { margin-left: 25.8% } (0,3,1) .fieldset > .field::before/::after { content:''; display:table } >=768 .actions-toolbar::before/::after { content:''; display:table } >=768 .actions-toolbar > .secondary .action.back { display: none } (0,4,0) .field-tooltip { position:absolute; right:0; top:1px } .field-tooltip .field-tooltip-action::before { content:'\e623'; font-size:24px; color:#bbb } .field-tooltip .label { clip:rect(0,0,0,0); position:absolute } .password-strength-meter { background:#f4f4f4; height:32px; line-height:32px } .password-strength-meter::before{ width 25/50/75/100% by state class } 1. `min-width: 600px` IS RESET — BUT MY STATED REASON FOR IT WAS FALSE. This file used to claim min-width was "the dangerous half" that could force horizontal overflow between 768 and ~1000. S1 refuted it with a counterfactual at 900px: re-imposing Blank's exact `width:50%; min-width:600px` gives a 600px form inside a 720px parent, `scrollWidth == innerWidth`, no overflow — with a positive control (`min-width:3000px`) proving the probe detects overflow when it exists. `.page-main` is pinned to 768px with 24px padding, so content is never wider than 720px and a 600px floor cannot overflow it. The reset is still right; the argument for it was not, and the extra sweep widths it justified were justified by nothing. 2. THE PHANTOM GENERATED BOXES are reset up front for every container this sheet makes flex or grid — §2 — whether or not each is currently observed to matter. S1 confirmed that part is done properly, including the `.legend + br` rule, which is load-bearing: without it the `
` would be a grid item. 3. AN HTML `` IS NOT A FLEX OR GRID ITEM. This is §3's story and it cost a CRITICAL — see there. 4. THE TOOLTIP IS A REAL CONTROL. Its `.label` and its action carry Blank's clip-rect accessible name (`id=tooltip-label`, text "Tooltip"). LEFT ALONE. The comp does not draw the tooltip; an artboard omitting a control is not authority to remove it or strip its name. Its `#bbb` icon measures **1.92:1 on the white card in all five palettes**, against WCAG 1.4.11's 3:1 — filed as register #47, not patched here. PALETTE: every colour is a var(--hrv-*). No hex, no !important. ========================================================================== */ /* -------------------------------------------------------------------------- 1. Page frame -------------------------------------------------------------------------- */ .customer-account-create .page-main { max-width: 768px; /* 720 comp column + 2x24 padding */ padding-left: 24px; padding-right: 24px; padding-top: 48px; } .customer-account-create .page-title-wrapper { text-align: center; } .customer-account-create .page-title-wrapper .page-title { font-family: var(--hrv-font-display); font-weight: 700; font-size: 32px; line-height: 1.12; margin: 0; text-wrap: balance; } /* -------------------------------------------------------------------------- 2. The card, and the reset for every generated box it would otherwise promote `.form.create.account` is (0,3,0); this is (0,4,0). -------------------------------------------------------------------------- */ .customer-account-create .column.main .form.create.account { width: auto; min-width: 0; max-width: none; float: none; margin: 28px 0 0; background: var(--hrv-surface); border: 1px solid var(--hrv-border); border-radius: var(--hrv-radius); padding: 32px; display: flex; flex-direction: column; gap: 16px; } .customer-account-create .form.create.account::before, .customer-account-create .form.create.account::after, .customer-account-create .form.create.account .fieldset::before, .customer-account-create .form.create.account .fieldset::after, .customer-account-create .form.create.account .fieldset > .field::before, .customer-account-create .form.create.account .fieldset > .field::after, .customer-account-create .form.create.account .actions-toolbar::before, .customer-account-create .form.create.account .actions-toolbar::after { display: none; } /* `fieldset.additional_info` renders with zero children and zero height, but it is still a flex item and still consumes one 16px `gap` — S1 measured 32px between the last fieldset and the toolbar against 16px with this rule. `:empty` would not match (the element contains whitespace), so it is targeted directly and will simply stop applying the day Magento puts something in it. S3 m2 measured the degradation precisely, and it is sharper than "real content": appending a single `` flips the fieldset `none -> flex` and restores the 16px phantom gap. So any module that drops a HIDDEN field into `additional_info` silently reintroduces the defect this rule exists to remove. `CSS.supports('selector(:has(*))')` is true on this engine. */ .customer-account-create .form.create.account .fieldset.additional_info:not(:has(*)) { display: none; } /* -------------------------------------------------------------------------- 3. Fieldsets and legends CRITICAL, and it is a fact about HTML rather than about Blank: an `` is the fieldset's RENDERED LEGEND. It is taken out of the fieldset's formatting context and NEVER becomes a flex or grid item. The first version made both fieldsets flex/grid containers with `gap`, set `float: none` on the legend and disabled Blank's `
` — removing BOTH mechanisms Blank used to give the legend its own row — and replaced them with a `gap` that cannot reach it. Measured result: **0px** between each legend and its first field, at every viewport, with `grid-column: 1 / -1` computing in the CSSOM and producing no layout at all. A match-count dead-CSS audit passes that cleanly. It was worse than a spacing bug because legend and field-label typography were BYTE-IDENTICAL, so the page rendered `PERSONAL INFORMATION` / `FIRST NAME *` as one undifferentiated block. Spacing is restored with margin — which a legend does honour — and the two are now typographically distinct (S1 SUGGESTION 3): the comp has no field labels at all, so the section label must out-rank them rather than match them. -------------------------------------------------------------------------- */ .customer-account-create .form.create.account .fieldset { margin: 0; padding: 0; border: 0; display: flex; flex-direction: column; gap: 16px; } .customer-account-create .form.create.account .fieldset > .legend { font-family: var(--hrv-font-body); font-size: 13px; font-weight: 700; text-transform: uppercase; letter-spacing: 0.08em; color: var(--hrv-text); border: 0; padding: 0; float: none; width: auto; margin: 0 0 12px; } .customer-account-create .form.create.account .fieldset.create.account > .legend { margin-top: 8px; /* the comp's second section label carries this */ } .customer-account-create .form.create.account .fieldset > .legend + br { display: none; } /* -------------------------------------------------------------------------- 4. Fields INPUT PAINT IS OWNED BY `web/css/components/_forms.css` AND IS NOT RE-DECLARED HERE. The first version restated ten declarations, seven of them byte-identical to the component and two SILENTLY DIVERGENT (`--hrv-radius-sm` against the component's `-md`, and `12px 16px` padding against `12px 14px`) — so the register page's inputs were shaped unlike every other form in the theme with nothing saying why. That is exactly the ownership enumeration the playbook requires before writing page CSS, and it was skipped. The comp does specify a 12px radius; the divergence from the theme's 14px is DECLARED in the handle rather than smuggled in as a duplicate block. -------------------------------------------------------------------------- */ .customer-account-create .form.create.account .fieldset > .field { margin: 0; display: flex; flex-direction: column; gap: 6px; } .customer-account-create .form.create.account .fieldset > .field > .label { font-size: 12px; font-weight: 600; text-transform: uppercase; letter-spacing: 0.06em; color: var(--hrv-text-muted); margin: 0; padding: 0; width: auto; text-align: left; } .customer-account-create .form.create.account .fieldset > .field > .control { width: auto; } /* The only paint this page overrides on the shared input: the comp's 12px corner. */ .customer-account-create .form.create.account .input-text { border-radius: var(--hrv-radius-sm); } /* The comp puts first and last name on one row. Core emits them as two sibling `.field`s, so the row is made by promoting the pair — no template change and no reordering. */ @media (min-width: 640px) { .customer-account-create .form.create.account .fieldset.create.info { display: grid; grid-template-columns: 1fr 1fr; column-gap: 12px; row-gap: 16px; } .customer-account-create .form.create.account .fieldset.create.info > .field.choice { grid-column: 1 / -1; } } /* Newsletter and assistance opt-ins — rows, not stacks. */ .customer-account-create .form.create.account .field.choice { flex-direction: row; align-items: center; gap: 8px; font-size: 13px; color: var(--hrv-text-muted); } .customer-account-create .form.create.account .field.choice input[type="checkbox"] { accent-color: var(--hrv-accent); margin: 0; } /* DIRECT CHILD, not descendant (S4 MINOR 2). As a descendant selector this also matched `span#tooltip-label.label` inside the tooltip - Blank's visually-hidden accessible name - and overrode its `margin: -1px` at (0,6,0). Measured still hidden and harmless, but reaching into a clip-rect a11y element is not what section 4's prose means, and "harmless today" is how a defect waits. */ .customer-account-create .form.create.account .field.choice > .label { margin: 0; padding: 0; font-weight: 400; text-transform: none; letter-spacing: normal; font-size: 13px; color: inherit; } /* -------------------------------------------------------------------------- 5. Password strength - MOVED TO components/_password-meter.css T23 renders the same control on customer/account/createpassword, and this element cost FIVE consecutive review gates here. Copying the result into a second page sheet would have copied the shape of the bugs with it, so it is now a shared component and this page no longer owns it. The component carries the full account of what it cost - the ID-not-a-class selector, the label clipped inside the bar, the inherited collapsed line-height, the fill re-parented into a 26px slab, and the fifth state nobody enumerated. This is also the ownership enumeration the playbook requires before writing page CSS, applied late: S1 caught this sheet restating ten declarations already owned by _forms.css. -------------------------------------------------------------------------- */ /* -------------------------------------------------------------------------- 6. The tooltip CRITICAL. The first version set `position: static`, which DESTROYS the containing block Blank's absolutely-positioned `.field-tooltip-content` resolves against. There is no other positioned ancestor on the route, so the popover fell back to the initial containing block and rendered at x=38, y=-9 — roughly 600px from its trigger, painting over the promo banner in the top-left of the document and clipped off the top. The control still toggled and the accessible names were intact, which is why nothing else caught it. S4 CORRECTED THE STORY THIS COMMENT USED TO TELL. Blank ships `.field.choice .field-tooltip { display:inline-block; margin-left:10px; position:relative; top:-3px }` at (0,3,0), which already beats the bare `.field-tooltip { position:absolute }` at (0,1,0) - so on THIS route Blank's own computed value is `relative`, and the line claiming "Blank's own absolute also mis-places it here at x=1453" described a state that cannot occur. The defect was purely my `static` overriding a value that was already correct, and the `position: relative` below is a no-op restatement kept for legibility. `top: auto` silently discards Blank's `top: -3px`; that 3px is now declared rather than accidental. -------------------------------------------------------------------------- */ .customer-account-create .form.create.account .field-tooltip { position: relative; right: auto; top: auto; display: inline-flex; align-items: center; } .customer-account-create .form.create.account .field-tooltip .field-tooltip-content { background: var(--hrv-surface); border: 1px solid var(--hrv-border); border-radius: var(--hrv-radius-sm); color: var(--hrv-text); font-size: 13px; } /* THE ARROW, THIRD ATTEMPT, AND THE FIRST TWO BOTH SHIPPED SOMETHING WORSE THAN BLANK. Attempt 1 themed `border-bottom-color` and blamed a media block. Attempt 2 added `border-right-color` to BOTH pseudo-elements on S4's finding that the desktop arrow uses the right border. S7 then proved with a FORCED-COLOUR PIXEL CONTROL (paint each edge of each pseudo a distinct colour, activate, count matching pixels) that `::before` renders **zero pixels at 375 and at 1440**: `::after` sits at the same left/top, is 1px larger, and carries `z-index: 4` against `::before`'s 3, so it fully occludes it. Both rules added to `::before` were dead CSS. Worse, `::after` had been themed to `--hrv-surface` - white, on a white card - so the popover shipped with NO VISIBLE CONNECTOR AT ALL, while the comment above it claimed "both edges are themed now". Blank at least drew a `#f4f4f4` triangle. Two rounds of "fixing" this made it strictly less visible than the thing being fixed. So the only pseudo-element that paints is themed, and to the BORDER token rather than the surface, because a connector that matches the card it sits on is not a connector. The dead `::before` rules are removed rather than left as decoration. ROUND 3 THEMED BOTH EDGES AT EVERY WIDTH, AND THAT PAINTED A SPURIOUS SECOND TRIANGLE. S8 separated them with a forced-colour control that recoloured only ALREADY-PAINTED edges, so painting itself was unchanged: at 1440 the right edge is the real arrow (100px) and the bottom edge added 97px that Blank leaves transparent; at 375 it mirrors - bottom is correct (89px) and right adds 15px of spurious ink. Third consecutive round in which an arrow edge was themed without first establishing whether it paints at that width, each time under a comment asserting the question settled. Each edge is now scoped to the context that actually uses it. TWO CLAIMS THIS COMMENT USED TO MAKE, BOTH WRONG, BOTH RETIRED: that the relevant media block is `(max-width:1023px)` - no such block exists for `.field-tooltip` in the deployed CSS, the contexts are 768 / 767 / 639 / 479 (S8 MINOR 2, correcting a wrong claim that had itself replaced a differently wrong one); and S7's account of the occlusion mechanism, which said `::after` "is 1px larger". Both pseudos compute to 20x20 at identical left/top - `::after`'s `width:1px` and `::before`'s `width:0` are BOTH clamped to the 20px border sum by `box-sizing: border-box`. They are coincident, not offset. The occlusion is real and pixel-proven either way (::before renders 0px with ::after present, 400px with it hidden), but the consequence the record kept missing is larger than the theme: because border-box collapses Blank's intended offset, **Blank's own two-tone arrow never renders for anyone in this build** - the #666 outline is dead in core. */ .customer-account-create .form.create.account .field-tooltip .field-tooltip-content::after { border-right-color: var(--hrv-border); } @media (max-width: 767px) { .customer-account-create .form.create.account .field-tooltip .field-tooltip-content::after { border-right-color: transparent; border-bottom-color: var(--hrv-border); } } /* -------------------------------------------------------------------------- 7. Actions — the inherited 25.8% indent, reset at (0,5,0) -------------------------------------------------------------------------- */ .customer-account-create .column.main .form.create.account .actions-toolbar { margin: 0; display: flex; flex-direction: column; gap: 10px; align-items: flex-start; } .customer-account-create .form.create.account .actions-toolbar > .primary, .customer-account-create .form.create.account .actions-toolbar > .secondary { float: none; margin: 0; } /* The comp's CTA is `width: fit-content` — deliberately NOT the full-bleed button T21 draws. Stated because the two pages are siblings and the difference reads as an oversight until you have both artboards open. */ .customer-account-create .form.create.account .actions-toolbar .action.submit { width: auto; } /* -------------------------------------------------------------------------- 8. What is NOT here The first version styled `.actions-toolbar > .secondary .action.back` — font-size, colour, text-decoration and a `:hover`. All of it was DEAD. Blank's `.actions-toolbar > .secondary .action.back` at (0,4,0) sets `display: none` and beats `styles-l`'s (0,3,1) `inline-block`, so that link never paints at any width. The rules are removed rather than out-specified: the comp's "Already registered? Sign in" is a DIFFERENT element with different text and a different target, and is declared in the handle rather than conjured out of a hidden core link that says "Back". `.secondary` itself is a 0x0 flex item and still consumes one 10px gap under the CTA. That falls out with the link and is left alone rather than papered over. -------------------------------------------------------------------------- */ /* -------------------------------------------------------------------------- 9. Responsive — 375 / 640 / 768 / 900 / 1024 / 1440 all measured -------------------------------------------------------------------------- */ @media (max-width: 639px) { .customer-account-create .column.main .form.create.account { padding: 24px; } .customer-account-create .page-main { padding-top: 32px; } .customer-account-create .page-title-wrapper .page-title { font-size: 26px; } }