Klebriger Mist (position: sticky)

[Rolf B]

Hallo alle,

ich hatte die Absicht, eine etwas breitere Tabelle mit einer klebrigen ersten Spalte zu versehen. Aus den gleichen Gründen, weshalb andere eine klebrige erste Zeile machen.

Nach etlichem Ringen habe ich das in ein Wiki-Beispiel gepackt:

Sticky First Column

Beim Start zeigt das Beispiel die triviale Lösung: die Zellen haben einen Rand, border-collapse ist auf collapse und das Zellpadding ist brav in em angegeben.

Aber das Ding hat seine Tücken.

(1) Generell ergibt sich der Mist, dass der linke und rechte Rand der Datumsspalte nicht sticky sind, sondern mit dem Rest nach links verschwinden. Bäh. Und links guckt dann auch noch der gescrollte Teil der Tabelle durch. BÄH.

(2) Chromia auf low-dpi Bildschirmen

Scrollt man das Beispiel in Chrome nach rechts (Fenster muss dafür schmal genug sein), ergeben sich in der sticky-Spalte visuelle Artefakte in Form von Pixel-Lücken zwischen den Datumszellen, wo der Datenteil der Tabelle durchguckt. Aber nur in Chrome, Edge kriegt es hin. Faszinierend. Firefox kann es auch vernünftig.

(3) Chrome für Android

Da scrollt einfach der ganze Body und von sticky ist keine Spur. Dabei hab ich doch das Viewport-Meta gesetzt. WTF?!

Das Problem mit dem linken Rand habe ich zu durch andere Ränder zu lösen versucht. Man stelle auf der Demo-Seite border-collapse auf separate und cell borders auf 50/50 (was es nicht mehr ist, ich habe es zu 75/25 ändern müssen). Dann bleibt der linke Rand stehen (er ist jetzt Teil der th in Spalte 1 und nicht mehr der table zugehörig).

Aber visuelle Artefakte in Chrome gibt's immer noch. Die verschwinden erst, wenn ich das Padding nicht in em, sondern px angebe. Das Bescheuerte ist, dass das nur in Chrome passiert. Edge und Firefox kriegen es ordentlich hin. Aber Chrome rechnet offenbar zu ungenau bzw. rundet die Positionen der sticky-Zellen anders als die Zellen in der Table.

Aber auf meinem Handy klebt immer noch nichts. Ist das mein Handy? Oder mach ich da generell noch was falsch?

Rolf

[JürgenB]

Hallo Rolf,

beim iPhone funktioniert die Kombination seperate und 50/50.

Gruß
Jürgen

[Gunnar Bittersmann]

@@Rolf B

Aber das Ding hat seine Tücken.

(1) Generell ergibt sich der Mist, dass der linke und rechte Rand der Datumsspalte nicht sticky sind, sondern mit dem Rest nach links verschwinden. Bäh.

Ja, ist bäh. Das war mir bei meinen Versuchen vor ein paar Tagen auch aufgefallen. Ich hab deshalb bei den sticky Kopfzellen border-inline entfernt und die Linien mit box-shadow: inset gemacht. Bei fetten Rahmen müsste man padding-inline entsprechend vergrößern.

Und links guckt dann auch noch der gescrollte Teil der Tabelle durch. BÄH.

Das ist bei deinem Beispiel auch noch nach o.g. Umbau so. Bei meinem aber auch bei fetten Rahmen nicht. Irgenwas machst du anders?

---

BTW, ich hab bei mir auch noch eine Unstimmigkeit gefunden: Wenn das Fenster so schmal ist, dass die Spalte Equatorial radius (und gar auch Mass unter die Kopfzelle scrollt, dann bleibt das ♁-Sybmbol sichtbar. Durch translate ist es über der Kopfzelle.

Damit z-index: -1 wirkt, muss man noch relativ positionieren. Dann kann man statt translate auch top nehmen: Version 3.

Jolan tru

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Irgendwas machst du anders?

Ah ja. Ich hab die Tabelle in einen Scrollcontainer gewrapt, wodurch einige Unschönheiten vermieden werden.

In Version 4 hab ich dem Ding noch tabindex="0" weggenommen (und role="region" und aria-labelledby gleich mit). Den Tastaturfokus setzen Browser bei überbreiten Elementen jetzt wohl alleine, wenn es nötig ist.

Und auch nur dann. Bis Version 3 war das Ding immer in der Tab-Reihenfolge; auch bei breiten Viewports, wo es gar nichts horizontal zu scrollen gibt.

Jolan tru

[Rolf B]

Hallo,

so, der Scroll-Container hat auch meinem Handy geholfen, und ich habe die Visualisierung der Varianten nochmal vereinfacht, so dass es jetzt "Basic", "Modell A" (=Fummelei Rolf) und "Modell B" (=Fummelei Gunnar) gibt.

Als zweite Auswahl habe ich die Einheit für die Paddings, denn die verhageln unter Chrome (nicht Edge!) das Layout. Es gibt

• em
• em gerundet: round(0.2em, 1px)
• px

round() erwies sich in meinen Tests als eine brauchbare Methode, den em-Angaben unter Chrome die Rundungsfehler auszutreiben und ist laut MDN seit einem Jahr Baseline. Gunnar hat sich in seinen Codepens diesem Problem geschickt entzogen, indem er vertikal 0.25em verwendet hat. Bei 16px Fontsize ist er dann aus dem Schneider. Aber das ist ja nicht verallgemeinerbar.

Bevor ich das in den sticky-Artikel einbaue, bitte ich nochmal einen Blick auf das Beispiel zu werfen. Es soll

• unterschiedlichen Varianten auswählbar haben
• das verwendete CSS visualisieren
• die Darstellung zeigen

Mit den Farben bin ich noch nicht glücklich. Ich will im Beispiel keine Styles aus dem Makeover-Skin einbinden, und das Selfhtml-Skin ist im Dark-Mode untauglich. Deshalb ist - bei mir - bei aktiviertem Browser-Darkmode der Scrollbar kontrastschwach. Das guck ich mir noch an, meine Frage ist nur, ob ein solches visualisierendes Beispiel brauchbar ist.

Tabelleninhalte kann man auch noch verschönern, Gunnars Planetentabelle ist eine gute Idee, die würde ich gern übernehmen.

Rolf