Hilfe Diskussion:Tabellen/Archiv/2014

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/Archiv/2014#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Hilfe_Diskussion:Tabellen/Archiv/2014#Thema_1

Falsche Sortierung von Zahlen

Hallo Auf der Seite Liste_der_Lokomotiv-_und_Triebwagenbaureihen_der_Deutschen_Bahn werden die Geschwindigkeiten in der Tabelle Dieselloks nicht richtig sortiert. Die 8 wird höher angesehen als 1 und entsprechend sortiert. In den anderen Tabellen funktioniert es aber. Wo liegt der Fehler? S. auch Diskussion --master-davinci (Diskussion) 16:06, 9. Jan. 2014 (CET)

Hallo master-davinci, ich habe bei den Geschwindigkeitsspalten eingetragen, dass sie numerisch sortiert werden sollen. --Wiegels „…“ 16:34, 9. Jan. 2014 (CET)

Tabellen nebeneinander

Leider weiß ich nicht, wie man zwei Tabellen nebeneinander anordnet. Könnte mir das jemand, der davon Ahnung hat, mal am konkreten Beispiel zeigen? Einfach so ändern, das sie nebeneinander stehen, das wäre freundlich, siehe hier. Danke im Voraus. --Jack User (Diskussion) 20:58, 22. Jan. 2014 (CET)

Ich hab's mal versucht: [1]. Problematisch sind die Angaben "center" und "width". Wenn man die drin lässt, gehen die Tabellen über mehr als eine Bildschirmbreite. --Drahreg01 (Diskussion) ^3Wf 21:17, 22. Jan. 2014 (CET)

Danke, ich probier einfach mal weiter. --Jack User (Diskussion) 21:20, 22. Jan. 2014 (CET)

Trotzdem nochmal: wie bekommt man es hin, dass beide gleich breit sind? --Jack User (Diskussion) 21:21, 22. Jan. 2014 (CET)

Warum sollten nebeneinander stehende Tabellen gleich breit sein müssen? --Drahreg01 (Diskussion) ^3Wf 21:26, 22. Jan. 2014 (CET)

(BK) Ich habs auch umgesetzt [2]. Es geht mit class="float-left" style="margin-top:0.0em" für die erste Tabelle. Die shat aber den Nachteil, das bei zu schmalen Aunzeigefenstern die Tabellen weiterhin nebeneinander dargestellet werden. --Cepheiden (Diskussion) 21:24, 22. Jan. 2014 (CET)

Ich rate übrigens generell von solchen Konstrukten ab. Wenn man sie einsetzt, sollte man zumindest das Layout auf kleinen Anzeigen wie Smartphone prüfen. --Cepheiden (Diskussion) 21:28, 22. Jan. 2014 (CET)

Danke für den Hinweis. Nur noch eine letzte Frage: kriegt man die Tabellen auch gleich breit? --Jack User (Diskussion) 21:33, 22. Jan. 2014 (CET)

Am Besten mit CSS und dem Befehl width [3] und vorgegebener Breite in "em". Aber auch solche Formatierungen mit bedacht einsetzen, nicht jeder Nutzer hat eine große Anzeige. --Cepheiden (Diskussion) 21:36, 22. Jan. 2014 (CET)

So, jetzt sind die beiden Tabellen zwar nicht gleich breit, dafür stehen sie nebeneinander. Gruß, — Elvaube ^?! 14:39, 23. Jan. 2014 (CET)

Das Beispiel hat leider ein ganz schwerwiegendes Problem: Die Sortierknöpfe sind durch das Zerbrechen auf zwei Tabellen völlig sinnlos geworden. Solche Tabellen müssen intakt bleiben. Wir haben keine vernünftige technische Möglichkeit, Mehrspaltiges zu sortieren. Und ich fürchte, das Beispiel entspricht auch nicht den Konventionen im Filmbereich. Um zwei voneinander unabhängige Tabellen nebeneinander zu stellen, würde ich zur folgenden Kombination raten. Sie hat den Vorteil, dass es auf Smartphones untereinander rutscht. PS: Achtung, Firefox kapiert das nicht, obwohl es standardkonform ist. --TMg 17:39, 23. Jan. 2014 (CET)

{| class="wikitable float-left" style="margin-top:0; min-width:30em;"
! Kopf 1
|-
| Inhalt 1
|}
{| class="wikitable" style="min-width:30em;"
! Kopf 2
|-
| Inhalt 2
|}
{{Absatz}}

Ich habe es nicht auf dem Smartphone getestet, aber die von dir beschrieben Methode funktioniert mit meinem Firefox nicht. Des Weiteren muss ich davon abraten diesen Inhalt überhaupt in zwei Tabellen aufzuteilen. Welchen Vorteil soll das haben? --Cepheiden (Diskussion) 18:51, 23. Jan. 2014 (CET)

<quetsch>Ich wollte mal austesten, wie es aussieht, vor allem bei ellenlangen Filmografien bei Stummfilmschauspielern. Aber ich lasse die Idee wieder fallen, da die Ergebnisse nicht gerade berauschend sind... --Jack User (Diskussion) 10:19, 24. Jan. 2014 (CET)

Wahrscheinlich den, dass die Tabelle nach unten hin so lang werden soll. Solch formatierte Tabellen findet man doch überall, in Ortsartikeln für die Auflistung der Einwohnerzahlen beispielsweise. Gruß, (nicht signierter Beitrag von Elvaube (Diskussion | Beiträge) 10:02, 24. Januar 2014)

Einwohnerzahlen sortiert man üblicherweise nicht um, sie sind schon nach dem Jahr sortiert. --TMg 12:31, 24. Jan. 2014 (CET)

Nur weil sie häufig verwendet werden, ist das nicht eine super Lösung. Es ist vielmehr ein Kompromiss der ähnliche Nachteile wie eine lange Tabelle hat. --Cepheiden (Diskussion) 20:15, 24. Jan. 2014 (CET)

Spaltenformatierung

Nachdem der Internet Explorer 8 in Deutschland nun nur noch einen Marktanteil von 3,4 Prozent hat, könnte doch nun das CSS-Element für Spaltenformatierung von Tabellen zugelassen werden. Wie in einer früheren Diskussion (siehe Archiv) mal angeregt, lassen sich Tabellenspalten prinzipiell mit table.drittespaltezentriert td:nth-child(3) { text-align: center } einheitlich formatieren, dann hat dieses ewige style:"text-align:center" endlich mal ein Ende. Momentan gibt es mangels Zugriff auf das style-Tag keine Möglichkeit das umzusetzen, aber es wäre sicher möglich, es über dafür eigens definierte Klassen im Standard-CSS umzusetzen und einfach nutzbar zu machen.

Eine Möglichkeit wäre sehr viele Klassen zu definieren und in den Tabellenkopf einfach class="wikitable lccr" rein und dann wird die zweite und dritte Spalte zentriert und die rechte rechts ausgerichtet.

Eine andere Möglichkeit bestände darin, für jede Spalte die drei Klassen links, zentriert und rechts zu definieren, dann sähe es so aus: class="wikitable s2c s3c s4r". Damit würde der Aufwand auch für eine große Anzahl Spalten übersichtlich bleiben. Klar, beides etwas unübersichtlicher, aber mal ehrlich, Tabellen sind ohnehin eher etwas für fortgeschrittenere Benutzer. --Sepp (Diskussion) 11:07, 18. Feb. 2014 (CET)

Ergänzung: Hier mal ein HTML-Code, der das macht, was ich meine:

<html>
<head>
<style>
table.s1l td:nth-child(1), table.s2l td:nth-child(2), table.s3l td:nth-child(3) { text-align: left; }
table.s1c td:nth-child(1), table.s2c td:nth-child(2), table.s3c td:nth-child(3) { text-align: center; }
table.s1r td:nth-child(1), table.s2r td:nth-child(2), table.s3r td:nth-child(3) { text-align: right; }
</style>
</head>
<body>
<table class="s1l s2c s3r">
<tr><td>Links</td><td>Mitte</td><td>Rechts</td></tr>
<tr><td>1</td><td>2</td><td>3</td></tr>
<tr><td>4</td><td>5</td><td>6</td></tr>
<tr><td>7</td><td>8</td><td>9</td></tr>
</table>
<body>
</html>

Im Wikitext sähe das dann so aus:

{| class="s2c s3r"
|-
! Links !! Mitte !! Rechts
|-
| 1 || 2 || 3
|-
| 1 || 2 || 3
|-
| 1 || 2 || 3
|}

Zum Vergleich: Momentan sähe der Wikitext so aus:

{| 
|-
! Links !! Mitte !! Rechts
|-
| 1 ||style="text-align:center;"| 2 ||style="text-align:right;"| 3
|-
| 4 ||style="text-align:center;"| 5 ||style="text-align:right;"| 6
|-
| 7 ||style="text-align:center;"| 8 ||style="text-align:right;"| 9
|}

Die Tabelle dementsprechend so:

Links	Mitte	Rechts
1	2	3
4	5	6
7	8	9

--Sepp (Diskussion) 11:34, 18. Feb. 2014 (CET)

Die eleganteste Möglichkeit solche CSS-Definitionen einzufügen, wäre <style scoped> mit Bug 50644. --Fomafix (Diskussion) 09:30, 19. Feb. 2014 (CET)

Ich wäre ja eher dafür, das gleich in die Common.css einzufügen. Ich glaube, für kaum etwas wird so viel per Hand zurechtformatiert, wie Tabellen. Sollte ich den Vorschlag da mal machen oder gibt es Vorbehalte gegen diese Implementation aus Sicht der Tabellenerstellenden? --Sepp (Diskussion) 14:12, 19. Feb. 2014 (CET)

Für die horizontale Ausrichtung (links/zentriert/rechts) lässt sich eine solche Definition theoretisch machen. Dann kommt aber bestimmt auch der Wunsch nach vertikaler Ausrichtung, nach Hintergrundfarbe, Rahmen, nach Fett, Kursiv usw. Da ist das Konzept mit CSS-Klassen für jede Eigenschaft schnell überfordert. --Fomafix (Diskussion) 15:34, 19. Feb. 2014 (CET)

Was den Einwand angeht, gebe ich Dir theoretisch recht, praktisch ist aber die horizontale Ausrichtung ein in Massen auftretendes Problem, wogegen all die anderen Dinge nur in Einzelfällen vorkommen. <style scoped> wird sicher wegen den Missbrauchsmöglichkeiten nie für normale Nutzer freigeschaltet werden. --Sepp (Diskussion) 22:11, 19. Feb. 2014 (CET)

Tabelle als Ergänzung

Detail der Anghiarischlacht, 1603
gezeichnete Kopie von Peter Paul Rubens

Tabellen zerreissen den Lesefluss. Ich fände es häufig besser, wenn ich kleine Tabelle rechts wie ein Bild darstellen könnte, aber den Lesefluss links nicht unterbrechen. Wie muss ich meine Kleintabelle aufbauen, um das zu erreichen, was ich mit dem Bild hier tue? Yotwen (Diskussion) 12:00, 13. Mär. 2014 (CET)

Hallo Yotwen, du kannst der Tabelle die CSS-Klasse „float-right“ mitgeben. Dann wird sie rechts angeordnet und der Text fließt herum, siehe Hilfe:Tabellen#Ausrichtung der Tabelle. --Wiegels „…“ 12:12, 13. Mär. 2014 (CET)

Kein Breitenparameter, das heisst dann wohl, ich muss harte Zeilenumbrüche machen oder? Yotwen (Diskussion) 16:08, 13. Mär. 2014 (CET)

Wenn deine „kleine Tabelle“ nicht schmal genug ist, kannst du sie nebenher wie gewohnt in der Breite einschränken, als Ganzes oder spaltenweise. Abhängig von der Art des Inhalts kann das eleganter sein als das Hinzufügen fester Zeilenumbrüche. --Wiegels „…“ 16:36, 13. Mär. 2014 (CET)

Dieser Abschnitt kann archiviert werden. Danke, das ist zwar etwas kniffelig, aber löst mein Problem. Yotwen (Diskussion) 17:19, 13. Mär. 2014 (CET)

Sortierpfeile unter dem Spaltentitel?

Gibt es eine Möglichkeit, die Sortierpfeile unter den Spaltentitel zu bekommen, statt daneben? Ich meine, früher hätte das mit einem Umbruchbefehl geklappt, das funktioniert aber jetzt nicht (mehr?). Es geht darum, breite Tabellen, die aus dem Bildschirm herausragen, zu verschlanken, aktuell beschäftigt mich das bei Liste der Plebiszite in Deutschland. --Nicolai P. (Disk.) 16:06, 27. Apr. 2014 (CEST)

Zwar nicht ratsam, auch nicht dauerhaft stabil, jedoch technisch möglich:

Typ
A
B

Nur wenn unbedingt notwendig; besser Kürzungsmöglichkeiten suchen. Oder der Inhaltstext ist ohnehin lang genug.

Viel Glück --PerfektesChaos 12:29, 28. Apr. 2014 (CEST)

Danke, wenn das so kompliziert ist, versuche ich tatsächlich nochmal anders mein Glück. Ich finde, die Sortierpfeile sollten generell unter der Zeilenüberschrift stehen, oder zumindest sollte es das als Möglichkeit geben. Ich habe mir schon sehr oft gewünscht, eine Tabelle auf diese Weise schmaler machen zu können. --Nicolai P. (Disk.) 12:39, 28. Apr. 2014 (CEST)

CSS-Klassen für Zellenzur Spaltenausrichtung

Hallo, aufgrund der kürzlichen Änderungen … es gibt mehrere Klassen für ganze Tabellen aber es fehlen m.M.n. Klassen für Zellen mit dicktengleicher Schrift (monospace)

.mono { font-family: monospace; }

und für rechtsbündige Zellen

.tar { text-align: right; }

Wobei … die sind vllt. auch außerhalb von Tabellen ganz praktisch …

Wen muss man denn da ansprechen? Oder wie sollte ich vorgehen, um das zu realisieren? LG, ℳ웃79 (Diskussion) 11:26, 1. Jun. 2014 (CEST)

Anlässlich der Anlage der Vorlage:A folgende Meinungsäußerung: Ich sehe keinerlei Bedarf für solche Klassen.

• Die Verwendung von Monospace-Schriften vermeidet man einfach. In den wenigen Fällen, in denen die Verwendung sinnvoll ist, ist meist auch die Verwendung eines Tags sinnvoll, das sowieso Monospace-formatiert ist, wie zum Beispiel <code> oder <syntaxhighlight>.
• Für die Ausrichtung schreibt man einfach normales CSS als style-Attribut: style="text-align:right;" – das wird seit Jahren so gemacht und class="tar" wäre nicht einfacher, sondern nur kryptischer.

Dass es bereits CSS-Klassen für ganze Tabellen gibt, heißt übrigens auf keinen Fall, dass ständig weitere Klassen angelegt werden. Ein Teil dieser Klassen ist sinnvoll, weil er der Vereinfachung und Vereinheitlichung dient; das funktioniert aber nur, solange es wenige Klassen sind. Ein anderer Teil ist Blödsinn, wurde nur irgendwann einmal aus einer spontanen Laune heraus angelegt und sollte nicht fortgeführt werden, indem man noch mehr unnötige Klassen einführt.

Gruß --Entlinkt (Diskussion) 19:06, 2. Jun. 2014 (CEST)

Gut, Monospace braucht keiner. Aber zentrierte und rechtsbündige Zellen werden oft benötigt und benutzt. Eine wirkliche Vereinfachung wäre allerdings nur, lediglich der Tabelle eine Klasse zuzuweisen, so dass die Ausrichtung der Spalten entspr. zugewiesen wird.

.col2right  tbody tr td:nth-of-type(2) { text-align: right; } 

.col3center tbody tr td:nth-of-type(3) { text-align: center; }

LG, ℳ웃79 ^✍ 03:03, 3. Jun. 2014 (CEST)

Siehe MediaWiki Diskussion:Common.css#Ausrichtung der Spalten in Tabellen. Problem: Man müsste für jede natürliche Zahl N zunächst einmal zwei Klassen anlegen, nämlich colNright und colNcenter und das kann nicht gut gehen, weil MediaWiki:Common.css endlich bleiben muss. Und selbst wenn man sich auf N < 30 oder ähnliches beschränken würde, würde die Datei dann zum größten Teil daraus bestehen.

Außerdem würde es über kurz oder lang nicht bei zwei Klassen bleiben, als nächstes werden colNbold, colNitalic, colNredbackground und vielleicht eben auch colNmonospace gefordert. Die letzten 10 Jahre ging es aber auch ohne solche Klassen. Vielleicht ist es sogar besser, keine zu haben, weil dann sparsamer mit Formatierungen umgegangen wird (Wikipedia-Artikel sollen allgemein nur wenige spezielle Formatierungen enthalten). --Entlinkt (Diskussion) 09:35, 3. Jun. 2014 (CEST)

Das Problem der spaltenweisen links-rechts-mitte-Ausrichtung bestimmter Spalten (abweichend von einer schriftspezifischen oder für die Tabelle vorgegebenen Standardausrichtung) besteht weltweit und ist häufig; auch keine triviale Dekoration, sondern verbessert die Lesbarkeit von Zahlen usw.

Wenn, dann sollte der Vorschlag nicht hier bei uns, sondern in dem MB an Ressourcen eingestrickt werden, das international mit jeder Wiki-Seite ausgestreut wird. Vo nmir aus bis Spalte 99, und nur für text-align.

LG --PerfektesChaos 10:30, 3. Jun. 2014 (CEST)

Nee, ich würde da sehr viel eher an eine Erweiterung der Wikisyntax denken, die es erlaubt, Attribute zu definieren, die auf alle Zellen einer Spalte angewendet werden. Mockup:

{| class="wikitable"
$ style="text-align:left;" $$ style="color:red; text-align:center;" $$ style="text-align:right; text-decoration:blink;"
|-
! Kopfzelle linksbündig || Kopfzelle rot und zentriert || Kopfzelle rechtsbündig und blinkend
|-
| Datenzelle linksbündig || Datenzelle rot und zentriert || Datenzelle rechtsbündig und blinkend
|}

CSS-Klassen sind hier der falsche Ansatz, weil sie einfach nicht funktionieren: Man bräuchte für jede natürliche Zahl eine Klasse (→ Murks hoch 3 selbst wenn man eine Obergrenze festlegt) und es kann in Verbindung mit colspan von Grund auf nicht funktionieren. Wenn überhaupt, sollte man wenigstens warten, bis die Browser die CSS4-Selektoren für Tabellen unterstützen, dies würde zumindest das Problem mit colspan beheben.

Ich sehe aber auch kein allzugroßes Problem darin, den Kram wie bisher einfach in jeder Zeile zu wiederholen oder spezielle Vorlagen wie Vorlage:Fußballtabelle anzulegen oder im Zweifelsfall einfach darauf zu verzichten. --Entlinkt (Diskussion) 17:49, 3. Jun. 2014 (CEST)

Danke für die Hinweise, PerfektesChaos. ℳ웃79 ^✍ 09:57, 4. Jun. 2014 (CEST)

Oh, gleiches Thema wie vor Kurzem. Bin nach wie vor für die Einführung der Klassen (ausschließlich zur Spaltenausrichtung) und für die ersten 10 Spalten sollte es reichen bis die CSS4-Selektoren verbreitet und unterstützt sind. Der colspan-Fall ist extrem selten (und für die eine betroffene Zeile behebbar), die Ausrichtung aber ständig anzutreffen. Ich finde es etwas absurd, in der oft selten abgerufenen Common.css vielleicht 1 kB einzusparen und dafür haufenweise Artikel deutlich größer zu machen. Und nochmal: Spaltenausrichtung ist so ziemlich die erste Funktion, die jedem Programm, was mit Tabellen zu tun hat, hinzugefügt wird, einfach weil es so wichtig ist. --Sepp (Diskussion) 20:14, 4. Jun. 2014 (CEST)

Dünnere Zeile

Wie lässt sich denn die Zeilenhöhe verkleinern? Zum Beispiel bei Zeile zwei hier:

normal

dünn

normal

Ich möchte, dass die Zeile gerade so hoch wie der Text ist. --Jobu0101 (Diskussion) 16:48, 12. Jun. 2014 (CEST)

Hallo Jubo0101, dein Wunsch lässt sich so umsetzen:

normal

dünn

normal

Ich hoffe, du wendest diese Formatierung im Artikelnamensraum nur in begründeten Fällen an. Wenn es dir nur um angenehmeres Lesen durch Platzersparnis geht, kannst du entsprechende Anpassungen in deinen persönlichen Einstellungen vornehmen. --Wiegels „…“ 17:10, 12. Jun. 2014 (CEST)

Vielen Dank. Hier habe ich es eingesetzt. --Jobu0101 (Diskussion) 17:21, 12. Jun. 2014 (CEST)

So wie du es nun editiert hast, wollte ich es ursprünglich machen. Es scheiterte dann auch an einer guten Spaltenbeschriftung (Dauer gefällt mir nicht so besonders, du hast ja auch schon angemerkt, dass du damit nicht so zufriden bist) und an der Tatsache, dass es eigentlich nicht in eine Zeile gehört, sondern zwischen zwei. Man könnte genauso gut vertreten, es in die nächste zu schreiben. --Jobu0101 (Diskussion) 17:48, 12. Jun. 2014 (CEST)

Eine ungenaue Spaltenbeschriftung finde ich besser als keine. Ich beschäftige mich wenig mit Ratswahlen. Wäre vielleicht „Dauer der Gemeinderats­zusammensetzung“ eine korrekte Überschrift? Die Dauer bezieht sich zurzeit jeweils auf die links davon beschriebene Sitzverteilung. So gesehen passt diese Zuordnung besser, als wenn sie um eine Zeile nach unten verschoben wäre. Gibt es Meinungen weiterer Mitleser dazu? --Wiegels „…“ 19:19, 12. Jun. 2014 (CEST)

Ich habe auch über "Zeitintervall bis zur Folgewahl" nachgedacht. Aber mit so langen Überschriften sieht die Tabelle nicht mehr schön aus. --Jobu0101 (Diskussion) 07:25, 13. Jun. 2014 (CEST)

Ich habe nun noch eine erklärende Fußnote eingebaut. So ist es ganz in Ordnung, denke ich. --Jobu0101 (Diskussion) 07:39, 13. Jun. 2014 (CEST)

Prima, sagt man nicht auch Legislaturperiode? --Wiegels „…“ 09:31, 13. Jun. 2014 (CEST)

Das passt hier nicht ganz, denn die neuen Gemeidneratsmitlgieder kommen ja nicht am Wahltag selbst in den Gemeinderat. --Jobu0101 (Diskussion) 21:45, 13. Jun. 2014 (CEST)

CSS-Klassen vs. persönlicher Geschmack

Es gibt immer mal wieder Auswüchse, dass der ein- oder andere WP-Autor Tabellen in seinem bevorzugten Stil haben will. Und das dann mit in hiesigem Artikel beschriebenen Möglichkeiten rechtfertigt. Hier der konkrete Anlass. Ich bin der Meinung, dass man solche "Specials" darauf beschränken sollte, wo inhaltlich notwendig, und sich ansonsten auf die vorgegebenen CSS-Klassen beschränken sollte - die sind nämlich Artikel-übergreifend einheitlich, ausgereift und (mehr oder weniger) abschließend diskutiert, auch für nicht-27-Zoll Monitore.

Bin ich da falscher Meinung? Sollen sich Autoren in jedem Artikel frei gestalterisch austoben dürfen?

--arilou (Diskussion) 14:45, 26. Jun. 2014 (CEST)

PS: Der "konkrete Anlass" ist übrigens auch genau 1 Abschnitt weiter oben in dieser Disku vertreten...

Und der heißt „Gleiche Spaltenbreite“ und ist kein „Mist“, sondern ein Versuch die Tabelle gleichmäßig aufzuteilen. Harry Canyon (Diskussion) 14:48, 26. Jun. 2014 (CEST)

1. Mit den width-Angaben könnt' ich leben (à la "alle Airbus-Modelle sind doch gleich wichtig, dann sollen auch die Spalten gleich breit sein"),
2. auch mit dem dickeren vertikalen "Trennstrich" nach den "Zeilenüberschriften".
3. Aber warum müssen die Überschriften unbedingt andersfarbig unterlegt sein (als in den CSS-Klassen vorgesehen)? Weil's in anderen Artikeln auch so (falsch) gemacht wird? Du springst auch vom Hochhaus, wenn's genug andere auch machen?
4. Und die dünneren Trennlinien innen begründest du mit "weil mir das besser gefällt" - siehe Überschrift dieses Disku-Absatzes...

--arilou (Diskussion) 14:57, 26. Jun. 2014 (CEST)

Siehe auch XHTML#XHTML und Layout, Inhalt und Layout sollte möglichst getrennt gehalten werden. Das gilt imo auch für WP-Artikelquelltexte. --arilou (Diskussion) 15:04, 26. Jun. 2014 (CEST)

PS: Ach ja: (Aus Cascading Style Sheets:) "[Cascading Style Sheets bieten auch] eine Unterscheidung zwischen verschiedenen Ausgabemedien.", d.h. ein Artikel kann unterschiedlich angezeigt werden, je nachdem, ob der Browser eine Smartphone- oder eine Desktop-Kennung an die WP-Engine meldet. Das geht natürlich nicht, wenn der Artikel "von Hand" in ein bestimmtes Layout gezwungen wird.

Was schreibst du den da von 27-Zoll Monitore? Ich habe hier einen 19"-Querformat und einen 15"-Hochformat stehen, auf Beiden schiebt sich die Tabelle nicht aus dem Bild. Und was heißt hier „‘weil mir das besser gefällt’“, wann hab ich denn das geschrieben? Die dünneren Striche innerhalb der technischen Angaben werden automatisch vorgegeben und nicht von mir eingefügt. Hingegen wurde der Trennstrich zwischen „Kenngröße“ und den nachfolgenden Modellen von mir im oberen Thread angesprochen und blieb bisher unbeantwortet. Zu Punkt 1: Es geht hier weniger um „à la ‘alle Airbus-Modelle sind doch gleich wichtig, dann sollen auch die Spalten gleich breit sein’“, sondern um den unnötigen Zeilenumbruch innherhalb der Tabellenzellen, wenn diese verschieden breit sind. Zu Punkt 3. Folgendes schrieb ich weiter oben: „In den weiteren Artikeln zur Airbus-Familie (bis auf den 380) wurden die Tabellenköpfe für die „Technische Daten“ farblich abgesetzt, selbiges findet sich beispielsweise auch bei der Boeing-Familie. Ich möchte dann doch nicht zu sehr in den Style eingreifen.“ Ich persönlich brauche keine "hintergrundfarbe8", nehme allerdings auf die bisherigen Autoren Rücksicht. Sollten wir uns hier auf ein Format für die Airbus-Familie geeinigt haben (die teilweise „lesenswert“ und „exzellent“ sind), bin ich gerne bereit innerhalb der Airbus-Familie sämtliche Tabellen auf ein einheitliches Format zu bringen. MfG, Harry Canyon (Diskussion) 15:58, 26. Jun. 2014 (CEST)

"weil mir das besser gefällt" entnehme ich aus "Da ich den Trennstrich etwas zu fett finde, möchte ich stattdessen gerne einen dünneren Trennstrich".

Wann es Zeilenumbrüche gibt, ist (auch) abhängig von der Bildschirmbreite.

"auf ein einheitliches Format geeinigt" haben sich die WP-Autoren beim Erstellen der CSS-Klassen. Eine kleine Gruppe Luftfahrtjünger meint es in den Airbus- und Boeing-Artikeln besser zu wissen (ich hab' nicht geprüft, welche Artikel alle so sind). Vielleicht ist die (orange-)farbliche Absetzung auch tatsächlich besser, das sollte dann aber bei den Tabellenvorlagen (wikitable, prettytable usw.) besprochen werden.

--arilou (Diskussion) 09:26, 30. Jun. 2014 (CEST)

border-color

Kann man das auch einfacher machen, ohne dass man so viel schreiben muss? In CSS könnte man ja einfach den td-Elementen der Tabelle die Eigenschaft zuordnen. Aber wie geht das hier in der Wikipedia? --Jobu0101 (Diskussion) 15:24, 11. Jul. 2014 (CEST)

Nein, das geht hier nicht, das müsste wenn dann über die allgemeine CSS erfolgen. Was Sonderformatierungen von Tabellen angeht, sind die Berechtigten hier sehr zurückhaltend; ich wollte kürzlich mal Spaltenausrichtung einbringen, sogar das wurde abgelehnt... Vielleicht wäre es sinnvoll, die betroffene Tabelle eher als Bild einzubinden, denn eigentlich ist es ja eher ein Diagramm denn eine Tabelle. --Sepp (Diskussion) 10:43, 14. Jul. 2014 (CEST)

Bei sich ggf. in Zukunft ändernden Diagrammen würde ich .svg vorschlagen, das lässt sich auch nachträglich leicht mit einem Texteditor überarbeiten, und ist scharf, egal bei welcher Auflösung.

Was sich nicht mehr ändert, kann natürlich ein Pixelformat bleiben, .png zum Beispiel.

--arilou (Diskussion) 16:47, 14. Jul. 2014 (CEST)

SVG ist auf jeden Fall das Format der Wahl; leider wandelt Wikipedia nach wie vor jedes Bild zu einem png um, aus Rücksicht auf Uraltbrowser mit minimalen Marktanteilen... ): --Sepp (Diskussion) 09:08, 15. Jul. 2014 (CEST)

Das stimmt für die Standardeinstellung, man kann dies als angemeldeter Nutzer aber abschalten. Ich finde leider nicht mehr den Beitrag in dem der Code-Schnippsel angegeben wurde. --Cepheiden (Diskussion) 20:22, 15. Jul. 2014 (CEST)

Wie bekomme ich hier denn die Überschrift schwarz? Im Code steht <b style="color:black;>Filme pro Jahr aus den Top 250</b>, jedoch schmeißt er das css-Statement raus, daher bleibt sie weiß und unsichtbar. --Jobu0101 (Diskussion) 15:30, 16. Jul. 2014 (CEST)

Da fehlt ein doppeltes Anführungszeichen, so geht es: <b style="color:black;">Filme pro Jahr aus den Top 250</b>. --Ajv39 (Diskussion) 15:50, 16. Jul. 2014 (CEST)

Tatsächlich, danke. --Jobu0101 (Diskussion) 16:05, 16. Jul. 2014 (CEST)

Gleiche Spaltenbreite

Hallo! Könnte mir bitte jemand erklären, wie ich auf die gleiche Spaltenbreite für die Angaben von den Modellen A350-800, A350-900, A350-900R, A350-900F und A350-1000 komme? MfG, Harry Canyon (Diskussion) 17:54, 25. Jun. 2014 (CEST)

Airbus A350 XWB

Kenngröße	A350-800	A350-900	A350-900R	A350-900F	A350-1000
Erstflug	k. A.	14. Juni 2013	k. A.	k. A.	k. A.
Indienststellung	Mitte 2016	2. Halbjahr 2014	Mitte 2016	Mitte 2017	Mitte 2017
Länge	60,60 m	66,89 m			73,90 m
Flügelspannweite	64,74 m
Höhenleitwerkspannweite	19,29 m
Höhe	17,07–17,39 m (je nach Gewicht und Schwerpunkt)
Rumpfbreite	5,96 m
Rumpfhöhe	6,09 m
Max. Kabinenbreite	5,61 m
Flügelfläche	443 m²
Flügelpfeilung (t/4-Linie)	innen 31,9°, Mitte 35°
Leergewicht	k. A.	115,7 t	k. A.
Maximales Startgewicht	259 t (Option 248 t)	268 t	298 t
Maximales Landegewicht	182,5 t	205,0 t	k. A.	k. A.	225,5 t
Treibstoffkapazität	129.000 l	138.000 l	k. A.	k. A.	156.000 l
Radstand	24,86 m	28,66 m	k. A.	k. A.	33,1 m
Spurweite	10,6 m
Passagierkapazität (3 Klassen)	270	314	314	k. A.	350
Max. Frachtkapazität	28 LD3 oder 9 Paletten	36 LD3 oder 11 LD7-Paletten	k. A.	zirka 90 t Fracht	44 LD3 oder 14 Paletten
Triebwerkstypen	Zwei Rolls-Royce Trent XWB Mantelstromtriebwerke
Schubkraft	2 × 351,5 kN (Option 2 × 330,5 kN)	2 × 374,5 kN	2 × 413,5 kN
Höchstgeschwindigkeit	Mach 0,89
Reisegeschwindigkeit	Mach 0,85 (ca. 910 km/h auf 11.000 m Reiseflughöhe)
Reichweite (mit typ. Passagierzahl)	15.860 km (Option 15.350 km)	15.000 km	zirka 17.600 km	über 9.250 km	14.800 km
Dienstgipfelhöhe	43.000 Fuß (13.100 m)

Hallo Harry Canyon, das kannst du erreichen, indem du beispielsweise in den Zellen der obersten Zeile prozentuale Angaben über die anteilige Breite machst:

Airbus A350 XWB

Kenngröße	A350-800	A350-900	A350-900R	A350-900F	A350-1000

Die Summe sollte 100 % ergeben. --Wiegels „…“ 18:07, 25. Jun. 2014 (CEST)

Supi, vielen herzlichen Dank an Dich! MfG, Harry Canyon (Diskussion) 18:20, 25. Jun. 2014 (CEST)

Airbus A350 XWB

Kenngröße	A350-800	A350-900	A350-900R	A350-900F	A350-1000

Habe das Beispiel mal etwas verändert. Die Angabe, dass die Tabelle über die ganze Breite gehen sollte ist eigentlich überflüssig, bei Bedarf tut sie es sowieso. Weiterhin ist die Angabe einer Hintergrundfarbe für die Kopfzeile eigentlich nicht sinnvoll; Zellen, die als Tabellenkopf mittels „!“ gekennzeichnet sind, werden automatisch anders formatiert und es gibt (zumindest hier) keinen guten Grund, von dem Standard abzuweichen. --Sepp (Diskussion) 10:00, 26. Jun. 2014 (CEST)

In den weiteren Artikeln zur Airbus-Familie (bis auf den 380) wurden die Tabellenköpfe für die „Technische Daten“ farblich abgesetzt, selbiges findet sich beispielsweise auch bei der Boeing-Familie. Ich möchte dann doch nicht zu sehr in den Style eingreifen. Das der Parameter width="100%" nicht benötigt wird, ist natürlich praktisch. Danke Dir für den Tipp. MfG, Harry Canyon (Diskussion) 11:24, 26. Jun. 2014 (CEST)

Die Breitenangabe hatte ich nur zur Demonstration hinzugefügt, um zu zeigen, wie die Spaltenbreiten der (bei mir leeren) Tabelle bei voller Ausdehnung aussehen würden. Ich hätte dazuschreiben sollen, dass man das wieder weglassen kann. --Wiegels „…“ 11:29, 26. Jun. 2014 (CEST)

Nun würde ich gerne noch zwischen den Spalten „Kenngröße“ und den nachfolgenden Modellen (A350-800, A350-900, …) noch einen etwas fetteren Trennstrich einfügen, was dann auch den leidigen Doppelpunkt in der ersten Spalte (der oft vorkommt) überflüssig machen würde. Wie ich der umseitigen Hilfe entnehme geht das wohl mit dem Befehl style="border-right:medium solid". Da ich den Trennstrich etwas zu fett finde, möchte ich stattdessen gerne einen dünneren Trennstrich mittels style="border-right:1px solid" bzw. style="border-right:2px solid" einfügen (je nachdem was üblicher ist?), was dann mit 1px so aussehen würde.

Airbus A350 XWB

Kenngröße	A350-800	A350-900	A350-900R	A350-900F	A350-1000

Allerdings muss ich wohl für jede Zeile style="border-right:1px solid" angeben, oder gibt es eine elegantere Lösung? MfG, Harry Canyon (Diskussion) 12:07, 26. Jun. 2014 (CEST)

Die eleganteste Lösung wäre wohl, diese Zellen einfach als Tabellenkopf zu definieren, denn nichts anderes sind sie ja in diesem Fall auch. Hier sieht man dann auch schön, warum die individuelle Farbwahl ein Problem ist. Hier die Tabelle wie sie mit Deiner Farbwahl aussehen würde:

Airbus A350 XWB

Kenngröße	A350-800	A350-900	A350-900R	A350-900F	A350-1000
erste KG	foo	bar	...	...	...
zweite KG	boo	far	...	...	...

Nun harmonieren die Farben überhaupt nicht mehr, also muss die Hintergrundfarbe schon wieder in jeder Zeile definiert werden. Hingegen ordentlich gemacht:

Airbus A350 XWB

Kenngröße	A350-800	A350-900	A350-900R	A350-900F	A350-1000
erste KG	foo	bar	...	...	...
zweite KG	boo	far	...	...	...

sieht das alles schon viel besser aus. Wenn Du eine gute Begründung (außer ist in einem ähnlichen Artikel auch so) hast, warum der Tabellenkopf farbig sein sollte, kannst Du ihn so lassen, aber ansonsten ist es sinnvoller, diese überflüssige Farbe (eventuell nach und nach) aus allen Artikeln zu streichen – der Ist-Zustand spielt keine Rolle. Sinnlose Farbverwendung ist ein Designfehler – Rechtschreibfehler lässt man ja auch nicht drin, weil sie auch woanders zu finden sind... (;

Ein abschließender Hinweis noch: |+ sollte immer vor der Definition der ersten Spalte per |- kommen (siehe Quellcode). --Sepp (Diskussion) 15:29, 27. Jun. 2014 (CEST)

Ich bin auch kein Freund von Farbspielereien, auf den Inhalt kommt es letztendlich an. Vielen Dank für eure hilfreichen Tipps! Gruß, Harry Canyon (Diskussion) 22:18, 28. Jul. 2014 (CEST)

P.S. Was genau meinst mit „|+ sollte immer vor der Definition der ersten Spalte per |- kommen“? Aus dem Quellcode kann ich nicht wirklich den Unterschied von meinem ersten Muster und deinem letzten Beispiel erkennen. Könntest du noch mal kurz erklärend mit einem Beispiel darauf eingehen? Gruß, Harry Canyon (Diskussion) 22:30, 28. Jul. 2014 (CEST)

Hallo, gemeint war wohl erste Zeile, nicht erste Spalte. Es geht um die zweite und dritte Quelltextzeile deiner ersten Tabelle ganz oben im Abschnitt. Die zweite Zeile (beginnend mit |-) beschreibt das Aussehen der Zeile mit den Spaltenüberschriften und die dritte Zeile (beginnend mit |+) bezeichnet den Tabellentitel, der, falls angegeben, über der Tabelle steht. Diese Elemente werden also in anderer Reihenfolge dargestellt, als sie definiert werden. Es funktioniert hier zwar so, aber sinnvoller ist es andersrum. --Wiegels „…“ 22:44, 28. Jul. 2014 (CEST)

Verstehe! Danke dir und wünsche noch einen schönen Abend, Harry Canyon (Diskussion) 22:57, 28. Jul. 2014 (CEST)

Problem mit Tabelle

Man betrachte die Tabelle bei Austragungen. Im Firefox wird bei mir über Matthias Opdenhövel kein Trennstrich angezeigt. Im Chrome fehlt die Umrandung des noch freien Kastens für die letzte Zeile in den letzten drei (bislang noch leeren) Spalten. Wie kommt das und was kann man dagegen tun? --Jobu0101 (Diskussion) 18:43, 2. Okt. 2014 (CEST)

Hallo Jobu0101, die letzte drei Spalten überspannende Zelle der Tabelle habe ich durch Einfügen einer leeren Zelle für Chrome sichtbar gemacht. Die fehlende Randlinie kann ich im Firefox nachvollziehen. Dahinter vermute ich einen Rechen-/Rundungsfehler des Browsers. Ähnliche Effekte kann man beobachten, wenn man die Schriftgröße ändert. --Wiegels „…“ 20:42, 2. Okt. 2014 (CEST)

Das RowSpan musste angepasst werden. LG, ℳ웃79 ^✍ 23:01, 2. Okt. 2014 (CEST)

Liste der Schweizer Bundespräsidenten

Hallo allerseits. Ich möchte gerne die vierte und achte Spalte (Partei) in allen sieben Tabellen gleich breit haben. Habe es mit Auffüllen mit {{0}} versucht, was mich aber nicht zufriedenstellt . Am Besten ersichtlich ist der Unterschied bei diesem Abschnitt. Danke für eure Rückmeldungen und die Bemühungen. Viele Grüße, Verschiedenes (Diskussion) 22:19, 7. Okt. 2014 (CEST)
Erledigt mit weiteren Verbesserungen. LG KontrollstelleKundl 10:44, 8. Okt. 2014 (CEST)

Super, vielen Dank! Beste Grüße, Verschiedenes (Diskussion) 11:31, 8. Okt. 2014 (CEST)

Import von Writer-Tabellen

Ich bin mir nicht sicher, wo dieser Hinweis eingeordnet werden soll oder ob es ihn schon gibt. Deswegen schreibe ich hier auf der Diskussionsseite.

Wenn man nur den Zeileninhalt einer Office-Tabelle in Wiki-Syntax bringen will, geht das schnell und einfach in zwei Schritten.

• Befehl Tabelle in Text, wobei das Trennzeichen nicht im Text vorkommen darf
• Drei "Suchen und Ersetzen" - Durchläufen:

1. Suchen nach: Trennzeichen...Ersetzen durch: || (Leerzeichen-Hochstrich-Hochstrich-Leerzeichen)
2. Suchen nach: ^. (Hütchen-Punkt)...Ersetzen durch: | & (Hochstrich-Leerzeichen-Und)
3. Suchen nach: .$ (Punkt-Dollar)...Ersetzen durch: &\n|- (Und-Backslash-n-Hochstrich-Minus)

Bei 2.+3. muss "Regulärer Ausdruck" markiert sein. Man erhält dann einen Block der Form

| Z1S1 || Z1S2 || Z1S3
|-
| Z2S1 || Z2S2 || Z2S3
|-
| Z3S1 usw.

und kann ihn beliebig einfügen.

--Thunderdan81 (Diskussion) 17:54, 29. Aug. 2014 (CEST)

Noch einfacher geht’s mit Konvertern, kannst z. B. aus Writer direkt in die Wikimedia speichern. LG, ℳ웃79 ^✍ 11:53, 25. Okt. 2014 (CEST)

Spalten hinzufügen

Überschrift
Spalte 1	Spalte 2

Hallo. Wie kann ich bei dieser Tabelle weitere Spalten hinzufügen? Die Tabelle soll zuerst eine Spalte ohne Unterteilung haben. Dann so wie im Beispiel, eine Überschrift und zwei Spalten darunter und daneben noch eine dritte Spalte mit einer Überschrift und 3 Spalten darunter. Geht das? --master-davinci (Diskussion) 15:15, 4. Nov. 2014 (CET)

Hallo Master-davinci, meinst du eine solche Tabelle? --Wiegels „…“ 15:36, 4. Nov. 2014 (CET)

Spalte 0	Überschrift 1		Überschrift 2
	Spalte 1a	Spalte 1b	Spalte 2a	Spalte 2b	Spalte 2c

Danke für die Hilfe. Ich habe es mal ein bischen mit Leben gefüllt. Wie kann ich aber nun den oberen Teil als Überschrift abgrenzen? Also alles was neben "Jahr" steht, gehört zur Überschrift. Unten neben 2013 sind die Werte. Kann man vieleicht eine dicke Linie ziehen oder den oberen Teil farbig machen? --master-davinci (Diskussion) 17:33, 4. Nov. 2014 (CET)

Jahr	Ausgeschrieben		Gewonnen
	Anzahl	Mio TrKm	Anzahl	Mio TrKm	%
2013	30	108	20	81	75

Die Kennzeichnung von Tabellenzellen als Überschriften passiert in unserer Wiki-Syntax mit dem Ausrufezeichen. Zusätzlich kannst du sie beispielsweise noch farblich gestalten, etwa wie folgt (aber bitte sparsam und dezent). --Wiegels „…“ 17:49, 4. Nov. 2014 (CET)

Jahr	Ausgeschrieben		Gewonnen
	Anzahl	Mio TrKm	Anzahl	Mio TrKm	%
2013	30	108	20	81	75

"Tabellen im Schreibmaschinenstil"

Ich kann mich nicht erinnern, eine Tabelle in diesem Stil in einem Artikel gesehen zu haben. Vielleicht sollte man diese Variante angesichts ihrer Nachteile gar nicht aufführen? Gestumblindi 00:00, 5. Nov. 2014 (CET)

Ooch, das steht seit uralten Zeiten da drin. Die Idee ist vermutlich, dass Newbies erstmal auf einfache Weise eine kleine Tabelle hineinkriegen, und der nächste Syntaxerfahrene macht was Richtiges draus.

Was das nicht-gesehen-haben angeht: Ich kann mich erinnern, dass ich sowas zwei- oder dreimal gesehen hatte, und es dann umgehend umgestrickt hatte. Das war dann Ursache dafür, dass das nach mir keiner mehr zu Gesicht bekam. Kommt alle paar Jahre mal vor.

LG --PerfektesChaos 01:19, 5. Nov. 2014 (CET)

Nunja, aber wenn nun offenbar auch die Newbies so gut wie nie eine derartige Tabelle kreieren...? Gestumblindi 01:22, 5. Nov. 2014 (CET)

Weißt du doch gar nicht, wie lange die drinbleiben und was die Abteilung mit dem verpönten Namen „Vollprogramm“ daraus macht? Ich bin da nicht tätig, finde die nur zufällig mal im Bestand. Ich würd hier nix ändern. Niedrigschwelliger Einstieg und so. LG --PerfektesChaos 01:28, 5. Nov. 2014 (CET)

Machen wir ein Meinungsbild! ;-) Nein... es ist mir ja kein wahnsinniges Anliegen, war nur so ein Gedanke, lassen wir's ruhig. Schaden kann's ja nicht. Gestumblindi 01:33, 5. Nov. 2014 (CET)

@Gestumblindi: Nachtrag, weil mir grad diese Minuten unterkommend und keine zwei Stunden alt.

• Ich habe auch schon ein halbes Dutzend Tabellen dieser Art in Wikitext umgeschrieben und dann die Grafik löschen lassen.
• Bei Newbies dieser Art ein völlig normaler Vorgang.

Mahlzeit --PerfektesChaos 13:30, 5. Nov. 2014 (CET)

Artikel Aalen - Tabellenfehler

Im Artikel gibt es derzeit folgende Tabelle, die allerdings bei Klick auf sortieren falsch sortiert:

Ortschaft	Wappen 1	Fläche in km2	Einwohner (1. Mai 2014)	Teilorte
Aalen (Kernstadt)		20,858	25.928	Himmlingen, Hirschhof
Dewangen		16,533	3.190	Aushof, Bernhardsdorf, Bronnenhäusle, Bubenrain, Degenhof, Dreherhof, Faulherrnhof, Freudenhöfle, Gobühl, Großdölzerhof, Haldenhaus, Hüttenhöfe, Kleindölzerhof, Kohlhöfle, Langenhalde, Lusthof, Neuhof, Rauburr, Reichenbach, Riegelhof, Rodamsdörfle, Rotsold, Schafhof, Schultheißenhöfle, Streithöfle, Tannenhof, Trübenreute
Ebnat		21,161	3.340	Affalterwang, Diepertsbuch, Niesitz
Fachsenfeld		3,950	3.549	Bodenbach, Frankeneich, Hangendenbuch, Himmlingsweiler, Mühlhäusle, Sanzenbach, Scherrenmühle, Spitzschafhaus, Steinfurt, Waiblingen
Hofen		12,583	2.076	Attenhofen, Fürsitz, Goldshöfe, Heimatsmühle, Kellerhaus, Oberalfingen, Wagenrain
Unterkochen		21,444	4.954	Birkhof, Glashütte, Klause, Neukochen, Neuziegelhütte, Pulvermühle, Stefansweilermühle
Unterrombach/ Hofherrnweiler		9,757	9.105	Hahnenberg, Hammerstadt, Hofherrnweiler, Lauchhof, Mädle, Mantelhof, Neßlau, Oberrombach, Pompelhof, Rauental, Sandberg, Sauerbachhof, Schwalbenhof, Sofienhof, Vogelsang
Waldhausen		24,375	2.309	Arlesberg, Bernlohe, Beuren, Brastelburg, Geiselwang, Hohenberg, Neubau, Simmisweiler
Wasseralfingen		15,965	11.761	Affalterried, Brausenried, Erzhäusle, Heisenberg, Mäderhof, Onatsfeld, Rötenberg, Röthardt, Treppach, Weidenfeld

Kann hier mir bitte ein fachlicher Rat gegeben werden? Was stimmt nicht? Danke im voraus und Grüße,--MitigationMeasure (Diskussion) 15:22, 24. Nov. 2014 (CET)

Es gibt drei Möglichkeiten, wie es funktioniert:

1. Überall stehen nur Zahlen, kein ref-Kram.
2. Zu jeder Zahl ist ein Sortierschlüssel angegeben (veraltet, unerwünscht).
3. Man gibt der Überschriftenzelle das Attribut data-sort-type="number" (was ich oben nachgeholt habe; siehe auch umseitig).

Ist das nicht der Fall, werden die mit ref gemischten Werte lexikalisch sortiert, also etwas, das mit „1“ anfängt, kommt vor etwas, das mit „2“ anfängt, und danach etwas, das mit „3“ anfängt.

HGZH --PerfektesChaos 15:40, 24. Nov. 2014 (CET)

Vielen herzlichen Dank! Jetzt brauchte es nur noch einen Admin, der das einbaut - oder bis 25. November muss ich halt zuwarten... Nochmals danke! Grüße,--MitigationMeasure (Diskussion) 16:17, 24. Nov. 2014 (CET)

Nur des Auszuges wegen:

und Schluss. --MitigationMeasure (Diskussion) 00:21, 26. Nov. 2014 (CET)

Nochmal Artikel Aalen

Nochmal danke für die Hilfe. Nun ist ein Kollege wieder fix fertig. Er ist der Meinung, dass die gemischte Sortierung, zudem mit , mittig zentriert, folgender tags bedarf (nur als ein herausgezogenes Beispiel): 20,858<span style="position:absolute"><ref>[//www.aalen.de/sixcms/detail.php?id=16866 ''Flächen nach der tatsächlichen Nutzung in der Kernstadt''], auf: aalen.de, abgerufen am 25. November 2014.</ref></span> darzustellen sei. Wie ist die Meinung? Das muss doch einfacher gehen, oder irre ich mich? Gruß,--MitigationMeasure (Diskussion) 00:19, 26. Nov. 2014 (CET)

• Ach, deswegen die Sperre.
• Ich finde euer beider Hantieren per BK und Edit-War nicht gut und möchte, dass ihr das auf einer Disku austragt; ggf. gleich hier, weil es wenig mit der Stadt Aalen zu tun hat, sondern eine Syntax-Angelegenheit ist.
  • Nebenbei bemerkt ist Benutzer:Fomafix sehr sattelfest in Syntaxfragen und Wiki-Software und hat dort langjährige Erfahrungen.
• position:absolute möchte ich im ANR nicht zu sehen bekommen.
  • Motivation ist offenkundig, trotz ein-und zweistelliger ref-Nummern die Zahlenposition fluchtend zu bekommen; also Dezimal-/Tausendertrenner.
• Ich möchte das vielmehr linksbündig haben (Normalzustand, keine Extra-Anweisung) und mit führender {{0}} für die vierstelligen wie bei sehr vielen anderen Tabellen mit ähnlicher Problematik.
  • Statt eines langwierigen padding-left können dann auch sämtliche Zellen ein {{0|000}} erhalten; die vierstelligen dann eben eine 0 mehr.
• Die Artikel sollen sich mit enzyklopädischen Fragen befassen und der Quelltext noch übersichtlich, knapp und verständlich bleiben, und nicht mit Syntax-Dekoration überladen werden, die nur ein halbes Dutzend Leute in diesem Projekt nachvollziehen können.
• Übrigens sehe ich da nichts von „zudem mittig zentriert“: ich finde nur rechtsbündig mit entsprechendem padding.

VG --PerfektesChaos 09:45, 26. Nov. 2014 (CET)

Wir können gerne diskutieren. Aber bitte erst diskutieren und eine funktionierende Lösung erstellen und dann den Artikel ändern und dabei keine weiteren Syntaxfehler einstellen.

Statt style="position:absolute" kann auch ein anderer CSS-Trick verwendet werden, wie style="display:inline-block; width:0"

Mit {{0}} davor wird ein Abstand der Breite von der 0 erzeugt. Nicht bei jeder Schriftart haben die Ziffern exakt die gleiche Breite. Ich finde diese manuelle Einrückung anhand der Anzahl der Dezimalstellen nicht Autorenfreundlich, denn diese müssen neben den Flächen- und Einwohnerzahlen zusätzlich die Anzahl der Stellen angeben. Außerdem muss diese Funktion erst mit der Sortierung geprüft werden und mit jeder Softwareänderung wieder überprüft werden, da an der Sortierfunktion immer wieder etwas geändert wird. --Fomafix (Diskussion) 10:05, 26. Nov. 2014 (CET)

• Dass {{0}} nicht immer exakt breit mit jeder Ziffer ist, weiß ich auch; eine diesbezügiche Falschbehauptung habe ich neulich aus deren Vorlagendoku entfernt.
  • Es ist aber ein verträglicher Kompromiss, der der Optik eines kurz über diese Tabelle huschenden Lesers keinen Knick bereitet. So fundamental für das Verständnis des Artikels ist diese Tabelle nun auch wieder nicht.
  • Nebenbei gilt das identische Argument auch für die Position des Dezimaltrenners; eigentlich müsste dieser fluchtend angeordnet werden. Macht er aber nicht zwangsläufig, weil die drei Nachkommastellen theoretisch unterschiedliche Breiten haben können und erst diese rechtsbündig ausgerichtet werden.
  • Tatsächlich haben bei den gängigen in Browsern genutzten Schriften die Ziffern gleiche oder fast gleiche Breite, so dass dies Tabellenziffern schon sehr nahe kommt.
• „nicht Autorenfreundlich“ – also, wenn etwas maximal autorenunfreundlich ist, dann ist es, jede einzelne Zahl mit dem nachstehenden zusätzlichen Syntaxwust zu dekorieren:

  style="text-align:right; padding-right:2.5em" | <span style="position:absolute"></span>

• Demgegenüber ist das von mir oben empfohlene {{0|000}} und manchmal {{0|0000}} optisch hinreichend sauber und sehr viel autorenschonender.

LG --PerfektesChaos 11:03, 26. Nov. 2014 (CET)

Das ist Ansichtssache. Die Formatierung wird einmal eingerichtet und kann dann dauerhaft bestehen. Die Zahlen sollten theoretisch monatlich aktualisiert werden. Wenn da mal eine Dezimalstelle dazu- oder wegkommt, dann wird das Anpassen der Nullen leicht übersehen. Außerdem kann es einfacher automatisiert werden, wenn nur die Zahl eingeführt werden muss. Auch für Nutzer des VisualEditors müsse es besser sein, wenn hier nicht noch zusätzlich die Anzahl der Nullen angepasst werden müssen. --Fomafix (Diskussion) 13:32, 26. Nov. 2014 (CET)

Statt

style="text-align:right; padding-right:2.5em" | 1234<span style="position:absolute"><ref /></span>

kann auch

style="text-align:right;" | 1234<span style="display:inline-block; width:2em; text-align:left"><ref /></span>

verwendet werden:

Ortschaft	Wappen 1	Fläche in km2	Einwohner (1. September 2014)	Teilorte
Aalen (Kernstadt)		20,858	25.938	Himmlingen, Hirschhof
Dewangen		16,533	3.179	Aushof, Bernhardsdorf, Bronnenhäusle, Bubenrain, Degenhof, Dreherhof, Faulherrnhof, Freudenhöfle, Gobühl, Großdölzerhof, Haldenhaus, Hüttenhöfe, Kleindölzerhof, Kohlhöfle, Langenhalde, Lusthof, Neuhof, Rauburr, Reichenbach, Riegelhof, Rodamsdörfle, Rotsold, Schafhof, Schultheißenhöfle, Streithöfle, Tannenhof, Trübenreute
Ebnat		21,161	3.355	Affalterwang, Diepertsbuch, Niesitz
Fachsenfeld		3,950	3.565	Bodenbach, Frankeneich, Hangendenbuch, Himmlingsweiler, Mühlhäusle, Sanzenbach, Scherrenmühle, Spitzschafhaus, Steinfurt, Waiblingen
Hofen		12,583	2.072	Attenhofen, Fürsitz, Goldshöfe, Heimatsmühle, Kellerhaus, Oberalfingen, Wagenrain
Unterkochen		21,444	4.963	Birkhof, Glashütte, Klause, Neukochen, Neuziegelhütte, Pulvermühle, Stefansweilermühle
Unterrombach/ Hofherrnweiler		9,757	9.102	Hahnenberg, Hammerstadt, Hofherrnweiler, Lauchhof, Mädle, Mantelhof, Neßlau, Oberrombach, Pompelhof, Rauental, Sandberg, Sauerbachhof, Schwalbenhof, Sofienhof, Vogelsang
Waldhausen		24,375	2.314	Arlesberg, Bernlohe, Beuren, Brastelburg, Geiselwang, Hohenberg, Neubau, Simmisweiler
Wasseralfingen		15,965	11.760	Affalterried, Brausenried, Erzhäusle, Heisenberg, Mäderhof, Onatsfeld, Rötenberg, Röthardt, Treppach, Weidenfeld

--Fomafix (Diskussion) 13:54, 26. Nov. 2014 (CET)

• Gerade für jemanden, der wohl eher halbjährlich mal Einwohnerzahlen aktualisieren soll, ist es ein Horror, dazwischen noch eine Zahl wiederzufinden.
• Ob da mal eine Null fehlt, weil die Einwohnerzahl eines Ortsteils urplötzlich von 3.000 auf über 10.000 explodiert sei, bekäme man ab diesem seltenen Jubeltag in der Vorschau bald mit.
• Die Alternative ist für den ANR und die 18-fache Verwendung genauso inakzeptabel wie die vorige Lösung.
• Derartige Syntaxdesaster haben nichts im ANR verloren. Von mir aus kannst du eine Vorlage schreiben für eine solche Ausrichtung auf ein halbes Pixel genau, aber mach diesen Brei weg, den allenfalls eine Handvoll Spezialisten dieses Projektes mit Mühen nachvollziehen könnte.
• Unkommentierte „CSS-Tricks“ereien haben ohnehin im ANR nichts zu suchen. Wer soll denn bloß begreifen, was du da anstellst? Der Eröffner dieses Threads war schon offenkundig überfordert, obwohl sich systematisch mit Syntax beschäftigend.
• Oder macht je eine eigene Tabellenspalte nur für das ref auf; aber ohne zellenweises Syntaxdrama. Dann kann auch der sort-type wieder aus dem Tabellenkopf raus.
• So wie es jetzt ist, kann und wird es jedenfalls nicht auf Dauer bleiben.

VG --PerfektesChaos 20:52, 27. Nov. 2014 (CET)

Ich bin nicht der einzige, der hier die Einwohnerzahlen aktualisiert. Autoren hatten hier keine Probleme.

Du kannst gerne probieren eine universelle Vorlage zu erstellen, die für die Tabellenausrichtung mit Einzelnachweise sorgt. Meiner Meinung nach vereinfachen solche Vorlagen aber die Bearbeitung nicht immer.

Gehören Tabelle überhaupt in den Artikelnamensraum? Die Syntax ist da für viele Benutzer bereits eine Herausforderung.

Wenn man CSS in Tabellen verbieten wollte, dann würden viele Tabellen sehr kahl und dürftig aussehen. Dieses Beispiel hier ist da eher harmlos.

Sauber wäre es, wenn Inhalt und Formatierung klar getrennt wäre. Die Zahlen gehören in eine Datenbank und über eine Transformation wird die Darstellung erzeugt.

Die Darstellung verschlechtern, nur weil jemand die Syntax nicht gefällt? Wo bleibt denn da der Leser?

--Fomafix (Diskussion) 23:42, 27. Nov. 2014 (CET)

Na ja, Moment: „Das Bessere ist noch immer der Feind des Guten.“

Ich hatte dir, Fomafix, schon lange (während des EW) den Vorschlag unterbreitet, das "ref" in eine eigene Spalte auszulagern, natürlich "unsortable", den Rest nach den Hilfeseiten anzupassen und den padding-Kram auch 'rauszuschmeißen, weil das eigentlich "trallala" ist: Letztlich schreckt es aber einen Bearbeiter ab, sich mit der Tabelle zu beschäftigen und ggf. vernünftige Erweiterungen anzulegen.

Diese Art von "Herrschaftswissen" hindert hier, wie an vielen anderen Stellen (betrifft ja nicht nur dich, sondern Bearbeiter, die seit Jahren sich inzwischen abgemeldet haben, aber ihre Überreste in noch ganz anderen Tabellen hinterlassen haben) die Umsetzung nötiger Aktualisierungen, weil motivierte, aber syntaktisch beim besten Willen nicht Bewanderte (man denke an Neu-Wikipedianer) eigentlich nur sich händehebend zurückziehen und dann der "syntaktische Mist" unbearbeitet weiter liegen bleibt (und die nötige Aktualisierung gleich mit) - und das kann es ja wohl auch nicht sein für eine "zukunftsfähige de:WP".

Gebe ich dir einfach mal zu bedenken. Grüße,--MitigationMeasure (Diskussion) 00:23, 28. Nov. 2014 (CET)