Using <details> für ein Menü mag eine interessante Idee sein, aber vielleicht nichts, was man tatsächlich in der Produktion einsetzen sollte. Siehe „More Details on <details>“ für eine Erklärung.
Eines der ermächtigendsten Dinge, die du als neuer Front-End-Entwickler lernen kannst, wenn du anfängst, JavaScript zu lernen, ist Klassen zu ändern. Wenn du Klassen ändern kannst, kannst du deine CSS-Kenntnisse nutzen, um viel auf einer Seite zu steuern. Schalte eine Klasse für das eine ein, style sie auf diese Weise, schalte zu einer anderen Klasse um (oder entferne sie) und style sie auf eine andere Weise.
Aber es gibt ein HTML-Element, das ebenfalls umschaltet! <details>!
Zum Beispiel ist es definitiv der schnellste Weg, eine Akkordeon-UI zu erstellen.
Wenn man dieses auf Toggles basierende Denken erweitert, was ist ein Benutzermenü, wenn nicht ein einzelnes Akkordeon? Dasselbe gilt für Modals. Wenn wir diesen Weg gehen würden, könnten wir JavaScript für diese dynamischen Dinge optional machen. Genau das hat GitHub mit seinem Menü gemacht.
Innerhalb des <details> Elements verwendet GitHub einige Web Components (die JavaScript erfordern), um einige Bonusfunktionen zu bieten, aber diese sind für die grundlegende Menüfunktionalität nicht erforderlich. Das bedeutet, dass das Menü robust und sofort interaktiv ist, wenn die Seite gerendert wird.
Mu-An Chiou, ein Web-Systems-Ingenieur bei GitHub, der dies vorangetrieben hat, hat eine Präsentation dazu!
<details> ist seine Browserunterstützung in Edge, aber ich schätze, wir müssen uns bald keine Sorgen mehr darüber machen, da Edge Chromium verwenden wird… bald? Weiß jemand das?
Ich bin mir semantisch nicht sicher, ob das eine gute Idee ist.
Wie auch immer, wir können Skripte durch die Verwendung von CSS focus-within aufgeben
Ich hatte diese Frage bezüglich der Semantik auch. Obwohl das W3C ein Beispiel liefert, das besagt, dass
<details>verwendet werden kann, um „einige Steuerelemente standardmäßig auszublenden“, bin ich mir nicht sicher, ob das Dropdown-Menüs beschreibt.Es ist möglich, ein Menü auf eine Weise zu betrachten, die sein Verhalten mit der Semantik eines
<details>-Tags in Einklang bringt. Zum Beispiel zeigt ein Benutzermenü, wenn es erweitert wird, mehr „detaillierte“ Optionen für Benutzeraktionen. Andererseits ist das Benutzermenü, wenn es nicht erweitert ist, wertlos, da man damit nicht interagieren kann, während ein Element, das mehr Details über sich selbst anzeigt, nützlich in seiner zusammengefassten Form sein sollte.An welchem Punkt diese Art der Nutzung in den Missbrauch von Semantik übergeht, ist eine gute Frage, wenn man bedenkt, wie oft Barrierefreiheitsanwälte gegen den Missbrauch von sogar ähnlichen Tags wie
<em>und<i>sprechen.Mein ursprünglicher Kommentar enthielt ein Markup-Beispiel, aber es wurde bereinigt…
Das Zuweisen einer Menürolle zum Summary-Element wäre ein Verstoß gegen die ARIA-Autorenrichtlinien, HTML-Semantiken nicht zu widersprechen.
Obwohl das Spielen mit dieser Option mich wundert https://codepen.io/WW3/pen/pYqRgq?editors=1100
Ähnlich wie der Checkbox-Hack ist dies, obwohl nicht die beste Methode, eine einfache und robuste Möglichkeit, eine einfache Funktion zu realisieren [die längst nativ in HTML hätte gelöst werden müssen], so dass Entwickler sie als Möglichkeit verwenden werden, Menüs und andere Inhalte umzuschalten.
Während JS üblicherweise aktiviert ist, sind für die Fälle, in denen dies nicht der Fall ist, CSS und native Funktionen wie diese die Fallbacks, die immer noch funktionieren. Und das ist der wichtige Punkt hier – dem Benutzer Funktionalität zu bieten, auch wenn die Gesamtfunktionen… eingeschränkt sind.
Ich stimme der Verwendung von focus-within zu – ich habe das auch kürzlich untersucht und es könnte eine praktikable Alternative zu „Hacks“ sein. Zweifellos wird sich etwas anderes auftun, um diesen Ansatz zu verderben!
Vor 18 Monaten wurde
<details><summary>in https://inclusive-components.design/collapsible-sections/ noch nicht einmal erwähnt.Es scheint jedoch, dass die Browser-/Screenreader-Unterstützung viel besser geworden ist.
– https://www.hassellinclusion.com/blog/accessible-accordions-part-2-using-details-summary/
– https://www.scottohara.me/blog/2018/09/03/details-and-summary.html