responsive Tabellen; JS-Problem mit custom properties im Firefox

[Gunnar Bittersmann]

Auf einen Tweet meines geschätzten Kollegen hin hab ich mal mit responsiven Tabellen rumgespielt.

Gängige Lösungen, den Daten eine Beschriftung zu verpassen, wenn sie auf schmalen Viewports nicht in Tabellenform angezeigt werden, waren bisher

• entweder die Beschriftung der Tabellenspalten im Stylesheet zu hinterlegen (wie im SELFHTML-Wiki gezeigt)
  Nachteil: Die Beschriftung muss an verschiedenen Stellen gepflegt werden. Inhalte gehören nicht ins Stylesheet (separation of concerns).

• oder die Beschriftung wird bei jeder Zelle in einem Attribut hinterlegt (im Wiki kurz erwähnt)
  Nachteil: vielfache Wiederholung derselben Beschriftungen, aufgeblähtes Markup

Mit custom properties (CSS-Variablen) steht nun ein Mittel zur Verfügung, das Beste beider Welten zu erreichen und keinen der Nachteile inkaufnehmen zu müssen: Die Beschriftungen der Datenzellen stehen im Markup nicht bei den einzelnen Zellen, sondern einmalig beim table-Element.
☞ Beispiel: responsive table with custom properties

Nun werden die Beschriftungen aber immer noch doppelt angegeben, in den th-Elementen im Tabellenkopf sowie im table-Element. Das kann man vermeiden, indem man die Beschriftungen mit JavaScript aus den th-Elementen ausliest und in die custom properties des table-Elements reinschreibt.
☞ Beispiel: Beispiel responsive table with custom properties set with JavaScript

Funktioniert auch – in Safari und Chrome. (Edge hab ich noch nicht getestet.) Nicht aber im Firefox. (EDIT: Das wurde im o.g. Beispiel behoben. Das Problem kann man unter responsive table with custom properties set with JavaScript, Firefox bug sehen.) Wenn man den Viewport von breit (Tabellendarstellung) auf schmal zieht, sind die Beschriftungen da. Wenn der Viewport aber beim Laden der Seite schmal ist, fehlen die Beschriftungen. Irgendwie kommt Firefox nicht hinterher, die custom properties aufzudröseln. Hat jemand einen Tip, wie man dem Fuchs auf die Sprünge helfen kann?

LLAP 🖖

[dedlfix]

Tach!

Funktioniert auch – in Safari und Chrome. (Edge hab ich noch nicht getestet.) Nicht aber im Firefox. Wenn man den Viewport von breit (Tabellendarstellung) auf schmal zieht, sind die Beschriftungen da. Wenn der Viewport aber beim Laden der Seite schmal ist, fehlen die Beschriftungen.

Doch, das geht, aber außerhalb vom Codepen.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Doch, das geht, aber außerhalb vom Codepen.

Nö. Das hatte ich auch im Verdacht; das isses aber nicht.

Geht auch nicht: bittersmann.de/test/planets

PS: Breakpoint auf 1001em hochgesetzt, sodass der media query ohne Zusammenschieben des Fensters wirkt

LLAP 🖖

[MudGuard]

Hi,

Geht auch nicht: bittersmann.de/test/planets

'thead:first-of-type > tr:first-of-type > th'

Dein thead enthält kein tr, da sind die th direkt im thead:

<table>
			<thead>
				<th>Planet</th>

(und das lang-Attribut im html-Element, das Du sonst immer bei allen anderen forderst, fehlt auch)

cu,
Andreas a/k/a MudGuard

[Matthias Apsel]

Hallo MudGuard,

Geht auch nicht: bittersmann.de/test/planets

'thead:first-of-type > tr:first-of-type > th'

Dein thead enthält kein tr, da sind die th direkt im thead:

Genau. Und da viele Tabellenelemente auf display:block gesetzt sind, werden vermutlich die tr nicht erzeugt.

Bis demnächst
Matthias

[Matthias Apsel]

Hallo Matthias Apsel,

Genau. Und da viele Tabellenelemente auf display:block gesetzt sind, werden vermutlich die tr nicht erzeugt.

Aber das Einfügen von tr hilft auch nicht.

Bis demnächst
Matthias

[Matthias Apsel]

Hallo Matthias Apsel,

Ebenso hilft das Kapseln in document.addEventListener('DOMContentLoaded', function () { nicht.

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Matthias Apsel

Ebenso hilft das Kapseln in document.addEventListener('DOMContentLoaded', function () { nicht.

Ich hätte schreiben sollten, was ich schon alles versucht habe‽ 😏

Auch das Kapseln in setTimeout() hat nicht geholfen.

LLAP 🖖

[Matthias Apsel]

Hallo Gunnar Bittersmann,

Ich hätte schreiben sollten, was ich schon alles versucht habe‽ 😏

Die Daten statt in das table-Element in body oder html zu schreiben? - Hilft nicht.

Die Daten statt in das table-Element in ein per JS erzeugtes zu schreiben? - Ungetestet.

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Matthias Apsel

Dein thead enthält kein tr, da sind die th direkt im thead:

Genau. Und da viele Tabellenelemente auf display:block gesetzt sind, werden vermutlich die tr nicht erzeugt.

Genau nicht. Das Stylesheet interessiert dem HTML-Parser herzlich wenig.

LLAP 🖖

[Gunnar Bittersmann]

@@MudGuard

Dein thead enthält kein tr, da sind die th direkt im thead:

Nö, die HTML5-Fehlerkorrektur des Browsers generiert ein tr-Element – auch bei fehlendem <tr>-Tag.

Deshalb war mir das gar nicht aufgefallen. Jetzt berichtigt.

(und das lang-Attribut im html-Element, das Du sonst immer bei allen anderen forderst, fehlt auch)

Und wo ich die Datei gerade offen hatte, das auch.

LLAP 🖖

[dedlfix]

Tach!

Doch, das geht, aber außerhalb vom Codepen.

Nö. Das hatte ich auch im Verdacht; das isses aber nicht.

Geht auch nicht: bittersmann.de/test/planets

Weiterhin kein Problem bei mir, selbst mit dem fehlenden tr.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Weiterhin kein Problem bei mir, selbst mit dem fehlenden tr.

Welches OS?

Hm, sollte sich der Firefox auf macOS hier anders verhalten als der unter Linux oder Windows?

Ich hab den aktuellen 56.0.2 (macOS) und die DeveloperEdition 57.0b14 – auch da geht’s nicht.

LLAP 🖖

[dedlfix]

Tach!

Weiterhin kein Problem bei mir, selbst mit dem fehlenden tr.

Welches OS?

Hm, sollte sich der Firefox auf macOS hier anders verhalten als der unter Linux oder Windows?

Ich hab den aktuellen 56.0.2 (macOS) und die DeveloperEdition 57.0b14 – auch da geht’s nicht.

56.0.2 64bit unter Windows. Beim Starten in klein (im privaten Fenser) sehe ich die Überschriften vor den Werten, aber im Codepen nicht.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

56.0.2 64bit unter Windows. Beim Starten in klein (im privaten Fenser) sehe ich die Überschriften vor den Werten, aber im Codepen nicht.

Hast du das Entwicklerwerkzeug offen?

LLAP 🖖

[Matthias Apsel]

Hallo dedlfix,

Doch, das geht, aber außerhalb vom Codepen.

Hab ich auch so festgestellt:

strg+f5 funktioniert, wirkliches Neuöffnen funktioniert aber nicht. Mysteriös.

Bis demnächst
Matthias

[Matthias Apsel]

Hallo Matthias Apsel,

strg+f5 funktioniert, wirkliches Neuöffnen funktioniert aber nicht. Mysteriös.

strg+f5 funktioniert manchmal, wirkliches Neuöffnen funktioniert aber nicht. Mysteriös.

Nightly 58.0a1 (2017-11-03) (64-Bit)

Bis demnächst
Matthias

[Matthias Apsel]

Hallo Gunnar Bittersmann,

Funktioniert auch – in Safari und Chrome. (Edge hab ich noch nicht getestet.) Nicht aber im Firefox.

Edge kann es nicht.

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Matthias Apsel

Edge kann es nicht.

Edge 15? Ja, laut Can I use ist der buggy.

Hat jemand schon Edge 16? Der sollte es können?

LLAP 🖖

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Warum steht im Feld Rotationsdauer für die Erde 0.997 d und nicht 1 d?

LLAP 🖖

[dedlfix]

Tach!

Warum steht im Feld Rotationsdauer für die Erde 0.997 d und nicht 1 d?

a) weil es jemand so reingeschrieben hat
b) weil es stimmt

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Warum steht im Feld Rotationsdauer für die Erde 0.997 d und nicht 1 d?

a) weil es jemand so reingeschrieben hat
b) weil es stimmt

💯 Gleich zwei richtige Antworten. 🤓

LLAP 🖖

[Matthias Apsel]

Hallo Gunnar Bittersmann,

Warum steht im Feld Rotationsdauer für die Erde 0.997 d und nicht 1 d?

Ich bin sicher, dass es eine rein rethorische Frage ist:

Der mittlere siderische Tag der Erde dauert 23 Stunden, 56 Minuten, 4,099 Sekunden = 86.164,099 s ≈ 23,9345 h = 0,99727083 d

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Matthias Apsel

Ich bin sicher, dass es eine rein rethorische Frage ist:

Und deshalb antwortest du darauf‽ 😂

LLAP 🖖

[Gunnar Bittersmann]

@@Matthias Apsel

Warum steht im Feld Rotationsdauer für die Erde 0.997 d und nicht 1 d?

Der mittlere siderische Tag der Erde dauert 23 Stunden, 56 Minuten, 4,099 Sekunden = 86.164,099 s ≈ 23,9345 h = 0,99727083 d

Ist das hier relevant? Wäre nicht der Sterntag von Bedeutung? 🤔

LLAP 🖖

[Matthias Apsel]

Hallo Gunnar Bittersmann,

Ist das hier relevant? Wäre nicht der Sterntag von Bedeutung? 🤔

siderischer Tag: Der siderische Tag (lateinisch sidus ‚Stern‘, Genitiv sideris) ist die Zeitspanne zwischen zwei aufeinander folgenden Kulminationen eines fiktiven, unendlich weit entfernten Fixsterns ohne Eigenbewegung.

Sterntag: Ein Sterntag ist der Zeitraum zwischen zwei oberen Kulminationen des Frühlingspunkts

Bei beiden sind auf einanderfolgende obere Kulminationen (erreichen von Himmelsrichtung Süd) gemeint. Der Frühlingspunkt ist ein fiktiver, unendlich weit entfernter Punkt ohne Eigenbewegung.

Nach meiner Lesart ist für die Erde beides dasselbe.

Bis demnächst
Matthias

[Matthias Apsel]

Hallo Matthias Apsel,

Nach meiner Lesart ist für die Erde beides dasselbe.

Wenn man berücksichtigt, dass der Frühlingspunkt aufgrund der Präzession nicht unbeweglich ist, kommt ein Unterschied von vielleicht einer Tausendstel Sekunde hinzu.

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Matthias Apsel

Nach meiner Lesart ist für die Erde beides dasselbe.

Nö; die beiden unterschieschieden sich immerhin um …

Wenn man berücksichtigt, dass der Frühlingspunkt aufgrund der Präzession nicht unbeweglich ist, kommt ein Unterschied von vielleicht einer Tausendstel Sekunde hinzu.

… acht Tausendstel, wie der verlinkten Quelle zu entnehmen ist.

Und um die Verwirrung komplett zu machen: „Die Benennung in englischsprachiger Literatur ist gerade andersherum als im Deutschen: hier heißt der Sterntag sidereal day und der Siderische Tag stellar day(!).“

LLAP 🖖

[JürgenB]

Hallo,

ihre messt der Erdbewegung zu viel Bedeutung bei. Die Zeit wird in Braunschweig gemacht, da steht die Zeitmaschine. Und wenn die mal eine Schaltsekunde einlegen muss, weil die Erde mal wieder falsch geht, dann nur deshalb, weil man die Erdbewegung nicht so einfach korrigieren kann.

Gruß
Jürgen

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Funktioniert auch – in Safari und Chrome. (Edge hab ich noch nicht getestet.) Nicht aber im Firefox. Wenn man den Viewport von breit (Tabellendarstellung) auf schmal zieht, sind die Beschriftungen da. Wenn der Viewport aber beim Laden der Seite schmal ist, fehlen die Beschriftungen. Irgendwie kommt Firefox nicht hinterher, die custom properties aufzudröseln.

Wenn man das Entwicklerwerkzeug offen hat, tritt der Effekt übrigens nicht auf – dann ist die Darstellung komplett.

Hat jemand einen Tip, wie man dem Fuchs auf die Sprünge helfen kann?

LLAP 🖖

[dedlfix]

Tach!

Wenn man das Entwicklerwerkzeug offen hat, tritt der Effekt übrigens nicht auf – dann ist die Darstellung komplett.

In einem frisch gestarteten Firefox ohne die Entwicklertools angefasst zu haben, ist bei mir weiterhin das geschilderte Verhalten nicht nachvollziehbar - zumindest wenn der ABP aktiv ist.

Das CSS muss hinters Javascript, dann klappt's auch mit dem Nachbarn.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

In einem frisch gestarteten Firefox ohne die Entwicklertools angefasst zu haben, ist bei mir weiterhin das geschilderte Verhalten nicht nachvollziehbar - zumindest wenn der ABP aktiv ist.

ABP? AdBlock Plus?

Hm, vielleicht triggert der tief in des Fuchsens Innereien dasselbe wie das Entwicklertool?

Das CSS muss hinters Javascript, dann klappt's auch mit dem Nachbarn.

Nö, macht bei mir keinen Unterschied. Klappt nicht mit dem Nachbarn.

LLAP 🖖

[dedlfix]

Tach!

Das CSS muss hinters Javascript, dann klappt's auch mit dem Nachbarn.

Nö, macht bei mir keinen Unterschied. Klappt nicht mit dem Nachbarn.

Das CSS bezieht sich auf Dinge, die erst durch das Javascript vorhanden sind. Die stehen also nur durch einen zeitlichen Zufall rechtzeitig bereit, wenn aus irgendeinem Grunde das CSS verzögert ausgewertet wird.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Das CSS bezieht sich auf Dinge, die erst durch das Javascript vorhanden sind. Die stehen also nur durch einen zeitlichen Zufall rechtzeitig bereit, wenn aus irgendeinem Grunde das CSS verzögert ausgewertet wird.

Custom properties sollten dynamisch geändert werden können (also auch nachträglich) und dann Wirkung zeigen.

Neuer Codepen, in welchem dasselbe für die Schriftfarbe gemacht wird → Klappt, der Text erscheint grau.

Einziger Unterschied, der mir einfallen mag, ist, dass content ja nicht aufs Element selbst angewandt wird, sondern aufs ::before-Pseudoelement.

LLAP 🖖

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Neuer Codepen, in welchem dasselbe für die Schriftfarbe gemacht wird → Klappt, der Text erscheint grau.

Einziger Unterschied, der mir einfallen mag, ist, dass content ja nicht aufs Element selbst angewandt wird, sondern aufs ::before-Pseudoelement.

Nee, das war’s auch nicht.

Noch ein Codepen, in welchem die Farbe für ein ::after-Pseudoelement gesetzt wird → Klappt, der Pfeil erscheint grau.

Scheint also mit der Generierung des Inhalts mit content zusammenzuhängen, was für ::after fix ist, für ::before über custom properties.

LLAP 🖖

[Matthias Apsel]

Hallo Gunnar Bittersmann,

Scheint also mit der Generierung des Inhalts mit content zusammenzuhängen, was für ::after fix ist, für ::before über custom properties.

Aber es hilft auch nicht, die entsprechenden Teile des CSS aus der MQ herauszunehmen.

Bis demnächst
Matthias

[dedlfix]

Tach!

Wenn die Tabelle von Anfang an die eine Custom-Property hat, dann setzt es auch in den bisherigen Misserfolgsfällen die Werte für diese Property. Nachvollziehbar, indem ich der Tabelle ein style="--colheader1:'foo'" spendiert habe, dann sind die anderen weiterhin nicht geändert, aber der eine.

Das lässt darauf schließen, dass dein CSS eine Referenz auf nichts setzt, dann das Javascript eine Property hinzufügt, aber das CSS nicht nochmal durchläuft, um die nun vorhandene Property zu berücksichtigen und die Referenz korrekterweise auf diese zu setzen.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Wenn die Tabelle von Anfang an die eine Custom-Property hat, dann setzt es auch in den bisherigen Misserfolgsfällen die Werte für diese Property. Nachvollziehbar, indem ich der Tabelle ein style="--colheader1:'foo'" spendiert habe, dann sind die anderen weiterhin nicht geändert, aber der eine.

Das lässt darauf schließen, dass dein CSS eine Referenz auf nichts setzt, dann das Javascript eine Property hinzufügt, aber das CSS nicht nochmal durchläuft, um die nun vorhandene Property zu berücksichtigen und die Referenz korrekterweise auf diese zu setzen.

Das halte ich für einen Trugschluss, denn wie gezeigt funktioniert das Ganze ja für --color[1-6] und --color.

LLAP 🖖

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Woran’s auch nicht liegt: an der mehrstufigen Zuweisung über --colheader[1-6] und --colheader.

Auch bei einstufiger Zuweisung über --colheader[1-6] tritt der Fehler auf: debugging 3

LLAP 🖖

[dedlfix]

Tach!

Das lässt darauf schließen, dass dein CSS eine Referenz auf nichts setzt, dann das Javascript eine Property hinzufügt, aber das CSS nicht nochmal durchläuft, um die nun vorhandene Property zu berücksichtigen und die Referenz korrekterweise auf diese zu setzen.

Das halte ich für einen Trugschluss, denn wie gezeigt funktioniert das Ganze ja für --color[1-6] und --color.

Nächster Versuch: content ist ein Referenztyp, color ein Value-Typ. Dann müsste man mindestens einen Defaultwert setzen, um ihn überwachen zu können, und dann schreibt es bei Änderungen den Wert direkt hinein. (Ist auch nur eine Vermutung.)

dedlfix.

[Matthias Apsel]

Hallo Gunnar Bittersmann,

Wenn man das Entwicklerwerkzeug offen hat, tritt der Effekt übrigens nicht auf – dann ist die Darstellung komplett.

Kann ich nicht bestätigen.

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Matthias Apsel

Wenn man das Entwicklerwerkzeug offen hat, tritt der Effekt übrigens nicht auf – dann ist die Darstellung komplett.

Kann ich nicht bestätigen.

Es wird immer mysteriöser.

LLAP 🖖

[Matthias Apsel]

Hallo Gunnar Bittersmann,

Wenn man das Entwicklerwerkzeug offen hat, tritt der Effekt übrigens nicht auf – dann ist die Darstellung komplett.

Kann ich nicht bestätigen.

Es wird immer mysteriöser.

Geöffnetes Entwicklerwerkzeug + FullPage-Ansicht von CodePen. Da tritt der Effekt nicht auf und man kann dem Browser bei der Arbeit zuschauen.

Bis demnächst
Matthias

[Matthias Apsel]

Hallo Gunnar Bittersmann,

• entweder die Beschriftung der Tabellenspalten im Stylesheet zu hinterlegen (wie im SELFHTML-Wiki gezeigt)
  Nachteil: Die Beschriftung muss an verschiedenen Stellen gepflegt werden. Inhalte gehören nicht ins Stylesheet (separation of concerns).

Nunja, man könnte die entsprechenden Zeilen ja auch mit JS in ein style-Element schreiben, dann hätte man auch keine doppelte Pflege.

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Matthias Apsel

Nunja, man könnte die entsprechenden Zeilen ja auch mit JS in ein style-Element schreiben, dann hätte man auch keine doppelte Pflege.

Nunja, die Eleganz der Lösung ginge verloren.

LLAP 🖖

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Ich hab das Problem mal reduziert: Codepen

| fehlerhafte Anzeige in Firefox | | erwartete Anzeige (wie in Chrome) |

LLAP 🖖

[dedlfix]

Tach!

Ich hab das Problem mal reduziert: Codepen

Ein zusätzliches

div {
  --content: '';
}

löst es.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Ich hab das Problem mal reduziert: Codepen

Ein zusätzliches

div {
  --content: '';
}

In der Tat. (WTF?)

Es ist mir auf die Schnelle aber nicht geglückt, das auf die Tabelle anzuwenden.

LLAP 🖖

[Matthias Apsel]

Hallo Gunnar Bittersmann,

* { --content: ''; }?

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Matthias Apsel

* { --content: ''; }?

Netter Versuch, Hoëcker. Leider falsch.

LLAP 🖖

[dedlfix]

Tach!

Ich hab das Problem mal reduziert: Codepen

Ein zusätzliches

div {
  --content: '';
}

In der Tat. (WTF?)

Es ist dasselbe Prinzip wie ich es bereits mit dem style-Attribut gelöst hatte.

Es ist mir auf die Schnelle aber nicht geglückt, das auf die Tabelle anzuwenden.

Wenn du die Eigenschaft mit Javascript setzen kannst, geht das auch anderenorts.

dedlfix.

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Es ist mir auf die Schnelle aber nicht geglückt, das auf die Tabelle anzuwenden.

My bad. --colheader[1-6] muss initial gesetzt werden – und zwar für table, nicht für td. Ich war nicht in meinem Element.

Im ursprünglichen Pen hinzugefügt; den aber vorher geforkt.

LLAP 🖖

[Gunnar Bittersmann]

@@dedlfix

Ein zusätzliches

div {
  --content: '';
}

löst es.

Das sollte nicht erforderlich sein. Mal sehen, wie lange es das noch ist. Bugticket erstellt.

LLAP 🖖

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Mit custom properties (CSS-Variablen) steht nun ein Mittel zur Verfügung, das Beste beider Welten zu erreichen und keinen der Nachteile inkaufnehmen zu müssen

… und in Browsern, in denen custom properties nicht zur Verfügung stehen, bleibt die Tabelle so wie sie ist und kann horizontal gescrollt werden. Progressive enhancement at its best.

Für ersteres kommt das ganze Tabelle-als-Liste-Darstellen in einen @supports()-Block.

Für zweiteres wird die Tabelle in ein <div role="region" tabindex="0"> mit overflow: auto gepackt, siehe „Scrolling“ in Adrian Roselli, A Responsive Accessible Table und Steve Faulkner, Short note on improving usability of scrollable regions.

Ich hab sämtliche Codepens angepasst.

LLAP 🖖

[JürgenB]

Hallo Gunnar,

magst du erklären, warum es besser ist, die Tabelle (oder andere übergroße Objekte) in ein Scrolldiv zu stecken, statt die Scrollmöglichkeit des Browsers zu nutzen?

Gruß
Jürgen

[Gunnar Bittersmann]

@@JürgenB

magst du erklären, warum es besser ist, die Tabelle (oder andere übergroße Objekte) in ein Scrolldiv zu stecken, statt die Scrollmöglichkeit des Browsers zu nutzen?

    

LLAP 🖖

[JürgenB]

Hallo Gunnar,

ich habe schon viele Seiten besucht, bei denen der horizontale Scrollbalken des Scrollelements weit unten lag und ich zum Scrollen erst mal scrollen musste. Der Scrollbalken des Browsers ist immer sichtbar.

Gruß
Jürgen

[Gunnar Bittersmann]

@@JürgenB

ich habe schon viele Seiten besucht, bei denen der horizontale Scrollbalken des Scrollelements weit unten lag und ich zum Scrollen erst mal scrollen musste.

Ja, das könnte bei Tabellen mit vielen Zeilen auf manchen Geräten ein Problem sein.

Ich hab aber wohl schon ewig kein Gerät mehr in der Hand gehabt, wo man zum Scrollen tatsächlich den Scrollbalken anfassen musste.

Allerdings geht es hier ja um die Grundfunktionalität, die @supports()-Support und ohne JavaScipt(! – hatte ich glatt vergessen zu erwähnen) zur Verfügung stehen muss. Da muss man abwägen …

Der Scrollbalken des Browsers ist immer sichtbar.

Nein. Nur auf manchen Systemen. Auf anderen Systemen bzw. in Browswern ist das einstellbar.

LLAP 🖖

[JürgenB]

Hallo Gunnar,

Ich hab aber wohl schon ewig kein Gerät mehr in der Hand gehabt, wo man zum Scrollen tatsächlich den Scrollbalken anfassen musste.

ich habe fast täglich einen 11" Laptop in der Hand. Nicht alle nutzen ausschließlich Apple oder Android-Geräte.

Gruß
Jürgen

[Matthias Apsel]

Hallo Gunnar Bittersmann,

Der Scrollbalken des Browsers ist immer sichtbar.

Gemeint ist sicher: Der Scrollbalken ist falls notwendig immer sichtbar.

Nein. Nur auf manchen Systemen. Auf anderen Systemen bzw. in Browswern ist das einstellbar.

Im Chrome auf Android etwa wird der vertikale erst beim Scrollen selbst sichtbar, auf den horizontalen muss ich bei Gelegenheit mal achten.

Aber einstellbar?

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Matthias Apsel

Im Chrome auf Android etwa wird der vertikale erst beim Scrollen selbst sichtbar

Bei iOS auch. Auch beim Mac ist das so. IIRC ist das die Grundeinstellung; das ist in den Systemeinstellungen unter Allgemein einstellbar.

Aber einstellbar?

Für IE/Edge kann man das mittels -ms-overflow-style: -ms-autohiding-scrollbar tun. [MSDN, MDN]

LLAP 🖖

[JürgenB]

Hallo,

Für IE/Edge kann man das mittels -ms-overflow-style: -ms-autohiding-scrollbar tun. [MSDN, MDN]

und wie scrolle ich dann? Mein Laptop kennt keine Wischgesten.

Gruß
Jürgen

[Gunnar Bittersmann]

@@JürgenB

Für IE/Edge kann man das mittels -ms-overflow-style: -ms-autohiding-scrollbar tun. [MSDN, MDN]

und wie scrolle ich dann?

Wahlweise mit Maus oder Tastatur – wie in den verlinkten Quellen beschrieben.

LLAP 🖖

[JürgenB]

Hallo Gunnar,

und wie scrolle ich dann?

Wahlweise mit Maus oder Tastatur – wie in den verlinkten Quellen beschrieben.

in welchen?

Gruß
Jürgen

[Gunnar Bittersmann]

@@JürgenB

und wie scrolle ich dann?

Wahlweise mit Maus oder Tastatur – wie in den verlinkten Quellen beschrieben.

in welchen?

In denen, die du beim Zitieren rausgelöscht hast.

LLAP 🖖

[JürgenB]

Hallo Gunnar,

jetzt habe ich es gesehen. Ich habe nur bei Mozilla gesucht.

Trotzdem finde ich die Lösung, die Scrollbalken an ein Element zu kleben, und nicht die der ganzen Seite zu nehmen, unpraktisch. Der Horizontale Balken ist ja noch nicht mal ausgeblendet, sondern liegt bei viel Inhalt nur außerhalb des Viewports und ist so direkt erst mal nicht zu erreichen. D.h. runter, rüber, rauf scrollen oder Wechsel von Maus/Touchfeld zur Tastatur. MMn kein gutes UI.

Gruß
Jürgen

[1unitedpower]

… und in Browsern, in denen custom properties nicht zur Verfügung stehen, bleibt die Tabelle so wie sie ist und kann horizontal gescrollt werden. Progressive enhancement at its best.

Ein Problem gibt es noch: In der Listenansicht lassen sich die Beschriftungen nicht markieren, infolgedessen lassen sie sich auch nicht in die Zwischenablage kopieren und das Kontextmenü lässt sich auch nicht mehr öffnen.

[Gunnar Bittersmann]

@@1unitedpower

Ein Problem gibt es noch: In der Listenansicht lassen sich die Beschriftungen nicht markieren, infolgedessen lassen sie sich auch nicht in die Zwischenablage kopieren und das Kontextmenü lässt sich auch nicht mehr öffnen.

Das ist bei CSS-generiertem Inhalt wohl generell so.

LLAP 🖖

[Matthias Apsel]

Hallo Gunnar Bittersmann,

Das ist bei CSS-generiertem Inhalt wohl generell so.

Browserabhängig. Im edge lässt sich der generierte Inhalt (hakelig zwar) markieren.

Bis demnächst
Matthias

[1unitedpower]

Das ist bei CSS-generiertem Inhalt wohl generell so.

Schade… irgendwie ernüchternd. Denn für mich bedeutet das, dass es am Ende doch wieder ein echtes Element pro Tabellenzelle für die Beschriftung braucht.

[Gunnar Bittersmann]

@@1unitedpower

Schade… irgendwie ernüchternd. Denn für mich bedeutet das, dass es am Ende doch wieder ein echtes Element pro Tabellenzelle für die Beschriftung braucht.

Dann hätte das JavaScript einiges am DOM zu tun …

Dann kann man auch gleich aus jeder Tabellenzeile eine Beschreibungsliste dl mit dt und dd machen.

LLAP 🖖

[1unitedpower]

Dann hätte das JavaScript einiges am DOM zu tun …

Eher der Autor des HTML oder der Server, der das HTML zusammenbaut. Das meine ich ja mit ernüchternd.

Dann kann man auch gleich aus jeder Tabellenzeile eine Beschreibungsliste dl mit dt und dd machen.

Ja, daran hab ich auch gedacht. Vereinfacht auf der anderen Seite das Stylesheet, weil man bei einem Breakpoint einfach die Tabelle aus- und die die Definitionsliste(n) einblenden könnte und umgekehrt. Oder man lässt die Tabelle ganz weg und man layoutet die Definitionslisten bei ausreichend großem Viewport wie eine Tabelle. Alles irgendwie halbgar.

[Gunnar Bittersmann]

@@1unitedpower

Dann hätte das JavaScript einiges am DOM zu tun …

Eher der Autor des HTML oder der Server, der das HTML zusammenbaut.

Nö, der Seitenautor sollte damit gar nichts zu tun haben. Der pflegt seinen Inhalt genau einmal ein.

Dann kann man auch gleich aus jeder Tabellenzeile eine Beschreibungsliste dl mit dt und dd machen.

Ja, daran hab ich auch gedacht. Vereinfacht auf der anderen Seite das Stylesheet, weil man bei einem Breakpoint einfach die Tabelle aus- und die die Definitionsliste(n) einblenden könnte und umgekehrt.

Du willst aber nicht den Inhalt doppelt (als Tabelle und als Beschreibungsliste^[1]) im DOM haben, oder?

Oder man lässt die Tabelle ganz weg und man layoutet die Definitionslisten bei ausreichend großem Viewport wie eine Tabelle.

Kann man so machen. Dann hat man natürlich die Beschriftungen zigfach im HTML-Code. Aber genau das willst du ja, wenn sie kopierbar sein sollen.

LLAP 🖖

---

1. dl steht für description list, nicht für definition list. ↩︎

[1unitedpower]

Nö, der Seitenautor sollte damit gar nichts zu tun haben. Der pflegt seinen Inhalt genau einmal ein.

Jagut, dann könnte man dem Seitenautor ein Werkzeug geben, in dem er die Daten einpfegen kann, um dann das HTML generieren zu lassen. Wenn so ein Werkzeug aber noch nicht benutzt wird, dann würde ich mir zwei mal überlegen, wie oft ich das brauchen würde und ob ich mir nicht lieber die Mühe mache redundantes HTML per Hand zu schreiben.

Du willst aber nicht den Inhalt doppelt (als Tabelle und als Beschreibungsliste) im DOM haben, oder?

Ne stimmt, eigentlich nicht. Ich dachte zuerst, dass es kaum eine Rolle spielt, wenn immer nur eine Alternative im Accessibility-Tree aktiv ist. Beim genaueren drüber Nachdenken stimmt das aber nicht, das würde einen Rattenschwanz mit sich ziehen, den ich erst nicht bedacht habe. Bspw. könnten Anker in den jeweiligen Teilen nicht mehr die selber IDs haben, und damit scheidet das dann auch schon aus. Die Navigation würde dadruch kaputt gehen. Dann doch besser eine Variante auf dem Server vorrrendern und die Alternative per JavaScript aktiveren, wenn Bedarf besteht.

Oder man lässt die Tabelle ganz weg und man layoutet die Definitionslisten bei ausreichend großem Viewport wie eine Tabelle.

Kann man so machen. Dann hat man natürlich die Beschriftungen zigfach im HTML-Code. Aber genau das willst du ja, wenn sie kopierbar sein sollen.

Ja, das ist m.M.n. nicht optional. Ein Benutzer kann erwarten, dass sich Text markieren lässt, erfüllt sich die Erwartung nicht, ist das schlechte UX.