Multă vorbărie în jurul vechiului <details> și <summary> elemente în ultima vreme! am văzut Lea Verou a postat recent o observație despre elementul display comportament și care s-au împărțit în mai multe observații și note de utilizare de la oameni, inclusiv a discuție reînviată dacă <summary> ar trebui să fie permis să conțină sau nu elemente interactive.
Există o mulțime de puncte de conectat și voi face tot posibilul aici pentru a face exact asta.
Putem schimba afișarea elementelor imbricate în <details> element?
Super ciudat! Dacă deschidem DevTools, ne spune foaia de stil a agentului utilizator <details> este afișat ca element de bloc.
Observați necesarul <summary> element și cele două suplimentare <div>e acolo. Putem trece peste display, dreapta?
La ce ne-am putea aștepta este asta <details> acum are o înălțime explicită de 40vh și trei rânduri în care al treilea rând ocupă spațiul rămas din primele două. Ca aceasta:
Uf, dar al treilea rând nu... face... asta.
Aparent, avem de-a face cu un container de grilă care nu poate aplica un comportament de grilă elementelor sale de grilă. Dar specificația HTML ne spune:
detailselementul este de așteptat să redea ca a cutie bloc. Elementul este de asemenea de așteptat să aibă un interior arbore de umbră cu doi sloturi.(sublinierea mea)
Și puțin mai târziu:
detailsal doilea element slot se așteaptă să-l aibăstyleatribut setat la „display: block; content-visibility: hidden;" canddetailselementul nu are unopenatribut. Când areopenatributul, celstyleeste de așteptat să fie eliminat din al doilea slot.(Sublinierea mea, din nou)
Deci, specificația spune al doilea slot - cele două suplimentare <div>s din exemplu — sunt constrânși să fie elemente bloc numai atunci când <details> este închis. Când este deschis - <details open> — ar trebui să se conformeze cu afișarea grilei care suprascrie stilul agentului utilizator... nu?
Asta e dezbaterea. Am înțeles slots sunt setate la display: contents în mod implicit, dar blocarea elementelor imbricate în sloturi și eliminarea capacității de a le modela pare dezamăgită. Este o problemă de specificație că conținutul este sloturi sau o problemă de browser pe care nu le putem suprascrie display chiar dacă sunt în copac? Oamenii mai inteligenți mă pot lumina, dar mi se pare o implementare incorectă.
Is <details> un container sau un element interactiv?
Mulți oameni sunt folosind <details> pentru a comuta între meniuri deschis si inchis. Este o practică popularizat de GitHub.
Pare rezonabil. Specificația permite sigur:
detailselement reprezintă un widget de dezvăluire de la care utilizatorul poate obține informații suplimentare sau controale.(sublinierea mea)
Bine, așa că ne-am putea aștepta la asta <details> este containerul (are un implicit role=group) Şi <summary> este un element interactiv care stabilește containerul open stat. Are sens de atunci <summary> are un implcit button rol în unele contexte (dar niciun rol WAI-ARIA corespunzător).
dar Melanie Sumner a făcut câteva săpături care nu numai că pare să contrazică asta, dar duce la concluzia că folosirea <details> ca un meniu probabil nu este cel mai bun lucru. Vezi ce se întâmplă când <details> este redat fără <summary> element:
Face exact ceea ce sugerează specificațiile atunci când lipsește un <summary> - isi face singur:
Prima
summaryelementul copil al elementului, dacă este cazul, reprezintă rezumatul sau legenda detaliilor. Dacă nu există copilsummaryelement, agentul utilizator ar trebui să furnizeze propria sa legendă (de exemplu, „Detalii”).(sublinierea mea)
Melanie a rulat asta printr-un validator HTML și - surpriză! - este invalid:
Asa de, <details> necesită <summary>. Și atunci când <summary> lipseste, <details> își creează propriul, deși este transmis ca markup nevalid. Totul este curioasă și valabil când <summary> este acolo:
Toate acestea conduc la o nouă întrebare: de ce este <summary> dat un implcit button rol când <details> este ceea ce pare a fi elementul interactiv? Poate că acesta este un alt caz în care implementarea browserului este incorectă? Apoi, din nou, specificațiile le clasifică pe ambele ca elemente interactive. Puteți vedea cât de extrem de confuze devin toate acestea.
Oricum, concluzia finală a Melaniei că ar trebui să evităm să folosim <details> pentru meniuri se bazează pe modul în care tehnologia de asistență citește și anunță <details> care conțin elemente interactive. Elementul este anunțat, dar nu se menționează controalele interactive dincolo de asta până când tu, eh, interacţiona cu <details>. Abia atunci se va anunța ceva de genul unei liste de link-uri.
În plus, conținutul din interiorul unui s-a prăbușit <details> este exclusă de la căutarea în pagină (cu excepția browserelor Chromium, care pot accesa conținutul restrâns în momentul scrierii), ceea ce face lucrurile și mai dificil de găsit.
Să <summary> permite elemente interactive?
Asta este întrebarea pusă în acest fir deschis. Ideea este că ceva de genul acesta ar fi invalid:
<details>
<summary><a href="...">Link element</a></summary>
</details>
<!-- or -->
<details>
<summary><input></summary>
</details>Scott O'Hara rezumă frumos de ce aceasta este o problemă:
Linkul nu poate fi descoperit deloc către JAWS când navighează cu cursorul virtual. Dacă navigați la elementul rezumat prin tasta Tab, JAWS anunță „text exemplu, buton” ca nume și rolul elementului. Dacă apăsați din nou tasta Tab, JAWS anunță din nou „text exemplu, buton”, chiar dacă tastatura se concentrează pe link.
[...]
Sunt mai multe despre care aș putea continua cu diferitele probleme pe care le au diferite AT cu modelul de conținut pentru rezumat... dar asta ar extinde acest comentariu dincolo de ceea ce este necesar. tldr; modelul de conținut rezumat produce experiențe foarte inconsecvente și, uneori, pur și simplu stricate pentru persoanele care folosesc AT.
Scott a deschis bilete pentru a corecta acest comportament în Crom și WebKit. Mulțumesc, Scott!
Cu toate acestea, este HTML valid:
Scott merge mai departe într-un postare separată pe blog. De exemplu, el explică cum se plesnește role=button on <summary> ar putea părea o soluție rezonabilă pentru a se asigura că este anunțată în mod constant de tehnologia de asistență. Asta ar rezolva și dezbaterea dacă <summary> ar trebui să permită elemente interactive deoarece butoanele nu pot conține elemente interactive. Singura problemă este că Safari tratează apoi <summary> ca buton standard, care își pierde expanded și collapsed state. Deci, rolul corect este anunțat, dar acum starea lui nu este. 🙃
Unde mergem acum?
Ți-e frică să folosești <details>/<summary> cu toate aceste probleme și inconsecvențe? Sunt sigur, dar numai în măsura în care mă asigur că ceea ce este în el oferă experiența și așteptările potrivite pentru utilizatori.
Mă bucur doar că aceste conversații au loc și că au loc în aer liber. Din acest motiv, puteți comenta cele trei soluții propuse de Scott pentru modul în care modelul de conținut <summary> este definit, votați-i tichetele și raportați-vă propriile probleme și cazuri de utilizare în timp ce sunteți la asta. Sperăm că, cu cât înțelegem mai bine cum sunt utilizate elementele și ce ne așteptăm să facă, cu atât mai bine sunt implementate.
