docs(eidos): los 20px del MenuDial son una decision, no una deriva — corregido el registro

El commit anterior (c53efc602) los documento mal. Escribi que el comentario
«mirrors the FAB» era falso y presente el `--space-5` como una divergencia a
unificar algun dia. No lo es: el dial corria en `--space-4` (16px) y se quedaba
corto, por eso se subio a 20. Lo deliberado era el VALOR; lo que quedo obsoleto
fue el comentario de al lado.

Cambia el sentido de lo que la ranura de override esta haciendo aqui. No preserva
una herencia incomoda a la espera de que alguien la unifique: registra que un
consumidor evaluo el eje y aterrizo en otro sitio. Que es justamente para lo que
existe — la capa posee el default, el consumidor que ha medido escribe la ranura.

Sin cambio de codigo: el valor y el puente ya eran correctos. Se corrige lo que
dicen de si mismos el recipe y los dos README, y se retira de los pendientes
«unificar el offset a 16px», que no es un pendiente.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
alpha-0.1-dir-prefs
dev 2 months ago
parent c53efc6025
commit ee41b691d9

@ -300,7 +300,7 @@ component with no soma layer, not defects:
| Gap | Disposición | Detalle |
| ------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **~~`Fab` y `MenuDial`~~ ✅ ambos migrados** (2026-08-14 · 2026-08-15) | **hecho** | Los dos importan `affix.css` y estampan `data-affix-placement`; sus copias privadas (4 y 9 zonas) están borradas y sus tokens propios retirados. Puentes: `Fab` reafirma `position` (empate con `[data-button]`) y fija la banda `sticky`; `MenuDial` no lo necesita y sólo puentea su offset de `--space-5`. `layer:check` los descubre solos por el import |
| **~~`Fab` y `MenuDial`~~ ✅ ambos migrados** (2026-08-14 · 2026-08-15) | **hecho** | Los dos importan `affix.css` y estampan `data-affix-placement`; sus copias privadas (4 y 9 zonas) están borradas y sus tokens propios retirados. Puentes: `Fab` reafirma `position` (empate con `[data-button]`) y fija la banda `sticky`; `MenuDial` no lo necesita y sólo puentea su offset de `--space-5` (20px, decidido: 16 se quedaba corto para un dial). `layer:check` los descubre solos por el import |
| **Inline safe-area is paired physically in `fab.css` / `menu-dial.css`** | **diferir** — a real RTL defect in shipped code, found while building this | Both pair `inset-inline-start` with `env(safe-area-inset-left)`, which clears the wrong notch in RTL landscape on a notched device. This layer does it correctly; the two copies inherit the fix when they migrate |
| **Portal escape for a transformed ancestor** | **descartar en v1** | Any ancestor with `transform` / `filter` / `contain` becomes the containing block for a fixed descendant, and the affix silently stops being viewport-fixed — with no workaround from inside the element. A `portal` prop composing `$soma/components/internal`'s `Portal` is the escape. Not shipped: the case did not arise for the consumer that drove this build, and CLAUDE.md §2 forbids the speculative prop. The demo exhibits the failure live (Live tab → «transformed ancestor») so it is documented behaviour, not a surprise; today the fix is to hoist the `<Affix>` above the transformed ancestor |
| **~~No rung between `sticky` (100) and `dropdown` (300)~~ — RESUELTO 2026-08-14** | **canon — firmado por el autor** | `--z-index-affix: 150` added to `STATIC_Z_INDEX`. Viewport-fixed page chrome is a role of its own: above container-sticky chrome, below every menu and dialog. It removed the workaround it replaced — the `z` prop this component carried for one review cycle is gone, since the default now clears the only measured collision |

@ -93,12 +93,17 @@ default `+`→`×` morph) · `aria-label` · `onOpenChange`.
is the layer hook. Verified after the migration: `bottom-end` in `arc` still
computes `--_menu-dial-arc-start: 270deg` / `span: 90deg`.
⚠️ **Its offset is `--space-5` (20px), and the bridge preserves it.** The
retired comment claimed it «mirrors the FAB»; it never did — the FAB is on
`--space-4` (16px), which is also the layer's default. Unifying is a visible
4px move and therefore a decision, not a migration side effect. Declared here
until someone takes it. The `z-index: var(--z-index-sticky, 1100)` fallback
went with the copy: the token always resolved, so the 1100 was dead.
**Its offset is `--space-5` (20px), and that is a DECISION, not drift.** The
dial ran on `--space-4` (16px) — still the layer's default and what `Fab`
uses — and 16 read as too little for a dial, so it was moved up. The bridge
writes the override slot to keep it. (The comment that sat beside the token
said it «mirrors the FAB»; that line went stale when the value changed — the
value was the deliberate part.) This is exactly what the slot exists for: the
layer owns the default, a consumer that has evaluated the axis and landed
somewhere else writes the slot.
The `z-index: var(--z-index-sticky, 1100)` fallback went with the copy: the
token always resolved, so the 1100 was dead.
## Keyboard & a11y

@ -49,7 +49,7 @@
<!-- The trigger IS the positioned action wrapper (no extra element). -->
<div class="menu-dial-action" style="--_menu-dial-i: {index};" {...props}>
<Fab
{...(part ? part.props : { 'data-menu-dial-action': '' })}
{...part ? part.props : { 'data-menu-dial-action': '' }}
data-disabled={disabled ? '' : undefined}
role="menuitem"
tabindex={-1}

@ -68,11 +68,15 @@
* which stamps no hook. The tie `Fab` has to win comes from the `<Button>` it
* composes; a dial composes nothing at the frame.
*
* ⚠️ The offset is `--space-5` (20px), NOT the layer's `--space-4` default, and
* it is bridged here to keep the dial exactly where it was. The retired comment
* claimed it "mirrors the FAB" — it never did: the FAB was on 16px. Unifying is
* a visible 4px change and therefore a decision, not a migration side effect;
* it stays declared until someone takes it.
* The offset is `--space-5` (20px), NOT the layer's `--space-4` default, and it
* is bridged here because 20px is a DECISION, not drift: the dial ran on 16px
* and it read as too little, so it was moved up. (The old comment beside the
* token still said "mirrors the FAB" — that line went stale when the value
* changed; the value was the deliberate part.)
*
* This is precisely what the override slot is for: the layer owns the default,
* a consumer that has evaluated the axis and reached a different answer writes
* the slot. Nothing to unify away.
*/
[data-menu-dial][data-affix-placement] {
--_affix-offset: var(--space-5);

Loading…
Cancel
Save

Powered by TurnKey Linux.