Veliko klepeta okoli starega <details> in <summary> elementi v zadnjem času! videl sem Lea Verou je nedavno tvitnila opazko o elementih display vedenje in to nekako razcepljeno na več opažanj in opomb o uporabi ljudi, vključno z a oživela razprava o tem, ali <summary> smejo vsebovati interaktivne elemente ali ne.
Veliko je točk, ki jih je treba povezati, in dal bom vse od sebe, da naredim točno to.
Ali lahko spremenimo prikaz elementov, ugnezdenih v <details> element?
Super čudno! Če odpremo DevTools, nam to pove slogovna tabela uporabniškega agenta <details> je prikazan kot element bloka.
Upoštevajte zahtevano <summary> element in dva dodatna <div>je tam notri. Lahko preglasimo display, prav?
To lahko pričakujemo <details> zdaj ima eksplicitno višino 40vh in tri vrstice, kjer tretja vrstica zavzame preostali prostor, ki ostane od prvih dveh. Všečkaj to:
Uf, ampak tretja vrsta ne … dela … tega.
Očitno imamo opravka z mrežnim vsebnikom, ki ne more uporabiti mrežnega vedenja za svoje mrežne elemente. Toda specifikacija HTML nam pove:
O
detailselement je se pričakuje, da bo prikazan kot a blok škatla. Element naj bi imel tudi notranjo senčno drevo z dvema reže.(poudarek moj)
In malo kasneje:
O
detailsdrugi element reža se pričakuje, da bo imel svojestyleatribut nastavljen na "display: block; content-visibility: hidden;" kodetailselement nimaopenatribut. Ko imaopenatribut, thestylePričakuje se, da bo atribut odstranjen iz drugega reža.(spet moj poudarek)
Torej, specifikacija pravi drugo režo - dve dodatni <div>s iz primera — so le prisiljeni v blokovne elemente, ko <details> je zaprto. Ko je odprto - <details open> — morajo biti v skladu z mrežnim prikazom, ki preglasi slog uporabniškega agenta ... kajne?
To je razprava. Razumem slots nastavljeni na display: contents privzeto, toda zatikanje ugnezdenih elementov v reže in odstranjevanje možnosti njihovega oblikovanja se zdi napačno. Ali je težava s specifikacijami, da so vsebine reže, ali težava z brskalnikom, ki jih ne moremo preglasiti display čeprav so v škatli? Pametnejši ljudje me lahko razsvetlijo, vendar se zdi, da je to napačna izvedba.
Is <details> vsebnik ali interaktivni element?
Veliko ljudi je uporabo <details> za preklapljanje med meniji odprto in zaprto. To je praksa populariziral GitHub.
Zdi se razumno. Specifikacije to zagotovo dovoljujejo:
O
detailselement predstavlja gradnik za razkritje, iz katerega lahko uporabnik pridobi dodatne informacije ali kontrole.(poudarek moj)
V redu, to lahko pričakujemo <details> je posoda (ima implicitno role=group) in <summary> je interaktivni element, ki nastavi vsebnik open država. Smiselno je od takrat <summary> ima implicit button Vloga v nekaterih kontekstih (vendar brez ustrezne vloge WAI-ARIA).
Ampak Melanie Sumner je nekaj kopala kar se zdi ne le v nasprotju s tem, ampak vodi do zaključka, da uporaba <details> ker meni verjetno ni najboljša stvar. Poglejte, kaj se zgodi, ko <details> je upodobljeno brez <summary> Element:
Naredi natanko to, kar predlaga specifikacija, ko manjka a <summary> — naredi svoje:
1.
summarypodrejeni element elementa, če kateri, predstavlja povzetek ali legenda podrobnosti. Če ni otrokasummaryelement, mora uporabniški agent zagotoviti lastno legendo (npr. »Podrobnosti«).(poudarek moj)
Melanie je to pognala skozi validator HTML in — presenečenje! — ni veljavno:
Torej, <details> zahteva <summary>. In kdaj <summary> manjka, <details> ustvari svojo lastno, čeprav je posredovana kot neveljavna oznaka. Vse je hunky-dory in velja, ko <summary> je tam:
Vse to vodi do novega vprašanja: zakaj je <summary> podan implicit button vlogo, ko <details> je tisto, kar se zdi interaktivni element? Morda je to še en primer, ko je implementacija brskalnika napačna? Potem spet specifikacija oba kategorizira kot interaktivni elementi. Vidite lahko, kako popolnoma zmedeno postane vse to.
Kakor koli že, Melanijin končni sklep, ki bi se ga morali izogibati <details> za menije temelji na tem, kako pomožna tehnika bere in napove <details> ki vsebujejo interaktivne elemente. Element je najavljen, vendar ni omenjenih interaktivnih kontrol razen tega, dokler vi, ee, interakcijo z <details>. Šele takrat bo objavljeno nekaj podobnega seznamu povezav.
Poleg tega je vsebina znotraj zrušena <details> je izključen iz iskanja po strani (razen v brskalnikih Chromium, ki lahko dostopajo do strnjene vsebine v času pisanja), zaradi česar je stvari še težje najti.
Če bi <summary> omogočite interaktivne elemente?
To je vprašanje, postavljeno v ta odprta tema. Ideja je, da bi bilo nekaj takega neveljavno:
<details>
<summary><a href="...">Link element</a></summary>
</details>
<!-- or -->
<details>
<summary><input></summary>
</details>Scott O'Hara lepo povzame zakaj je to problem:
JAWS med navigacijo z virtualnim kazalcem sploh ne odkrije povezave. Če se do elementa povzetka pomaknete prek tipke Tab, JAWS napove »primer besedila, gumb« kot ime in vlogo elementa. Če znova pritisnete tipko Tab, JAWS ponovno napove »primer besedila, gumb«, čeprav je fokus tipkovnice na povezavi.
[...]
O različnih težavah, ki jih imajo različni AT z modelom vsebine za povzetek, bi lahko še našteval ... toda to bi samo razširilo ta komentar čez tisto, kar je potrebno. tldr; model povzetka vsebine ustvarja zelo nedosledne in včasih preprosto zlomljene izkušnje za ljudi, ki uporabljajo AT.
Scott je odprl vstopnice, da bi popravil to vedenje krom in WebKit. Hvala, Scott!
Kljub temu je veljaven HTML:
Scott gre dlje v a ločena blog post. Na primer, pojasnjuje, kako klofuta role=button on <summary> se morda zdi razumen popravek za zagotovitev, da ga podporna tehnika dosledno oznanja. To bi tudi rešilo razpravo o tem, ali <summary> bi moral omogočati interaktivne elemente, ker gumbi ne smejo vsebovati interaktivnih elementov. Edina težava je, da Safari potem zdravi <summary> kot standardni gumb, ki izgubi svojo expanded in collapsed države. Torej, pravilna vloga je napovedana, zdaj pa njeno stanje ni. 🙃
Kam gremo zdaj?
Ali se bojite uporabljati <details>/<summary> z vsemi temi težavami in nedoslednostmi? Zagotovo sem, vendar le toliko, da zagotovim, da tisto, kar je v njem, zagotavlja pravo vrsto izkušenj in pričakovanj za uporabnike.
Vesel sem, da se ti pogovori odvijajo in da potekajo na prostem. Zaradi tega lahko komentirate tri Scottove predlagane rešitve za model vsebine za <summary> je definiran, glasujte za njegove vstopnice in poročajte o svojih težavah in primerih uporabe, ko ste že pri tem. Upajmo, da bolje ko razumemo, kako se elementi uporabljajo in kaj od njih pričakujemo, bolje se izvajajo.
