svelte-kit-vice/docs/audit/theming/date-picker.md

date-picker — alcance de tema: análisis y propuesta

Generado por node --import tsx/esm scripts/theming-census.ts --report. Lo medido y la propuesta se regeneran; el Veredicto (§5) se conserva. Vista de conjunto: README · método y protocolo: PLAN-theming.md §1, §2, §7.

• Medido: 2026-08-20 · Alcance: 0% — 0 de 2 knobs por token público
• Knobs de apariencia: 2 — público 0 · privado 0 · global 0 · literal 2 · sistema 0 (fuera del ratio)
• Contrato hoy (lib/recipes/base.ts): sin entrada en base.ts
• Eje size: no · ficheros: date-picker.css

1. Knobs fuera de alcance

1.1 Directo a primitivo global (0)

Ninguno.

1.2 A través de un privado (0)

Ninguno.

1.3 Literales (2)

#	fichero:línea	selector	propiedad	valor
1	date-picker.css:47	[data-popover-content]:has( > [data-date-picker-calendar], > [data-month-grid], > [data-year-grid] )	inline-size	max-content
2	date-picker.css:48	[data-popover-content]:has( > [data-date-picker-calendar], > [data-month-grid], > [data-year-grid] )	min-inline-size	max-content

2. Sistema transversal (0) — informativo, fuera del ratio

Un tema los alcanza a nivel de sistema, por diseño (recipe-contract §2).

Ninguno.

3. Privados de la receta — ¿de dónde sale su valor?

La receta no declara privados propios en su CSS.

4. Propuesta de corrección

• Consume la capa compartida picker-shell. Un eje que la capa posee se consume como var(--_x, var(--x)); el consumidor no acuña --date-picker-{eje} para él — sería un vocabulario paralelo (README de eidos/components, «Capas compartidas» regla 2).

4.1 Tokens a declarar en lib/recipes/base.ts (1)

Valor verbatim del CSS de hoy: el default no se mueve, sólo cambia quién puede moverlo. Nombres derivados de recipe-contract §1 (ejes lógicos, talla al final) y theming §6.7 (slots de color, modificador delante). Un token con DOS valores distintos es una colisión de nombre: son dos knobs, o el nombre no distingue lo que debería — se marca ⚠.

token (--date-picker-…)	scope TSC	valor propuesto	usos
calendar-width	root	max-content	2

4.4 Lo que hay que comprobar a mano (PLAN-theming §1.3 · §7.4)

• Privado que no deriva de un público — §3 lo marca; el privado debe leer el público o desaparecer.
• Velo o acento en el nodo equivocado (archetype: 'item' en un envoltorio, un background en shorthand que mata la capa de estado) — se mide desde el píxel hacia arriba.
• Doble animación al mover un sello a una superficie con animación propia — registro de animationstart/animationend.
• Diff de computed = 0 en reposo · hover · abierto · disabled · foco, por talla, antes y después.
• Centinela por token nuevo: valor imposible en el root → el nodo lo sigue. Si no, el token miente.

5. Veredicto

Medido 2026-08-22. Su 0 % es DEFINITIVO, no deuda — y su propia cabecera lo dice: «This recipe must NOT re-declare any of those… it owns ONLY the popover / calendar layout».

DatePicker es un DateField compuesto que además ancla el popover del calendario. Su raíz lleva data-field + data-date-field, así que todo su cromo de campo —la pila etiqueta/control/ayuda, los tokens de control por talla, variante, invalid, disabled y el gap de segmentos— viene de field.css y date-field.css. Re-declararlo sería aliasear la base de Field.

Sus dos knobs contados son inline-size: max-content y min-inline-size: max-content sobre el popover que hospeda el calendario, y su comentario explica por qué: el panel debe crecer hasta su contenido para que la fila del pie (Clear / Cancel / Save + huecos) no desborde y saque una barra horizontal. Es una CORRECCIÓN DE COMPOSICIÓN con un solo valor correcto — max-content —, no una preferencia: cualquier otro valor reintroduce el desbordamiento que la regla existe para evitar. Lo mismo vale para los resets del calendario embebido (padding, borde, fondo y sombra a cero), que apagan el cromo duplicado del panel que ya lo envuelve.

No hay contrato que escribir. Lo tematizable de esta pantalla vive en field, en calendar (vía la capa calendar-surface) y en picker-shell, los tres ya con contrato.