Veel geklets rond de oude <details> en <summary> elementen de laatste tijd! ik zag Lea Verou heeft onlangs een observatie getweet over het element display gedrag en dat versplinterde zo'n beetje in meer observaties en gebruiksnotities van mensen, waaronder een nieuw leven ingeblazen discussie op of <summary> al dan niet interactieve elementen mogen bevatten.
Er zijn veel punten om met elkaar te verbinden en ik zal hier mijn best doen om precies dat te doen.
Kunnen we de weergave van elementen die zijn genest in de <details> element?
Super raar! Als we DevTools openbreken, vertelt de stylesheet van de user-agent ons: <details> wordt weergegeven als een blokelement.
Let op de vereiste <summary> element en de twee extra <div>zit erin. We kunnen de displaytoch?
Wat we zouden kunnen verwachten is dat <details> heeft nu een expliciete hoogte van 40vh en drie rijen waarbij de derde rij de resterende ruimte van de eerste twee in beslag neemt. Soortgelijk:
Ugh, maar de derde rij doet dat niet.
Blijkbaar hebben we te maken met een rastercontainer die geen rastergedrag kan toepassen op zijn rasteritems. Maar de HTML-specificatie vertelt ons:
De
detailsonderdeel is verwacht te renderen als a blokdoos. Van het element wordt ook verwacht dat het een interne schaduwboom met twee speelautomaten.(benadruk de mijne)
En even later:
De
detailstweede element sleuf zal naar verwachting zijnstyleattribuut ingesteld op "display: block; content-visibility: hidden;" wanneer dedetailselement heeft geenopenattribuut. Wanneer het de . heeftopenattribuut, destyleattribuut zal naar verwachting worden verwijderd uit de tweede sleuf.(Benadruk de mijne, nogmaals)
Dus de specificatie zegt het tweede slot - de twee extra <div>s uit het voorbeeld — worden alleen gedwongen om blokelementen te zijn wanneer <details> is gesloten. Als het open is — <details open> - ze moeten voldoen aan de rasterweergave die de styling van de user-agent overschrijft ... toch?
Dat is het debat. ik snap het slots zijn ingesteld op display: contents bij verstek, maar het blokkeren van geneste elementen in slots en het verwijderen van de mogelijkheid om ze te stylen lijkt onzinnig. Is het een specificatieprobleem dat de inhoud slots zijn, of een browserprobleem dat we niet kunnen negeren? display ook al zitten ze in de buxus? Slimmere mensen kunnen me informeren, maar het lijkt een onjuiste implementatie.
Is <details> een container of een interactief element?
Veel mensen zijn gebruik <details> om tussen menu's te schakelen geopend en gesloten. Het is een oefening gepopulariseerd door GitHub.
Lijkt redelijk. De specificatie staat het zeker toe:
De
detailselement vertegenwoordigt een openbaarmakingswidget waaruit de gebruiker aanvullende informatie kan krijgen of controles.(benadruk de mijne)
Oké, dus dat kunnen we verwachten <details> is de container (het heeft een stilzwijgend role=group) en <summary> is een interactief element dat de container open staat. Logisch sinds <summary> heeft een impliciete button rol in sommige contexten (maar geen overeenkomstige WAI-ARIA-rol).
Maar Melanie Sumner heeft wat gegraven dat lijkt dat niet alleen tegen te spreken, maar leidt ook tot de conclusie dat het gebruik van <details> omdat een menu waarschijnlijk niet het beste is. Kijk wat er gebeurt wanneer <details> wordt weergegeven zonder de <summary> element:
Het doet precies wat de specificatie suggereert als het een mist <summary> - het maakt zijn eigen:
De eerste
summaryelement kind van het element, Eventuele, vertegenwoordigt de samenvatting of legenda van de details. Als er geen kind issummaryelement, moet de user agent zijn eigen legenda geven (bijv. “Details”).(benadruk de mijne)
Melanie haalde dat door een HTML-validator en - verrassing! — het is ongeldig:
Dus, <details> vereist de <summary>. En wanneer <summary> ontbreekt, <details> maakt zijn eigen, hoewel het wordt doorgegeven als ongeldige opmaak. Het is allemaal hunky-dory en geldig wanneer <summary> is daar:
Dit alles leidt tot een nieuwe vraag: waarom is <summary> gegeven een impliciete button rol wanneer <details> is wat lijkt op het interactieve element? Misschien is dit een ander geval waarin de browserimplementatie onjuist is? Aan de andere kant categoriseert de specificatie beide als interactieve elementen. Je kunt zien hoe volkomen verwarrend dit alles wordt.
Hoe dan ook, Melanies uiteindelijke conclusie die we moeten vermijden om te gebruiken <details> voor menu's is gebaseerd op hoe ondersteunende technologie leest en aankondigt <details> die interactieve elementen bevatten. Het element is aangekondigd, maar er is geen melding gemaakt van interactieve bedieningselementen totdat u, eh, interactie Met <details>. Alleen dan wordt zoiets als een lijst met links aangekondigd.
Trouwens, inhoud in een samengevouwen <details> is uitgesloten van zoeken op de pagina (behalve in Chromium-browsers, die toegang hebben tot de samengevouwen inhoud op het moment van schrijven), waardoor dingen nog moeilijker te vinden zijn.
Moeten <summary> interactieve elementen toestaan?
Dat is de vraag die wordt gesteld in deze open draad. Het idee is dat zoiets als dit ongeldig zou zijn:
<details>
<summary><a href="...">Link element</a></summary>
</details>
<!-- or -->
<details>
<summary><input></summary>
</details>Scott O'Hara vat het mooi samen waarom is dit een probleem?:
De link is helemaal niet vindbaar naar JAWS bij het navigeren met zijn virtuele cursor. Als u met de Tab-toets naar het samenvattingselement navigeert, kondigt JAWS "voorbeeldtekst, knop" aan als de naam en rol van het element. Als u nogmaals op de Tab-toets drukt, kondigt JAWS opnieuw "voorbeeldtekst, knop" aan, ook al ligt de toetsenbordfocus op de link.
[...]
Er is meer waar ik het over zou kunnen hebben over de verschillende problemen die verschillende AT heeft met het inhoudsmodel voor een samenvatting... tldr; het samenvattende inhoudsmodel levert zeer inconsistente en soms ronduit gebroken ervaringen op voor mensen die AT gebruiken.
Scott opende tickets om dit gedrag te corrigeren in Chromium en WebKit. Bedankt, Scott!
Toch is het geldige HTML:
Scott gaat verder in een aparte blog post. Zo legt hij uit hoe slapping role=button on <summary> lijkt misschien een redelijke oplossing om ervoor te zorgen dat het consequent wordt aangekondigd door ondersteunende technologie. Dat zou ook het debat over de vraag of <summary> interactieve elementen moeten toestaan omdat: knoppen mogen geen interactieve elementen bevatten. Het enige probleem is dat Safari dan behandelt <summary> als een standaardknop, die zijn . verliest expanded en collapsed staten. Dus de juiste rol is aangekondigd, maar nu is de status dat niet.
Waar gaan we nu heen?
Ben je bang om te gebruiken? <details>/<summary> met al deze problemen en inconsistenties? Dat ben ik zeker, maar alleen om ervoor te zorgen dat wat erin zit, gebruikers de juiste ervaring en verwachtingen biedt.
Ik ben gewoon blij dat deze gesprekken plaatsvinden en dat ze in het openbaar plaatsvinden. Daarom kunt u commentaar geven op de drie voorgestelde oplossingen van Scott voor hoe het inhoudsmodel voor <summary> is gedefinieerd, stemt u op zijn tickets en meldt u uw eigen problemen en use-cases terwijl u toch bezig bent. Hopelijk, hoe beter we begrijpen hoe de elementen worden gebruikt en wat we verwachten dat ze doen, hoe beter ze worden geïmplementeerd.
