Vorlage Diskussion:Tabellenstile

Änderung mw-datatable und Erweiterung um sticky

Es gab ja schon eine Vordiskussion dazu auf MW/Ä, ich möchte hier nochmal meine Vorschläge anbringen.

• mw-datatable: ist m.E. schlecht benannt, Klassen mit mw-Präfix sollten wir nicht lokal irgendwie belegen und datatable ist auch komplett nichtssagend hinsichtlich des eigentlichen Effekts bei einer Einbindung. Vorschlag daher: Alternativname table-hover mit allmählicher Migration dorthin.
• sticky-Tabellenköpfe: wird schon manuell verwendet (daran bin ich nicht ganz unschuldig), aber oftmals rudimentär und mit blöden Auswirkungen auf Wikitable-Tabellenheader (Zellenränder verschwinden). Vorschlag daher table-header-sticky mit Realisierung wie Vorlage:Denkmalliste Sachsen Tabellenkopf/styles.css (was ich auch nur von XaXens Vorlage:Charttabelle/styles.css gemopst habe). Da müsste man evtl. nochmal über den neuen Vector und seinen sticky Seitenheader nachdenken, da gab es ja Interferenzen, ich finde nur grad die Diskussion dazu nicht mehr.

Gruß, -- hgzh 18:18, 20. Feb. 2022 (CET)

Zu letzterem Punkt: Der Task war phab:T289817, ist mittlerweile fast funktional (bloß in der Diff-Ansicht gibt es noch einen Bug). Per aktueller Definition erwartet MediaWiki die Klasse mw-sticky-header-element oder charts-stickyhead, mit anderen Namen würde es einen Clash geben. --XanonymusX (Diskussion) 19:06, 20. Feb. 2022 (CET)

Ah danke, genau das. Gut, also könnte man notfalls mw-sticky-header-element nehmen darum bitten, einen allgemeineren Bezeichner aufzunehmen, der dann auch für die Charts gelten könnte. Gruß, -- hgzh 19:28, 20. Feb. 2022 (CET)

Was mw-datatable angeht, so ist das der einstweilige Ersatz für Bestands-Seiten, bei denen die Benutzies keinen Bock haben alle Klassennamen in womöglich verschachtelten Einbindungen umzustellen, und nur einmal diesen Polyfill in die oberste Seite in die erste Zeile reinklatschen.

• MediaWiki hat in Person meines speziellen Freundes mw-datatable außerhalb von Spezialseiten aufgegeben und herrenlos zurückgelassen.

table-hover muss leider ausscheiden, weil das ein Name ist, der sowohl von MW (die prefixen leider bis heute nicht konsequent mit mw-) oder von der enWP für was Ähnliches aber nicht das Gleiche verwendet werden könnte.

• Wir müssten entweder eindeutig deutschsprachige Selektoren definieren, oder mit dewiki- prefixen.
• Über die Zigtausende englischsprachiger Klassennamen hat schon MW um 2010 komplett den Überblick verloren, die navigieren auch nur nach Versuch und Irrtum.

table-header-sticky muss leider ausscheiden, aus den gleichen Gründen. Entweder klar deutschsprachig oder mit dewiki-, aber niemals wieder in den Seiten und zahlreichen Vorlagen und in den Köpfen Hunderter Autoren ausgestreut irgendwelche pseudo-englischen Klassennamen wie dieses bescheuerte metadata, das dann prompt zu einer Namenskollision führte.

VG --PerfektesChaos 19:39, 20. Feb. 2022 (CET)

Sodele, ich hab dann mal eine Nacht drübergeschlafen und das schöne deutsche Wort tabelle- hiermit für alle zukünftigen umseitigen lokalen Träume reserviert.

Wenn in der enWP oder bei MW in einer Extension oder im Chor irgendwer einen Klassennamen braucht, dann wird die erstbeste englische Kombination aus Wörtern genommen, völlig egal ob es das schon gibt und womit es kollidieren könnte.

• Und was in der enWP steht, kommt per halbgarer C&P-Übersetzung über kurz oder lang auch bei uns an.

Wenn wir exakt eine MW-Funktionalität übernehmen, die bloß als Module nicht in unsere Textseiten eingebunden sind, zumindest nicht immer, oder nur auf Spezialseiten, dann sollten wir auch genau deren Klassenbezeichner übernehmen und die MW-Deklarationen ggf. nachführen.

VG --PerfektesChaos 15:56, 21. Feb. 2022 (CET)

Puh, jetzt nötigst du mir aber eine Übersetzung von hover und sticky auf ;) Denglisch wäre ja blöd. Muss ich erstmal drüber nachdenken, die Tagesration Gehirnschmalz ist heute schon für den Brötchengeber drauf gegangen. Gruß, -- hgzh 19:01, 21. Feb. 2022 (CET)

Und wieder eine Nacht zum Drüberschlafen; bin erstmal bis hover gekommen in meinen Träumen; nach Länge sortiert:

• .tabelle-aktivzeile
• .tabelle-aktive-zeile
• .tabelle-aktive-zeile-hervorheben
• .tabelle-zeile-hervorheben-wenn-cursor-schwebt

Es gibt ja irgendwelche Ideen, dass eine Kopf- oder auch Fuß- und Legendenzeile immer sichtbar sein soll, und diese Zeile zu kennzeichnen ist:

• .tabelle-festposition
• Eigentlich soll dieser Effekt schon seit über 20 Jahren für <thead> und <tfoot> standardmäßig von allen Browsern dargestellt werden, mit Scrollen über die Zeilen von <tbody> falls nicht auf den aktuellen Fensterausschnitt passend, aber irgendwie isses noch nicht so weit.

VG --PerfektesChaos 10:26, 22. Feb. 2022 (CET)

.tabelle-zeile-fixieren ähnlich zu excel (fixieren find eich verständlicher als sperren) --Wetterwolke (Diskussion) 21:47, 22. Feb. 2022 (CET)

.tabelle-zeile-aktiv und .tabelle-kopf-fixiert wären nun meine Favoriten, zwecks Konsitenz von Tabelle über Ziel (Zeile/Kopf) zu Funktion (aktiv/fixiert). Gruß, -- hgzh 22:38, 3. Mär. 2022 (CET)

Habe die Klasse jetzt mal in freier Wildbahn getestet und war etwas verwirrt vom Verhalten. Ist wohl nur schwer mit Inline-Anweisungen kombinierbar (zumindest finde ich die Vergabe der Klasse direkt an die Kopfzeile unlogisch). Wäre sicher klüger, wenn wir direkt eine zentrale Lösung per Klasse anbieten, statt derlei Basteleien im ANR zuzulassen, die dann im neuen Vector spurlos verlorengehen. --XanonymusX (Diskussion) 23:48, 22. Feb. 2022 (CET)

.tabelle-zeile-aktiv ist nun umseitig live, ich kümmere mich die Tage noch um die Doku. sticky folgt dann später. -- hgzh 20:08, 15. Mär. 2022 (CET)

.tabelle-kopf-fixiert funktioniert nun auch, bisher wird aber auch mw-sticky-header-element benötigt für den neuen Vector. @XanonymusX kannst du dir vorstellen, innerhalb deiner Chartvorlagen auf tabelle-kopf-fixiert umzusteigen? Dann könnten wir um eine Aufnahme dieser allgemeinen Klasse ins Stylesheet bitten und lokal auf die mw-Klasse verzichten. Gruß, -- hgzh 13:20, 7. Okt. 2022 (CEST)

Muss ich mir noch technisch überlegen. Der Klassenname ist zum Glück nur geringfügig länger als der bisherige, sollte also unproblematisch sein, aber das zweite Stylesheet möchte ich nicht einbinden. Wobei ich auch nicht glaube, dass die Entwickler die Aufnahme der neuen Klasse von der Streichung der alten abhängig machen würden. Eher frage ich mich, ob wir die Platzierung der Klasse ganz durchdacht haben; laut meinen letzten Diskussionen auf Phabricator sollte die Klasse zukünftig in den thead von Tabellen, wenn der Tag denn endlich erlaubt wird. Ansonsten kann der neue Vector nicht in allen Fällen damit umgehen. Sollen wir uns in die Richtung noch etwas umhören? Der Task wäre phab:T289817 (bzw. der dort zuletzt erwähnte). Gruß—XanonymusX (Diskussion) 21:59, 8. Okt. 2022 (CEST)

Hm, zwischen der Tabellensyntax dann mit HTML-Tags herumzufrickeln ist aber mE auch nicht besonders nutzerfreundlich oder verständlich. Innerhalb von Vorlagen würde das noch gehen, aber frei im ANR finde ich das schwierig.

Wenn das Ergänzen weiterer Klassen kein Problem ist, dann können wir die chartspezifische natürlich auch behalten. -- hgzh 20:22, 10. Okt. 2022 (CEST)

Also, das Gedöns mit thead (und tfoot) wurde schon 1998 in HTML.4 konzipiert, und ist Stand heute in den Browsern eher nicht umgesetzt. Würde ich ja nich erst ignoriern, und unseren bisherigen Weg weiterverfolgen.

Nachdem MW von sich aus eine robuste Lösung zur Nutzung dokumentiert hat, können wir uns denen anpassen.

Bis dahin unseren eingeschlagenen Weg weiter, auch in den Charts ist es bis zum großen Aufräumen egal.

Sollte eine Migration außer an ein paar Vorlagen im ANR-Bestand erforderlich werden, sieht das hier gut Bot-geeignet und unkompliziert aus.

VG --PerfektesChaos 22:18, 10. Okt. 2022 (CEST)

In allen aktuellen Browsern funktioniert thead mittlerweile (seit diesem Jahr!) tatsächlich, daher dürfte langsam wieder Bewegung in den verstaubten Task kommen. Bis dahin müsste auf jeden Fall von der Nutzung fixierter Tabellenköpfe bei mehrzeiligen Headern abgeraten werden. Ansonsten für mich alles okay, wir müssten dann nur die Berücksichtigung der Klasse anfragen. Gruß—XanonymusX (Diskussion) 00:16, 11. Okt. 2022 (CEST)

Zurzeit weitermachen wie bisher, keine Maßnahmen von uns, keine Anfragen.

• Erstmal muss MW zu einem stabilen Zustand finden und zur Verwendung durch Wikis dokumentieren. Das kann 2024 werden.
• Vorher bringt Einmischung nur Verwirrung und wäre nicht nachhaltig.

Quelltext-Seiten (ANR und Vorlagen), die umseitig direkt einbinden und die Klasse zuweisen, lassen sich leicht identifizieren und später auf den endgültigen Zustand nacharbeiten. Das geht zumindest leichter als an irgendwelchen Elementen irgendwie mit hineingefrickeltem style=.

Das ganze Feature ist nur eine freundliche Erleichterung für besseres Lesen, nicht spezifisch für irgendeine besondere Tabelle sondern sollte wie schon 1998 vorgesehen unaufgefordert Standard für jede Tabelle sein. Wenn Leute das heute schon unbedingt verbauen müssen dann sollten sie es besser mit class= als mit style= machen. Wenn es gelegentlich nicht wirksam wäre passiert den Inhalten überhaupt nix.

MW müsste alle vollständigen !-Zeilen, die unmittelbar auf die Tabelleneröffnung folgen, unaufgefordert dem thead zuordnen, und alle !-Zeilen, auf die am Ende keine | mehr folgen, in den tfoot stecken. Danach kann das gesamte Gefrickel hier wieder eliminiert werden. Den Rest machen die Browser dann von selbst. Die identische Logik könnten Browser sogar von sich aus auf die direkten table-Kinder oder sogar den tbody anwenden, seit Jahrzehnten.

VG --PerfektesChaos 08:43, 11. Okt. 2022 (CEST)

Alles richtig, allerdings ist ja angedacht, dass der neue Vector Ende des Jahres Standard wird (bin noch skeptisch, so wie ich die Community kenne, aber zumindest wäre es der Plan). Damit wäre der Nutzen unserer hier entworfenen Lösung wieder dahin. Aber gut, man kann immer noch mw-sticky-header-element ergänzen. Gruß --XanonymusX (Diskussion) 12:51, 11. Okt. 2022 (CEST)

Eine Klassendefinition kann in ein, zwei .css-Seiten schnell mal aktualisiert, per C&P erstmal reingepflegt werden.

Oder komplett eliminiert, wenn irgendwann die Browser das von sich aus so machen wie seit 1998 vorgesehen.

Ob wir hingegen mw-sticky-header-element verwenden können und ob das CSS in der Seite verfügbar ist, ergibt sich erst nach offizieller MW-Doku und Freigabe.

Lästig und zwingend zu vermeiden sind inline-style im ANR, weil die können sich irgendwann mal behindernd auswirken.

Wenn Inhaltsbereiche von einem Vector-Skin abhängen sollen, dann läuft aber irgendwas sehr schief. Das ist dann auch nicht robust und stabil. Nur die Fenstergröße (mobil) oder Breite des Inhaltsbereichs mag von Benutzersituation und Skin abhängen.

VG --PerfektesChaos 13:09, 11. Okt. 2022 (CEST)

Dank Wurgl ist tabelle-kopf-fixiert jetzt breitflächig in Benutzung und die Inline-Bastelei bis auf wenige Restfälle entfernt. Um die kümmere ich mich dann die Tage. Wahrscheinlich muss in ein paar Wochen die umseitige Definition noch einmal angepasst werden, weil der Header noch etwas eingekürzt werden soll. -- hgzh 14:06, 23. Jan. 2023 (CET)

Schön! :) Eventuell gibt es auch noch Namensraum-Änderungen, aktuell ist der Header ja nicht in allen Namensräumen verfügbar, das könnte aber noch geändert werden. Wir werden sehen! Gruß --XanonymusX (Diskussion) 15:30, 23. Jan. 2023 (CET)

Zeilennummerierung

Ich plane eine etwas verbesserte Implementierung von en:Template:Static row numbers. Der Wunsch nach einer solchen Nummerierungsfunktion kommt ja nun recht häufig, und die zugrundeliegende CSS-Technik scheint mir inzwischen ausreichend weit verbreitet und stabil. -- hgzh 13:11, 24. Jan. 2023 (CET)

work in progress hier: https://de.wikipedia.beta.wmflabs.org/wiki/Benutzer:Hgzh/rownumbers -- hgzh 20:30, 24. Jan. 2023 (CET)

Ich würde das gern demnächst hier einführen, vielleicht mag ja noch jemand Feedback geben zum Thema Bezeichner etc. pp. Gruß, -- hgzh 22:32, 17. Mai 2023 (CEST)

Mir gefällts! :) --XanonymusX (Diskussion) 22:45, 17. Mai 2023 (CEST)

Ich finds toll, habe ich schon lange vermisst! Danke! Glückauf, fcm. --Frank C. Müller (Diskussion) 13:51, 17. Jul. 2023 (CEST)

tabelle-kopf-fixiert bei mehrzeiligen header

Bei dieser Tabelle mit 1 bis 2 Kopfzeilen verschwindet "Länge" und "Station Höhe (m)". Optimal wäre, dass dies sichtbar bleibt. --Enhancing999 (Diskussion) 10:31, 11. Feb. 2023 (CET)

Richtig, das ist aber unter den gegebenen Umständen derzeit nicht möglich. -- hgzh 11:52, 11. Feb. 2023 (CET)

Vorlage:Charttabelle/styles.css löst das Problem irgendwie, vgl. Elvis_Presley/Diskografie. --Enhancing999 (Diskussion) 13:54, 11. Feb. 2023 (CET)

Tabellenüberschrift ("Caption") bei tabelle-kopf-fixiert

Bei Seiten mit mehreren Tabellen könnte es hilfreich sein, wenn auch die Tabellenüberschrift oben bleibt. --Enhancing999 (Diskussion) 10:35, 11. Feb. 2023 (CET)

Das funktioniert leider nicht, weil für eine Anzeige von Überschrift und Kopfzeile die Höhe der Überschriftenzeile bekannt sein müsste, die aber bekanntlich umbricht und somit variabel ist. -- hgzh 11:56, 11. Feb. 2023 (CET)

Könnte man es fixieren mit der Annahme, dass es nur eine Zeile ist? --Enhancing999 (Diskussion) 12:04, 11. Feb. 2023 (CET)

Nein, das wäre keine robuste Programmierung. Da reicht schon ein größerer Browserfont, ein schmalerer Bildschirm, der Text bricht um und es entsteht ein unerwünschter Effekt. -- hgzh 12:10, 11. Feb. 2023 (CET)

Verstehe. Im Vergleich zu (allen) Spaltenüberschriften könnten captions doch eher kurz sein. --Enhancing999 (Diskussion) 12:18, 11. Feb. 2023 (CET)

Ja, könnten, sind sie aber nicht immer (die Definition würde dann ja für alle Tabellen gelten), und auch kurze captions können umbrechen. -- hgzh 12:52, 11. Feb. 2023 (CET)

Es müsste wohl eine separate class sein (z.B. "tabelle-kopf-fixiert-mit-caption"). Kann ein "nowrap" bei captions gesetzt werden? --Enhancing999 (Diskussion) 13:55, 11. Feb. 2023 (CET)

Konflikt mit user css

Ich checks grad nicht. In Liste der denkmalgeschützten Objekte in Prigglitz ist der dritte Eintrag mit Datenfehler markiert, was in der Vorlage {{Denkmalliste Österreich Tabellenzeile}} zu class="BDAerror" führt. Über Benutzer:Herzi Pinki/vector.css wird dem ein abweichendes Styling zugeordnet. Ich sehe im Inspektor sowohl die Klasse BDAerror als auch die Definition aus Benutzer:Herzi Pinki/vector.css. Nur im gerenderten Text sehe ich mein Styling nicht. Nehme ich die {{Tabellenstile}} aus {{Denkmalliste Österreich Tabellenkopf}} heraus, dann sehe ich mein Styling wieder. Wo ist das Problem und wie kann ich / man das fixen? lg --Herzi Pinki (Diskussion) 19:09, 28. Mai 2023 (CEST)

Ursache ist border-collapse:separate in der Tabellenstile-Definition, die für die korrekte Anzeige der Kopfzeile benötigt wird. Eine Möglichkeit, dies zu überschreiben, wäre

table.wikitable.tabelle-kopf-fixiert:has(.BDAerror) {
  border-collapse: collapse !important;
}

Das funktioniert aber bspw. im Firefox noch nicht standardmäßig, da :has() relativ neu ist. Eine andere Variante ist mir jetzt grad auch nicht eingefallen. -- hgzh 08:11, 30. Mai 2023 (CEST)

Danke für die Analyse. lt. Wikipedia:Technik/Skin/CSS#CSS-Benutzerseiten sollte mein !important wichtiger sein? Hab's jetzt auf background-color geändert, das funktioniert. lg --Herzi Pinki (Diskussion) 21:03, 30. Mai 2023 (CEST)

Sorry für die späte Antwort: theoretisch zwar ja, aber durch das Separieren der Zellumrandung werden einzelne Definitionen für die Zellränder irgendwie wirkungslos, so ganz bin ich da aber auch nicht durchgestiegen. Gruß, -- hgzh 14:41, 20. Jun. 2023 (CEST)

Anker und tabelle-kopf-fixiert

Scheint irgendwie nicht optimal. vgl. #Test_4 --Enhancing999 (Diskussion) 14:14, 20. Jun. 2023 (CEST)

Lösung wäre folgende:

body:not(.skin-vector-2022) table.wikitable.tabelle-kopf-fixiert td,
body:not(.skin-vector-2022) table.wikitable.tabelle-kopf-fixiert tr {
	scroll-margin-top: 3em;
}

... wird aber vom (leider in dieser Hinsicht nicht aktuellen) CSS-Sanitizer abgelehnt. Ist also derzeit nichts zu machen. Gruß, -- hgzh 14:36, 20. Jun. 2023 (CEST)

Zähler als letzte Spalte

Ist es möglich den Zähler auf der rechten Seite einer Tabelle anzuzeigen? --Enhancing999 (Diskussion) 13:55, 2. Jan. 2024 (CET)

Sollte gehen, erfordert aber das Duplizieren sämtlichen Codes und folgend dessen redundante Pflege. Aufwand größer Nutzen. -- hgzh 10:33, 5. Jan. 2024 (CET)

tabelle-kopf-fixiert und Vector2022

Irgendwie scheint das nicht ganz zu funktioniert, vgl. Wikipedia_Diskussion:WikiProjekt_Schweiz#Kaputte_Vorlagen_"Liste_der_Kulturgüter_in..._"_und_"Liste_der_Kunstwerke_im_öffentlichen_Raum_in...". --Enhancing999 (Diskussion) 00:17, 8. Jun. 2024 (CEST)

phab:T366314. -- hgzh 11:09, 8. Jun. 2024 (CEST)

Ich habe das Problem in Vorlage:Charttabelle/styles.css jetzt erst einmal mit genereller Deaktivierung des overflow-x gelöst (damit funktionieren der Sticky Header und das CSS-Tooltip wieder). Keine Ahnung, ob das bei anderen Elementen Nebenwirkungen hat. --XanonymusX (Diskussion) 21:24, 9. Jun. 2024 (CEST)

Das sieht so aus: Liste der Kulturgüter in Aarberg

Ob man das als Lösung bezeichnen kann, bezweifle ich.

Komischerweise finden sich derartige "Stapelungen" der Kopfzeile nicht auf Seiten wie z.B. Liste der Kulturgüter in Bannwil (nur ein Zeilenbereich)

Mengengerüst: Es handelt sich so um die 1800 Listen, welche, falls Vector 2022 verwendet wird, visuell verhunzt sind.

Anmerkung: Ich bin weder Techie noch Coder oder CSS Dude. Nur ein Anwender.

just my 2 cents --AnBuKu (Diskussion) 22:33, 12. Jun. 2024 (CEST)

Liste der Kulturgüter in Bannwil verwendet auch keine fixierte Kopfzeile. Der Hinweis von XanonymusX bezog sich auf Charttabellen, nicht die hiesige Vorlage. Gut finde ich die Lösung aber nicht, weil diese sämtliche responsive Tabellen auf der Artikelseite deaktiviert, also auch an Stellen wirkt, die nicht vorhersehbar sind. -- hgzh 07:49, 13. Jun. 2024 (CEST)

Ja, ich verstehe allerdings auch gar nicht, wozu overflow-x gut sein soll, es kann doch nicht gewollt sein, dass Tooltips etc. ober- oder unterhalb einer Tabelle abgeschnitten werden. Werde ich nach der nächsten Korrektur wieder testen … --XanonymusX (Diskussion) 08:01, 13. Jun. 2024 (CEST)

Es geht darum, dass die Tabellen nicht in die Seitenleiste ragen, aber ja, durch den overflow gibt es einige Folgeprobleme. Auch die Lösung, eine Höhe anzugeben, wie umseitig eingesetzt, würde ich eher als absolute Notlösung ansehen, die selbst wieder Probleme schafft. -- hgzh 08:10, 13. Jun. 2024 (CEST)

Ah ja, ich gehe gerade den verlinkten Bugreport durch, ziemliche Bastelei alles. Deaktivierung des Overflows für bestimmte Elemente (die wie die Charttabellen ohnehin responsiv sind) wäre wohl das sinnvollste. Ich setze mich wieder ran, wenn die Änderungen durch sind. --XanonymusX (Diskussion) 08:15, 13. Jun. 2024 (CEST)

Jetzt auch phab:T367369. -- hgzh 08:39, 13. Jun. 2024 (CEST)

Damit ich es nicht vergesse, denke es passt aber irgendwie hier:

Vielleicht wäre es sinnvoll, bei breiten Listen, statt nur einem Slider (dem sagt man glaubs so) unten auch einen Slider oben an der Liste zu haben.

Ist-Zustand: Benutzer:AnBuKu/Liste der Kunstwerke im öffentlichen Raum in Bern/Kirchenfeld-Schosshalde

Ich stelle mir den Leser vor, welcher den Artikel anklickt und nur einen Teil der Liste sieht und vielleicht nicht auf die Idee kommt, runter und runter und runter zu scrolen bis zu dem "Slider". Für diesen Leser wäre es vielleicht noch hilfreich, wenn er gleich oben ein "Instrument hat um die Liste zu seitlich zu verschieben.

Nur so ein Gedanke. Und Danke für eure Arbyte. cheeers, --AnBuKu (Diskussion) 14:26, 13. Jun. 2024 (CEST)

„Slider“ passt schon, offiziell wäre scrollbar, deutsch „Schieberegler“ oder „Schieber“ oder so.

Wir können aber nur dem Browser sagen, dass wir sowas haben möchten, oder ob er abschneiden soll was zu breit ist.

Wie der Browser das macht, ist sein Ding.

VG --PerfektesChaos 15:09, 13. Jun. 2024 (CEST)

Schade, nix W3C oder RFC oder so. Wie auch immer. Danke für deine Antwort. cheeers, --AnBuKu (Diskussion) 15:14, 13. Jun. 2024 (CEST)

@PerfektesChaos Ich kenne das Problem auch (aus meiner Arbeit als Webentwickler). Mit den Mitteln, die ich auf Arbeit habe, hätte ich die gesamte Tabelle in einen Bereich gepackt, der maximal so hoch ist wie ca. 90% der viewPort-Höhe (also der sichtbare Bereich des Browserfensters), so dass die horizontale Scrollbar unten gleich sichtbar ist, und dass man innerhalb dem den Tabelleninhalt (falls zu hoch) hoch- und runterscrollen kann. Aber ob das hier mit Bordmitteln (CSS, HTML, die aus den Vorlagen kommen) möglich ist, kann ich schlecht sagen.

HaTeEmEllige und ZehEsEssige Grüße --Hlambert63 (Diskussion) 17:27, 13. Jun. 2024 (CEST)

Irgendwie tut's da gar nicht -> Benutzer:AnBuKu/Liste der Kunstwerke im öffentlichen Raum in Bern/Innere Stadt (Ost) ist halt etwas doof, da Kopfzeile die ersten Zeilen verdeckt :( --AnBuKu (Diskussion) 17:20, 17. Jun. 2024 (CEST)

Mir ist ein Problem mit der ersten Tabelle in der Liste der Hochhäuser in Deutschland aufgefallen. Die Kopfzeile verdeckt dabei die erste Zeile, so dass zum Beispiel statt Frankfurt am Main nur Main sichtbar ist. Entspricht das den vorherigen Problemen oder ist das ein neues Problem nach der Umstellung auf mw:MediaWiki_1.43/wmf.17.? Zur Lösung des Problems: Ist es akzeptabel, ein "float:left" wie hier einzufügen?--Kallichore (Diskussion) 21:56, 9. Aug. 2024 (CEST)

Der vor Monaten oben genannte Phabricator-Eintrag wurde wenige Tage später als gelöst markiert, aber ich habe das Problem mit tabelle-kopf-fixiert und Vector2022 immer noch, und zwar nur mit Firefox und interessanterweise nur eingeloggt (also ausgeloggt auch mit ?useskin=vector-2022 nicht), und das obwohl ich kein einschlägiges Benutzer-CSS (oder Benutzer-Javascript) habe und auch bei Helferlein und sonstigen Einstellungen wohl weitgehend die Standardeinstellungen benutze. Wenn ich im CSS-Inspector das "top: 3.125rem;" entferne, sehen die betroffenen Denkmallisten bei mir wieder gut aus. --Karotte Zwo (Diskussion) 17:39, 11. Sep. 2024 (CEST)

Unangemeldet wird offenbar der sticky header von Vector-2022 nicht angezeigt, wodurch der Sonderfall nicht aktiviert wird und der Kopf nicht verschoben ist. Es bleibt aber das Problem, dass der fixierte Tabellenkopf nicht funktioniert. Der aktuelle Task ist phab:T367369. Wahrscheinlich ist, dass folgendes passiert:

• man wird den x-overflow deaktivieren können, indem man die Tabellen in einen einfachen div-Container packt. Das hat zur Folge, dass große Tabellen wie anfangs wieder über die Seitenleiste laufen.
• man kann eine fixierte Höhe angeben und basteln (auch nicht toll, schon gar nicht als Universallösung).
• eine andere Möglichkeit, die fixierten Tabellenköpfe zu erhalten, gibt es nicht.

Nicht sicher bin ich mir, ob irgendwann Container-Style-Queries die Lösung sind, das können die Browser nur noch nicht.

Da eine kurzfristige Lösung nicht absehbar ist, könnte der Sonderfall für Vector-2022 mit aktiviertem Sticky Header entfernt werden, dann wären zumindest die Tabellenköpfe nicht mehr verschoben. -- hgzh 17:58, 11. Sep. 2024 (CEST)

@Karotte Zwo: Ich sehe dieses Verhalten unter Vector-2022 (verschobener Kopf bei Anmeldung, keine Verschiebung ohne Anmeldung) gleichermaßen unter Firefox, Chrome und Edge.--Kallichore (Diskussion) 18:17, 11. Sep. 2024 (CEST)

Hmm. Unter Chrome hatte ich wahrscheinlich nur abgemeldet (aber mit Vector-2022) getestet. Aber auch wenn ich mich dort jetzt anmelde, sieht https://de.wikipedia.org/wiki/Liste_der_Kulturg%C3%BCter_in_Aarberg?useskin=vector-2022 immer noch gut aus. --Karotte Zwo (Diskussion) 09:18, 12. Sep. 2024 (CEST)

Siehst du denn den Kopfbereich mit dem Artikeltitel, der sich mit dem Scrollen nach unten von oben aufklappt? Wenn nicht, evtl. JavaScript deaktiviert? -- hgzh 09:48, 12. Sep. 2024 (CEST)

Stupid me! Ja, ich benutze Chrome eigentlich nicht, daher wusste ich gar nicht mehr, dass ich da mal NoScript installiert habe. Mit JavaScript isses genauso kaputt wie im Firefox. Sorry für die Verwirrung! --Karotte Zwo (Diskussion) 15:02, 12. Sep. 2024 (CEST)

Ich habe im o.g. Task jetzt nochmal zum weiteren Vorgehen nachgefragt. Melde mich nochmal. -- hgzh 15:15, 12. Sep. 2024 (CEST)