La información sobre herramientas parece el problema de interfaz de usuario más pequeño que pueda tener. Son pequeños y normalmente están ocultos. Cuando alguien pregunta cómo construir uno, la respuesta tradicional casi siempre es usar alguna biblioteca de JavaScript. Y durante mucho tiempo ese fue el consejo sensato. Yo también lo seguí. A primera vista, la información sobre herramientas es simple. Pase el cursor sobre un elemento o céntrese en él, muestre un pequeño cuadro con texto y luego ocúltelo cuando el usuario se aleje. Pero una vez que envías uno a usuarios reales, los límites comienzan a mostrarse. Los usuarios del teclado presionan el disparador, pero nunca ven la información sobre herramientas. Los lectores de pantalla lo anuncian dos veces o ninguna. La información sobre herramientas parpadea cuando mueve el mouse demasiado rápido. Superpone contenido en pantallas más pequeñas. Al presionar Esc no se cierra. El foco se pierde. Con el tiempo, mi código de información sobre herramientas se convirtió en algo que ya no quería tener. Los oyentes del evento se amontonaron. El desplazamiento y el enfoque debían manejarse por separado. Los clics externos necesitaban casos especiales. Los atributos de ARIA debían mantenerse sincronizados manualmente. Cada pequeña solución agregaba otra capa de lógica. Las bibliotecas ayudaron, pero también eran más como cajas negras con las que trabajé en lugar de comprender completamente lo que estaba sucediendo detrás de escena. Eso fue lo que me impulsó a mirar la API Popover más nueva. Quería ver qué pasaría si reconstruyera una única información sobre herramientas utilizando el modelo nativo del navegador sin la ayuda de una biblioteca. Al comenzar, vale la pena señalar que, como ocurre con cualquier característica nueva, hay algunas cosas que aún se están resolviendo. Dicho esto, actualmente disfruta de un excelente soporte para navegadores, aunque hay varias piezas de la API general que están en proceso de cambio. Mientras tanto, vale la pena vigilar a Caniuse. La información sobre herramientas "antigua" Antes de la API de Popover, usar una biblioteca de información sobre herramientas no era un atajo. Era lo predeterminado. Los navegadores no tenían un concepto nativo de información sobre herramientas que funcionara en el mouse, el teclado y la tecnología de asistencia. Si te importaba la corrección, tu única opción era usar una biblioteca, y eso es exactamente lo que hice. En un nivel alto, el patrón era siempre el mismo: un elemento desencadenante, un elemento de información sobre herramientas oculto y JavaScript para coordinar los dos.
La biblioteca manejó el cableado que permitía que el elemento se mostrara al pasar el mouse o al enfocarlo, ocultarlo al desenfocarlo o dejarlo con el mouse, y reposicionar/cambiar el tamaño al desplazarse.
Con el tiempo, la información sobre herramientas podría volverse frágil. Los pequeños cambios entrañaban riesgos. Las correcciones menores provocaron regresiones. Peor aún, agregar nueva información sobre herramientas heredó la misma complejidad. Las cosas funcionaron técnicamente, pero nunca se sintieron resueltas o completas. Ese era el estado de las cosas cuando decidí reconstruir la información sobre herramientas utilizando la API Popover nativa del navegador. El momento en que probé la API Popover No cambié a usar la API de Popover porque quería experimentar con algo nuevo. Cambié porque estaba cansado de mantener un comportamiento de información sobre herramientas que creía que el navegador ya debería haber entendido. Al principio era escéptico. La mayoría de las API web nuevas prometen simplicidad, pero aún requieren pegamento, manejo de casos extremos o una lógica alternativa que recrea silenciosamente la misma complejidad de la que estaba tratando de escapar. Entonces, probé la API Popover de la forma más pequeña posible. Así es como se veía:
1. El teclado "simplemente funciona" La compatibilidad con el teclado dependía de que varias capas se alinearan correctamente: el enfoque tenía que activar la información sobre herramientas, el desenfoque tenía que ocultarla, Esc tenía que conectarse manualmente y el tiempo importaba. Si se perdiera un caso extremo, la información sobre herramientas permanecería abierta demasiado tiempo o desaparecería antes de que pudiera leerse. Con el atributo popover configurado en automático o manual, el navegador se hace cargo de lo básico: Tab y Shift+Tab se comportan normalmente, Esc cierra la información sobre herramientas cada vez y no se requieren oyentes adicionales.
Lo que desapareció de mi código base fueron los controladores globales de pulsación de teclas, la lógica de limpieza específica de Esc y las comprobaciones de estado durante la navegación con el teclado. La experiencia del teclado dejó de ser algo que tenía que mantener y se convirtió en una garantía del navegador. 2. Previsibilidad del lector de pantalla Este fue elmayor mejora. Incluso con un trabajo cuidadoso de ARIA, el comportamiento varió, como señalé anteriormente. Cada pequeño cambio parecía arriesgado. Usar un popover con un rol adecuado parece y se siente mucho más estable y predecible en cuanto a lo que sucederá:
Y aquí hay otra victoria: después del cambio, Lighthouse dejó de marcar advertencias de estado ARIA incorrectas para la interacción, en gran parte porque ya no hay estados ARIA personalizados para que yo pueda equivocarme accidentalmente.
3. Gestión del enfoque El enfoque solía ser frágil. Antes, tenía reglas como: dejar que el disparador de enfoque muestre información sobre herramientas, mover el foco a la información sobre herramientas y no cerrarlo, desenfocar el disparador cuando está demasiado cerca y cerrar la información sobre herramientas y restaurar el enfoque manualmente. Esto funcionó hasta que dejó de funcionar. Con la API Popover, el navegador aplica un modelo más simple en el que el foco puede moverse de forma más natural hacia el popover. Al cerrar la ventana emergente, el enfoque vuelve al disparador y no hay trampas de enfoque invisibles ni momentos de pérdida de enfoque. Y no agregué código de restauración de enfoque; Lo eliminé.
Conclusión La API Popover significa que la información sobre herramientas ya no es algo que se simula. Son algo que el navegador entiende. La apertura, el cierre, el comportamiento del teclado, el manejo de Escape y una gran parte de la accesibilidad ahora provienen de la plataforma misma, no de JavaScript ad-hoc. Eso no significa que las bibliotecas de información sobre herramientas estén obsoletas porque todavía tienen sentido para sistemas de diseño complejos, personalización intensa o restricciones heredadas, pero el valor predeterminado ha cambiado. Por primera vez, la información sobre herramientas más sencilla también puede ser la más correcta. Si tiene curiosidad, pruebe este experimento: simplemente reemplace solo una información sobre herramientas en su producto con la API Popover, no reescriba todo, no migre un sistema completo, simplemente elija una y vea qué desaparece de su código. Cuando la plataforma le ofrece una primitiva mejor, la ganancia no es solo menos líneas de JavaScript, sino que hay menos cosas de las que preocuparse. Consulte el código fuente completo en mi repositorio de GitHub. Lectura adicional Para profundizar en los popovers y las API relacionadas:
"Poppin' In", Geoff Graham “Aclarando la relación entre popovers y diálogos”, Zell Liew “¿Qué es popover=pista?”, Una Kravets “Comandos del invocador”, Daniel Schwarz “Creación de una notificación de cierre automático con una ventana emergente HTML”, Preethi Explicación de la API emergente de interfaz de usuario abierta "Explota (sobre) los globos", John Rhea “Posicionamiento de Anclas CSS”, Juan Diego Rodríguez
MDN también ofrece documentación técnica completa para la API de Popover.
