Mer information om `detaljer`

Mycket prat runt ol' <details> och <summary> element på sistone! jag såg Lea Verou twittrade nyligen en observation om elementets display beteende och det splittrades upp i fler observationer och användningsanteckningar från folk, inklusive en återupplivad diskussion om huruvida <summary> bör tillåtas innehålla interaktiva element eller inte.

Det finns många prickar att koppla ihop och jag ska göra mitt bästa här för att göra just det.

Kan vi ändra visningen av element kapslade i <details> element?

I appen jag bygger använder jag för paneler men stötte på lite konstiga storlekar.
flexbox: https://t.co/noZvxAN35G
Rutnät: https://t.co/pis0lPjvXk
Först trodde jag att det var en bugg, men alla tre motorerna håller med. Inget i UA-formatmallen för verkar förklara det.

— Lea Verou (@LeaVerou) Augusti 28, 2022

Super konstigt! Om vi ​​öppnar DevTools, berättar användaragentens stilark för oss <details> visas som ett blockelement.

Lägg märke till det nödvändiga <summary> element och de två ytterligare <div>är där inne. Vi kan åsidosätta display, höger?

Vad vi kan förvänta oss är det <details> har nu en explicit höjd på 40vh och tre rader där den tredje raden tar upp resterande utrymme från de två första. Så här:

Usch, men den tredje raden gör inte... det.

Det vi har att göra med är tydligen en rutnätsbehållare som inte kan tillämpa rutnätbeteende på sina rutnätsobjekt. Men HTML-specifikationen säger oss:

Smakämnen details element är förväntas återge som en blocklåda. Elementet förväntas också ha en inre skuggträd med två spelautomater.

(Betonar min)

Och lite senare:

Smakämnen details elementets andra slits förväntas ha sin style attribut satt till "display: block; content-visibility: hidden;" när details element har inte en open attribut. När den har open attribut, den style attribut förväntas tas bort från det andra slits.

(Betoning min, igen)

Så specen säger att den andra luckan - de två extra <div>s från exemplet — tvingas bara till att vara blockelement när <details> Stängt. När det är öppet - <details open> — de bör överensstämma med rutnätsvisningen som åsidosätter användaragentens stil... eller hur?

Det är debatten. jag förstår det slots är inställda på display: contents som standard, men att blockera kapslade element i platser och ta bort möjligheten att styla dem verkar avstängt. Är det ett specifika problem att innehållet är slots, eller ett webbläsarproblem som vi inte kan åsidosätta deras display trots att de är i buxträdet? Smartare människor kan upplysa mig men det verkar vara en felaktig implementering.

Is <details> en behållare eller ett interaktivt element?

Många människor är det med hjälp av <details> för att växla menyer öppen och stängd. Det är en praxis populariserad av GitHub.

Verkar rimligt. Specifikationen tillåter det:

Smakämnen details elementet representerar en avslöjande widget från vilken användaren kan få ytterligare information eller kontroller.

(Betonar min)

Okej, så vi kan förvänta oss det <details> är behållaren (den har en implicita role=group) Och <summary> är ett interaktivt element som ställer in behållarens open stat. Vettigt sedan <summary> har en implcit button roll i vissa sammanhang (men ingen motsvarande WAI-ARIA-roll).

Men Melanie Sumner grävde lite som inte bara verkar motsäga det, utan leder till slutsatsen att använda <details> eftersom en meny förmodligen inte är det bästa. Se vad som händer när <details> återges utan <summary> element:

Den gör precis vad specen antyder när den saknar en <summary> — den gör sin egen:

Den första summary element barn till elementet, Eventuella, representerar sammanfattningen eller förklaringen av detaljerna. Om det inte finns något barn summary element, bör användaragenten tillhandahålla sin egen förklaring (t.ex. "Detaljer").

(Betonar min)

Melanie körde det genom en HTML-validator och — överraskning! – det är ogiltigt:

Så, <details> kräver <summary>. Och när <summary> saknas, <details> skapar sin egen, även om den vidarebefordras som ogiltig uppmärkning. Det är allt hunky-dory och giltigt när <summary> finns det:

Allt detta leder till en ny fråga: varför är <summary> gett en implcit button roll när <details> är det som verkar vara det interaktiva elementet? Kanske är detta ett annat fall där webbläsarens implementering är felaktig? Återigen, specen kategoriserar båda som interaktiva element. Du kan se hur förvirrande allt detta blir.

Hur som helst, Melanies slutsats som vi borde undvika att använda <details> för menyer är baserad på hur hjälpmedel läser och tillkännager <details> som innehåller interaktiva element. Elementet tillkännages, men det nämns inte om interaktiva kontroller utöver det förrän du, eh, interagera med <details>. Först då kommer något som en lista med länkar att tillkännages.

Dessutom innehåll i en kollapsad <details> är utesluten från sökning på sidan (förutom i Chromium-webbläsare, som kan komma åt det komprimerade innehållet i skrivande stund), vilket gör det ännu svårare att hitta.

Om <summary> tillåta interaktiva element?

Det är frågan som ställs denna öppna tråd. Tanken är att något sådant här skulle vara ogiltigt:

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

<!-- or -->

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

Scott O'Hara sammanfattar fint varför detta är ett problem:

Länken är inte alls upptäckbar för JAWS när man navigerar med sin virtuella markör. Om du navigerar till sammanfattningselementet via Tab-tangenten, tillkännager JAWS "exempeltext, knapp" som namn och roll för elementet. Om du trycker på Tab-tangenten igen, tillkännager JAWS igen "exempeltext, knapp" även om tangentbordets fokus är på länken.

[...]

Det finns mer jag skulle kunna fortsätta om med de olika problem som olika AT har med innehållsmodellen för sammanfattning... men det skulle bara utöka denna kommentar utöver vad som är nödvändigt. tldr; sammanfattningsinnehållsmodellen producerar mycket inkonsekventa och ibland helt enkelt trasiga upplevelser för personer som använder AT.

Scott öppnade biljetter för att rätta till detta beteende krom och WebKit. Tack, Scott!

Ändå är det giltig HTML:

Scott går längre i en separat blogginlägg. Han förklarar till exempel hur smällande role=button on <summary> kan verka som en rimlig lösning för att säkerställa att det konsekvent meddelas av hjälpmedelstekniker. Det skulle också lösa diskussionen om huruvida <summary> bör tillåta interaktiva element eftersom knappar kan inte innehålla interaktiva element. Det enda problemet är att Safari då behandlar <summary> som en standardknapp, som förlorar sin expanded och collapsed stater. Så den korrekta rollen tillkännages, men nu är det inte dess tillstånd. 🙃

Vart går vi nu?

Är du rädd för att använda <details>/<summary> med alla dessa problem och inkonsekvenser? Det är jag säkert, men bara i den mån det är för att se till att det som finns i det ger rätt sorts upplevelse och förväntningar för användarna.

Jag är bara glad att dessa samtal sker och att de äger rum i det fria. På grund av det kan du kommentera Scotts tre föreslagna lösningar för hur innehållsmodellen för <summary> är definierad, rösta upp hans biljetter och rapportera dina egna problem och användningsfall medan du håller på. Förhoppningsvis, ju bättre vi förstår hur elementen används och vad vi förväntar oss att de ska göra, desto bättre implementeras de.