Viel Geschwätz um den alten <details> und <summary> Elemente in letzter Zeit! ich sah Lea Verou hat kürzlich eine Beobachtung getwittert über die Elemente display Verhalten und das zersplitterte in weitere Beobachtungen und Nutzungshinweise von Leuten, darunter a wiederbelebte Diskussion auf ob <summary> interaktive Elemente enthalten dürfen oder nicht.
Es gibt viele Punkte zu verbinden und ich werde hier mein Bestes tun, um genau das zu tun.
Können wir die Anzeige von Elementen ändern, die in der verschachtelt sind <details> Element?
Super seltsam! Wenn wir DevTools knacken, teilt uns das User-Agent-Stylesheet mit <details> wird als Blockelement dargestellt.
Beachten Sie das Erforderliche <summary> Element und die beiden zusätzlichen <div>ist drin. Wir können die überschreiben display, Recht?
Was wir erwarten könnten, ist das <details> hat jetzt eine explizite Höhe von 40vh und drei Reihen, wobei die dritte Reihe den verbleibenden Platz einnimmt, der von den ersten beiden übrig geblieben ist. So was:
Ugh, aber die dritte Reihe tut … das nicht.
Anscheinend haben wir es mit einem Grid-Container zu tun, der kein Grid-Verhalten auf seine Grid-Elemente anwenden kann. Aber die HTML-Spezifikation sagt uns:
Das
detailsElement ist voraussichtlich als rendern Blockbox. Es wird auch erwartet, dass das Element ein internes hat Schattenbaum mit zwei Slots.(Hervorhebung von mir)
Und etwas später:
Das
detailszweite Element Schloß wird voraussichtlich seine habenstyleAttribut gesetzt auf „display: block; content-visibility: hidden;" wenn derdetailsElement hat keinopenAttribut. Wenn es das hatopenAttribut, dasstyleAttribut wird voraussichtlich aus dem zweiten entfernt Schloß.(Hervorhebung wieder von mir)
Die Spezifikation sagt also den zweiten Steckplatz – die zwei zusätzlichen <div>s aus dem Beispiel – werden nur dann in Blockelemente umgewandelt, wenn <details> ist geschlossen. Wenn es geöffnet ist – <details open> – Sie sollten der Rasteranzeige entsprechen, die das Design des Benutzeragenten überschreibt … richtig?
Das ist die Debatte. ich verstehe das slots Sind eingestellt auf display: contents standardmäßig, aber das Einklemmen verschachtelter Elemente in Slots und das Entfernen der Möglichkeit, sie zu stylen, scheint deaktiviert zu sein. Ist es ein Spezifikationsproblem, dass die Inhalte Slots sind, oder ein Browserproblem, das wir nicht überschreiben können? display obwohl sie im Buchsbaum sind? Klügere Leute können mich aufklären, aber es scheint eine falsche Implementierung zu sein.
Is <details> ein Container oder ein interaktives Element?
Viele Leute sind Verwendung von <details> Menüs umschalten offen und geschlossen. Es ist eine Praxis Popularisiert von GitHub.
Scheint vernünftig. Die Spezifikation erlaubt es sicher:
Das
detailsElement representiert ein Offenlegungs-Widget, von dem der Benutzer zusätzliche Informationen erhalten kann oder Kontrollen.(Hervorhebung von mir)
Okay, also könnten wir das erwarten <details> ist der Behälter (er hat eine implizit role=group) und <summary> ist ein interaktives Element, das die Container festlegt open Zustand. Macht seither Sinn <summary> hat eine implizite button Rolle in einigen Kontexten (aber keine entsprechende WAI-ARIA-Rolle).
Jedoch müssen auch Melanie Sumner hat nachgeforscht das scheint dem nicht nur zu widersprechen, sondern lässt darauf schließen, dass using <details> als Menü ist wahrscheinlich nicht das Beste. Sehen Sie, was wann passiert <details> wird ohne die gerendert <summary> Element:
Es tut genau das, was die Spezifikation vorschlägt, wenn a fehlt <summary> - es macht sich selbst:
Der Erste
summaryuntergeordnetes Element des Elements, wenn überhaupt, representiert die Zusammenfassung oder Legende der Details. Wenn kein Kind da istsummary-Element sollte der Benutzeragent eine eigene Legende bereitstellen (z. B. „Details“).(Hervorhebung von mir)
Melanie ließ das durch einen HTML-Validator laufen und – Überraschung! — es ist ungültig:
Damit <details> erfordert die <summary>. Und wann <summary> wird vermisst, <details> erstellt ein eigenes, obwohl es als ungültiges Markup weitergeleitet wird. Es ist alles bestens und gültig wann <summary> Gibt es:
All das führt zu einer neuen Frage: warum ist <summary> gegeben eine implizit button Rolle wann <details> ist das, was das interaktive Element zu sein scheint? Vielleicht ist dies ein weiterer Fall, in dem die Browserimplementierung falsch ist? Andererseits kategorisiert die Spezifikation beide als interaktive Elemente. Sie können sehen, wie äußerst verwirrend all dies wird.
Wie auch immer, Melanies ultimative Schlussfolgerung, die wir vermeiden sollten <details> für Menüs basiert darauf, wie Hilfstechnologien lesen und ankündigen <details> die interaktive Elemente enthalten. Das Element wird angekündigt, aber darüber hinausgehende interaktive Steuerelemente werden nicht erwähnt, bis Sie, äh, interagieren mit <details>. Erst dann wird so etwas wie eine Linkliste bekannt gegeben.
Außerdem ist der Inhalt in einem zusammengebrochen <details> ist von der In-Page-Suche ausgeschlossen (außer in Chromium-Browsern, die zum Zeitpunkt des Schreibens auf den minimierten Inhalt zugreifen können), was das Auffinden noch schwieriger macht.
Sollte <summary> interaktive Elemente zulassen?
Das ist die Frage, die in gestellt wird dieser offene Thread. Die Idee ist, dass so etwas ungültig wäre:
<details>
<summary><a href="...">Link element</a></summary>
</details>
<!-- or -->
<details>
<summary><input></summary>
</details>Scott O'Hara fasst schön zusammen warum das ein Problem ist:
Der Link ist überhaupt nicht für JAWS erkennbar, wenn mit seinem virtuellen Cursor navigiert wird. Wenn Sie über die Tabulatortaste zum Zusammenfassungselement navigieren, sagt JAWS „Beispieltext, Schaltfläche“ als Name und Rolle des Elements an. Wenn Sie die Tabulatortaste erneut drücken, sagt JAWS erneut „Beispieltext, Schaltfläche“ an, obwohl der Tastaturfokus auf dem Link liegt.
[...]
Ich könnte noch mehr über die verschiedenen Probleme erzählen, die verschiedene AT mit dem Inhaltsmodell für die Zusammenfassung haben … aber das würde diesen Kommentar nur über das hinausführen, was notwendig ist. tldr; Das zusammenfassende Inhaltsmodell erzeugt sehr inkonsistente und manchmal einfach nur kaputte Erfahrungen für Leute, die AT verwenden.
Scott hat Tickets eröffnet, um dieses Verhalten zu korrigieren Chrom und WebKit. Danke, Scott!
Dennoch ist es gültiges HTML:
Scott geht weiter in a separaten Blog-Post. Zum Beispiel erklärt er, wie man slappt role=button on <summary> scheint eine vernünftige Lösung zu sein, um sicherzustellen, dass sie von Hilfstechnologien konsistent angekündigt wird. Damit wäre auch die Debatte darüber erledigt, ob <summary> sollte interaktive Elemente zulassen, weil Schaltflächen dürfen keine interaktiven Elemente enthalten. Das einzige Problem ist, dass Safari das dann behandelt <summary> als Standard-Taste, die ihre verliert expanded und collapsed Zustände. Die richtige Rolle wird also angesagt, aber jetzt nicht ihr Status. 🙃
Wo gehen wir jetzt hin?
Haben Sie Angst zu benutzen <details>/<summary> mit all diesen Problemen und Ungereimtheiten? Das bin ich auf jeden Fall, aber nur insofern, um sicherzustellen, dass das, was darin enthalten ist, die richtige Art von Erfahrung und Erwartungen für die Benutzer bietet.
Ich bin nur froh, dass diese Gespräche stattfinden und dass sie offen stattfinden. Aus diesem Grund können Sie die drei von Scott vorgeschlagenen Lösungen für das Inhaltsmodell kommentieren <summary> definiert ist, stimmen Sie seinen Tickets zu und melden Sie Ihre eigenen Probleme und Anwendungsfälle, wenn Sie schon dabei sind. Je besser wir verstehen, wie die Elemente verwendet werden und was wir von ihnen erwarten, desto besser werden sie hoffentlich implementiert.
