|
|
|
|
|
# Pendientes
|
|
|
|
|
|
|
|
|
|
|
|
## Forma (shape) — asignar la familia de borde por componente
|
|
|
|
|
|
|
|
|
|
|
|
Que cada componente reciba la **familia de forma** (`rounded` · `continuous` · `cut` · `scoop`)
|
|
|
|
|
|
como prop, además del default del tema. Diferenciador fuerte en **chips y badges**.
|
|
|
|
|
|
|
|
|
|
|
|
- ✅ **Hecho (2026-06-05)**: canon `SHAPE_FAMILIES` + tipo `ShapeFamily` en `lib/types`; prop
|
|
|
|
|
|
`shape` en **Badge · Card · Button · TagsInput.Item** (el chip) → emite `data-shape="{family}"`
|
|
|
|
|
|
(la regla `[data-shape]` del motor hace el resto). Ortogonal a `rounded` (magnitud); default =
|
|
|
|
|
|
arco.
|
|
|
|
|
|
- 💡 **Universal hoy vía atributo**: TODO componente que difunde `{...rest}` acepta
|
|
|
|
|
|
`data-shape="cut"` directamente (verificado en inputs, tags, etc.) — la familia ya es usable en
|
|
|
|
|
|
cualquier sitio sin prop. La prop typed es solo el azúcar ergonómico de los más comunes.
|
|
|
|
|
|
- ⏳ **Pendiente — azúcar typed** en más superficies si se piden: inputs (number-field/
|
|
|
|
|
|
textarea/search-field/select), contenidos flotantes (popover/dropdown/select content). Mismo
|
|
|
|
|
|
patrón de 3 ediciones (import `ShapeFamily` + prop + `data-shape`).
|
|
|
|
|
|
- **Familias angulares (cut/scoop) sobre píldoras/círculos** — a radio-píldora (999) NO hay
|
|
|
|
|
|
esquina que cortar: sus extremos son curvas continuas, así que el bevel se come el extremo entero
|
|
|
|
|
|
→ hexágono. La respuesta correcta **no es excluirlas** (eso es esquivar el problema): el control
|
|
|
|
|
|
**adopta un radio FINITO bajo la familia angular** para *tener* esquinas — un "cut capsule"
|
|
|
|
|
|
coherente — o se queda **shape-neutral por decisión deliberada** (un avatar / dot que conviene
|
|
|
|
|
|
redondo). Decisión per-control, no un veto a las píldoras. Implementado en `/temas/tema` (switch
|
|
|
|
|
|
track → radio finito en cut/scoop, píldora en round/continuous; thumb y avatar redondos a
|
|
|
|
|
|
propósito). **La recipe del `Switch` de eidos debería seguir el mismo patrón** (`[data-shape='cut'|
|
|
|
|
|
|
'scoop']` → radio de track finito). `continuous` sobre círculos/píldoras es inocuo (squircle
|
|
|
|
|
|
suave), solo cut/scoop degeneran.
|
|
|
|
|
|
- ✅ **Demos (2026-06-05)**: control `shape` en vivo en las demos de **badge · button · card ·
|
|
|
|
|
|
tags-input** (chips + code snippet + fila de patrones en badge). Ya es descubrible, no solo
|
|
|
|
|
|
documentado.
|
|
|
|
|
|
- **scoop / cóncavo**: en Chromium actual, `corner-shape: scoop` con `border` + `box-shadow`
|
|
|
|
|
|
proyecta la sombra DENTRO de los entrantes y el borde de 1px hace costura en las esquinas
|
|
|
|
|
|
cóncavas → se ve sucio. Para chips/badges `scoop` (y `cut`), preferir **relleno plano** sin
|
|
|
|
|
|
borde/sombra fuerte, o gestionar la sombra en la recipe (p. ej. `filter: drop-shadow()` en
|
|
|
|
|
|
lugar de `box-shadow`, evaluando coste). Verificado en `/temas/forma` §Familias.
|
|
|
|
|
|
|
|
|
|
|
|
## Forma — adopción general por componentes
|
|
|
|
|
|
|
|
|
|
|
|
Que las superficies **rectangulares** reales (cards, dialogs, inputs, popovers, menús…) opten a
|
|
|
|
|
|
`data-shape="continuous"` desde sus recipes — como hicimos con el halo de depth. Cuidando de no
|
|
|
|
|
|
squircle-izar avatares / píldoras (círculos perfectos). Es una pasada de barrido aparte.
|
|
|
|
|
|
|
|
|
|
|
|
## Forma — soporte de `corner-shape` (decisión de canon)
|
|
|
|
|
|
|
|
|
|
|
|
La continuidad (squircle), `cut` y `scoop` dependen de `corner-shape` (Chromium 2025+). Donde no
|
|
|
|
|
|
hay soporte **degrada al arco** de `border-radius` (la magnitud siempre funciona) — decisión de
|
|
|
|
|
|
canon: **progressive enhancement, NO polyfill**. Un Houdini Paint Worklet no existe en Firefox y
|
|
|
|
|
|
las máscaras SVG por elemento recortan la sombra (mismo problema que `clip-path`). Revisar el
|
|
|
|
|
|
soporte de Safari/Firefox periódicamente y subir el listón cuando lleguen.
|
|
|
|
|
|
|
|
|
|
|
|
## Depth — cue `scrim`
|
|
|
|
|
|
|
|
|
|
|
|
`--depth-{plane}-scrim` existe como token pero sin regla cableada; el backdrop dim de los modales
|
|
|
|
|
|
lo gestiona hoy cada componente. Cablear una regla `[data-depth][data-scrim]` si emerge un
|
|
|
|
|
|
consumidor que lo necesite fuera de dialog/drawer.
|
|
|
|
|
|
|
|
|
|
|
|
## Tema completo — más allá de los canales visuales (diferido)
|
|
|
|
|
|
|
|
|
|
|
|
`eidos.applyTheme(seed)` (capstone, hecho) compone **solo los 5 canales visuales** (color ·
|
|
|
|
|
|
tipografía · profundidad · forma · espacio). Un **tema** en sentido pleno es más, y reparte por
|
|
|
|
|
|
capas — esto hay que tenerlo claro antes de construir una página de construcción de tema "de
|
|
|
|
|
|
verdad":
|
|
|
|
|
|
|
|
|
|
|
|
| Dimensión | Define | Capa | ¿En applyTheme? |
|
|
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
| **Visual** | color · tipo · depth · shape · space | eidos (`applyTheme`) | ✅ |
|
|
|
|
|
|
| **Semántica** | firmas de sonido + háptica, packs por componente, intents | sema (`EngineSemantic`) | ❌ otra capa |
|
|
|
|
|
|
| **Iconografía** | set / estilo de iconos | art (icon) | ❌ |
|
|
|
|
|
|
| **Variantes** | control/selection/chip/marker/tabs | **canon** de eidos (`EIDOS_VARIANTS`) | ⚠️ no se definen — se retintan + previsualizan |
|
|
|
|
|
|
|
|
|
|
|
|
Claves:
|
|
|
|
|
|
- **`applyTheme` está bien acotado a eidos (visual).** Un tema *completo* es **cross-layer**; su
|
|
|
|
|
|
sitio natural es `active-uix`, p. ej. `uix.applyBrand({ visual, sema, icons })` que compone
|
|
|
|
|
|
`eidos.applyTheme` + perfil sema + iconos. NO meter sema dentro de eidos (rompe eidos≠sema).
|
|
|
|
|
|
- **La capa sema es opcional / nullable.** Un tema puede traer perfil completo, afinado, o
|
|
|
|
|
|
**silencioso** (`events: { sound: false, haptic: false }` / sin packs). No es caso especial: es
|
|
|
|
|
|
ausencia de perfil (sema es ornamental, el runtime va sin ella).
|
|
|
|
|
|
- **Variantes = canon, no theme-extensible** (THEMING §19). Un tema las retinta, no las inventa.
|
|
|
|
|
|
Lo que faltó en el demo: **previsualizarlas** (matriz botones × 4 variantes × intents, selección,
|
|
|
|
|
|
chips…) para ver el tema sobre todo el vocabulario, no una sola mini-tarjeta.
|
|
|
|
|
|
|
|
|
|
|
|
**Deuda de encuadre**: el demo `/temas/tema` ("Un tema, una semilla") **sobre-promete** — es, con
|
|
|
|
|
|
precisión, *los canales visuales* de un tema. Es válido para ese alcance (decisión consciente),
|
|
|
|
|
|
pero al retomar: o (A) reencuadrar el copy a "canales visuales del tema", o (B) ampliar la página
|
|
|
|
|
|
(control de perfil sema completo/afinado/silencioso + matriz de variantes + iconografía), o (C)
|
|
|
|
|
|
subir a `uix.applyBrand` cross-layer (lo arquitectónicamente completo). Decidir al reabrir.
|
|
|
|
|
|
|
|
|
|
|
|
## Iconos — auditoría del bug `<svg>` + banco de pruebas
|
|
|
|
|
|
|
|
|
|
|
|
(Residual del track icono↔tipografía, resuelto 2026-06-13. La regla canónica
|
|
|
|
|
|
—`size = font = icon`, el icono acompaña el font que el componente realmente
|
|
|
|
|
|
usa; cards siguen el título, no se inflan— vive ya en `THEMING.md §5` + los
|
|
|
|
|
|
recipes. Solo quedaron sueltos estos dos.)
|
|
|
|
|
|
|
|
|
|
|
|
- ⏳ **Auditar el bug del `<svg>` del `Icon` en otros componentes.** El `<svg>`
|
|
|
|
|
|
del `Icon` lleva `width: var(--icon-size)` **inline**; si un componente
|
|
|
|
|
|
dimensiona ese svg por CSS externo (`[data-x] svg { inline-size: … }`), el
|
|
|
|
|
|
inline lo **vence** y el icono queda fijo (no responde al `size`). Pasó en
|
|
|
|
|
|
**button** (arreglado: el button alimenta `--icon-size: var(--_button-icon-size)`).
|
|
|
|
|
|
`radio-cards` NO lo tiene. Patrón de fix: el componente alimenta
|
|
|
|
|
|
`--icon-size: var(--_x-icon-size)`. Revisar el resto de recipes que estilan
|
|
|
|
|
|
`svg` directamente.
|
|
|
|
|
|
- ⏳ **Decidir si se borra el banco de pruebas** `/uix/icon-scale-study`
|
|
|
|
|
|
(`web/routes/uix/icon-scale-study/+page.svelte`) — comparaba modelos icon/font;
|
|
|
|
|
|
con la decisión ya tomada (opción 1) probablemente sobra.
|
