Hilfe Diskussion:Tabellen/Archiv/2022

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

oder als Weblink zur Verlinkung außerhalb der Wikipedia

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

Überschriften

Ist es eigentlich irgendwie möglich, Überschriften in 'Eine Tabelle einzufügen, die dann auch im Artikel-Inhaltsverzeichnis angezeigt werden? [1] 2003:E7:B719:709F:2CBF:91CB:1B3A:2B16 09:13, 25. Jan. 2022 (CET)

Möglich ist das, man sollte darauf aber verzichten, da es die Abschnittsbearbeitung verkompliziert. Wenn man neben einer Abschnittsüberschrift auf [Bearbeiten] klickt und plötzlich mitten zwischen Tabellensyntax landet, dann kann die Auswirkung einer Änderung zum einen nicht überprüft werden (beispielsweise zerstörte Darstellung, weil etwas falsch eingefügt wurde) und zum anderen sieht man unter Umständen in der Vorschau nur merkwürdige Syntaxkonstrukte und keine Tabelle mehr, weil sich die umschließende Tabellensyntax (H:Tabellen/Wikisyntax#Elemente) außerhalb des Abschnitts befindet.

Ich würde dringend davon abraten so etwas zu tun. Es erhöht die Fehleranfälligkeit. --Liebe Grüße, Lómelinde Diskussion 10:11, 25. Jan. 2022 (CET)

Vorlage:Tabellenstile statt mw-datatable

Wo wurde das wieder beschlossen? Es ist eine ganz schlechte Lösung, zusätzlich auch noch eine Vorlage einbinden zu müssen. Wir sollten weniger, nicht mehr Vorlagen nutzen und es ist stets besser, wenn Funktionen bereits softwareseitig unterstützt werden. Das ist nun ein großer Rückschritt. mw-datatable hat bisher prima funktioniert, warum wurde das geändert und warum wurde dafür kein Konsens gesucht? -- Chaddy · D 17:12, 20. Mär. 2022 (CET)

MediaWiki hatte mitgeteit, dass dies deren private Klasse und deren eigenes Design ist, das sie niemals zur Verwendung durch die lokalen Projekte freigegeben hatten.

Die enWP hatte sich das wohl mal um 2012 abgeguckt und unter den Nagel gerissen, und irgendwer hatte sich das dort abgeguckt und hier bei uns Reklame dafür gemacht.

Nachdem es jetzt ein halbes Jahr überhaupt nicht möglich war, wurde es heute in unserer eigenen Lösung wieder verfügbar gemacht.

Du hast zwei Möglichkeiten: So verfahren wie dargestellt, oder es weiterhin bleiben lassen.

So ist das halt, wenn man sich undokumentierte Hacks abguckt.

Gegenfrage: Wann und wo wurde beschlossen, dass dies ein offizielles MediaWiki-Feature für die Projekte ist?

VG --PerfektesChaos 17:33, 20. Mär. 2022 (CET)

"Du hast zwei Möglichkeiten: So verfahren wie dargestellt, oder es weiterhin bleiben lassen." - Vielen Dank für deine mal wieder sehr erfrischende Selbstherrlichkeit. Selbstverständlich entscheidet die Community, ob diese Lösung sinnvoll ist.

Ich habe ja gar nicht unbedingt ein Problem mit der Lösung an sich. Aber diese Lösung sollte so ausgestaltet sein, dass die Vorlage:Tabellenstile überflüssig wird. Das funktioniert bei allen anderen Tabellenklassen ja auch. -- Chaddy · D 17:45, 20. Mär. 2022 (CET)

„funktioniert bei allen anderen Tabellenklassen ja auch“ – Das trifft so nicht zu.

Bei den offiziell für die Projekte unterstützten Tabellenklassen guckt MediaWiki (teils nur auf den Desktop-Skins) nach, ob sowas in der Inhaltsseite vorkommt, und liefert den Code nur dann aus, wenn das vorkommt und benötigt wird.

Genauso ist es mit dem mw-datatable – das gibt es nur noch auf Seiten, auf denen MediaWiki das für eigene Zwecke benutzt. mw- bedeutet, dass die Klasse MediaWiki „gehört“, und diese über die globale Verwendung bestimmen. Zukünftig (und auch jetzt schon) wird sich die Wirkung dieser Klasse ändern. Deshalb musste auch ein abweichender Name von uns gewählt werden.

Solltest du übrigens auf Benutzerseiten noch prettytable verwenden, hätte ich gleich die nächste bittere Pille – die ist seit ca. 2008 veraltet und wird eines Tages auch nicht mehr unterstützt werden, sondern ist am schlauesten durch wikitable zu ersetzen. Oder, Notlösung, Vorlage:Tabellenstile einbinden.

Ganz grundsätzlich bekommen Seiten schon seit einem Dutzend Jahren nicht mehr jede Ressource, so wie man das in unserem Krabbelalter mal gemacht hatte, sondern die paar Hundert oder auch mal Tausend Seiten, die unter 20 Millionen anderer Inhaltsseiten und unzähligen dynamischen Auswertungen in Spezialseiten oder Versionsgeschichten ein ganz bestimmtes Feature benötigen, müssen dieses explizit anfordern.

In unserer Kindergarten-Ära hatte es mal eine Handvoll Klassen und ein Dutzend Skriptfunktionen gegeben; dies geht heutzutage in die Zehntausende und die Seiten werden nicht mehr handhabbar, wenn wie früher überall jeder Code geladen und ausgeführt und jede Seite nach allem Erdenklichen durchsucht werden muss.

VG --PerfektesChaos 18:09, 20. Mär. 2022 (CET)

Prettytable verwende ich nicht. Ich war damals in den 2000ern sogar engagiert mit dabei, im ANR prettytable durch wikitable zu ersetzen.

Wenn das alles so unwartbar sein soll, dann ist es aber doch besser, ganz darauf zu verzichten, statt solche Basteleien zu erstellen. -- Chaddy · D 18:47, 20. Mär. 2022 (CET)

Es hat nur was damit zu tun, dass es zur Stunde ganze 2.019 ANR-Verwendungen unter 20 Millionen anderer Inhaltsseiten und unzähligen dynamisch generierten Seiten gibt.

Heißt: In einem von 10.000 Fällen kommt die Klasse vor; in 9.999 Fällen verbraucht der Browser die Ressourcen bei allen Lesenden bei jedem Abruf völlig umsonst (fast 99 % der Abrufe sind im ANR).

Deshalb wird schon seit einem Jahrzehnt sowas nur noch eingeführt, wenn es auch in dieser Situation benötigt wird; andernfalls werden alle Seiten irgendwann unbrauchbar, weil sie minutenlang sinnlose Suchen und Aktionen ausführen.

Statt hier Terz zu machen und unsere Zeit zu vergeuden, könntest du eher hoffen, dass ein mitlesender Bot-Betreiber nunmehr die bisherigen Verwendungen der Klasse umstellt und vor der ersten einschlägigen Tabelle die Vorlageneinbindung einfügt.

Das Feature war jetzt seit August 2021 nicht verfügbar, ohne dass die Welt unterging, und es ist auch kaum jemand aufgefallen. Die Tabellen waren immer noch lesbar.

VG --PerfektesChaos 19:02, 20. Mär. 2022 (CET)

Kritik als "Terz machen" abwerten ist mal wieder großartig.

Und ne, ich will ja gerade eben nicht, dass die Vorlage "Tabellenstile" verwendet wird. Wenn eine Erhaltung der Funktion nicht sinnvoll möglich ist, dann sollte sie besser ganz verschwinden. Wirklich nötig ist sie ja sowieso nicht. Ein besonders großer Zugewinn ist es nicht, wenn Tabellenzeilen beim drüberfahren hervorgehoben werden. -- Chaddy · D 19:20, 20. Mär. 2022 (CET)

Das ist deine private Ansicht. Andere Autoren sind anderer Auffassung, und irgendwer hatte diese 2019 ANR-Verwendungen verbaut und wollte gern, dass unübersichtliche Datentabellen mit vielen Spalten besser die Zusammengehörigkeit etwa der ersten Spalte mit der elften verdeutlichen.

Nun haben die deWP-Techies sich die Mühe gemacht, unterstützen das ohne Nachteile für die zweieinhalb Millionen Artikel ohne solche Tabellen, und du bringst nichts Produktivres zustande außer kreuz und quer in alle Richtungen über alles zu meckern, und nichts ist dir recht. Wenn du es nicht haben willst, dann benutze es halt nicht. Das war eine der beiden Optionen, die ich dir oben angeboten hatte. Und wenn es dir eh völlig egal ist, dann bist du nicht dazu befugt, deine Privatmeinung denjenigen vorzuschreiben, die sowas gern haben möchten.

--PerfektesChaos 20:02, 20. Mär. 2022 (CET)

Es muss überhaupt nicht sein, eine Diskussion über Tabellen derartig zu emotionalisieren und direkt persönlich zu werden. Das fällt auch letztlich auf dich selbst zurück. Also versuche es bitte nochmal in freundlich. -- Chaddy · D 02:59, 21. Mär. 2022 (CET)

In einer idealen MediaWiki-Welt würden diese Stildefinitionen, wie beschrieben, geladen werden, sobald sie im Quelltext vorkommen. Derartige Verbesserungen für Leser unmittelbar am Inhalt sind aber keine Priorität der WMF-Softwareabteilung, sodass leider jedes Projekt sein eigenes Süppchen kochen muss (bspw. auch enwiki mit einer ähnlichen Vorlage). Die Lösung mit Vorlage:Tabellenstile ist nun leider keine optimale, aber immerhin besser als die alte mw-datatable, die bspw. auf Mobilgeräten gar nicht funktionierte.

Und nachgefragt war diese Funktion schon, und ich sehe grundsätzlich auch einen sinnvollen Anwendungsfall. Gruß, -- hgzh 14:58, 21. Mär. 2022 (CET)

Text Bild Text

Ich bearbeite gerade folgenden Artikel First Lord of the Admiralty und bei der Spalte König/Königin habe ich das Problem, dass ich den Namen, das Sigel und die Jahreszahl, ab Victoria einfach nicht untereinander bekomme so wie bei den anderen darüber.--Mr.Lovecraft (Diskussion) 12:12, 24. Mai 2022 (CEST)

Hallo Mr.Lovecraft, du kannst an diesen Stellen wie schon an den Stellen darüber feste Zeilenumbrüche (<br/>) einfügen. --Wiegels „…“ 12:38, 24. Mai 2022 (CEST)

Wieder was gelernt... Danke :-D --Mr.Lovecraft (Diskussion) 12:41, 24. Mai 2022 (CEST)

Schriftgröße

Coole Tools, Danke dafür. Erarbeite grade eine Tabelle für die Wikipedia:Formatvorlage Staat#Wirtschaft. Gibts eine Möglichkeit, innerhalb einer Zelle verschiedene Schriftgrößen zu haben? Würde gerne im Spaltentitel die Erläuterungen kleiner haben. Auch sonstige Tipps zur Tabelle sind willkommen. --Fah (Diskussion) 11:41, 16. Jun. 2022 (CEST)

{| class="wikitable"
! colspan="7"| Wirtschaftsdaten Cook-Inseln
|- style="vertical-align:top;"
! Parameter
! Primärer Sektor<br /><small>(Urproduktion)</small>
! Sekundärer Sektor<br /><small>(Verarbeitendes Gewerbe)</small>
! Tertiärer Sektor<br /><small>(Dienstleistungen)</small>
! Gesamt
! Bezugsjahr
! Quelle
|-
|
|
|
|
|
|
|
|}

Versuch es mal so. --Liebe Grüße, Lómelinde Diskussion 13:19, 16. Jun. 2022 (CEST)

Volle Kontrolle über die Schriftgröße hast du mit dem span-Tag: <span style="font-size:80%">Beispieltext</span>.

Allerdings sollte grundsätzlich auf solche Schriftverkleinerungen verzichtet werden, nur in Ausnahmefällen ist das sinnoll. Die verkleinerte Schrift ist nämlich nicht barrierefrei, Menschen mit Sehschwäche haben dann Probleme, den Text lesen zu können. -- Chaddy · D 14:00, 16. Jun. 2022 (CEST)

Diagonal geteilter Header

Hallo, im Artikel Mansische Sprache bin ich auf zahlreiche Tabellen gestoßen, deren Kopfzeile auf den ersten Blick etwas verwirrend ist, z.B.

Besitz		Singular	Dual	Plural
Besitzer
SG	1.	-m -əm	-ɣəm -aɣəm	-nəm -anəm
	2.	-n -ən	-ɣən -aɣən	-n(ən) -an(ən)
	3.	-te -e	-ɣe -aɣe	-ne -ane
DU	1.	-men	-ɣamen -aɣamen	-namen -anamen
	2.	-n -en	-ɣen -aɣen	-nen -anen
	3.	-ten -en	-ɣen -aɣen	-nen -anen
PL	1.	-w -uw	-ɣuw - aɣuw	-nuw - anuw
	2.	-n -en	-ɣen -aɣen	-nen -anen
	3.	-nəl -anəl	-ɣanəl -aɣanəl	-n(an)əl -an(an)əl

"Besitz" ist hier die Überschrift für die Spalten Singular, Dual und Plural, während "Besitzer" hier als Überschrift für die darunterfolgenden Zeilen SG 1./2./3., DU 1./2./3. und PL 1./2./3. gemeint ist. Hier wäre die englische Vorlage Template:Diagonal split header ideal statt der relativ unansehnlichen derzeitigen Lösung mit einer zweiten Header-Zeile und drei leeren Zellen rechts davon. Leider habe ich aber keine Vorlage in der deutschen Wikipedia hierzu gefunden. Gibt es hier etwas Passendes, um die Zelle links oben diagonal zu teilen? Ich freue mich auf eure Rückmeldungen. Liebe Grüße, --Hanzlan (Diskussion) 22:03, 24. Jul. 2022 (CEST)

Besitz Besitzer		Singular	Dual	Plural
SG	1.	-m -əm	-ɣəm -aɣəm	-nəm -anəm
	2.	-n -ən	-ɣən -aɣən	-n(ən) -an(ən)
	3.	-te -e	-ɣe -aɣe	-ne -ane
DU	1.	-men	-ɣamen -aɣamen	-namen -anamen
	2.	-n -en	-ɣen -aɣen	-nen -anen
	3.	-ten -en	-ɣen -aɣen	-nen -anen
PL	1.	-w -uw	-ɣuw - aɣuw	-nuw - anuw
	2.	-n -en	-ɣen -aɣen	-nen -anen
	3.	-nəl -anəl	-ɣanəl -aɣanəl	-n(an)əl -an(an)əl

Braucht man so etwas wirklich? Du kannst ja mal in der Vorlagenwerkstatt fragen, hier ist nicht so ganz der richtige Ort für dein Anliegen. --Liebe Grüße, Lómelinde Diskussion 06:33, 25. Jul. 2022 (CEST)

Ok, danke für deine Antwort. Ich habe die Vorlage:Diagonal geteilter Header mittlerweile angelegt, weil es meiner Meinung doch ansprechender erscheint, und in dem Artikel Mansische Sprache verwendet. --Liebe Grüße, Hanzlan (Diskussion) 22:05, 25. Jul. 2022 (CEST)

Die Verwendung dieser Vorlage stört die Barrierefreiheit und macht Tabellen ggf. für Screenreader unverständlich.

• Separate Tabellenzellen mit sinnvoller Bedeutung sind für die semantische Interpretation unabdingbar; optische Spielereien können weder vorgelesen werden noch den Spalten und Zeilen zugeordnet werden.
• Die Verwendung in enzyklopädischen Artikeln und auf offiziellen Projektseiten ist deshalb ausdrücklich unerwünscht.
• Es hat seinen triftigen Grund, warum wir den Spielkram aus der enWP bei uns nicht haben und nicht haben wollen.
• Warum fragst du erst, kümmerst dich dann doch nicht um die Antwort und legst sofort los?

In den als Beispiel genannten Tabellen sind die Kopfzellen derinhaltlichen Spalten mit rowspan="2" über beide Zeilen zu führen.

• Dann kann für die obere Eckzelle mit scope="row" semantisch auch für Screenreader klargestellt werden, dass sie sich auf die Kopfzellen bezieht.
• Die untere Eckzelle erhält scope="col" und damit ist semantisch vereinbart, dass sich das auf die Spalte mit den Zeilen-Leitwörtern bezieht.

VG --PerfektesChaos 22:54, 25. Jul. 2022 (CEST)

Tabellenunterschriften

Im Abschnitt Hilfe:Tabellen #Tabellenüberschrift erfährt man, wie man eine Tabellenüberschrift erzeugt. Leider finde ich nirgends eine Information darüber, wie man eine Tabellenunterschrift erzeugen kann. Mein konkretes Problem: Ich möchte unmittelbar unterhalb einer Tabelle einen Satz zu ihrer Erläuterung anfügen. Er soll unterhalb des Tabellenrahmens stehen, links aligniert sein und auch dann exakt unter der Tabelle stehen (und seitlich nicht über diese hinausragen), wenn der laufende Text mit float-left bzw. float-right zum Teil rechts oder links neben der Tabelle steht. --BurghardRichter (Diskussion) 18:01, 5. Aug. 2022 (CEST)

Ich meine das geht irgendwie mit style="caption-side:bottom; text-align:left;"

Text der Überschrift die jetzt unten steht

Überschrift	Überschrift	Überschrift
Beispiel	Beispiel	Beispiel
Beispiel	Beispiel	Beispiel
Beispiel	Beispiel	Beispiel

Irgendetwas mit Text oder …
wenn der Text nicht fett sein soll, dann nocht + font-weight:normal;
und zudem sollte der Abstand nach unten nicht durch dieses Format unnötig vergrößert werden.
Ich vermute mal das wäre zumindest für Artikel keine wirklich brauchbare Lösung,
weil das Zurücksetzen des Umflusses einen zu großen Abstand
unter der Tabelle hinterlässt.
was schreibe ich noch?
Text Text Text
neben der Tabelle

Hilft dir das weiter? --Liebe Grüße, Lómelinde Diskussion 19:18, 5. Aug. 2022 (CEST)

Danke, Lómelinde, das sieht schon ganz gut aus. Aber anscheinend ist dann nicht gleichzeitig auch eine Tabellenüberschrift mehr möglich. Die soll natürlich auch da sein. Mir schwebt jetzt noch etwas anderes vor mit einer Verschachtelung zweier Tabellen, von denen nur die innere im oberen Teil der äusseren mit class=wikitable gesetzt wird. Ach, das ist ein Elend mit unserer primitiven Tabellen-Software! Liebe Grüsse, Burghard; --BurghardRichter (Diskussion) 20:05, 5. Aug. 2022 (CEST)

Man könnte die Erläuterung natürlich auch einfach unter die Tabelle setzen; das wäre aber vermutlich zu einfach. :P -- Chaddy · D 20:10, 5. Aug. 2022 (CEST)

Ja, wenn es so einfach ginge! Wenn der nachfolgende laufende Text nicht unterhalb, sondern neben der Tabelle steht, dann funktioniert das nicht. --BurghardRichter (Diskussion) 22:17, 5. Aug. 2022 (CEST)

Verschachtelung zweier Tabellen geht auch nicht; da scheint „float-left“ (natürlich in der äusseren Tabelle gesetzt) nicht zu funktionieren. Ich habe jetzt den angefügten Erläuterungstext als zusätzliche Zeile in die Tabelle mit einbezogen, mit colspan und die Umrandung mit border-left/bottom/right:hidden in dieser Zeile unsichtbar gemacht: siehe Euro #Umrechnung der alten Währungen in Euro. --BurghardRichter (Diskussion) 22:17, 5. Aug. 2022 (CEST)

Das wäre dann mein zweiter Vorschlag gewesen. Tabellen nur aus reinen Layoutgründen zu verschachteln, ist keine gute Idee, das erschwert die visuelle Bearbeitung und wäre wohl auch nicht barrierefrei. --Liebe Grüße, Lómelinde Diskussion 06:39, 6. Aug. 2022 (CEST)

Wie zentriert man Tabellen?

Frage: siehe Überschrift. Also gemeint ist wirklich die Tabelle selbst und nicht der Zelleninhalt. --Viele Grüße, Alabasterstein (Diskussion) 08:18, 13. Sep. 2022 (CEST)

Habe es gefunden: mit <center> … </center> --Viele Grüße, Alabasterstein (Diskussion) 08:23, 13. Sep. 2022 (CEST)

@ Alabasterstein Nein auf gar keinen Fall, dann erzeugt das gleich Linterfehler. Siehe bitte Hilfe:Tabellen#Ausrichtung zentriert --Liebe Grüße, Lómelinde Diskussion 09:03, 13. Sep. 2022 (CEST)

Okay, wusste ich nicht. Was genau bewirkt dieser Linterfehler? --Viele Grüße, Alabasterstein (Diskussion) 10:14, 13. Sep. 2022 (CEST)

Ich sage es mal so, ich weiß nicht 100%ig wie sich das später einmal auswirken wird, da es derzeit (zumindest bei mir im Firefox) noch keinen Fehler erzeugt, aber das Tag →center ist veraltet. Das bedeutet es ist nicht sichergestellt, dass es auch in Zukunft erkannt und als zentrierendes Element umgesetzt wird. Somit kann die Darstellung dann kaputt gehen und etwas wird nicht mehr wie gewünscht dargestellt. Siehe auch →H:Tags#Ungebräuchliches HTML Das gilt im Grunde auch für →Hilfe:CSS#Veraltete Anweisungen, die man vermeiden sollte. Hier auch noch →Hilfe:Wikisyntax/Validierung#Veraltetes HTML-Tag es geht dabei um eine →Softwareumstellung für das gesamte Projekt, die nach und nach umgesetzt wird. --Liebe Grüße, Lómelinde Diskussion 10:36, 13. Sep. 2022 (CEST)

Lómelinde: noch eine Frage, die nichts mit dem Thema hier im Abschnitt zu tun hat, aber du vermutlich beantworten kannst. Wie bekomme ich hier Benutzer:Alabasterstein/Artikel/Schaukasten die Kästen gleich breit? Habe es mit style="width:50%;" versucht, aber irgendwie sieht es nicht richtig aus. --Viele Grüße, Alabasterstein (Diskussion) 16:22, 13. Sep. 2022 (CEST)

Ich schaue gleich mal. --Liebe Grüße, Lómelinde Diskussion 16:23, 13. Sep. 2022 (CEST)

Danke, kommt davon wenn man zu viel copy-pasted ;-) --Viele Grüße, Alabasterstein (Diskussion) 16:29, 13. Sep. 2022 (CEST)

Jetzt habe ich allerdings nochmal ein Problem, wenn ich den Tabellencode exakt dupliziere (für eine weitere Zeile) dann werden die Kästen nicht wie in der 1. Zeile nebeneinander sondern untereinander angeordnet und ich sehe nicht wieso. --Viele Grüße, Alabasterstein (Diskussion) 16:47, 13. Sep. 2022 (CEST)

Sollte jetzt passen, die Breitenangaben musst du nicht wiederholen, da sie in den Zellen, die untereinander stehen nicht unterschiedlich sein können. Kannst du dich bitte um den Artikel kümmern, um den es hier ursprünglich ging, da der Benutzer jetzt ständig die center Tags wieder einfügt, und damit Fehler verursacht. Ich mag mich mit solchen Leuten nicht herumärgern. --Liebe Grüße, Lómelinde Diskussion 16:57, 13. Sep. 2022 (CEST)

Ohje, ein schwieriger Zeitgenosse. Aber ich werde das im Auge behalten. --Viele Grüße, Alabasterstein (Diskussion) 17:10, 13. Sep. 2022 (CEST)

Zeilenumbruch innerhalb eines Tabelleneintrags

Es heisst umseitig im Abschnitt Hilfe:Tabellen #Zeilenumbruch, Aufzählung: „Ein Zeilenumbruch kann über das Element <br /> oder durch zweimaliges Betätigen von ↵ Enter erzeugt werden, was aber einen größeren Abstand erzeugen kann als die Verwendung des <br />.“ Zunächst verstehe ich nicht, warum die Enter-Taste zweimal betätigt werden soll. Dadurch wird in den Quelltext eine Leerzeile eingefügt. Das ist in laufendem Text notwendig, um einen Absatz zu erzeugen; aber innerhalb einer Tabelle genügt es dafür, mit einmaligem Enter eine neue Zeile des Quelltextes zu beginnen.
Meines Erachtens sollte man grundsätzlich ein <br /> dem Beginn einer neuen Quelltext-Zeile vorziehen. Erstens entsteht sonst, wie richtig festgestellt wird, ein vergrösserter vertikaler Abstand zwischen den Zeilen, was vermutlich in der Regel nicht beabsichtigt ist. Zweitens scheint sich der Beginn einer neuen Quelltext-Zeile innerhalb eines Tabelleneintrags nicht mit der sonst bestehenden Möglichkeit zu vertragen, direkt im Anschluss an einen Eintrag innerhalb derselben Quelltext-Zeile mit doppeltem Vertikalstrich (||) den nächsten Eintrag der Tabellenzeile anzufügen. Das wurde neulich in diesem Edit im Artikel Freie und Reichsstädte #Liste von freien und Reichsstädten versucht, und man kann sehen, wozu das führte.
Ich wäre deshalb dafür, nur das <br /> als einzige Möglichkeit zur Erzwingung eines Zeilenbruchs innerhalb eines Tabelleneintrags zu empfehlen. Nur zur Erzeugung einer Liste innerhalb eines Tabelleneintrags wird man wohl nicht umhinkommen, für jedes Listenelement eine neue Quelltext-Zeile zu beginnen. --BurghardRichter (Diskussion) 00:02, 16. Sep. 2022 (CEST)

<br />	2 × enter	*	#
Zeile 1 Zeile 2 Zeile 3	Zeile 1 Zeile 2 Zeile 3	Zeile 1 Zeile 2 Zeile 3	Zeile Zeile Zeile

Nach deiner Einschätzung sollte das dann nicht passieren, wenn man nur <br /> verwendet, das ist aber nicht so hier die Tabelle mit doppelpipes als Trennung der Zellen

<br />	2 × enter	*	#
Zeile 1 Zeile 2 Zeile 3 || Zeile 1 Zeile 2 Zeile 3 || Zeile 1 Zeile 2 Zeile 3 || Zeile Zeile Zeile

Wie man unschwer sehen kann es hat nichts damit zu tun ob man da <br /> setzt oder nicht es hängt ganz allein davon ab, dass man bei Aufzählungen generell die nächste nebenstehende Tabellenzelle stets am Zeilenanfang beginnen sollte. Das Problem ist nämlich eher, dass man die Zeile verlässt also zwischen || Text || ein Zeilenumbruch erfolgt, der dann zu Darstellungsfehlern führt. Hier ein einfaches Beispiel:

{| class="wikitable"
|-
! 1 !! 2 !! 3 !! 4
|-
| Text ||
Text || Text ||
Text
|}

{| class="wikitable"
|-
! 1 !! 2 !! 3 !! 4
|-
|Text<br />
Text || Text<br />
Text || Text<br />
Text || Text<br />
Text
|}

erzeugt ebenso Murks

1	2	3	4
Text	Text || Text || Text

1	2	3	4
Text Text || Text Text || Text Text || Text Text

es hat also absolut rein gar nichts mit der Verwendung von <br /> zu tun. Diese Empfehlung wäre also wirkungslos. --Liebe Grüße, Lómelinde Diskussion 06:50, 16. Sep. 2022 (CEST)

Sorry, ich kann deiner Argumentation nicht ganz folgen; vielleicht hast du mein Anliegen nicht richtig verstanden. Das nachfolgende Demonstrationsbeispiel enthält fünf Darstellungen eines Zeilenbruchs innerhalb eines Tabelleneintrags: 1. <br />, 2. neue Zeile im Quelltext, 3. <br /> und neue Zeile im Quelltext, 4. Leerzeile im Quelltext, 5. zwei Leerzeilen im Quelltext.

{|class="wikitable" style="margin-left:3em"

|-

| Zeile 1<br /> Zeile 2 || Zeile 1

Zeile 2

| Zeile 1<br />

Zeile 2

| Zeile 1

Zeile 2

| Zeile 1

Zeile 2

|}

Das Ergebnis ist

Zeile 1 Zeile 2

Zeile 1 Zeile 2

Zeile 1 Zeile 2

Zeile 1 Zeile 2

Zeile 1 Zeile 2

Es entsteht bei keiner dieser Möglichkeiten Murks; aber man sieht: Einen normalen Abstand zwischen den beiden Zeilen des Tabelleneintrags erhält man nur im ersten Fall, also mit <br />. Wann immer ein Tabelleneintrag sich über mehr als eine Quelltext-Zeile erstreckt, wird der Abstand zwischen den beiden Zeilen – in der Regel unerwünschterweise – vergrössert. Dabei macht es keinen Unterschied, ob dem Zeilenbruch in der Quelldatei ein <br /> vorangeht oder nicht und ob zwischen die beiden Quelltext-Zeilen noch eine Quelltext-Leerzeile eingeschoben wird oder nicht; nur wenn es mehrere Quelltext-Leerzeilen sind, wird der Abstand noch mehr vergrössert. Ausserdem funktioniert die vertikale Zentrierung eines Eintrags mit einem Quelltext-Zeilenbruch nicht richtig.

Man sollte also tunlichst, sofern man nicht wirklich einen vergrösserten Zeilenabstand wünscht, einen Zeilenbruch im Tabelleneintrag nicht durch einen Zeilenbruch im Quelltext, sondern nur durch ein <br /> innerhalb der nicht gebrochenen Quelltextzeile erzeugen. Das hat ausserdem den Vorteil, dass man eventuelle weitere Einträge in der Tabellenzeile genauso wie nach einem nicht umbrochenen Tabelleneintrag unmittelbar innerhalb derselben Quelltext-Zeile mit || angefügen kann. --BurghardRichter (Diskussion) 22:58, 16. Sep. 2022 (CEST)

Die Sache verhält sich noch etwas komplizierter, als ich bis gestern annahm. Meine Annahme, dass jeder Anfang einer neuen Quelltext-Zeile innerhalb einer Zelle der Tabelle automatisch einen Zeilenbruch erzeugen würde (also auch ohne vorangehendes <br />), war falsch. Das trifft nur für den ersten Anfang einer neuen Quelltext-Zeile zu, für evetuelle weitere dagegen nicht mehr; für die weiteren Zeilenbrüche braucht man also tatsächlich ein <br />. Alternativ zu den <br /> geht es auch mit einer Leerzeile im Quelltext; dann werden allerdings die Abstände zwischen den Zeilen wesentlich grösser. Nachfolgend einige Demonstrationsbeispiele:

Tabelle 1 (mit <br />, alles in einer Quelltext-Zeile)

{| class="wikitable" style="float:left; margin-left:3em; margin-right:1em"

|-

|style="text-align:center"| 1

|-

| Zeile 1<br />Zeile 2<br />Zeile 3<br />Zeile 4

|}

Tabelle 2 (jede Eintragszeile ausser der ersten in eigener Quelltext-Zeile, ohne <br />)

{| class="wikitable" style="float:left; margin-right:1em"

|-

|style="text-align:center"| 2

|-

| Zeile 1

Zeile 2

Zeile 3

Zeile 4

|}

Tabelle 3 (jede Eintragszeile ausser der ersten in eigener Quelltext-Zeile, mit <br />)

{| class="wikitable" style="float:left; margin-right:1em"

|-

|style="text-align:center"| 3

|-

| Zeile 1

Zeile 2<br />

Zeile 3<br />

Zeile 4

|}

Tabelle 4 (jede Eintragszeile einschliesslich der ersten in eigener Quelltext-Zeile, mit <br />)

{| class="wikitable" style="float:left; margin-right:1em"

|-

|style="text-align:center"| 4

|-

|

Zeile 1<br />

Zeile 2<br />

Zeile 3<br />

Zeile 4

|}

Tabelle 5 (jede Eintragszeile einschliesslich der ersten in eigener Quelltext-Zeile, mit Quelltext-Leerzeilen)

{| class="wikitable" style="float:left"

|-

|style="text-align:center"| 5

|-

|

Zeile 1

Zeile 2

Zeile 3

Zeile 4

|}

1

Zeile 1 Zeile 2 Zeile 3 Zeile 4

2

Zeile 1 Zeile 2 Zeile 3 Zeile 4

3

Zeile 1 Zeile 2 Zeile 3 Zeile 4

4

Zeile 1 Zeile 2 Zeile 3 Zeile 4

5

Zeile 1 Zeile 2 Zeile 3 Zeile 4

Die Darstellung der Tabelle 2 ist natürlich unbrauchbar, weil der Zeilenbruch (ausser beim ersten) so nicht funktioniert. Auch die Darstellung der Tabelle 3 ist unbefriedigend, weil die Zeilenabstände ungleich sind. In der Darstellung 5 (mit Quelltext-Leerzeilen) sind die Abstände zwischen den Zeilen zu gross. Nur die Darstellungen der Tabellen 1 (alles innerhalb einer Quelltext-Zeile) und 4 (lauter separate Quelltext-Zeilen mit <br />) sind in Ordnung und können empfohlen werden – wie es auch umseitig anhand der dort präsentierten Beispiele geschieht; nur die textliche Beschreibung ist nicht zufriedenstellend. Allerdings ist die vertikale Plazierung des Zelleninhalts innerhalb des Rahmens unterschiedlich: Bei Darstellung 4 erscheint im Vergleich zu Darstellung 1 ein zusätzlicher Leerraum oberhalb und unterhalb des Zelleninhalts (der bei Darstellung 2 und 3 nach der ersten und nach der letzten Zeile erscheint). --BurghardRichter (Diskussion) 16:31, 17. Sep. 2022 (CEST), erweitert 20:03, 17. Sep. 2022 (CEST)

Da du diesen Link Spezial:Diff/226061509#Liste von freien und Reichsstädten mit der total zerlegten Tabelle als Beispiel angegeben hast und dich über den Murks dort beschwert hast, war nicht wirklich ersichtlich, was genau dein Problem ist. Das mit den unterschiedlichen Abständen zwischen der ersten Zeile und dem nachfolgenden Inhalt, nach einmaligem Umbruch ist leider ein Verhalten, dass sich hier nicht ändern lässt. Wenn, dann sollten alle Aufzählungen in der Zeile nach dem Pipe beginnen oder alles in einer Zeile stehen und umgrbrochen werden, also so:

1<br />2<br />	Neue Zeile 1<br />	Neue Zeile *	Neue Zeile #
Zeile 1 Zeile 2 Zeile 3	Zeile 1 Zeile 2 Zeile 3	Zeile 1 Zeile 2 Zeile 3	Zeile Zeile Zeile

Wie man das aber jetzt genau vorgeben soll weiß ich nicht, da ich nicht weiß was der Bearbeitende erreichen möchte. Aufzählungen sollten als Aufzählungen definiert werden, dafür gibt es ja * und # Auf der Vorderseite stehen aber zwei unterschiedliche Dinge einmal ein Zeilenumbruch und einmal eine Aufzählung folglich ist das korrekt was dort steht.

Zitat:

• Ein Zeilenumbruch kann über das Element <br /> oder durch zweimaliges Betätigen von ↵ Enter erzeugt werden, was aber einen größeren Abstand erzeugen kann als die Verwendung des <br />.
• Wie Aufzählungen realisiert werden, steht ausführlich unter Hilfe:Listen. Bei der Bearbeitung im Quelltext muss darauf geachtet werden, dass die Aufzählungszeichen * oder # direkt am Zeilenanfang stehen müssen.

Hervorhebung durch mich. Einmal geht es ausschließlich darum einen Zeilenumbruch zu erzeugen und dafür gibt es zwei Möglichkeiten, und das andere sind Aufzählungen (H:Listen). --Liebe Grüße, Lómelinde Diskussion 17:16, 17. Sep. 2022 (CEST)

Danke, Lómelinde, für deine geduldigen Erklärungen! Es waren zwei Missstände, zum Teil in Verbindung mit einem Irrtum meinerseits, die mich zur Anlage dieses Threads veranlassten. Der erste ist die Sache mit dem doppelten Enter, also der Einfügung einer Leerzeile, die nicht recht verständlich ist und die auch nicht mit dem nachfolgenden Demonstrationsbeispiel konsistent ist, das ja im Quelltext keine Leerzeile enthält. Der zweite ist die Inkompatibilität des Zeilenumbruchs in Form mehrerer Quelltext-Zeilen mit nachfolgend direkt in der letzten dieser Quelltext-Zeilen angefügten weiteren Tabellenzellen. Darauf war ich neulich durch diesen Edit im Artikel Freie und Reichsstädte gestossen; natürlich hatte ich dann sogleich verstanden, dass so etwas anscheinend nicht geht. Ich war dann etwas frustriert, dass ich auf dieser Hilfe-Seite nichts dazu fand. Es war mir nicht bewusst, dass diese Sache – wie auch überhaupt die bekannte Möglichkeit, mehrere Zellen einer Tabellenzeile innerhalb einer Quelltext-Zeile anzuordnen – vor gut zwei Jahren in die damals neu angelegte Unterseite Hilfe:Tabellen/Wikisyntax #Elemente ausgelagert worden war, und da fand ich die gesuchte Information natürlich nicht. (Vielleicht sollte man das wieder in die Hauptseite zurückholen. Das ist nicht etwas Spezielles, was nur einige „Fortgeschrittene“ interessiert, sondern etwas ganz Elementares, was eigentlich hierher gehört.) In meinem weiter unten präsentierten Vorschlag einer Neufassung des umseitigen Abschnitts habe ich diese beiden Kritikpunkte natürlich aufgenommen.

Irrtümlich nahm ich bis gestern an, dass der Beginn einer neuen Quelltext-Zeile innerhalb einer Tabellenzelle in jedem Fall einen Zeilenbruch erzeugen würde. Man sieht ja oft, dass ein Zeilenbruch innerhalb eines Tabelleneintrags in der Weise bewerkstelligt wird, dass der Inhalt der ersten Zeile direkt an das Pipe-Zeichen angefügt wird (ohne <br /> am Ende) und der Inhalt der zweiten Zeile in eine neue Quelltext-Zeile gesetzt wird – was durchaus funktioniert, wenngleich der Abstand zwischen den beiden Zeilen dann viel zu gross ist. Und ich wollte eigentlich anregen, dass von so etwas abgeraten werden sollte. Erst danach wurde mir klar, dass der Beginn einer neuen Quelltext-Zeile allein, d.h. ohne vorangehendes <br />, nur beim ersten Mal und wenn der Inhalt der ersten Zeile direkt dem Pipe-Zeichen folgt, einen Zeilenbruch erzeugt. Wenn man aber bereits den Inhalt der ersten Zeile in eine neue Quelltext-Zeile setzt und jedes Mal ein <br /> am Ende hinzufügt, dann wird es ja doch ganz gut, einschliesslich der Zeilenabstände. So wird es ja auch in dem umseitigen Demonstrationsbeispiel gemacht; aber der darüberstehende Text sagt dazu nichts. Deshalb in meinem Vorschlag die deutlichere Formulierung „Eine alternative Möglichkeit besteht darin, für jede Zeile des Eintrags eine neue Quelltext-Zeile zu beginnen, ebenfalls mit <br /> an den Bruchstellen am jeweiligen Zeilenende“, mit ausdrücklichem Hinweis auf das nachfolgende Demonstrationsbeispiel; „für jede Zeile des Eintrags“ gilt natürlich ausdrücklich auch für die erste Zeile, die damit also nicht unmittelbar auf das Pipe-Zeichen folgen soll. --BurghardRichter (Diskussion) 23:46, 17. Sep. 2022 (CEST)

Einige Anmerkungen:

• „zweimaliges Betätigen von ↵ Enter erzeugt werden“ – das ist unglücklich.
  • Es steht im Quelltext eine Leerzeile. Diese Leerzeile hat in der Wikisyntax eine Bedeutung.
  • Wie die Leerzeile dorthin gelangt, ob per C&P oder durch Drücken irgendwelcher Tasten oder Anklicken irgendwelcher Werkzeugknöpfe, ist hier bedeutungslos.
• Eins drüber mit kleinem „drücken“ ähnlich.
• Es ist grundsätzlich so, dass die Fortsetzung einer Tabellenzeile mit verdoppeltem Trennzeichen nur innerhalb einer geschlossenen Quelltext-Zeile möglich ist.
  • Siehe das (den ersten Einstieg für VE und Quelltext gemeinsam) vertiefende Hilfe:Tabellen/Wikisyntax: „Innerhalb einer einzigen Quelltext-Zeile können auch mehrere Zellen angeordnet werden; dann sind die Symbole für jede nachfolgende Zelle zu verdoppeln“
  • Geschlossene Quelltext-Zeile pro Tabellenzeile ist nur dann eine gute Idee, wenn die Quelltext-Zeilen alle sehr kurz sind; also etwa zwei Spalten und dann Jahreszahl und Einwohnerzahl direkt nebeneinander.
  • Wenn bereits Zeilenumbrüche im Raum stehen, dann ist diese Vorbedingung bereits nicht mehr gegeben.
• Es ist üblich, bei dargestelltem Zeilenumbruch das <br /> an das Ende einer Quelltext-Zeile zu setzen und die folgende dargestellte Zeile analog auf einer neuen Quelltext-Zeile zu beginnen.
• Seit ewig reagiert die Wiki-Darstellung teils überempfindlich auf Zeilenumbruch im Quelltext, mit vergrößertem Abstand auch durch Bildung eines <p>-Elements, und das wird deshalb auch auf ewig so bleiben.
• Ob mittels Leerzeile ein neuer Absatz generiert wird, was ja deren Zweck ist, hängt von den Umständen des Einzelfalls ab und kann nicht verboten werden.
  • Riecht allerdings schwer nach einer „Layout-Tabelle“ und wäre eher deshalb fragwürdig.
  • Kürzere Einzelinformationen sollten tatsächlich nicht durch Absätze getrennt werden, sondern kompakt durch <br />, jedoch gibt es viele viele viele unterschiedliche Inhalte einzelner Tabellenspalten.
• Nach Maßgabe der Diskussion steht es frei, die umseitig an VE- und Wikisyntax-Bearbeitung adressierten Inhalte verständlicher darzustellen.

VG --PerfektesChaos 08:22, 16. Sep. 2022 (CEST)

Danke für die klärenden Statements! Im umseitigen Abschnitt Hilfe:Tabellen #Zeilenumbruch, Aufzählung ist, wie ich es jetzt verstehe, insbesondere unbefriedigend, dass der Text und das Demonstrationsbeispiel nicht zusammenpassen. Im Text ist die Rede von „zweimaliges Betätigen von Enter“, also Einfügen einer Quelltext-Leerzeile nach jeder Eintragszeile; im nachfolgenden Beispiel werden dann aber <br /> ans Ende jeder Eintragszeile angefügt.

Mein Alternativvorschlag für den zweiten Teil des Abschnitts (Quelltextbearbeitung):

Quelltextbearbeitung

• Ein Zeilenumbruch in einer Zelle kann am einfachsten durch das Tag <br /> an jeder Bruchstelle innerhalb einer und derselben Zeile des Quelltextes erzeugt werden. Eine alternative Möglichkeit besteht darin, für jede Zeile des Eintrags eine neue Quelltext-Zeile zu beginnen, ebenfalls mit <br /> an den Bruchstellen am jeweiligen Zeilenende, wie im nachfolgenden Beispiel (2. Spalte) gezeigt wird. Das ist bei längeren Zeilen des umbrochenen Tabelleneintrags übersichtlicher, kann allerdings zu einer etwas veränderten vertikalen Anordnung des Zelleninhalts führen; auch können dann nicht in direktem Anschluss daran weitere Zellen innerhalb derselben Quelltext-Zeile hinzugefügt werden (wie in Hilfe:Tabellen/Wikisyntax #Elemente beschrieben).
• Eine Zelle innerhalb einer Tabelle kann auch eine Aufzählung in Form einer Liste, wie in Hilfe:Listen beschrieben, enthalten. Da hierbei jedes Element der Liste eine eigene Quelltext-Zeile erfordert, ist dies ein Sonderfall der im vorigen Punkt genannten Alternativmöglichkeit des Zeilenumbruchs. Die <br /> an den Zeilenenden entfallen hier, da die Aufzählungszeichen * oder #, die alle direkt am Anfang der jeweiligen Quelltext-Zeile stehen müssen, hinreichend den Zeilenwechsel markieren.

Eine QT-Zeile	Individuelle QT-Zeilen
<br />	<br />	*	#
Zeile 1 Zeile 2 Zeile 3	Zeile 1 Zeile 2 Zeile 3	Zeile 1 Zeile 2 Zeile 3	Zeile Zeile Zeile

QT = Quelltext

Quelltext dieser Tabelle:

{| class="wikitable toptextcells"
|-
! ''Eine'' QT-Zeile !!colspan="3"| Individuelle QT-Zeilen
|-
! <code>&lt;br /&gt;</code> !! <code>&lt;br /&gt;</code> !! <code>*</code> !! <code>#</code>
|-
|Zeile 1<br />Zeile 2<br />Zeile 3
|
Zeile 1<br />
Zeile 2<br />
Zeile 3
|
* Zeile 1
* Zeile 2
* Zeile 3
|
# Zeile
# Zeile
# Zeile
|}

So weit mein Vorschlag für den umseitigen Abschnitt.

Den Klassenparameter toptextcells habe ich hinzugefügt, um die unterschiedliche vertikale Anordnung der Tabelleneinträge sichtbar zu machen. Die zweite Tabelle („Einfache Tabelle“), d.h. ohne Wikitable-Format, habe ich weggelassen, da sie keine weiteren Informationen bietet. Zum ersten Teil des Abschnitts (Visual Editor) kann ich nichts sagen, da ich mich damit nicht auskenne.

Nicht sehr glücklich bin ich auch in Hilfe:Tabellen/Wikisyntax #Elemente mit dem Absatz

„Eine ‚Nachbarzelle‘, die ‚innerhalb einer einzigen Quelltext-Zeile‘ der vorangehenden benachbart ist, setzt voraus, dass auch ganz am Anfang bereits eine Zelle steht. Somit kann kein Zeilenumbruch darin vorkommen; ausgenommen bei der letzten Zelle, die dann ‚innerhalb derselben Quelltext-Zeile‘ jedoch keine ‚Nachbarzelle‘ mehr haben kann.“

Die Formulierung erscheint mir schwer verständlich. Mein Alternativvorschlag:

Wenn eine Zelle einen Zeilenumbruch in der Form mehrerer Quelltext-Zeilen enthält, können innerhalb der letzten dieser Quelltext-Zeilen keine weiteren Nachbarzellen angeschlossen werden; diese müssen dann in eine neue Quelltext-Zeile gesetzt werden. --BurghardRichter (Diskussion) 22:12, 17. Sep. 2022 (CEST)

Da zu meinen beiden Vorschlägen keine Kritik geäussert wurde, habe ich sie jetzt umgesetzt: Spezial:Diff/227469361, Spezial:Diff/227469701. --BurghardRichter (Diskussion) 23:55, 29. Okt. 2022 (CEST)

Einsatz von festen Leerstelle ({{0}}) am Spaltenende

In etlichen Tabellen fällt mir eine verzerrte Darstellung durch den Einsatz von festen Leerstellen am Ende einer Spalte auf, z.B. hier. Die Darstellung ist ja immer unterschiedlich, je nachdem ob ich eine Seite am Handy oder am PC ansehe, zudem in welcher Größe ich etwas ansehe. Durch die Leerstelle wird die Darstellung an meinem PC verzerrt. Daher lösche ich sie, da ja sowieso ein Spaltenende erreicht ist und der Quelltext unnötig aufgebläht und unübersichtlich wird.

Unter Layout-Tabelle heißt es: Vermieden werden sollte generell: Unterbinden von Zeilenumbrüchen (nowrap, geschützte Leerzeichen) wo nicht wirklich erforderlich. Bei schmaler Bildschirmbreite muss an geeigneten Stellen umbrochen werden können.

Das betrifft ja dann auch den Einsatz der festen Leerstelle ({{0}})? --Montrachet (Diskussion) 18:36, 25. Okt. 2022 (CEST)

Wenn es dazu keine Anmerkungen gibt, würde ich das Unterbinden von Zeilenumbrüchen im Abschnitt Layout-Tabellen um {{0}} und &nbsp; ergänzen. --Montrachet (Diskussion) 22:12, 28. Okt. 2022 (CEST)

Schön, dass du vorher fragst bzw. ankündigst.

Ich habe allerdings nicht verstanden, was du machen möchtest, Empfehlung zu löschen oder hinzuzufügen?

Vorlage:0 ist ohnehin ein ungern gesehener Hack aus unserem Kindergarten, und hinter einen Inhalt irgendwas zu verbauen um zu erzwingen dass dahinter Platz verschenkt wird ist in der Tat Mist. Und im Zeitalter der Smartphones erst recht, aber vorher auch schon.

VG --PerfektesChaos 22:42, 28. Okt. 2022 (CEST)

Im Text heißt es Unterbinden von Zeilenumbrüchen (nowrap, geschützte Leerzeichen) wo nicht wirklich erforderlich. In der Klammer möchte ich {{0}} und &nbsp; ergänzen, um dies zu verdeutlichen. --Montrachet (Diskussion) 14:24, 29. Okt. 2022 (CEST)

&nbsp; ist nichts anderes als die Darstellung eines geschützten Leerzeichens, und die Vorlage:0 erzeugt eine unsichtbare Null, also praktisch einen Leerraum von der Breite einer Ziffer; das hat mit der Ermöglichung oder Verhinderung von Zeilenumbrüchen nichts zu tun. Ich sehe nicht, was man in dem Satz noch ergänzen könnte. --BurghardRichter (Diskussion) 16:46, 29. Okt. 2022 (CEST)

(nach BK) Ich glaube nicht, dass das hier nötig ist. Die Vorlage funktioniert ja nicht einmal so wie erwartet. Im oben genannten Beispiel der Orgeln des Aachener Doms gibt es z. B. bei bestimmten Festerbreiten hässliche Umbrüche, wenn die unsichtbare 0 in einer eigenen Zeile landet. @Eliasorgel: Du solltest Dir ein anderes Verfahren überlegen. Ich vermute, es geht darum, dass Werte wie „Scharffmixtur IV“ und „1 ¹⁄₃′“ nicht so dicht beieinander liegen, dass man sie für zusammengehörig halten könnte. Ein padding-right an den betroffenen Tabellenzellen wäre da besser, würde aber auch den Quellcode ziemlich stark aufblähen. Ich halte den Nutzen für so gering, dass ich es lassen würde. --Rodomonte (Diskussion) 16:47, 29. Okt. 2022 (CEST)

Es geht auf dieser Seite in erster Linie um die verzerrte Darstellung bei Superoktave und Venezianerflöte, die durch die unsichtbare 0 hervorgerufen wird. --Montrachet (Diskussion) 18:53, 29. Okt. 2022 (CEST)

Jetzt wurde es bearbeitet und es sind noch mehr unsichtbare 0 drin. --Montrachet (Diskussion) 20:20, 29. Okt. 2022 (CEST)

Es war missverständlich und verwirrend, dass du oben in deinem Eingangsstatement vom „Ende einer Spalte“ schriebst; es handelt sich ja um Tabelleneinträge, die gerade nicht ganz unten am Ende der Spalte stehen. Wie auch Rodomonte richtig festgestellt hat, hängt die erzeugte Wirkung, zumindest am PC-Bildschirm, davon ab, wie breit das Fenster eingestellt ist, in dem man den Artikel ansieht. Bei mir erscheint an den beiden Stellen, die Du jetzt genannt hast, alles in Ordnung; aber in der folgenden Tabelle treten bei mir unsinnige Effekte auf. (Wie es bei Mobiltelephonen ist, weiss ich nicht, da ich nur einen PC und kein internetfähiges Mobiltelephon besitze.)

Elias hat anscheinend in jeder Teiltabelle bei dem Registernamen, der jeweils der längste ist, eine solche unsichtbare Null hinzugesetzt, um auf die Weise den Abstand zur nächsten Spalte künstlich zu vergrössern. Das ist sicher eine plausibel erscheinende Möglichkeit, wenn auch nicht gerade sehr elegant. In seinem letzten Edit hat er keine weiteren unsichtbaren Nullen hinzugefügt, sondern nur gewöhnliche Leerzeichen vor diesen unsichtbaren Nullen entfernt, so dass zwischen dem Registernamen und der unsichtbaren Null kein Zeilenbruch mehr möglich ist. Das erscheint auch einigermassen plausibel. Bei der nächsten Tabelle im Abschnitt Orgeln des Aachener Doms #Hochmünsterorgel hat er diese gewöhnlichen Leerzeichen belassen, und das führt bei entsprechender Einstellung der Fensterbreite zu dem unsinnigen Effekt, dass an dieser Stelle ein Zeilenbruch erfolgt und die untere Zeile nur die unsichtbare Null enthält. Dadurch erscheint die obere Zeile um eine halbe Zeilenhöhe nach oben verschoben, während die Einträge links und rechts daneben auf mittlerer Höhe stehen. Das ganze ist also totaler Murx.

Ich vermute auch, dass man es richtigerweise irgendwie mit padding machen müsste. Ich habe es auch versucht (aber nicht abgespeichert und nur in der Vorschau angesehen); doch es funktionierte nicht so, wie ich es mir gedacht hatte. Unsere Tabellensyntax taugt leider nicht viel, und die umseitige Dokumentation lässt auch sehr zu wünschen übrig. Da treten oft Dinge auf, die ich mir nicht erklären kann. Und mit Tabellen ohne Wikitable-Formatierung (also ohne senkrechte bzw. waagerechte Linien zwischen den Spalten und Zeilen) habe ich ohnehin praktisch keine Erfahrung. --BurghardRichter (Diskussion) 21:24, 29. Okt. 2022 (CEST)

Verstehe ich das jetzt richtig, dass es nicht an der 0 liegt, dass das ganze verzerrt wirkt, sondern daran dass es vor der 0 noch eine Leerstelle gibt? --Montrachet (Diskussion) 21:39, 29. Okt. 2022 (CEST)

Vielleicht. Aber ich weiss nicht, was du konkret mit „verzerrt wirken“ meinst. Wenn diese Verzerrung in der ersten grossen Tabelle jetzt nicht mehr auftritt, nachdem Elias dort die gewöhnlichen (d.h. nicht umbruchgeschützten) Leerzeichen entfernt hat, wohl aber noch in der zweiten Tabelle bei entsprechender Fensterbreite, so wie von mir beschrieben, vorhanden ist, dann könnte es wohl daran liegen. Dann könnte man auch dort die gewöhnlichen Leerzeichen vor den unsichtbaren Nullen entweder entfernen oder durch geschützte Leerzeichen ersetzen. Allerdings wäre das eine Flickschusterei, die ich nur ungern empfehlen mag. --BurghardRichter (Diskussion) 21:57, 29. Okt. 2022 (CEST)

* Ich glaube mir wird langsam klar was Montrachet mit "eine verzerrte Darstellung" meinen könnte...

Je nach Fensterbreite oder ZoomEinstellung werden die Tabellen neu gerendert und da sich diese nicht (wie der Rest einer WIKI-Seite) an die Seitenbreite halten sondern munter weiter so breit dargestellt werden wie sie das Erstelly vorgegeben hat - in Aachen zB 6 Spalten weil irgendjemand meinte er müsse für das eine Tuba-Register welches etwas arg vollmundig auch noch als eigenes Werk (Auxiliar) bezeichnet wird (aber lassen wir das)

da trotzdem versucht wird die Tabelle in der Breite anzupassen, geschieht folgendes - in jeder Tabellenzelle wird überprüft ob der Inhalt nicht durch einen Zeilenumbruch "schmaler" gemacht werden kann und (für Orgel-Dispositionen) blöderweise funktioniert das immer bei Registereinträgen die ein Leerzeichen beinhalten (Mixtur XX, Trompete harm, Flöte B/D, Cheleste (ab c0) etc). Ich persönlich wäre sofort dabei sämtliche Dispositionen daraufhin zu "verbessern", dass dermaßen unschöne Zeilenumbrüche überhaupt nicht mehr vorkommen.

Dafür gibt es verschiedene Möglichkeiten, denn der Zeilenumbruch (einer Spalte) richtet sich immer nach dem längsten zusammenhängenden Eintrag (in dieser Spalte) und dazu zählen die {{0}} und &nbsp;

hier könnte d/f/m gleich zwei Fliegen durch eine Bresche schlagen

denn wie der Richter* "richtig" angemerkt hat:

"Elias hat anscheinend in jeder Teiltabelle bei dem Registernamen, der jeweils der längste ist, eine solche unsichtbare Null hinzugesetzt, um auf die Weise den Abstand zur nächsten Spalte künstlich zu vergrössern. Das ist sicher eine plausibel erscheinende Möglichkeit, wenn auch nicht gerade sehr elegant."

wer auch immer, zeige mir bitte (und gerne) eine elegantere Möglichkeit und ich bin sofort dabei diese anzuwenden (so gut ich kann - versprochen)

Herzliche Grüße oliver --Eliasorgel (Diskussion) 00:29, 30. Okt. 2022 (CEST)

• * Lieber BurkhardRichter, falls ich gemeint sein sollte - mein Benutzername ist Eliasorgel und nicht Elias, auch im wahren Leben heiße ich an keiner Stelle Elias und bin weder eine Orgel noch Richter (von Beruf ;-) --Eliasorgel (Diskussion) 00:29, 30. Okt. 2022 (CEST)

Zur inhaltlichen Klärung: Die aktuelle Benennung von „geschützte Leerzeichen“ meint in erster Linie das Konstrukt   – es gibt aber auch „schmale geschützte Leerzeichen“ und andere Kodierungsmöglichkeiten. Hier geht es aber nur um den „irgendwie verhinderten Zeilenumbruch“ und nicht um eine erschöpfende Aufzählung aller erdenklichen technischen Umsetzungen, was an dieser Stelle das eigentliche Ziel vor die Wand fahren würde.

• Eine direkt (ohne normales Leerzeichen dazwischen) angeschlossene Vorlage:0 bewirkt auch nichts anderes als ein geschütztes Leerzeichen, bloß mit einer voraussichtlich um wenige Pixel schmaleren Breite. Hinzu kommt, dass sie den Inhalt der Zelle um Pseudo-Zeichen (Nullen) aufbläht, die sich jedoch auf Suchergebnisse voll auswirken. Letzteres macht sie zur erheblich schlechteren Lösung.
• Generell ist mit allen Aktivitäten, die eine Mindest-Spaltenbreite erzwingen oder irgendwo inhaltlich nicht erforderliche leere Flächen bewirken, große Zurückhaltung geboten. Was irgendein „Hauptautor“ sich mal für seinen Desktop-PC und sein persönliches Bildschirmfenster layoutet hatte, kann im Zeitalter von Smartphones katastrophal werden. Grundsätzlich ist so wenig wie möglich Syntax zu verwenden, so wenig wie irgend möglich zu erzwingen, und das Layout den Browsern beim Publikum zu überlassen – denn die wissen, wie breit dort im Moment der Bildschirm ist. Deshalb ist umseitig auch nicht dazu zu animieren, wie sich noch mehr Platz für Privatgeschmack verschenken ließe. Wer sowas kann und sicher beherrscht und sinnvoll einsetzen kann, der weiß dies auch so; wer nicht, muss nicht noch den Rahmen sprengende Anleitungen erhalten, wie sich das Layout noch weiter verhunzen lässt. Es werden schlicht und ergreifend keine inhaltlich nicht erforderlichen Extra-Abstände zu irgendwas erzwungen.

VG --PerfektesChaos 01:19, 30. Okt. 2022 (CEST)

Es gilt also, dass das Unterbinden von Zeilenumbrüchen unterbleiben soll, wie es hier steht. Daher bitte ich dich @Eliasorgel: zukünftig keine {{0}} oder &nbsp; mehr einzufügen, wenn es nur darum geht, Zeilenumbrüche zu vermeiden.--Montrachet (Diskussion) 17:10, 30. Okt. 2022 (CET)

@Montrachet: Das hast du möglicherweise missverstanden. Im umseitigen Abschnitt Hilfe:Tabellen #„Layout-Tabellen“ steht nicht, dass die Verhinderung von Zeilenumbrüchen grundsätzlich unterbleiben soll, sondern es heisst vielmehr: „Vermieden werden sollte generell: … Unterbinden von Zeilenumbrüchen … wo nicht wirklich erforderlich.“ Dass man Zeilenumbrüche nur an solchen Stellen verhindern soll, wo es wirklich notwendig ist, um eine störende Trennung zweier eng zueinandergehörender Ausdrücke (von denen mindestens einer sehr kurz sein muss) zu vermeiden, das gilt ganz allgemein in der Wikipedia – ganz besonders aber in Tabellen, wo die für einen Eintrag zur Verfügung stehende Zeilenlänge in der Regel viel kleiner als die Zeilenlänge des laufenden Textes ist. Wenn es sich aber um Ausdrücke handelt, die aus gutem Grund nicht zertrennt werden sollen, dann ist selbstverständlich auch in einem Tabelleneintrag ein geschütztes Leerzeichen notwendig und richtig. Beispiele sind etwa aus mehreren Buchstaben bestehende Abkürzungen, Paragraphenzeichen mit nachfolgender Nummer, Zahlen mit abgekürzter Masseinheit, und das gilt natürlich auch für Einträge, die aus ein oder zwei Wörtern und einer nachfolgenden kurzen (d.h. ein- oder zweistelligen) Zahl bestehen. Da kann es sogar notwendig sein, mit Hilfe eines &nbsp; vor der Zahl zu erzwingen, dass diese nicht in eine neue Zeile gesetzt wird, auch wenn die Zelle der Tabelle dadurch etwas breiter wird. Und eine solche Verbreiterung der Zelle war ja von Eliasorgel mit dem Hinzusetzen einer – in diesem Fall unsichtbaren – Zahl beabsichtigt, um damit den Abstand zur rechts danebenstehenden Spalte optisch zu vergrössern. Aber dieser Zweck konnte natürlich verfehlt werden, wenn die unsichtbare Null mit einem gewöhnlichen Leerzeichen, an dem ein Zeilenbruch möglich war, angeschlossen wurde.

@Eliasorgel: Es ist immer schlecht, wenn man zur Erreichung eines bestimmten Zieles nicht das dafür vorgesehene Mittel, sondern ein anderes Mittel verwendet, welches dafür eigentlich nicht vorgesehen ist. Die Vorlage:0 ist (abgesehen davon, dass einige sie grundsätzlich nicht schätzen) nicht dafür geschaffen worden, damit den breitesten Tabelleneitrag einer Spalte künstlich noch etwas breiter zu machen, um so den Zwischenraum zur nächsten Spalte optisch zu vergrössern. Dass dieser Weg ungeeignet ist, zeigt sich schon daran, dass ein Tabelleneintrag, der aus mehr als einem Wort besteht, je nach der Fensterbreite in zwei Zeilen umbrochen werden kann; dann ist er nicht mehr der breiteste der Spalte, und der beabsichtigte Zweck wird verfehlt.

Das Mittel, um rechts neben einem Tabelleneintrag (egal aus wievielen Zeilen er besteht) einen Leerraum von bestimmter Breite anzufügen, ist style="padding-right:…", wie umseitig im Abschnitt Hilfe:Tabellen #Texteinrückung beschrieben. Es bleibt dabei aber der Nachteil, dass man oft (wegen möglicher nicht vorhersehbarer Zeilenumbrüche) nicht im voraus wissen kann, welcher Eintrag einer Spalte tatsächlich der breiteste ist. Man müsste also, um sicherzugehen, nicht nur bei einem, sondern bei allen Einträgen der Spalte dieses padding-right setzen. Alternativ könnte man natürlich auch bei allen Einträgen der folgenden Spalte ein padding-left setzen.

Aber eigentlich ist auch das nicht das wirklich geeignete Mittel. Mit einem Padding erzeugt man keinen Abstand zwischen zwei Spalten, sondern erreicht nur, dass die Einträge innerhalb der jeweiligen Zelle in einer Spalte einen gewissen Abstand vom rechten bzw. linken Rand der Zelle haben. Bei einer einfachen Tabelle ohne Linien zwischen den Spalten und Zeilen sieht man den Unterschied nicht, aber tatsächlich sind es verschiedene Dinge. Einen Abstand zwischen zwei Spalten erzeugt man mit der Angabe style="border-spacing: … …", wie in Hilfe:Tabellen für Fortgeschrittene #Zellenabstände beschrieben.

Zur Demonstration ein einfaches Beispiel: eine kurze Tabelle mit zwei Spalten in drei verschiedenen Darstellungen, 1. ohne Festlegung eines Abstands zwischen den beiden Spalten, 2. mit style="padding-right:1em", 3. mit style="border-spacing: 1em 0em". Hierin ist „em“ die im Schriftsatz gebräuchliche Masseinheit, die etwa der Breite eines kleinen m entspricht, je nach der benutzten Schriftgrösse.

ab	24
abc	36
abcd	48
abc	60
ab	72

ab	24
abc	26
abcd	48
abc	60
ab	72

ab	24
abc	36
abcd	48
abc	60
ab	72

Natürlich geht es nicht ohne den üblichen Vorführeffekt: Wenn man etwas zeigen will, funktioniert es nicht. Eigentlich sollten alle drei Tabellen nebeneinander stehen, so wie umseitig im Abschnitt Hilfe:Tabellen #Tabellen linksbündig nebeneinander erklärt. Es weiss der Kuckuck, warum hier die dritte Tabelle nicht rechts neben, sondern unter den ersten beiden erscheint. Solche unerklärlich erscheinenden Dinge erlebt man manchmal in der Wikipedia-Arbeit, besonders bei Tabellen. Aber zum Glück ist dies ja kein Artikel, sondern nur eine Diskussionsseite, auf der nicht alles perfekt sein muss. Wenn einer, der dies liest, weiss, was ich falsch gemacht habe, darf er es gerne berichtigen und dieses Kleingesetzte entfernen.

Der Quelltext zu diesen drei Tabellen:

{| style="float:left; margin-left:3em; margin-right:2em"

|-

| ab || 24

|-

| abc || 36

|-

| abcd || 48

|-

| abc || 60

|-

| ab || 72

|}

{| style="float-left; margin-right:2em"

|-

|style="padding-right:1em"| ab || 24

|-

|style="padding-right:1em"| abc || 26

|-

|style="padding-right:1em"| abcd || 48

|-

|style="padding-right:1em"| abc || 60

|-

|style="padding-right:1em"| ab || 72

|}

{| style="float-left; border-spacing: 1em 0em"

|-

| ab || 24

|-

| abc || 36

|-

| abcd || 48

|-

| abc || 60

|-

| ab || 72

|}

Wie man sieht, hat border-spacing gegenüber padding-right den Vorteil, dass man es nicht für jeden Eintrag der linken Spalte, sondern nur einmal in der Anfangszeile der Tabelle zu setzen braucht.

Bei den Orgelregistertabellen im Artikel Orgeln des Aachener Doms liegen die Dinge noch etwas komplizierter, da es sich um verschachtelte Tabellen handelt. Die äusseren Tabellen enthalten Festsetzungen des Spaltenabstands in der (veralteten, heute nicht mehr verwendeten) Form cellspacing="24" cellpadding="18"; das betrifft nur die Abstände zwischen den inneren Tabellen und hat keine Wirkung innerhalb der inneren Tabellen. --BurghardRichter (Diskussion) 02:24, 1. Nov. 2022 (CET)

Vielleicht habe ich mich unklar ausgedrückt. Bezogen auf mein erstes Statement sollte das Unterbinden von Zeilenumbrüchen unterbleiben, also in dieser Form: „Kontrabombarde0000“ oder „Trompette en chamade“.

@BurghardRichter: Was du vorschlägst widerspricht den Erklärungen von @PerfektesChaos: „Generell ist mit allen Aktivitäten, die eine Mindest-Spaltenbreite erzwingen oder irgendwo inhaltlich nicht erforderliche leere Flächen bewirken, große Zurückhaltung geboten. Was irgendein „Hauptautor“ sich mal für seinen Desktop-PC und sein persönliches Bildschirmfenster layoutet hatte, kann im Zeitalter von Smartphones katastrophal werden.“ Für Laien ist das Ganze viel zu kompliziert. Am Ende ist der Quelltext riesig aufgebläht und es klappt dann doch nicht so, wie man es sich vorgestellt hat. Grüße--Montrachet (Diskussion) 09:17, 2. Nov. 2022 (CET)

@Montrachet: Ich habe nicht den Eindruck, dass du dich unklar ausgedrückt hast. Du hast oben geschrieben: „Es gilt also, dass das Unterbinden von Zeilenumbrüchen unterbleiben soll, wie es hier [d.h. im umseitigen Abschnitt Hilfe:Tabellen #„Layout-Tabellen“] steht. Daher bitte ich dich Eliasorgel zukünftig keine {{0}} oder &nbsp; mehr einzufügen, wenn es nur darum geht, Zeilenumbrüche zu vermeiden.“

• Den zitierten Satz hast du falsch wiedergegeben, indem du die Einschränkung „wo nicht wirklich erforderlich“ weggelassen hast.
• Das {{0}} hatte Eliasorgel nicht zu dem Zweck gesetzt, einen Zeilenbruch zu verhindern, sondern um den Tabelleneintrag unsichtbar um die Breite einer Ziffer zu verlängern und dadurch optisch den Abstand zur nächsten Spalte zu vergrössern. Wenn dieses {{0}} mit einem gewöhnlichen Leerzeichen angeschlossen war, konnte es allerdings geschehen, dass es infolge eines Zeilenumbruchs in eine neue Zeile gesetzt wurde und dadurch die beabsichtigte Wirkung verfehlte. Um nun diesen – zu Recht unerwünschten – Zeilenbruch zu verhindern, hat er es kompress (d.h. ohne Zwischenraum) angeschlossen. Solch ein kompress gesetztes {{0}} hat praktisch den gleichen Effekt wie ein &nbsp;, insofern es scheinbar einen Leerraum erzeugt, an dem kein Zeilenbruch möglich ist. Die primäre Absicht war aber das Anfügen eines Leerraums; zu verhindern, dass dieser Leerraum in eine neue Zeile rutschte, ergab sich dann als sekundäre Notwendigkeit. Um zwischen zwei aufeinanderfolgenden Wörtern einen Zeilenbruch zu verhindern, ist es selbstverständlich nicht richtig, anstelle des Leerzeichens kompress eine unsichtbare Null dazwischenzusetzen, wie PerfektesChaos auch schon richtig festgestellt hat. Hierher gehört dann ein &nbsp;. Eine unsichtbare Ziffer ist grundsätzlich etwas anderes als ein Leerzeichen, und sie kann, je nach dem verwendeten Schriftfont, auch eine mehr oder weniger davon abweichende Breite haben. Anderenfalls brauchten wir das umbruchgeschützte Leerzeichen nicht, sondern könnten stattdessen immer eine unsichtbare Null verwenden – was aber einige Probleme nach sich ziehen würde.
• Wenn man anstelle eines gewöhnlichen Leerzeichens ein &nbsp; setzt, geht es immer darum, einen Zeilenbruch an der Stelle zu verhindern.
• Die Schreibweise „Trompette&nbsp;en&nbsp;chamade“ ist vollkommen korrekt, wenn es gute Gründe gibt, einen Zeilenbruch innerhalb dieses Ausdrucks zu verhindern. Das ist im laufenden Text kaum vorstellbar, in einer Tabelle aber durchaus möglich – zum Beispiel dann, wenn die dadurch bewirkte Verbreiterung der Spalte ein kleineres Übel ist als die sonst (möglicherweise) erfolgende Aufteilung des Ausdrucks in zwei Zeilen.
• Es geht bei allen hier diskutierten Möglichkeiten im Endeffekt darum, den Abstand zwischen zwei Spalten einer Tabelle zu vergrössern. Das kompresse Anfügen unsichtbarer Nullen wie auch das Hinzufügen von Paddings vergrössern die Spaltenbreite, indem sie innerhalb der Tabellenzellen inhaltlich nicht notwendigen Leerraum einfügen, und sind deshalb im Sinne von PerfektesChaos kritisch zu sehen. Dem schliesse ich mich an. Die direkte Vergrösserung des Spaltenabstands durch Border-spacing entspricht der Forderung von PerfektesChaos. Von den drei Möglichkeiten ist meines Erachtens die kompresse Anfügung unsichtbarer Nullen die schlechteste und Border-spacing die beste. --BurghardRichter (Diskussion) 13:40, 2. Nov. 2022 (CET)

border-spacing bezieht sich aber leider auf sämtliche Spalten der Tabelle und auch auf den linken Abstand. Das bläht Tabellen mit mehr als zwei Spalten ziemlich stark auf und dürfte schon deshalb unerwünscht sein. --Rodomonte (Diskussion) 13:55, 2. Nov. 2022 (CET)

Ja, das stimmt. Die Tabellen im Artikel Orgeln des Aachener Doms bestehen aber im wesentlichen nur aus zwei Spalten. Wenn man will, dass die Nummern am Anfang keinen so grossen Abstand vom jeweiligen nachfolgenden Registernamen haben, kann es sinnvoller sein, sie mit in deren Spalte einzubeziehen. In der Regel dürfte wohl kein Grund vorhanden sein, warum in einer Tabelle ohne vertikale Trennlinien unterschiedliche Abstände zwischen den Spalten notwendig sein sollten. Wenn man bei komplexeren Tabellen eine Gruppierung der Spalten wünscht, macht man das besser mit Trennlinien unterschiedlicher Stärke. Letztlich muss man immer die Vor- und Nachteile der verschiedenen Möglichkeiten gegeneinander abwägen. Selbstverständlich kann es dann in manchen Fällen sein, dass letztlich doch Paddings optimal sind. Linker Abstand: Ist es schlimm, wenn eine Tabelle ein klein wenig eingerückt ist?

Leider haben wir hier in der Wikipedia eine ausgesprochen schlechte Tabellensoftware, die mit zahlreichen Unzulänglichkeiten behaftet ist. Da lässt sich oft Flickwerk nicht vermeiden, um trotz dieser Mängel ein wenigstens halbwegs befriedigendes Ergebnis zu erreichen. Damit müssen wir leben. Wenn wir hier die Möglichkeiten hätten, wie es sie etwa in TeX gibt, dann könnten wir wunderschöne Tabellen mit allen Raffinessen produzieren. Damit würden allerdings über 90 % unserer Benutzer hoffnungslos überfordert sein. --BurghardRichter (Diskussion) 14:57, 2. Nov. 2022 (CET)

@BurghardRichter: Es geht Eliasorgel nicht darum, die Spaltenbreite zu vergrößern. Das siehst du falsch. In zahlreichen Beiträgen schreibt er „Layout Zeilenumbrüche vermieden“. An den Stellen, wo es von ihm gemacht wird, ist das Unterbinden von Zeilenumbrüchen nicht erforderlich. Und „Trompette en chamade“ kann auch in zwei Zeilen stehen. --Montrachet (Diskussion) 14:01, 2. Nov. 2022 (CET)

Ich weiss nicht, was Eliasorgel in anderen Artikeln gemacht hat. Wenn er dort andere Dinge gemacht hat, die er besser hätte lassen sollen, dann ist das ggf. ein anderes Thema. Selbstverständlich kann „Trompette en chamade“ in zwei Zeilen umbrochen werden – in laufendem Text in jedem Fall und grundsätzlich auch in einer Tabelle. Es kann aber auch sein, dass dieser Ausdruck als längster Eintrag in der Spalte nur wenig länger als der zweitlängste ist und man es als störend empfindet, dass nur dieser Eintrag als einziger in zwei Zeilen gebrochen wird. Das kann als grösserer Nachteil angesehen werden, als wenn im Alternativfall die Tabelle insgesamt ein ganz klein wenig breiter wird. --BurghardRichter (Diskussion) 14:57, 2. Nov. 2022 (CET)

Zellen übers Eck verbinden

Ist es möglich Zellen aus Tabellen die übers Eck gehen zu verbinden also so: Bild --Daniel Maak (Diskussion) 18:21, 23. Nov. 2022 (CET)

Hallo Daniel, du kannst die Abbildung optisch nachbauen, indem du einzelne Zellenumrandungen weglässt oder als nicht vorhanden überschreibst. Mir ist aber keine Möglichkeit bekannt, wie man die konkave Fläche links oben wie eine einzelne Tabellenzelle behandeln und beispielsweise mit Fließtext füllen kann. Hast du einen konkreten Anwendungsfall? --Wiegels „…“ 19:41, 23. Nov. 2022 (CET)