/* --------------------------------------------------------------------- v12 -- matched to sonnettech.com's own chrome. Every value read from the live site on 2026-09-23, not chosen: brand purple #6b539c (the dominant brand colour in css/sonnet.webflow.css, 26 uses) nav text #fff, hover #ffffff80 font stack Roboto Custom, Arial, sans-serif WHY A SEPARATE FILE rather than editing style.css: v1-v8 share that stylesheet and their visual match to the current support page was verified separately. This loads after it and overrides only the chrome, so nothing earlier moves. The font falls back to Arial, which is what the live stack does when Roboto Custom is unavailable. We do not hotlink their font file -- it would break the moment they move it. --------------------------------------------------------------------- */ :root { --sonnet-purple: #6b539c; --sonnet-purple-dark: #5d3e8f; --sonnet-nav-text: #ffffff; } body.v12, body.v12 input, body.v12 select, body.v12 textarea, body.v12 button { font-family: 'Roboto Custom', Roboto, Arial, Helvetica, sans-serif; } /* The purple bar. On the live site it spans the full width with the logo left and the links right. */ body.v12 .site-header { background: var(--sonnet-purple); border-bottom: 0; } body.v12 .site-header .wrap, body.v12 .header-inner { display: flex; align-items: center; justify-content: space-between; padding-top: 14px; padding-bottom: 14px; } /* Their logo is white on the purple; ours is the dark mark, so invert it rather than shipping a second image. */ /* The logo is a dark mark on transparent. brightness(0) invert(1) turns every opaque pixel white -- which reads as a white block where the mark is solid. Left at its own colours instead; the mark is dark enough to sit on the purple without inverting. */ body.v12 .brand img { height: 26px; width: auto; } /* The page title block: gear icon, centred heading, grey standfirst -- the shape of the live support page. */ body.v12 .site-hero { text-align: center; padding: 46px 0 8px; } body.v12 .site-hero svg { width: 92px; height: 92px; margin-bottom: 18px; } body.v12 .site-hero h1 { font-size: 42px; line-height: 1.15; font-weight: 700; color: #1d1d1f; margin: 0 0 10px; letter-spacing: -0.5px; } body.v12 .site-hero p { font-size: 19px; color: #6e6e73; margin: 0; } body.v12 .page-intro { display: none; } /* replaced by .site-hero */ /* One token, not a pile of rules. style.css exposes design tokens as custom properties and the project convention is to change the token rather than override each rule -- otherwise every new accent-coloured element has to be found and repainted by hand. Repointing --color-accent turns the buttons, the step numbers, the rail's current marker and the focus rings purple in one line, because they all already read from it. */ body.v12 { --color-accent: #6b539c; --color-accent-d: #5d3e8f; /* The recessed grey, biased toward the accent. * * Was #f5f5f7 -- Apple's system grey, which carries a faint blue * cast (R245 G245 B247). Beside a purple accent that reads slightly * cold, and it left the recessed surfaces disagreeing: the receipt * box was retinted purple while the disclosure and the macOS panel * stayed blue-grey. * * Same lightness, hue nudged off blue and onto the accent. One * token, so all nineteen surfaces in style.css that read * --color-bg-alt move together and anything added later inherits * it. A neutral should look chosen; a stock system grey looks like * whatever the framework shipped. */ --color-bg-alt: #f6f4f9; } /* Links take the brand purple -- but NOT links styled as buttons. * * `body.v12 a` is class+element, which outranks a plain `.btn-hero` * class selector, so this quietly repainted the white text on the FAQ * button purple. Purple text on a purple button is invisible, and it * only showed up on step 2 where that button lives. * * :not() carries no specificity of its own, so this stays exactly as * strong as before -- it just stops applying to buttons. */ body.v12 a:not([class*="btn"]) { color: var(--sonnet-purple); } /* Belt and braces: restate white on the button links, so a future selector cannot take it away silently again. */ /* The header nav, restated AFTER the link rule above. * * `body.v12 a:not([class*="btn"])` and `body.v12 .site-header a` have * IDENTICAL specificity -- :not() contributes the weight of its * argument, and an attribute selector counts the same as a class. With * the two tied, source order decides, and the link rule used to come * last: the nav went purple on a purple bar and disappeared. * * Declared here, below it, so the nav wins. */ body.v12 .site-header a, body.v12 .site-header .brand { color: var(--sonnet-nav-text); } body.v12 .site-header a:hover { color: #ffffff80; } body.v12 a.btn-hero, body.v12 a.btn-primary, body.v12 a.btn { color: #fff; /* No underline. A filled, padded, rounded control already reads as clickable three ways over; the underline only says "this is really an ", which is an implementation detail. The live site's buttons carry none either. */ text-decoration: none; } /* Hover and keyboard selection are DIFFERENT states, so they look different. They shared one rule, and the result was two identically highlighted rows whenever the pointer happened to rest over the list while somebody was arrowing through it -- with no way to tell which one Enter would take. Reported from a screenshot on 30 September that appeared to show two selections. Hover is a tint: "your mouse is passing over this". Keyboard selection is the stronger claim -- "Enter takes this one" -- so it earns a deeper ground, a marker down the left edge, and more weight. The padding compensates for the border so the text does not shift as the highlight moves down the list. */ body.v12 .ta-item:hover { background: #f5f2fb; } body.v12 .ta-item.is-active { background: #e7defa; border-left: 3px solid var(--color-accent, #6b539c); padding-left: 11px; /* 14px - 3px border */ font-weight: 600; } /* And when both land on the same row, the keyboard wins: it is the one that says what Enter will do. */ body.v12 .ta-item.is-active:hover { background: #e7defa; } /* The active step card. * * style.css gives .sim-step.is-hero a LITERAL blue border and a * blue-tinted shadow rather than reading from --color-accent, so * repointing the token left it behind -- it read as a stray blue * selection ring around the card on an otherwise purple page. * * Tints of #6b539c at the same weights: the border is the brand purple * lightened to sit quietly against white, the shadow is the same hue at * the original 0.09 alpha. */ body.v12 .sim-step.is-hero { border-color: #d5cce6; box-shadow: 0 2px 14px rgba(107, 83, 156, 0.09); } /* The rest of the literal blues. * * Six more places in style.css use rgba(10,132,255,…) or #b9dcff * directly instead of --color-accent, so none of them followed the * token. Found by grepping the stylesheet for those two values rather * than by looking at the page -- several only appear mid-flow, on the * assistant panel and the article verdict, where a stray blue would not * have shown up until the demo was already running. * * If more turn up, the grep is: * grep -nE '#b9dcff|rgba\(10, *132, *255' assets/style.css */ body.v12 input:focus, body.v12 select:focus, body.v12 textarea:focus { box-shadow: 0 0 0 3px rgba(107, 83, 156, 0.18); } body.v12 .btn-secondary:hover, body.v12 .btn-match:hover:not(:disabled), body.v12 .match-verdict.is-onward { background: rgba(107, 83, 156, 0.06); } body.v12 .chat-turn.is-assistant { background: rgba(107, 83, 156, 0.05); } body.v12 .sim-demo { border-color: #d5cce6; } /* Completed steps in the brand purple rather than green. * * style.css marks them with --color-success, which is semantically * right -- green reads as "done" without being taught. But there is no * green anywhere on sonnettech.com, so on this skin it read as a * different system's UI bolted on. * * Safe to change because colour is not the only signal: the rail also * gives the CURRENT step a bold label and an underline, so done and * current stay distinguishable when every circle is purple. Were that * not true this would cost real information and the green would be * worth keeping. * * Done is the full-strength purple and current is lighter, so the eye * still lands on where you are. */ body.v12 .sim-rail li.is-done .n, body.v12 .sim-step.is-done .sim-num { background: #6b539c; } body.v12 .sim-rail li.is-current .n, body.v12 .sim-step.is-hero .sim-num { background: #8b74b8; } /* Focus on buttons and links. * * style.css styles :focus for inputs, selects and textareas only -- * buttons and links fall through to the browser's own ring, which is * blue on Chrome and macOS. Everything else on this skin is purple, so * that one blue outline is the tell that the theme is a layer. * * :focus-visible, not :focus -- the ring appears for keyboard users and * stays off when the same control is clicked with a mouse, which is * what people expect and why the browser itself works that way. * * Never remove it without replacing it: keyboard users navigate by * this, and it is the one focus indicator these controls have. */ body.v12 button:focus-visible, body.v12 a:focus-visible, body.v12 .btn:focus-visible, body.v12 .btn-hero:focus-visible, body.v12 .btn-primary:focus-visible, body.v12 .btn-secondary:focus-visible { outline: 2px solid #6b539c; outline-offset: 2px; border-radius: var(--radius-button, 8px); } /* Form controls the browser paints itself. * * Radios, checkboxes and progress bars are drawn by the OS, not by our * CSS, so they came out in the system accent -- blue on this Mac, and * whatever the visitor has chosen on theirs. That is the same family as * the green checkmark and the blue card outline: a default we never * claimed, which means the page was never fully ours to look at. * * accent-color is the one property that reaches inside those native * widgets. It is inherited, so setting it on body.v12 covers every * control on every step, including ones added later. The browser keeps * deciding the contrasting mark -- a white dot on our purple -- so the * selected state stays legible without us picking a second colour. * * Deliberately not set on :root: v1-v8 keep the system accent, so the * v10-to-v12 comparison still shows the difference. */ body.v12 { accent-color: var(--color-accent); } /* Focus ring on the purple header. * * The rule above paints every focus ring in --color-accent, which is the * right call everywhere the page is light -- and invisible on the header, * because the header IS that purple. The nav links were taking focus * correctly the whole time; there was simply nothing to see, so keyboard * users had no way to tell where they were. * * White, because it is the one colour guaranteed to read against the * brand purple, and it matches the nav text already sitting there. * * Specificity: (0,3,2) against the general rule's (0,2,1), so this wins * regardless of source order -- but it is placed after it as well, so * the cascade is obvious to whoever reads this next. */ body.v12 .site-header a:focus-visible, body.v12 .site-header .brand:focus-visible { outline: 2px solid #ffffff; outline-offset: 3px; border-radius: 4px; } /* Field labels read as the question, not as a caption. * * The base rule sets labels bold at 17px but colours them * --color-muted, so on a card whose only other text is a purple * underlined link, the eye lands on the escape hatch instead of the * field. "Will a product work with my Mac?" was winning against * "Product", which inverts what the step is asking for. * * Weight and size were already right; only the contrast was wrong, so * this changes the one thing at fault and nothing else. */ body.v12 label { color: var(--color-text); } /* A completed step is marked in brand purple, not green. * * The base rule tints a done card's border #cfe8da, which is the * success green from before this skin existed. The number badge was * repointed to purple when v9 was made; the border was missed, so the * finished card sat in a green frame directly above a neutral one and * the two read as unrelated components. * * A pale purple rather than plain --color-border: "done" is worth * showing, and the checkmark alone is a small target. This keeps the * signal and drops the stray hue. * * The customer-facing skin already neutralises this rule * (.skin-sonnet .sim-step.is-done), so only the demo skin was showing * green -- which is why it appeared in the screenshots and not on * support-flow. */ body.v12 .sim-step.is-done { border-color: #d9d0e8; } /* The macOS-version panel is an aside, not a warning. * * It was #fff8ec on #e6cf9f -- a caution tint from the palette this * skin replaced. Nothing has gone wrong when a customer sees it: it * explains which versions we test against, shows them how to check, * and offers two ways to carry on regardless. Painting guidance in * warning colours tells someone on an older macOS that they have hit * an error when they have hit a suggestion. * * Neutral grey, so it reads as a panel set apart from the step rather * than an alarm. The purple buttons inside it carry the brand; tinting * the block itself purple would read as "selected" and compete with * the card it sits in. */ body.v12 .sim-gate.is-stop { background: var(--color-bg-alt); border-color: var(--color-border); } /* The optional system-details disclosure. * * Styled as a control, not as a heading: it is something to click, and * it must not compete with the real questions around it. The marker * stays the browser's own triangle -- it is the one affordance every * platform already renders correctly, and replacing it buys nothing. */ body.v12 .sim-details { margin: 0 0 20px; border: 1px solid var(--color-border); border-radius: var(--radius-card, 10px); background: var(--color-bg-alt); padding: 0 16px; } body.v12 .sim-details > summary { cursor: pointer; padding: 12px 0; font-size: 15px; font-weight: 600; color: var(--color-accent); list-style-position: inside; } body.v12 .sim-details[open] > summary { border-bottom: 1px solid var(--color-border); margin-bottom: 16px; } body.v12 .sim-details > summary:focus-visible { outline: 2px solid var(--color-accent); outline-offset: 2px; border-radius: 4px; } /* The fields inside keep their own spacing; the wrapper only needs to stop the last one colliding with the border. */ body.v12 .sim-details > .field-grid:last-of-type { margin-bottom: 16px; } /* Programmatic focus targets carry no ring. * * assistant.js focuses the answer that just landed so the keyboard and * a screen reader both start from it. Chrome paints its own blue ring * on any focused element, and this one is a div -- outside the * button/link focus rules above -- so a system blue rectangle appeared * around the answer on a page with no other blue in it. * * Safe to remove here, and only here: tabindex="-1" means it is not a * tab stop, so no one navigates TO it. Focus lands on it once, to say * "the reply is here", and moves on to the citation at the next Tab. * Every element a customer can actually tab to keeps its ring. */ body.v12 .chat-turn[tabindex="-1"]:focus, body.v12 .sim-step[tabindex="-1"]:focus { outline: none; } /* The receipt and its status pill take the brand purple. * * Both were greens from the palette this skin replaced: #f1f9f4 on * #c4e3d2 for the receipt, #e8f5ed / #1d6b42 / #b8ddc7 for the pill. * Defensible in isolation -- green does mean "this went well" in a way * purple does not -- but on a page where every other affirmative mark * is purple, the one green block reads as belonging to a different * system rather than as a signal. * * The pill keeps a darker text colour than the border so the word * RECEIVED still carries at small size; a pill tinted to the accent * with accent-coloured text washes out. */ body.v12 .sim-receipt { background: var(--color-bg-alt); border-color: #ded4ec; } body.v12 .sim-status { background: #efe9f6; color: #4a3475; border-color: #d9cdeb; } /* Selected text takes a purple ground. * * The last system colour on the page: macOS draws the selection * highlight in the OS accent, so dragging across any text produced a * blue block -- and on someone else's Mac, a pink or graphite one. * * Text colour is set explicitly alongside the background. A tint that * leaves the foreground to the browser can land dark-on-dark once the * viewer's own accent is involved, and selected text that cannot be * read is worse than the system default it replaced. * * Unprefixed and ::-moz- are separate rules on purpose: grouping them * makes the whole selector list invalid in any engine that does not * recognise one of them, and the tint would silently not apply. */ body.v12 ::selection { background: #ded4ec; color: #2e2340; } body.v12 ::-moz-selection { background: #ded4ec; color: #2e2340; } /* The ceiling block sits under the per-run meter, quieter than it. */ body.v12 .sim-meter-cap { margin-top: 14px; border-top: 1px solid var(--color-border); padding-top: 14px; } /* The monitor page is read across, not read down. * * It inherits the customer flow's styling, where .sim-meter is capped * at 44rem -- correct for a form column somebody reads one line at a * time, wrong for a table of figures being scanned and compared. The * page sat in the left half of the screen with the right half empty. * * Scoped to .is-monitor so the customer flow keeps its narrow measure, * which is the whole point of that cap. */ body.is-monitor .sim-wrap { max-width: 1100px; margin: 0 auto; padding: 32px 24px 64px; } body.is-monitor .sim-meter { max-width: none; } /* Figures line up when the label column is fixed and the numbers are tabular -- otherwise "12.2%" and "4.9%" sit at different offsets and the eye cannot compare a column at a glance. */ body.is-monitor .sim-meter-row .k { flex: 1 1 auto; } body.is-monitor .sim-meter-row .v { flex: 0 0 7rem; text-align: right; font-variant-numeric: tabular-nums; } body.is-monitor .sim-meter-row .n { flex: 0 0 22rem; text-align: right; } /* The live OS/version mismatch hint. Amber, not red: nothing is broken and nothing is blocked -- we are telling them something looks off while they can still see the field they typed it in. */ body.v12 .os-mismatch { color: #8a6100; font-weight: 600; } /* Inline email warning. Amber like the OS/version hint: it is telling them something looks wrong while they can still see the field, not reporting a failure after the fact. */ body.v12 .email-warn { color: #8a6100; font-weight: 600; } /* --------------------------------------------------------------------- * "I'm not sure, or I'm running something else" sits under Continue. * * It used to be its own
, which stacked it naturally. It had to * move INSIDE the OS form so a typed answer travels with the click -- * as its own form it carried no OS field at all, and the answer never * reached the server. See the note beside the button in simulate-v12.php. * * Sharing a form put it inline beside the button. The behaviour needed * the move; the layout did not, so put the line break back rather than * unpick the fix. * ------------------------------------------------------------------ */ body.v12 .btn-hero + .sim-link-btn { display: block; margin-top: 0.75rem; } /* --------------------------------------------------------------------- * Finished steps on the rail are buttons that go back. * * They have to look exactly like the labels they replace -- the rail is a * progress indicator first, and a row where one item suddenly looks like a * control reads as broken rather than helpful. Underline on hover and a * pointer are enough of a signal; the title attribute says the rest. * ------------------------------------------------------------------ */ body.v12 .sim-rail-back { display: inline; margin: 0; padding: 0; } body.v12 .sim-rail-btn { font: inherit; color: inherit; background: none; border: 0; padding: 0; cursor: pointer; } body.v12 .sim-rail-btn:hover, body.v12 .sim-rail-btn:focus-visible { text-decoration: underline; } /* --------------------------------------------------------------------- * Back on the left, Start over on the right. * * .sim-restart sets text-align:right on its own, which is why it ends up * where it does; the row below overrides that so the pair sits at opposite * ends of the same line rather than stacking. * ------------------------------------------------------------------ */ body.v12 .sim-nav-foot { display: flex; justify-content: space-between; align-items: baseline; gap: 1rem; margin-top: 8px; } body.v12 .sim-nav-foot .sim-restart, body.v12 .sim-nav-foot .sim-back { margin: 0; text-align: left; } /* --------------------------------------------------------------------- * The catch-all rows sit in their own strip under the scrolling list. * * Not position:sticky -- that worked on one machine and not on another, and * "the row you need when nothing else fits" should not depend on a layout * trick. typeahead.js puts them in a separate