Vorlage Diskussion:Tabellenstile

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Änderung mw-datatable und Erweiterung um sticky[Quelltext bearbeiten]

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)Beantworten[Beantworten]

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)Beantworten[Beantworten]
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)Beantworten[Beantworten]
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)Beantworten[Beantworten]
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)Beantworten[Beantworten]
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)Beantworten[Beantworten]
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)Beantworten[Beantworten]
.tabelle-zeile-fixieren ähnlich zu excel (fixieren find eich verständlicher als sperren) --Wetterwolke (Diskussion) 21:47, 22. Feb. 2022 (CET)Beantworten[Beantworten]
.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)Beantworten[Beantworten]
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)Beantworten[Beantworten]
.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)Beantworten[Beantworten]
.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)Beantworten[Beantworten]
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)Beantworten[Beantworten]
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)Beantworten[Beantworten]
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)Beantworten[Beantworten]
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)Beantworten[Beantworten]
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)Beantworten[Beantworten]
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)Beantworten[Beantworten]
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)Beantworten[Beantworten]
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)Beantworten[Beantworten]
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)Beantworten[Beantworten]

Zeilennummerierung[Quelltext bearbeiten]

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)Beantworten[Beantworten]

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