Mehr Details zu `details`

In letzter Zeit gibt es viel Gerede über die ol’ <details> und <summary> Elemente! Ich habe gesehen, wie Lea Verou kürzlich eine Beobachtung getwittert hat über das display-Verhalten des Elements, und das spaltete sich in weitere Beobachtungen und Nutzungshinweise von Leuten, einschließlich einer wiederbelebten Diskussion darüber, ob <summary> interaktive Elemente enthalten darf oder nicht.

Es gibt viele Punkte, die verbunden werden müssen, und ich werde mein Bestes tun, um genau das zu tun.

Können wir die Anzeige von Elementen ändern, die in das <details>-Element verschachtelt sind?

In der App, die ich baue, verwende ich <details> für Panels, stieß aber auf einige seltsame Größenprobleme.
Flexbox: https://#/noZvxAN35G
Grid: https://#/pis0lPjvXk
Zuerst dachte ich, es sei ein Fehler, aber alle drei Engines stimmen überein. Nichts im UA-Stylesheet für <details> scheint es zu erklären.

— Lea Verou (@LeaVerou) 28. August 2022

Super seltsam! Wenn wir DevTools öffnen, sagt uns das User-Agent-Stylesheet, dass <details> als Block-Element angezeigt wird.

Beachten Sie das erforderliche <summary>-Element und die beiden zusätzlichen <div>s darin. Wir können das display überschreiben, oder?

Was wir erwarten könnten, ist, dass <details> nun eine explizite Höhe von 40vh und drei Zeilen hat, wobei die dritte Zeile den verbleibenden Platz der ersten beiden einnimmt. So

Ugh, aber die dritte Zeile... tut... das nicht.

Anscheinend haben wir es hier mit einem Grid-Container zu tun, der sein Grid-Verhalten nicht auf seine Grid-Elemente anwenden kann. Aber die HTML-Spezifikation sagt uns

Es wird erwartet, dass das details Element als Block-Box gerendert wird. Es wird auch erwartet, dass das Element einen internen Shadow Tree mit zwei Slots hat.

(Hervorhebung von mir)

Und etwas später

Es wird erwartet, dass der zweite Slot des details Elements das style Attribut auf „display: block; content-visibility: hidden;“ gesetzt hat, wenn das details Element kein open Attribut hat. Wenn es das open Attribut hat, wird erwartet, dass das style Attribut vom zweiten Slot entfernt wird.

(Hervorhebung wieder von mir)

Die Spezifikation besagt also, dass der zweite Slot – die beiden zusätzlichen <div>s aus dem Beispiel – nur dann zu Block-Elementen gezwungen werden, wenn <details> geschlossen ist. Wenn es geöffnet ist – <details open> – sollten sie dem Grid-Display entsprechen, das das User-Agent-Styling überschreibt… oder?

Das ist die Debatte. Ich verstehe, dass Slots standardmäßig auf display: contents gesetzt sind, aber verschachtelte Elemente in Slots zu zwängen und die Möglichkeit, sie zu stylen, zu entfernen, scheint daneben zu sein. Ist es ein Spezifikationsproblem, dass die Inhalte Slots sind, oder ein Browserproblem, dass wir ihr display nicht überschreiben können, obwohl sie sich im Box-Tree befinden? Klügere Leute können mich aufklären, aber es scheint eine falsche Implementierung zu sein.

Ist <details> ein Container oder ein interaktives Element?

Viele Leute nutzen <details> zum Auf- und Zuklappen von Menüs. Es ist eine Praxis, die von GitHub populär gemacht wurde.

Scheint vernünftig. Die Spezifikation erlaubt es sicherlich

Das details Element repräsentiert ein Offenlegungswidget, von dem der Benutzer zusätzliche Informationen oder Steuerelemente erhalten kann.

(Hervorhebung von mir)

Okay, also könnten wir erwarten, dass <details> der Container ist (es hat eine implizite role=group) und <summary> ein interaktives Element ist, das den open-Status des Containers setzt. Macht Sinn, da <summary> in einigen Kontexten eine implizite button-Rolle hat (aber keine entsprechende WAI-ARIA-Rolle).

Aber Melanie Sumner hat einige Nachforschungen angestellt, die dem nicht nur zu widersprechen scheinen, sondern zu dem Schluss führen, dass die Verwendung von <details> als Menü wahrscheinlich nicht das Beste ist. Sehen Sie, was passiert, wenn <details> ohne das <summary>-Element gerendert wird

Es tut genau das, was die Spezifikation vorschlägt, wenn es ein <summary> vermisst – es erstellt sein eigenes

Das erste summary Element-Kind des Elements, falls vorhanden, repräsentiert die Zusammenfassung oder Legende der Details. Wenn kein summary Element als Kind vorhanden ist, sollte der User-Agent eine eigene Legende bereitstellen (z. B. „Details“).

(Hervorhebung von mir)

Melanie hat das durch einen HTML-Validator laufen lassen und – Überraschung! – es ist ungültig

Also erfordert <details> das <summary>. Und wenn <summary> fehlt, erstellt <details> sein eigenes, obwohl es als ungültiges Markup gemeldet wird. Es ist alles in Ordnung und gültig, wenn <summary> vorhanden ist

All das führt zu einer neuen Frage: Warum bekommt <summary> eine implizite button-Rolle, obwohl <details> das interaktive Element zu sein scheint? Vielleicht ist das ein weiterer Fall, in dem die Browserimplementierung falsch ist? Andererseits kategorisiert die Spezifikation beide als interaktive Elemente. Man sieht, wie absolut verwirrend das alles wird.

Auf jeden Fall basiert Melanies endgültige Schlussfolgerung, dass wir <details> für Menüs vermeiden sollten, darauf, wie assistive Technologien <details>, die interaktive Elemente enthalten, vorlesen und ankündigen. Das Element wird angekündigt, aber es gibt keine Erwähnung von interaktiven Steuerelementen darüber hinaus, bis man, äh, mit <details> *interagiert*. Erst dann wird beispielsweise eine Liste von Links angekündigt.

Außerdem ist Inhalt innerhalb eines zusammengeklappten <details> von der seiteninternen Suche ausgeschlossen (außer in Chromium-Browsern, die zum Zeitpunkt der Erstellung auf den zusammengeklappten Inhalt zugreifen können), was die Suche noch schwieriger macht.

Sollte <summary> interaktive Elemente zulassen?

Das ist die Frage, die in diesem offenen Thread gestellt wird. Die Idee ist, dass etwas wie das hier 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 dies ein Problem ist

Der Link ist für JAWS beim Navigieren mit seinem virtuellen Cursor überhaupt nicht auffindbar. Wenn man über die Tabulatortaste zum Summary-Element navigiert, kündigt JAWS „Beispieltext, Schaltfläche“ als Namen und Rolle des Elements an. Wenn man erneut die Tabulatortaste drückt, kündigt JAWS erneut „Beispieltext, Schaltfläche“ an, obwohl der Tastaturfokus auf dem Link liegt.

[…]

Es gibt noch mehr, worüber ich mit den verschiedenen Problemen, die verschiedene AT mit dem Inhaltsmodell für Summary haben, sprechen könnte – aber das würde diesen Kommentar nur über das Notwendige hinaus verlängern. tldr; das Summary-Inhaltsmodell erzeugt sehr inkonsistente und manchmal einfach nur kaputte Erfahrungen für Menschen, die AT benutzen.

Scott hat Tickets eröffnet, um dieses Verhalten in Chromium und WebKit zu korrigieren. Danke, Scott!

Dennoch ist es valides HTML

Scott geht in einem separaten Blogbeitrag weiter. Zum Beispiel erklärt er, wie das Hinzufügen von role=button zu <summary> eine vernünftige Lösung zu sein scheint, um sicherzustellen, dass es von assistiver Technik konsistent angekündigt wird. Das würde auch die Debatte darüber beenden, ob <summary> interaktive Elemente zulassen sollte, denn Schaltflächen dürfen keine interaktiven Elemente enthalten. Das einzige Problem ist, dass Safari <summary> dann als normale Schaltfläche behandelt, wodurch seine expanded und collapsed Zustände verloren gehen. Die korrekte Rolle wird also angekündigt, aber jetzt fehlt sein Zustand. 🙃

Wohin gehen wir jetzt?

Haben Sie Angst, <details>/<summary> mit all diesen Problemen und Inkonsistenzen zu verwenden? Ich bin es sicherlich, aber nur insofern, als ich sicherstelle, dass das, was darin enthalten ist, die richtige Art von Erfahrung und Erwartung für die Benutzer bietet.

Ich bin einfach froh, dass diese Gespräche stattfinden und dass sie offen geführt werden. Aus diesem Grund können Sie Scotts drei Lösungsvorschläge für die Definition des Inhaltsmodells für <summary> kommentieren, seine Tickets hochwählen und Ihre eigenen Probleme und Anwendungsfälle melden, während Sie dabei sind. Hoffentlich, je besser wir verstehen, wie die Elemente verwendet werden und was wir von ihnen erwarten, desto besser werden sie implementiert.