En masse snak omkring ol' <details> , <summary> elementer på det seneste! jeg så Lea Verou tweetede for nylig en observation om elementets display adfærd og den slags splintrede sig i flere observationer og brugsnotater fra folk, inklusive en genoplivet diskussion Om hvorvidt <summary> skal have lov til at indeholde interaktive elementer eller ej.
Der er mange prikker at forbinde, og jeg vil gøre mit bedste her for at gøre præcis det.
Kan vi ændre visningen af elementer indlejret i <details> element?
Super mærkeligt! Hvis vi åbner DevTools, fortæller brugeragent-stilarket os <details> vises som et blokelement.
Bemærk det nødvendige <summary> element og de to yderligere <div>er derinde. Vi kan tilsidesætte display, højre?
Det, vi kan forvente, er det <details> har nu en eksplicit højde på 40vh og tre rækker, hvor den tredje række optager den resterende plads fra de to første. Sådan her:
Uh, men den tredje række gør ikke... det.
Det, vi har at gøre med, er tilsyneladende en gitterbeholder, der ikke er i stand til at anvende gitteradfærd på sine gitterelementer. Men HTML-specifikationen fortæller os:
detailselement er forventes at gengive som en blokkasse. Elementet forventes også at have en intern skygge træ med to spillemaskiner.(Fremhæv min)
Og lidt senere:
detailselementets andet slot forventes at have sinstyleattribut sat til "display: block; content-visibility: hidden;" nårdetailselement har ikke enopenattribut. Når den haropenattribut, denstyleattribut forventes at blive fjernet fra den anden slot.(Fremhæv min, igen)
Så specifikationerne siger det andet slot - de to yderligere <div>s fra eksemplet — er kun tvunget til at være blokelementer, når <details> er lukket. Når den er åben - <details open> — de skal passe til den gittervisning, der tilsidesætter brugeragentens stil... ikke?
Det er debatten. Det forstår jeg slots er indstillet til display: contents som standard, men jamming af indlejrede elementer i slots og fjernelse af muligheden for at style dem virker off. Er det et speciel problem, at indholdet er slots, eller et browserproblem, som vi ikke kan tilsidesætte deres display selvom de er i bukstræet? Smartere mennesker kan oplyse mig, men det virker som en forkert implementering.
Is <details> en beholder eller et interaktivt element?
Det er mange mennesker ved brug af <details> for at skifte mellem menuer åben og lukket. Det er en praksis populariseret af GitHub.
Virker rimeligt. Specifikationen tillader det helt sikkert:
detailselement repræsenterer en oplysningswidget, hvorfra brugeren kan få yderligere information eller kontroller.(Fremhæv min)
Okay, så det kan vi forvente <details> er beholderen (den har en implicitte role=group) og <summary> er et interaktivt element, der sætter containerens open stat. Giver mening siden <summary> har en implcit button rolle i nogle sammenhænge (men ingen tilsvarende WAI-ARIA-rolle).
Men Melanie Sumner gravede lidt der ikke kun ser ud til at modsige det, men fører til den konklusion, at brug <details> som en menu sandsynligvis ikke er den bedste ting. Se hvad der sker hvornår <details> er gengivet uden <summary> element:
Den gør præcis, hvad spec'en antyder, når den mangler en <summary> - den laver sin egen:
Den første
summaryelement underordnet af elementet, hvis nogen, repræsenterer resuméet eller forklaringen af detaljerne. Hvis der ikke er noget barnsummaryelement, skal brugeragenten give sin egen forklaring (f.eks. "Detaljer").(Fremhæv min)
Melanie kørte det gennem en HTML-validator og - overraskelse! - det er ugyldigt:
Så, <details> kræver <summary>. Og når <summary> mangler, <details> opretter sin egen, selvom den videregives som ugyldig markup. Det er alt sammen hunky-dory og gyldigt hvornår <summary> er der:
Alt dette leder til et nyt spørgsmål: hvorfor er <summary> givet en implicit button rolle hvornår <details> er det, der ser ud til at være det interaktive element? Måske er dette et andet tilfælde, hvor browserimplementeringen er forkert? Så igen kategoriserer specifikationen begge som interaktive elementer. Du kan se, hvor fuldstændig forvirrende alt dette bliver.
Uanset hvad, Melanies ultimative konklusion, som vi burde undgå at bruge <details> for menuer er baseret på, hvordan hjælpeteknologi læser og annoncerer <details> der indeholder interaktive elementer. Elementet annonceres, men der er ingen omtale af interaktive kontroller ud over det, før du, øh, interagere med <details>. Først da vil noget som en liste over links blive annonceret.
Desuden indhold inde i en kollapset <details> er udelukket fra søgning på siden (undtagen i Chromium-browsere, som kan få adgang til det kollapsede indhold i skrivende stund), hvilket gør tingene endnu sværere at finde.
Skulle <summary> tillade interaktive elementer?
Det er spørgsmålet, der stilles denne åbne tråd. Tanken er, at noget som dette ville være ugyldigt:
<details>
<summary><a href="...">Link element</a></summary>
</details>
<!-- or -->
<details>
<summary><input></summary>
</details>Scott O'Hara opsummerer fint hvorfor dette er et problem:
Linket er slet ikke synligt for JAWS, når du navigerer med dens virtuelle markør. Hvis du navigerer til opsummeringselementet via Tab-tasten, annoncerer JAWS "eksempeltekst, knap" som navnet og rollen for elementet. Hvis du trykker på Tab-tasten igen, annoncerer JAWS igen "eksempeltekst, knap", selvom tastaturfokus er på linket.
[...]
Der er mere, jeg kunne fortsætte med de forskellige problemer, som forskellige AT har med indholdsmodellen til opsummering... men det ville bare udvide denne kommentar ud over, hvad der er nødvendigt. tldr; den sammenfattende indholdsmodel producerer meget inkonsekvente og nogle gange bare flade, ødelagte oplevelser for folk, der bruger AT.
Scott åbnede billetter for at rette op på denne adfærd Chromium , WebKit. Tak, Scott!
Alligevel er det gyldig HTML:
Scott går videre i en særskilt blogindlæg. For eksempel forklarer han, hvordan du slår role=button on <summary> kan virke som en rimelig løsning for at sikre, at den konsekvent annonceres af hjælpeteknologi. Det ville også afgøre debatten om, hvorvidt <summary> bør tillade interaktive elementer, fordi knapper kan ikke indeholde interaktive elementer. Det eneste problem er, at Safari så behandler <summary> som en standardknap, som mister sin expanded , collapsed stater. Så den korrekte rolle er annonceret, men nu er dens tilstand ikke. 🙃
Hvor skal vi hen nu?
Er du bange for at bruge <details>/<summary> med alle disse problemer og uoverensstemmelser? Det er jeg bestemt, men kun for så vidt at sikre, at det, der er i det, giver brugerne den rigtige slags oplevelse og forventninger.
Jeg er bare glad for, at disse samtaler finder sted, og at de foregår i det fri. Derfor kan du kommentere Scotts tre foreslåede løsninger til, hvordan indholdsmodellen for <summary> er defineret, opstem hans billetter, og rapporter dine egne problemer og brugssager, mens du er i gang. Forhåbentlig, jo bedre vi forstår, hvordan elementerne bruges, og hvad vi forventer, at de gør, jo bedre implementeres de.
