/* Vivly Living — newsletter WPForms embed (form 366). NOT built on css/form-embed.css. That sheet encodes the Contact/Land layout (two-up field grid, 200px pill Send button below the fields); this band is a single 58px inline row with a 50px square button fused to the right edge of the field. Sharing it would mean overriding most of it. What IS shared is its METHOD, and the two routes it documents: Route (a) — restyle via WPForms' own --wpforms-* custom properties. A custom property resolves by cascade on the element (or by inheritance), NOT by the specificity of the rule that later reads it with var(). Redeclaring on .wpforms-container therefore beats WPForms' :root defaults for every descendant regardless of stylesheet load order — which matters, because WPForms' tags render at the very END of , i.e. after this file, so it wins same-specificity literal fights. Route (b) — where WPForms hardcodes a literal, deepen the selector using the REAL ancestor classes until it wins outright. Specificity arithmetic is stated at each such rule. Markup this file targets, read from the live rendered output of [wpforms id="366"] rather than assumed: div.wpforms-container.wpforms-container-full.wpforms-render-modern#wpforms-366 form.wpforms-validate.wpforms-form noscript.wpforms-error-noscript (not rendered when JS is on) div#wpforms-error-noscript (inline style="display:none") div.wpforms-field-container div.wpforms-field.wpforms-field-email label.wpforms-field-label > span.wpforms-required-label input[type=email].wpforms-field-medium.wpforms-field-required div.wpforms-recaptcha-container (one hidden input only) div.wpforms-submit-container 4 x input[type=hidden] button.wpforms-submit[type=submit] The !important on every variable below is the SAME single justified exception form-embed.css documents: WPForms writes a per-form `#wpforms-366 { --wpforms-*: ... }` block from settings.themes (CSSVars.php:399-406) at ID specificity (1,0,0), which would beat a plain (0,2,0) rule here with no error — button silently reverting to WPForms blue, radii to 3px. Form 366 was created by a direct post_content write that deliberately OMITS settings.themes, so that block is empty today; the !important keeps it that way if anyone ever opens the Themes/Style tab on it. Do not take this as licence for !important anywhere else in this file — there is none. */ /* -- Container: kill WPForms' outer margins, then Route (a) ------------- */ /* WPForms: `div.wpforms-container-full:not(:empty){margin:24px auto}` is (0,2,1); three classes here = (0,3,0), an outright win. */ .vl-newsletter__form-embed .wpforms-container.wpforms-container-full { margin: 0; } .vl-newsletter__form-embed .wpforms-container { margin: 0; max-width: none; /* WPForms caps this; the band's own column width rules */ /* Field — node 57:50/57:51: 58px cream field, 1px ink border, radius 10. Height, background, border colour/size/style, text colour, font size and horizontal padding are ALL variable-driven in WPForms' own rules, so they need no literal override. The asymmetric border-radius and the removed right border cannot be expressed as variables and are handled by Route (b) below. */ --wpforms-field-size-input-height: 58px !important; --wpforms-field-background-color: var(--vl-cream) !important; --wpforms-field-border-color: var(--vl-ink) !important; --wpforms-field-border-style: solid !important; --wpforms-field-border-size: 1px !important; --wpforms-field-text-color: var(--vl-ink) !important; --wpforms-field-size-font-size: var(--vl-text-input) !important; /* 30px desktop */ --wpforms-field-size-padding-h: 20px !important; /* Both controls set their own asymmetric radius literally below (no variable can express one). These baselines exist so that IF a literal ever loses a specificity fight to a future WPForms rule, the fallback is square — not WPForms' 3px, which would round the fused inner edges and read as two detached controls. */ --wpforms-field-border-radius: 0 !important; /* Button — node 57:52/57:53: 50px brick square, right corners rounded. Height matches the field so the two read as one control. */ --wpforms-button-background-color: var(--vl-brick) !important; --wpforms-button-border-color: var(--vl-ink) !important; --wpforms-button-border-style: solid !important; --wpforms-button-border-size: 1px !important; --wpforms-button-text-color: var(--vl-white) !important; --wpforms-button-border-radius: 0 !important; /* see the field baseline above */ --wpforms-button-size-height: 58px !important; /* Its only consumer is .wpforms-submit-container's margin-top; the button sits INSIDE the row here, not below it. */ --wpforms-button-size-margin-top: 0 !important; } /* -- The row ----------------------------------------------------------- */ /* field-container and submit-container are SIBLINGS, both direct children of the form (the structural fact form-embed.css's header records getting wrong first time) — so the flex row goes on the form itself. */ .vl-newsletter__form-embed .wpforms-form { display: flex; align-items: stretch; } /* v3 reCAPTCHA's container holds nothing but a hidden input, but it is still a flex item. display:none removes it from the row WITHOUT removing the input from the submission — only `disabled` does that, and this isn't. */ .vl-newsletter__form-embed .wpforms-recaptcha-container { display: none; } .vl-newsletter__form-embed .wpforms-field-container { flex: 1 1 auto; min-width: 0; /* let the field shrink inside the row (flex min-size-auto) */ } /* Route (b). WPForms stacks TWO padding rules on this element: `.wpforms-container .wpforms-field{padding:15px 0}` (0,2,0) and `div.wpforms-container .wpforms-form .wpforms-field{padding-inline:1px}` (0,3,2). Four classes here = (0,4,0), which beats (0,3,2) on class count and so wins outright. A (0,3,0) selector would NOT — it ties on classes and loses on elements. */ .vl-newsletter__form-embed .wpforms-field-container .wpforms-field.wpforms-field-email { padding: 0; } /* Label stays in the accessibility tree — it is the input's only accessible name (a placeholder is not one). Clipped rather than moved to left:-9999px so it can never contribute scroll width. WPForms' label rule is (0,2,1); three classes here = (0,3,0). */ .vl-newsletter__form-embed .wpforms-field-container .wpforms-field-label { position: absolute; width: 1px; height: 1px; margin: 0; padding: 0; overflow: hidden; clip-path: inset(50%); white-space: nowrap; } /* The asterisk is decorative here (this is the only field, and the span already carries aria-hidden="true") and the design shows none. */ .vl-newsletter__form-embed .wpforms-field-container .wpforms-required-label { display: none; } /* Route (b). WPForms' base input rule is `div.wpforms-container-full input[type=email]` = (0,2,2). Three classes + the [type] attribute = (0,4,1) here, an outright win. Only the two properties no variable can express are restated. */ .vl-newsletter__form-embed .wpforms-field-container .wpforms-field input[type="email"] { width: 100%; /* LOAD-BEARING, and the bug this file shipped with (Liam spotted it live, 2026-08-24): the field stopped ~60% across, leaving a cornflower gap before the button. WPForms' field-size feature is implemented as `.wpforms-container input.wpforms-field-medium{max-width:60%}` — and max-width CLAMPS width no matter how specific the width rule is, so `width:100%` alone could never win. The field is 'medium' in the form definition; releasing the cap here rather than switching it to 'large' keeps the layout correct whatever size the form is later saved with. */ max-width: 100%; border-right: none; /* the button's own left border is the single line between them */ border-radius: var(--vl-radius-field) 0 0 var(--vl-radius-field); } .vl-newsletter__form-embed .wpforms-field-container .wpforms-field input[type="email"]::placeholder { color: var(--vl-grey); opacity: 1; /* Firefox dims placeholders by default */ } /* -- The button -------------------------------------------------------- */ .vl-newsletter__form-embed .wpforms-submit-container { flex: 0 0 50px; /* node 57:52 — 50px wide, full row height */ display: flex; margin: 0; padding: 0; } /* Route (b). WPForms' base button rule is `div.wpforms-container-full button[type=submit]` = (0,2,2); the real-class chain here is (0,3,0), an outright win — the same construction form-embed.css uses for the Send button. */ .vl-newsletter__form-embed .wpforms-submit-container .wpforms-submit { display: flex; align-items: center; justify-content: center; width: 100%; padding: 0; /* All four borders, as the stub had: the input drops its RIGHT border so the button's LEFT border is the single line between the two. Removing this one as well (which the first version did) leaves no line at all. */ border-radius: 0 var(--vl-radius-field) var(--vl-radius-field) 0; /* The button's text is its accessible name ("Sign up", and "Signing up..." while submitting) and must stay in the DOM. font-size:0 hides it visually while leaving it announced; the arrow below is a ::before, sized in px so it is unaffected. */ font-size: 0; cursor: pointer; overflow: hidden; /* keeps the arrow inside the rounded corner (it no longer slides -- see the hover note below -- but the clip still guards the radius) */ transition: background-color 0.2s ease; } /* Arrow: masked, not an , so its colour is CSS-controlled — same construction as the card CTAs (card-development.css). */ .vl-newsletter__form-embed .wpforms-submit-container .wpforms-submit::before { content: ''; flex: 0 0 auto; width: 24px; /* node svgexport-13 1 */ height: 12px; background-color: var(--vl-white); -webkit-mask: url("../assets/icon-arrow-right.svg") no-repeat center / contain; mask: url("../assets/icon-arrow-right.svg") no-repeat center / contain; } /* Hover is driven by the WHOLE row, not the button — same interaction language as the card CTAs (Liam, 2026-07-23). Specificity note: WPForms' `button[type=submit]:not(:hover):not(:active)` rule is (0,4,2) and it STILL MATCHES while the row is hovered but the button itself is not (e.g. the pointer is over the field). Its background-color is variable-driven, so a var() override would be inherited — but this needs a LITERAL different colour, so the selector must out-specify it: five classes = (0,5,0) beats (0,4,2). A shorter chain without .wpforms-submit-container would tie on classes and lose. */ .vl-newsletter__form-embed .wpforms-form:hover .wpforms-submit-container .wpforms-submit { background: var(--vl-brick-dark); } /* NO arrow movement on hover (client request via Liam, 2026-08-25). The arrow used to slide 5px right with the row hover, matching the card CTAs (card-development.css :136, dev-plots.css :667, popup.css :302, all 10px). The client disliked it HERE specifically; those others are deliberately untouched, so this button is now the one exception to that interaction language. The background-colour change on hover stays -- only the movement went. Removed with it: the `transition: transform` on the ::before above, which had nothing left to animate. */ /* -- Focus ------------------------------------------------------------- */ /* The sitewide focus ring is cornflower, which is invisible on this band — the band IS cornflower. Ink instead, on both controls. */ .vl-newsletter__form-embed .wpforms-field-container .wpforms-field input[type="email"]:focus-visible { outline: 2px solid var(--vl-ink); outline-offset: 2px; } /* WPForms sets `outline:none` on the button's :focus at (0,2,2); (0,3,0) here wins outright. */ .vl-newsletter__form-embed .wpforms-submit-container .wpforms-submit:focus-visible { outline: 2px solid var(--vl-ink); outline-offset: 2px; } /* WPForms draws its own focus ring as a :focus::after inset border coloured --wpforms-button-background-color — i.e. brick on brick, invisible, and it would sit under our outline anyway. (0,3,0) + pseudo-element beats its (0,2,2) + pseudo-element. */ .vl-newsletter__form-embed .wpforms-submit-container .wpforms-submit:focus::after { display: none; } /* -- Validation -------------------------------------------------------- */ .vl-newsletter__form-embed .wpforms-field-container .wpforms-field input.wpforms-error, .vl-newsletter__form-embed .wpforms-field-container .wpforms-field input.user-invalid { border-color: #D63637; /* WPForms' own invalid red, matching form-embed.css */ } /* WPForms injects its error label INSIDE the field div, which would grow the 58px row and shove the button out of line. Taken out of flow instead and hung below the row — .wpforms-field already carries position:relative from WPForms' own `.wpforms-container .wpforms-field` rule, so this anchors to the field. */ .vl-newsletter__form-embed .wpforms-field-container .wpforms-field .wpforms-error { position: absolute; top: 100%; left: 0; margin-top: 8px; font-size: var(--vl-text-sm); line-height: 22px; } /* -- Confirmation (inline, Liam 2026-08-24) ---------------------------- */ /* This band sits in the footer of every page, so a redirect would throw away wherever the visitor was for a minor action; the form is replaced in place instead. WPForms styles this container with `color:#333` and `margin:0 auto 24px; padding:15px` at (0,2,1) — stripped back here to sit in the band as plain type at field size, so the confirmation reads as the field it replaced. Both shapes of the markup are covered: the in-container form, and the `div[submit-success]` form. */ .vl-newsletter__form-embed .wpforms-container .wpforms-confirmation-container-full, .vl-newsletter__form-embed div[submit-success] > .wpforms-confirmation-container-full { margin: 0; padding: 0; border: none; background: none; color: var(--vl-ink); font-family: var(--vl-font); font-size: var(--vl-text-input); font-weight: var(--vl-weight-regular); line-height: 1.2; } /* -- Admin-only notice (wire-or-hide) ---------------------------------- */ .vl-newsletter__notice { margin: 0; font-size: var(--vl-text-sm); line-height: 22px; } /* -- Tablet / mobile --------------------------------------------------- */ /* Matches the stub's own breakpoint: the 30px field size steps to 20px so a real email address still fits the narrower row. Set through the variable (Route (a)) rather than a literal, because WPForms' input font-size rule is the thing that reads it. */ @media (max-width: 767px) { .vl-newsletter__form-embed .wpforms-container { --wpforms-field-size-font-size: 20px !important; } }