En RTL el navegador DESCANSA scrollLeft en 0 con el contenido pegado a la
derecha y lo lleva NEGATIVO hacia el final de lectura (modelo negativo del
CSSOM). Nadie lo traducia, asi que resolvedDir era codigo muerto y toda la
matematica del eje inline estaba rota:
aria-valuenow -50 / -99 con aria-valuemin="0" -> 0 / 50 / 100
thumb left: -167px, FUERA del carril -> dentro y espejado
data-at-left siempre puesto -> solo en el borde izq.
data-at-right nunca -> en reposo
click canalon al 10% desde la izquierda -> 0 -> -232, el 90% logico
Dos traducciones privadas en el provider y cada consumidor toma la suya: lo
que sigue el eje de LECTURA (offset del thumb, aria-valuenow, click en el
canalon) y lo que se queda FISICO (data-at-left / data-at-right, cuyos
nombres lo son y cuyo uso documentado —sombras de scroll— tambien).
El ancla del thumb pasa a inset-inline-start porque el offset es progreso de
lectura: es la decision opuesta a tabs / sliding-indicator, donde el JS media
una coordenada fisica. La regla no cambia: mira de que lado esta la medida.
El arrastre no necesito nada, y no por suerte: subir scrollLeft mueve el
viewport a la derecha en los dos marcos. Verificado, no supuesto.
Ambos extremos llevan ahora la misma holgura de 1px, porque solo uno cae en
un cero exacto y cual de los dos depende de la direccion. De paso LTR gana el
data-at-right del extremo, que tampoco se encendia.
Medido en Chrome en las dos direcciones, con el toggle del topbar. El test
nuevo sale ROJO con el provider anterior.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
dev
ae756ee578