|
|
# 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`).
|
|
|
- **No** aplicar familias a círculos / píldoras (avatares): las deformaría (un avatar
|
|
|
`continuous` se vuelve squircle, un `cut` octágono). El default de esos componentes debe
|
|
|
quedarse en `rounded`.
|
|
|
- ✅ **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.
|
