Tarkemmat tiedot kohdasta "yksityiskohdat".

Paljon puhetta vanhan ajan ympärillä <details> ja <summary> elementtejä viime aikoina! minä näin Lea Verou twiittasi hiljattain havainnon elementistä display käyttäytyminen ja se jakautui useammiksi havainnoksi ja käyttöhuomautuksiksi ihmisiltä, ​​mukaan lukien a herätti keskustelua kumman <summary> pitäisi sisältää interaktiivisia elementtejä vai ei.

Yhdistettäviä pisteitä on paljon, ja teen parhaani tehdäkseni juuri sen.

Voimmeko muuttaa sisäkkäisten elementtien näyttöä <details> elementti?

Käytän rakentamassani sovelluksessa paneeleille, mutta törmäsin joihinkin koon omituisuuksiin.
flexbox: https://t.co/noZvxAN35G
Ruudukko: https://t.co/pis0lPjvXk
Aluksi luulin sen olevan vika, mutta kaikki kolme moottoria ovat samaa mieltä. Ei mitään UA-tyylitaulukossa kohteelle näyttää selittävän sen.

- Lea Verou (@LeaVerou) Elokuu 28, 2022

Super outoa! Jos avaamme DevToolsin, käyttäjäagentin tyylitaulukko kertoo meille <details> näkyy lohkoelementtinä.

Huomaa vaadittu <summary> elementti ja kaksi ylimääräistä <div>s siellä. Voimme ohittaa display, eikö?

Sitä voimme odottaa <details> on nyt selkeä korkeus 40vh ja kolme riviä, joissa kolmas rivi vie kahdesta ensimmäisestä jäljellä olevan tilan. Kuten tämä:

Voi, mutta kolmas rivi ei… tee… sitä.

Ilmeisesti kyseessä on ruudukkosäilö, joka ei pysty soveltamaan ruudukkokäyttäytymistä ruudukkokohteisiinsa. Mutta HTML-spesifikaatio kertoo meille:

- details elementti on odotetaan olevan a lohkolaatikko. Elementillä odotetaan olevan myös sisäinen varjopuu kahdella lähtö.

(korostus minun)

Ja vähän myöhemmin:

- details elementin toinen aukko odotetaan saavan sen style määritteeksi asetettu "display: block; content-visibility: hidden;" kun details elementillä ei ole open määrite. Kun sillä on open attribuutti, style attribuutin odotetaan poistuvan toisesta aukko.

(Korostus minun, jälleen)

Joten tekniset tiedot sanovat toisen paikan - kaksi ylimääräistä <div>s esimerkistä - pakotetaan vain lohkoelementeiksi, kun <details> on suljettu. Kun se on auki - <details open> — niiden pitäisi mukautua ruudukon näyttöön, joka ohittaa käyttäjäagentin tyylin… eikö niin?

Se on keskustelu. Ymmärrän tuon slots asetetaan display: contents oletuksena, mutta sisäkkäisten elementtien häiritseminen paikkoihin ja niiden tyylin poistaminen näyttää epätodelliselta. Onko se tekninen ongelma, että sisältö on slotteja, vai selainongelma, jota emme voi ohittaa display vaikka ne ovatkin pussapuussa? Älykkäät ihmiset voivat valistaa minua, mutta se näyttää väärältä toteutukselta.

Is <details> kontti vai interaktiivinen elementti?

Monet ihmiset ovat käyttämällä <details> vaihtaaksesi valikkoja auki ja kiinni. Se on käytäntö suosituksi GitHub.

Vaikuttaa järkevältä. Tekniset tiedot sallivat sen:

- details elementti edustaa ilmoituswidget, josta käyttäjä voi saada lisätietoja tai ohjaimia.

(korostus minun)

Selvä, voimme odottaa sitä <details> on kontti (sillä on implisiittinen role=group) Ja <summary> on interaktiivinen elementti, joka määrittää säilön open osavaltio. Siitä lähtien järkevää <summary> on implisiittistä button rooli joissakin yhteyksissä (mutta ei vastaavaa WAI-ARIA-roolia).

Mutta Melanie Sumner kaivoi joka ei vain näytä olevan ristiriidassa sen kanssa, vaan johtaa johtopäätökseen, että käyttämällä <details> menu ei ehkä ole paras asia. Katso mitä tapahtuu milloin <details> on tehty ilman <summary> elementti:

Se tekee täsmälleen mitä speksit ehdottavat, kun se puuttuu a <summary> - se tekee oman:

Ensimmäinen summary elementti elementin lapsi, jos, edustaa yhteenveto tai selitys yksityiskohdista. Jos ei ole lasta summary elementtiä, käyttäjäagentin tulee tarjota oma selitteensä (esim. "Tiedot").

(korostus minun)

Melanie suoritti sen HTML-validaattorin läpi ja - yllätys! - se on virheellinen:

Niin, <details> vaatii <summary>. Ja milloin <summary> puuttuu, <details> luo oman, vaikka se välitetään virheellisenä merkintänä. Kaikki on jännää ja voimassa silloin, kun <summary> onko siellä:

Kaikki tämä johtaa uuteen kysymykseen: miksi on <summary> annettu implisiitti button rooli milloin <details> onko se mikä näyttää olevan interaktiivinen elementti? Ehkä tämä on toinen tapaus, jossa selaimen toteutus on virheellinen? Sitten taas tekniset luokittelevat molemmat interaktiivisia elementtejä. Voit nähdä kuinka hämmentävää tästä kaikesta tulee.

Joka tapauksessa Melanien lopullinen johtopäätös, jota meidän pitäisi välttää <details> valikoissa perustuu siihen, miten avustava tekniikka lukee ja ilmoittaa <details> jotka sisältävät interaktiivisia elementtejä. Elementistä ilmoitetaan, mutta interaktiivisista ohjaimista ei mainita sen lisäksi ennen kuin sinä olla vuorovaikutuksessa with <details>. Vasta sitten julkistetaan jotain linkkiluettelon kaltaista.

Lisäksi sisältö romahti <details> on jätetty pois sivun sisäisestä hausta (paitsi Chromium-selaimissa, jotka voivat käyttää kutistettua sisältöä kirjoitettaessa), mikä tekee asioiden löytämisestä entistä vaikeampaa.

Pitäisi <summary> sallia interaktiiviset elementit?

Siinä se kysymys esitettiin tämä avoin ketju. Ajatuksena on, että jokin tällainen olisi virheellinen:

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

<!-- or -->

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

Scott O'Hara tiivistää hienosti miksi tämä on ongelma:

Linkki ei ole havaittavissa ollenkaan JAWS:iin navigoitaessa sen virtuaalisen kursorin avulla. Jos navigoidaan yhteenvetoelementtiin Tab-näppäimellä, JAWS ilmoittaa elementin nimeksi ja rooliksi "esimerkkiteksti, painike". Jos painat Tab-näppäintä uudelleen, JAWS ilmoittaa jälleen "esimerkkiteksti, painike", vaikka näppäimistön kohdistus on linkissä.

[...]

Voisin kertoa enemmänkin niistä erilaisista ongelmista, joita eri AT:llä on sisältömallin kanssa yhteenvetona… mutta se vain laajentaisi tätä kommenttia tarpeettoman pidemmälle. tldr; tiivistelmäsisältömalli tuottaa erittäin epäjohdonmukaisia ​​ja joskus vain rikkinäisiä kokemuksia AT:tä käyttäville ihmisille.

Scott avasi liput korjatakseen tämän käyttäytymisen Kromi ja WebKit. Kiitos Scott!

Silti se on kelvollinen HTML:

Scott menee pidemmälle a erillinen blogi. Hän esimerkiksi selittää kuinka läimäyttää role=button on <summary> saattaa tuntua järkevältä korjaukselta varmistaakseen, että avustava tekniikka ilmoittaa siitä johdonmukaisesti. Tämä ratkaisisi myös keskustelun siitä, onko <summary> pitäisi sallia interaktiiviset elementit, koska painikkeet eivät saa sisältää interaktiivisia elementtejä. Ainoa ongelma on, että Safari sitten käsittelee <summary> tavallisena painikkeena, joka menettää sen expanded ja collapsed valtioita. Joten oikea rooli on ilmoitettu, mutta nyt sen tila ei ole. 🙃

Minne me menemme nyt?

Pelkäätkö käyttää <details>/<summary> kaikkien näiden ongelmien ja epäjohdonmukaisuuksien kanssa? Varmasti olen, mutta vain siltä osin kuin varmistetaan, että sen sisältö tarjoaa käyttäjille oikeanlaisen kokemuksen ja odotukset.

Olen vain iloinen, että näitä keskusteluja tapahtuu ja että ne tapahtuvat avoimesti. Tästä syystä voit kommentoida Scottin kolmea ehdottamaa ratkaisua sisällön mallinnukseen <summary> on määritelty, äänestä hänen lippujaan ja raportoi omista ongelmistasi ja käyttötapauksistasi. Toivottavasti mitä paremmin ymmärrämme, miten elementtejä käytetään ja mitä odotamme niiden tekevän, sitä paremmin ne toteutetaan.