and `aria-labelledby` and emits no

at all. GEOMETRY AND COLOUR ARE TAKEN OVER TOGETHER. deferred-work names the half-and-half -- overriding colour onto Neve's padding, border width and radius -- as the specific risk, so the control rule below states padding, border-width and border-radius beside the colours rather than inheriting Neve's 2px box and repainting it. FAMILY C, RECORDED RATHER THAN INHERITED. CAP-7's encoding is A ROUNDED BOX CAN BE OPERATED; A SQUARED ONE CANNOT. Two exemptions were taken here and BOTH WERE LIFTED ON 2026-09-30 -- the paragraphs are kept verbatim because the first one's REASONING still decides where the line sits, and the second one's still decides the value. The radii and the full amendment are at `--shape-input-radius` below. - TEXT FIELDS ARE SQUARE. You type into an input; you do not click it the way you click a control that does something. Rounding every field would spend the site's one operability signal on the most numerous boxes on the page and leave the submit -- the box that actually acts -- indistinguishable from them. LIFTED: fields are 11px. The argument above is why they are not 999px, which is the number that would actually have spent the signal. - THE CHECKBOX IS SQUARE, and this one is not a judgement call: a round checkbox reads as a radio button, which is a different control with different semantics. Shape is already spoken for. LIFTED TO 4px ONLY, and this paragraph is the reason it is 4 and not 11: a softened square still reads as a square, and at 11px on a 22px box it would not. The submit keeps `--shape-button-radius` (999px) through the `button[type="submit"]` rules above, so the one box that acts is the one round box on the panel. `--shape-input-radius` and `--shape-check-radius` are declared in the scope below, NOT in the Family C block at `:root`, for the same one-consumer reason as the rest of this section. THE PROTOTYPE IS `https://claude.ai/code/artifact/f8b40415-c37d-4b3e-8079-65ea0d611431` ("Joe Tennis Contact Slate"), chosen by Joe 2026-09-25, and every value below is re-measured from it rather than re-derived. Three of its declarations could not be copied literally and the reasons are worth keeping: it read the Neve palette's grey slot directly (written here as the literal `#5c646b`, because `checks/05` greps this file for palette reads and cannot tell a comment from code); it forced its focus ring with `!important` (the ring is a TOKEN here, re-bound on the panel scope, so there is no specificity contest to win); and its error state keyed off a JS-applied `.is-invalid` class (this ships `:user-invalid`, which needs no script -- the class hook is story 3's, when there is a handler for it to report). --------------------------------------------------------------------- */ /* THE WHITE GROUND -- the page the panel sits on. No control renders here today: the form is entirely inside the slate panel, and these values exist so the family has a white-ground binding the moment one does (a search field, a newsletter box, an Experiments form). Measured on #ffffff: rest edge #5c646b 6.02:1, hover/focus edge #16191d 17.63:1, placeholder #6b7278 4.88:1, error #b3261e 6.54:1, checked fill #0b6b78 6.20:1. THE REST EDGE IS THE DEFECT THIS FAMILY EXISTS TO FIX. `--ground-edge` is `rgba(0, 0, 0, 0.25)`, which composites to 1.84:1 on white -- below the 3:1 WCAG 1.4.11 wants for a control boundary. That value is correct where it is spent (a header hairline, an

, a blockquote rule) and wrong on the edge that tells you where a field is. The prototype's notes reached the same number independently, which is why it is not re-litigated here. */ .contact-page { --state-input-rest-fg: #16191d; --state-input-rest-bg: #ffffff; --state-input-rest-bd: #5c646b; --state-input-hover-bd: #16191d; --state-input-focus-bd: #16191d; --state-input-focus-ring: #000000; --state-input-placeholder-fg: #6b7278; --state-input-invalid-bd: #b3261e; --state-input-invalid-bg: #fdf3f2; /* ERROR TEXT, added by story 3 with the handler that can produce a message. A separate role from the three above because it is INK on the ground rather than paint on a control, so it answers to the 4.5:1 text floor rather than 1.4.11's 3:1 -- #b3261e is 6.54:1 on #ffffff. NOTHING RENDERS THIS VALUE TODAY, and saying so matters here more than elsewhere in this block. Every selector that reads the role is scoped inside `.contact-page__form` or `.contact-page__panel`, which is to say always on slate, where the rebinding below wins -- so the 6.54:1 above is a figure this page never draws. It is bound for the same reason the rest of the white-ground block is: so the family has a white binding the moment an error message renders off the panel. Recorded plainly because CLAUDE.md has a standing section on values documented as though they paint while waiting for their first consumer. */ --state-input-error-fg: #b3261e; --state-input-label-fg: #16191d; --state-input-hint-fg: #5c646b; --state-check-rest-bg: #ffffff; --state-check-rest-bd: #5c646b; --state-check-hover-bd: #16191d; --state-check-checked-bg: #0b6b78; --state-check-checked-bd: #0b6b78; --state-check-mark-fg: #ffffff; --state-check-label-fg: #16191d; /* THE FIELD RADIUS, AND THE FAMILY C EXEMPTION THAT WAS LIFTED TO GET IT. Both were `0` until 2026-09-30. Joe ruled the pair above on seeing the /contact/ refinement drawn against /about/, and the reasoning in the Family C note above is AMENDED rather than contradicted -- read it there, and read this for what survived. WHAT THE ORIGINAL ARGUMENT ACTUALLY PROTECTED was the submit's distinctness: "rounding every field would spend the site's one operability signal on the most numerous boxes on the page and leave the submit -- the box that actually acts -- indistinguishable from them." That holds against a PILL and it does not hold against 11px. The submit is `--shape-button-radius`, 999px, which on a 46px-tall control is a full semicircle at each end; 11px on a 45px field is a softened corner. The two are not confusable, so the signal is not spent. Had the fields gone to 999px the argument would still win. 11px IS ABOUT'S FACET RADIUS and 4px is not About's at all. The split About ships is BY BOX SIZE -- 28px for its six large panels, 11px for its four small facet boxes -- so a field takes the small one and the panel around them takes the large one. The checkbox goes to 4px rather than 11px because the Family C note's second exemption is NOT a judgement call: at 11px on a 22px box the corner is half the side and starts reading as a radio button. 4px is a softened square that still reads as a square. VALUES HAND-COPIED FROM about.css, WHICH IS THE COST OF THIS AND IS RECORDED RATHER THAN HIDDEN. about.css:141,145 declare `--about-panel-radius: 28px` and `--about-facet-radius: 11px` in its own `:root`, and that sheet loads ONLY on /about/ -- so /contact/ cannot read them and these are a second declaration of the same two numbers. `checks/06` pins `#8cc201` and has no opinion about radii, so nothing catches them drifting apart. THE FIX IS TO POINT about.css AT THESE TWO TOKENS when /about/ is next touched; it was not done here because it is an edit to a shipped page outside this refinement's scope, for no visible gain. CLAUDE.md's `--primarybtnpadding` entry is the same shape of problem. */ --shape-input-radius: 11px; --shape-check-radius: 4px; /* THE PANEL'S RADIUS, new 2026-09-30, About's large-box value. It is declared here rather than in contact.css because contact.css states no value this sheet could own -- and because the moment a second page wants it, the token is already in the sheet every page loads. */ --shape-panel-radius: 28px; /* The panel's own surface. `#3C5158` is the bench's third ground and CLAUDE.md already records it as a COMPONENT SURFACE deliberately kept out of the palette -- the same kind of object as the Flush Split hero media and the flip cards, which spend it as `--color-bg-surface` on their own roots. It is a panel on a white page, not a site ground, so it takes a scoped rebinding rather than a `ground` key, and `checks/05`'s count of 6 does not move. It is named here rather than in contact.css because that sheet declares no colour value of its own. */ --color-form-panel-bg: #3C5158; --color-form-panel-fg: #ffffff; /* THE STATEMENT'S INK, AND IT MOVED UP A SCOPE ON 2026-09-30 BECAUSE THE ELEMENT DID. It was declared on `.contact-page__panel` while the

lived inside the panel. The refinement moved that heading out onto the white band, and the token did not follow -- so `.contact-pagestatement h1`'s `color: var(--state-statement-fg)` referenced an undefined property, which is INVALID AT COMPUTED-VALUE TIME and drops the declaration entirely. `color` then inherited `.contact-page`'s `--ground-ink`, and the headline shipped to dev NEAR-BLACK. Joe caught it by eye on the installed v2.0.0: "Looks pretty good, beside the H1 being black not green." THIS IS THE EXACT FAILURE THIS SHEET ALREADY WARNS ABOUT, a few hundred lines down at `--state-input-focus-bd`: "a role bound on one ground and left unbound on the other does not fall back to something sensible, it falls through to a value chosen against a different background." Moving an ELEMENT between grounds is the same hazard as adding one, and it is less obvious, because nothing about the move mentions colour. THE CHECK WORTH RUNNING when a styled element changes parent: list every `var()` its rules read and confirm each still resolves at the new position. IT IS ON `.contact-page` RATHER THAN ON THE STATEMENT so the panel keeps it too -- the panel is a descendant of this element, so a declaration here covers both sides of the move and a future heading put back inside the panel would still resolve. AND THE CONTRAST FIGURE MOVED WITH THE ELEMENT, which is the part that is a decision rather than a bug. #8cc201 measured 3.91:1 inside the slate panel and clears the 3:1 large-text floor there. On the white band it is 2.14:1 and does NOT. That is the ruling Joe made for /about/ on 2026-09-29 with all three numbers in front of him -- about.css:225-236 records it verbatim, and the prototype's Layout E cites it for this page. Green on white is a trade he has taken twice now, deliberately. The one-line reversal is pointing this at `--ground-ink`. / --state-statement-fg: var(--color-tab-current); } / THE SLATE PANEL -- values only, no rules. Measured on #3C5158: ink #ffffff 8.37:1, hints and "(optional)" #d3dde1 6.06:1, ring #00e5ff 5.44:1 (black would be 2.50:1 here, which is why the ring is a token rather than a literal), error edge #ffb4ab 4.93:1. THE FIELDS KEEP THEIR WHITE FILL ON THIS GROUND, and that is what makes the rest of the block short: a white box on slate is an 8.37:1 boundary by itself, so the EDGE only has to mark state rather than carry the control's presence. That is also why `--state-input-rest-fg` and `-bg` are not re-bound -- ink on the fill has not changed ground. THE LEFT RULE STAYS `#b3261e` (inherited, deliberately not restated): it is drawn INSIDE the field, on the white fill, where it measures 6.54:1. The error EDGE moves to #ffb4ab because that one is drawn against the slate, where the dark red would be 1.32:1. One state, two surfaces, two values -- which is the whole reason it is two tokens. THE SUBMIT IS NOT RE-BOUND AT ALL. `:root`'s Button/CTA values are already the dark-ground ones -- white ink, cyan edge, filling cyan with black ink on hover -- so the form's submit inherits the shipped treatment unchanged on this panel and needs nothing here. Its DISABLED pair is the exception: `:root` disables to a #00b8cc fill, which is a filled cyan pill at 0.3 opacity on slate. The ghost form is re-bound so the disabled submit reads as the same ghost shape the rest state has, dimmed. The 0.3 opacity itself is untouched -- it is this project's disabled convention and it is what exempts the cell from the contrast floor. / .contact-pagepanel { --state-input-rest-bd: #ffffff; --state-input-hover-bd: #00e5ff; / FOCUS RE-BINDS TOO, AND IT WAS THE ONE ROLE THIS BLOCK MISSED. Measured on the installed v1.13.25: clicking a field dropped its border from #ffffff at 8.37:1 to the white-ground value #16191d at 2.11:1 on this panel -- the control's boundary all but erased at the moment of interaction. The cyan ring still marked focus, so this was never a focus-INDICATOR failure; it was the edge disappearing underneath a perfectly good ring. This is the failure the ground contract exists to prevent, in miniature: a role bound on one ground and left unbound on the other does not fall back to something sensible, it falls through to a value chosen against a different background. Cyan matches hover, so the edge now reinforces on the way in rather than contradicting. / --state-input-focus-bd: #00e5ff; --state-input-focus-ring: #00e5ff; --state-input-invalid-bd: #ffb4ab; --state-input-invalid-bg: #fff5f4; --state-input-hint-fg: #d3dde1; / ERROR TEXT ON SLATE. #ffb4ab is 4.93:1 on #3C5158, which clears the 4.5:1 text floor; the white-ground #b3261e would be 1.32:1 here and unreadable. Same shape as the error EDGE directly above -- one state, two surfaces, two values -- and the same reason it is a token. / --state-input-error-fg: #ffb4ab; / THE FIELD LABELS RESOLVE FROM THE ONE DECLARATION, never a second copy. `--color-tab-current` is declared once at :507 of this file and `checks/06` pins that value to exactly two role names across every theme/.css -- a third declaration fails the suite, which is the check doing its job rather than an obstacle. Reading the token also means these labels move with the tab kickers and the About medallion's current arc if that value is ever re-ruled, which is Joe's 2026-09-23 coupling ruling extended to a fourth site. / --state-input-label-fg: var(--color-tab-current); /* THE PAGE'S HEADLINE, ADDED BY STORY 5, AND IT READS THE SAME ONE DECLARATION for the same reason the labels above do -- a third literal `#8cc201` anywhere in theme/.css fails `checks/06`, and a `var()` reference is not a declaration, so this costs nothing. IT IS A SEPARATE ROLE FROM THE LABEL and not an alias of it, because the two answer to different contrast floors on the same ground. #8cc201 measures 3.92:1 on the slate: the labels clear the 3:1 large-text floor only by being 19px/700, which is why that rule carries a "do not tidy it smaller" warning. This headline is clamp(32px, 4.2vw, 56px) at weight 800 and clears the same floor with room to spare at every viewport. Binding them together would invite a future change to one to be reasoned about from the other's margin. / --state-check-rest-bg: transparent; --state-check-rest-bd: #ffffff; --state-check-hover-bd: #00e5ff; --state-check-checked-bg: #00e5ff; --state-check-checked-bd: #00e5ff; --state-check-mark-fg: #05070d; --state-check-label-fg: #ffffff; --state-button-disabled-bg: transparent; --state-button-disabled-fg: #ffffff; --state-button-disabled-bd: #00e5ff; /* THE BASELINE RING IS COUNTER-BOUND, PRE-EMPTIVELY, and the precedent is `.joetennis-site-footer` doing exactly this at :1183 for exactly this reason. Every control on this panel is enumerated above and wins the baseline rules on specificity, so nothing reads this today. It is bound anyway because `--ground-default-ring` is #000000 at `:root` -- chosen against a white page, where it is 21:1 -- and on #3C5158 it measures 2.50:1, under the 3:1 floor a focus indicator has to clear. So any focusable this panel grows that ISN'T enumerated here gets an unreadable ring with no code change to review: story 3's error summary (a `tabindex="-1"` container that takes focus on a failed submit), story 4's Privacy Statement link, a
, a skip target. #00e5ff is 5.44:1 here. / --ground-default-ring: #00e5ff; } / THE DISABLED SUBMIT KEEPS ITS EDGE, and this rule exists because the rebinding directly above would otherwise erase the control. The sitewide disabled rule states `border-color: transparent` as a literal, and that is correct where it was written: the CTA's disabled cell has a FILL (#00b8cc), so the box is drawn by the fill and an edge would be redundant. This panel rebinds that fill to `transparent`, so with the shipped literal still in force the submit would have no fill AND no edge -- a faint line of text where a button should be. Measured in the harness before this rule existed: `background-color rgba(0,0,0,0)`, `border-color rgba(0,0,0,0)`. THE BUTTON HAS TO STILL READ AS A BUTTON. Its whole job in story 2 is to say "this exists and is not connected yet"; a control that dissolves into text says "this page is unfinished" instead, which is the reading the note beside it is there to prevent. THIS IS NOT THE DISABLED-CONVENTION DIVERGENCE THE STORY HOLDS FOR JOE. That question is whether `opacity: 0.3` gives way to the prototype's explicit greys -- which would change the shipped CTA too, and is untouched here. The opacity, the tokens and the rule above all stand; this restores a border the panel's own rebinding removed, and it reaches nothing outside `.contact-pageform`. Specificity (0,3,1) clears the sitewide rule's (0,2,1). IT HAS NO LIVE CONSUMER SINCE v1.13.30, and the paragraph above is therefore history rather than description: story 3 removed the `disabled` attribute from the submit, so nothing on this site renders a disabled button today. The rule is KEPT because what it corrects is a real consequence of the panel's rebinding, which is still in force -- the next thing to disable this submit (a "sending" state, an `aria-disabled` pass) would otherwise find a control with no fill and no edge. Forward cover, stated as forward cover. / body .contact-pageform .contact-page__submit:disabled { border-color: var(--state-button-disabled-bd); } / The panel's title. Stated here rather than left to inherit because Neve paints headings from its own typography theme_mods and this panel's ground is not the page's. IT WAS TWO ROLES UNTIL v1.13.31. The second was `.contact-pagepanel-sub`, the line reading "Only your name and email are required", removed along with both field hints on Joe's call -- the panel now states its name and asks its questions with nothing between them. Deleted rather than kept as forward cover, unlike the hint role below: a panel subheading is a thing this page had, not a member of the form-control family the story designed. / body .contact-pagepanel-title { color: var(--color-form-panel-fg); } / THE FIELD LABEL, AND THE SIZE IS THE ACCESSIBILITY FIX -- DO NOT TIDY IT SMALLER OR LIGHTER. `--color-tab-current` measures 3.92:1 on the slate. That is under the 4.5:1 normal-text floor and over the 3:1 LARGE-text floor, and WCAG's large-text threshold is 18.66px BOLD (14pt) or 24px regular. 19px at weight 700 clears it; 19px at 600, or 18px at 700, does not, and neither failure is visible -- the label looks identical and the cell silently stops passing. The green was ruled in at this ratio twice before (flush-split-white.css:385, decision 7, and again when the About medallion adopted it), each time as an improvement on the purple's 2.11:1 rather than as a pass; 19px/700 is what turns it into a pass on this panel. White at 8.37:1 was rendered alongside it and Joe chose the green, 2026-09-25. 700 IS REQUESTED BY THIS THEME AS OF THIS STORY. functions.php asked Google Fonts for `Inter:wght@400;500;600` and this rule is the first thing in the theme to set 700 in that family. CSS font matching would have supplied 600 with no error and no missing file -- the exact failure CLAUDE.md's typography entry records for the archive card's ExtraBold -- which would have rendered a label that looks bold, is not, and fails the contrast floor it was sized to clear. `700` was added to the request in the same commit. / body .contact-pageform .contact-pagelabel { font-family: var(--font-body); font-size: 19px; font-weight: 700; line-height: 1.3; letter-spacing: 0.2px; color: var(--state-input-label-fg); } / THE REQUIRED MARK, AND IT REPLACED `.contact-pageoptional` OUTRIGHT AT STORY 5. The convention inverted: the drawing marks the two REQUIRED fields with a green asterisk and marks nothing optional, where this form previously marked the optional ones in words and asserted "there are no asterisks anywhere on this form". THAT IS THE THIRD ROUND ON THIS ONE QUESTION and the rounds are not a contradiction, so they are worth naming once: story 2 said it in a panel sub-line plus two field marks, v1.13.31 removed the sub-line and one mark on Joe's call, and the drawing replaces the MECHANISM the other two were reaching for. All three were after the same thing. IT INHERITS THE LABEL'S 700 AND ITS COLOUR, which is the whole of the rule. The mark is part of the label's own name in the drawing -- same weight, same green, three pixels out -- so it states only the offset. The `.contact-pagerequired-note` beside the Send button is the same class and gets the same treatment, which is the point: the legend has to look like the thing it is a legend for. IT IS `aria-hidden` IN THE MARKUP AND THAT IS NOT THIS FILE'S BUSINESS TO ENFORCE, but it is the reason a purely visual mark is acceptable at all: the input's own `required` attribute is what announces the field, and an asterisk read aloud as "star" is noise. / body .contact-pageform .contact-pagerequired { margin-left: 3px; color: var(--state-input-label-fg); } / THE HINT ROLE HAS NO CONSUMER AS OF v1.13.31, and it is kept anyway. Both hints this form carried -- "Used only to reply to you" under the email field and "If you would rather talk" under phone -- were removed on Joe's call, so nothing on this page renders this class today. IT STAYS because a hint is a member of the form-control family CAP-3 designed, not a one-off line of this page's copy: the role is bound on both grounds (#5c646b at 4.88:1 on white, #d3dde1 at 6.06:1 on slate), the "(optional)" mark above resolves its colour from the same token, and the next field anywhere on this site that needs a hint should not have to redecide what one looks like. Compare the panel sub-line above, which was deleted: that was this page's, this is the family's. Stated plainly rather than left for a reader to discover, because an unannotated rule matching nothing is indistinguishable from a rule whose selector has drifted. / body .contact-pageform .contact-pagehint { font-family: var(--font-body); font-size: 13px; line-height: 1.45; color: var(--state-input-hint-fg); } / THE TEXT CONTROLS -- text, email, tel and textarea in one rule, reached through a class rather than through element or attribute selectors. SPECIFICITY IS THE WHOLE REASON FOR THE CLASS. Neve's base is `form input:read-write` at (0,1,2) and its focus at (0,2,1), both in neve-style-css, which loads AFTER every child sheet -- so a rule that merely TIES loses. `body .contact-pageform .contact-pagecontrol` is (0,2,1), which beats the base on class count; the state rules below add a pseudo-class and land at (0,3,1), which beats the focus rule the same way. An element-selector group would have been (0,1,1) for `textarea` and would have lost to Neve's base silently, painting nothing and looking like a cascade bug. BORDER WIDTH IS 1px IN EVERY STATE INCLUDING ERROR, and the prototype is deliberately not followed here: it bumps the slate error edge to 2px. This sheet's standing convention is that width is held and `border-color` carries the change, so no state re-flows the control -- the same reason the Button/CTA block above holds 1px through four states. The error state has two other carriers (the fill and the left rule), so it loses nothing by holding the width. / body .contact-pageform .contact-pagecontrol { box-sizing: border-box; font-family: var(--font-body); / 18px, About's body size, up from 17 on 2026-09-30. 17 was measured to hold a full email address in the narrower column story 5 drew against; the page has since taken the site band, so the field is WIDER at the same breakpoint and the extra pixel costs nothing it was protecting. / font-size: 18px; font-weight: 400; line-height: 1.5; letter-spacing: 0.2px; color: var(--state-input-rest-fg); background-color: var(--state-input-rest-bg); border: 1px solid var(--state-input-rest-bd); border-radius: var(--shape-input-radius); padding: 12px 14px; box-shadow: none; } / THE TEXTAREA RESIZES VERTICALLY ONLY, and the `max-width` is a second belt on the same failure. A textarea's UA default is `resize: both`, so the drag handle lets a visitor pull it WIDER than its grid track -- out through the slate panel's padding and past its edge, on a panel whose whole job is to contain the form. `resize: vertical` is what the prototype declared and it was lost in transcription; `max-width: 100%` holds every control inside its track for the other routes to the same place (a long `value`, a wide `placeholder`, a future `size` attribute), because a grid track sized `minmax(0, 1fr)` stops the track blowing out but does not stop a child overflowing it. / body .contact-pageform .contact-pagecontrol { max-width: 100%; } body .contact-pageform textarea.contact-pagecontrol { resize: vertical; } body .contact-pageform .contact-pagecontrol:hover { border-color: var(--state-input-hover-bd); } / A BARE `:focus` RULE, AND IT IS THE ONE EXCEPTION THIS SHEET ALLOWS ITSELF -- read the next sentence before deleting it. It declares no state paint of its own that `:focus-visible` does not: what it does is REMOVE Neve's, which is applied on bare `:focus` and therefore paints on a mouse click, where `:focus-visible` does not match. Without it, a visitor who clicks into a field gets a 3px #2f5aae glow and a #2f5aae border from a palette slot nothing in this theme reads, and the keyboard ring below never fires to cover it. `box-shadow` and `border-color` are both stated because Neve sets both. / body .contact-pageform .contact-pagecontrol:focus { border-color: var(--state-input-focus-bd); box-shadow: none; } / AUTOFILL, AND IT IS NOT HYPOTHETICAL ON THIS FORM. The name and email fields carry `autocomplete="name"` and `autocomplete="email"`, which is an invitation -- so the browser filling them is the expected path, not an edge. Chrome then paints its OWN background and ink over the control (a pale yellow historically, the UA's accent now) and neither obeys a `background-color` declaration, which is why the mask below is an inset `box-shadow` 100px deep rather than a colour: the shadow is the one property the UA's autofill layer does not replace. `-webkit-text-fill-color` is likewise the only thing that moves the ink, since `color` is overridden too. WHAT IT COSTS IF LEFT: every measured figure on the slate panel is void for the two fields most likely to be filled -- the ink is the UA's, the fill is the UA's, and the white edge that carries the control's presence against #3C5158 sits around a colour nobody chose. TWO RULES, NOT ONE COMMA-JOINED LIST, AND THAT IS LOAD-BEARING. A selector a browser does not recognise invalidates the WHOLE rule it sits in, so pairing the standard `:autofill` with `:-webkit-autofill` in one list would silently drop the declarations in every engine that knows only one of them. Kept apart, each engine takes the rule it understands and ignores the other. / body .contact-pageform .contact-pagecontrol:-webkit-autofill, body .contact-pageform .contact-pagecontrol:-webkit-autofill:hover, body .contact-pageform .contact-pagecontrol:-webkit-autofill:focus { -webkit-text-fill-color: var(--state-input-rest-fg); caret-color: var(--state-input-rest-fg); border-color: var(--state-input-rest-bd); box-shadow: inset 0 0 0 100px var(--state-input-rest-bg); } body .contact-pageform .contact-pagecontrol:autofill, body .contact-pageform .contact-pagecontrol:autofill:hover, body .contact-pageform .contact-pagecontrol:autofill:focus { -webkit-text-fill-color: var(--state-input-rest-fg); caret-color: var(--state-input-rest-fg); border-color: var(--state-input-rest-bd); box-shadow: inset 0 0 0 100px var(--state-input-rest-bg); } body .contact-pageform .contact-pagecontrol:focus-visible { outline: 2px solid var(--state-input-focus-ring); outline-offset: 2px; } / `opacity: 1` because Firefox still applies a UA opacity to ::placeholder, which would composite the decided value into a lighter one and quietly undo the ratio it was chosen for. No field on this page carries a `placeholder` attribute -- a hint that vanishes on the first keystroke is not a label, and every field here has a real one -- so this rule is the FAMILY being decided rather than this page being painted. It is bound anyway, on the same principle the chip roles are: a ground supplies values whether or not a component is on screen. The default it replaces composites to #8a8c8e, 3.37:1, under the text floor. / body .contact-pageform .contact-pagecontrol::placeholder { color: var(--state-input-placeholder-fg); opacity: 1; } / `:user-invalid`, NEVER `:invalid`, and the difference is the whole behaviour. A required field is `:invalid` from first paint, so `:invalid` would paint an error on a form nobody has touched -- scolding the visitor for not yet having done the thing. `:user-invalid` matches only after the field has been interacted with and blurred, or after a submit attempt, which is exactly the I/O matrix's first two rows. COLOUR IS NEVER THE ONLY SIGNAL, AND THE CARRIER CHANGED ON 2026-09-30. It was `box-shadow: inset 4px 0 0` -- a rule down the field's left edge, drawn on the field's own fill rather than against the ground, which is why it kept ONE value on both grounds. The non-colour carrier is now BORDER WIDTH: 1px at rest, 2px when invalid, which survives a greyscale render and a colour-vision deficiency the same way. The error MESSAGE is the other carrier and it is story 3's: a message has to be honest about what failed, which needs the handler that decides it. WHY IT CHANGED, because "we rounded the corners" is not a good enough reason on its own and this one is mechanical. `--shape-input-radius` went from 0 to 11px in the same change, and an `inset` box-shadow follows the border-box's CORNER CURVE -- so a 4px left rule on an 11px radius is pinched to nothing at both ends of its own run and reads as a smear rather than a rule. There is no way to draw a straight-edged inset rule inside a rounded box. The choice was therefore the radius or the rule, and Joe took the radius knowing the cost; the 2px edge is what replaces the signal rather than dropping it. `--state-input-invalid-rule` was deleted with it -- it had no other consumer. THE ONE THING THE SWAP GIVES UP is ground-independence. The left rule sat on the field's own near-white fill, so `#b3261e` worked on the white page and on the slate panel alike. A BORDER is seen against whatever is behind the field, so it has to take `--state-input-invalid-bd`, which is bound per ground -- `#b3261e` on white, `#ffb4ab` on the panel. That is the ground contract working as designed rather than a regression, but it is one more value that has to be right on two surfaces instead of one. IT IS LAST IN THE STATE ORDER ON PURPOSE. This rule and the `:focus` pair share specificity (0,3,1), so source order settles a field that is both focused and invalid -- and the error edge is the one that should win, with the keyboard ring still painting over it from the `outline` property, which nothing here touches. KEEP IT IN ITS OWN RULE. An unsupported selector invalidates the whole selector LIST it appears in, so grouping `:user-invalid` with anything else would take that rule down with it on any engine that does not know the pseudo-class. / body .contact-pageform .contact-pagecontrol:user-invalid { border-color: var(--state-input-invalid-bd); background-color: var(--state-input-invalid-bg); border-width: 2px; } / `.is-invalid` -- the SERVER's error paint, and story 2 left the hook here deliberately for story 3 to fill. WHY THE PSEUDO-CLASS ABOVE IS NOT ENOUGH. `:user-invalid` matches only after the visitor has interacted with a field IN THIS DOCUMENT. A re-rendered page after a rejected POST is a NEW document nobody has touched yet, so every field would paint clean while the summary at the top said the form was not sent. The handler adds this class to the fields it rejected, which is the only way server-decided state can reach the paint. It also covers what the pseudo-class cannot know: an address that is syntactically fine and still not an address. IT IS ITS OWN RULE AND MUST STAY ONE. The declarations are identical to the rule above, and grouping them into one selector list would be the obvious tidy -- and would take BOTH down on any engine that does not know `:user-invalid`, because an unsupported selector invalidates the whole list it appears in. That is the note directly above this one, and this is the case it was written for. Duplicated on purpose. / body .contact-pageform .contact-pagecontrol.is-invalid { border-color: var(--state-input-invalid-bd); background-color: var(--state-input-invalid-bg); border-width: 2px; } / --------------------------------------------------------------------- THE HANDLER'S OWN TEXT -- per-field errors, the whole-form notice, the error summary and the confirmation. Story 3 (CAP-4). COLOUR ONLY. Every one of these elements takes its layout from contact.css, which declares no colour value of its own; the ink is here because this sheet is the single owner of state, and an error message is state made readable. Each resolves from the role above, so all four move together on the white page and on the slate panel without restating a value. THE SUMMARY'S LINKS ARE NOT STYLED HERE. They are anchors, and anchors on this page are enumerated in contact.css against the WHITE ground -- teal ink that would measure badly on slate. Overriding them from this sheet would mean out-specifying rules in a sheet that loads after it, so the correction lives beside the rules it corrects instead. See contact.css. --------------------------------------------------------------------- / body .contact-pageform .contact-pageerror, body .contact-pagepanel .contact-pagenotice, body .contact-pagepanel .contact-pagesummary-title { color: var(--state-input-error-fg); } / The summary's box, drawn so the block reads as one thing rather than as a loose heading above a list. The rule is the same non-colour carrier the fields use -- an edge on the leading side, not a fill -- which is why there is no background here to measure against. ITS WIDTH AND THE PADDING THAT CLEARS IT LIVE IN DIFFERENT FILES, which is a seam worth naming since neither file's banner would lead you to expect it: this sheet owns colour and that is why the border is here, while `contact.css` owns layout and carries the `padding-left: 16px` that was sized against these 4px. Change one and the other no longer matches. contact.css says the same thing at its end of the seam. / body .contact-pagepanel .contact-pagesummary { border-left: 4px solid var(--state-input-error-fg); } / The confirmation takes the panel's own ink. Stated rather than left to inherit for the reason the panel's title and subheading are: Neve paints this panel's descendants from typography theme_mods chosen against the page, and this ground is not the page. / body .contact-pagepanel .contact-pagesent { color: var(--color-form-panel-fg); } / THE CHECKBOX -- the site's first, and the one control here drawn from scratch. `appearance: none` is what makes the box paintable at all; a native checkbox takes its colour from the platform and ignores everything below. The tick is a rotated two-sided box on ::after rather than an SVG or a character, so it needs no font, no asset and no additional element, and it scales with the border width. `scale(0)` AT REST RATHER THAN `display: none`, so the mark has a geometry to grow from; nothing animates it today, which is why there is no reduced-motion counterpart in this file. / body .contact-pageform .contact-pagecheck-input { appearance: none; -webkit-appearance: none; flex: none; width: 22px; height: 22px; margin: 1px 0 0; display: grid; place-items: center; background-color: var(--state-check-rest-bg); border: 2px solid var(--state-check-rest-bd); border-radius: var(--shape-check-radius); cursor: pointer; } body .contact-pageform .contact-pagecheck-input::after { content: ""; width: 6px; height: 11px; margin-top: -2px; border: solid var(--state-check-mark-fg); border-width: 0 2.5px 2.5px 0; transform: rotate(45deg) scale(0); } body .contact-pageform .contact-pagecheck-input:hover { border-color: var(--state-check-hover-bd); } body .contact-pageform .contact-pagecheck-input:checked { background-color: var(--state-check-checked-bg); border-color: var(--state-check-checked-bd); } body .contact-pageform .contact-pagecheck-input:checked::after { transform: rotate(45deg) scale(1); } body .contact-pageform .contact-pagecheck-input:focus-visible { outline: 2px solid var(--state-input-focus-ring); outline-offset: 2px; } / THE CHECKBOX'S TEXT IS AN ANSWER, NOT A FIELD LABEL, which is why it is the one label on this panel that does not take the green label ink. It reads as a sentence the visitor is agreeing with, so it takes the panel's body ink at 8.37:1 and a normal reading size; the green marks the NAME of a field you are about to fill in, and this is not one. `cursor: pointer` because the whole label is a click target -- which is the doing its job, not a rule here. / body .contact-pageform .contact-pagecheck-label { font-family: var(--font-body); font-size: 16px; font-weight: 500; line-height: 1.45; letter-spacing: 0.2px; color: var(--state-check-label-fg); cursor: pointer; } / THE NOTE BESIDE THE SUBMIT IS GONE, and so is this rule. Story 2's own comment here ended "It goes when the handler lands", and story 3 is the handler landing: the sentence it styled said sending was not connected yet, which stopped being true. Recorded rather than silently deleted because a reader comparing this file against story 2's diff will look for it. / / --------------------------------------------------------------------- INLINE BODY-COPY LINKS -- the third gap, and the only one with no child-theme owner at all: a grep for a bare `a {` / `a:` selector across theme/.css returned nothing. Two selector groups: 1. The four `single-project` prose regions, which emit their own markup. 2. Neve's content wrapper. CONFIRMED LIVE 2026-09-19 against dev.joetennis.com: `.nv-content-wrap.entry-content`, exactly one per page. About / Blog / `experiment` render their prose through Neve markup, because the four modern `project` templates `esc_html()` theirs (templates/simple-stack.php:397-403) -- so without this group those pages have no owned link treatment at all. If a future Neve release renames that wrapper, these links fall back to Neve's own styling: degraded, not broken. Specificity: Neve's `.entry-content a:not([class])` (0,2,1) sets `--linkdeco: underline`, and its `a:hover, a:focus` (0,1,1) tints every anchor to the SECONDARY accent. The `body` prefix plus `:not(.button)` clears both. `:not(.button)` also keeps a CTA dropped into prose on the button rules above. TWO THINGS TO KNOW ABOUT THESE VALUES: (a) The decided cells REMOVE the rest underline on both grounds. That is a real change here -- Neve underlines unclassed content links today. (b) With no rest underline, WCAG 1.4.1 falls back to colour alone, and the comparison it makes is against the SURROUNDING BODY TEXT, not the page. The dark-ground rest ink was re-derived for exactly this reason and is now #0f8c9d at 3.24:1 against body ink -- see the long note on `--state-link-rest-fg` in the token block above for the derivation and the luminance window. The white ground already passed at 3.39:1 and is unchanged. / .single-projectintro-summary a, .single-projectpsr-body a, .single-projectdetails-body a, .single-projecttoggle-body a, body .nv-content-wrap.entry-content a:not(.button):not(.wp-block-buttonlink) { color: var(--state-link-rest-fg); border-radius: var(--shape-link-radius); font-weight: 400; text-decoration: none; --linkdeco: none; /* Neve renders `text-decoration: var(--linkdeco)`. / } .single-projectintro-summary a:hover, .single-projectpsr-body a:hover, .single-projectdetails-body a:hover, .single-projecttoggle-body a:hover, body .nv-content-wrap.entry-content a:not(.button):not(.wp-block-buttonlink):hover { color: var(--state-link-hover-fg); text-decoration: underline; text-decoration-thickness: 2px; text-underline-offset: 2px; --linkdeco: underline; } .single-projectintro-summary a:focus-visible, .single-projectpsr-body a:focus-visible, .single-projectdetails-body a:focus-visible, .single-projecttoggle-body a:focus-visible, body .nv-content-wrap.entry-content a:not(.button):not(.wp-block-buttonlink):focus-visible { color: var(--state-link-focus-fg); text-decoration: underline; --linkdeco: underline; outline: 2px solid var(--state-link-focus-ring); outline-offset: 2px; } / --------------------------------------------------------------------- BREADCRUMB LINKS -- the second control that hovered more than one way, and the one story 1 had no tokens for. flush-split.css moved `color` through a BARE `var(--nv-primary-accent)` -- no local fallback, so an unresolved Neve variable dropped the declaration and left the link with no hover affordance at all. simple-stack.css used the mandatory fallback pattern. Same design, two idioms, one of them a latent silent no-op; both now resolve from the tokens above. Rest ink stays in the template sheets (`color: inherit`): a breadcrumb at rest is ground ink, not a state. No ring is declared -- the baseline `a:focus-visible` already paints one, measured against the ground rather than against this ink. RECONCILED IN STORY 3. flush-split-white.css used to override these at (0,3,1) with a text-decoration hover instead of a colour one -- the one cell on the site where a ground changed the PROPERTY rather than the value, which is what CAP-2 forbids. That override is retired; the white ground binds these and moves `color`, exactly as the dark ground does. (Both grounds bound BOTH roles to #0b6b78 / cyan when that was written; as of 2026-09-21 hover follows `--current-marker` per ground -- #8100fc here at 6.29:1, #a855f7 on dark at 4.87:1 -- while focus keeps #0b6b78 at 6.20:1. See the role declarations for why hover moved and why focus did not.) It also closes the failure mode story 2 opened here: with the white override in place and no colour binding, these rules resolved to cyan on white at 1.54:1, carried only by that underline. / .flush-splitbreadcrumb-item a:hover, .simple-stackbreadcrumb-item a:hover { color: var(--state-breadcrumb-hover-fg); } .flush-splitbreadcrumb-item a:focus-visible, .simple-stackbreadcrumb-item a:focus-visible { color: var(--state-breadcrumb-focus-fg); } / --------------------------------------------------------------------- CAROUSEL CONTROLS -- the one control that hovered three different ways in three templates, which is the clearest evidence of the drift this spec exists to remove. As of story 2 it hovers ONE way: the three template sheets keep only geometry, and every colour, the radius and the glyph weight resolve from here. THREE THINGS STORY 2 ADDED, all visible: - `font-weight`. No `carousel-btn` rule in any sheet declared it, so the glyphs took Neve's button weight (600, measured live). The decided cell is 500. - `border-color` on `:disabled`, the decided disabled cell. This used to RENDER AS NOTHING and the arithmetic for that is worth keeping, because v1.13.4 broke it: the rest edge was `rgba(0, 229, 255, 0.3)` at element opacity 1 and disabled is a full-alpha accent at element opacity 0.3, so both landed at an effective alpha of 0.3 and the edge did not move. The ink did not move either -- `--state-carousel-disabled-fg` was the same `#f8fafc` as rest -- so `opacity: 0.3` alone was what made a disabled button read as disabled. SINCE v1.13.4 THE REST EDGE IS SOLID `#ffffff` AND THAT SYMMETRY IS GONE. A disabled button would now show a faded CYAN edge against a solid white one, i.e. it would read as "hovered and faded" rather than as disabled. NOBODY CAN SEE IT: flush-split.js wraps at both ends and never disables either button, and the one carousel any JS does disable (`single-project.js`) emits `editorial-split` markup, so the selector matches nothing on the site. Recorded rather than fixed, because fixing it means picking a disabled edge value that no decision row covers and that nothing would render. If a flush-split carousel ever gains a disabled state, THIS is the cell to decide first -- do not read the paragraph above as saying it is harmless. Worse, nothing can exercise it. `.single-projectcarousel-btn` is the only carousel any JS ever disables (single-project.js:121 and :124) and `single-project.php` emits `editorial-split` markup instead, so that selector matches nothing on the site. flush-split.js and simple-stack.js both state in-file that they have no disabled-at-the-ends state. See KNOWN GAPS item 4. - `border-radius`, from `--shape-carousel-radius`. Story 4 took it to 999px from the token block alone -- no change here. Both buttons that actually render show the shape at rest, since story 2 had already given simple-stack the edge it needed; they are not the same shape, because their boxes are not the same size. See the Family C carousel note. HAZARD 1 IS RETIRED, DELIBERATELY AND WITH MEASUREMENT. `simple-stack.css` used to draw `outline: 2px solid currentColor` and split `:hover` off into its own selector so that `currentColor` could never be the accent when the ring was painted. That defence was chosen against a LIGHT page (its comments quoted 1.54:1 and ~1.3:1) and the template has not rendered on one for some time. Measured live on the real ground 2026-09-19, on `/projects/auto-loan-future/`: the `currentColor` ring scores 15.62:1 and this sheet's cyan ring 12.52:1, against a 3:1 non-text floor. Joe ruled the local ring out the same day, so all three carousels now share one rule. What replaces the defence is the token, not an accident of selectors: a ground where a cyan ring would fail re-binds `--state-carousel-focus-ring`, exactly as flush-split.css does for white. `:hover` and `:focus-visible` still get separate selectors below -- not to protect `currentColor` any more, but because the decided focus cell keeps the rest ink while hover moves it. THE FILL IS DECLARED IN STORY 5, AND NO `body` PREFIX IS NEEDED. Measured live 2026-09-19: exactly two Neve rules reach a carousel button's background -- `button` at (0,0,1), which the template sheets' own `background: transparent` at (0,1,0) already outranks, and `button:hover` at (0,1,1), which nothing outranked because no rule here declared the property at all. These selectors are (0,2,0) and beat it. Do not raise them to `body ...`; that would be unearned specificity of exactly the kind the baseline block below warns against. / .flush-splitcarousel-btn, .simple-stackcarousel-btn, .single-projectcarousel-btn { background-color: var(--state-carousel-rest-bg); color: var(--state-carousel-rest-fg); border-color: var(--state-carousel-rest-bd); border-radius: var(--shape-carousel-radius); font-weight: 500; } .flush-splitcarousel-btn:hover, .simple-stackcarousel-btn:hover, .single-projectcarousel-btn:hover { background-color: var(--state-carousel-hover-bg); color: var(--state-carousel-hover-fg); border-color: var(--state-carousel-hover-bd); } .flush-splitcarousel-btn:focus-visible, .simple-stackcarousel-btn:focus-visible, .single-projectcarousel-btn:focus-visible { border-color: var(--state-carousel-focus-bd); outline: 2px solid var(--state-carousel-focus-ring); outline-offset: 2px; } .flush-splitcarousel-btn:disabled, .simple-stackcarousel-btn:disabled, .single-projectcarousel-btn:disabled { color: var(--state-carousel-disabled-fg); border-color: var(--state-carousel-disabled-bd); opacity: 0.3; cursor: default; } / --------------------------------------------------------------------- ARCHIVE FILTER CHIP -- Family A cells only, and live as of story 2: archive-project.css now keeps geometry alone. THE FUNNEL ICON RIDES ALONG. `.portfolio-archivetoolbar-icon` opens the filter panel below 768px and had its own hover/focus rule moving ink and edge to the accent -- a seventh idiom, and the last ad hoc state rule in that file. It has no cell in state-values.md, so Joe ruled it onto the CHIP family (2026-09-19): a filter control, in the filter toolbar, that acts in place -- the same affordance tier as the chips it opens. Its rest edge moves purple -> white with them, and it newly takes weight 500, which archive-project.css never declared for it. SCOPING ASYMMETRY, DELIBERATE BUT WORTH KNOWING: these rules are unconditional, while the icon's GEOMETRY (width, height, border width and style) lives inside archive-project.css's `max-width: 768px` block, because the icon is `display: none` above that. Nothing breaks today. But a future decision to show the funnel at wide viewports would get a coloured edge with no width until that geometry is unscoped. The shared sheet does not carry template breakpoints, so the fix belongs there, not here. HAZARD 2 IS NOW A RULE, NOT AN ACCIDENT. `archive-project.css:263-265` used to keep a hovered, already-SELECTED chip looking selected purely because its `:hover` rule sat before `.is-active` in one file. With hover moved here that ordering would still work -- this sheet loads first -- but it would be banking the same accident across two files instead of one. The `:not(.is-active)` below states the contract's precedence rule directly: Family A never overrides Family B, whatever the file order. CHIP HOVER IS COLOUR-ONLY, AND THAT IS A RULING, NOT AN OVERSIGHT. `--state-chip-rest-bd` and `--state-chip-hover-bd` are both #ffffff, so once the fill was ruled off, hover moves ink alone. That sits against SPEC.md's "colour is never the sole carrier of a state", and against the inline-link block above, which earns its hover by thickening an underline. Joe was shown the tension and offered a non-colour carrier (a thickened edge via inset box-shadow, no layout shift) and chose colour-only, 2026-09-19: the chip already reads as operable from its border and cursor, so nothing here is conveyed by colour ALONE that is not conveyed otherwise, and hover is pointer-only and supplementary. Do not "fix" this by adding a carrier. The strict rule still binds Family B, where weight 600 is load-bearing. The constraint's exception is handed to bmad-spec at docs/handover/2026-09-19-bmad-spec-story2-contract-amendments.md. THE CHIP'S FAMILY B CELLS LANDED IN STORY 5, in the Family B block below rather than here -- they are not a chip state, they are the selected state that happens to appear on a chip. What archive-project. css used to ship (near-white ink on an #a855f7 fill) measured 3.85:1 and failed the 4.5:1 text floor; the decided cell, with its fill ruled off on this ground, measures 4.87:1 and passes. --------------------------------------------------------------------- / .portfolio-archivechip, .portfolio-archivetoolbar-icon { background-color: var(--state-chip-rest-bg); color: var(--state-chip-rest-fg); border-color: var(--state-chip-rest-bd); border-radius: var(--shape-chip-radius); font-weight: 500; } .portfolio-archivechip:not(.is-active):hover, .portfolio-archivetoolbar-icon:hover { color: var(--state-chip-hover-fg); background-color: var(--state-chip-hover-bg); border-color: var(--state-chip-hover-bd); } / `:not(.is-active)` on the EDGE for the same reason it is on hover. Without it, `.portfolio-archivechip.is-active` in archive-project.css ties this rule at (0,2,0) and wins on order, so a focused SELECTED chip would take its edge from the local Family B rule rather than from the token -- the second source-order dependency of exactly the kind the hover rule was written to remove. It renders identically today only because `--color-accent-secondary` and `--state-chip-focus-bd` both resolve to #a855f7, and that equality holds only while Neve leaves `--nv-secondary-accent` undefined. The RING is deliberately outside the guard: a selected chip must still show a focus indicator. / .portfolio-archivechip:not(.is-active):focus-visible, .portfolio-archivetoolbar-icon:focus-visible { border-color: var(--state-chip-focus-bd); } .portfolio-archivechip:focus-visible, .portfolio-archive__toolbar-icon:focus-visible { outline: 2px solid var(--state-chip-focus-ring); outline-offset: 2px; } / --------------------------------------------------------------------- THE <=768px FILTER OVERLAY'S CLOSE BUTTON -- adopted into the chip family 2026-09-20, v1.11.7. It sits inside the overlay directly beside the chips and was the last control in archive-project.css owning neither their colour behaviour nor their shape. WHY IT NEEDS A `body` PREFIX AND THE CHIPS DO NOT. This control is a bare