@kenlo/sds-design-system 0.9.9 → 1.0.2

package/README.md

@@ -37,6 +37,12 @@ import "@kenlo/sds-design-system/components/Button/Button.css";
 As tags não precisam de import. O `marko.json` na raiz do pacote é o catálogo: o compilador
 do Marko acha `<sds-button>` sozinho.
 
+**A tipografia vem junto no passo 1, e não há passo para esquecer.** A Manrope — a fonte
+padrão — viaja dentro do pacote, e as regras `@font-face` estão no próprio `tokens.css`,
+que é o arquivo que declara qual fonte usar. Nada é pedido ao Google enquanto a página
+carrega: o visitante do site é cliente da imobiliária, e o IP dele não sai daqui. As outras
+cinco opções de `data-font` estão descritas em **Tema**, logo abaixo.
+
 ```marko
 <sds-button variant="primary" onClick=salvar>Salvar</sds-button>
 
@@ -61,6 +67,32 @@ Quatro atributos no `<html>` decidem a aparência inteira. Um atributo no valor
 | `data-radius` | `flat`, `soft`, `medium`, `rounded` | `soft` |
 | `data-font` | `manrope`, `inter`, `helvetica`, `source-sans`, `nunito`, `montserrat` | `manrope` |
 
+**De onde cada fonte vem**, porque isso decide o que o visitante baixa:
+
+| | onde mora | o que o visitante baixa |
+|---|---|---|
+| `manrope` (padrão) | dentro do pacote | ~24 KB — só o subset do idioma dele |
+| `helvetica` | na máquina do visitante | nada |
+| as outras quatro | bucket da Kenlo, publicado pelo KDLS | só o subset do idioma, e só se você escolher |
+
+A Manrope é embarcada de propósito: a fonte padrão não pode depender de rede nenhuma além
+da do próprio app — se o bucket cair, nenhum produto perde a tipografia junto. As opcionais
+ficam fora do pacote pelo motivo oposto: os bytes delas não devem pesar em quem nunca
+escolhe nenhuma.
+
+> **As quatro opcionais carregam desde 21/09**, quando o CORS entrou no bucket. Conferido
+> aqui com `npm run check:fonts`: 24 de 24 utilizáveis, e num navegador limpo as quatro
+> famílias renderizam.
+>
+> **Com uma ressalva que vale saber.** Entre a publicação do bucket e o conserto do CORS,
+> houve uma janela em que os arquivos respondiam sem o cabeçalho. Um navegador que passou
+> por uma dessas URLs nessa janela **guardou a resposta ruim** — e elas são servidas
+> `immutable`, com um ano de cache, então ele não revalida. Essa pessoa continua vendo o
+> fallback, e consertar o servidor não a alcança: só um nome de arquivo novo alcança.
+>
+> A `manrope` e a `helvetica` nunca dependeram disso — e essa é exatamente a razão de a
+> padrão vir embarcada.
+
 Há duas portas para escrevê-los, e a diferença importa:
 
 ```js
@@ -80,20 +112,39 @@ visitante. A metade servidor existe para evitar isso.
 
 ## Cor do cliente
 
-Cada site tem a sua cor, e ela entra em tempo de execução:
+Os dez esquemas da tabela acima são os prontos. Um site com marca própria usa as **suas**
+cores, e uma marca tem duas: um **destaque** e uma **complementar**. As duas entram em tempo
+de execução, e há três jeitos de usá-las:
+
+| | destaque | complementar |
+|---|---|---|
+| **1 sólida** | preenche o slot primário | não é aplicada |
+| **2 sólidas** | preenche o slot primário | pinta o botão `ghost`, e nada mais |
+| **gradiente** | primeiro stop | último stop |
 
 ```js
-import { applyCustomColor, applyCustomGradient, clearCustomScheme }
+import { applyCustomColor, applyComplementColor, applyCustomGradient,
+  clearComplementColor, clearCustomScheme }
   from "@kenlo/sds-design-system/foundations/custom-scheme.js";
 
-applyCustomColor("#2E7D32");                   // nove tons sólidos
-applyCustomGradient(["#77A6E0", "#BF71E5"]);   // nove gradientes
-clearCustomScheme();
+applyCustomColor("#2E7D32");                   // nove tons sólidos no slot primário
+applyComplementColor("#BF71E5");               // nove tons em --color-complement-10..90
+applyCustomGradient(["#2E7D32", "#BF71E5"]);   // nove gradientes
+clearComplementColor();                        // derruba só a complementar
+clearCustomScheme();                           // derruba as duas
 ```
 
-As duas preenchem `--color-primary-10..90`, os companheiros `-solid` e o
+O destaque preenche `--color-primary-10..90`, os companheiros `-solid` e o
 `--color-on-primary` — este último escolhido por luminância relativa (WCAG), para o texto
-sobre a cor ficar legível seja ela qual for. Uma chamada substitui a outra; nunca empilham.
+sobre a cor ficar legível seja ela qual for.
+
+**A complementar pinta um controle só: o botão `ghost`**, que é o contornado. É decisão, não
+limitação — uma segunda cor solta no sistema é como o sistema deixa de ter uma cor.
+
+E ela é uma **camada**, não um terceiro modo: mora no seu próprio `<style>`, então trocar o
+destaque não a derruba junto. Enquanto você não definir nenhuma, o ghost fica exatamente
+como sempre foi — a leitura é `var(--color-complement-50, var(--color-primary-50-solid))`,
+o fallback responde, e nada muda para quem nunca usar isso.
 
 ---
 

package/components/Avatar/Avatar.css

@@ -108,3 +108,25 @@
   object-fit: cover;
   border-radius: inherit;
 }
+
+/* ── The site's gradient, on the stroke ────────────────────────────────────────
+
+   `border-color` rejects a gradient, so a stroke normally reads the `-solid` companion —
+   the gradient's first stop, flat. These rules paint it properly instead: the gradient on
+   `border-box`, the surface colour on `padding-box`, over a transparent border. Only the
+   border's own 2px show the gradient, and `border-radius` still works, which is what
+   `border-image` would cost.
+
+   `[data-primary-gradient]` is written by `applyCustomGradient` and removed by
+   `applyCustomColor` — a stylesheet cannot ask what a custom property contains, so the
+   code that fills the slot says so. KDLS wrote the same rules under
+   `[data-color-scheme="lya"]`, its own brand gradient; SDS deleted every `lya` block with
+   the brand and these went with them. Keyed on the marker they serve any site's gradient.
+   ─────────────────────────────────────────────────────────────────────────── */
+
+[data-primary-gradient] .sds-avatar--clickable:hover {
+  background:
+    linear-gradient(var(--component-bg-color), var(--component-bg-color)) padding-box,
+    var(--color-primary-50) border-box;
+  border-color: transparent;
+}

package/components/Button/Button.css

@@ -94,15 +94,32 @@
    VARIANT: primary  (filled)
    Uses --color-primary-* → follows data-color-scheme
 ────────────────────────────────────────────── */
+/* `background-origin` travels with every one of these, and it has to.
+
+   `.sds-button` carries `border: 2px solid transparent`, so a primary button comes out the
+   same size as a ghost one, which has a visible border. With a solid colour that border is
+   invisible: the colour paints the whole border box. With a GRADIENT — and the primary slot
+   is allowed to hold one — the background is sized to the box INSIDE the border, painted
+   over the border anyway, and the 2px strip is filled with the next tile: the left edge
+   shows the colour from the far right, all the way round. Rafael saw it as a strange stroke
+   on the picker's "Aplicar".
+
+   Declaring it once on `.sds-button` does not work, and that is the trap: the `background`
+   shorthand RESETS `background-origin` to `padding-box`, and the shorthand is what every
+   rule below uses — because the slot may hold a colour or a gradient and only the shorthand
+   takes both. So it is repeated wherever the shorthand appears. */
 .sds-button--primary {
   background: var(--color-primary-50);
+  background-origin: border-box;
   color: var(--color-on-primary);
 }
 .sds-button--primary:hover:not(:disabled):not(.sds-button--loading) {
   background: var(--color-primary-60);
+  background-origin: border-box;
 }
 .sds-button--primary:active:not(:disabled):not(.sds-button--loading) {
   background: var(--color-primary-70);
+  background-origin: border-box;
 }
 .sds-button--primary:focus-visible {
   box-shadow: var(--focus-ring);
@@ -110,20 +127,37 @@
 /* ──────────────────────────────────────────────
    VARIANT: ghost  (outlined / ghost)
 ────────────────────────────────────────────── */
+/* The outlined control is the one thing the site's COMPLEMENTARY colour paints.
+
+   A brand has a highlight and a complement. The highlight fills the primary slot and
+   paints everything; the complement paints this. The product that consumes SDS already
+   models both, and until now the design system could only receive the first.
+
+   Every declaration reads the complement THROUGH a fallback to the primary tone it used
+   to read, and to the same tone — never a neighbouring one. So a consumer that sets no
+   complement gets this button exactly as it has always been, and clearing the complement
+   reverts it with nothing that has to know how to undo anything.
+
+   The primary fallback keeps its `-solid` companion because the primary slot may hold a
+   gradient and `color` and `border-color` reject one. The complement never needs the
+   twin: that slot is solid by definition, and in gradient mode it is not used at all.
+   See foundations/custom-scheme.js, applyComplementColor. */
 .sds-button--ghost {
   background-color: transparent;
-  border-color: var(--color-primary-50-solid);
-  color: var(--color-primary-50-solid);
+  border-color: var(--color-complement-50, var(--color-primary-50-solid));
+  color: var(--color-complement-50, var(--color-primary-50-solid));
 }
 .sds-button--ghost:hover:not(:disabled):not(.sds-button--loading) {
-  background: var(--color-primary-10);
-  border-color: var(--color-primary-60-solid);
-  color: var(--color-primary-60-solid);
+  background: var(--color-complement-10, var(--color-primary-10));
+  background-origin: border-box;
+  border-color: var(--color-complement-60, var(--color-primary-60-solid));
+  color: var(--color-complement-60, var(--color-primary-60-solid));
 }
 .sds-button--ghost:active:not(:disabled):not(.sds-button--loading) {
-  background: var(--color-primary-20);
-  border-color: var(--color-primary-70-solid);
-  color: var(--color-primary-70-solid);
+  background: var(--color-complement-20, var(--color-primary-20));
+  background-origin: border-box;
+  border-color: var(--color-complement-70, var(--color-primary-70-solid));
+  color: var(--color-complement-70, var(--color-primary-70-solid));
 }
 .sds-button--ghost:focus-visible {
   box-shadow: var(--focus-ring);
@@ -164,14 +198,17 @@
   font-weight: var(--font-weight-medium);
   line-height: var(--lh-body-md);
   background: var(--color-primary-50);
+  background-origin: border-box;
   color: var(--color-on-primary);
   border: 1px solid var(--color-primary-50-solid);
 }
 .sds-button--pillFilled:hover:not(:disabled):not(.sds-button--loading) {
   background: var(--color-primary-60);
+  background-origin: border-box;
 }
 .sds-button--pillFilled:active:not(:disabled):not(.sds-button--loading) {
   background: var(--color-primary-70);
+  background-origin: border-box;
 }
 .sds-button--pillFilled:focus-visible {
   box-shadow: var(--focus-ring);
@@ -338,3 +375,53 @@
 
 [data-radius="rounded"] .sds-button--md { border-radius: var(--radius-full); }
 [data-radius="rounded"] .sds-button--lg { border-radius: var(--radius-full); }
+
+/* ── The site's gradient, on the stroke ────────────────────────────────────────
+
+   `border-color` rejects a gradient, so a stroke normally reads the `-solid` companion —
+   the gradient's first stop, flat. These rules paint it properly instead: the gradient on
+   `border-box`, the surface colour on `padding-box`, over a transparent border. Only the
+   border's own 2px show the gradient, and `border-radius` still works, which is what
+   `border-image` would cost.
+
+   `[data-primary-gradient]` is written by `applyCustomGradient` and removed by
+   `applyCustomColor` — a stylesheet cannot ask what a custom property contains, so the
+   code that fills the slot says so. KDLS wrote the same rules under
+   `[data-color-scheme="lya"]`, its own brand gradient; SDS deleted every `lya` block with
+   the brand and these went with them. Keyed on the marker they serve any site's gradient.
+   ─────────────────────────────────────────────────────────────────────────── */
+
+[data-primary-gradient] .sds-button--ghost {
+  background:
+    linear-gradient(var(--component-bg-color), var(--component-bg-color)) padding-box,
+    var(--color-primary-50) border-box;
+  border-color: transparent;
+}
+
+[data-primary-gradient] .sds-button--ghost:hover:not(:disabled):not(.sds-button--loading) {
+  background:
+    var(--color-primary-10) padding-box,
+    var(--color-primary-50) border-box;
+  border-color: transparent;
+}
+
+[data-primary-gradient] .sds-button--ghost:active:not(:disabled):not(.sds-button--loading) {
+  background:
+    var(--color-primary-20) padding-box,
+    var(--color-primary-50) border-box;
+  border-color: transparent;
+}
+
+[data-primary-gradient] .sds-button--ghost:focus-visible {
+  background:
+    linear-gradient(var(--component-bg-color), var(--component-bg-color)) padding-box,
+    var(--color-primary-50) border-box;
+  border-color: transparent;
+}
+
+[data-primary-gradient] .sds-button--pill:hover:not(:disabled):not(.sds-button--loading) {
+  background:
+    linear-gradient(var(--component-bg-color), var(--component-bg-color)) padding-box,
+    var(--color-primary-50) border-box;
+  border-color: transparent;
+}

package/components/Card/Card.css

@@ -33,16 +33,26 @@
 .sds-card--hoverable:focus-visible {
   box-shadow: var(--focus-ring);
 }
-/* ── Cover — media/image slot, no padding, bleeds to the card's own radius.
-   Default: top, full width, aspect-ratio fixed at 16/9 (overridden by coverHeight).
-   horizontal: left column, fixed width, fills the row's height — aspect-ratio has
-   no effect there since both dimensions are already explicit. ── */
+/* Default: top, full width, no proportion — the cover is as tall as its picture unless
+   the caller says otherwise, with coverHeight (pixels) or coverRatio (a proportion).
+
+   This comment used to claim a 16/9 default. It was never true: the class below existed
+   and the template never emitted it. Making it the default now would resize every card
+   already published, so the ratio is opt-in and the comment is what changed.
+
+   horizontal: left column. A ratio there also releases the fixed width, otherwise both
+   dimensions are explicit and the proportion has nothing to do. ── */
 .sds-card__cover {
   position: relative;
   line-height: 0;
 }
-.sds-card__cover--16-9 {
-  aspect-ratio: 16 / 9;
+.sds-card__cover--16-9 { aspect-ratio: 16 / 9; }
+.sds-card__cover--4-3  { aspect-ratio: 4 / 3; }
+.sds-card__cover--3-2  { aspect-ratio: 3 / 2; }
+.sds-card__cover--1-1  { aspect-ratio: 1 / 1; }
+
+.sds-card--horizontal .sds-card__cover[class*="sds-card__cover--"] {
+  width: auto;
 }
 .sds-card__cover img {
   display: block;

package/components/Card/card-variants.js

@@ -22,3 +22,21 @@ export const assertCardSize = (v) => assertOneOf('size', v, CARD_SIZES);
 // `align` is optional in both places that take it, so undefined passes through.
 export const assertAlign = (v) => (v === undefined ? v : assertOneOf('align', v, ALIGNMENTS));
 export const assertColumns = (v) => assertOneOf('columns', v, INFO_ROW_COLUMNS);
+
+/**
+ * The cover's proportion.
+ *
+ * Card.css has claimed since it was written that the cover defaults to 16/9, and the
+ * class that would do it — .sds-card__cover--16-9 — was never emitted by the template.
+ * This is that rule, made real and made opt-in: defaulting it now would change the shape
+ * of every card already using this component.
+ *
+ * Asked for by the Site layer, which needs 4/3 on a vertical property card and 3/2 on a
+ * horizontal one (Rafael, 2026-09-17).
+ */
+export const COVER_RATIOS = ['16/9', '4/3', '3/2', '1/1'];
+
+export const assertCoverRatio = (v) => (v === undefined ? v : assertOneOf('coverRatio', v, COVER_RATIOS));
+
+// '4/3' -> '4-3', which is what the class name uses.
+export const coverRatioSlug = (v) => v.replace('/', '-');

package/components/Card/card.marko

@@ -11,13 +11,14 @@ nothing. A property listing renders twenty of these.
 It is a <button> when it has a click handler, rather than a div with a handler and no
 keyboard path. -->
 
-import { assertCardSize } from "./card-variants.js";
+import { assertCardSize, assertCoverRatio, coverRatioSlug } from "./card-variants.js";
 
 $ {
   const {
     cover,
     coverWidth,
     coverHeight,
+    coverRatio,
     coverBadges,
     horizontal = false,
     size = "md",
@@ -32,6 +33,7 @@ $ {
   } = input;
 
   assertCardSize(size);
+  assertCoverRatio(coverRatio);
 
   const renderable = (value) => (value && value.renderBody) || value;
   const interactive = Boolean(onClick);
@@ -62,6 +64,14 @@ $ {
     horizontal && coverWidth ? `width: ${coverWidth}px` : "",
     !horizontal && coverHeight ? `height: ${coverHeight}px` : "",
   ].filter(Boolean).join("; ") || null;
+
+  // An explicit pixel dimension is the caller being specific; the ratio is the shape's
+  // default. Whichever dimension this orientation can honour, if given, wins.
+  const pixelWins = horizontal ? Boolean(coverWidth) : Boolean(coverHeight);
+  const coverClass = [
+    "sds-card__cover",
+    coverRatio && !pixelWins ? `sds-card__cover--${coverRatioSlug(coverRatio)}` : "",
+  ].filter(Boolean).join(" ");
 }
 
 <macro|{ }| name="inner">
@@ -69,7 +79,7 @@ $ {
   // skeleton block, promising a picture that was never going to arrive — and once loaded
   // the card jumped as that block disappeared. KDLS gates on the cover alone.
   <if(cover)>
-    <div class="sds-card__cover" style=coverStyle>
+    <div class=coverClass style=coverStyle>
       <if(loading)>
         <sds-skeleton-image fill/>
       </if>

package/components/Checkbox/Checkbox.css

@@ -247,3 +247,59 @@
 /* Indeterminate is drawn from a class rather than the :indeterminate pseudo-class.
    That property can only be set from JavaScript, and this component does not hydrate —
    with appearance:none the browser draws nothing here anyway, so the class is enough. */
+
+/* ── The site's gradient, on the stroke ────────────────────────────────────────
+
+   `border-color` rejects a gradient, so a stroke normally reads the `-solid` companion —
+   the gradient's first stop, flat. These rules paint it properly instead: the gradient on
+   `border-box`, the surface colour on `padding-box`, over a transparent border. Only the
+   border's own 2px show the gradient, and `border-radius` still works, which is what
+   `border-image` would cost.
+
+   `[data-primary-gradient]` is written by `applyCustomGradient` and removed by
+   `applyCustomColor` — a stylesheet cannot ask what a custom property contains, so the
+   code that fills the slot says so. KDLS wrote the same rules under
+   `[data-color-scheme="lya"]`, its own brand gradient; SDS deleted every `lya` block with
+   the brand and these went with them. Keyed on the marker they serve any site's gradient.
+   ─────────────────────────────────────────────────────────────────────────── */
+
+[data-primary-gradient] .sds-checkbox:hover:not(.sds-checkbox--disabled):not(.sds-checkbox--checked):not(.sds-checkbox--indeterminate) .sds-checkbox__box,
+[data-primary-gradient] .sds-checkbox:active:not(.sds-checkbox--disabled):not(.sds-checkbox--checked):not(.sds-checkbox--indeterminate) .sds-checkbox__box {
+  background:
+    linear-gradient(var(--component-bg-color), var(--component-bg-color)) padding-box,
+    var(--color-primary-50) border-box;
+  border-color: transparent;
+}
+
+/* ── And when the gradient FILLS the box, it has no border to fight ────────────
+
+   A checked box paints the slot as its fill and the `-solid` companion as its border. With
+   a solid colour those are the same colour and the border cannot be seen. With a gradient
+   they are not: the fill runs from one stop to the other while the 2px ring stays flat at
+   the first, so a 20px box gets a hard edge of the wrong colour all the way round — and
+   the fill, sized to the box inside that ring and tiled into it, shows the far end there
+   as well.
+
+   `border: none` is the answer, and it is KDLS's: under a gradient the fill IS the whole
+   box, so there is nothing left to ring.
+
+   The touched state brightens rather than stepping to tone 60. Stepping a gradient's tone
+   moves every stop at once, which reads as a different colour rather than as the same
+   control being pressed. ─────────────────────────────────────────────────────── */
+[data-primary-gradient] .sds-checkbox--checked .sds-checkbox__box,
+[data-primary-gradient] .sds-checkbox--indeterminate .sds-checkbox__box,
+[data-primary-gradient] .sds-checkbox__input:checked ~ .sds-checkbox__box {
+  background: var(--color-primary-50);
+  border: none;
+}
+
+[data-primary-gradient] .sds-checkbox--checked:hover:not(.sds-checkbox--disabled) .sds-checkbox__box,
+[data-primary-gradient] .sds-checkbox--checked:active:not(.sds-checkbox--disabled) .sds-checkbox__box,
+[data-primary-gradient] .sds-checkbox--indeterminate:hover:not(.sds-checkbox--disabled) .sds-checkbox__box,
+[data-primary-gradient] .sds-checkbox--indeterminate:active:not(.sds-checkbox--disabled) .sds-checkbox__box,
+[data-primary-gradient] .sds-checkbox:hover:not(.sds-checkbox--disabled) .sds-checkbox__input:checked ~ .sds-checkbox__box,
+[data-primary-gradient] .sds-checkbox:active:not(.sds-checkbox--disabled) .sds-checkbox__input:checked ~ .sds-checkbox__box {
+  background: var(--color-primary-50);
+  border: none;
+  filter: brightness(1.1);
+}

package/components/ColorPicker/ColorPicker.css

@@ -218,8 +218,8 @@ button.sds-colorpicker__trigger:disabled {
 /* The canvas and the sliders take focus now, so they have to show it. */
 .sds-colorpicker__canvas:focus-visible,
 .sds-colorpicker__slider:focus-visible {
-  outline: var(--focus-ring-width) solid var(--focus-stroke-color);
-  outline-offset: 2px;
+  outline: var(--focus-ring-outline);
+  outline-offset: var(--focus-ring-outline-offset);
 }
 
 /* ── Overlay ──
@@ -251,3 +251,26 @@ button.sds-colorpicker__trigger:disabled {
 .sds-colorpicker--headless {
   display: contents;
 }
+
+/* ── The site's gradient, on the stroke ────────────────────────────────────────
+
+   `border-color` rejects a gradient, so a stroke normally reads the `-solid` companion —
+   the gradient's first stop, flat. These rules paint it properly instead: the gradient on
+   `border-box`, the surface colour on `padding-box`, over a transparent border. Only the
+   border's own 2px show the gradient, and `border-radius` still works, which is what
+   `border-image` would cost.
+
+   `[data-primary-gradient]` is written by `applyCustomGradient` and removed by
+   `applyCustomColor` — a stylesheet cannot ask what a custom property contains, so the
+   code that fills the slot says so. KDLS wrote the same rules under
+   `[data-color-scheme="lya"]`, its own brand gradient; SDS deleted every `lya` block with
+   the brand and these went with them. Keyed on the marker they serve any site's gradient.
+   ─────────────────────────────────────────────────────────────────────────── */
+
+[data-primary-gradient] .sds-colorpicker__trigger:hover:not(.sds-colorpicker__trigger--disabled),
+[data-primary-gradient] .sds-colorpicker__trigger--open {
+  background:
+    linear-gradient(var(--component-bg-color), var(--component-bg-color)) padding-box,
+    var(--color-primary-50) border-box;
+  border-color: transparent;
+}

package/components/ColorPicker/color-picker.marko

@@ -65,7 +65,11 @@ class {
     this.state.sat = s;
     this.state.bri = v;
     this.state.opacity = startingAlpha(input.value);
-    this.syncHexInput();
+    // The argument, not `this.input`. Marko has not assigned it yet at this point — the
+    // same reason onCreate takes one, five lines above. Falling through to `this.input`
+    // read `disableAlpha` of undefined, and the throw escaped into the update: the page
+    // stopped hydrating, the colour stayed applied and the picker stayed open.
+    this.syncHexInput(input);
   }
 
   get currentHex() {
@@ -222,12 +226,29 @@ class {
     }
   }
 
+  /**
+   * Reports the colour and closes — and does everything it needs from `this.input` BEFORE
+   * either, because either can take this component away.
+   *
+   * A caller closes on the report, and closing this picker unmounts it. So the line after a
+   * call out can be running on a component that no longer exists, where `this.input` is
+   * undefined. It threw exactly there; the error escaped into Marko's update, and from that
+   * point nothing on the page hydrated again — the colour had been applied and the app was
+   * dead, with a theme pill still showing the old value beside a token that had changed.
+   *
+   * So: read first, then close, then report through the captured reference. Closing goes
+   * through `setOpen` like every other way out of this panel — writing `state.open`
+   * directly closed it only when nobody owned `open`, which left a controlled caller told
+   * about the colour and never told to close.
+   */
   apply() {
-    const hex = this.input.disableAlpha
+    const { onChange, disableAlpha } = this.input;
+    const hex = disableAlpha
       ? this.currentHex
       : this.currentHex + alphaToHex(this.state.opacity);
-    this.input.onChange?.(hex);
-    this.state.open = false;
+
+    this.setOpen(false);
+    onChange?.(hex);
   }
 }
 

package/components/DatePicker/DatePicker.css

@@ -427,3 +427,25 @@
 [data-radius="rounded"] .sds-datepicker__day { border-radius: var(--radius-full); }
 [data-radius="rounded"] .sds-datepicker__month-item { border-radius: var(--radius-full); }
 [data-radius="rounded"] .sds-datepicker__year-item { border-radius: var(--radius-full); }
+
+/* ── The site's gradient, on the stroke ────────────────────────────────────────
+
+   `border-color` rejects a gradient, so a stroke normally reads the `-solid` companion —
+   the gradient's first stop, flat. These rules paint it properly instead: the gradient on
+   `border-box`, the surface colour on `padding-box`, over a transparent border. Only the
+   border's own 2px show the gradient, and `border-radius` still works, which is what
+   `border-image` would cost.
+
+   `[data-primary-gradient]` is written by `applyCustomGradient` and removed by
+   `applyCustomColor` — a stylesheet cannot ask what a custom property contains, so the
+   code that fills the slot says so. KDLS wrote the same rules under
+   `[data-color-scheme="lya"]`, its own brand gradient; SDS deleted every `lya` block with
+   the brand and these went with them. Keyed on the marker they serve any site's gradient.
+   ─────────────────────────────────────────────────────────────────────────── */
+
+[data-primary-gradient] .sds-datepicker__day--today {
+  background:
+    linear-gradient(var(--component-bg-color), var(--component-bg-color)) padding-box,
+    var(--color-primary-50) border-box;
+  border-color: transparent;
+}

package/components/Floating/focus-when-ready.js

@@ -0,0 +1,59 @@
+/**
+ * Put the caret inside a floating panel, once the panel can actually take it.
+ *
+ * `sds-floating` renders its panel `visibility: hidden` until it has measured and placed
+ * it — see Floating.css: a panel nobody has measured is 0×0, 0×0 fits anywhere, and a flip
+ * decided on that basis puts the panel on the wrong side in front of the reader. The
+ * reveal happens one frame later, in `afterOpen`.
+ *
+ * A component that opens a panel and wants the caret inside it runs on the render where
+ * the panel exists and is still hidden. `focus()` there is a no-op, and a silent one:
+ * nothing throws, nothing returns false, `document.activeElement` simply does not move.
+ * Measured in Chromium on 2026-09-17, sampling every frame after a click on an
+ * sds-select's trigger:
+ *
+ *     frame 1 — panel present, visibility hidden, not positioned   ← the focus call
+ *     frame 2 — visibility visible, positioned                     ← nothing asks again
+ *
+ * So: ask, check whether the caret arrived, and ask again on the next frame if it did not.
+ * Bounded, because a panel that never becomes visible is a panel that was closed, and a
+ * retry with no end is worse than a caret that did not move. In the measurement above it
+ * took three tries.
+ *
+ * The target arrives as a LOOKUP rather than an element. Marko replaces the node on
+ * re-render, and a reference held across one points at something detached — focus() on it
+ * throws nothing and moves nothing, which is the same silent failure by another route.
+ *
+ * jsdom has no layout and so honours focus() on a hidden element. This rule therefore
+ * cannot be caught by rendering a component in a test; it is tested directly, with the
+ * first attempt made to fail the way the browser fails it.
+ */
+
+/** How many times to ask in total, including the first. Three sufficed when measured. */
+const DEFAULT_ATTEMPTS = 5;
+
+/**
+ * @param {() => (HTMLElement|null|undefined)} lookup  finds the element to focus, now
+ * @param {object} [options]
+ * @param {number} [options.attempts]  total tries, including the first
+ * @param {(cb: () => void) => void} [options.schedule]  when to try again; a frame by
+ *   default, and injectable so the rule can be stepped by hand in a test
+ */
+export function focusWhenReady(lookup, { attempts = DEFAULT_ATTEMPTS, schedule } = {}) {
+  const later = schedule
+    ?? ((callback) => (typeof requestAnimationFrame === 'function'
+      ? requestAnimationFrame(() => callback())
+      : setTimeout(callback, 16)));
+
+  const tryOnce = (left) => {
+    const target = lookup();
+    if (!target) return;
+
+    target.focus({ preventScroll: true });
+    if (document.activeElement === target || left <= 1) return;
+
+    later(() => tryOnce(left - 1));
+  };
+
+  tryOnce(attempts);
+}

package/components/Incrementer/Incrementer.css

@@ -92,3 +92,25 @@
   border-color: var(--border-interactive-color);
   color: var(--color-neutral-40);
 }
+
+/* ── The site's gradient, on the stroke ────────────────────────────────────────
+
+   `border-color` rejects a gradient, so a stroke normally reads the `-solid` companion —
+   the gradient's first stop, flat. These rules paint it properly instead: the gradient on
+   `border-box`, the surface colour on `padding-box`, over a transparent border. Only the
+   border's own 2px show the gradient, and `border-radius` still works, which is what
+   `border-image` would cost.
+
+   `[data-primary-gradient]` is written by `applyCustomGradient` and removed by
+   `applyCustomColor` — a stylesheet cannot ask what a custom property contains, so the
+   code that fills the slot says so. KDLS wrote the same rules under
+   `[data-color-scheme="lya"]`, its own brand gradient; SDS deleted every `lya` block with
+   the brand and these went with them. Keyed on the marker they serve any site's gradient.
+   ─────────────────────────────────────────────────────────────────────────── */
+
+[data-primary-gradient] .sds-incrementer:hover:not(.sds-incrementer--disabled) {
+  background:
+    linear-gradient(var(--component-bg-color), var(--component-bg-color)) padding-box,
+    var(--color-primary-50) border-box;
+  border-color: transparent;
+}