Üksikasjad 'detailide' kohta

Palju jutuajamist vanade ümber <details> ja <summary> elemendid viimasel ajal! ma nägin Lea Verou säutsus hiljuti tähelepaneku elemendi kohta display käitumist ja seda sorti, mis jagunes inimeste tähelepanekuteks ja kasutusmärkusteks, sealhulgas a elavnenud arutelu kas <summary> peaks olema lubatud sisaldada interaktiivseid elemente või mitte.

Ühendamiseks on palju punkte ja ma annan siin endast parima, et seda täpselt teha.

Kas saame muuta pesastatud elementide kuvamist <details> element?

Ehitatavas rakenduses kasutan paneelide jaoks funktsiooni , kuid puutusin kokku veidrustega.
flexbox: https://t.co/noZvxAN35G
Võrgustik: https://t.co/pis0lPjvXk
Alguses arvasin, et see on viga, kuid kõik kolm mootorit nõustuvad. Näib, et UA stiililehel ei ole miski seda selgitavat.

- Lea Verou (@LeaVerou) August 28, 2022

Super imelik! Kui me DevToolsi lahti murrame, teatab kasutajaagendi stiilitabel meile <details> kuvatakse plokielemendina.

Pange tähele nõutavat <summary> element ja kaks täiendavat <div>s seal sees. Saame alistada display, eks?

Mida me võime oodata, on see <details> on nüüd selge kõrgusega 40vh ja kolm rida, kus kolmas rida võtab enda alla kahest esimesest järelejäänud ruumi. Nagu nii:

Oeh, aga kolmas rida ei tee… seda.

Ilmselt on meil tegemist võrgukonteineriga, mis ei suuda oma ruudustiku üksustele ruudustiku käitumist rakendada. Kuid HTML-i spetsifikatsioon ütleb meile:

. details element on eeldatavasti esitatakse kui a plokk kast. Elemendil eeldatakse ka sisemist varjupuu kahega slots.

(Rõhuasetus minu poolt)

Ja veidi hiljem:

. details elemendi teine ava eeldatavasti omab style atribuudiks on määratud "display: block; content-visibility: hidden;" kui details elemendil puudub open atribuut. Kui sellel on open atribuut, style Eeldatakse, et atribuut eemaldatakse teisest ava.

(Rõhutan veelkord minu oma)

Niisiis, spetsifikatsioonis on öeldud, et teine ​​pesa - kaks täiendavat <div>s näitest — on ainult sunnitud olema plokkelemendid, kui <details> on suletud. Kui see on avatud - <details open> — need peaksid vastama ruudustiku kuvale, mis alistab kasutajaagendi stiili… eks?

See on arutelu. ma saan sellest aru slots on seadistatud display: contents vaikimisi, kuid pesastatud elementide segamine pesadesse ja nende stiilimisvõimaluse eemaldamine tundub olevat sobimatu. Kas see on spetsifikatsiooniprobleem, et sisu on pesad, või brauseri probleem, mida me ei saa alistada display kuigi nad on pukspuus? Targemad inimesed võivad mind valgustada, kuid see tundub vale teostusena.

Is <details> konteiner või interaktiivne element?

Paljud inimesed on kasutamine <details> menüüde vahetamiseks avatud ja suletud. See on tava populariseeris GitHub.

Tundub mõistlik. Spetsifikatsioon lubab seda kindlasti:

. details element esindab avalikustamisvidin, millest kasutaja saab lisateavet või juhtnupud.

(Rõhuasetus minu poolt)

Olgu, nii et me võime seda oodata <details> on konteiner (sellel on kaudselt role=group) Ja <summary> on interaktiivne element, mis määrab konteineri open olek. Sellest alates on see mõistlik <summary> on kaudne button roll mõnes kontekstis (kuid puudub vastav WAI-ARIA roll).

Kuid Melanie Sumner kaevas veidi mis mitte ainult ei näi olevat sellega vastuolus, vaid viib järelduseni, et kasutades <details> menüüna pole ilmselt parim asi. Vaata, mis millal juhtub <details> renderdatakse ilma <summary> Element:

See teeb täpselt seda, mida spetsifikatsioon soovitab, kui see puudub a <summary> — see teeb oma:

1. summary element elemendi laps, kui mõni, esindab detailide kokkuvõte või legend. Kui last pole summary element, peaks kasutajaagent esitama oma legendi (nt „Üksikasjad”).

(Rõhuasetus minu poolt)

Melanie käis selle läbi HTML-i validaatori ja — üllatus! — see on kehtetu:

Niisiis, <details> nõuab <summary>. Ja millal <summary> on kadunud, <details> loob oma, kuigi see edastatakse kehtetu märgistusena. See kõik on äge ja kehtib siis, kui <summary> on seal:

Kõik see viib uue küsimuseni: miks on <summary> antud kaudselt button rolli, millal <details> on see, mis näib olevat interaktiivne element? Võib-olla on see veel üks juhtum, kus brauseri rakendamine on vale? Jällegi, spetsifikatsioonid liigitavad mõlemad kui interaktiivsed elemendid. Näete, kui segaseks see kõik muutub.

Mõlemal juhul on Melanie lõplik järeldus, mille kasutamist peaksime vältima <details> menüüde jaoks põhineb sellel, kuidas abitehnoloogia loeb ja teatab <details> mis sisaldavad interaktiivseid elemente. Elemendist teatatakse, kuid interaktiivsetest juhtelementidest pole juttugi, kuni te, ee, suhelda koos <details>. Alles siis tehakse teatavaks midagi linkide loendi taolist.

Pealegi varises sisu sees kokku <details> on lehesisesest otsingust välja jäetud (välja arvatud Chromiumi brauserid, mis pääsevad kirjutamise ajal ahendatud sisule juurde), muutes asjade leidmise veelgi keerulisemaks.

Peaks <summary> lubada interaktiivseid elemente?

See on küsimus, mis esitati see avatud teema. Mõte on selles, et midagi sellist oleks kehtetu:

<details>
  <summary><a href="...">Link element</a></summary>
</details>

<!-- or -->

<details>
  <summary><input></summary>
</details>

Scott O'Hara võtab ilusti kokku miks see probleem on:

JAWSi link ei ole virtuaalse kursoriga navigeerimisel üldse leitav. Kui navigate tabeldusklahvi kaudu kokkuvõtlikule elemendile, teatab JAWS elemendi nimeks ja rolliks "näidisteksti, nupu". Kui vajutate uuesti tabeldusklahvi, teatab JAWS uuesti „näidistekst, nupp”, kuigi klaviatuuri fookus on lingil.

[...]

Kokkuvõtteks võiksin jätkata erinevate probleemidega, mis erinevatel AT-l on sisumudeliga, kuid see laiendaks seda kommentaari kaugemale sellest, mis on vajalik. tldr; kokkuvõtlik sisumudel tekitab AT-d kasutavatele inimestele väga ebajärjekindlaid ja mõnikord lihtsalt katkendlikke kogemusi.

Scott avas selle käitumise parandamiseks piletid kroom ja WebKit. Aitäh, Scott!

Siiski on see kehtiv HTML:

Scott läheb kaugemale a Eraldi blogi postitus. Näiteks selgitab ta, kuidas laksu andmine role=button on <summary> võib tunduda mõistlik lahendus tagamaks, et abitehnoloogia teatab sellest järjepidevalt. See lahendaks ka arutelu selle üle, kas <summary> peaks lubama interaktiivseid elemente, sest nupud ei tohi sisaldada interaktiivseid elemente. Ainus probleem on selles, et Safari siis töötleb <summary> tavalise nupuna, mis kaotab oma expanded ja collapsed osariigid. Niisiis, õige roll on välja kuulutatud, kuid nüüd pole selle olek mitte. 🙃

Kuhu me nüüd läheme?

Kas sa kardad kasutada <details>/<summary> kõigi nende probleemide ja ebakõladega? Olen seda kindlasti, kuid ainult niivõrd, et veenduda, et see pakub kasutajatele õiget kogemust ja ootusi.

Mul on lihtsalt hea meel, et need vestlused toimuvad ja et need toimuvad avalikult. Seetõttu saate kommenteerida Scotti kolme pakutud lahendust sisumudeli jaoks <summary> on määratletud, hääletage tema pileteid ja teavitage oma probleemidest ja kasutusjuhtudest, kui olete selle juures. Loodetavasti, mida paremini me mõistame, kuidas elemente kasutatakse ja mida me neilt ootame, seda paremini neid rakendatakse.