Le descrizioni comandi sembrano il più piccolo problema di interfaccia utente che puoi avere. Sono piccoli e solitamente nascosti. Quando qualcuno chiede come costruirne uno, la risposta tradizionale ritorna quasi sempre utilizzando qualche libreria JavaScript. E per molto tempo questo è stato il consiglio sensato. L'ho seguito anch'io. In superficie, un tooltip è semplice. Passa il mouse o concentrati su un elemento, mostra una piccola casella con del testo, quindi nascondila quando l'utente si allontana. Ma una volta spedito uno agli utenti reali, i vantaggi iniziano a essere visibili. Gli utenti della tastiera utilizzano la scheda Tab nel trigger, ma non visualizzano mai la descrizione comando. Gli screen reader lo annunciano due volte o non lo annunciano affatto. La descrizione comando sfarfalla quando si sposta il mouse troppo velocemente. Si sovrappone al contenuto su schermi più piccoli. Premendo Esc non lo si chiude. La concentrazione si perde. Nel corso del tempo, il mio codice tooltip è diventato qualcosa che non volevo più possedere. Gli ascoltatori di eventi si ammucchiavano. Il passaggio del mouse e la messa a fuoco dovevano essere gestiti separatamente. I clic esterni richiedevano casi speciali. Gli attributi ARIA dovevano essere mantenuti sincronizzati manualmente. Ogni piccola correzione aggiungeva un altro livello di logica. Le biblioteche hanno aiutato, ma erano anche più come scatole nere su cui ho lavorato invece di comprendere appieno cosa stava succedendo dietro le quinte. Questo è ciò che mi ha spinto a guardare la nuova API Popover. Volevo vedere cosa sarebbe successo se avessi ricostruito un singolo tooltip utilizzando il modello nativo del browser senza l'ausilio di una libreria. Iniziando, vale la pena notare che, come per ogni nuova funzionalità, ci sono alcune cose che devono ancora essere risolte. Detto questo, attualmente gode di un ottimo supporto da parte dei browser, anche se ci sono diverse parti dell’API complessiva che sono in continuo cambiamento. Nel frattempo vale la pena tenere d'occhio Caniuse. Il tooltip “vecchio”. Prima dell'API Popover, l'utilizzo di una libreria di descrizioni comandi non era una scorciatoia. Era l'impostazione predefinita. I browser non avevano un concetto nativo di descrizione comando che funzionasse con mouse, tastiera e tecnologia assistiva. Se ti interessava la correttezza, l'unica opzione era utilizzare una libreria, ed è esattamente quello che ho fatto. Ad alto livello, il modello era sempre lo stesso: un elemento trigger, un elemento tooltip nascosto e JavaScript per coordinare i due.
La libreria gestiva il cablaggio che consentiva all'elemento di essere mostrato al passaggio del mouse o al fuoco, di nascondersi quando si sfoca o si lascia il mouse e di riposizionarsi/ridimensionarsi durante lo scorrimento.
Nel corso del tempo, il tooltip potrebbe diventare fragile. Piccoli cambiamenti comportavano rischi. Correzioni minori hanno causato regressioni. Peggio ancora, l'aggiunta di nuovi tooltip ha ereditato la stessa complessità. Le cose tecnicamente funzionavano, ma non sembravano mai stabili o complete. Questo era lo stato delle cose quando ho deciso di ricostruire il tooltip utilizzando l'API Popover nativa del browser. Il momento in cui ho provato l'API Popover Non sono passato all'utilizzo dell'API Popover perché volevo sperimentare qualcosa di nuovo. Ho cambiato perché ero stanco di mantenere il comportamento dei tooltip che credevo che il browser avrebbe dovuto già comprendere. All'inizio ero scettico. La maggior parte delle nuove API Web promettono semplicità, ma richiedono comunque colla, gestione dei casi limite o logica di fallback che ricrea silenziosamente la stessa complessità a cui stavi cercando di sfuggire. Quindi, ho provato l'API Popover nel modo più piccolo possibile. Ecco come appariva:
1. La tastiera “funziona e basta” Il supporto della tastiera dipendeva dal corretto allineamento di più livelli: la messa a fuoco doveva attivare il tooltip, la sfocatura doveva nasconderlo, l'Esc doveva essere collegato manualmente e il tempismo era importante. Se ti perdessi un caso limite, il tooltip resterebbe aperto troppo a lungo o scomparirebbe prima di poter essere letto. Con l'attributo popover impostato su auto o manual, il browser assume il controllo delle nozioni di base: Tab e Shift+Tab si comportano normalmente, Esc chiude ogni volta il tooltip e non sono richiesti ascoltatori aggiuntivi.
Ciò che è scomparso dalla mia base di codice sono stati i gestori di keydown globali, la logica di pulizia specifica di Esc e i controlli di stato durante la navigazione da tastiera. L'esperienza della tastiera ha smesso di essere qualcosa che dovevo mantenere ed è diventata una garanzia del browser. 2. Prevedibilità dello screen reader Questo era ilil miglioramento più grande. Anche con un attento lavoro di ARIA, il comportamento variava, come ho sottolineato in precedenza. Ogni piccolo cambiamento sembrava rischioso. Usare un popover con un ruolo adeguato sembra molto più stabile e prevedibile per quanto riguarda ciò che accadrà:
Ed ecco un'altra vittoria: dopo il passaggio, Lighthouse ha smesso di segnalare gli avvisi di stato ARIA errati per l'interazione, soprattutto perché non ci sono più stati ARIA personalizzati per cui posso sbagliare accidentalmente.
3. Gestione della concentrazione La concentrazione era fragile. Prima avevo regole come: lascia che l'attivazione della messa a fuoco mostri la descrizione comando, sposta la messa a fuoco nella descrizione comando e non chiuderla, attiva la sfocatura quando è troppo vicina, chiudi la descrizione comando e ripristina la messa a fuoco manualmente. Ha funzionato fino a quando non ha funzionato più. Con l'API Popover, il browser applica un modello più semplice in cui l'attenzione può spostarsi in modo più naturale nel popover. La chiusura del popover riporta il focus sul trigger e non ci sono trappole di focus invisibili o momenti di focus persi. E non ho aggiunto il codice di ripristino del focus; L'ho rimosso.
Conclusione L'API Popover significa che i tooltip non sono più qualcosa che simuli. Sono qualcosa che il browser capisce. L'apertura, la chiusura, il comportamento della tastiera, la gestione dell'Escape e gran parte dell'accessibilità ora provengono dalla piattaforma stessa, non da JavaScript ad hoc. Ciò non significa che le librerie di tooltip siano obsolete perché hanno ancora senso per sistemi di progettazione complessi, personalizzazioni pesanti o vincoli legacy, ma l'impostazione predefinita è cambiata. Per la prima volta il tooltip più semplice può essere anche quello più corretto. Se sei curioso, prova questo esperimento: sostituisci semplicemente un solo tooltip nel tuo prodotto con l'API Popover, non riscrivere tutto, non migrare un intero sistema e scegline semplicemente uno e guarda cosa scompare dal tuo codice. Quando la piattaforma ti offre una primitiva migliore, la vittoria non sta solo in meno righe di JavaScript, ma in meno cose di cui devi preoccuparti. Controlla il codice sorgente completo nel mio repository GitHub. Ulteriori letture Per approfondimenti sui popover e sulle API correlate:
"Poppin' In", Geoff Graham "Chiarire la relazione tra popover e dialoghi", Zell Liew "Cos'è popover=suggerimento?", Una Kravets “Comandi dell'Invocatore”, Daniel Schwarz "Creazione di una notifica di chiusura automatica con un popover HTML", Preethi Apri la spiegazione dell'API Popover dell'interfaccia utente “Fai(sopra) i palloncini”, John Rhea “Posizionamento dell'ancora CSS”, Juan Diego Rodríguez
MDN offre anche una documentazione tecnica completa per l'API Popover.
