Tuve un muy embarazoso Momento CSS el otro día.
Estaba trabajando en el código de interfaz de usuario de un diseño que tenía una barra lateral estrecha de iconos. No hay suficiente espacio allí para mostrar el texto de los íconos, por lo que la idea es que usemos texto accesible (pero visualmente oculto, por defecto) que ya está allí como un información sobre herramientas en un “vuelo estacionario largo”. Es decir, un dispositivo con un cursor y el cursor sobre el elemento durante un tiempo, como tres segundos.
Entonces, mi mente fue así …
- Puedo usar Expresar: la información sobre herramientas es visible o no visible. Administraré el estado, que se manifestará en el DOM como un nombre de clase en un elemento HTML.
- Entonces me ocuparé de la lógica por cambiar ese estado.
- El defecto el estado será no visible, pero si el mouse está dentro del elemento durante más de tres segundos, cambiaré el estado a visible.
- Si el mouse abandona el elemento, el estado permanecerá (o se convertirá) no visible.
Este era un proyecto de React, por lo que el estado estaba solo en la mente. Eso terminó así:
No está tan mal, ¿verdad? Eh. Tener el estado administrado en JavaScript potencialmente abre algunas puertas, pero en este caso, fue una exageración total. Aparte del hecho de que encuentro mouseenter y mouseleave un poco quisquilloso, CSS podría haber hecho todo, y con menos código.
Esa es la parte vergonzosa … ¿por qué iba a subir la cadena a una biblioteca de JavaScript para hacer esto cuando el CSS que ya estoy escribiendo puede manejarlo?
Dejaré la interfaz de usuario en React, pero arrancar todas las cosas de la gestión estatal. Todo lo que haré es agregar un transition-delay: 3s cuando el .icon es :hover de modo que son cero segundos cuando no está suspendido, luego desaparece inmediatamente cuando el cursor del mouse sale).
Un hover largo es básicamente una línea en CSS:
.thing {
transition: 0.2s;
}
.thing:hover {
transition-delay: 3s; /* delay hover animation only ON, not OFF */
}Funciona genial.
Un problema que no se aborda aquí es el problema de la pantalla táctil. Se podría argumentar que los lectores de pantalla están bien con el texto accesible y los navegadores de escritorio están bien debido a la información sobre herramientas personalizada, pero es posible que los usuarios con pantallas solo táctiles no puedan descubrir las etiquetas de los iconos. En mi caso, estaba construyendo para un escenario de pantalla grande que asume cursores, pero no creo que todo esté perdido para las pantallas táctiles. Si el elemento es un enlace, el :hover podría disparar al primer toque de todos modos. Si el enlace lo lleva a algún lugar con un título claro, ese podría ser suficiente contexto. Y siempre puede volver a más JavaScript y manejar eventos táctiles.