fietur: Kein <div> und kein <p> im <summary> erlaubt - was tun?

Hallo.

Warum dürfen weder <div> noch <p> innerhalb eines <summary> stehen?

"Element div not allowed as child of element summary in this context." lautet die Validator-Meldung hierzu.

Auf meiner Seite habe ich eine Vielzahl von <article>-Containern mit folgendem Aufbau:

<article>
<details>
<summary>
<img ...>
<p>ein paar Zeilen</p>
</summary>
<p>weiterer Text>/p>
<img ...>
<p>...</p>
</details>
</article>

Im CSS ist p {padding:1rem;} notiert. Die Bilder sollen (meist) die gesamte Breite einnehmen.

Das obenstehende HTML wird zwar wie gewünscht gerendert, ist aber eben nicht Validator-konform.

Wenn ich die <p>-Tags entferne und summary {padding:1rem;} notiere, wird es zwar konform, aber <img> erhält unerwünschterweise ebenfalls Ränder. summary :not(img) zu notieren, ändert daran nichts (wäre das überhaupt korrekt so?).

<div> darf (weil kein phrasing content) ebenfalls nicht notiert werden. Wählt man hilfsweise etwas wie <span> und weist so einen Rand zu, wird ja nur die erste Zeile eingerückt, was ebenfalls unerwünscht ist - es passt nicht zum Rest.

Wie kann ich im <summary> Text von Grafik getrennt auszeichnen?

akzeptierte Antworten

  1. @@fietur

    Hallo.

    Warum dürfen weder <div> noch <p> innerhalb eines <summary> stehen?

    Das hast du doch schon selbst beantwortet: „weil kein phrasing content“.

    Ergänzung: und kein heading content, was laut Spec auch erlaubt wäre.

    <div> darf (weil kein phrasing content) ebenfalls nicht notiert werden. Wählt man hilfsweise etwas wie <span> und weist so einen Rand zu, wird ja nur die erste Zeile eingerückt, was ebenfalls unerwünscht ist - es passt nicht zum Rest.

    Du kannst span nehmen und auf summary span { display: block } setzen.

    Kwakoni Yiquan

    --
    Ad astra per aspera
    1. Hallo Gunnar,

      an der Stelle - find ich - führt sich das Inhaltsmodell ad absurdum. Die phrasing content Elemente sind ja typischerweise Inline-Elemente, und ihr Zweck ist normalerweise, im Fließtext für eine Formatierung zu sorgen. Oder, wie es die Spec schreibt:

      Phrasing content is the text of the document, as well as elements that mark up that text at the intra-paragraph level. Runs of phrasing content form paragraphs.

      Durch das Umstylen auf display:block wird dieser Zweck ad absurdum geführt.

      Deswegen halte ich das von fietur angestrebte Layout für keine gute Idee. Der ganze Teaser als Aufklappschaltfläche? Damit rechnet man doch eigentlich nicht. Das kleine schwarze Dreieck des details-Elements geht da vollkommen unter.

      <summary>
      <img ...>
      <p>ein paar Zeilen</p>
      </summary>
      

      Das summary-Element ist die eingeklappte "Kurzfassung" des details-Elements. Es durch "ein Bild und ein paar Zeilen" zu füllen, kann es doch eigentlich nicht sein. Das klingt irgendwie nach den Cards, die wir im Wiki gerade anstreben. Eine Card als Trigger für den Rest? Wenn sie einen Link darstellt und als Card klar erkennbar ist, wie im Wiki, dann okay, aber Fließtext als riesige Schaltfläche (was summary ja letztlich ist), das finde ich fragwürdig.

      Vor allem schießt das ::marker-Element dann quer, das hängt nämlich bestenfalls an der Unterkante des Bildes, aber nicht tiefer, das sieht komisch aus, find ich. Ich hab's jedenfalls nicht an die Unterkante des summary bekommen, es wollte entweder ganz nach oben (dann war rechts davon frei) oder an die Unterkante des Bildes und das Bild wurde um Markerbreite eingerückt. Die Marker-Gestaltung im summary-Element ist nicht so frei, wie man meint. Ich hab dann versucht, den ganzen Summary-Inhalt als span mit display:inline-block zu erzeugen und die Paragraphen durch <br> herbeizubrummen, aber er hat's immer noch gemerkt.

      Deshalb meine ich, dass statt

      <details>
         <summary>Ein Bild und ein paar Absätze</summary>
         <p>Langtext mit Bildern</p>
      </details>
      

      doch eigentlich sowas angezeigt wäre:

      <article>
         <header>
         Bild, Überschrift und Teaserabsätze
         </header>
         <details>
            <summary>Mehr dazu...</summary>
            <p>Langtext mit Bildern</p>
         </details>
      <article>
      

      Den "Mehr dazu" Text könnte man per CSS und details[open] Selektor auch in ein "(Einklappen)" umschalten, wenn die details aufgeklappt sind.

      Rolf

      --
      sumpsi - posui - obstruxi
      1. Der ganze Teaser als Aufklappschaltfläche? Damit rechnet man doch eigentlich nicht. Das kleine schwarze Dreieck des details-Elements geht da vollkommen unter.

        Und das genau ist es, was ich daran super finde. Das Dreieck wird bei mir ohnehin ausgeblendet. Unter dem Teaser-Text/Bild werden drei riesige Punkte per :after eingesetzt. Die Bedienung ist intuitiv, egal ob gewohnt oder nicht. Ja, so ist es nicht gedacht, und ja, da könnte alles oder nichts stehen. Eine riesen Schaltfläche, bei der es nicht darauf ankommt, wo man hintippt... Im Teaser sind ja keine Links, sondern der ganze Teaser erfüllt im Grunde genau diese Funktion: Interaktion bei Interesse. Nicht für ein Detail, sondern einfach nur für mehr.

        Der Zweck ist nicht, details/summary konform einzusetzen, sondern ein Mittel, um das Ein-/Ausklappen zu ermöglichen. Jedenfalls für mich - und vermutlich für den größten Teil der Verwender.

        Aber: phrasing content ist doch kein Summary! Mehr "Blockigkeit" als bei einem klassischen Bild ist kaum vorstellbar - und das ist erlaubt. Stattdessen müssen die in <p> schon vorhandenen Eigenschaften übertragen werden.

        Irreführend, so finde ich die Bezeichnung summary. Eine Zusammenfassung ist kürzer als das Zusammengefasste, aber nicht zwangsläufig bis zur Einäscherung. Auf mich wirkt die Begrenzung auf phrasing content künstlich oder bevormundend. Dass heading content erlaubt ist, macht es nicht besser. Denn Überschriften müssen nicht Zusammenfassung sein. Zwar macht es Sinn, diese gleich auch noch als Summary zu nutzen, aber dann steht für mich eben diese Nutzung im Vordergrund. Summary könnte phrase-trigger heißen oder etwas in der Art. Das würde allerdings nichts daran ändern, dass viele sich die Funktionalität zu Nutze machen würden. Auch mangels Alternativen oder aus reinem Spieltrieb (mit den möglichen unbedachten und nicht beabsichtigten Auswirkungen).

        <header> und <summary> zugunsten einer besseren Strukturierung zu trennen - da bin ich prinzipiell einverstanden, und so habe ich das auch implementiert; die Überschriften sind außerhalb des summary in <h..> tags verpackt.

        Jedenfalls funktioniert die Bedienung bei mir jetzt auch im volltrunkenem Zustand und für grobmotorische Analfabeten. (Nicht dass ich volltrunken oder Analfabet wäre - ...)

        1. Hallo fietur,

          ich denke, dann hast Du diese Optionen.

          (1) Pfeif auf valides HTML und möglicherweise auch auf zugängliche Bedienung, und bau deine Seite so, wie Du angefangen hast.

          (2) Spiele ein bisschen mit position:absolute herum und lege dein Summary komplett über deine Card. Nachteil: Der Anwender kann nichts mehr in der Card auswählen (es sei denn, du nimmst den füllenden Effekt in der ausgeklappten Version 'raus).
          Das könnte so aussehen - ich nehme aber an, dass ins summary-Element noch ein visuell versteckter Informationstext hinein muss, damit das Ganze zugänglich ist. Muss man mit NVDA oder so schauen, der sagt ja für summary bereits etwas an. Die teiltransparente Hintergrundfarbe für's summary ist drin, damit man sieht, wo es ist - die ist nicht für den praktischen Einsatz

          (3) Baue das Ding mit JavaScript nach. Viel Glück mit der Zugänglichkeit, das wird ein Haufen aria-Gedöns.

          Rolf

          --
          sumpsi - posui - obstruxi
          1. (1) Pfeif auf valides HTML und möglicherweise auch auf zugängliche Bedienung, und bau deine Seite so, wie Du angefangen hast.

            Ja, so hat es angefangen und ging online. Dann erst kam der Check mit dem Validator...

            (2) Spiele ein bisschen mit position:absolute herum und lege dein Summary komplett über deine Card. Nachteil: Der Anwender kann nichts mehr in der Card auswählen (es sei denn, du nimmst den füllenden Effekt in der ausgeklappten Version 'raus).

            Insofern stimmt der Inhalt mit einer Zusammenfassung/einem Teaser überein: Da gibt es keine Links, das Ganze ist eine kompakte Einheit.

            Das könnte so aussehen

            Danke für die Mühe. Tatsächlich blende ich den "Schalter" nach Aufklappen aus, weil er unnötig wird. Das ist sicher nicht generell so, aber bei mir schon; zugeklappt sind die Artikel, die als Kacheln den Bildschirm füllen, übersichtlich. Aufgeklappt werden sie meist auch gelesen/die Bilder angesehen werden. Es gibt keinen Grund, zurückzuscrollen an den Anfang, um dort den Artikel wieder einzuklappen. Es folgt mehr der Logik: Wo etwas (noch) verborgen ist, befindet sich ein gut wiedererkennbares Schaltelement (auch wenn das Bild und der teaser als solcher dienen kann). Wo nichts verborgen ist (weil aufgeklappt), braucht es auch keinen Schalter mehr.

            An anderer Stelle (einer Tabelle, von der nur die ersten Einträge gezeigt werden) handhabe ich das anders: dort ändert sich das "..." nach Aufklappen in ":" - simpel und wirkungsvoll implementiert (wenn auch nicht mit details/summary). Der Nutzer sieht die zugrunde liegende Technik nicht, aber die Bedienung wirkt konsistent und wirft keine Fragen auf.

            • ich nehme aber an, dass ins summary-Element noch ein visuell versteckter Informationstext hinein muss, damit das Ganze zugänglich ist. Muss man mit NVDA oder so schauen, der sagt ja für summary bereits etwas an. Die teiltransparente Hintergrundfarbe für's summary ist drin, damit man sieht, wo es ist - die ist nicht für den praktischen Einsatz

            Ich habe es mir mit NVDA "angesehen"; es scheint zu funktionieren (das Summary wird als Schalter gemeldet). Um in der Hinsicht wirklich barrierefrei zu sein, müsste ohnehin ein "richtiger" Nutzer testen.

            (3) Baue das Ding mit JavaScript nach. Viel Glück mit der Zugänglichkeit, das wird ein Haufen aria-Gedöns.

            Bisher habe ich noch keine Notwendigkeit für JavaScript gesehen. CSS und Server-Voodoo (PHP) reichen mir vollauf.

            1. @@fietur

              Es gibt keinen Grund, zurückzuscrollen an den Anfang, um dort den Artikel wieder einzuklappen. Es folgt mehr der Logik: Wo etwas (noch) verborgen ist, befindet sich ein gut wiedererkennbares Schaltelement (auch wenn das Bild und der teaser als solcher dienen kann). Wo nichts verborgen ist (weil aufgeklappt), braucht es auch keinen Schalter mehr.

              Ein Adventskalender? 😊

              Kwakoni Yiquan

              --
              Ad astra per aspera
              1. Ein Adventskalender? 😊

                Hübsch! Aber nein, einfach nur alle möglichen Artikel - meist Ankündigungen oder Berichte über Veranstaltungen - , die so zusammenkommen und nach einer Weile wieder verschwinden (oder archiviert werden).

                Das Design erinnert mich an ein Memory, das ich zur Pandemiezeit mal für zu Hause kasernierte Kindergartenkinder ins Netz gestellt hatte. (Jede Karte ein Link; und die Crawler schienen damals über unbegrenzte Budgets - und ganz sicher noch weniger rudimentäre KI als heute - zu verfügen. Über 100.000 Klicks im ersten Monat, bis mir das auffiel...)

      2. Durch das Umstylen auf display:block wird dieser Zweck ad absurdum geführt.

        Verwechseln wir jetzt womöglich die inhaltliche Struktur mit der optischen Repräsentation? Ander gefragt: wozu sollte denn beispielsweise die Zweiwort-Syntax dann überhaupt „erfunden worden“ sein“? Welchen Sinn hätten Elemente wie article usw, wenn sie ebensogut als div oder span, ggf. „mit Klassen drin“, geschrieben werden können. Oder gar sollen, denn sonst erzeugen sie ja womöglich einen „Content-Sprung“ ind andere, falsche oder gar verbotene, Ebenen⁉︎ Und wieso heißt das Ding dazu (immer noch?) display?