As informacións sobre ferramentas parecen o menor problema de IU que podes ter. Son pequenos e normalmente ocultos. Cando alguén pregunta como construír un, a resposta tradicional case sempre volve usando algunha biblioteca de JavaScript. E durante moito tempo, ese foi o consello sensato. Eu tamén o seguín. Na superficie, unha información sobre ferramentas é sinxela. Pasa o rato ou céntrate nun elemento, amosa un pequeno cadro con algo de texto e escóndeo cando o usuario se afasta. Pero unha vez que envías un a usuarios reais, os bordos comezan a mostrarse. Os usuarios do teclado pulsan no disparador, pero nunca ven a información sobre ferramentas. Os lectores de pantalla anúnciano dúas veces, ou nada. A información sobre ferramentas parpadea cando moves o rato demasiado rápido. Superpón contido en pantallas máis pequenas. Premendo Esc non se pecha. O foco pérdese. Co paso do tempo, o meu código de información sobre ferramentas converteuse en algo que xa non quería posuír. Os oíntes do evento acumuláronse. Hover e foco tiveron que manexarse por separado. Os clics externos necesitaban casos especiais. Os atributos ARIA tiveron que manterse sincronizados a man. Cada pequena corrección engadiu outra capa de lóxica. As bibliotecas axudaron, pero tamén eran máis como caixas negras coas que traballei en lugar de comprender completamente o que estaba a suceder entre bastidores. Iso foi o que me impulsou a mirar a nova API de Popover. Quería ver que pasaría se reconstruía unha única información sobre ferramentas usando o modelo nativo do navegador sen a axuda dunha biblioteca. Cando comezamos, paga a pena sinalar que, como ocorre con calquera función nova, hai algunhas cousas con ela que aínda se están a resolver. Dito isto, actualmente goza dun gran soporte para o navegador, aínda que hai varias pezas na API xeral que están en proceso. Paga a pena manter un ollo en Caniuse mentres tanto. A información sobre ferramentas "Vela". Antes da API Popover, usar unha biblioteca de información sobre ferramentas non era un atallo. Era o predeterminado. Os navegadores non tiñan un concepto nativo dunha información sobre ferramentas que funcionase con rato, teclado e tecnoloxía de asistencia. Se che importaba a corrección, a túa única opción era usar unha biblioteca, e iso é exactamente o que fixen. A un alto nivel, o patrón era sempre o mesmo: un elemento de activación, un elemento de información de ferramentas oculto e JavaScript para coordinar os dous.
A biblioteca manexaba o cableado que permitía que o elemento se mostrase ao pasar o rato ou ao foco, esconderse ao desenfocar ou ao saír do rato e reposicionar/redimensionar ao desprazarse.
Co paso do tempo, a información sobre ferramentas pode volverse fráxil. Os pequenos cambios levaban risco. As correccións menores provocaron regresións. Peor aínda, engadir novas ferramentas herdou a mesma complexidade. As cousas funcionaron tecnicamente, pero nunca se sentiron resoltas nin completas. Ese foi o estado das cousas cando decidín reconstruír a información sobre ferramentas usando a API Popover nativa do navegador. O momento en que probei a API Popover Non cambiei a usar a API Popover porque quería experimentar con algo novo. Cambiei porque estaba canso de manter o comportamento da información sobre ferramentas que cría que o navegador xa debería entender. Eu era escéptico ao principio. A maioría das novas API web prometen simplicidade, pero aínda así requiren pegamento, manexo de casos extremos ou lóxica alternativa que recrea en silencio a mesma complexidade da que estabas tentando escapar. Entón, probei a API Popover da forma máis pequena posible. Aquí tes o que parecía:
1. O teclado "Só funciona" O soporte do teclado dependía de que varias capas se aliñaran correctamente: o foco tiña que activar a información sobre ferramentas, o desenfoque tiña que ocultalo, o Esc tiña que conectarse manualmente e o tempo importaba. Se perdeches un caso de borde, a información sobre ferramentas permanecería aberta demasiado tempo ou desaparecería antes de poder ler. Co atributo popover configurado como automático ou manual, o navegador toma o control do básico: Tab e Maiús+Tab compórtanse normalmente, Esc pecha a información sobre ferramentas cada vez e non se necesitan oíntes adicionais.
O que desapareceu da miña base de código foron os controladores globais de teclas, a lóxica de limpeza específica de Esc e as comprobacións de estado durante a navegación do teclado. A experiencia do teclado deixou de ser algo que tiña que manter e converteuse nunha garantía do navegador. 2. Predicibilidade do lector de pantalla Este foi omaior mellora. Mesmo cun traballo coidadoso de ARIA, o comportamento variou, como delineei anteriormente. Cada pequeno cambio parecía arriscado. Usar un popover cun papel axeitado parece e parece moito máis estable e previsible en canto ao que vai pasar:
E aquí hai outra vitoria: despois do cambio, Lighthouse deixou de marcar avisos de estado ARIA incorrectos para a interacción, en gran parte porque xa non hai estados ARIA personalizados para que me equivoque accidentalmente.
3. Xestión do foco O foco adoitaba ser fráxil. Antes tiña regras como: deixar que o disparador do foco amose a información sobre ferramentas, mover o foco á información sobre ferramentas e non pechar, desenfocar o disparador cando está demasiado preto e pechar a información sobre ferramentas e restaurar o foco manualmente. Isto funcionou ata que non. Coa API Popover, o navegador aplica un modelo máis sinxelo onde o foco pode moverse de forma máis natural ao popover. Ao pechar o popover devolve o foco ao gatillo e non hai trampas de foco invisibles nin momentos de foco perdidos. E non engadín o código de restauración do foco; Quiteino.
Conclusión A API Popover significa que as informacións sobre ferramentas xa non son algo que simulas. Son algo que o navegador entende. A apertura, o peche, o comportamento do teclado, o manexo de Escape e unha gran parte da accesibilidade agora veñen da propia plataforma, non de JavaScript ad-hoc. Iso non significa que as bibliotecas de información sobre ferramentas estean obsoletas porque aínda teñen sentido para sistemas de deseño complexos, personalización pesada ou limitacións antigas, pero o predeterminado cambiou. Por primeira vez, a información máis sinxela tamén pode ser a máis correcta. Se tes curiosidade, proba este experimento: simplemente substitúe só unha información sobre ferramentas no teu produto pola API Popover, non reescribas todo, non migres un sistema completo e elixe un e mira o que desaparece do teu código. Cando a plataforma ofréceche un primitivo mellor, a vitoria non son só menos liñas de JavaScript, senón que hai menos cousas das que tes que preocuparte. Consulte o código fonte completo no meu repositorio de GitHub. Lecturas complementarias Para inmersións máis profundas en popovers e API relacionadas:
"Poppin' In", Geoff Graham "Aclarando a relación entre popovers e diálogos", Zell Liew "Que é popover=suxestión?", Una Kravets "Comandos invocadores", Daniel Schwarz "Crear unha notificación de peche automático cun popover HTML", Preethi Abre o explicador da API Popover de UI "Pop(over) the Balloons", John Rhea “CSS Anchor Positioning”, Juan Diego Rodríguez
MDN tamén ofrece documentación técnica completa para a API Popover.
