Lesetip: responsive Tabellen (Inclusive Components)

[Gunnar Bittersmann]

Wo Tabellen hier immer wieder ein Thema sind (zuletzt auch in einem Thread von mir):

Da hat uns Heydon Pickering als Osterhase („Traditionshase“ 🤣) ein Osterei ins Osternest gelegt: Data Tables.

Prädikat: lesenswert!

TIL:

• verwende <th scope="col"> für Spaltenköpfe und <th scope="row"> für Zeilenköpfe

• Heydon plädiert dafür, für Listendarstellung bei schmalen Viewports tatsächlich die Daten doppelt im DOM zu haben – einmal als Tabelle, einmal als Liste, wobei jeweils nur eins davon sichtbar ist. Wie @1unitedpower in besagtem Thread sagte.

Die eine oder andere Anmerkung hab ich dazu noch:

• jede Tabelle hat mindestens ein tbody-Element, auch wenn keine <tbody>-Tags im HTML-Code stehen [1]

• div ist in dl erlaubt, um zusammengehörige dt/dd zu gruppieren. [2]

• role="none" als Synonym für role="presentation" [3]

LLAP 🖖

PS: Wieso ist eigentlich die Anzahl vergebbarer Tags (Kategorien) auf 3 beschränkt? Da hätte auch durchaus noch „html“ und „lesetipp“ oder „zur info“ reingehört. Und mit dieser Frage auch noch „zu diesem forum“.

[pl]

hi

redundate Daten sind keine Schande. Und da es sich um Daten für Listen//Tabellen handelt, wird das Layout eh als Template gerendert, daraus ergibt sich kaum ein Mehraufwand.

MfG

[Gunnar Bittersmann]

@@pl

Und da es sich um Daten für Listen//Tabellen handelt, wird das Layout eh als Template gerendert

Nicht unbedingt. Aber wenn dies nicht der Fall ist, wird man das Duplizieren der Tabellendaten in Listen-Markup unobtrusive per JavaScript erledigen.

LLAP 🖖

[JürgenB]

Hallo, Gunnar,

nach dem lesen deines Titels dachte ich, im Artikel von Heydon Pickering würde ich erfahren, wie ich Tabellen richtig aufbaue. Und was lese ich? Jede Menge Javascript. Können responsive Tabellen nur noch mit Javascript erzeugt werden? Ist klassisches HTML out? 😟

Vielleicht verstehe ich den Artikel ja beim zweiten etwas gründlcherem Lesen.

Gruß
Jürgen

[Gunnar Bittersmann]

@@JürgenB

nach dem lesen deines Titels dachte ich, im Artikel von Heydon Pickering würde ich erfahren, wie ich Tabellen richtig aufbaue. Und was lese ich? Jede Menge Javascript.

Das ist nicht der (Haupt-)Punkt des Artikels.

Können responsive Tabellen nur noch mit Javascript erzeugt werden? Ist klassisches HTML out? 😟

Nein und nein.

LLAP 🖖

[Henry]

Hallo JürgenB,

Können responsive Tabellen nur noch mit Javascript erzeugt werden? Ist klassisches HTML out?

Nein.

Und dann gibt's noch was umfangreicheres mit verschiedenen Ansätzen, inwieweit hier JS zum Tragen kommt, weiß ich aber noch nicht genau.

Gruss
Henry

[Matthias Apsel]

Hallo Henry,

Können responsive Tabellen nur noch mit Javascript erzeugt werden? Ist klassisches HTML out?

Nein.

Und dann gibt's noch was umfangreicheres mit verschiedenen Ansätzen, inwieweit hier JS zum Tragen kommt, weiß ich aber noch nicht genau.

Ich glaube, die Fragen waren eher rhetorischer Natur. Es gibt auch ein Tutorial im Wiki: http://wiki.selfhtml.org/wiki/CSS/Tutorials/Tabellen_responsiv_gestalten

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Matthias Apsel

Es gibt auch ein Tutorial im Wiki

welches aber in keinster Weise darauf eingeht, dass es problematisch ist, Tabellenelemente auf display: block zu setzen, da dadurch jeglicher Zusammenhang zwischen den Daten verlorengeht. Genau das ist Heydons Punkt.

LLAP 🖖

[Matthias Apsel]

Hallo Gunnar Bittersmann,

welches aber in keinster Weise darauf eingeht, dass es problematisch ist, Tabellenelemente auf display: block zu setzen, da dadurch jeglicher Zusammenhang zwischen den Daten verlorengeht. Genau das ist Heydons Punkt.

Was mich aber ein wenig verwundert. CSS ist für die Darstellung da. Warum beeinflusst diese die Semantik des zugrundeliegenden HTML?

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Matthias Apsel

welches aber in keinster Weise darauf eingeht, dass es problematisch ist, Tabellenelemente auf display: block zu setzen, da dadurch jeglicher Zusammenhang zwischen den Daten verlorengeht. Genau das ist Heydons Punkt.

Was mich aber ein wenig verwundert. CSS ist für die Darstellung da. Warum beeinflusst diese die Semantik des zugrundeliegenden HTML?

Zum einen sind Screenreader aber keine akustischen Browser, sondern eben: Screenreader, sie lesen das vor, was auf dem Bildschirm ist, und das möglichst adäquat. Deshalb wirkt display: none auch auf Screenreader.

Zum anderen kann man dieses Verhalten, dass die Änderung der Darstellung (womit nicht Nichtdarstellung gemeint ist) den Elementen ihre Bedeutung nimmt, durchaus als Bug ansehen. Was nichts daran ändert, dass man damit irgendwie umgehen muss.

Man könnte den Tabellenelementen explizit ihre Rolle per role-Attribut zuweisen; diese bliebe dann bei Änderung der display-Eigenschaft erhalten. Was aber ebenfalls nicht unproblematisch ist. Schon gar nicht, wenn die Tabelle als Liste dargestellt wird.

Siehe dazu Adrian Rosellis Artikel Tables, CSS Display Properties, and ARIA (den ich unlängst schon mal verlinkte).

LLAP 🖖

[Matthias Apsel]

Hallo Gunnar Bittersmann,

Was mich aber ein wenig verwundert. CSS ist für die Darstellung da. Warum beeinflusst diese die Semantik des zugrundeliegenden HTML?

Zum anderen kann man dieses Verhalten, dass die Änderung der Darstellung (womit nicht Nichtdarstellung gemeint ist) den Elementen ihre Bedeutung nimmt, durchaus als Bug ansehen. Was nichts daran ändert, dass man damit irgendwie umgehen muss.

Heydon schreibt: „Wie Adrian Roselli kürzlich bemerkte, hat die Verwendung von CSS-Anzeigeeigenschaften zum Ändern des Tabellenlayouts die Tendenz, die zugrunde liegende Tabellensemantik zu entfernen. Dies sollte wahrscheinlich nicht passieren, weil es mit dem Prinzip der Trennung der Interessen kollidiert. Es passiert trotzdem.“

Blöd.

Man könnte den Tabellenelementen explizit ihre Rolle per role-Attribut zuweisen; diese bliebe dann bei Änderung der display-Eigenschaft erhalten. Was aber ebenfalls nicht unproblematisch ist. Schon gar nicht, wenn die Tabelle als Liste dargestellt wird.

Wie sieht die Unterstützung von @media speech aus?

The ‘print’ and ‘screen’ media types are defined in HTML4. The complete list of media types in HTML4 is: ‘aural’, ‘braille’, ‘handheld’, ‘print’, ‘projection’, ‘screen’, ‘tty’, ‘tv’. CSS2 defines the same list, deprecates ‘aural’ and adds ‘embossed’ and ‘speech’. (https://www.w3.org/TR/css3-mediaqueries/#background)

Das scheint mir das richtige Werkzeug für solche Zwecke zu sein.

@media screen and (max-width: 42em) and not speech {
  /* Tabelle als Liste */
} 

was aber so nicht geht, weil not immer eine komplette MQ negiert (Es sei denn, sie sind durch Komma voneinander getrennt).

Aber in CSS3 gehen nested media queries

@media not speech {
  @media screen and (max-width: 42em) {
    /* Tabelle als Liste */
  }
} 

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Matthias Apsel

Wie sieht die Unterstützung von @media speech aus?

Was hast du damit vor? Wie ich schon sagte, Screenreader sind Screenreader, keine akustischen Browser. Screenreader sind Aufsätze auf visuellen Browsern, sie lesen das vor, was ein visueller Browser anzeigt.

LLAP 🖖

[Henry]

Hallo Matthias,

Ich glaube, die Fragen waren eher rhetorischer Natur. Es gibt auch ein Tutorial im Wiki: http://wiki.selfhtml.org/wiki/CSS/Tutorials/Tabellen_responsiv_gestalten

Das müsste nur leider mal überarbeitet werden. Responsive? In keinem Fall.

Gruss
Henry

[Matthias Apsel]

Hallo Henry,

Das müsste nur leider mal überarbeitet werden. Responsive? In keinem Fall.

Definiere in keinem Fall und schau dir die Beispiele ohne frickl an (Rechtsklick, in neuem Tab öffnen).

Bis demnächst
Matthias

[Henry]

Hallo Matthias,

Definiere in keinem Fall und schau dir die Beispiele ohne frickl an (Rechtsklick, in neuem Tab öffnen).

oje, da hätte ich doch genauer hinsehen sollen. Habe die Beispiele für sehr schmale Viewports übersehen, bzw. gedacht, wenn schmale schon nicht geht… Dabei ist das aber wohl doch anders konzeptioniert, soll ja bei schmalen Viewports am Inhalt orientieren und da der nun mal keine harten Umbrüche erlaubt, erscheinen halt die Scrollbalken.

Insofern, habe ich mich geirrt, sry.

Gruss
Henry