Hilfe Diskussion:Tabellen für Fortgeschrittene/Archiv/1

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Hilfe Diskussion:Tabellen für Fortgeschrittene/Archiv/1#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Hilfe_Diskussion:Tabellen_f%C3%BCr_Fortgeschrittene/Archiv/1#Thema_1

- 2007 -

CSS vs. HTML

Hallo allezusammen, ich habe mir gerade die Tabellen-Referenz angeschaut und musste feststellen, dass hauptsächlich (aber nicht ausschließlich) HTML-Befehle empfohlen werden. Was spricht gegen eine generelle Empfehlung, alle Formatierungen durch CSS-Anweisungen zu auszudrücken? --Cepheiden 11:24, 1. Aug. 2007 (CEST)

Ich wüsste keinen Grund der dagegen spricht, was per CSS machbar ist, darf gerne per CSS gemacht werden. Gruß --W_I^KImaniac 13:55, 2. Mär. 2008 (CET)

Es geht nicht darum ob man CSS nutzen kann, sondern ob die Nutzung empfohlen wird. --Cepheiden 16:19, 2. Mär. 2008 (CET)

Ja, so war meine Antwort auch zu interpretieren, wenn ich's auch nicht explizit geschrieben habe. Ich würde die Verwendung von CSS empfehlen, selbstverständlich nur da, wo es der MediaWiki-Parser zulässt. Gruß --W_I^KImaniac 17:45, 2. Mär. 2008 (CET)

- 2008 -

Überschrift fixieren

Ist es möglich, dass Tabellenüberschriften immer sichtbar zuoberst stehen bleiben und sich nur der Tabellen-"Inhalts"-Teil bewegen lässt??? --Lantus 11:55, 10. Feb. 2008 (CET)

Was meinst du mit bewegen? --Marcel1984 ^{(?! | ±)} 12:13, 10. Feb. 2008 (CET)

Falls diese bspw. aus Microsoft Excel bekannte Funktionalität gemeint ist, nein, das geht leider nicht. Gruß --W_I^KImaniac 12:56, 10. Feb. 2008 (CET)

Ja, etwas in der Art habe ich gemeint. Von mir aus auch zwei Tabellen: die erste bleibt stehen, die andere bekommt eine Bildlaufleiste. :-|| --Lantus 13:05, 10. Feb. 2008 (CET)

Das wäre zwar ein möglicher Workaround, der aber dazu führen würde, dass beim Ausdrucken entsprechende Teile der Tabelle nicht sichtbar wären. Daher sind solche Lösungen in der Wikipedia eher nicht so gern gesehen. Gruß --W_I^KImaniac 13:12, 10. Feb. 2008 (CET)

Das wäre dann noch die Frage… Aber lassen wir es halt so stehen. Das Erzeugen einer Druckvorschauseite zum Optimieren der Druckseiten ist ja offensichtlich im Wiki auch nicht erforderlich (oder gewollt!?). --Lantus 13:51, 10. Feb. 2008 (CET)

Doch, die gibt es wiederum. Du findest sie unter dem Link "Druckversion" im Abschnitt "Werkzeuge" auf der linken Seite dieser Seite. Gruß --W_I^KImaniac 14:10, 10. Feb. 2008 (CET)

Zellen in Spalte und Zeile zusammenfassen

Ich suche den Syntax um in einer Tabelle mit den Zeilen 1 bis 3 und den Spalten a bis c beispielsweise die Zellen A:1 bis B:2 zu einer Zelle zusammenzufassen. Gruss, --Markus 09:40, 2. Mär. 2008 (CET)

Das geht ähnlich wie bei normalen HTML-Tabellen mit colspan und rowspan (vgl. [1]) --Cepheiden 10:08, 2. Mär. 2008 (CET)

A1 & B1		C1
A2	B2	C2
A3	B3	C3

Siehe hierzu auch gleich „nebenan“ unter Hilfe:Tabellen-Referenz#Rowspanning und Colspanning. Gruß --W_I^KImaniac 13:54, 2. Mär. 2008 (CET)

Rowspan oder Colspan hatte ich verstanden. Ich suche aber nach einer Kombination, mit der ich die Zellen A1 B1 A2 B2 als "Viererblock" zusammenfassen kann. Gruss, --Markus 15:54, 2. Mär. 2008 (CET)

Musst du die beiden befehle eben kombinieren --Cepheiden 15:56, 2. Mär. 2008 (CET)

A1 & B1 &A2 & B2		C1
		C2
A3	B3	C3

Uff - das ist mir eine Nummer zu gross: Knotenkunde. Dort hätte ich gern "Prüfungsknoten" in einem Feld mit dem leeren darunter zusammengefasst... Danke, --Markus 19:54, 2. Mär. 2008 (CET)

So, bitte schön. --Cepheiden 19:57, 2. Mär. 2008 (CET)

Super Service! herzlichen Dank, --Markus 21:47, 2. Mär. 2008 (CET)

Spalten senkrecht beschriften

Ich suche den Syntax, um schmale Spalten im Kopf mit einer um 90° gedrehten Schrift zu bezeichnen.

Workaround:

!<!--Segeln CH--> style="vertical-align:bottom;"|S</br>e</br>g</br>e</br>l</br>n</br> </br>CH 

Gruss, --Markus 09:40, 2. Mär. 2008 (CET)

Ist meines wissens mit HTML-Tabellen und somit auch mit Wiki-Tabellen nicht möglich. Die Alternative mag ich persönlich nicht. --Cepheiden 10:13, 2. Mär. 2008 (CET)

Hallo Markus, es gibt hierfür unterschiedliche Optionen:

1. Die von Dir bereits genannten „br“-Methode.
2. Per CSS mittels writing-mode: tb-rl, was aber nur der Internet Explorer versteht.
3. Einbindung als Bild, dann aber bitte BIENE-konform.

Gruß --W_I^KImaniac 13:33, 2. Mär. 2008 (CET)

Spalten abwechselnd einfärben

Ich suche den Syntax, um Spalten abwechselnd einzufärben. (Antworten bitte als How-To auf die Hilfeseite) Gruss, --Markus 09:40, 2. Mär. 2008 (CET)

Hier gibts auch keine Automatik. Dies wäre mit JavaScript möglich, ist aber nicht gewünscht. Ähnlich wie Zebra-Tabellen in Zeilenkönnen diese auch leicht unübersichtlich werden, und wird eigentlich nicht bevorzugt in der Wikipedia. Hier bleibt aufgrund des starken Zeilenbezugs nur eine manuelle Angabe für jede Zelle als Alternative. --Cepheiden 10:18, 2. Mär. 2008 (CET)

Hallo Markus, das kannst Du wie folgt machen:

Code

{| class="prettytable"
|+Überschrift
|- style="background-color: #c9c9c9"
!
! Überschrift Spalte 1
! Überschrift Spalte 2
! Überschrift Spalte 3
|-
! style="background-color: #c9c9c9" | Zeile 1
| Zeile 1/Spalte 1
| Zeile 1/Spalte 2
| Zeile 1/Spalte 3
|- style="background-color: #efefef" 
! style="background-color: #c9c9c9" | Zeile 2
| Zeile 2/Spalte 1
| Zeile 2/Spalte 2
| Zeile 2/Spalte 3
|-
! style="background-color: #c9c9c9" | Zeile 3
| Zeile 3/Spalte 1
| Zeile 3/Spalte 2
| Zeile 3/Spalte 3
|- style="background-color: #efefef" 
! style="background-color: #c9c9c9" | Zeile 4
| Zeile 4/Spalte 1
| Zeile 4/Spalte 2
| Zeile 4/Spalte 3
|-
! style="background-color: #c9c9c9" | Zeile 5
| Zeile 5/Spalte 1
| Zeile 5/Spalte 2
| Zeile 5/Spalte 3
|- style="background-color: #efefef" 
! style="background-color: #c9c9c9" | Zeile 6
| Zeile 6/Spalte 1
| Zeile 6/Spalte 2
| Zeile 6/Spalte 3
|}

Vorschau

Überschrift

	Überschrift Spalte 1	Überschrift Spalte 2	Überschrift Spalte 3
Zeile 1	Zeile 1/Spalte 1	Zeile 1/Spalte 2	Zeile 1/Spalte 3
Zeile 2	Zeile 2/Spalte 1	Zeile 2/Spalte 2	Zeile 2/Spalte 3
Zeile 3	Zeile 3/Spalte 1	Zeile 3/Spalte 2	Zeile 3/Spalte 3
Zeile 4	Zeile 4/Spalte 1	Zeile 4/Spalte 2	Zeile 4/Spalte 3
Zeile 5	Zeile 5/Spalte 1	Zeile 5/Spalte 2	Zeile 5/Spalte 3
Zeile 6	Zeile 6/Spalte 1	Zeile 6/Spalte 2	Zeile 6/Spalte 3

Selbstverständlich kannst Du die beiden styles (style="background-color: #efefef" und style="background-color: #c9c9c9") auch in entsprechende Klassen in Deinem Wiki in der MediaWiki:Common.css ablegen:

.tabellenkopf {
   background-color: #c9c9c9;
}

.tabellenzeile {
   background-color: #efefef;
}

Du solltest allerdings auf Sortierbarkeit (class="sortable") bei solch eingefärbten Tabellen verzichten, da die Zeilen beim erstellen der Tabelle markiert werden, diese Markierung beim Umsortieren aber nicht neu berechnet wird, so dass u.U. gleichfarbige Zeilen aufeinander folgen können. Gruß --W_I^KImaniac 13:52, 2. Mär. 2008 (CET)

Nur nebenbei, es wurde nach Spalteneinfärbung und nicht nach Zeileneinfärbung gefragt. --Cepheiden 14:08, 2. Mär. 2008 (CET)

Autsch, hab ich glatt überlesen… ;-) Danke für den Hinweis! Naja, geht ja aber auch analog. Falls Markus auch dafür ein separates Beispiel haben möchte, bau ich's noch einmal um. Gruß --W_I^KImaniac 14:14, 2. Mär. 2008 (CET)

Lösung für eigentlich viel zu breite Tabelle

Hallo, ich suche nach Hilfe für den Artikel Upside Down Text: In diesem Artikel soll eine Tabelle mit den Maßen 30 Datensätze x 4 Spalten x 5 Zeichen breit sind hinein. Dies ist aber viel zu lang (bzw bei horizontaler Darstellung zu breit) für jeden Bildschirm. Beispiel für die Tabelle:

Original	ASCII-Zeichen	Unicode-Zeichen	Unicode-Entity
a	e	ɐ	ɐ
a	e	ɐ	ɐ
a	e	ɐ	ɐ
a	e	ɐ	ɐ
u.s.w. (insgesamt 30 Datensätze)	u.s.w.	u.s.w.	{

Wie soll ich das am besten lösen? Bis jetzt habe ich im Artikel die Tabelle horizontal gemacht (Datensätze in Spalten) und die zeichenintensive Angabe der Unicode-Entity erstmal weggelassen, bin damit aber nicht zufrieden --Mgmax 22:33, 21. Mai 2008 (CEST)

Hallo Mgmax, Du beziehst Dich auf die Tabelle im Abschnitt Entsprechungen? Kannst Du nicht eine weitere Zeile "Unicode-Entity" einfügen und ggf. die Schriftgröße runterregulieren? Wenn das dann die Seitenbreite sprengt, wovon ich leider momentan ausgehe, dann füge doch einfach die Tabelle wie oben abgebildet ein. Meiner Meinung nach ist es unkritisch, wenn man die Tabelle nicht vollständig angezeigt bekommt, sondern ein wenig scrollen muss. Bei 30 Zeilen solltest Du Dir wirklich noch keine Sorgen machen, da hab ich hier schon ganz andere Tabellen gesehen. ;-) Gruß --W_I^KImaniac 14:37, 22. Mai 2008 (CEST)

- 2009 -

Vertikaler Text

Hallo Experten, gibt es eine Möglichkeit, Text (z. B. in der Kopfzeile von Tabellen) vertikal in die Zelle zu setzen, z. B. wie bei Excel? Das würde in einem konkreten Fall die Spalten schmaler machen, und die Tabelle würde besser in den Artikel und auf den Bildschirm passen. Viele Grüße --Meichs 17:50, 15. Aug. 2009 (CEST)

Hallo Meichs, ist das eine Alternative für Dich?

V<br />e<br />r<br />t<br />i<br />k<br />a<br />l<br />e<br />r<br /><br />T<br />e<br />x<br />t

Gruß --W_I^KImaniac 18:35, 15. Aug. 2009 (CEST)

Vielen Dank, ich werd mal Schauen, wie´s aussieht. --Meichs 18:44, 15. Aug. 2009 (CEST)

Gern geschehen. Gruß --W_I^KImaniac 18:49, 15. Aug. 2009 (CEST)

Bitte nicht den Text so zerpflücken, wenn es geht. Um vertikal schreiben zu können, müssen wir uns wohl noch bis zur nächsten CSS-Version gedulden; bis dahin lassen wir wohl lieber die Browser in Abhängigkeit des Ausgabemediums entscheiden, wie er Tabelleninhalte anordnet. Gruß, -- E 20:55, 15. Aug. 2009 (CEST)

Spaltenformatierung

Hallo

gibt es eine Möglichkeit einer Spalte die Formatierung "center" zuzuordnen, ohne in jeder Zeile das jeweilige Feld einzeln zu formatieren.--77.23.233.223 13:53, 13. Sep. 2009 (CEST)

Mit CSS-Definitionen am HTML-Element table leider nicht. --Fomafix 14:02, 13. Sep. 2009 (CEST)

HTML und CSS (und somit zwangsläufig auch die Wikimedia Software) bieten hier Aufgrund des Aufbaus der Tabelle keine Möglichkeiten für Spalten einheitliche Formatierungen mit nur einer Anweisung zu definieren. Das geht leider nur für Zeilen. --Cepheiden 14:30, 13. Sep. 2009 (CEST)

So stimmt die Aussage nicht ganz, denn CSS3 würde dafür schon Möglichkeiten bieten:

table.drittespaltezentriert td:nth-child(3) { text-align: center }

Solche CSS-Klassen werden aber sicherlich hier nicht definiert werden, vorallem, weil noch nicht alle Browser dies unterstützen. --Fomafix 14:50, 13. Sep. 2009 (CEST)

Interessant, das kannte ich noch nicht. --Cepheiden 15:48, 13. Sep. 2009 (CEST)

Ich danke auch für die Infos. Zumindest schön zu wissen, dass schon an dieser Lücke gearbeitet wurde. --77.23.233.223 15:54, 13. Sep. 2009 (CEST)

Sortierbare Tabelle mit römischen Zahlen

Scheint mit der angegebenen Vorlage leider nicht zu funktionieren, siehe Vorlage:Römische Zahl/Test#Beispiel mit sortierbarer Tabelle. Habe den betreffenden Text aus dem Abschnitt Sortierbare Tabellen entfernt (diff). -- Emdee 18:17, 7. Mai 2009 (CEST)

Die Testseite gibt es nicht (mehr). Das Beispiel in der Vorlagendokumentation zeigt auch keine auffälligen Fehler. --Cepheiden 11:32, 31. Aug. 2010 (CEST)

- 2010 -

Griechische Zeichen in sortierbarer Tabelle

Offensichtlich wird Omega vor Omicron gereiht (siehe Spalte 3: Νικόλαος vs. Νίκωνος), was nicht der Regeln des griechischen Alphabets entspricht. Beispiel:

Bezirk	Deutsch	Griechisch	Einwohner
01	Agios Nikolaos	Άγιος Νικόλαος	508
02	Agios Nikonos	Άγιος Νίκωνος	146
03	Exochori	Εξωχώρι	298
		Gesamt (2001)	952

Alfie↑↓ 13:36, 22. Sep. 2010 (CEST)

Unbefriedigende Erklärung: Die Sortierung erfolgt über den Unicode-Wert und "hängt" am Iota, das einmal mit Tonos angegeben ist. Also: ί (hex 03AF, dec 943) und ι (hex 0359, dec 953). Daher ί < ι und Άγιος Νίκωνος < Άγιος Νικόλαος. Vermutlich – wenn überhaupt – nicht ohne weiteres lösbar. Einen Hinweis habe ich über Unicode-Sortierungsalgorithmus hier gefunden: »Special case #3: Case-Folding maps iota-subscript (U+0345 (ͅ) COMBINING GREEK YPOGEGRAMMENI) to an iota, due to the special behavior of iota-subscript, while the UCA treats iota-subscript as a regular combining mark (secondary ignorable).«. Alfie↑↓ 17:22, 22. Sep. 2010 (CEST)

Ja, daran liegt es, daher wird auch ÄäÖöÜü falsch sortiert. Du kannst aber Vorlage:SortKey verwenden, um das zu richten. Der Umherirrende 19:08, 22. Sep. 2010 (CEST)

Wunderbar, sehr hilfreich! Alfie↑↓ 19:33, 22. Sep. 2010 (CEST)

- 2011 -

Export

Ich will eine Tabelle aus der Wikipedia in ein Tabellenprogramm exportieren. Wie geht denn das am Einfachsten? Einfach nur mit c&p wird die ganze Tabelle in eine einzige Zelle kopiert. In der Hilfe habe ich nur Tools für die Gegenrichtung gefunden. Generator 19:22, 19. Jul. 2011 (CEST)

Hallo Generator, bei mir funktioniert einwandfrei, dass der Inhalt jeder Zelle in einer eigenen Zelle landet, getestet mit Firefox und OpenOffice Calc. --Wiegels „…“ 20:10, 19. Jul. 2011 (CEST)

OpenOffice Calc beendet sich leider kommentarlos nach dem Versuch (Hab auch Firefox). Generator 22:26, 19. Jul. 2011 (CEST)

Benutzt du eine aktuelle Version von Calc? Testest du mit einer besonders komplizierten Tabelle? Was passiert, wenn du den Inhalt unformatiert einfügst (Umschalt+Strg+V)? --Wiegels „…“ 22:35, 19. Jul. 2011 (CEST)

Es geht um Diskussion:Regierungskrise in der Elfenbeinküste 2010/2011#Täglich. Ausprobieren kann ich es leider erst morgen. Generator 22:37, 19. Jul. 2011 (CEST)

Auch damit habe ich keine Probleme. Beim unformatierten Einfügen werden auch die kleinen Grafiken in den Spaltenköpfen nicht beachtet. Vielleicht führten die ja zum Absturz. --Wiegels „…“ 23:34, 19. Jul. 2011 (CEST)

Habs jetzt ohne Tabellenkopf probiert und so hat es funktioniert. Danke! Generator 10:46, 20. Jul. 2011 (CEST)

Format 'unsortable'

Vielleicht kann mir hier jemand helfen: Ich habe eine Tabelle, die sortiert werden soll. Darin sind einige Zeilen, die in die Sortierung nicht einbezogen werden sollen. Laut Hilfe:Tabellen muss class="unsortable" eingefügt werden. Das habe ich getan. Die Zeile wird trotzdem in die Sortierung einbezogen. Möglicherweise gibt es Konflikte mit den anderen Formatierungen? -- Tommes ^{(Roter Frosch)} 21:35, 23. Jul. 2011 (CEST)

Hallo Tommes, wenn du die CSS-Klasse nicht der ersten Zelle (hinter |), sondern der ganzen Zeile (hinter |-) zuweist, funktioniert es. --Wiegels „…“ 19:09, 24. Jul. 2011 (CEST)

Danke für den Tip. Mit class="hintergrundfarbe5" funktioniert es. class="unsortable" funktioniert aber nicht. Müssen die classes irgendwie voneinander getrennt werden? Wo ist der Haken? -- Tommes ^{(Roter Frosch)} 22:22, 24. Jul. 2011 (CEST)

Bitte einfach machen, wie in Hilfe:Tabellen_für_Fortgeschrittene#Eine beliebige Zeile nicht sortieren beschrieben. Aber die angegebene Tabelle enthält für die Buchstaben, zusammengeschlossene Zellen, da funktioniert die Sortierfunktion allgemein nicht korrekt. --Cepheiden 22:25, 24. Jul. 2011 (CEST)

Muss mich korrigieren. Bei einer so gestallteten Tabelle, die in der Ursprungsform nach der ersten Spalte sortiert ist und für die Überischtlichkeit Zwischenzeilen mit den Anfangsbuchstaben besitzt, kann eine Sortierfunktion auch mit festen Zeilen nicht korrekt funktionieren. Denn mit einer anderen Sortierung werden die Zwischenzeilen zwangsläufig immer falsch angeordnet, denn die Sortierung, für die sie vorgesehen ist, besteht nicht mehr. Was du also vorhast geht prinzipiell nicht, denn dazu müssten die Zwischenspalten immer automatisch in Abhängigkeit von der Sortierung erzeugt werden. --Cepheiden 22:36, 24. Jul. 2011 (CEST)

Leider mußte ich Deine Änderungen überschreiben (Bearbeitungskonflikt, da ich gerade die Koordinaten aller Straßen eingefügt hatte). Genau eben weil sich eine falsche, weil unmögliche Sortierung zusammengefaßter Zellen in Übersichtszeilen ergeben würde, will ich die Zeilen ja von der Sortierung ausnehmen. Schade, daß es nicht zu gehen scheint.-- Tommes ^{(Roter Frosch)} 01:52, 25. Jul. 2011 (CEST)

Man kann sie von der Sortierung ausnehmen, aber sie stehen dann nur bei einer möglicher Sortierung (so wie du sie angelegt hast) an der richtigen Position. Bei allen anderen Sortierungen stehen sie am falschen Ort oder sind eben komplett untauglich, denn was nützt mir eine optische Trennung/Gruppierung der Einträge nach dem Namen, wenn diese garnicht genutzt wird? --Cepheiden 05:28, 25. Jul. 2011 (CEST)

Nunja, nach Namen habe ich sie ja schon sortiert. Es gibt nur noch die Sortierungen nach Länge und Jahr. Ich dachte, wenn man danach sortiert, würden die Zeilen mit dem Alphabet einfach verschwinden, denn sie machen ja keinen Sinn (es sind ja dann alle nametlich durcheinander). Es ist wohl besser, die Sortierung einfach wegzulassen. -- Tommes ^{(Roter Frosch)} 10:53, 25. Jul. 2011 (CEST)

Du kannst auch die Zeilen mit den Buchstaben weglassen und die Tabelle wieder sortierbar machen. Das erschwert ein bisschen die Orientierung im Standardfall, dafür stören sie nicht, wenn nach anderen Spalten sortiert wird. --Wiegels „…“ 12:18, 25. Jul. 2011 (CEST)

Tabellen-Titelzeile(n) vom Sortieren ausschließen

(Crossposting, wegen geringer Lösungs-Aussichten in WP:FZW):

Tabellen haben ja mitunter mehrere Kopfzeilen. Wenn man jetzt einfach die ganze Tabelle sortable macht, wird ja mit der obersten Zeile angefangen. Wenn das nun eine Titelzeile ist, wird das ganze sinnlos, und der Sortier-Klick sortiert einfach alles Darunterstehende hin und zurück.

Nun hatte ich neulich eine korrekte Lösung hierfür gesehen: Über die eigentliche Tabelle war eine Zeile drübergesetzt, und zwar codiert mit einem Plus-Zeichen (an Genaueres kann ich mich nicht erinnern). In den Hilfetexten ist das aber nirgends beschrieben, und den betreffenden Artikel finde ich auch nicht mehr.

Weiß jemand, was ich meine? Hier mal zur besseren Übersicht eine Beispiel-Tabelle, die natürlich in dieser Form falsch ist. Wie also kann ich die Sortierkriterien sortable machen?

Tabelle
Verschiedenes		Spezielles
Sortierkriterium 1	Sortierkriterium 2	Sortierkriterium 3	Sortierkriterium 4
Montag	10	Juni	Köln
Dienstag	9	Januar	Frankfurt
Mittwoch	8	Dezember	Berlin

-- Hunding 23:12, 28. Aug. 2011 (CEST)

Hallo Hunding, mit senkrechtem Strich und Plus-Zeichen erzeugst du eine Tabellenüberschrift (caption-Tag in HTML), siehe Hilfe:Tabellen#Tabellenüberschriften, Trennstriche. Eine beliebige Zeile soll sich mithilfe der CSS-Klasse unsortable von der Sortierung ausschließen lassen, siehe Hilfe:Tabellen#Eine beliebige Zeile nicht sortieren. Dies scheint bei den spaltenübergreifenden Überschriften nicht zu funktionieren, also habe ich das hier auskommentiert. Die Tabelle sieht dann so aus:

Tabelle

Sortierkriterium 1	Sortierkriterium 2	Sortierkriterium 3	Sortierkriterium 4
Montag	10	Juni	Köln
Dienstag	9	Januar	Frankfurt
Mittwoch	8	Dezember	Berlin

--Wiegels „…“ 01:23, 29. Aug. 2011 (CEST)

Perfekt, das war's.

Wobei jetzt immer noch das Ausschließen der zweiten Titelzeile ungelöst ist. Aber ich vermute, das Problem muß ich mal den Entwicklern der Wikisoftware beschreiben. -- Hunding 22:11, 29. Aug. 2011 (CEST)

bug?/abwärtsinkompatibel: sortierung mit formatierung der ersten zeile

der neue sortable-parser scheint sich zu verlaufen, wenn die erste zeile mit manueller zeilenformatierung |- gesetzt ist:

{| class="wikitable sortable" |- valign="top" | A || B |- | 1 || 2 |}

A B 1 2

früher war das nicht, da funktionieren etlich tabellen also nicht mehr: gibt es eine genau spezifikation, wie die erste kopfzeile auszusehen hat? --W!B: 07:13, 9. Nov. 2011 (CET)

Hallo, die Kopfzeile ist meiner Ansicht nach der Tabellenkopf (table header) und die Zellen werden mit "!" angegeben.

{| class="wikitable sortable" |- valign="top" ! A || B |- | 1 || 2 |}

A B 1 2

Grüße --Cepheiden 10:14, 9. Nov. 2011 (CET)

Chronologisch sortierbae Zeiträume

Wie kann ich es einrichten, dass Datierungen chronologisch sortiert werden. Hier speziell die Spalte Datierung. Momentan stehen in der Spalte jeweils nur die jüngsten Werte der Datierungszeiträume und ich würde aber gerne die Datierungszeiträume in die Spalte mit aufnhemen und nach einem Wert sortierbar machen. Habe es mit {{SortKey|...}} probiert, was dazu führte, dass die vor- und nachchristlichen Daten getrennt voneinander auf- oder absteigend sortiert wurden, ich hätte aber gerne eine chronologische Sortierung vom größten negativen Wert (vor Chr.) bis zum größten positiven (nach Chr.). Als Sortierkriterium wäre nur ein Wert (jüngster oder der ältester des Datierungszeitraums) ausreichend. (hoffe ich hab mich verständlich ausgedrückt) --Bullenwächter 11:26, 21. Dez. 2011 (CET)

Zeiträume sortieren
A mit {{SortKey|…}}	B mit {{Dts|||…}}
{{SortKey|{{Dts|||-300}}}}ca. 300-200 v. Chr.	{{Dts|||-300}} bis 200 v. Chr.
{{SortKey|{{Dts|||-4500}}}}um 4500-4000 v. Chr.	{{Dts|||-4500}} bis 4000 v. Chr.
1890-1920	1890-1920
{{SortKey|0055}}0050-59 (auf 55 sortiert)	0050-59
0050-60	0050-60

Zeiträume richtig zu sortieren ist schon etwas umständlich. Es gibt auch hier und hier solche Fälle.

Am besten du nimmst die Vorlage:SortKey, die Jahre vor Christus müsssen aber mit der Vorlage:Dts umgewandelt werden. Du schreibst: {{SortKey|{{Dts|||-300}}}}ca. 300 - 200 v. Chr. für die erste Zeile der rechten Tabelle. Dieser Sortierschlüssel erlaubt es auch vor der ersten Ziffer Text zu schreiben (z. B. ca.) und auf die Mitte des Bereiches zu sortieren, wie bei 50-59 in der rechten Tabelle.

Die 2. Variante ist mit der Vorlage:Dts: {{Dts|||-300}} bis 200 v. Chr.}}. Sie gibt das Datum immer richtig aus (auch mit "v. Chr."), da alle Sortier-Vorlagen am Anfang stehen müssen kann damit kein Text wie "ca." vor die erste Ziffer gesetzt werden.

Bei Jahreszahlen ab 1000 können die Vorlagen weggelassen werden, um den Quelltext besser zu lesen. Jahre zwischen 0 und 999 müssen aber mit {{0|00}}50 auf 4 Stellen erweitert oder immer die Vorlage:Sortkey verwendet werden.

Siehe auch Wikipedia:Typografie#Bis-Strich --MatthiasDD 00:48, 14. Jan. 2012 (CET)

Vielen Dank für die Info --Bullenwächter 18:44, 24. Jan. 2012 (CET)

- 2012 -

Sortieren

Ist es möglich, Tabellen nach mehreren Spalten zu sortieren? 79.252.192.144 15:04, 24. Jan. 2012 (CET)

Ja, indem man bei den nachfolgenden Klicks auf weitere Tabellenheader die SHIFT-Taste gedrückt hältst. --Cepheiden 15:30, 24. Jan. 2012 (CET)

Ural-Motorradwerk

Kann mal bitte jemand bei obigem Artikel vorbeischauen, wie man dort die Zeitleiste besser anlegen kann? Im Moment finde ich sie etwas sehr aufgebläht. Vielleicht hat jemand einen Vorschlag, wie man die Tabelle besser gestalten kann. Der Autor ist Benutzer:Cossacks. Er hatte mich um Hilfe gebeten, aber ich weiß da auch nicht weiter. Danke --Rita2008 17:18, 16. Feb. 2012 (CET)

Ich habe dort geantwortet. --Wiegels „…“ 19:45, 16. Feb. 2012 (CET)

Verschachtelte Tabellen

Ich möchte eine etwas verschachtelte, sortierbare Tabelle erstellen, komm aber nicht so richtig weiter. Was ich mir vorstelle: 1. Spalte soll über 5 Reihen gehen, ebenso die 2. Spalte. Die 3. Spalte hat 5 einzelne Spalten. Die 4., 5. und 6. Spalte teilt sich jeweils auf in einen oberen Teil, der über 3 Reihen geht und einen unteren Teil, der über die verbleibenden 2 Reihen geht. Ist das möglich? Kann sich jemand vorstellen was ich meine bzw. kann mir da jemand eine Syntax basteln? Dankend! --Kauk0r (Diskussion) 22:14, 28. Mär. 2012 (CEST)

Hallo Kauk0r, irgendetwas an deiner Beschreibung passt nicht ganz zusammen, aber ich glaube, du meinst eine Tabelle wie hier:

1	2	3a	4a	5a
		3b
		3c
		3d	4d	5d
		3e

Und welche Inhalte darin möchtest du sortieren lassen können? --Wiegels „…“ 23:05, 28. Mär. 2012 (CEST)

Ja das sieht so aus wie ich meinte. Sortierbar soll sein Spalte 1,2,3,4,5, eine 6. Spalte (oben als zweite 5. drin, habs korrigiert, war das was du meintest?) soll nicht sortierbar sein. --Kauk0r (Diskussion) 23:17, 28. Mär. 2012 (CEST)

Damit eine Tabelle sortierbar ist, werden Spaltenüberschriften benötigt:

1	2	3	4	5	6
1	2	3a	4a	5a	6a
		3b
		3c
		3d	4d	5d	6d
		3e

Diese Tabelle tut, was sie soll, oder? --Wiegels „…“ 23:43, 28. Mär. 2012 (CEST)

Sieht brauchbar aus, denke damit komm ich klar...vielen Dank für deine schnelle Hilfe! --Kauk0r (Diskussion) 23:56, 28. Mär. 2012 (CEST)

Tabellenhöhe?

Habe in meinem eigenen Wiki den Fall, dass ich ein Bild in eine Tabelle einbinde und sich das über mehrere Zeilen streckt. Es war mit dieser Hilfe möglich, die zugehörige Zelle über mehrere Zeilen zu spannen und so das Bild unterzubekommen. Ich vermute, dass das hier nicht gemacht wird, weswegen dazu keine Ausführung existiert? Ansonsten wüsste ich gerne, wie ich die Zeilenhöhe so skalieren kann, dass sich alle Zeilen gleichmäßig verteilen, denn die Höhe des eingebundenen Bildes kenne ich über die Angabe des Vorschaubildes (welches nur dargestellt wird).

• style="height:5em" -- P.oppenia 09:52, 28. Feb. 2012 (CET)

Das geht meines Wissens nur wenn du jeder Zeile sagst, wie "hoch" sie sein darf. Eine dynamische Lösung kenne ich nicht. Da die Anfrage 2 Jahre alt ist, hat sich das sicher erledigt, oder? ---Cepheiden (Diskussion) 15:42, 10. Aug. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: -- Cepheiden (Diskussion) 15:42, 10. Aug. 2014 (CEST)

Tabelle und Galerie überlappt sich

Hallo...unter Regierung Abhisit Vejjajiva überlappen sich, zumindest in meinem Browser, die Tabelle und die Gallerie. Was kann ich denn da machen? Generator (Diskussion) 14:54, 30. Mär. 2012 (CEST)

Hallo Generator, ich habe der Tabelle mal gesagt, dass sie rechts Platz für die Galerie lassen soll. Falls es in deinem Browser nicht passt, könnten eingestellte rechte Abstand von benutzerabhängigen Einstellungen für Standardbildgrößen abhängen. Dann müsste man nochmal überlegen, wie man das Problem allgemeiner lösen kann. --Wiegels „…“ 17:07, 30. Mär. 2012 (CEST)

Super danke. Also bei mir klappt es gut. Ich werde es auch mal mit verschiedenen Browsern probieren. Generator (Diskussion) 17:09, 30. Mär. 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Generator (Diskussion) 17:09, 30. Mär. 2012 (CEST)

Übertragen von Tabellen

Hallo...ich würde gerne die Ergebnisstabelle aus dem englischen Artikel en:Thai general election, 2011#Election result zu uns übertragen. Allerdings beruht die die Vorlage die dafür verwendet wurde (Template:Thai general election, 2011), auf wieder einer anderen Vorlage: Template:electiontable die auch nicht ganz trivial ist. Hat jemand mit sowas Erfahrung und kann mir helfen? Generator (Diskussion) 11:56, 26. Mär. 2012 (CEST)

Hat sich erstmal erldigt. Generator (Diskussion) 08:43, 2. Apr. 2012 (CEST)

Zellen miteinander verbinden (colspan und rowspan)

Zitat: „ Sollen in sortierbaren Tabellen Zellen mit den Attributen colspan und/oder rowspan miteinander verbunden werden, funktioniert die Sortierung nicht mehr richtig.“

Mir scheint diese Aussage ist mit der Einführung des neuen Sortieralgorithmus' vor ein paar Monaten nicht mehr gültig. Da mit rowspan verbundene Zellen automatisch geteilt werden und die Sortierung bei mit colspan verbundene Zellen offenbar keine Probleme mehr hat. Meiner Meinung nach sollten wir daher den entsprechendne abschnitt überarbeiten. Auch das Beispiel mit Vorlage:SortKeyColspan sehe ich kritisch, ich bin hier eher für die Abschaffung oder gibt es noch Gründe warum wir diese hier empfehlen oder erhalten sollten? SortKeyColspan reagiert bezüglich der Sortierung eh etwas anders als ich erwartet hatte, denn der Wert von verbundenen Zellen wird der letzten Spalte zu geordnet und nicht der ersten (wie bei HTML) oder eben allen beteiligten Spalten (wie man es von einer extra erstellten Vorlage erwarten würde). Das zeigt sich auch in der Positionierung der Werte.

Zahlen	Alphabet	Datum	Währung	Unsortierbar
1	Z	02-02-2004	5,00	Diese
2	y	13-apr-2005		Spalte
3	X	17.aug.2006	6,50	ist
4		01.Jan.2005	4,20	unsortierbar
5	V			wie man sieht.
Gesamt: 15			Gesamt: 29,55

colspan Spalte 1 Spalte 2 Spalte 3 Spalte 4 1 2 5 2 1 5 2 3 3 3 4 1 2 5 4 1

SortKeyColspan Spalte 1 Spalte 2 Spalte 3 Spalte 4 1 {{SortKeyColspan |colspan=2 |width=10 |key=2}} 5 2 1 5 2 3 {{SortKeyColspan |colspan=2 |width=10 |key=3}} 3 4 {{SortKeyColspan |colspan=2 |width=10 |key1=5 |key=1}} 2 5 {{SortKeyColspan |colspan=2 |width=10 |key=4}} 1

Was meint ihr? --Cepheiden (Diskussion) 07:51, 11. Apr. 2012 (CEST)

• Die fehlerhafte Positionierung des Textes bei Verwendung der Vorlage liegt daran, dass du den Pflicht-Parameter widthSum nicht angegeben hast. Den kann man aber eigentlich optional machen, was ich jetzt in der Vorlage auch getan habe. Die inzwischen entstandenen zusätzliche Abweichungen in der Formatierung liegt daran, dass die Symbole der Sortierung nicht als padding-right umgesetzt wurden. Auch das ist jetzt in der Vorlage berücksichtigt.
• Den inzwischen falschen Hinweis zum rowspan sollte man tatsächlich entfernen - was ich jetzt auch getan habe.
• Dass der sichtbare Wert der letzten Spalte zugeordnet wird hat technische Gründe, anders ist das Ganze auch schlicht nicht möglich. Falsch ist, dass alle mit colspan verbundenen Zellen bei der Vorlage den Wert nicht enthalten würden. Natürlich enthalten sie den Wert, nur eben versteckt. Sonst würde der Sortierung auch gar nicht funktionieren...
• Die Vorlage ist insgesamt eben nicht obsolet: Versuche einfach mal in deinem Beispiel...

• Spalte 2 zu sortieren: Einmal klicken funktioniert, danach bekomme ich im Firefox einen JavaScript-Fehler.
• Spalte 3 zu sortieren: Ergebnis ist die vollkommen falsche Sortierung 4-1-3-2-5 bzw. 2-5-3-1-4. Die richtige Sortierung 1-2-3-4-5 erzielt die Vorlage.
• Spalte 4 zu sortieren: Ergebnis ist die Sortierung 1-2-3-2-5 bzw. 5-2-3-2-1. Richtig wäre aber 1-2-2-3-5 - wie das die Vorlage umsetzt. Außerdem funktioniert der Wechsel von auf- zu absteigender Sortierung nur nach zwei Klicks.

Summa sumarum: Die Vorlage ist alles andere als obsolet... --Vanger ^!–!? 16:24, 1. Okt. 2013 (CEST)

Sortieren nach Jahreszahlen in einer Tabelle, die Angaben VOR und NACH Christi Geburt enthalten

Wie kann man das anstellen? Siehe dazu hier. MfG --Oktonaut (Diskussion) 17:25, 10. Nov. 2012 (CET)

Dazu gibt es die Vorlage:Dts. Hab' die Tabelle schon geändert. (diff) --MatthiasDD (Diskussion) 18:46, 10. Nov. 2012 (CET)

Habe es gesehen. Danke sehr! :) --Oktonaut (Diskussion) 18:47, 10. Nov. 2012 (CET)

- 2013 -

Komplexe Namen sortieren

Hallo Zusammen,

das ist jetzt vllt. nicht wirklich eine Diskussion, aber ich brauch Hilfe: Seit über einer Stunde versuche ich eine Tabelle mit sortierbaren Namen zu bauen, in der ein komplexes Lemma enthalten ist: José Padilla (Vereinigte Staaten)

Weder SortKeyName noch mit data-sort-value komme ich zu der gewünschten Lösung.

Alle anderen Namen in der Liste sind klassisch "Vorname Nachname" und funktionieren über SortKeyName. Bei José Padilla hätte ich gern in der Anzeige "José Padilla", als Link "José Padilla (Vereinigte Staaten)" und als Sortierung "Padilla".

Ich weiß mir grad nicht mehr zu helfen, außer: Ich aktzeptiere als Link "José Padilla" ... dann müsste sich der Nutzer aber zum tatsächlichen José Padilla weiter-vor-klicken.

Hat Jemand eine Idee? ... schon mal tausend Dank.--AKor4711 (Diskussion) 19:32, 2. Jul. 2013 (CEST)

die Lösung steht natürlich hier: Vorlage:SortKeyName ... *schäm* ... hätt ich auch eher drauf kommen können.

Archivierung dieses Abschnittes wurde gewünscht von: AKor4711 (Diskussion) 12:28, 3. Jul. 2013 (CEST)

wikitable sortable: Vorzeichen spielen nicht mit

Hallo, ich habe unter Umweltprämie#Veränderung des Fahrzeugbestandes eine sortierbare Tabelle angelegt, in der eine Spalte Zahlenwerte mit Vorzeichen beinhaltet. Diese Spalte lässt sich nicht wie gewünscht sortieren. Hat jemand eine Lösung parat? (Nebenbei wäre ich auch froh, wenn man in den Tabellen darüber die letzte Spalte "Insgesamt" vom Sortieren auschließen kann, ohne sie als Kopfzeile festzulegen, denn der Text soll linksbündig erscheinen.) --217.227.106.50 19:39, 19. Sep. 2013 (CEST)

Hallo, ich habe die Tabellen mit dem Attribut data-sort-type="number" im Tabellenkopf versehen, so geht es. Die Leerzeichen zwischen Vorzeichen und Ziffern verhinderten die automatische Erkennung als Zahl. (Nebenbei: um Spalten oder Zeilen von der Sortierung auszuschließen hilft auch ein Blick auf diese Hilfeseite hier vorn 2.6 Zellen von der Sortierung ausschließen.) --MatthiasDD (Diskussion) 00:16, 27. Sep. 2013 (CEST)

- 2014 -

Sortierung unterschiedlicher Datumsangaben

Hallo, ich habe das Problem, dass in einer Tabelle unterschiedlich genaue Datumsangaben stehen sollen. Für einen Teil sind die Daten auf den Tag genau bekannt, für einen kleineren Teil aber nicht, dort sind teilweise noch der Monat, teilweise wenigstens das Jahr und in einigen wenigen Fällen nur der Zeitraum bekannt (bspw. "vor 1914"). Wie kann so was in einer sortierbaren Tabelle abgebildet werden? Mit data-sort-type="date" würde ich ansonsten ja auskommen... --Wdd (Diskussion) 15:12, 2. Jan. 2014 (CET)

Standardmäßig {{SortDate|2014-01-03}} (ergibt ''{{SortDate|2014-01-03}}''), für Monatsangaben {{SortDate|2014-01-00}} (ergibt ''{{SortDate|2014-01-00}}'') und für Jahresangaben {{SortDate|2014-00-00}} (ergibt ''{{SortDate|2014-00-00}}''). Konzepte wie "vor 2014" entweder wie bei den Jahresangaben (testen ob die Sortierung klappt), ansonsten mit {{SortKey|2013-99-99|vor 2014}} (ergibt ''{{SortKey|2013-99-99|vor 2014}}'' - das wird dann vor "2014" aber nach "31. Dezember 2013" einsortiert). Alternativ kann man auch mit data-sort-value="" arbeiten, dann musst du aber alle Daten doppelt pflegen: einmal in YYYY-MM-DD-Notation innerhalb vom data-sort-value="2013-01-03" und ein zweites mal in der darzustellenden Notation (z. B. 3. Januar 2013). --Vanger ^!–!? 02:04, 3. Jan. 2014 (CET)

Ganz herzlichen Dank, hat mir auf jeden Fall schon gut geholfen! So ganz klappt es aber noch nicht, oder ich habe was übersehen. Die "vor 1920"-Werte werden separat sortiert, danach dann erst die Zeilen mit exakten Daten, siehe Benutzer:Wahldresdner/Liste der Klettergipfel. Wo liegt da mein Denkfehler? --Wdd (Diskussion) 22:21, 3. Jan. 2014 (CET)

1. Die Darstellung von Vanger ist hübsch; sollte im Prinzip als Auflistung oder Tabelle Bestandteil der Hilfeseiten werden.
2. Bei der Höllengrundscheibe fand ich fehlsortiertes {{SortKey|1935-99-99|vor 1936}} gemäß obiger Anleitung.
   • Du hast gar keinen Denkfehler.
   • Irgendwie ist an diesen Vorlagen jemand dran, der das Format ab und an ändert, ohne die Hilfeseiten und Dokumentationen vollständig an die veränderte Funktion anzupassen, geschweige denn den Artikelbestand.
   • Die Vorlage:SortKey wurde als „veraltet“ erklärt.
   • Was bisher wie von Vanger vorgeschlagen den Sortiercode 1935-99-99 bekommen müsste, geht heute nicht mehr.
   • Früher bekam der dritte Januar 2014 den Sortiercode 2014-01-03 – heute ist das wohl 70140103, wenn ich den Quellcode richtig interpretiert habe (Doku isnich).
   • Dafür funktionieren mit Vorlage:SortDate die Tages- und Monatsangaben mit 99 nicht mehr, weil seit letztem Sommer nur noch legitime Kalendertage akzeptiert werden und Angaben wie „vor“ in diesem Konzept nicht mehr zulässig sind.
   • Wie man hier langfristig verfahren soll, weiß ich auch nicht, weil ich keine Dokumentation, kein alle Situationen umfassendes Konzept und keine stabile Lösung sehe. Der Fall eines nur ungefähr bekannten Datums ist konzeptionell nicht mehr vorgesehen.
   • Bereits die Doku-Seite Vorlage:SortDate/Doku enthält am heutigen Tag einen Syntaxfehler. Das heißt, die Programmierung kann seit Monaten noch nicht einmal ihre eigene Doku sachgerecht unterstützen.
   • Wikipedia:Lua/Modul/Vorlage:FormatDate/de gibt mir jedenfalls keinen Aufschluss über die beabsichtigte Funktionalität; oder irgendeinen Abgleich, was in welchen Situationen als Ergebnis herauskommen sollte, was im Moment tatsächlich herauskommt und welches Konzept dahintersteht. Eine Testseite hierzu fehlt völlig.
   • Über diesen Eingriff in den Artikelbestand gab es wohl schon häufiger Beschwerden, wenn ich das in den letzten Monaten richtig mitbekommen habe.

LG --PerfektesChaos 14:54, 5. Jan. 2014 (CET)

Immer diese Verschlimmbesserungen... Über Jahre hat das alles super funktioniert, dann setzt sich einer hin und macht alles "besser" - und macht damit alles kaputt. Richtig absurd ist diese Infobox bei Vorlage:SortKey, dass sie veraltet sei. Selbst dieser neumodische, nicht funktionierende LUA-Mist verwendet nicht etwa data-sort-value="" sondern machts genauso wie die Vorlage...

Hab mir das jetzt mal angesehen, ich sehe eigentlich zwei Möglichkeiten:

1. Die normalen Daten sortiert man wie oben erklärt, für Angaben wie "vor 2014" kann man {{SortDate|2014-00-00|davor=vor}} (ergibt vor 2014) verwenden. Nachteil: Das wird zusammen mit 2014-00-00 (also 2014) einsortiert.
2. Möchte man die "vor 2014"-Daten wirklich auch vor den "2014"-Daten einsortiert haben sehe ich eigentlich nur eine Möglichkeit: Den Sortieralgorithmus von diesem LUA-Gedöns umgehen und zum alten Verhalten zurückkehren. Für die Formatierung des dargestellten Datums kann das LUA ja weiterhin verwendet werden. Da hätten wir zwei Möglichkeiten:
   1. Wir setzen die Vorlage:SortDate einfach zurück auf die Version vom 28. Aug. 2013, 12:23:25. Nachdem ich glaube, dass es einige Artikel gibt die das so oder so ähnlich machen, wird das wahrscheinlich eine gar nicht mal so doofe Idee sein.
   2. Wir legen eine zweite Vorlage (z.B. Vorlage:SortDateNoBugs) an. Inhalt: Besagte Version vom 28. Aug. 2013, 12:23:25.

--Vanger ^!–!? 01:23, 6. Jan. 2014 (CET)

Solange wie jede Vorlage einen anderen Sortierschlüssel verwendet, muss in der gesammten Spalte immer die gleiche Vorlage verwendet werden. Ich habe obigen Artikel mal auf Vorlage:SortDate geändert. Damit "vor 1914" vor "um 1914" einsortiert wird, habe ich mit Vorlage:0 eine unsichtbare ~ eingefügt. So geht es. --MatthiasDD (Diskussion) 00:57, 9. Jan. 2014 (CET)

Eine Zeile für eine bestimmte Spalte vom Sortieren ausschließen

Ich würde gerne eine Zeile für eine bestimmte Spalte vom Sortieren ausschließen. Konkret geht es unter Wirtschaftszahlen zum Automobil#PKW-Neuzulassungen nach Automarken um die Spalten "Rang 2013" und "Rang 2012". (Achtung: es geht um die bisher ungesichtete Version!) Die Zeilen, in denen in der entsprechenden Spalte kein Wert steht, werden offenbar als "0" erkannt und stehen daher vor der "1". Ich möchte diese Zeilen aber nicht grundsätzlich vom Sortieren auschließen, weil in anderen Spalten ihre Sortierung erwünscht ist. Lässt sich das technisch umsetzen? --217.227.85.225 02:27, 7. Apr. 2014 (CEST)

Ich wüsste nicht, dass/wie das geht. Immerhin könnte man zum Beispiel mit dem Attribut data-sort-value="99" dafür sorgen, dass diese Zeilen bei aufsteigender Sortierung hinten einsortiert werden (dafür landen sie dann aber bei absteigender Sortierung vorne; das lässt sich so nicht verhindern). --Entlinkt (Diskussion) 02:57, 7. Apr. 2014 (CEST)

Perfekt, vielen Dank für den Tipp! --217.227.65.17 21:19, 7. Apr. 2014 (CEST)

aus Differenz zweier Spalten dynamisch neue Spalte (sortierbar) generieren?

Ich habe gerade die Reihenfolge der Spalten in Privacy International - Privatsphären Index chronologisch angepasst und bin dabei auf die Frage gestoßen, ob sich eine neue Spalte dynamisch aus der Differenz der beiden Spalten erzeugen ließe (sortierbar), mit der man dann die Tendenz der Veränderung gegenüber dem Vorjahr darstellen könnte. Geht das per Script, oder müßte man die neue Spalte auch in den Wikitext reinschreiben? --92.225.13.96 00:09, 10. Apr. 2014 (CEST)

Etwas derartiges ist nicht möglich, du musst die Differenz selbst berechnen und entsprechend manuell einfügen. --Vanger ^!–!? 19:32, 10. Apr. 2014 (CEST)

Hallo, dein Wunsch ließe sich mit einer Vorlage umsetzen, der zwei Zahlenwerte übergeben werden und die drei Tabellenzellen ausliefert, zwei (automatisch gefärbte) mit den ursprünglichen Zahlen und eine weitere mit der Differenz. Eine Sortierbarkeit nach der neuen Spalte ließe sich an der Tabelle einstellen. --Wiegels „…“ 20:29, 10. Apr. 2014 (CEST)

Zelle unter zwei Zellen

Hallo zusammen, im Moment arbeit ich an einem Artikel zu einem englischen Wahlkreis und habe eine Frage zur Darstellung des Wahlergebnisses in einer Tabelle. Im englischsprachigen Original geht es um die zweite Tabelle zu den Wahlen 2010. Leider wird dort ausschließlich mit Vorlagen gearbeitet um die Tabelle zu generieren, sodass man dort nicht spiken kann :) Mir geht es um die Zellen Majority, Turnout und Conservative gain from Labour. Wie bekommt man es hin, damit die Zellen jeweils die darüberstehenden (Party und Candidate) umfassen? Wenn ich das richtig verstehe, hilft colspan da nicht weiter, weil ich ja eine Zelle unter zwei Zellen will und nicht darüber...?! Danke für Eure Hilfe! Gruß --Teddychen81 (Diskussion) 16:03, 12. Aug. 2014 (CEST)

colspan ist genau das richtige. Wenn Du einer Zelle diesen Wert zuweist, erstreckt sie sich automatisch über so viele Zellen wie angegeben. Hier ein Beispiel, übernommen von der Hilfeseite:

A	B	C
Zelle 1	Zelle 2
Zelle 3	Zelle 4	Zelle 5

Es ist völlig egal, in welcher Zeile sich die Zelle befindet, die sich über mehrere erstrecken soll. --Sepp (Diskussion) 10:59, 13. Aug. 2014 (CEST)

Ich denke du meinst links und rechts neben der Zelle, nicht oben und unten, ja? Das ist colspan. Auch wenn es so aussieht als sei der Text in der Candidate-Spalte, ist das in Wirklichkeit die erste Spalte (die mit den Farben) die mittels eines colspan="3" auf die Breite der drei Spalten ausgedehnt wurde. Mit style="text-align: right;" wurde der Text dann noch rechtsbündig ausgerichtet. --Vanger ^!–!? 12:09, 13. Aug. 2014 (CEST)

Jetzt hat es funktioniert! Herzlichen Dank für die Hilfe! Gruß --Teddychen81 (Diskussion) 22:38, 13. Aug. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Teddychen81 (Diskussion) 22:38, 13. Aug. 2014 (CEST)

SortKeyName: von Benutzung abraten und aus Beispielen entfernen?

Nur zufällig habe ich vor kurzem erfahren, dass bei der Benutzung der Vorlage:SortKeyName der entsprechende Name nicht mehr von der WP-Volltextsuche gefunden wird. Für mich ist das ein klarer Bug. Jedenfalls irritiert dieses Verhalten nicht nur mich, sondern auch andere - siehe zum Beispiel Wikipedia:Löschkandidaten/23._August_2015#div. Weiterleitungen von Holocaustopfern, inklusive hitzigem Wortgefecht. Dieser Aspekt des Verhaltens der Vorlage ist auch gewiss vielen Autoren, die SortKeyName benutzen, nicht bewusst. Eine Alternativlösung scheint ja zu bestehen in Gestalt des Attributs data-sort-value. Das steht auch schon auf der Hilfeseite. Aber warum dominiert in den Beispielen immer noch die Benutzung von SortKeyName? Könnte man nicht klipp und klar von dessen Benutzung abraten und es aus den Code-Beispielen tilgen? Gruß, --Yen Zotto (Diskussion) 23:49, 28. Aug. 2015 (CEST)

Als Ergänzung hierzu noch, dass ebenfalls Hilfe:Tabellen#Sortierbare Tabelle betroffen ist. Vielleicht sollte man auf der dortigen Diskussionsseite auf diese Diskussion hinweisen. --Sitacuisses (Diskussion) 00:45, 29. Aug. 2015 (CEST)

Danke, habe ich eben (endlich) gemacht. --Yen Zotto (Diskussion) 19:00, 2. Sep. 2015 (CEST)

• Zumindest ist die Programmierung veraltet; ich würde unbeschadet der Suchgeschichte zum Einbau von Text|removeDiacritics um den gebildeten SORTKEY raten.
  • Sonst hat eine gesonderte Vorlage heute keinen Sinn mehr.
  • Mit gesondertem Attribut data-sort-value im Quelltext muss man die Info doppelt angeben; diese Doppelarbeit will man ja eigentlich vermeiden.
• Nicht ganz nachvollziehbar ist, warum die Volltextsuche den kompletten Namen nicht finden würde; die müsste eigentlich den dargestellten expandierten Text sehen, und der steht ja in der ersten Spalte.
  • Suche nach Hans Zehnder auf Hilfeseiten scheint auf Hilfe:Tabellen erst die Quelltext-Darstellung zu sehen, nicht die generierte Tabelle. Auch Hilfe:Tabellen für Fortgeschrittene greift irgendwie seltsam zu; sieht aber auch das data-sort-value mit dem Komma. Ähnlich mit Anführungszeichen.
• Möglicherweise ließe sich der Suchfunktion unter die Arme greifen.
  1. Anhängen eines   an den kombinierten Namen, den HTMLtidy dann in Ruhe ließe. Offenbar klatscht der Nachname mit der nächsten Spalte zusammen. &zwnj; etc. würde ich ungern sehen, weil sie beim C&P dran kleben bleiben und in alle Welt verstreut werden.
  2. Mittels eines <span style="display:none"> um irgendwas herum; nicht schön, aber wenn es hilft und den Artikelbestand erschließt, dann pragmatisch.
• Mag das jemand erproben? (natürlich nicht an der Produktivversion)
• Ziel sollte schon sein, der Suchfunktion wieder zu Treffern zu verhelfen und den Artikelbestand in Ruhe zu lassen; auch nicht jeden Namen doppelt zu schreiben.

LG --PerfektesChaos 20:15, 2. Sep. 2015 (CEST)

Ich verstehe zwar höchstens die Hälfte von dem, was Du da schreibst, aber den letzten Punkt unterschreibe ich 100%. --Yen Zotto (Diskussion) 23:34, 3. Sep. 2015 (CEST)

So, Wetter und Umgebungstemperaturen waren der Denkarbeit dienlich.

Ich habe jetzt mal einen ersten der oben beschriebenen Eingriffe vorgenommen. Auf BETA erfolgreich.

@Yen Zotto: Bitte berichten, ob heute mittag hier die Suche nach Namen konveniert.

LG --PerfektesChaos 09:31, 5. Sep. 2015 (CEST)

Sieht gut aus! Die am 28.8. von der Volltextsuche noch unauffindbaren Erwähnungen von Felix Metzl in Liste der Stolpersteine in Třeboň und Otto Líbezný in Liste der Stolpersteine in Lomnice u Tišnova werden jetzt problemlos gefunden. Im Quelltext der entsprechenden Seiten erscheinen die Namen nach wie vor nur in der SortKeyName-Vorlage. Meiner laienhaften Meinung nach ist das Problem damit gelöst. Vielen Dank, Benutzer:PerfektesChaos! Gruß, --Yen Zotto (Diskussion) 22:13, 6. Sep. 2015 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Wetterwolke (Diskussion) 11:56, 3. Mai 2019 (CEST)

Addition

Gemeldet in Phabricator
Task T120480

Hallo, wie bekommt man eine Addition der Tabelleninhalte hin? Wenigstens die Zahl der Gemeinden würde ich addiert haben wollen, da mit jeder Änderung in der Tabelle das Ergebis bei fehlender Änderung unten falsch ist. Die übrigen Inhalte wären, wenn es zu komplex ist, viell. anders steuerbar.

Kürzel	Name	Region	Einwohner	Fläche (km²)	Gemeinden
AG	Agrigent	Sizilien	00438.276	003.042	0043
AL	Alessandria	Piemont	00440.481	003.559	0190
VT	Viterbo	Latium	00318.205	003.614	0060
Gesamt			60.702.570	301.169	8.092

--Adelfrank (Diskussion) 09:40, 4. Aug. 2019 (CEST)

Addition geht zwar generell siehe Hilfe:Vorlagenprogrammierung#Funktion expr, aber nicht in normalen Tabellen sondern nur über Vorlagensyntax, die jedoch nicht direkt in Artikeln stehen soll. Das Ergebnis für die Einwohner in deinem Beispiel wäre also {{#expr: 438.276 + 440.481 + 318.205}} = 1196.962

Aber wie soll diese Funktion erkennen welche Werte addiert werden sollen? Die Berechung müsste also ebenso von Hand geändert werden. Siehe auch Kategorie:Vorlage:Zahlenformatierung, ich finde dort nichts passendes und denke, das ist so nicht möglich. Dafür müsste man einer Vorlage die Werte über parameter übergeben und diese könnte dann auch etwas ausrechnen, der Aufwand so etwas zu erstellen wäre vermutlich recht komplex. Ich zumindest kenne keine solche Lösung. --Liebe Grüße, Lómelinde Diskussion 13:14, 4. Aug. 2019 (CEST)

Danke für die Beantwortung. Ich hatte schon mal vor längerer Zeit eine solche Frage gestellt, konnte es aber damals wie auch heute nicht fassen. Also wir leben im 21. Jh. und allemöglichen Computerprogramme werden entwickelt und in meiner Umwelt werde ich von den techn. Neuerungen im wahrsten Sinne des Wortes überrollt. Aber hier gibt es nicht mal ein einziges simples Rechenprogramm, das z.B. a) Die Summe der Spalte A, B oder C errechnet oder b) Die Zellinhalte C1+C2+C3 oder c) Die Zellinhalte C1 ... C3 addiert, ob extern oder intern, beides nicht möglich. Und kein anderer Lösungsvorschlag als die Taschenrechnerfunktion 1 + 2 + 3 = 6 ist möglich, wenn ich die Werte so errechnen soll kann ich auch gleich den Taschenrechner zur Hand nehmen, der Aufwand dürfte der selbe sein, viell. sogar noch geringer sein. - Die Menschen fliegen zum Mond und erkunden, ob dort Leben möglich ist, aber in Wikipedia sind die Technik-Freaks ja "von hinter dem Mond". Ich muss ehrlich sagen, ich spiele mit dem Gedanken mich mit der Presse in Verbindung zu setzen und das mal publik zu machen, wie vorsinntflutlich das hier abgeht. Da könnt ihr euch aber wiki-data, wiki-leaks, wiki-was-weiss-ich-Foren und was es da noch alles gibt, an die Backe schmieren, wenn nicht mal das, was jede bucklige Excel-Datei kann, hier umsetzbar ist. Manno ist das erbärmlich. - Aufhänger ist diese Tabelle: Italienische Provinzen#Liste. Dass das manuell nur schwer zu händeln ist, sieht ein Laie. In der Summe stehen schon seit Jahren falsche Werte, wo hingegen die anderen Zellinhalte (Ew.zahlen u. Ew. je km²) perfekt durch Programmierungen aktualisiert werden. - Da bleibt als einziges Sinnvolles, die Summen komplett zu löschen - lieber nix, als falsche Werte (denke Ich), da bei Wikipedia die Addition noch nicht so weit entwickelt wurde ("Steinzeit-Niveau") und es unmöglich sei, das ohne Riesen-Aufwand zu bewerkstelligen. Ich finde das sollte die Welt erfahren. Alles auf höchstem Niveau, aber ein Programm das Spalteninhalte addiert, nein das ist zu futuristisch, das gibt es wenn überhaupt, erst im Jahre 2119 bei Wikipedia. Wenn es nicht so traurig wäre, würde ich mich totlachen. --Adelfrank (Diskussion) 15:28, 4. Aug. 2019 (CEST)

Wir könnten zwar eine solche Tabelle generieren, auch alle möglichen Summen, Durchschnitte und Quersummen ausrechnen – aber kein normaler Autor könnte das noch bearbeiten. Du wohl auch nicht.

Eine Grundanforderung der Wikipedia ist, dass möglichst jeder Mensch unsere Artikel bearbeiten können soll, mit möglichst geringen Hürden.

Deine Forderung läuft auf einen Zielkonflikt hinaus: Wenn das nur noch drei Leute bearbeiten können, dann ist das auch keine gute Idee.

Tipp: Du kannst die Tabelle aus dem Wikipedia-Artikel in ein Tabellenkalkulationsprogramm übertragen (wie etwa Excel), dort ausrechnen was du willst, und es dann in unseren Artikel eintragen.

In unseren Artikeln stehen möglichst nur direkte Texte. Je komplizierter das wird, die Daten aus Vorlagen, WikiData, Modulen generiert würde, desto weniger kann das noch jemand bedienen, und dann kann nicht mehr jeder unsere Artikel pflegen.

Wenn jemand neue Werte einträgt, dann ist es die Verantwortung des Eintragenden, auch die Summen zu aktualisieren. Wenn das schon die Autoren überfordert, dann überfordern deine Ideen die technischen Fähigkeiten eines Textbearbeiters erst recht.

VG --PerfektesChaos 15:59, 4. Aug. 2019 (CEST)

Also mal ganz ehrlich, diese Antwort kommt mir irgendwie bekannt vor. Wir könnten zwar, aber blabla Mach dies, mach das, kümmere dich selbst. Eigentlich wie in jeder guten Autowerkstatt: Wenn was klemmt frage ich dort nach und der Meister erklärt mir alles hochtrabend, und dann ziehe ich mir die Arbeitskombi an und lege mich unters Kfz und versuche das Auto selbst zu reparieren. Kennt ihr sicher auch, oder etwa nicht? Ich dachte ursprünglich (damals war's) in Wikipedia gibt es eine gewisse Arbeitsteilung und man bekommt bei techn . Problemen Unterstützung, wenn man Hilfe braucht. Stattdessen kommen von Eurer Seite entweder hochtrabende fachchinesische Erläuterungen (wie bei einigen von sich selbst eingenommenen Ärzten, die damit ihre Überlegenheit demonstrieren wollen) oder Nix. In den 10 Jahren die ich hier arbeite, hatte ich wenn's hoch kommt, 20 mal ein techn. Problem, dabei gab es, ebenfalls wenn's hoch kommt, 3 mal richtig gute Hilfe, der Rest verlief wie hier. Blablabla, mach Deinen Scheiss selbst. - Ich bin Autor und habe von Technik Null Ahnung. Aber Unterstützung von techn. Seite ist hier wie ein Sechser beim Lotto. - Mit meinem Spatzen-Hirn hätte ich gedacht, dass es möglich wäre, wenn ich eine Zahl eingebe, dass diese in einer externen Excel-Datei landet. Scheinbar unmöglich oder doch? In dieser Excel-Datei, werden die Daten addiert, Scheinbar unmöglich oder doch? Mit jeder abgespeicherten Änderung der Ursprungszahl, wird diese durch ein Programm auch in der verknüpften Excel-Datei geändert, Scheinbar unmöglich oder doch? Die Summe der Excel-Datei wird in die Summe der Ursprungstabelle integriert, Scheinbar unmöglich oder doch? Aber ich schätze das war wieder 'ne blöde Idee von mir, bei techn. Problemen in Wikipedia zu fragen. Es ist fast immer sinnlos, weil ihr keine Lust habt außer euren eigenen Spielereien ein Arbeitserleichterung für andere zu bieten und ständig andere Ausreden habt um jedes Problem beiseite zu schieben. - Es ist doch illusorisch anzunehmen, dass bei etlichen Tausenden von Daten (Bsp. Italienische Gemeinden) einer manuellen Pflege den Vorzug zu geben besser sei, da: Eine Grundanforderung der Wikipedia ist, dass möglichst jeder Mensch unsere Artikel bearbeiten können soll, mit möglichst geringen Hürden. ... Forderung läuft auf einen Zielkonflikt hinaus: Wenn das nur noch drei Leute bearbeiten können, dann ist das auch keine gute Idee. - Frage mich wer die Einwohnerzahlen jährlich aktualisieren soll, wenn das: 188.483 Einwohner (Stand 31. Dezember 2022), erzeugt: 188.483 Einwohner (Stand 31. Dezember 2022) nicht mehr gehen soll. (Antwort kenne ich schon: Na solche Idioten wie Du!) - Wenn die Daten mehr als 10 Jahre alt sind, soll das besser sein, nur damit hier niemand ausgeschlossen wird. UND: Wenn jemand neue Werte einträgt, dann ist es die Verantwortung des Eintragenden, auch die Summen zu aktualisieren., diese Behauptung (ohne jegliche Relevanz; drin ist drin) wäre dann der sogenannte Todesstoß: eingetragen und nun bitte manuell jährlich einpflegen, derweil sich die Techniker hier die Fingernägel lackieren und regelrecht zu Tode schuften mit Arbeiten an andere zurück zu delegieren. Wenn mich jemand fragen sollte, wäre meine Antwort: Such Dir woanders Hilfe, hier ist es hoffnunglos, die wollen nicht, oder die können nicht! --Adelfrank (Diskussion) 18:01, 4. Aug. 2019 (CEST)

Liebes „Spatzenhirn“, eine passendere Stelle für deinen Vorschlag um Erweiterung ist Wikipedia:Verbesserungsvorschläge. Solltest du dort dein Anliegen vortragen wollen, verinnerliche bitte vorher unsere Wikiquette. Pauschale Beleidingungen aller (ehrenamtlichen) Techniker und weiterer Berufsstände sind sicher kontraproduktiv. --Wiegels „…“ 19:24, 4. Aug. 2019 (CEST)

Ein wirklicher Techniker steht da drüber. „Deine unzufriedensten Kunden sind deine größte Lernquelle.“ Ich finde die Kritik schon ein Stück weit verständlich. Hier eine Vorlage zu bauen (vor allem in Zeiten von Lua) sollte kein Problem sein. Das Problem dürfte nur sein, wie anwenderfreundlich bzw. wie allgemein diese zu sein vermag. Ich meine eine solche Vorlage schon auf En gesehen zu haben. Ein kleines JavaScript-Snippet könnte man auch zum Tabellen-Generator anfügen... -- User: Perhelion 22:32, 4. Aug. 2019 (CEST)

PS: Ich habe mal nach dem aktuellen Status für dieses Anliegen geschaut, ein wirklicher Techniker könnte sich hier phab:T120480 etwas dazuverdienen. -- User: Perhelion 23:05, 4. Aug. 2019 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Wiegels „…“ 19:24, 4. Aug. 2019 (CEST)

HTML oder CSS in den Beispielen?

Hallo, wäre es nicht besser bei den Beispielen generell nur CSS für die Formatierungen zu nutzen? Dies würde meiner Meinung nach das Vorkommen von seltsamem HTML-CSS-Doppelangaben und Mischanweisungen reduzieren. --Cepheiden 11:30, 31. Aug. 2010 (CEST)

Finde ich eine gute Idee. Vielleicht wäre es sinnvoll, das übliche „border="1"“ durch „class="wikitable"“ zu ersetzen. --Sepp (Diskussion) 11:53, 20. Aug. 2014 (CEST)

Ich verstehe nicht ganz, wovon ihr sprecht. @Cepheiden meint vielleicht, dass <div style="text-aline:center; margin:1em"> statt <div align="center" style="margin:1em"> verwendet werden sollte, um die Gegenüberstellung von Code und Ergebnis in den Beispielen zu formatieren. @Sepp scheint dagegen auf die Tatsache Bezug zu nehmen, dass die ersten Abschnitte des Artikels den Parameter border behandeln, von dessen Verwendung @Sepp anscheinend nichts hält. Wegen des letzteren Gesichtspunkts bin ich hier. Hier habe ich border="1" durch class="wikitable" ersetzt und das „Aktualisierung des Tabellendesigns“ genannt. Etwas später habe ich aus anderem Grund erstmals den „umseitigen“ Artikel gesehen. Hier sieht es so aus, als ob

Zelle 1	Zelle 2
Zelle 3	Zelle 4

im Vergleich zu

Zelle 1	Zelle 2
Zelle 3	Zelle 4

besonders anmutiges Design wäre, das man nur von mit HTML und CSS schon sehr vertrauten Nutzern erwarten könne, während ich eher gedacht hatte, das erste sehe unmöglich aus und stamme aus den HTML-Anfängen des vergangen Jahrtausends (vielleicht, weil ich das noch nie in Druckwerken gesehen habe). Wie sehen das denn andere? --Lückenlos^wecken! 08:01, 20. Apr. 2015 (CEST)

Ich sehe hier eher einen Aktualisierungsbedarf der Seite. Noch zur Klarstellung align="center" und border="1" sind kein CSS und sind auch seit WP:HTML5 obsolete.^[2] ↔ User: Perhelion  08:34, 20. Apr. 2015 (CEST)

• Der eine Teil stimmt nicht so ganz exakt: align= war schon 1998 mit HTML4 obsolet gewesen; border= ist es erst seit HTML5 offiziell.
• Schon vor HTML5 ging der Trend allerdings dahin, sämtliche dekorativen Fragen einheitlich in style= zu stecken und nur noch die strukturellen colspan= und rowspan= als Attribute zu verwenden. Siehe auch Hilfe:CSS.
• Das momentane Verhalten der Browser, beim Auftreten eines Attributs aus den 1990ern auch den optischen Stil der 1990er zu imitieren, ist zufällig und frei und durch nichts garantiert. Tatsächlich wird dieses 3D-Erscheinungsbild durch eine komplexe Kombination von border-style-Parametern bewirkt. Sieht man ein Wiki als eine langlebige Datenhaltung an, dann kann das optisch auch zukünftig ganz anders präsentiert werden.

style="border-color:#000000; border-style:ridge; border-width:5px;"

• Die Artikel geben weitaus überwiegend mittels wikitable ein einheitliches Design ab; ansonsten stehen richtige und übersichtlich dargestellte Inhalte im Vordergrund; rein dekorativer Schnickschnack und unsägliche Verkomplizierung ohne Bedeutungsverstärkung wird regelmäßig wieder zurückgebaut.
• Schlussfolgerung: Abschnitt/Seite überarbeiten, border= nicht mehr erwähnen, Umstellung auf wikitable; was ist daran überhaupt „komplexer“? Unter „komplexer“ verstehe ich Verschachtelung und Zellverschmelzung; das hier ist bloß Dekoration und nur wenig fortgeschritten, sondern rückschrittlich.

VG --PerfektesChaos 09:45, 20. Apr. 2015 (CEST)

Gut, das machen wir so! @align: da muss man wohl tatsächlich differenzieren zwischen deprecated (missbilligt) und obsolete (überholt) und den Elementen (tatsächlich war es für th, td, tr völlig zulässig und für table/div deprecated aber nicht obsolete, diese Unterscheidung gibt es für HTML5 nicht mehr).^[3] Ich werde das mal unter WP:HTML5 erwähnen. VG ↔ User: Perhelion  15:43, 20. Apr. 2015 (CEST)

Sortierbare Listen

Um zu beschreiben, was ich will, zuerst ein Anwendungsbeispiel: Bei vielen Songs, die in einem eigenen Artikel behandelt werden, gehört auch ein Abschnitt mit Coverversionen dazu. Üblicherweise werden sie als Liste mit Aufzählungspunkten präsentiert, also mit "*" im Quelltext, dem ein, zwei Sätze Fließtext folgen. Beispiel: Sympathy for the Devil#Coverversionen. Ich fände es schön, wenn man diese Liste nach beispielsweise Datum oder auch Name des covernden Interpreten sortieren könnte – ohne dabei optisch den Aufzählungspunkt-Charakter zu verlieren. Oberhalb oder unterhalb der Liste sollte ein Bedienungsteil sein, um das Sortierkriterium auszuwählen.

Kann man das machen, indem man eine Tabelle als sortable erstellt, die den Text beinhaltet, aber so umgestaltet wurde, dass sie wie ein Aufzählungspunkt-Liste aussieht? Ich stelle mir vor, dass in einer Spalte der Text reinkommt, in die zwei weitere Spalten kommen ausschließlich {{SortKey…}}, so dass keine Ausgabe auf den Schirm kommt, sondern lediglich Sortierschlüssel angegeben werden. (Die ich halt händisch aus dem Fließtext extahieren müsste.)

Ein erster Versuch:

Coverversionen (	Sortiert nach Datum	Sortiert nach Bandname	)
Lindra Kendrick veröffentlichte 1974 eine Version mit Chor und Orchesterbegleitung.				{{SortKey|1974}}	{{SortKey|Kendrick Lindra}}
Eine Coverversion des Stücks von Guns N’ Roses begleitet den Abspann des Films Interview mit einem Vampir (1995). Außerdem schreibe ich hier noch Blatext, um mal zu gucken, wie es sich bei ausführlicheren Auslassungen der Wikpedia-Haupt-, Neben-, Seiten- und Spaltenautoren auswirkend auf dem Schirm bemerkbar macht.				{{SortKey|1995}}	{{SortKey|Guns n Roses}}
Die Band Death SS veröffentlichte 2002 ein Cover auf ihrem Album Humanomalies.				{{SortKey|2002}}	{{SortKey|Death SS}}

Kritikpunkte:

• Wo muss »border="0"« hin, damit es wirkt?
• Die Aufzählungszeichen musste ich als bullets einfügen; sie sind etwas kleiner als die durch "*" erzeugten; beides verschmerzbar.
• Rechts sind komische schmale Leerspalten durch das colspan entstanden
• Die erste Zeile mit den drei Spalten ist viel zu prominent, <small> hilft auch nicht wirklich. Schöner wären z.B: Radiobuttons nebeneinander oder eine Dropdownliste; außerdem würde ich es eher an den unteren Rand der Aufzählung bringen.

Fazit: häßlich, im Ergebnis (zumindest beim gegebenen Beispiel) nicht zu rechtfertigen.

Gibt es schönere (Im Artikel) und elegantere (im Quelltext) Möglichkeiten, sowas zu erreichen?

-- Pemu (Diskussion) 15:22, 10. Aug. 2014 (CEST)

Bitte keine Tabellenkonstrukte nutzen um so etwas wie sortierbare Listen zu erzeugen. --Cepheiden (Diskussion) 15:30, 10. Aug. 2014 (CEST)

Die Semantik ist diskussionswürdig (semantisch ist das zumindest nicht komplett falsch, denn: jede Tabelle ist eine Liste, eine Liste aber nicht zwangsläufig eine Tabelle)... Aus dem Gesichtspunkt der Barrierefreiheit wäre es auch unproblematisch (ein Blinder "sieht" statt einer Liste eine Tabelle mit korrekt befüllten Spalten). Die Frage die sich aber zwangsläufig stellt ist warum du nicht einfach eine Tabelle machst. Du hast Informationen die sich wunderbar als Tabelle darstellen lassen (Interpret, Datum, Beschreibung), diese Daten in Fließtext zu "verstecken" macht es dem Leser doch schwieriger und nicht einfacher die Information zu erfassen. Ansonsten: Ja, das geht, wie auch Benutzer:Cepheiden würde ich aber eher davon abraten. --Vanger ^!–!? 23:11, 10. Aug. 2014 (CEST)

Warum ich nicht einfach eine Tabelle mache? Im Prinzip möglich, aber ich würde gerne die Freiheit haben. Wenn Interessantes zu einzelnen Coverversionen dasteht, kann man sie ja auch (trotz der Bullets) als Fließtext lesen. Wenn ich die Sätze so lassen will, wie sie im genannten Artkel standen, sieht eine Tabelle doof aus, weil mich (vorm/beim Lesen) die äußere Gestalt auf stichpunktartiges Listenwissen einstellen lässt. Außerdem glaube ich, dass die Aufzählungsliste dem Anlass angemessener ist und (damit) auf breitere Akzeptanz bei meinen Mitautoren stößt. -- Pemu (Diskussion) 09:21, 19. Aug. 2014 (CEST)

Ich finde die Idee dafür eine Tabelle zu verwenden auch nicht so toll, aber ich habe die obige Tabelle mal so angepasst, dass sie Deinen Vorstellungen etwas näher kommt. Zu Deinen Kritikpunkten: Auf Wikitable verzichten, ohne Border sind die Phantomspalten nicht mehr zu sehen, für richtige Aufzählungspunkte muss der Inhalt in einer neuen Zeile anfangen (siehe Hilfeseite) und durch eine Extraspalte lässt sich die Überschrifszeile komprimieren. Eine alternative Implementation wäre mit der ominösen Vorlage:SortKeyColspan:

{| class="sortable"
! class="unsortable" | Coverversionen (
! Sortiert nach Datum
! Sortiert nach Bandname
! class="unsortable" width="100%" style="text-align:left;" | )
|-
{{SortKeyColspan|colspan=4|width=9.6|txtAlign=left|key=2002|key3=Death SS|txt=
*Die Band Death SS veröffentlichte 2002 ein Cover auf ihrem Album Humanomalies.}}
|-
{{SortKeyColspan|colspan=4|width=9.6|txtAlign=left|key=1995|key3=Guns N’ Roses|txt=
* Eine Coverversion des Stücks von Guns N’ Roses begleitet den Abspann des Films Interview mit einem Vampir (1995). Außerdem schreibe ich hier noch Blatext, um mal zu gucken, wie es sich bei ausführlicheren Auslassungen der Wikpedia-Haupt-, Neben-, Seiten- und Spaltenautoren auswirkend auf dem Schirm bemerkbar macht.}}
|-
{{SortKeyColspan|colspan=4|width=9.6|txtAlign=left|key=1974|key3=Lindra Kendrick|txt=
*Lindra Kendrick veröffentlichte 1974 eine Version mit Chor und Orchesterbegleitung.}}
|}

Diese Vorlage scheint mir aber für solche Dinge nicht vorgesehen zu sein und macht das Warten auch nicht leichter. Beide Varianten sind ziemlich zusammengehackt. Wäre nicht eine solche Tabelle auch in Ordnung, sie wäre deutlich leichter zu warten:

Coverversionen

Jahr	Bandname	Anmerkung
1974	Lindra Kendrick	Version mit Chor und Orchesterbegleitung
1995	Guns N’ Roses	Die Coverversion begleitet den Abspann des Films Interview mit einem Vampir.
2002	Death SS	Im Album Humanomalies enthalten. Und dazu sag ich mal Lorem ipsum dolor sit amet, consectetur adipisici elit, sed eiusmod tempor incidunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquid ex ea commodi consequat.

Bevor Du das großflächig änderst, kläre das am Besten erstmal im entsprechenden Portal. --Sepp (Diskussion) 11:28, 20. Aug. 2014 (CEST)

Die Vorlage:SortKeyColspan brauchts hier nicht, siehe Benutzer:Vanger/Arbeitsspeicher. Ich hatte diese Lösung übrigens bewusst nicht gepostet Benutzer:Sepp, ein Hack ist hier einfach nicht nötig - eine normale Tabelle ist semantisch wie auch inhaltlich sinnvoller. (Übrigens: Die Vorlage:SortKeyColspan ist nicht "ominös" sondern hat solange ihre Existenzberechtigung, bis sich die WMF dazu durchringt, das ins JavaScript der Sortierfunktion zu integrieren und damit den Hack unnötig zu machen...) --Vanger ^!–!? 02:45, 21. Aug. 2014 (CEST)

Koordinatenangaben werden nicht richtig sortiert

Koordinatenangaben werden nicht richtig sortiert. Hier zum Beispiel kommt 16°6' nach 16°59', und 17°2' nach 17°10'. Hier wird offensichtlich alphabetisch sortiert, obwohl intern Grad mit Nachkommastellen angegeben sind. Gibt es eine Möglichkeit, hier eine korrekte Sortierung von Nord nach Süd zu erzwingen?--Ratzer (Diskussion) 16:17, 21. Aug. 2014 (CEST)

Hallo Ratzer, du kannst bei der Einbindung der Coordinate-Vorlage den Parameter sortkey belegen, um eine Sortierung zu veranlassen. --Wiegels „…“ 16:44, 21. Aug. 2014 (CEST)

Danke, da hilft wohl nix als bei jedem Tabelleneintrag einzeln Hand anzulegen..--Ratzer (Diskussion) 17:27, 21. Aug. 2014 (CEST)

Ich geb auf

Hier versuche ich vergeblich, die ineinandergeschachtelte Tabelle so aussehen zu lassen, wie unten. An welcher Stelle fehlt ein align=center oder style="text-align:center", damit die inneren Tabellen der oberen Artikelhälfte mittig stehen wie die in der unteren Hälfte? Ich sehe keinen Unterschied im Code. Die inneren Tabellenrahmenränder sind nur zur Verdeutlichung sichtbar gemacht. --Tommes ^✉ 18:05, 4. Okt. 2015 (CEST) Ping an @PerfektesChaos, Mfb, Boshomi: angehängt, eine Kleinigkeit für Euch.

style="text-align:center" richtet keine Tabellen aus. Versuchs mal mit CSS oder mit Wiki-CSS-Klassen wir class="center", vgl. Hilfe:Tabellen#Ausrichtung der Tabelle. --Cepheiden (Diskussion) 20:10, 4. Okt. 2015 (CEST)

class=centered zentriert die Tabelle wirklich. In der unteren Tabelle (WK II) funktioniert es aber auch ohne dieses. Was ist dort anders? --Tommes ^✉ 21:06, 4. Okt. 2015 (CEST)

Nein es funktioniert unten auch nicht. Dort sind die äußeren Tabellen aber nicht breiter als die inneren, daher scheint es so. Entferne mal obenn die "width:75%". Insgesamt halte ich die Struktur mit drei ineinander geschachtelten Tabellen für zu umständlich. Ich mach mal 'nen Vorschlag. --Cepheiden (Diskussion) 21:20, 4. Okt. 2015 (CEST)

Mhh, ich sehe was du mit border und der Hintergrundfarbe erreichen willst, das geht mit weniger Tabellen und CSS leider nicht so einfach (außer man definiert Klassen, was in der Wiki nicht individuell machbar ist). Da kann ich also auf die Schnelle keine gleichwertige optimierte Version anbieten. Nur Korrekturen. -- Cepheiden (Diskussion) 21:28, 4. Okt. 2015 (CEST)

Ich habe mal eine innere Tabelle entfernt und dafür mit padding:7px eingerückt. Durch Weglassen von width:33% wird jede Spalte vom Browser so breit dargestellt, dass der Inhalt hineinpasst. Dadurch gibt es auch bei schmaleren Anzeigefenstern keine Zeilenumbrüche. --MatthiasDD (Diskussion) 21:46, 4. Okt. 2015 (CEST)

Ich danke vielmals für Eure Beteiligung! Ich bevorzuge die doppelte Tabelle, um einen äußeren Rand zu erzielen, der mit spacing und padding nicht so zu erreichen ist. Daß unten die inneren Tabellen die äußeren nahezu ausfüllen, erklärt deren "korrektes" aussehen. Ich sehe es mir morgen auf einem anderen Browser noch mal an. Mir scheint die Lösung mit class="centered" das, was ich noch brauchte. Danke Euch! --Tommes ^✉ 22:51, 4. Okt. 2015 (CEST)

Ich habe mal die Tabellen-Verschachtellung bis in die 3. Ebene entfernt. Der line-height Workaround ist leider nicht ganz geeignet um Tabellenhöhe festzulegen. ↔ User: Perhelion  20:37, 21. Dez. 2015 (CET)

Wiedermal Tabellen, Tabellen ..

Ich möchte hier im rechten der drei Teile die Inschrift und deren kleine Überschrift (was die Zeilen 2 und 3 sind) direkt unter dem Bild stehen haben. Warum ist aber dort soviel Platz unter dem Foto? Der Platz sollte ganz unten sein. (Ping an Helfer von neulich: @Cepheiden, MatthiasDD:) --Tommes ^✉ 22:18, 23. Nov. 2015 (CET)

Hallo Tommes, der Platz unter dem Bild war da, weil der Browser versucht hat, die gesamte verfügbare Höhe mit den drei übereinanderliegenden Tabellenzellen möglichst gleichmäßig auszufüllen. Jetzt stehen die Inhalte des rechten Teils oben ausgerichtet in einer einzigen Tabellenzelle. --Wiegels „…“ 00:19, 24. Nov. 2015 (CET)

Wenn ich es richtig verstanden habe, hast Du statt meiner jeweils neu angelegten Tabellenzellen und -zeilen einfach mit einem <div>-Tag (<div style="background-color:#ddd; padding:1em; text-align:center">) in derselben Tabellenzeile weiter getextet. Danke sehr!--Tommes ^✉ 18:08, 24. Nov. 2015 (CET)

Genau so habe ich das gemacht. Stimmt es, dass auf dem Schild „Legende Soldaten“ steht, nicht „Liegende“? Weißt du, was das bedeuten soll? --Wiegels „…“ 20:41, 24. Nov. 2015 (CET)

Alois-Kottmann-Preis

Als vor Jahren die Tabelle der Preisträger eingebaut wurde, wurde offenbar ein Fehler gemacht. Es ist ja wohl nicht sinnvoll, wenn die folgenden Kapitel neben der Tablle weiter gehen.
Ich habe allerdings nur rudimentäre Tabellenkenntnisse und finde daher den Fehler nicht. Kann mal jemand reinschauen?
Gruß --Baumfreund-FFM (Diskussion) 08:17, 21. Feb. 2016 (CET)

Hallo Baumfreund-FFM, ist es jetzt besser? Eigentlich lag es am style="... float:left; ...", was dafür sorgt, dass das Folgende rechts vorbei fließen darf, eher geeignet für kleine Tabellen und Bilder. --Wiegels „…“ 14:25, 21. Feb. 2016 (CET)

Hallo Wiegels,

wunderbar – herzlichen Dank für die schnelle Hilfe und die Erläuterung.

Gruß --Baumfreund-FFM (Diskussion) 15:02, 21. Feb. 2016 (CET)

Absteigend sortieren

Bei Zählen wird standardmäßig erst aufsteigend sortiert. Erst beim zweiten Klick auf die Sortierung wird absteigend sortiert. Gibt es eine Option, dies umzudrehen? --ElTres (Diskussion) 10:11, 14. Mär. 2016 (CET) P.S.: Absteigende Sortierung dürfte in den meisten Anwendungsfällen sowieso interessanter sein. ElTres (Diskussion) 10:11, 14. Mär. 2016 (CET)

Sortierung Einwohnerzahlen

Unter Gemeinden der Schweiz-A werden die Einwohnerzahlen mittels Vorlagen ausgegeben. Bei Sortierung der Einwohnerzahlen werden diese derzeit nach der ersten Zahl sortiert, unabhängig von der Anzahl der Ziffern. Sofern im Tabellenkopf in der Spalte „Einwohner“ data-sort-type="number" ergänzt wird, sieht es etwas besser aus, jedoch werden zuoberst jene Gemeinden mit 10.000 bis 20.000 Einwohnern aufsteigend angezeigt, danach alle dreistelligen Einwohnerzahlen aufsteigend. Wer hat eine Lösung parat? – PsY.cHo (Diskussion) 15:22, 9. Apr. 2016 (CEST)

Hochkommata (') werden nicht als gültiges Tausendertrennzeichen erkannt. Du kannst statt Vorlage:EWZ CH alternativ Vorlage:EWZ verwenden, oder, falls du das Hochkommata als Tausendertrennzeichen als wichtig empfindest, die Vorlage:EWZ für das Attribut data-sort-value="" verwenden.

Beispiel: | [[Aarau]] || {{CH-AG}} || style="text-align: right;" data-sort-value="{{EWZ|CH-AG|4001}}"| {{EWZ CH|CH-AG|4001}}

--Vanger ^!–!? 01:42, 10. Apr. 2016 (CEST)

Vielen Dank, es hat funktioniert. – PsY.cHo (Diskussion) 09:10, 10. Apr. 2016 (CEST)

text-indent

So ich bin mal wieder über etwas gestolpert, wonach ich manchmal eigentlich schon gesucht hatte, aber nicht wusste wie man das eventuell nennt. Wenn ich das richtig verstehe, lässt sich beispielsweise mit style="text-indent:4px;" der Text in den einzelnen Zellen um 4px nach rechts rücken.

{| class="wikitable" |- |style="text-indent:4px;"| Ein um 4px nach rechts eingerückter Text |style="text-indent:4em;"| Ein um 4em nach rechts eingerückter Text |- | Text ohne Verschiebung | Text ohne Verschiebung |}	Ein um 4px nach rechts eingerückter Text Ein um 4em nach rechts eingerückter Text Text ohne Verschiebung Text ohne Verschiebung
oder als Zuweisung für die komplette Tabelle
{| class="wikitable" style="text-indent:1em;" |- | Ein um 1em nach rechts eingerückter Text | Ein um 1em nach rechts eingerückter Text |- |style="text-indent:0;"| Text ohne Verschiebung |style="text-indent:0;"| Text ohne Verschiebung |}	Ein um 1em nach rechts eingerückter Text Ein um 1em nach rechts eingerückter Text Text ohne Verschiebung Text ohne Verschiebung

Negative Werte eignen sich aber scheinbar nicht wirklich bei Wikitable

Ein um 1em nach links eingerückter Text	Ein um 1em nach links eingerückter Text
Text ohne Verschiebung	Text ohne Verschiebung

Da das in →einigen Artikeln benutzt wird, sollte man da nicht auf diese Möglichkeit der Formatierung hinweisen, oder ist das eher unerwünscht und sollte entfernt werden? --Liebe Grüße, Lómelinde Diskussion 09:13, 13. Jul. 2016 (CEST)

• Dieses text-indent ist ein riesiges Mistverständnis.
  • Da hat mal wieder irgendwer irgendwo irgendwas gesehen und abkopiert, ohne zu wissen, was es ist.
• text-indent ist der Einzug nur der allerersten Zeile eines Absatzes (jede Tabellenzelle ist ein Textblock wie auch ein Absatz).
• text-indent gehört zum Absatz (Text) #Einzug.
  • Der passt wiederum in gedruckte Werke, während die deutschsprachige Wikipedia keinen Einzug an die Webtexte stellt. Zumal das ungeeignet für dynamische Texte ist, die von Laien permanent umgestrickt werden und bei denen sich andere das Layout beeinflussende Elemente wie Bilder und Aufzählungen ständig anders dazwischen mischen. Das bräuchte schon eine hochintelligente Software, um das automatisiert richtig zu formatieren, und würde dann von Autoren doch wieder ausgehebelt.
• Bei Tabellen, und um die geht es umseitig, ist es völliger Quatsch.
  • Der Abstand in Tabellenzellen heißt padding in CSS.
  • In wikitable ist padding längst definiert.
  • Der Einzug der ersten Zeile, um den Absatz optisch von dem vorangehenden Absätzen zu trennen, ist bei Tabellenzellen totaler Unsinn; dort ist in der Regel eine Trennlinie und ansonsten ein Abstand zwischen den Zellen.
  • Möglicherweise wollte man das padding-left erhöhen oder etwas wie „mittig“ oder gar „rechtsbündig“ erreichen.
  • Wenn die Tabellenzelle nur aus einem Wort besteht oder mehrere Wörter meist in eine Zeile passen, hat das optisch so eine ähnliche Wirkung; nur doof, falls bei schmalem Bildschirmfenster plötzlich ein Zeilenumbruch nötig wird – dann gibt es Bruch.
• Die Dinger müssten fast alle wieder raus.
  • Nur wenn nach Art eines Faksimile das Schriftbild eines historischen Druckwerks nachgeahmt werden soll, hätte es seine Berechtigung.
  • In Tabellen können sie wohl komplett entfernt werden; möglicherweise müssten sie aber durch text-align ersetzt werden, wenn das die Absicht war.
  • Vielleicht lassen sich Themengebiete von Artikeln identifizieren und innerhalb dieser abkopierter Unsinn, der durch einen Bot ersetzt werden kann, damit man erstmal von den 266 Einzelfällen runterkommt.
    • Irgendwas mit -eder hinten habe ich mir schon mal zur Modernisierung abgegriffen.
  • Der Rest ist Handarbeit und Einzelfallentscheidung.
  • Die Dinger sollten in absehbarer Zeit eliminiert werden, damit sie nicht abkopiert werden und auch noch Junnge kriegen.

Gut aufgepasst. LG --PerfektesChaos 11:31, 13. Jul. 2016 (CEST)

Also sollte ich es rausschmeißen. Irgendwo hatte ich noch etwas was ich auch noch nicht kannte. Rules=rows. Ich vergesse aber oft es mir irgendwo zu notieren und finde dann nicht mehr was es war, weil ich vergesse, wie es hieß. --Liebe Grüße, Lómelinde Diskussion 11:53, 13. Jul. 2016 (CEST)

Die text-indent habe ich erstmal unter 150 geschossen, damit sie nicht abkopiert werden; nun langt es erstmal.

rules="rows" ist für uns überdimensioniert, aber schadet nicht.

LG --PerfektesChaos 23:54, 5. Sep. 2016 (CEST)

Sehr schön, vielen Dank. --Liebe Grüße, Lómelinde Diskussion 19:11, 6. Sep. 2016 (CEST)

−0 und +0 immer absteigend sortiert

Kopf
+0
1
−1
−0

Was nicht hilft:

• data-sort-type="number"
• Bindestrich statt Minuszeichen
• Pluszeichen weglassen

Lästiger Workaround:

Kopf
+0
1
−1
−0

--Rainald62 (Diskussion) 21:00, 5. Nov. 2016 (CET)

+0 und -0 sind mathematisch 2 gleiche Zahlen 0. Lösung: Die +0 etwas größer machen mit 10^-9:data-sort-value="1e-9"| +0, oder die -0 etwas kleiner.

Kopf
+0
1
−1
−0

--MatthiasDD (Diskussion) 22:56, 5. Nov. 2016 (CET)

Danke. Ich war schon ganz nah dran, der data-sort-value "0.5" wurde aber als Text interpretiert. "0,5" hätte funktioniert, mir ist das Dezimalkomma in Skript-Kontexten fremd. --Rainald62 (Diskussion) 02:37, 6. Nov. 2016 (CET)

In den Tabellenzellen stehen lokalsprachlich formatierte Werte.

Diese sollen erkannt und einsortiert werden.

Mit dem data-sort-value wird nun ein Wert simuliert, der scheinbar in der Tabellenzelle stünde.

Also ist das lokal formatiertes Datum, Zahl oder was immer.

VG --PerfektesChaos 11:44, 6. Nov. 2016 (CET)

Rangspalte

Kann man die „Tabelle in der Tabelle“ etwas ausführlicher erläutern als nur mit dem Hinweis auf ein Beispiel (in dem ich keine zusätzliche Tabelle erkennen kann). --Janjonas (Diskussion) 21:04, 9. Nov. 2016 (CET)

Ja. Grüße --Diwas (Diskussion) 23:29, 9. Nov. 2016 (CET)

Portal:Klavier

Hallo, in meiner arg verschachtelten Portalseite gelingt es mir nicht die linke Spalte zu verkleinern, in der Vorschau sieht es gut aus, wenn das Wikipediamenu dazukommt ist die zweite Spalte viel zu schmal, erste und zweite Spalte sollten gleich breit sein. Ich hatte mich am Portal:Orgel orientiert, aber irgendwann wurde es anscheinend zu komplex. Für Vorschläge oder Umgestaltungen in diesem Sinne wäre ich dankbar. -- Room 608 (Diskussion) 15:09, 23. Dez. 2017 (CET)

Hallo Room 608, das Problem wurde verursacht von den Schweizer Anführungszeichen im Baustein Portal:Klavier/Schon gewusst, die ich hiermit durch einfache Anführungszeichen ersetzt habe. Die Mediawiki-Software scheint für die Darstellung vor und hinter solchen Anführungszeichen normale Leerzeichen duch (vor Zeilenumbruch) geschützte Leerzeichen zu ersetzen, was zur Folge hat, dass die sechs Wörter „mit »Himmelsblau«, »Liebesleid« und »Wiesengrund« skandiert“ immer in derselben Zeile stehen. --Wiegels „…“ 16:08, 23. Dez. 2017 (CET)

Wunderbar, darauf muss man erstmal kommen. Sieht aus wie geplant. Ich hatte damals schon die letzte Umstellung des Gesamterscheinungsbildes der Wikipedia in Verdacht. Und Zeilen auf Umbruchfallen hatte ich auch schon abgesucht. Vielen Dank. Und da hatte ich mir so viel Mühe mit den hübschen Anführungszeichen gegeben. -- Room 608 (Diskussion) 20:02, 23. Dez. 2017 (CET)

@Wiegels: Scheint nicht nur so, ist auch seit einem Jahrzehnt so.

Sprachliche Unterscheidung:

fr-CH	«Le Léman»
fr	« Pont d’Avignon »
de-CH	«Basel»
de	„Bonn“

Aus genau diesem Grund sieht WP:TYP die „…“ vor.

Verwendet man nun die hübschen deutschen Buchdrucker-Anführungszeichen für »Hamburg« und »Bremen«, dann schlägt MediaWiki zu und hält und für französisch.

LG --PerfektesChaos 12:26, 27. Dez. 2017 (CET)

Seltsam, ich hatte den Eindruck es ist mit der letzten größeren Mediawikiumstellung geschehen, die aber nicht zehn Jahre her ist. Und Französisch kann mediawiki auch nicht. --Room 608 (Diskussion) 02:21, 28. Dez. 2017 (CET)

schönere Tabellendarstellung?

Hallo, kenne mich mit Formatierung nicht sonderlich gut aus. Deshalb die Frage: Wie kann ich hier die Tabellen so darstellen, dass sie alle die gleiche Höhe haben und nicht in unterschiedlichen Zeilen anfangen? --Siebenschläferchen (Diskussion) 17:23, 18. Jun. 2018 (CEST)

Hallo Siebenschläferchen, die Unterschiede kommen aus den Tabellentiteln, die meistens einzeilig und manchmal zweizeilig sind. Der Verzicht auf Fettformatierung und einfache Verringerung der Schriftgröße reicht hier nicht aus, um Einzeiligkeit zu erreichen. Du könntest entweder durch Hinzufügen von festen Umbrüchen bei allen Titeln zweizeilige Überschriften erzwingen oder durch Vorgabe einer geeigneten festen Tabellenbreite oder Namensspaltenbreite genügend Platz für einzeilige Titel schaffen. Brauchst du Hilfe dabei? --Wiegels „…“ 23:25, 18. Jun. 2018 (CEST)

Danke für die schnelle Hilfe. Ich habs mir jetzt einfach gemacht und einfach die Namen so angepasst, dass sie in eine Zeile passen. Nur aus Interesse, wie würdest du die Breite der Namensspalte festlegen?--Siebenschläferchen (Diskussion) 09:55, 19. Jun. 2018 (CEST)

Hallo Siebenschläferchen, du kannst die Breite der Namensspalte festlegen, indem du ! Name durch ! style="width:15em;" | Name ersetzt, wobei du die Breitenangabe (hier: 15em) variieren kannst. --Wiegels „…“ 11:06, 19. Jun. 2018 (CEST)

Danke!--Siebenschläferchen (Diskussion) 23:01, 19. Jun. 2018 (CEST)

Zeilenhöhe

Die Zeilenhöhe scheint sich mit style=height anpassen zu lassen. Soll man das bei Bedarf verwenden?

2	10	20
A	B	C

--Diwas (Diskussion) 12:50, 20. Jun. 2018 (CEST)

Zum einen ist height: nicht notwendigerweise bei allen anderen Browsern gleich wirksam, sondern bedarf ggf. min-height:, zum anderen ist das eine Lösung auf der Suche nach einem Problem. Wir verwenden Tabellen nicht, um irgendwelche platzraubenden Layout-Effekte vorzugeben, sondern überlassen es dem Browser, die wichtigen Inhalte platzsparend unter den Bedingungen bei den Lesern anzuordnen. Es gibt Dutzende weitere Attribute, die wir auch nicht alle erwähnen. CSS ist riesig. LG --PerfektesChaos 13:08, 20. Jun. 2018 (CEST)

Danke für die Bestätigung meiner Vermutungen. Anlass der Frage war das Problemchen eins drüber, wo die Überschriften mal einzeilig mal zweizeilig waren, aber dafür gibt es ja schon Lösungen. Grüße --Diwas (Diskussion) 00:11, 21. Jun. 2018 (CEST)

Einrückung/ Einzug

Wie nimmt man eine Einrückung innerhalb einer Zelle vor?

Der Doppelpunkt an Zeilenanfang scheint ja innerhalb einer Tabelle nicht zu funktionieren.

nette Grüße, Kai Kemmann (Diskussion) - Verbessern statt löschen. - 15:27, 1. Aug. 2018 (CEST)

Der Doppelpunkt an Zeilenanfang ist eine Spezialität von Diskussionsseiten wie dieser, produziert kaputte Syntax und hat auf richtigen Seiten und insbesondere im ANR nix am Suchen.

Es geht mittels CSS ähnlich umseitig Hilfe:Tabellen für Fortgeschrittene #Rechtsbündige Anordnung.

Ü
Normal	Normal
Einrückung	Normal
Große Einrückung	Normal

VG --PerfektesChaos 15:57, 1. Aug. 2018 (CEST)

Danke, liebes PerfektesChaos

Magst Du das vielleicht in den Absatz Hilfe:Tabellen für Fortgeschrittene #Ausrichtung mit aufnehmen?

Das wird ja vermutlich auch noch andere Nutzer interessieren.

Ist die Aufzählung mittels „ ; “ und „ : “ im Artikelnamensraum übrigens auch nicht erwünscht?

Sollte man immer Überschriften mit z.B. „ ===== ... ===== “ statt der Fettschrift per „ ; “ verwenden?

nette Grüße

Kai Kemmann (Diskussion) - Verbessern statt löschen. - 23:35, 8. Aug. 2018 (CEST)

Nein, es gehen Tausende von Sachen, aber niemand blickt mehr durch, wenn man versucht, alles was irgendwen interessieren könnte, auch noch dazuzuschreiben, und es sollte ohnehin nur sehr sparsam eingesetzt werden und nur wenn unbedingt erforderlich und nicht lediglich aus dekorativen Gründen die Syntax verkompliziert werden, bloß weil irgendwer findet, dass sein Artikel damit schick aussähe. Und vollständige Paarungen aus ; und : sind okay, bloß nicht in kastriert. VG --PerfektesChaos 00:59, 9. Aug. 2018 (CEST)

Kurze Frage: Zeilenhöhe

Hello Zusammen. Habe ne kurze Frage. Auf der Seite Paraclimbing habe ich die Tabelle mit Bildern ausgestattet, was mir allerdings nicht gefällt, ist, dass er jeweils die letzte Zeile extrem verzerrt/verbreitert, anstatt es auf die zwei/drei Zeilen zu verteilen. Versteht ihr, was ich meine? Kann man irgendwie die Zeilenhöhe einstellen? Danke schonmal, --KrätzchenEcho (Diskussion) 17:50, 20. Nov. 2018 (CET)

Normalerweise so wie in Hilfe Diskussion:Tabellen für Fortgeschrittene#Zeilenhöhe angesprochen wäre das zwar möglich, ist aber eher nicht erwünscht. In dem Falle geht das auch nicht wirklich, da die Zeilenhöhe durch die Höhe der Bilder vorgegeben ist und sich ja quasi schon automatisch anpasst.

Klasse	Kategorie	Behinderung	Beispielhaftes Foto
Visual	B1	Blindheit	Beispiel style="line-height:10px;"
Visual	B1	Blindheit	Beispiel style="line-height:20px;"
Visual	B1	Blindheit	Beispiel style="line-height:30px;"
Visual	B1	Blindheit	Beispiel style="line-height:40px;"

Kleiner als Bildhöhe ginge zwar auch, dann aber nur mit Scrollbalken.

Paraclimbing-Klassen und -Kategorien der IFSC

Klasse	Kategorie	Behinderung	Beispielhaftes Foto
Visual	B1	Blindheit	B1
	B2	Sehschärfe ⩽2/60 oder Gesichtsfeld ⩽ 5 %
	B3	Sehschärfe ⩽6/60 oder Gesichtsfeld ⩽ 20 %
Amputee	AL-1	Amputation/Fehlbildung von zwei Beinen	AL-2
	AL-2

Das ist aber sicherlich nicht das, was du meintest. --Liebe Grüße, Lómelinde Diskussion 14:52, 24. Nov. 2018 (CET)

Colspan?

Also nicht generell, ich weiß natürlich was clospan tut aber ist →das hier erwünscht oder wäre es überhaupt korrekte Syntax? Oder wird es, so wie ich vermute, eher als colspan="100" = überspanne 100 Zellen interpretiert?

rowspan="0"	Zelle	Zelle	Zelle	Zelle	Zelle
Zelle	colspan="3%"	Zelle
colspan="100%"

rowspan="0"	Zelle	Zelle	Zelle	Zelle	Zelle
Zelle	colspan="3"			Zelle
colspan="100"

Erzeugt also quasi eine Tabelle mit offenem Rand rechts. Ich meine zumindest beim rowspan, was auch oft mit 99 belegt wird, weil man vermutlich einfach zu faul zum zählen ist, ist das dann unten manchmal nicht geschlossen. Ich finde es eigentlich nicht wirklich toll, colspans gibt es auch mit 100 ohne % oder auch 99 … --Liebe Grüße, Lómelinde Diskussion 14:52, 24. Nov. 2018 (CET)

colspan darf nur ganzzahlige Werte von 1…1000 haben html.spec.whatwg.org. Nur bei rowspan ist die "0" erlaubt und bedeutet "die ganze Tabelle oder rowgroup", siehe oben. Das % ist nicht erlaubt. --MatthiasDD (Diskussion) 11:46, 24. Mär. 2019 (CET)

Warum nur zwei Möglichkeiten bei der Ausrichtung nach der Kommastelle?

Im Abschnitt H:Tabellen für Fortgeschrittene #Ausrichtung nach der Kommastelle heisst es, dass es zwei Möglichkeiten gibt, die linksbündige Anordnung und die rechtsbündige Anordnung. Ich verstehe nicht die Beschränkung auf diese beiden Möglichkeiten. Als dritte Möglichkeit gibt es auch bei Zahlen mit unterschiedlichen Stellenzahlen die zentrische Anordnung mit style = "text-align:center". Man muss dann nur die Vorlage:0 in geeigneter Weise einsetzen, damit die einzelnen Zahlenstellen korrekt übereinander erscheinen. Dann wird die längste Zahl in die Mitte der Spalte gesetzt und die anderen Zahlen entsprechend darüber und darunter. Auch die Sortierung funktioniert einwandfrei.
Wenn die Überschrift der Spalte breiter ist als die darunterstehenden Zahlen und dadurch eine grössere Breite der Spalte erzwingt, sieht die Zahlenkolumne in zentrischer Anordnung in aller Regel gefälliger aus, als wenn sie an den linken oder rechten Rand der Spalte gerückt ist. --BurghardRichter (Diskussion) 16:23, 4. Apr. 2019 (CEST)

Na, das zentrierte Anordnen ist halt etwas wacklig, und das Gepfusche und Gehacke mit unsichtbaren dazugedichteten Nullen ist auch nicht so das Gelbe vom Ei.

Insofern sind diese ganzen Varianten nicht so superb.

Optimal wäre vielmehr rechtsbündig mit padding-right; aber das ist viel zu viel action für unser handgeschmiedetes Zeugs. Das wäre dafür robust, wenn die Anzahl der Nachkommastellen einheitlich gehandhabt wird oder keine vorhanden sind.

Alles hat quelltechnische Verkomplizierung und Tücken zur Folge, und die ausgewählten empfohlenen Lösungen reichen für die Hilfeseite völlig, und die weiteren Konstrukte können sich die Autoren auch selbst ausdenken; wir müssen das Gemurkse nicht noch als empfehlenswertes Vorgehen propagieren.

VG --PerfektesChaos 16:47, 4. Apr. 2019 (CEST)

Ich denke auch, dass es sich nicht empfiehlt, so etwas durch übermäßigen Gebrauch von {{0}} umzusetzen. Man stelle sich mal eine Tabelle vor, die mehrere solcher Spalten und mehr als diese vier Zeilen hätte.

{| class="wikitable sortable" style="text-align:center"
|-
! class="unsortable"| Nr. !! (Mit Vorlagen) !! (ohne)
|-
| 1
| 1000{{0|,0000}} || 1000
|-
| 2
| {{0|000}}1,0001 || 1,0001
|-
| 3
| {{0}}200,2{{0|000}} || 200,2
|-
| 4
| {{0|00}}11,1{{0|000}} || 11,1
|}

Vor lauter Vorlagen, vor und hinter den Werten, würde man den eigentlichen Inhalt kaum noch sehen. Ich würde das nicht empfehlen wollen. --Liebe Grüße, Lómelinde Diskussion 16:58, 4. Apr. 2019 (CEST)

Vielen Dank für eure Antworten!

@PerfektesChaos: Was meinst du mit „etwas wacklig“? Deine Wortwahl („Gepfusche und Gehacke“, „nicht so das Gelbe vom Ei“, „Gemurkse“) lässt mich vermuten, dass deine Ablehnung im wesentlichen subjektiv begründet ist. Das will ich gar nicht kritisieren. Meine Frage ist konkret: Gibt es objektive Gründe, weshalb eine Anordnung der Zahlen in der Mitte weniger günstig ist als am linken oder rechten Rand?

Die Vorlage:0 braucht man bei einer linksbündigen Anordnung der Zahlen ebenso wie bei einer zentrischen Anordnung. Und die explizite Angabe style="text-align:right" für die rechtsbündige Anordnung ist nicht weniger aufwendig als style="text-align:center". Daher sehe ich bei der zentrischen Anordnung überhaupt keine Verkomplizierung der Quelldatei. Kompliziert und unübersichtlich wird die Quelldatei, wenn zum Beispiel Einträge, die sich über mehrere Spalten oder Zeilen erstrecken, hinzukommen, aber nicht durch die Zentrierung der Einträge in einzelnen Spalten.

Aber es könnte vielleicht sein, dass bei zentrischer Anordnung unter bestimmten Umständen einiges nicht zuverlässig funktioniert, zum Beispiel die Sortierung, wenn gleichzeitig unterdrückte Nullen und Referenzen vorhanden sind, oder irgend so etwas, und dass in dieser Hinsicht die links- und die rechtsbündige Anordnung robuster sind. Das wäre dann ein objektiver Grund, nach Möglichkeit keine zentrischen Anordnungen vorzunehmen. Darum noch einmal meine Frage: Gibt es solche objektiven Gründe gegen die zentrische Anordnung?

@Lómelinde: Dein konstruiertes Beispiel ist beeindruckend; aber vier Zahlen von so unterschiedlicher Grössenordnung innerhalb einer Tabellenspalte sind höchst untypisch. Als Gegenbeispiel sieh dir einmal die beiden Tabellen im Artikel Metropolregion Hamburg an. Dass alle Zahlen in den numerischen Spalten an den rechten Rand gedrückt sind, sieht nach meinem Empfinden unmöglich aus, zumal die Überschriften der Spalten zentriert sind. Und solche Tabellen gibt es zu Tausenden in der deutschen Wikipedia. Und das nur, weil es dem Verfasser zu mühsam ist, den kürzeren Zahlen in den einzelnen Spalten unsichtbare Nullen voranzustellen? Bei den vielen Steuerbefehlen, die solch eine Tabelle ohnehin enthält, würde das nicht zusätzlich ins Gewicht fallen. --BurghardRichter (Diskussion) 20:31, 4. Apr. 2019 (CEST)

Die Vorlage:0 verfälscht den Inhalt.

• Sie fügt dem Dokument-content Inhalte hinzu, die gar nicht hineingehören, und die nur optisch ausgeblendet werden.
• Es ist messtechnisch ein Unterschied, ob etwas den Wert 17 oder 17,0 oder 17,00 hätte.
• Alle Inhalte von HTML-Elementen gehören zum sogenannten content, völlig egal, ob diese sichtbar sind oder nicht. Bei Google-Suchergebnissen, möglicherweise auch bei Cirrus kannst du sie wohl sehen.

Aus dem gleichen Grund hatte man schon vor einem Jahrzehnt weltweit die Sort-Vorlagen für obsolet erklärt und die MediaWiki-Software für data-sort-value ausgestattet.

Beide Techniken sind Basteleien aus dem letzten Jahrhundert und gehören nicht in zeitgenössische Dokumente.

• Im HTML-Dokument wird gruseliges Element-Gewürge erzeugt.

Korrekt wäre es, mit style="padding-right:2em; text-align:right;" in allen Zellen zu arbeiten. Das ist nicht notwendigerweise genau zentriert, aber um eine exakte Zentrierung geht es letztlich auch nicht; es soll eigentlich nur vermieden werden, dass die Zahl ganz am rechten Rand klebt, falls die Spaltenüberschrift deutlich breiter als die Zahlen ist.

Umseitig steht zwar was von „für Fortgeschrittene“, aber die Inhalte der Artikel müssen in den Jahren nach erster Einrichtung mit möglichst geringen Syntaxkenntnissen und auch zukünftig im VE gepflegt werden.

• Zahlenwerte müssen ergänzt, aktualisiert, ganze Zeilen hinzugefügt werden, und das mit dem VisualEditor. Das ist schon im Quelltext schwierig, wie Ló demonstrierte, und im VE überhaupt nicht mehr zu leisten.
• Am Ende sind die Zahlenwerte leider falsch, aber optisch nett dekoriert. Das ist nicht Sinn des Projektes.
• Auch padding-Attribuierungen sind Overkill und unnötig erschwerend.
• In vielen Bereichen des Projektes entscheiden wir uns für einfache Bearbeitbarkeit mit möglichst geringen Vorkenntnissen, geben den Inhalten absoluten Vorrang, und nehmen dafür Einschränkungen in der Super-Optik in Kauf, wenn diese mit unverhältnismäßig hohem Syntaxaufwand erkauft werden muss, der nur noch von Experten beherrscht werden kann.
• Irgendwelche Wahlergebnisse in Prozent und Hubraum in cm³ oder Einwohnerzahlen werden es überleben, wenn die Zahlenwerte bei gleich vielen oder ohne Nachkommastellen rechts am Zellenrand ausgerichtet werden. Ob einzelne Werte sich zu 42, 137, 5.678 entwickeln, ist völlig egal. Sobald hingegen die größte Zahl für dieses Jahr von vier- auf fünfstellig springt, müssten mit Vorlage:0 sämtliche anderen Zeilen entsprechend umgeschrieben werden.
• In Daten-Tabellen kann global für die gesamte Tabelle style="text-align:right" vereinbart werden, und damit wäre in vielen Fällen die Geschichte erledigt. Egal, in welchen Zeilen wie große Zahlen auftreten.
• Wir bauen schon seit langer Zeit übermäßig komplizierte Fummelarbeiten aus den frühen Jahren wieder zurück.

VG --PerfektesChaos 22:32, 4. Apr. 2019 (CEST)

@PerfektesChaos, Vielen Dank für deine ausführlichen Erklärugen! Ich habe in den letzten 30 Jahren sehr viel mit TeX gearbeitet – nicht LaTeX, das die meisten eher kennen, sondern ich habe mir mein eigenes TeX-Format „RiTeX“ geschaffen, das ähnlich wie LaTeX auf PlainTex aufbaut, aber speziell auf meine persönlichen Bedürfnisse zugeschnitten ist. Da bin ich natürlich mit dem Makro „\phantom{…}“ vertraut, das genau in derselben Weise angewandt wird und dieselbe Wirkung erzielt wie hier die Vorlage:0, indem es eine leere Box erzeugt, die dieselbe Breite hat wie der Inhalt des Arguments {…}. Das fügt sich bestens in das Gesamtkonzept von TeX ein und bereitet niemals Schwierigkeiten. Auch hier sehe ich mal wieder, dass bei HTML vieles total anders ist als bei TeX. Ich entnehme deinen Ausführungen im wesentlichen, dass man die Vorlage:0 am besten so weit wie möglich vermeiden sollte.

Dies erklärt allerdings nicht, was mich eingangs zu meiner Frage veranlasste, nämlich warum umseitig nur die Anordnungen der Einträge einer numerischen Tabellenspalte an der linken und der rechten Seite der Spalte empfohlen werden und die zentrische Anordnung, die in den meisten Fällen ästhetisch befriedigender ist, nicht genannt wird. Zahlenspalten in einer Tabelle enthalten in der Regel Zahlen unterschiedlicher Grösse mit gleicher Anzahl von Nachkommastellen, und sie sollen innerhalb der Spalte so gesetzt werden, dass die Einer-, Zehner-, Hunderterstellen u.s.w. exakt untereinander stehen. Um das zu erreichen, braucht man bei der Anordnung der Zahlenkolumne an der linken Seite der Spalte exakt genauso viele „unsichtbare Nullen“ wie bei einer zentrischen Anordnung. Lediglich erfordert die zentrische Anordnung ein klein wenig mehr Rechenarbeit als die Anordnung an der linken Seite, um die Position der Einträge innerhalb der Zelle zu bestimmen. Aber das scheint ja nicht der Grund zu sein, der gegen die zentrische Anordnung sprechen könnte. Andererseits erfordert die zentrische Anordnung den Mehraufwand, dass man jeweils explizit style = "text-align:center" setzen muss. Wenn diese Spezifizierung nicht für alle Spalten gilt, weil die Tabelle auch Spalten mit Texteinträgen enthält, die linksbündig gesetzt werden sollen, dann ist diese Angabe bei jeder einzelnen Zahl notwendig, und dieses Durcheinander von Steuerbefehlen und Daten macht natürlich die Quelldatei extrem unübersichtlich. Jedoch teilt die zentrische Anordnung diesen Nachteil mit der Anordnung an der rechten Seite, wo man in gleicher Weise jedes Mal style = "text-align:right" hinzufügen muss. Also kann auch das kein Grund sein, der gegen die zentrische Anordnung spricht.

Ansonsten hat die Anordnung der Zahlenkolumne an der rechten Seite der Spalte offensichtlich den Vorteil gegenüber den beiden anderen Anordnungen, dass keine unsichtbaren Nullen zur Auffüllung notwendig sind. Dagegen hat sie den Nachteil, dass die Zahlen alle am rechten Rand kleben, was besonders dann ästhetisch unbefriedigend ist, wenn links davon noch massenhaft Platz in der Spalte vorhanden ist. Die von dir genannte Abhilfe, mit style="padding-right:Abstand" einen gleichbleibenden rechten Randabstand zu erzeugen, erfordert noch mehr Style-Anweisungen in der Quelldatei und macht sie entsprechend noch unübersichtlicher. Also, mein Facit ist: Es ist alles ein Krampf, und eine befriedigende Lösung scheint es in HTML nicht zu geben.

Bei TeX ist es so einfach: Man gibt in der Quelldatei zuerst eine Musterzeile an, die die Formatierungen für alle Spalten enthält; da kann man also hineinschreiben, ob die Einträge Zahlen oder Text sind, ob Zahlen nach Stellenpositionen untereinander angeordnet sein sollen, ob die Kolumnen am linken oder rechten Rand oder in der Mitte stehen sollen, ob sie normal oder kursiv oder fett gesetzt werden sollen, ob links und rechts zusätzliche Abstände angebracht werden sollen, und das individuell für jede Spalte; sogar Masseinheiten und Teile der Zahlen, die in allen Einträgen einer Spalte gleich sind, kann man in die Musterzeile schreiben. Kurzum, alles was in den einzelnen Zeilen einer Tabelle gleich ist, kann dort untergebracht werden. So enthalten die folgenden Datenzeilen in der Quelldatei nur noch die reinen Dateneinträge der jeweiligen Tabellenzeile (und natürlich Trennzeichen dazwischen). Nur etwaige Abweichungen von der Formatierung der Musterzeile, die insbesondere in der Kopfzeile vorkommen, die muss man natürlich dann noch explizit angeben.

Der grundsätzliche Fehler bei den HTML-Tabellen scheint mir zu sein, dass die syntaktische Struktur primär auf die Zeilen statt auf die Spalten ausgerichtet ist. Formatierungen, die für die ganze Tabelle gelten, kann man Anfang angeben; Formatierungen, die für alle Einträge einer Zeile gelten, kann man am Anfang der Zeile angeben. Aber typischerweise sind nicht alle Einträge einer Zeile, sondern alle Einträge einer Spalte gleich zu formatieren, und die Formatierungen der einzelnen Spalten können sich voneinander unterscheiden. Dann bleibt nichts anderes übrig, als bei jedem einzelnen Tabelleneintrag die Formatierungsangaben hinzuzufügen. Über solche Primitivität kann ich nur den Kopf schütteln. Aber Spielerei mit unterschiedlichen Farben, Sortierbarkeit für die Zeilen und ähnlicher überflüssiger Firlefanz, das ist alles möglich.

Nun gut, wir können es nicht ändern und müssen uns damit abfinden, wie es nun einmal ist. Ich sehe mich als Anwender jetzt vor der Aufgabe, grundsätzlich die Vor- und Nachteile der einzelnen Möglichkeiten zur Plazierung von Text- und Zahlenkolumnen abzuwägen (ästhetische Schönheit, versteckte Nullen, etwas mehr oder weniger Unübersichtlichkeit der Quelldatei) und mich dann zu entscheiden, welcher Möglichkeit ich generell den Vorzug gebe. Angesichts der ohnehin unvermeidbaren Unübersichtlichkeit dürfte ein bisschen mehr davon sicher kein allzu schwerwiegender Nachteil sein. --BurghardRichter (Diskussion) 22:26, 6. Apr. 2019 (CEST)

• Es gibt keine super-ästhetische mit einfacher VisualEditor-gerechter Weiterbearbeitung zu vereinbarende Lösung in HTML, um echte Zentrierung von Zahlen zu erreichen, die nicht zwingend immer die gleiche Anzahl von Stellen haben.
  • Wenn alles Jahreszahlen sind, und die im Mittelalter anfangen, dann reicht es zentiert bis in die mittlere Sternenzeit.
• Es ist nicht erforderlich, wie ich oben schon einmal schrieb, dass jede Zelle den CSS-Code für rechtsbündige Ausrichtung erhalten muss. Oft genügt es, der gesamten Tabelle dies als Standard-Ausrichtung einmalig mitzugeben. Wenn dann ausschließlich Zahlen vorhanden sind, oder weitaus überwiegend und jeweils nur die erste Spalte linksbündig etwa den textuellen Gegenstand enthalten soll, dann ist der Aufwand an Code minimal.
  • Etwa bei Wahlergebnissen ist das gängige Praxis, in der ersten Spalte linksbündig die Partei, danach rechtsbündig Prozente, Gewinne/Verluste, Mandate, Gewinne/Verluste, Stimmen, Gewinne/Verluste; genauso bei Bevölkerungszahlen oder Produktionsdaten, die womöglich nur Jahreszahlen und Einwohnerzahlen usw. enthalten.
  • 6300 Treffer in aktueller Syntax – etliche Varianten möglich.
• Wenn in einem Dorf die Einwohnerzahl im 19. Jh. immer dreistellig war, im 20. Jh. vierstellig, dann bekämen die paar dreistelligen Zahlen die 0-Vorlage und gut wäre es. Wenn nun letztes Jahr die 10.000 überschritten wurden, dann müssen rückwirkend sämtliche Zahlen nachbearbeitet werden. Und das mach mal mit dem VisualEditor, wenn du überhaupt nicht weißt, wie und was und wo diese Vorlagen versteckt sind und was sie bewirken würden und wo sie wie verändert und neu eingefügt werden müssen.
• An deinem TeX-Dokument bist du der einzige Bearbeiter. Wir müssen für die nächsten Jahrzehnte mit absehbarer Software durch unbekannte Generationen mit möglichst wenig Vorkenntnissen leicht und sicher zu pflegende Artikel hinterlassen.
• Sehr breite Spalten kommen durch breite, lange Überschriften zustande. Wenn das mehr als eine Jahreszahl wird, ist halt Pech.
• Ja, in HTML und allen anderen ML-Sprachen sind die Zellen Kinder der Zeile und die Zeilen sind Kinder des Hauptkörpers und der Hauptkörper ist ein Kind der Tabelle. Spalten kommen in einem ML-Modell nicht vor, es können aber nur von Vorfahren Eigenschaften an die Nachkommen gerader Linie vererbt werden, Spalten sind keine Nachkommen und die Browser-Entwickler weigern sich seit einem Vierteljahrhundert beharrlich, beliebige Eigenschaften spaltenweise zu unterstützen.
• Schlicht zusammengefasst: Die zentrierte Anordnung von Zahlen im Wikitext ist ein absoluter Scheißdreck, führt zu megakomplizierter und nur noch von wenigen Experten zu pflegender Wikisyntax und ist deshalb mit voller Absicht umseitig nicht als empfehlenswerte vorbildliche Lösung aufgeführt. Schon die laienverständliche Erklärung mit und ohne VE bei Anpassungen füllt Bildschirmseiten.

VG --PerfektesChaos 00:08, 7. Apr. 2019 (CEST)

Tab-Einstellung

Hallo,

bin mir nicht ganz sicher, ob ich hier bei den Tabellenexperten an der richtigen Stelle bin. Ich habe auf meinen zwei Benutzerunterseiten Benutzer:Alabasterstein/Artikel und Benutzer:Alabasterstein/Hilfreiches einen Tabreiter eingerichtet. Der gefällt mir soweit auch gut. Ich würde allerdings gerne die Farbe des aktiven (und nur die) gerne auf weiß schalten, da das mit dem dunkelblauen Hintergrund besser kontrastiert. Leider ist mir die Syntax nicht ganz klar, wo ich was an den Einstellungen von Benutzer:Alabasterstein/Tab dafür verändern muss. --Alabasterstein (Diskussion) 11:34, 5. Apr. 2019 (CEST)

Hallo Wiegels: ich wollte die Schrift des aktiven Tabs weiß haben, der Hintergrund des aktiven Tabs soll das dunkelblau behalten. --Alabasterstein (Diskussion) 12:07, 5. Apr. 2019 (CEST)

Genau so. Super. Danke! --Alabasterstein (Diskussion) 12:10, 5. Apr. 2019 (CEST)

Ich hatte schon nachfragen wollen, welche der Farben wirklich gemeint war, aber du warst schneller. Jetzt passt es also, fein! --Wiegels „…“ 12:11, 5. Apr. 2019 (CEST)

Ist eine bedingte Formatierung von Tabellenfeldern in Wikipedia möglich?

Ist eine bedingte Formatierung von Tabellenfeldern in Wikipedia möglich?

z.B.:

- Liegt das angegebenes Datum in der Zelle bei Seitenaufruf in der Vergangenheit? Dann Zellenfarbe = rot

- Liegt das angegebenes Datum in der Zelle bei Seitenaufruf in der Zukunft? Dann Zellenfarbe = grün

etc ?

--2001:16B8:292:4A00:8012:C3AF:B78E:7DBD 23:05, 7. Jun. 2019 (CEST)

Ja, das geht, wenn das Datum jeweils nicht nur in der Zelle steht, sondern gleichzeitig ausgewertet wird, um eine Formatierung, hier die Hintergrundfarbe, festzulegen. Für vielfache Auswertungen könnte das Anlegen einer Vorlage hilfreich sein, um den Quellcode übersichtlich zu halten:

2019-01-01: Vergangenheit

2019-12-31: Zukunft

--Wiegels „…“ 02:19, 8. Jun. 2019 (CEST)

Das ist nicht nur für Tabellenfelder, sondern für beliebige Elemente möglich.

Es darf jedoch ausschließlich über Vorlagen realisiert werden, die eine Bedienungsanleitung und Erklärung mitliefern und die einfache Wiederverwendbarkeit und einheitliche Darstellung ermöglichen.

Direkter Einbau in einen Artikel wäre unzulässig.

Grundsätzlich ist Glaskugelei unerwünscht.

• Die Wikipedia berichtet von Vorgängen, die bereits stattgefunden hatten.
• Konzerte können abgesagt werden, Wahlen können verschoben werden (also hinsichtlich des Termins).
• Deshalb könnten allenfalls als sicher stattfindend anzunehmende Ereignisse in der nahen Zukunft mit derartigem Design ausgestattet werden. Dass der vorausgesagte Kalendertag nunmehr verstrichen ist, heißt ja nicht, dass es auch tatsächlich passierte; es könnte auch ausgefallen sein.
  • Dass der 30. Jahrestag des Mauerfalls dieses Jahr anstehen würde, hatten wir schon einige Zeit vor Seehofers Heimatmuseum gewusst. Das wäre ein Fall für ein mit Sicherheit vorherzusagendes Ereignis.

Diese Abfragen belasten das System. Eine solche dynamische Abfrage darf nicht beginnend mit dem Mittelalter Jahreszahlen vergleichen und auf ewig im Artikel verbleiben, sondern muss bei Überarbeitung des Artikels für die jetzt vergangenen Zeitpunkte eine feste Zuweisung vornehmen.

• Nur für die unmittelbare Zukunft (einige Monate) dürfte eine dynamische Abfrage die tagesaktuelle Darstellung sichern.
• Angemeldete Benutzer sehen es übrigens immer tagesaktuell; nicht angemeldete Benutzer (IP) mit mehreren Tagen Verspätung; aus Performance-Gründen.

VG --PerfektesChaos 09:10, 8. Jun. 2019 (CEST)

Vielen Dank!

Es ging mir um vorab bindend festgelegte Supportzeiträume (noch im Support oder Support abgelaufen), die Glaskugelei ist daher kein Problem, aber danke für den Hinweis.

Ich bin noch nicht wirklich Fit in Sachen Vorlagen, hat jemand ggf. einen Beispiel in Wikipedia wo eine Vorlage für diese datumsbasierte bedingte Formatierung genutzt wird?

--2001:16B8:213:3B00:1573:146E:56C8:F1CF 14:12, 8. Jun. 2019 (CEST)

Olympische Sommerspiele 1896/Tennis#Einzel

Hallo, wie schaffe ich es, dass unter der #Einzel kein Abstand zwischen Text und Tabelle ist?--Siebenschläferchen (Diskussion) 20:22, 13. Jun. 2019 (CEST)

Ich schaue morgen mal, aber das hat etwas mit der Infobox oben und der Tabelle (Medaillenspiegel) zu tun. --Liebe Grüße, Lómelinde Diskussion 20:42, 13. Jun. 2019 (CEST)

Hallo Siebenschläferchen, du meinst den vertikalen Abstand zwischen Fließtext und Tabelle des Abschnitts „Einzel“ bei großen Fensterbreiten (> 2000 Pixel bei Normaldarstellung im Standard-Skin)? Der kam daher, dass der Medaillenspiegel sich inhaltlich vor dem gesamten Einzel-Abschnitt befindet und sich rechts unterhalb der Infobox angeordnet, wodurch nachfolgende, links angeordnete Elemente nicht höher stehen können. Hiermit werden die Infobox und der Medaillenspiegel als Ganzes betrachtet und anfangs rechts angeordnet, mit dem kleinen Nachteil, dass das streifenförmige Rechteck links von der Infobox und oberhalb des Medaillenspiegels ungenutzt (leer) bleibt. --Wiegels „…“ 22:09, 13. Jun. 2019 (CEST)

Danke für die sehr detailierte und gute Antwort!--Siebenschläferchen (Diskussion) 22:11, 13. Jun. 2019 (CEST)

Leerzellen

Leerzellen ohne Inhalt werden beim Sortieren an den Anfang gestellt, solche mit   (Geschütztes Leerzeichen) an das Ende. Anscheinend wird beides beim Sortieren von Zahlen wie eine 0 sortiert und beides beim aufsteigenden Sortieren von Text an den Anfang also nach oben sortiert und beim absteigenden Sortieren ans Ende also nach unten sortiert. --Diwas (Diskussion) 10:30, 6. Jun. 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Lómelinde 17:07, 1. Mai 2020 (CEST)

Zeilennummerierung

Falls ich einen Zähler einbauen will und dieser zentriert werden soll müsste das auch als ! (table header) klappen. das wäre einfacher als die Definition über style.

Zähler	Inhalt
1	Wien
2	München
3	Brüssel
4	Rom

Archivierung dieses Abschnittes wurde gewünscht von: --Lómelinde 17:07, 1. Mai 2020 (CEST)

Probleme mit der Zeilenhöhe

Hallo Tabellenprofis, ich möchte in einer Tabelle (Kartenlegende) außer den Farbindex-Flächen auch farbige Symbole darstellen. Da ich diese Symbole mit dem big-Tag größer anzeigen lassen möchte, vergrößert sich leider auch die Zeilenhöhe. Wie lässt sich das lösen? Hier ein Beispiel:

Natürliche Vegetation	Vorwiegend subsistenzorientierte Landnutzung	Vorwiegend marktorientierte Landnutzung
 Inlandeis	⚫⚫⚫ Sammeln* / Fischen* / Jagen*
	▲ 10–20% der Anbauflächen	 Ballungsräume
	▲ 20–30% der Anbauflächen	♦ Rohstoffförderung

--Fährtenleser (Diskussion) 19:19, 4. Apr. 2020 (CEST)

Hallo Fährtenleser, probiere mal, ob dir der Code <span style="font-size:1.75em; line-height:0.5em;"><span style="color:#cfa75e;">⚫</span><span style="color:#3dab9c;">⚫</span><span style="color:#87c02e;">⚫</span></span> weiterhilft. An der Schriftgröße und Zeilenhöhe kannst du noch „drehen“.

Ich hätte noch eine inhaltliche Anregung für dich: Falls die Einträge innerhalb der Zeilen nichts miteinander zu tun haben, wäre eine Darstellung der Legende in Form von mehreren (horizontalen oder vertikalen) Listen sinnvoller als in Tabellenform. --Wiegels „…“ 02:15, 5. Apr. 2020 (CEST)

Und ich möchte darauf hinweisen dass das Tag →<big>…</big> nicht verwendet werden soll. Also bitte „nicht verwenden“ siehe auch Hilfe:Textgestaltung#nicht. Wozu sollen diese Punkte denn so riesenhaft sein, das empfinde ich optisch als absolut aufdringlich und störend. Kreise kann man übrigens auch leicht und in jeder Farbe oder Größe mit der Vorlage:Farbe erzeugen. _ _ die kann auch  → _ verkleinern. --Liebe Grüße, Lómelinde Diskussion 08:37, 5. Apr. 2020 (CEST)

Euch beiden herzlichen Dank! Damit kann ich sicherlich etwas anfangen. Gruß --Fährtenleser (Diskussion) 09:49, 5. Apr. 2020 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Lómelinde 17:07, 1. Mai 2020 (CEST)

Hilfe bei nochmaligem Trennen von Zellen gesucht

Hallo.

ich übearbeite gerade eine Tabelle und stehe vor einem Problem. Bei der nachstehenden Tabelle stehen zwei Personen in einer Zelle, zwei Teams in einer Zelle, usw. Ich habe hin und her probiert aber ich komm nicht drauf. Gibt es eine Möglichkeit mit rowspan="2" oder ähnlichem die Zellen abermals zu teilen, sodass Cuellar und McLain, sowie deren Statistiken in einer einzelnen Zelle stehen? --Fossiy (Diskussion) 20:53, 20. Mär. 2020 (CET)

Jahr	Liga	Name		Team	W	L	Saves	ERA
1969	American	Mike Cuellar	Vereinigte Staaten	Baltimore Orioles	23	11	0	2.38
		Denny McLain	Vereinigte Staaten	Detroit Tigers	24	9	0	2.80
	National	Tom Seaver	Vereinigte Staaten	New York Mets	25	7	0	2.21

Hallo Fossiy, hast du dir das so vorgestellt? --Wiegels „…“ 21:15, 20. Mär. 2020 (CET)

Ja, perfekt! Vielen Dank! :) --Fossiy (Diskussion) 21:34, 20. Mär. 2020 (CET)

Die vertikale Zentrierung kann man weglassen, weil sie voreingestellt ist, und die Summe der Spaltenbreiten sollte 100 % ergeben. --Wiegels „…“ 22:20, 20. Mär. 2020 (CET)

#Sortierbare Tabellen ausgliedern

Mir ist das Thema „Sortierbare Tabellen“ noch nicht vollständig genug behandelt, andererseits schon heute den Umfang der Seite sprengend.

• Ich beabsichtige deshalb die Ausgliederung der umseitigen Darstellung mit IU auf: Hilfe:Tabellen/Sortierbar
• Damit soll das ohnehin komplexe Thema übersichtlicher gestaltet werden.
• Weiterhin missfällt mir die Dopplung mit Hilfe:Tabellen #Sortierbare Tabelle – eine umfangreiche Doppeldarstellung desselben Themas ist immer Mist.
  • Dort würde ich den Abschnitt komplett eliminieren und auf die neue Seite verweisen wollen.
  • Man hatte dort nicht auf „Fortgeschrittene“ verlinken wollen und deshalb die Hälfte dann doch noch mal reingeschrieben.
  • Damit wird Hilfe:Tabellen dann auch erstmal übersichtlicher und nicht so abschreckend.

Meinungen? --PerfektesChaos 17:10, 26. Mär. 2020 (CET)

Klingt vernünftig, dass man zusammenfügt was thematisch zusammen gehört. --Liebe Grüße, Lómelinde Diskussion 18:53, 26. Mär. 2020 (CET)

Hallo, ich wäre auch einverstanden, würde aber als Zielseite einfach „Hilfe:Sortierbare Tabellen“ statt „Hilfe:Tabellen/Sortierbar“ wählen. Der Hilfe-Namensraum hat keine Unterseiten und Pseudo-Unterseiten scheinen mir hier nicht gebräuchlich zu sein. --Wiegels „…“ 21:29, 26. Mär. 2020 (CET)

„Pseudo-Unterseiten scheinen mir hier nicht gebräuchlich zu sein“

• ????
• Ohne Weiterleitungen gibt es 182 Oberseiten sowie 347 Seiten insgesamt – also statistisch fast genau so viele Unterseiten wie Oberseiten.

Bei einer Suche soll zu h:tab eine vertiefende Auswahl geliefert werden; zurzeit gibt es als Angebote auch:

• Hilfe:Tabellen/prettytable
• Hilfe:Tabellen/VisualEditor

Der Begriff Hilfe:Sortierung ist aber bereits von einer BKS versorgt; h:sor liefert bereits einen Weg und h:sortable dann direkt.

VG --PerfektesChaos 22:00, 26. Mär. 2020 (CET)

Ach ja; die Unterseiten-Funktion ist hier wie fast überall MW-seitig aktiv.

Nur ANR, Datei und MediaWiki-NR haben diese nicht; bei diesen sprechen jeweils objektive Gründe dagegen.

VG --PerfektesChaos 22:05, 26. Mär. 2020 (CET)

Da hast du wohl Recht. Ich bin in diesem Namensraum selten unterwegs und hatte mich von meinem Eindruck auf Hilfe:Tabellen mit künstlich angelegtem Pfad und den Schrägstrich-losen Namen in der Hilfe-Seitenleiste täuschen lassen, bestätigt von einem kurzen Blick auf Hilfe:Namensräume#Unterseiten. Dann habe ich keine Einwände gegen deinen Plan. :-) --Wiegels „…“ 22:41, 26. Mär. 2020 (CET)

@Lómelinde, Wiegels: Ich habe dann mal Hilfe:Tabellen/Sortierung komplett neu geschaffen.

• Bitte mal durchgucken, ob ich alles richtig gemacht habe oder am Ende was fehlt.
• Danach umseitig per Vorlage:Hauptseite den Inhalt des Abschnitts radikal eliminieren, damit es nicht zu Inkonsistenzen kommt und doppelter Pflegebedarf entsteht.
• In der Basisversion Hilfe:Tabellen mögen durchaus ein oder zwei einfache Beispiele zum ersten Schnuppern verbleiben, aber mir ist das zu viel und das sollte eher eingekürzt werden. Auch hier sollte nichts kurz schlecht erklärt werden, was auf der Unterseite präzise und komplett steht.

LG --PerfektesChaos 23:21, 25. Apr. 2020 (CEST)

Ich weiß noch immer nicht, wie ich da weiterkommen soll. Da stehen Dinge, die ich nicht kenne von denen ich manchmal nicht einmal weiß, ob es sie irgendwo geben könnte. Wie class="sorttop" oder irgendwelche Kinder von Kopfzeilen. Die Seite überfordert mich ein wenig, wenn ich alles immer auch noch austesten muss. Ausgerechnet Sortierung, wo ich damit eigentlich wirklich wenig im Sinn habe, mich nerven Tabellen, die aus ein bis drei oder fünf Zeilen bestehen und trotzdem zwingend sortierbar sein müssen. Also ich lese das irgendwann bis zum Ende durch. Ob etwas vergessen wurde, kann ich nicht beurteilen, ich würde immer ein nachvollziehbares Beispiel zum Testen einsetzen, da man das einfach besser versteht als wenn da nur ein Codeschnipsel steht, aber das ist dir wieder zu viel. Irgendwie stecke ich fest. Das ist nicht so mein Thema. --Liebe Grüße, Lómelinde Diskussion 13:32, 27. Apr. 2020 (CEST)

Ich könnte mir als nächste Maßnahme eine Seite Hilfe:Tabellen/Beispiele vorstellen, wo dann auf viel viel Platz für alle Tabellen-Hilfeseiten jeweils Quelltext, ggf. VE-Details und Resultat mobiltauglich in passend benannten Abschnitten vorkommen.

Dadurch würden die eigentlichen Erklärungsseiten entlastet, und sie würden übersichtlicher. Es sollte dort immer nur ein Code-Schnipsel oder ein minimales Beispiel vorkommen; ansonsten quellen die Erklärungsseiten über, werden abschreckend und die inhaltlichen Erklärungen ersaufen in den Beispielen. Und gerade Tabellen brauchen seeeehr viel Platz für Quelltext plus Resultat. Wir haben für umfangreiche Vorlagen-Beispiele auch separate Testseiten zur Vorlagendoku, damit auch die nicht kilometerlang werden.

Die Klassen und Features habe ich der Programmierung, teils der Doku auf meta: entnommen. Es gibt aber vermutlich einen Programmierfehler oder eine nicht allgemein unterstützte Syntaxvariante, was dazu führt, dass einige Verwendungen der Klassen zurzeit nicht flutschen. Ich habe aber im Moment viel zu viel am Hals, mache zwischendurch noch die Migration der Labs/Tools auf die Cloud, baue die neuen Sortiervorlagen aus, und da muss das bis in den Mai warten.

LG --PerfektesChaos 14:43, 27. Apr. 2020 (CEST)

Bis Mai, na so viel Zeit habe ich allemal. Ich frage jetzt auch nicht was es mit dieser Cloud auf sich hat. Ich sehe dass du beschäftigt bist, aber du hattest mich hierher gerufen. --Liebe Grüße, Lómelinde Diskussion 14:51, 27. Apr. 2020 (CEST)

OK ich habe mir jetzt noch mal Gedanken zu diesem sorttop gemacht und eigentlich finde ich es sogar sinnvoll, dass es diese Klasse nicht gibt. Wenn man nämlich so eine gewisse Anzahl von Zellen erst einmal nach oben setzt, dann wird man schlimmstenfalls gezwungen bis zu den eigentlich gewünschten Zeilen hinunterzuscrollen, um sich das Ergebnis der Sortierung anzusehen. Dann muss man den selben Weg zurück, um wieder an die Pfeile zu gelangen. Das ist also maximal kontraproduktiv und das wird vermutlich auch der Grund dafür sein, dass diese Klasse nicht aktiviert wurde. Sortbottom hingegen schiebt die Zeilen, die ich von der Sortierung ausnehme zwar möglicherweise aus dem Bildschirmfenster, aber das ist ja ein erwünschter Effekt, denn ich möchte ja möglichst viele von den sortierten Ergebnissen innerhalb des Fensters sehen. Ähnliches gilt für die Kinderchen, auch die sollten natürlich mit ihren Müttern nach unten gesetzt werden. Was für mich auf eine Empfehlung herauslaufen würde diese Klasse immer gemeinsam mit sortbottom einzusetzen. Es braucht halt Zeit, bis ich so etwas verstehe. --Liebe Grüße, Lómelinde Diskussion 06:24, 28. Apr. 2020 (CEST)

Wie weiter? Ich würde wirklich ungern den Abschnitt hier vorne komplett entfernen und damit die Beispiele verlieren. Hilfe:Tabellen/Beispiele hmm da würde man alle Beispiele vermuten, oder doch besser Hilfe:Tabellen/Sortierung/Beispiele. Öhm ja VE- und mobiltauglich, habe ich schon mal erwähnt, dass ich nicht mobil bin und den VE nicht verwende es sei denn, ich soll etwas testen. Machen wir im Mai. --Liebe Grüße, Lómelinde Diskussion 19:04, 28. Apr. 2020 (CEST)

Ich meinte schon eine zentrale Hilfe:Tabellen/Beispiele für alles, sowohl umseitig wie auch die Basisversion.

• Überschriften H2 für „Grundlagen“, „Verbundzellen“, „Dekoration“, „Sortierung“ usw.
• Eine H3 für jedes Beispiel, kurzer Satz was das Beispiel illustrieren soll, welche Syntaxkonstrukte entscheidend sind für die Wirkung, Quelltext und Live. Untereinander statt nebeneinander wegen mobil, oder dynamisch floatend.
• Ein narrensicherer Anker pro Beispiel-Überschrift, und Backlink auf den zugehörigen Abschnitt der Erklär-Seite.
• Dann können die drei erklärenden Seiten übersichtlicher gestaltet werden, statt voller Beispiele nur Code-Schnipsel oder aber bei unwichtigeren Möglichkeiten nur eine Verlinkung auf den Beispiel-Abschnitt erhalten.
• Künftige Generationen werden nicht mehr ganz so viel mit Quelltext und stärker mit VE arbeiten, und der wird ja wohl auch zukünftig noch mehr zu Zeilen und Zellen lernen. Dann müssen aber die drei oder irgendwann noch mehr erklärenden Seiten überschaubar und verständlich sein.

LG --PerfektesChaos 21:51, 28. Apr. 2020 (CEST)

Dann hatte ich es wohl richtig interpretiert, ich wollte nur sichergehen. --Liebe Grüße, Lómelinde Diskussion 06:33, 29. Apr. 2020 (CEST)

Ich habe noch ein kleines Problem. Es gibt etliche > 800 Artikel die ein Attribut scope verwenden. Also es gäbe wohl

• scope="col" = Specifies that the cell is a header for a column
• scope="row" = Specifies that the cell is a header for a row
• scope="colgroup" = Specifies that the cell is a header for a group of columns
• scope="rowgroup" = Specifies that the cell is a header for a group of rows
• Ist dieses aktiv?
• Wenn ja, was genau tut es, sehe ich die Wirkung? Sollte man so etwas dann auch beschreiben, empfehlen?
• Wo finde ich die Seite die das Dingen und die Wirkung auf was genau beschreibt?
• Wenn nein, sollte ein Bot es eliminieren, damit es nicht verbreitet wird?

Einerseits fand ich es nicht in dieser Tabelle aber ich finde auch keine Erläuterungen zu scope="…" es wird auch dort nur im Quelltext verwendet. Oder ich suche falsch. --Liebe Grüße, Lómelinde Diskussion 07:30, 2. Mai 2020 (CEST)

Stöhn. Es war zu befürchten, dass du irgendwann damit ankommst.

• Die Antwort hängt mit etwas zusammen, zu dem weiter unten auf dieser Seite gnadenlos dummes Zeug steht, und sie weist auch nach, warum das dort völlig inkompetentes Gesabbel ist.
• Die scope="row" sagen einem TH im Tabellenrumpf, dass es die Überschrift zur (rechts folgend zu erwartenden) restlichen Zeile ist. Damit könnte etwa dummen Screenreadern ermöglicht werden, das als den Zeilentitel zu erkennen. Screenreader können dann zu jeder beliebigen Zelle irgendwo auf Anfrage mitteilen, welches die Spalten- und welches die Zeilenüberschrift ist; also ich bin in der Zelle mit dem Inhalt „12.345“ und der Screenreader sagt mir, das wäre die Zelle von Zeile „Dingenskirchen“ in der Spalte „1876“ und damit weiß ich die Einwohnerzahl dieses Ortes in diesem Jahr. Könnten neben Screenreadern auch sonstige Tools auswerten, die es durchaus in JavaScript gibt und die auf Wunsch per rechter Maustaste bei jeder Zelle als Tooltip diese beiden Infos anzeigen.
• Allerdings sind sehr selten Tabellen so ausgestattet, und Screenreader können es deshalb auch so erraten; folgt in einer Zeile auf ein TH eine Ansammlung von TD, dann ist dieses TH die „Überschrift“ zu dieser Zeile.
• Die scope="col" sagen einem TH im Tabellenkopf, dieses TH wäre eine Überschrift für die Spalte darunter. Weil auch das nur selten mit beisteht, denken sich Screenreader das selbst, und wenn die erste Zeile einer Tabelle nur TH enthält, dann werden das ja wohl die Überschriften für die Spalten darunter sein.
• Obwohl es nicht so dringend benötigt würde und schlimmstenfalls von der Wiki-Software nach den beiden von mir angegebenen einfachen Regeln für alle in Frage kommenden TH leicht rekonstruiert werden könnte, wird es in der enWP gern extra dazugeschrieben, weshalb du es wohl nur nach C&P aus der enWP antreffen wirst.
• Raten nennt sich offiziell: apply to a set of cells selected based on context

Ich seh mich schon wieder das ganze Wochenende nur auf Diskussionsseiten statt irgendwas produktiv voranzubringen und etwas mal fertigzubekommen und abzuschließen.

LG --PerfektesChaos 15:06, 2. Mai 2020 (CEST)

. Gut ich ignoriere es mal. --Liebe Grüße, Lómelinde Diskussion 15:37, 2. Mai 2020 (CEST)

Scrollbare Tabellen

Viele als Tabelle veröffentlichten Listen kommen auf erhebliche Längen. Das bläht den Artikel optisch auf. Zudem verschwinden beim Scrollen der Seite die Kopf-/Fußzeilen; nicht immer lässt sich der Zellen-/Spalteninhalt dann noch ohne Zurückblättern zuordnen. Schon bei harmlosen Tabellen wie HIER, weiß ich in der 10. Zeile nicht mehr, was die Zahlen bedeuten. Daher halte ich es für sehr hilfreich, wenn solche Listen/Tabellen auf eine sinnvolle Anzahl Zeilen reduziert werden können. Bei Sichtbarkeit der Kopf- ggf. Fußzeile könnte der Inhalt vertikal gescrollt werden.

In HTML ist so etwas recht simpel realisierbar, siehe Beispiel (Funktionsmuster ohne Layout):

<table rules=all border=2 cellpadding=2>
<caption>Überschrift</caption>
<thead style="display:block;">
<tr><th>Kopf 1</th><th>Kopf 2</th></tr>
</thead>
<tbody style="overflow:auto;height:150px;display:block;"
<tr><td>Inhalt1</td><td>Inhalt1a</td></tr>
<tr><td>Inhalt2</td><td>Inhalt2a</td></tr>
<tr><td>Inhalt3</td><td>Inhalt3x</td></tr>
<tr><td>Inhalt4</td><td>Inhalt4a</td></tr>
<tr><td>Inhalt5</td><td>Inhalt5a</td></tr>
<tr><td>Inhalt6</td><td>Inhalt6a</td></tr>
<tr><td>Inhalt7</td><td>Inhalt7a</td></tr>
<tr><td>Inhalt8</td><td>Inhalt8a</td></tr>
<tr><td>Inhalt9</td><td>Inhalt9a</td></tr>
</tbody>
<tfoot style="display:block;">
<tr><th>Fuß A</th><th>Fuß B</th></tr>
</tfoot>
</table>

Hier kann es leider nicht ausgeführt werden, da WP die Tags<thead>,<tbody>,<tfood>nicht akzeptiert.

Meine Frage(n):

1. Gibt es in der Tabellenfunktion irgendwelche Parameter, die so etwas anbieten?
2. Eher unwahrscheinlich, da WP nur <tbody> erzeugt und <thead>,<tfood> unterschlägt, aber könnte man irgendwo die passenden style in der WP-Tabelle unterbringen?
   • Es gibt ja z.B. en:Template:Scroll box, ein Ansatz in dieser Richtung für einfache Listen.

--Klaus-Peter (ex und hopp) 10:36, 21. Apr. 2020 (CEST)

In WP:Beitragszahlen gibt es eine extrem lange Tabelle mit schätzungsweise einigen Tausend Zeilen. Dort ist das Problem dadurch gelöst worden, dass in gewissen Abständen Wiederholungen der Kopfzeile eingefügt worden sind. --BurghardRichter (Diskussion) 11:31, 21. Apr. 2020 (CEST)

Letzters geht auch ohne Vorlage aus der en:WP siehe →Beispiel

Du meinst so ähnlich

Tabellenüberschrift

A B C D 1. Beispiel Beispiel Beispiel Text 2. Beispiel A 100 Nummer 3. Beispiel B 300 Wort 4. Beispiel C 110 Beispiel 5. Beispiel D 400 Blabla 6. Beispiel A 120 irgendetwas 7. Beispiel B 320 Murks 8. Beispiel C 125 Test 9. Beispiel D Beispiel Was solls
Fußzeile	Fußzeile	Fußzeile	Fußzeile

Ich denke nicht, dass das für Artikel geeignet wäre. Wie sich so etwas (das ist ja eher eine Krücke, die ich hier gebastelt habe) auf Mobilgeräte oder unterschiedliche Browser auswirkt, sollte man auch immer bedenken und beachten. Nicht alles, was einem selbst als supertoll erscheinen mag, ist auch praktikabel. Je mehr komplizierte Syntax man in den Quelltext verbaut desto fehleranfälliger wird es, meiner Meinung nach. Aber vielleicht kannst du trotzdem etwas damit anfangen. --Liebe Grüße, Lómelinde Diskussion 11:38, 21. Apr. 2020 (CEST)

Erst mal herzlichen Dank. Klar, das ist Schritt 1 und sieht brauchbar aus. In der Richtung hatte ich auch schon experimentiert, aber die divs anders gesetzt. Deine Variante ist eleganter! Nun gibt es einen Haken: Bei WP ist sortable extrem beliebt und üppig verwendet. Ich habe es mal provisorisch und mit Erfolg in deine obige Lösung reingebastelt.

Supertoll? Ich stoße immer wieder auf ellenlange Listen, die über viele Seiten gehen und damit kaum noch visuell erfassbar sind. Mobil ist das noch weniger brauchbar. 'overflow' ist aber ein alter Hut seit 'Urzeiten' verfügbar. Mit der Buschtrommel muss es nicht laufen. Mit dem zunehmend eingesetzten mw-collapsible gibt es deutlich mehr Probleme, sogar bei moderneren Browsern. Also ich würde eher dazu neigen, die Scrollfunktion fest in die Tabelenvorlage (resp. css) einzubauen. MfG--Klaus-Peter (ex und hopp) 13:32, 21. Apr. 2020 (CEST)

PS, habe gerade mal den Mobiltest gemacht (Android), Da werden Vorgaben wie overflow und sortable schlicht ignoriert. Da müsste man sich mal die passenden css ansehen. Ist aber kaum meine Zielgruppe --Klaus-Peter (ex und hopp) 13:40, 21. Apr. 2020 (CEST)

Wenn du das vernünftig hinbekommen kannst, ich habe ein Problem damit, dass in meiner Konstruktion leider Tabellen ineinander geschachtelt werden müssen und so die Breite der äußeren Kopfzeilen von denen mit den Zelleninhalten darunter, je nach Breite der Tabellen, abweichen kann und es so zu Verschiebungen kommt. mw-collapsible sollte eigentlich auch vermieden werden. Für ausufernde Legenden mag das noch ok sein, aber wesentliche Inhalte sollte man nicht verbergen, weil das auch manchmal die Sprungadressen der Belegtags verschluckt. Viel Erfolg beim Testen. --Liebe Grüße, Lómelinde Diskussion 13:48, 21. Apr. 2020 (CEST)

@Lómelinde

Ich werde mal in der Richtung weiter experimentieren, auch mit Sprungadressen. Hast du mal ein Muster der verschachtelten Tabellen? Vielleicht fällt mir etwas Sinnvolles ein. mw-collapsible könnte ich mir für normalen Text gut vorstellen, um Monsterbeiträge wie „Donald Trump der Twitter“ etwas zu schrumpfen. Wer die „Spezialitäten“ lesen will, könnte ausklappen.

Freundliche Grüße --Klaus-Peter (ex und hopp) 16:36, 21. Apr. 2020 (CEST)

Das Beispiel oben ist eine verschachtelte Tabelle, da ist ein colspan sogar über 5 Spalten, eine mehr als es erforderlich wäre, nur damit die Scrolleiste nicht die Spaltenbreite zu sehr reduziert. Ich habe da schon eine Weile herumprobiert, bis es zu einem „für mich“ passablen Ergebnis gereicht hat. Und in der Zeile wird dann der eigentlich scrollbare Inhalt formatiert = Tabelle in Tabelle = Schachtel, was dann vermutlich auch visuell eher umständlich zu bearbeiten ist. Es sieht zumindest in der visuellen Bearbeitung nicht sonderlich vorteilhaft aus. Gerade bei solchen Dingen wird es schwierig alle Benutzer mitzunehmen, so dass wirklich alle damit vernünftig arbeiten können. --Liebe Grüße, Lómelinde Diskussion 16:55, 21. Apr. 2020 (CEST)

Da bin ich doch bei der Änderung deiner Tabelle mit Blindheit auf mich selbst reingefallen. Habe schlicht übersehen, dass bei ‚sortable‘ die erste Zeile auch weggescrollt wird. Somit ist diese Variante unbrauchbar.

Bei der Analyse des erzeugten HTML-Codes stellte ich fest, dass die ‚overflow‘-Anweisungen nicht als Parameter bei den Tags <thead> bzw. <tbody> landen, sondern erst beim folgenden <tr>. Damit kann man keinen Blumentopf gewinnen.

Sofern man das schon bei ‚Komplette Textübergabe‘ angesprochene Problem lösen könnte, wäre eine perfekte Bearbeitung mit ein paar Zeilen LUA absolut keine Hürde ... aber ... (das Thema ignorieren die, die es wissen müssten) --Klaus-Peter (ex und hopp) 08:24, 22. Apr. 2020 (CEST)

Ich sagte ja geht nur mit Schachtel und Schachtel ist ungeeignet. Wenn dann müsstest du vermutlich mal in der Technikwerkstatt, beim Projekt Technische Wünsche oder bei den Verbesserungsvorschlägen fragen, ob es da Möglichkeiten gäbe. Ich könnte mir zumindest vorstellen dass man Klassen einrichten könnte so ähnlich wie class="Sortbottom" eben dann nur als class="Scrolltop" die das wegscrollen verhindern. Ein Problem dabei bleibt aber der Scrollbalken, der nach außerhalb, also quasi neben der letzten Spalte, gesetzt werden müsste. Und wenn du mit Zitat: „das Thema ignorieren die, die es wissen müssten“ auf PC anspielen solltest, er hat das hier sicherlich gelesen, mich dafür im Geiste „verflucht“, dass ich dir geantwortet habe, und wird sicher keine Tipps für so etwas geben, weil das, so vermute ich mal, keine sinnvolle Anwendung für Artikel wäre. Es muss sich mit allen Endgeräten, Bearbeitungsprogrammen und der Weiternutzung (PDF, Kopie …) vertragen. Mein Beispiel ist nur Spielerei und die ist wirklich absolut untauglich. --Liebe Grüße, Lómelinde Diskussion 10:33, 22. Apr. 2020 (CEST)

Also scrollbare Listen und Tabellen sind ja weder Hexenwerk noch eine fixe Idee von mir. Sogar WP verwendet es (siehe links Sprachen/Sprachenauswahl) Auf unendlich vielen Seiten wird es WWWweit eingesetzt, um nicht -- wie hier leider üblich -- ellenlange Listen darzustellen. Meist nimmt man es nicht wahr, weil es Standard ist. In den HTML-Urzeiten haben wir so was via JS realisiert.

1. Bei meinem Muster ist nichts verschachtelt. «overflow» pickt sich ja nur <tbody> heraus und lässt <thead> und <tfood> da, wo es ist.
2. Der Scrollbalken wird innerhalb platziert und müsste bei der letzten (rechten) Spalte ggf. berücksichtigt werden. Bei "auto" verbreitert sich die letzte Spalte, wenn der Rahmen nicht mit Datenzeilen überfüllt werden. Die Tabellenbreite bleibt konstant.
3. Was ist sinnvoll? Ich lebe nicht nur in und mit Wikipedia, da ist mein Spektrum deutlich breiter. Was da allgemein geboten ist, ist mein Maßstab, was an sinnvollen Neuerungen kommt, weckt meinen Ehrgeiz. So etwas kann man aber bei WP nie realisieren. Das gibt bestenfalls endlose Debatten ohne Erfolgsaussicht. Bei en-WP läuft so etwas konstruktiver und erfrischender ab.
4. Die Darstellung auf anderen Geräten, iPhone, Android, Druckern (incl. Ausdruck in Datei, PDF) wird jetzt schon via css recht ordentlich geregelt. Da gibt es schon deutlich eingeschränkte Funktionen und Darstellungen, aber Listen werden typischerweise komplett ausgedruckt. Also Kompatibilität kann kein Thema sein.
5. Ich kenne leider weder das Vorlagenprogramm für die Tabellen und die dazugehörigen css, kann mir aber gut vorstellen, das die Änderung ein Klacks ist. Eine Klasse scroll mit Parameter Tabellenhöhe (px, em, Zeilen ...) und der Rest wird via css erledigt

Ma sehen, was daraus wird. Ich denke mal, mit den enWikipedianern ist das schneller realisiert. Hübschen Nachmittag --Klaus-Peter (ex und hopp) 12:55, 22. Apr. 2020 (CEST)

Deine nachträglich erweiterte Spielerei geht schon ein Schritt weiter in die richtige Richtung. Dennoch ist es kaum praktikabel, weil es kein „outsider“ blickt. Ich habe gerade eine Lösung entwickelt, die sich auf den Zusatz scroll und optional eine Höhen- ggf. auch Breitenangabe beschränkt, also z.B.

class="wikitable zebra sortable scroll" style="width:50%; height:200px;"

Realisiert wird das ausschließlich mit 4 - 5 Zeilen css. Mein Muster im BNR funktioniert fast perfekt (Scroll 100 %, Spaltenausrichtung 75 %). Muss es noch auf Kompatibilität mit anderen Tabellenschmankerl prüfen. Vermutlich klappt es SOGAR mit horizontalem Scrollen und evtl. sogar mit Ankern/Sprungadressen in der Liste. Vielen Dank fürs Mitdenken --Klaus-Peter (ex und hopp) 16:07, 23. Apr. 2020 (CEST)

Jetzt muss ich leider einige Meter zurückrudern. Bei den Tests zeigen sich die ‚Vorteile‘ von WP-Code: erstens kommt es anders und zweitens als man denkt. Während ich mit bravem HTML (alte Versionen, XHTML, HTML5) keinerlei Probleme habe, scheint WP einige andere Vorstellungen vom Einsatz von CSS zu haben. Da wird mir schon klar, das so ein Schmankerl wie mw-collapsible drin ist, aber nicht overflow. Der Kollaps lässt einfach alles verschwinden - und fertig ist es. overflow kann nicht mit der bei WP vorgegebenen/eingestellten Spaltenbreiten umgehen, macht Murks bei col-/rowspan, unterschlägt einige css-Anweisungen und ergänzt mit sehr vielen, die vermutlich gegeneinander arbeiten. Zudem wird jQuery (fürs Sortieren) auch noch zu berücksichtigen sein. Bei sehr einfach strukturierten Tabellen klappt es einwandfrei, aber wenn es interessant wird, knirscht es an allen Ecken und Enden. Das zu analysieren und entsprechend anzupassen kann ohne interessierte Mitstreiter nicht funktionieren, jedenfalls nicht bei de-WP. Also werde ich das Thema hier begraben und bei/mit en-WP weiter verfolgen. --Klaus-Peter (ex und hopp) 08:18, 25. Apr. 2020 (CEST)

Na dann, wie gesagt, ich bin keine Programmiererin und habe von all diesen Fachausdrücken keinen Schimmer. Ich spiele nur gern mal mit der Syntax hier. --Liebe Grüße, Lómelinde Diskussion 10:09, 25. Apr. 2020 (CEST)

@Lómelinde Das ist der feine Unterschied: Ich verdiente mit Programmierung meine Brötchen bis zum Ruhestand. Habe noch nicht vergessen, wie es geht. DU kennst dich besser mit WP-Syntax aus, das ist nicht mein bevorzugtes Territorium. Aber wenn man sich gegenseitig ergänzt, kann was Sinnvolles bei herauskommen. Gerade bin ich bei der Plauderei (Fachsimpelei) mit en-WP-Fellows auf eine nette Zeile gekommen, die schon etwas die o.g. Problematik löst. Klar, PC wird das als störenden Schwachsinn verdammen, daher überlasse ich es Anderen, so etwas zu etablieren:

@ BurghardRichter Versuch: Fixierte Kopfzeile

Bei langen Tabellen ist es mitunter nicht klar, was die Werte bedeuten, wenn weit herunter gescrollt wird. Tabellen mit fixierter (Maximal-)Höhe und der css-Anweisung overflow funktionieren (noch) nicht perfekt. Es gibt aber eine billige Alternative:

1. On der ersten Zeile der sortierbaren Tabelle nach {| wird ergänzt: class="wikitable sortable kopf"
2. In die eigene css-Seite kommt die Zeile table.kopf thead th {position:-webkit-sticky; position:sticky; top:0;} - Abspeichern -- fertig!
3. Ab sofort werden beim Scrollen dieser (mit class='kopf' ergänzten) Tabellen die Kopfzeilen der Tabellen am oberen Seitenrand fixiert, bis die Tabelle durchgescrollt ist.

Eigene css-Seite anlegen/bearbeiten (für Angänger)

• Spezial:Globale_Einstellungen#mw-prefsection-rendering aufrufen.
• Dort bei Benutzeroberfläche die markierte auswählen („Voreinstellung“)
• Benutzerdefiniertes CSS anklicken zur Neuanlage (wenn Rotlink) oder Bearbeitung
• table.kopf thead th {position:-webkit-sticky; position:sticky; top:0;} eintragen, speichern
• Ab sofort kann man den Erfolg bei den entsprechend 'kopf'-markierten Tabellen sehen.
• Der Eintrag kopf ist für alle anderen Benutzer wirkungslos und unschädlich. Es muss aber damit gerechnet werden, dass WP-Puristen und Oberlehrer es ‚korrigieren‘ (siehe hier)
• Möglicherweise findet ein echter WP-Experte Freude daran, erkennt den Nutzen und übernimmt es global. Es geschehen mitunter noch Wunder.

Bei normalen, nichtsortierbaren Tabellen will es noch nicht. Ist in Arbeit!

Schönes WE --Klaus-Peter (ex und hopp) 12:31, 25. Apr. 2020 (CEST)

PS- nichtsortierbare Tabelle:

Problem ist, dass WP dann die erste Zeile nicht zu thead th .. th..., sondern zu tbody th .. th...macht. Das ist perfekter Unsinn, denn th darf nur bei thead (und ggf. tfood) stehen. Zutbody gehört td

Somit muss, um diesen Makel auszuglechen, noch die css-Zeile
table.kopf thead:not th {position:-webkit-sticky; position:sticky; top:0;}
dazu, dat hilft dem Vadder uff de Mudder --Klaus-Peter (ex und hopp) 15:31, 25. Apr. 2020 (CEST)

„Das ist perfekter Unsinn, denn th darf nur bei thead (und ggf. tfood) stehen. Zutbody gehört td“

• Das ist schlicht falsch, von vorn bis hinten.
• Die einzige Bedingung an THEAD und TFOOT ist, dass darin ausschließlich TR vorkommen dürfen. Ob diese TR dann nur TH, manchmal TH und TD oder nur TD enthalten, ist in die Gestaltungswünsche das Autors gestellt.
• Es kann durchaus sinnvoll sein, dass der Tabellenkopf (der nach Fähigkeiten des Browser statisch bleibt, während der TBODY ein scrollbarer Bereich ist) in seinem feststehenden Bereich auch TD-Zellen enthält. Gleiches gilt für einen TFOOT, der gern ausschließlich aus TD ggf. mit einer allgemeinen Legende bestehen kann.
• Auch vom TBODY wird lediglich verlangt, dass er nichts als TR enthalten darf. Ob diese TR dann TD oder TH enthalten, ist völlig egal.
• Im TBODY ist eine TH im TR gerade die barrierefreie „Überschrift“ für die einzelne Zeile; ergibt sich von selbst aber könnte auch explizit mit scope="row" gekennzeichnet werden. Das ist eine explizit wünschenswerte Struktur, mit der sogar Tabellen für Screenreader geeignet ausgestattet werden sollen, weil man dann bei Positionierung auf jede einzelne Zelle auf Anfrage erklärt bekommen kann, in welcher Spalte in welcher Zeile mit welchen Beschreibungen sie steht.
• Die Methodik der scrollbaren Tabellen obliegt den Herstellern der Browser; seit 1998 ermöglichen die THEAD, TBODY, TFOOT genau das und sind bewusst eingeführt worden, um eine solche Darstellung zu ermöglichen. Bislang ist das wohl noch nicht üblich. Zumindest unterstützen bisher nicht alle Browser entsprechende Möglichkeiten.
• Wenn überhaupt irgendjemand unsere Tabellen mit statischer Kopfzeile und Fußbereich und scrollbarem Inhaltsbereich dazwischen ausstattet, dann ist das die MediaWiki-Software, und zwar global für alle Wikis und auch für Mobil geeignet.

Solche Bastelarbeiten wie deine hatte man hier mal bis 2010 in die Artikel und Vorlagen reingebaut; wir sind seit etlichen Jahren damit beschäftigt, all diesen untauglichen Pfusch wieder rauszuwerfen. Jetzt, ein Jahrzehnt später, schlägst du auf, hast weder von HTML-Syntax noch von Wiki-Syntax viel Ahnung, und drückst uns auf dem Niveau der Bastel-Wikipedia von 2005 all diese Schandtaten erneut wieder auf. In unseren Artikeln und Vorlagen haben nur robuste mobiltaugliche fachkundige Programmierungen was zu suchen, irgendwelche experimentellen privaten Hacks, die auf dem eigenen Browser und Bildschirm irgendwie hingetrickst werden und dann in Seitenquelltexte reingedroschen werden haben erfahrungsgemäß keine lange Lebensdauer.

VG --PerfektesChaos 14:02, 12. Mai 2020 (CEST)

Für "data-sort-type" fehlen die Werte

Im früheren Abschnitt "Festlegung des Sortiermodus und Sortierreihenfolge" stand bis 4. Mai 2020:

• data-sort-type="text"|text
• data-sort-type="number"|number
• data-sort-type="currency"|currency
• data-sort-type="time"|time
• data-sort-type="date"|date
• data-sort-type="isoDate"|isoDate

Auf der neuen Seite unter "Datentyp explizit festlegen" fehlt die Erwähnung komplett.

Hm, musste das umständlich recherchieren. Und was könnte sonst noch kommentarlos weggefallen sein? Gruß --Chiananda (Diskussion) 01:25, 26. Sep. 2020 (CEST)

Hallo Chiananda, das Thema Sortierung wird jetzt auf einer eigenen Seite behandelt. --Wiegels „…“ 02:14, 26. Sep. 2020 (CEST)

Genau, deshalb ist oben der entsprechende Abschnitt verlinkt: Hilfe:Tabellen/Sortierung #Datentyp explizit festlegen. Und da fehlen Details und Beispiele. Gruß --Chiananda (Diskussion) 02:29, 26. Sep. 2020 (CEST)

@Chiananda: ????????????

• Das Code-Beispiel steht bei Hilfe:Tabellen/Sortierung #Datentyp explizit festlegen mit bei; hier mal exemplarisch für number.
• H:TSORT #Datentypen – Konzept müsste grob antizipiert werden, bevor es in Sub-Detailfragen geht.
• Die einzelnen Datentypen sind erläutert bei: H:TSORT #Einzelne Datentypen

Die neue Seite ist sehr viel umfangreicher, konkreter, präziser und aktueller als es umseitig jemals gewesen war.

Weil es heutzutage sehr viel mehr und detailliertere Beispiele gibt als „Früher war alles besser“, und diese jede normale Seite zersprengen und völlig unübersichtlich und unlesbar machen würden, gibt es dafür speziell: Hilfe:Tabellen/Beispiele

VG --PerfektesChaos 18:27, 26. Sep. 2020 (CEST)

"Leere Zelle"

In der Tabelle "Microvision#Spiele" gibt es Zellen, die -hm- so was ähnliches wie "thematisch leer" sind. Beispiel:

Hersteller	Modell	Preis
BMW	323i	25.000
VW	Touran	unbekannt
Mercedes	E190	19.000
Opel	Ampera	unbekannt

Damit ein Leser schneller erfassen kann, dass manche Zellen "leer" sind, habe ich diese per <small> -hm- zurückgenommen (was ist das Gegenteil von 'hervorgehoben'?):

Hersteller	Modell	Preis
BMW	323i	25.000
VW	Touran	unbekannt
Mercedes	E190	19.000
Opel	Ampera	unbekannt

Hier im Beispiel hält sich der Unterschied in Grenzen, im Artikel "Microvision#Spiele" macht es -imo- einen ganz erheblichen Unterschied bzgl. der Lesbarkeit: Artikelversion mit 'small' vs. Artikelversion ohne 'small'

Benutzer:Schnurrikowski revertet meine 'small-Version' wieder auf Normal-Text zurück.

Ich finde, ein Artikel sollte möglichst leserfreundlich gestaltet sein, möchte aber weder einen Editwar anfachen - und solche "Geschmacksfragen" sind eigentlich auch keine VM wert. Was denken die anderen WP-Autoren?

Weder auf Hilfe:Tabellen noch hier auf Hilfe:Tabellen für Fortgeschrittene konnte ich diesbezüglich etwas finden...

--arilou (Diskussion) 17:33, 8. Dez. 2020 (CET)

Richtig, ein Artikel sollte möglichst leserfreundlich gestaltet sein. Deshalb sollte auf verkleinerte Schrift weitgehend verzichtet werden, weil die nämlich leserunfreundlich ist. -- Chaddy · D 17:41, 8. Dez. 2020 (CET)

+1 Schnurrikowski (Diskussion) 18:17, 8. Dez. 2020 (CET)

• Richtig ist, dass Zellen nicht einfach leer gelassen werden soll, wenn wir einen konkreten Grund kennen, warum da nichts konkret steht. Kann ja auch einfach heißen: Wissen wir nicht, haben wir noch keine Infos dazu gefunden. Das würde ich bei leeren Feldern als Standardfall annehmen.
• Wenn eine Zelle keine Daten enthalten kann, aus irgendeiner Logik heraus, wäre ein breiterer horizontaler Strich üblich, um das zu verdeutlichen.
• Hier geht es darum, dass bestimmte Varianten niemals erschienen waren.
  • Das sollte sich optisch unterscheiden von den expliziten Bezeichnungen.
  • Die Verwendung gleicher Schriftgröße und gleichen Schriftstils wie für die deutschsprachigen Namen ist sehr, sehr unglücklich und leserunfreundlich.
  • Verkleinerung der Schrift für bedeutungstragende Informationen möchten wir nicht, aber statt des harten small eine Zelle in zarterem (nicht erschienen) wäre hier angemessen.
• Die Angelegenheit ist keine „Geschmacksfrage“; offenbar schlechtere Darstellungen sind keine gleichberechtigten Geschmacksfragen, für die irgendjemand Eigentumsansprüche anmelden könnte.

VG --PerfektesChaos 20:40, 8. Dez. 2020 (CET)

Es ist auf jeden Fall sinnvoll und leserfreundlich, durch eine andere Schriftart anzuzeigen, dass es sich hier nicht um normale Tabelleneinträge handelt. Kleinsatz – sofern es nicht zu klein ist – ist eine Möglichkeit dazu; Kursivsatz wäre eine andere Möglichkeit. Für einen mässigen Kleinsatz spricht in manchen Fällen auch: Wenn in einer Spalte von Zahlen ersatzweise ein erklärendes Wort eingesetzt wird, so ist dieses Wort in vielen Fällen länger als die Zahlen, was dazu führen kann, dass die Tabellenspalte breiter wird. Dieser Effekt kann durch kleinere Schrift abgemildert werden. --BurghardRichter (Diskussion) 02:51, 9. Dez. 2020 (CET)

Eine breitere Tabellenspalte ist nun wirklich kein besonderes Problem. Das ist kein wirkliches Argument für Kleinschrift. Kursivschrift ist aber aus meiner Sicht ok. -- Chaddy · D 06:27, 9. Dez. 2020 (CET)

Dass irgendetwas nicht erschienen ist, ist eine zu den anderen Tabelleneinträgen völlig gleichwertige Information. Darum ist m.E. für diese Kenntlichmachung auch die gleiche Schrift(größe und -art) zu benutzen. Eine Verbesserung der Übersicht durch Kleinschreibung oder Kursivssatz kann ich persönlich nicht erkennen. Eine leere Zelle ist aus meiner Sicht auch keine Lösung. Soviel zu meinen Vorlieben. Eure Schreibweisen sind ebenfalls als persönliche Vorlieben zu werten, denn eine explizite Vorschrift seitens Wikipedia oder Duden zum Thema ist mir nicht bekannt. Und damit es in solchen Fällen unterschiedlichen Geschmacks kein Hauen und Stechen gibt, hat lt. WP:KORR der Hauptautor das letzte Wort. Und weil das in diesem Fall ich bin und ich meine Version für die bessere halte, habe ich Arilous Änderungen rückgängig gemacht. Ich bitte das zu respektieren oder ein entsprechendes Meinungsbild für eine entsprechende Vorschriftenfindung zu starten. Viele Grüße, Schnurrikowski (Diskussion) 10:26, 9. Dez. 2020 (CET)

"Dass irgendetwas nicht erschienen ist, ist eine zu den anderen Tabelleneinträgen völlig gleichwertige Information." Das sehe ich ganz anders. "nicht erschienen" ist kein 'Spielname' (Spaltenüberschrift!) wie die anderen Einträge, und hat damit eine ganz andere Bedeutung: Es ist kein "gültiger Tabelleneintrag", sondern eine Erklärung, warum die Zelle eigentlich leer sein müsste!

Du willst ein 'Meinungsbild' dazu? Nimm' doch bis auf weiteres diese Diskussion. Soweit ich das sehe, ist die deutliche Mehrzahl der Diskutierenden durchaus dafür, dass solche Einträge optisch etwas zurückgesetzt erscheinen sollten. Ob nun kursiv, oder mit <small>, oder leicht 'ausgegraut', oder sonstwie - aber der derzeitige Stand im Artikel ist so ziemlich die schlechteste mögliche Variante.

--arilou (Diskussion) 10:34, 10. Dez. 2020 (CET)

PS: Was ich zum Thema 'Hauptautor' denke, kann auf meiner Benutzerseite nachgelesen werden.

Was du über Hauptautoren, die im Gegensatz zu dir Artikel schreiben und nicht nur darin herumeditieren, denkst, ist hier völlig unerheblich. In diesem Fall gilt nach wie WP:KORR. Und wie du anhand der mindestens fünf anderen hier gemachten Vorschläge siehst, nicht ohne Grund. Und hör bitte auf, die Diskussion über die Tabelleninhalte in der gesamten Wikipedia zu verteilen. Viele Grüße, Schnurrikowski (Diskussion) 10:49, 10. Dez. 2020 (CET)

Ich hab' zwar nicht mitgezählt, aber in meinen mittlerweile 14 Jahren WP-Autorenschaft habe auch ich so einige Artikel neu angelegt. Ich brauche aber keine "Hauptautorenrechte", meine Benutzerseite definiert sich auch nicht fast ausschließlich über eine „Liste mit tollen Erfolgen“ und ich vermeide Kritiken nahe an ad hominem - zumindest mein Ego kommt auch ohne so etwas klar.

--arilou (Diskussion) 11:14, 10. Dez. 2020 (CET)

PS: "die Diskussion über die Tabelleninhalte in der gesamten Wikipedia zu verteilen" - 2 Stellen sind zu viel? Eine für das Thema im Allgemeinenen, eine speziell für den Artikel, in dem das Problem aufgekommen ist - "überall in der Wikipedia"?

WP:Dritte Meinung

wurde angefordert --Siehe-auch-Löscher (Diskussion) 17:17, 9. Dez. 2020 (CET)

Dritte Meinung: Meine Devise: So wenig Schriftveränderungen wie möglich bzw. nötig. In der obigen Tabelle springt der Unterschied von einer Zahl "25.000" und "unbekannt" direkt ins Auge, da bedarf es keiner Hervorhebung. Im folgenden Beispiel hingegen würde ich kursiv setzen.

Jahr	Jahres-Tournee
1982	Amerika (Nord)
1983	Australien
1984	Ausgefallen
1985	Afrika
1986	Amerika (Süd)

Daher, keine globale Regel, sondern im Einzelfall entscheiden. Es gibt bestimmt auch Beispiele wo small oder geklammert zu bevorzugen ist. --Siehe-auch-Löscher (Diskussion) 17:17, 9. Dez. 2020 (CET)

Sehe ich ähnlich. Ich würde eine optische Unterscheidbarkeit zwischen normalen Werten und fehlenden Werten, Anmerkungen usw. generell bevorzugen. Eine kleinere Schrift ist dabei aber nicht unbedingt das Mittel der Wahl. Elemente wie Kursivsetzung, die Verwendung von Strichen/Symbolen oder die (Einklammerung) halte ich für besser geeignet. -- H005 (Diskussion) 17:45, 9. Dez. 2020 (CET)

Wuerde ebenfalls von einer globalen Regelung abraten, da diese auch recht schnell mit anderen Konventionen in Konflikt geraten kann. (Tabelle mit Schiffsnamen (kursiv gemaess üblicher Praxis in WP) und die Leerzelle wird dann auch kursiv um sie unterscheiden zu koennen??) Kurz gesagt, das sollte im Einzelfall, bzw. evtl. auch auf Portalebene geklärt werden, da es z.B. durchaus sinnvoll sein kann wenn dies bei Artikeln eines Themenkomplexes einheitlich geregelt wird.--KlauRau (Diskussion) 19:06, 9. Dez. 2020 (CET)

3M: Ich finde eine unterschiedliche Formatierung sehr sinnvoll. Ob man das Wort kursiv setzt oder einklammert oder Striche hinzufügt (z. B. "– unbekannt –") kann man sicherlich im Einzelfall festlegen. In manchen Fällen ist vermutlich auch keine unterschiedliche Formatierung notwendig, z. B. wenn die Spalte sonst nur Zahlen enthält fällt ein "unbekannt" schon von sich aus aus der Reihe. Unterschiedliche Schriftgröße und -farbe würde ich aus Barrierefreiheitsgründen möglichst vermeiden. -- Jonathan 09:11, 10. Dez. 2020 (CET)

Hm, dann plädiere ich dafür, in den Artikel "Hilfe Diskussion:Tabellen für Fortgeschrittene" etwas derartiges aufzunehmen:

Von der eigentlichen Spaltenbedeutung abweichende Einträge können optisch abgesetzt werden, wenn dies die Lesbarkeit signifikant erhöht. Die Absetzung sollte möglichst dezent bleiben; wenn beispielsweise in einer „Zahlenwerte-Spalte“ stattdessen Worte erscheinen, so ist dies bereits ein ausreichender Unterschied, die Einträge sollten nicht zusätzlich kursiv oder klein gesetzt werden, auch eine (Einklammerung) ist dann nicht nötig; ebenso ist eine leere Zelle fast immer bereits ausreichend optisch abgegrenzt. In manchen Themengebieten gelten Fachbereichs-spezifische Vereinbarungen bzgl. der Formatierung, beispielsweise werden Schiffsnamen stets kursiv gesetzt (siehe Portal:Schifffahrt/Richtlinien Schifffahrt).

--arilou (Diskussion) 10:54, 10. Dez. 2020 (CET)

Nein. Das hier ist eine Hilfe-Seite, die in technischer Hinsicht die Tabellensyntax beschreibt. Hier fügen wir defintiv keine good practices oder sonstige Formatierungskonventionen ein. Das ist eine Unart, die man sich endlich mal abgewöhnen sollte. Für derartige Konventionen etc. gibt es den Wikipedia-Namensraum. 80.135.51.183 11:42, 10. Dez. 2020 (CET)

+1, IP.

Wir haben aus alter Tradition und ewig umstritten kein en:WP:Manual of Style – nur WP:WSIGA und verstreute Brösel gehen in diese Richtung.

Müsste in der Tat im WP-Namensraum lokalisiert sein, so wie auch WP:AI. Gestaltungsfragen sind diffizil, die Technik kann nur mögliche technische Lösungen darstellen und klar unerwünschte Syntaxstrukturen zurückweisen.

Ein „MoS“ wurde jedoch vor einem Dutzend Jahren immer abgelehnt, weil die Hauptautoren der Gründungsgeneration jeder sein individuelles Ding in „seinen“ Artikeln drehen wollten, und nicht durch ein MoS davon zu überzeugen wären, dass ihr privater Geschmack nicht lesertauglich ist. Deshalb darf es kein MoS geben. In der Konsequenz fehlt Newcomern die Orientierung und Anleitung.

VG --PerfektesChaos 15:37, 10. Dez. 2020 (CET)

+1: keine globale Regel, sondern im Einzelfall entscheiden.

Empfehlenswert ist auch einfach die Angabe von – oder k. A.. Gruß --Chiananda (Diskussion) 16:05, 15. Dez. 2020 (CET)

Und, wie hier beispielhaft am Artikel Microvision zu sehen: (Zitate!) "eine explizite Vorschrift seitens Wikipedia [...] ist mir nicht bekannt. [...] der Hauptautor [hat] das letzte Wort. Und weil das [...] ich bin und ich meine Version für die bessere halte" kommt ein Revert. Basta. "Bitte unterlasse deine Geschmacksedits."

Ein 'Manual of Style' könnte auch als Ratgeber formuliert sein - so wie mein obiger Vorschlag; wobei ich zugeben muss, dass mir schon oft Mitautoren begegnet sind, die ganz eindeutig den Unterschied zwischen 'muss', 'kann' und 'sollte' nicht kennen (und alle drei Varianten als 'muss' verstehen).

--arilou (Diskussion) 12:35, 15. Dez. 2020 (CET)

PS: Nur schlechte Hauptautoren klopfen auf ihren Status. Gute brauchen das nicht.

Da hier ja ein recht klares Votum gegen eine pauschale Regelung und für Einzelfallentscheidungen geäußert wurde, wäre es, denke ich, hilfreich, wenn weitere Stimmen die Einzelfallentscheidung für den Konflikt unterstützen würden, an dem sich das Ganze entzündet hat: Diskussion:Microvision#Nicht-Erschienen_in_Tabelle_'Spiele' -- H005 (Diskussion) 10:02, 16. Dez. 2020 (CET)

Colspan und rowspan in Überschriften

Ich möchte bei Wikipedia:Denkmal-Cup/2021 im Tabellenkopf verbundene Zeilen einfügen. aber ich scheiter mit colspan und rowspan. kann man diese funktionen nicht im Tabellenkopf nutzen? viele grüße -- ^Thomas 11:58, 8. Jul. 2021 (CEST)

Hallo Thomas, sollen die Zellen ahnlich verbunden sein wie hier? --Wiegels „…“ 12:04, 8. Jul. 2021 (CEST)

oh mann @Wiegels: ich schäme mich für meine Frage :-) vielen Dank -- ^Thomas 12:20, 8. Jul. 2021 (CEST)

Du hast es geschafft! :-) --Wiegels „…“ 12:28, 8. Jul. 2021 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Wiegels „…“ 12:28, 8. Jul. 2021 (CEST)

Sortierbare Dezimalzahlen mit Vorzeichen

Hallo, auf der Hilfe-Seite vermisse ich im Abschnitt Zahlen und Buchstaben eine Beschreibung für den Fall der Sortierbarkeit vorzeichenbehafteter Dezimalzahlen.

Anwendungsbeispiel: Tabelle mit Umsatzzahlen von Unternehmen, wobei eine Spalte die (prozentuale) Veränderung zum Vorjahr mit 2 Nachkommastellen angibt. Ein solcher Wert trägt in jedem Fall ein Vorzeichen („+“, „±“, „−“), das ohne Leerzeichen angeschlossen ist:

Umsatz

Unternehmen	2018 (Mrd. €)	Änd. (%)
Firma A	167,36	+1,84
Firma B	025,78	+9,75
Firma C	020,62	−6,14
Firma D	011,11	−11,11
Firma E	006,00	±0,00
Firma F	004,40	+14,88
Firma G	004,32	+21,01
Firma H	004,21	−0,24
Firma J	002,78	−14,72

So wie im Beispiel umgesetzt funktioniert es wohl, aber ich bin mir nicht sicher, ob das den heutigen Vorgaben für die Tabellensyntax entspricht oder doch eher ein Workaround ist. Noch drei Anmerkungen:

• Für die letzte Spalte ist trotz der Vorzeichen der Datentyp number vorgegeben.
• Im speziellen Fall „keine Veränderung zum Vorjahr“ ist der Null-Wert zusätzlich mit data-sort-value="0,00" attributiert, um trotz des Plusminuszeichens eine korrekte Sortierung zu erzwingen.
• Auf eine perfekt ausgerichtete Spalte wurde im Hinblick auf möglichst einfache Tabellensyntax verzichtet. (Dafür würde wohl noch ein vorangestelltes geschütztes Leerzeichen benötigt, z. B.  +1,84)

--rolf_acker (Diskussion • Beiträge • Logbücher) 10:12, 7. Nov. 2019 (CET)

Hallo,

Spalten, die Zahlen enthalten, sollten der Lesbarkeit halber immer rechtsbündig angeordnet werden, wobei Dezimalzahlen immer gleich viele Nachkommastellen brauchen. Ich habe gelernt, dass das vorangestellte geschützte Leerzeichen eine unerwünschte Umgehungslösung ist. Ich behelfe mich gegenwärtig so:

Umsatz

Unternehmen	2018 (Mrd. €)	Änd. (%)
Firma A	167,36	+1,84
Firma B	025,78	+9,75
Firma C	020,62	−6,14
Firma D	011,11	−11,11
Firma E	006,00	±0,00
Firma F	004,40	+14,88
Firma G	004,32	+21,01
Firma H	004,21	−0,24
Firma J	002,78	−14,72

--Wolfdietmann (Diskussion) 10:39, 25. Feb. 2022 (CET)