Sfaturile instrumente se simt ca cea mai mică problemă de UI pe care o puteți avea. Sunt mici și de obicei ascunse. Când cineva întreabă cum se construiește unul, răspunsul tradițional revine aproape întotdeauna folosind o bibliotecă JavaScript. Și pentru o lungă perioadă de timp, acesta a fost sfatul înțelept. L-am urmat si eu. La suprafață, un tooltip este simplu. Treceți cu mouse-ul sau concentrați-vă pe un element, afișați o casetă cu ceva text, apoi ascundeți-o când utilizatorul se îndepărtează. Dar odată ce expediați unul utilizatorilor reali, marginile încep să se arate. Utilizatorii de tastatură Apăsați declanșatorul, dar nu văd niciodată indicația. Cititoarele de ecran o anunță de două ori sau deloc. Indicatorul instrument pâlpâie când mișcați mouse-ul prea repede. Se suprapune conținut pe ecrane mai mici. Apăsarea Esc nu îl închide. Concentrarea se pierde. De-a lungul timpului, codul meu tooltip a devenit ceva ce nu mai doream să dețin. Ascultătorii evenimentelor s-au îngrămădit. Hoverul și focalizarea trebuiau gestionate separat. Clicurile din exterior aveau nevoie de cazuri speciale. Atributele ARIA trebuiau menținute sincronizate manual. Fiecare reparație mică a adăugat un alt strat de logică. Bibliotecile au ajutat, dar erau, de asemenea, mai mult ca niște cutii negre cu care lucram, în loc să înțeleg pe deplin ce se întâmplă în culise. Asta a fost ceea ce m-a împins să mă uit la noul API Popover. Am vrut să văd ce s-ar întâmpla dacă aș reconstrui un singur tooltip folosind modelul nativ al browserului fără ajutorul unei biblioteci. Pe măsură ce începem, merită remarcat faptul că, ca și în cazul oricărei funcții noi, există unele lucruri cu ea care sunt încă în curs de rezolvare. Acestea fiind spuse, în prezent se bucură de un suport excelent pentru browser, deși există mai multe piese ale API-ului general care sunt în flux. Merită să fii cu ochii pe Caniuse între timp. Balonul cu instrumente „vechi”. Înainte de API-ul Popover, utilizarea unei biblioteci de informații despre instrumente nu era o comandă rapidă. A fost implicit. Browserele nu aveau un concept nativ al unui tooltip care să funcționeze cu mouse, tastatură și tehnologie de asistență. Dacă îți pasă de corectitudine, singura ta opțiune era să folosești o bibliotecă și exact asta am făcut. La un nivel înalt, modelul a fost întotdeauna același: un element de declanșare, un element ascuns de tip tooltip și JavaScript pentru a le coordona pe cele două.
Biblioteca s-a ocupat de cablajul care a permis elementului să se afișeze la trecerea cu mouse-ul sau la focalizare, ascunderea la încețoșare sau la plecarea mouse-ului și repoziționarea/redimensionarea pe derulare.
De-a lungul timpului, tooltipul ar putea deveni fragil. Micile schimbări au implicat riscuri. Remedieri minore au cauzat regresii. Mai rău, adăugarea de noi sfaturi cu instrumente a moștenit aceeași complexitate. Lucrurile au funcționat tehnic, dar nu s-au simțit niciodată rezolvate sau complete. Aceasta a fost starea lucrurilor când am decis să reconstruiesc balonul folosind API-ul Popover nativ al browserului. Momentul în care am încercat API-ul Popover Nu am trecut la utilizarea API-ului Popover pentru că am vrut să experimentez ceva nou. Am schimbat pentru că m-am săturat să mențin un comportament de tip tooltip pe care credeam că browserul ar fi trebuit să îl înțeleagă deja. Am fost sceptic la început. Majoritatea noilor API-uri web promit simplitate, dar necesită totuși lipici, gestionarea cazurilor marginale sau logica de rezervă care recreează în liniște aceeași complexitate de care încercați să scăpați. Deci, am încercat API-ul Popover în cel mai mic mod posibil. Iată cum arăta:
1. Tastatura „Funcționează doar” Suportul pentru tastatură depindea de alinierea corectă a mai multor straturi: focalizarea trebuia să declanșeze balonul, estomparea trebuia să-l ascundă, Esc trebuia să fie conectat manual, iar sincronizarea a contat. Dacă ați ratat o carcasă de margine, sfatul instrument fie ar rămâne deschis prea mult timp, fie ar dispărea înainte de a putea fi citit. Cu atributul popover setat la automat sau manual, browserul preia elementele de bază: Tab și Shift+Tab se comportă normal, Esc închide de fiecare dată mesajul cu instrumente și nu sunt necesari ascultători suplimentari.
Ceea ce a dispărut din baza mea de cod au fost gestionarea globală a tastelor, logica de curățare specifică Esc și verificările stării în timpul navigării cu tastatura. Experiența cu tastatura a încetat să mai fie ceva ce trebuia să o întrețin și a devenit o garanție pentru browser. 2. Predictibilitatea cititorului de ecran Acesta a fostcea mai mare îmbunătățire. Chiar și cu o muncă atentă ARIA, comportamentul a variat, așa cum am subliniat mai devreme. Fiecare mică schimbare se simțea riscantă. Folosirea unui popover cu un rol adecvat arată și se simte mult mai stabilă și previzibilă în ceea ce privește ceea ce se va întâmpla:
Și iată o altă victorie: după schimbare, Lighthouse a încetat să semnaleze avertismente incorecte de stare ARIA pentru interacțiune, în mare parte pentru că nu mai există stări ARIA personalizate pentru ca eu să greșesc accidental.
3. Managementul focusului Focalizarea era odinioară fragilă. Înainte, aveam reguli precum: lăsați declanșatorul de focalizare să arate balonul cu instrumente, mutați focalizarea în balonul cu instrumente și nu închideți, estompați declanșatorul când este prea aproape și închideți balonul cu instrumente și restabiliți focalizarea manual. Acest lucru a funcționat până când nu a funcționat. Cu API-ul Popover, browserul impune un model mai simplu în care focalizarea se poate muta mai natural în popover. Închiderea popover-ului readuce focalizarea pe declanșator și nu există capcane de focalizare invizibile sau momente de focalizare pierdute. Și nu am adăugat codul de restaurare a focalizării; l-am scos.
Concluzie API-ul Popover înseamnă că sfaturile instrumente nu mai sunt ceva ce simulați. Sunt ceva pe care browserul le înțelege. Deschiderea, închiderea, comportamentul tastaturii, manipularea Escape și o mare parte a accesibilității vin acum din platformă în sine, nu din JavaScript ad-hoc. Asta nu înseamnă că bibliotecile de indicații informative sunt învechite, deoarece încă mai au sens pentru sistemele de design complexe, personalizarea grea sau constrângerile vechi, dar implicit s-a schimbat. Pentru prima dată, cel mai simplu tooltip poate fi și cel mai corect. Dacă sunteți curios, încercați acest experiment: înlocuiți doar un sfat explicativ din produsul dvs. cu API-ul Popover, nu rescrieți totul, nu migrați un întreg sistem și alegeți unul și vedeți ce dispare din codul dvs. Când platforma vă oferă o primitivă mai bună, câștigul nu este doar mai puține linii de JavaScript, ci sunt mai puține lucruri de care trebuie să vă faceți griji. Consultați codul sursă complet în depozitul meu GitHub. Lectură suplimentară Pentru scufundări mai profunde în popover-uri și API-uri aferente:
„Poppin’ In”, Geoff Graham „Clarificarea relației dintre popovers și dialoguri”, Zell Liew „Ce este popover=hint?”, Una Kravets „Comenzile invocatorului”, Daniel Schwarz „Crearea unei notificări de închidere automată cu un popover HTML”, Preethi Deschideți UI Popover API Explainer „Pop(over) the Balloons”, John Rhea „Poziționarea ancorelor CSS”, Juan Diego Rodríguez
MDN oferă, de asemenea, documentație tehnică cuprinzătoare pentru API-ul Popover.
