|
|
|
|
@ -1190,4 +1190,49 @@ deberían seguir la dirección.
|
|
|
|
|
|
|
|
|
|
Conclusión: extremos físicos son defendibles **porque no hay semántica que
|
|
|
|
|
respetar**, pero no hay precedente que lo respalde ni que lo contradiga.
|
|
|
|
|
Decisión del usuario, ahora informada.
|
|
|
|
|
|
|
|
|
|
**DECIDIDO** (el usuario dejó la elección): el movimiento por teclado del
|
|
|
|
|
panel —flechas y `Home`/`End`— **se queda FÍSICO**. Sin valor semántico que
|
|
|
|
|
respetar, el vocabulario físico es coherente CONSIGO MISMO (`bounds.left` /
|
|
|
|
|
`bounds.right` ya lo son), que es la misma excepción legítima con la que §6.10
|
|
|
|
|
dejó intacto al `toast`. No se toca nada.
|
|
|
|
|
|
|
|
|
|
### 9.14 · El resize del float-panel — el usuario lo vio, yo no lo había mirado
|
|
|
|
|
|
|
|
|
|
Commit `552f4f2c7`. Reportado con una captura del grip en la esquina inferior
|
|
|
|
|
IZQUIERDA. **Ahí es donde debe estar en RTL** (el recipe lo coloca con
|
|
|
|
|
`inset-inline-end`), pero la matemática no acompañaba:
|
|
|
|
|
|
|
|
|
|
```ts
|
|
|
|
|
if (edge.includes('e')) width = start.width + dx; // dx es FÍSICO
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Los handles se colocan con insets LÓGICOS, así que el marcado `e` es el borde
|
|
|
|
|
inline-END: físicamente derecho en LTR y físicamente IZQUIERDO en RTL.
|
|
|
|
|
Medido: **arrastrar el grip hacia FUERA encogía el panel** — 436 → 327 donde
|
|
|
|
|
debía crecer a 545. El eje de bloque sí estaba bien (292 → 346).
|
|
|
|
|
|
|
|
|
|
Resuelto convirtiendo el edge lógico a su lado FÍSICO una sola vez
|
|
|
|
|
(`physicalResizeEdge`), de modo que toda la geometría de abajo sigue en píxeles
|
|
|
|
|
físicos — **la forma de `drawer.resolveDirection()`**, que §6.9 señaló como el
|
|
|
|
|
ejemplo a imitar.
|
|
|
|
|
|
|
|
|
|
⚠️ **Y destapó un SEGUNDO defecto, latente**: crecer desde `w`/`n` mantiene el
|
|
|
|
|
lado opuesto fijo, así que el origen del panel viaja hacia fuera, y ese caso no
|
|
|
|
|
se acotaba contra los bounds — el panel se salía del contenedor (medido
|
|
|
|
|
`POS -85` con el stage empezando en 0). **En LTR la rama era inalcanzable**:
|
|
|
|
|
sólo montan `e`, `s` y el grip `se`. Ahora se acota por el hueco disponible.
|
|
|
|
|
|
|
|
|
|
El grip además mentía en RTL: `cursor: nwse-resize` (↘↖) y los chevrones a
|
|
|
|
|
`-45deg / bottom right` son físicos y no tienen forma lógica → par `:dir(rtl)`.
|
|
|
|
|
|
|
|
|
|
| | resultado |
|
|
|
|
|
| --- | --- |
|
|
|
|
|
| RTL · arrastre hacia fuera | 300 → 409 de ancho, borde DERECHO fijo en 803 |
|
|
|
|
|
| RTL · arrastre largo | se detiene exacto en el borde del stage (`left 0`) |
|
|
|
|
|
| LTR | sin cambios: 300 → 436, borde izquierdo fijo en 24 |
|
|
|
|
|
|
|
|
|
|
⚠️ **LECCIÓN, y es la tercera vez que aparece en esta sesión**: §6.10 y §9.5
|
|
|
|
|
dieron el float-panel por revisado **midiendo sólo la POSICIÓN del panel**.
|
|
|
|
|
Nadie tocó el resize. Verificar un componente con gestos no es medir su
|
|
|
|
|
geometría en reposo — hay que **ejercitar cada gesto que ofrece**.
|
|
|
|
|
|