MediaWiki Diskussion:Common.css

Diese Common.css-Anweisungen werden gemeinsam von den verschiedenen Stylesheets aller Skins genutzt; siehe auch Hilfe:Skin.
Bitte Common.css nur für Anweisungen im Textfeldbereich und für 100%ig funktionierende (browser-, auflösungs- und skinunabhängige), zuvor geprüfte Ergänzungen verwenden, also nicht für absolute Positionierungen. --:Bdk: 14:02, 17. Dez 2005 (CET)/13:38, 18. Feb. 2008 (CET)

Automatische Archivierung

Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit 7 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind.

Archiv

2005 bis 2008 2009 bis 2012 ab 2013

Wie wird ein Archiv angelegt?

Anwendung der Definitionen

Rahmen- und Hintergrundfarben

Die in hier in MediaWiki:Common.css definierten Hintergrund- und Rahmenfarben sollen eine

• skinunabhängige und
• einheitliche

Farbgebung unterstützen. Auch hier gilt: weniger ist mehr.

Beachtet, dass die tatsächliche Farbgebung nicht festgelegt wird, dass eine Warnfarbe in einer anderen Umgebung beispielsweise nicht rot sondern weiß sein könnte und dass die Verwendung dieser Definitionen auch noch bei einer Ausgabe in Graustufen oder für eine Skinanpassung für Personen mit einer Farbsehschwäche Sinn machen soll.

Die hier definierten Farben sind als Beispiele für eine Standardausgabe zu verstehen; die Verwendung und eigentliche Definition sollte der angegebenen Beschreibung folgen und findet bei Bedarf in anderen CSS-Dateien statt.

Übersicht

Definiert sind rahmenfarbe1 bis rahmenfarbe5 und hintergrundfarbe1 bis hintergrundfarbe9.

rahmenfarbe1 Wie Inhaltsverzeichnis	rahmenfarbe2 Unauffällig, geringer Kontrast	rahmenfarbe3 „Rot“, auffällig
rahmenfarbe4 Neutrale Farbe, deutlich	rahmenfarbe5 „Schwarz“, hoher Kontrast
hintergrundfarbe1 Wie Inhaltsverzeichnis	hintergrundfarbe2 „Weiß“, für Nicht-Artikel-Seiten, neutral	hintergrundfarbe3 „Gelb“, auffällig
hintergrundfarbe4 Sehr auffällig	hintergrundfarbe5 Neutral, abgesetzt	hintergrundfarbe6 Allgemeine Hervorhebung, Unterscheidung
hintergrundfarbe7 Allgemeine Hervorhebung, Unterscheidung	hintergrundfarbe8 Allgemeine Hervorhebung, Unterscheidung	hintergrundfarbe9 Allgemeine Hervorhebung, Unterscheidung

---

H 1 + R 1	H 2 + R 1	H 3 + R 1	H 4 + R 1	H 5 + R 1	H 6 + R 1	H 7 + R 1	H 8 + R 1	H 9 + R 1
H 1 + R 2	H 2 + R 2	H 3 + R 2	H 4 + R 2	H 5 + R 2	H 6 + R 2	H 7 + R 2	H 8 + R 2	H 9 + R 2
H 1 + R 3	H 2 + R 3	H 3 + R 3	H 4 + R 3	H 5 + R 3	H 6 + R 3	H 7 + R 3	H 8 + R 3	H 9 + R 3
H 1 + R 4	H 2 + R 4	H 3 + R 4	H 4 + R 4	H 5 + R 4	H 6 + R 4	H 7 + R 4	H 8 + R 4	H 9 + R 4
H 1 + R 5	H 2 + R 5	H 3 + R 5	H 4 + R 5	H 5 + R 5	H 6 + R 5	H 7 + R 5	H 8 + R 5	H 9 + R 5

Beispiele

Diese Farben sind zur Verwendung für Textkästen und Tabellen gedacht. Sie werden als CSS-Klasse eingebunden. Dabei definieren die Rahmenfarben zusätzlich eine Strichstärke von 1px, so dass für einen dünnen Rahmen nur noch die Strichart festgelegt werden muss.

<div class="hintergrundfarbe5 rahmenfarbe3" style="border-style: solid; width: 200px; text-align: center;">Text im Kasten</div> erzeugt Text im Kasten

<div class="hintergrundfarbe1 rahmenfarbe4" style="border-style: solid; border-width: 3px; width: 200px; text-align: center;">Text im Kasten</div> erzeugt Text im Kasten

{| width="280" border="1" cellpadding="2" cellspacing="0" class="hintergrundfarbe2" |- ! colspan="2" class="hintergrundfarbe8" | Tabelle |- | Inhalt || Inhalt |} erzeugt Tabelle Inhalt Inhalt

Diskussion

float-right

Hallo, derzeit werden alle rechtsfließenden Elemente mit margin-top ausgerüstet. Das sieht aber nach Überschriften nicht gut aus. Daher schlage ich vor, folgenden Code zu ergänzen:

h1 + div.float-right,
h2 + div.float-right,
h3 + div.float-right,
h4 + div.float-right,
h5 + div.float-right,
h6 + div.float-right,
h1 + table.float-right,
h2 + table.float-right,
h3 + table.float-right,
h4 + table.float-right,
h5 + table.float-right,
h6 + table.float-right {
   margin-top: 0;
}

Eventuell könnte man das sogar für direkt formatierte Elemente einrichten:

h1 + *[style~="float:right;"],
h2 + *[style~="float:right;"],
h3 + *[style~="float:right;"],
h4 + *[style~="float:right;"],
h5 + *[style~="float:right;"],
h6 + *[style~="float:right;"] {
   margin-top: 0 !important;
}

meint -- ✓ ^Bergi 13:35, 29. Jul. 2010 (CEST)

Die zweite Regel ist schlecht. Wenn schon per style-Attribut float:right angegeben wird, dann sollte dort auch ein passender Abstand eingestellt werden können. Kannst Du ein paar Artikel nennen, um das Darstellungsproblem besser beurteilen zu können? --Fomafix 14:07, 29. Jul. 2010 (CEST)

Ja, die zweite Regel sollten wir wirklich besser weglassen. Allerdings muss dann auch wirklich überall die Klasse float-right verwendet werden, was noch nicht wirklich Standard ist. ALs Beispielartikel könnte man S-Bahn Berlin#Geschichte nennen. Sollte man die Selektoren auch noch über divs und tables hinaus ausweiten?
meint -- ✓ ^Bergi 15:23, 29. Jul. 2010 (CEST)

Den Abstand oberhalb von Tabellen mit float-right finde ich auch etwas groß. Es liegt vorallem daran, dass der Abstand von Fließobjekten nicht mit anderen Abständen zusammenfällt (http://www.w3.org/TR/CSS2/box.html#collapsing-margins). Eine solche spezielle Regel, die nur Überschriften im Artikel betrifft, finde ich allerdings etwas problematisch. Die obige Regel trifft beispielsweise nicht bei den häufigen Infoboxen und Tabellen am Artikelanfang ein. --Fomafix 13:30, 30. Jul. 2010 (CEST)

Stimmt. Man könnte noch ein #jump-to-nav + .float-right, #contentSub2 + .float-right, div.previewnote + .float-right, #shortcut + .float-right einfügen. Wahrscheinlich hab ich viel vergessen, das im Quelltext vor dem eigentlichen Artikelanfang kommt. Wie wäre es denn mit

.float-right {
   /*[...]*/
   margin: 0 0 1em 1em; /* statt 1em 0 1em 1em; */
}
p + .float-right,
dl + .float-right /*,
.float-right + .float-right ??? */ {
   margin-top: 1em;
}

Das dürfte doch der ursprünglich erwünschte Effekt sein. Imho deutlich leichter (kürzer), wenn man soherum an die Sache herangeht. Bloß hab ich hier vermutlich auch noch jede Menge mögliche Elemente vergessen.
meint -- ✓ ^Bergi 14:51, 30. Jul. 2010 (CEST)

Es ist ganz problematisch, so komplizierte Fallunterscheidungen zu machen, weil die Regel dann im Prinzip beliebig lang werden kann und man immer etwas übersieht, so dass Inkonsistenzen eintreten. Der Teil .float-right + .float-right ist auch problematisch, weil Float-Objekte aufeinanderfolgend gerendert werden können, auch wenn sie im Quelltext gar nicht unmittelbar aufeinanderfolgen. Wir sollten versuchen, die Regeln einfach zu halten.

Ich frage mich aber, ob Float-Objekte überhaupt einen so großen oberen Außenabstand brauchen. Da die Außenabstände von Float-Objekten nicht mit anderen Außenabständen zusammenfallen und andere Blockelemente außer Listen schon untere Außenabstände haben, erscheint mir 1em etwas exzessiv. Gruß --Entlinkt 19:31, 30. Jul. 2010 (CEST)

Hinweis: In Infoboxen wird der zu große obere Abstand manchmal mit einem hartkodierten style="margin-top: 0;" umgangen (Infobox Berg, Infobox Fluss, Infobox See usw.). --Entlinkt 18:32, 6. Aug. 2010 (CEST)

ich weiß, und das sollte eben nicht nötig sein. Zudem ist es eben auch nur bei manchen so. Bei der Vorlage wird aber auch nur davon ausgegangen, dass sie oben im Artikel eingesetzt wird, wenn nicht wäre vielleicht ein größeres margin-top besser. Den Abstand von 1em finde ich ganz OK, .float-right + .float-right kann man auch problemlos weglassen, das finde ich auch nicht so sinnvoll. Könntest du die Änderung bitte durchführen?
meint -- ✓ ^Bergi 12:11, 7. Aug. 2010 (CEST)

Mit Adjacent sibling selectors die Abstände von Fließobjekten zu beeinflussen ist generell schlecht, denn die Positionierung hängt von den anderen Fließobjekten ab. Nur eine generelle Verringerung von margin-top kommt daher in Frage. Thumbnails am rechten Rand verwenden beispielsweise margin: 0.5em 0 0.8em 1.4em. Firefox hat übrigens Probleme mit Textüberlappung, wenn breitere Fließobjekte durch ein schmaleres Fließobjekt nach unten verschoben wird, wie das Bild der Brooklyn Bridge im Artikel New York City. --Fomafix 14:38, 7. Aug. 2010 (CEST)

Benutzer:✓, ich kann die Änderung nicht durchführen, weil ich nicht weiß, welche.

• Ich stimme Fomafix zu, dass wir andersherum vorgehen sollten (wenn überhaupt), also für alle Floats margin-top verringern und dann sehen, wo der Abstand durch zu geringe margin-bottom an anderer Stelle zu klein wird.
• Floatierte Nicht-Thumbnails ([[Datei:Beispiel.jpg|right]]) haben sogar margin-top: 0, was ich u. U. auch interessant fände.
• Der Firefox-Bug ist bekannt (https://bugzilla.mozilla.org/show_bug.cgi?id=25888, Testfall), ich sehe aber ehrlich gesagt den Zusammenhang zu margins nicht. Der Firefox-Bug tritt übrigens oft in Zusammenhang mit der Sichtungsbox auf (jedoch nicht in Monobook, weil die Sichtungsbox in Monobook anders positioniert ist), und hiermit hätten wir schon auch das erste Beispiel für einen Float, dem ein margin-bottom fehlt (nämlich die Sichtungsbox).

Gruß --Entlinkt 04:17, 8. Aug. 2010 (CEST)

@Fomafix: Stimmt, es gibt wahrscheinlich Unregelmäßigkeiten bei im Quelltext nicht nacheinander stehenden Objekten, die dennoch aufeinander floaten. Die fände ich allerdings hinnehmbarer als die derzeitigen Probleme.

Mein neuer Vorschlag: margin-top: .4em; für alle float-Objekte – zumindest die mit Rahmen (auch Bilder). Das ist nämlich der margin-top für Absätze laut main.css (Achtung: dl hat .2em!), sodass dann sämtliche Objekte auf Oberkante nach/nebenstehenden Textes rutschen. …wenn sie nicht durch andere float-Objekte weitergerutscht werden. Gefühlt könnten sie auch noch ein bisschen höher stehen, die reale Textoberkante ist nicht unbedingt die wahrgenommene; imho ist von 0 bis 0.4em alles offen. Bei dem größerem Abstand nach Text (p + .float-right, dl + .float-right { margin-top: 1em; }) bin ich mir noch unsicher, er würde aufeinander gerutschte Elemente (<div class="float-right" /><p>kurzer Text.</p><div class="float-right" />) trennen, was zwar in einer Reihe merkwürdig aussehen kann, aber da sie ja tatsächlich nicht zusammengehören auch gar nicht so falsch ist.
meint -- ✓ ^Bergi 12:46, 8. Aug. 2010 (CEST)

div.float-right, table.float-right, .float-right { margin-top: 0.4em; } (ohne irgendwelche sonstigen Zusätze) ist ein Vorschlag, den man testen kann. Die Ausführungen zu Absätzen und Definitionlisten verwirren mich aber. Für Floats denselben margin-top wie für Absätze (oder Definitionslisten, oder was auch immer) zu verwenden, hat IMHO keinen Vorteil, weil Floats eigene Block-Formatting-Kontexte sind und Absätze nicht. Ihre margins verhalten sich deshalb völlig anders. (Es kann natürlich gern derselbe Wert genommen werden, falls er passt, aber nicht, weil er derselbe ist). --Entlinkt 14:56, 8. Aug. 2010 (CEST)

Demonstration, dass der margin-top-Wert nachfolgender Absätze für Floats völlig belanglos ist. Von Interesse ist vielmehr der margin-bottom-Wert des vorausgehenden Elements. Gruß --Entlinkt 16:48, 8. Aug. 2010 (CEST)

Mit Bug 33445 habe ich eine Reduzierung der Abstände von wikitable vorgeschlagen. In dem Zuge oder auch unabhängig davon könnten die Abstände für float-right und float-left reduziert werden. Vielleicht sollten diese CSS-Klassen auch in MediaWiki direkt aufgenommen werden, denn schließlich sind fließende Tabellen ein allgemeines Problem. --Fomafix 02:14, 9. Jan. 2012 (CET)

Es gibt bereits in MediaWiki die Klassen floatleft und floatright (ohne Bindestrich). --Fomafix 17:13, 30. Jan. 2012 (CET)

Ich versuche gerade herauszufinden, warum wir float-left und float-right definiert haben und nicht floatleft und floatright verwenden.

Hier die aktuellen Definitionen zusammengefasst zum Vergleich:

MediaWiki:Common.css:

/* @noflip */div.float-left,
table.float-left,
ul.float-left,
.float-left {
	clear: left;
	float: left;
	margin: 1em 1em 1em 0;
}
/* @noflip */div.float-right,
table.float-right,
ul.float-right,
.float-right {
	clear: right;
	float: right;
	margin: 1em 0 1em 1em;
}

svn:trunk/phase3/skins/common/shared.css:

/* @noflip */ div.tright,
div.floatright,
table.floatright {
	clear: right;
	float: right;
}
/* @noflip */ div.tleft,
div.floatleft,
table.floatleft {
	float: left;
	clear: left;
}
div.floatright,
table.floatright,
div.floatleft,
table.floatleft {
	position: relative;
}

svn:trunk/phase3/skins/common/commonContent.css:

/* @noflip */div.floatright, table.floatright {
	margin: 0 0 .5em .5em;
	border: 0;
}
div.floatright p { font-style: italic; }
/* @noflip */div.floatleft, table.floatleft {
	margin: 0 .5em .5em 0;
	border: 0;
}
div.floatleft p { font-style: italic; }

Die Unterschiede gegenüber unseren Definitionen sind:

• Abstand nach oben 0 (Wird hier ebenfalls vorgeschlagen)
• Abstand zur Seite und unten 0.5em (Der Seitenabstand ist mir etwas zu wendig, der Abstand unten reicht aber meiner Meinung nach)
• position:relative (Spezialanwendung vorstellbar, aber bei uns ist das ein Stopper für unsere absolut positionierten Elemente wie Artikel-Koordinaten rechts oben, die üblicherweise in Infoboxtabellen erzeugt werden.)
• border: 0 (Seltsame Definition. Kein Rahmen ist doch Standard. wikitable überschreibt den Rahmen dann wieder.)
• div.floatleft p { font-style: italic; } (Ein seltsames Gimik, das Absätze kursiv macht, einzelne Zeilen aber nicht.)

Beispiele zum Vergleich:

Box

Zeile

<div class="float-right">Box{{Coordinate}}
Zeile
</div>

Box

Zeile

<div class="floatright">Box{{Coordinate}}
Zeile
</div>

Wegen der seltsamen Zusatzdefinitionen bin ich mit den CSS-Klassen von MediaWiki nicht so glücklich. Ein Verringern auf margin-top:0 und margin-bottom:0.5em bei uns finde ich aber akzeptabel. --Fomafix 22:15, 30. Jan. 2012 (CET)

Nur zur Info: Das position:relative hat m. E. nichts mit einer Spezialanwendung zu tun, sondern ist nur ein Workaround für einen alten IE-6-Bug, den kaum jemand mehr kennt (wir haben das auch noch in Vorlage:Bausteindesign1 usw. und hatten es zeitweise auch an den Navigationsleisten und haben es immer noch an der Klasse div.sideBox). --Entlinkt (Diskussion) 17:52, 12. Mai 2013 (CEST)

Das habe ich auch vermutet. Meiner Meinung nach wäre es langsam an der Zeit diese Workarounds für den IE6 zu entfernen. Als Grade B sollte reichen, wenn an manchen Stellen der Hintergrund nicht sichtbar ist. Lesbar bleibt es ja weiterhin. Gibt es dazu bereits einen Bug? --Fomafix (Diskussion) 17:57, 12. Mai 2013 (CEST)

Ich habe keinen Bug zu diesem Thema gefunden. Aber vielleicht sollte man wirklich einen Bug zum Aufräumen von floatright und floatleft melden.

Diese beiden Klassen werden von MediaWiki verwendet, wenn man Bilder mit |right oder |left (ohne |thumb) einbindet (und anscheinend auch für nichts anderes). Für diesen Zweck genügt der Teil

div.floatright,
table.floatright {
	clear: right;
	float: right;
	margin: 0 0 .5em .5em;
}
div.floatleft,
table.floatleft {
	float: left;
	clear: left;
	margin: 0 .5em .5em 0;
}

Die Zusatzdefinitionen schaden dabei erstmal nicht, verhindern aber andere Nutzungen. Idealerweise könnten dabei auch die Abstände wie gewünscht eingestellt werden und wir bräuchten unsere eigenen Klassen mittelfristig nicht mehr. --Entlinkt (Diskussion) 21:05, 14. Mai 2013 (CEST)

Schlichte Buch-Tabellen?

Gibt es schon sowas wie ein Format für schlichte Tabellen, wie in gedruckten (wissenschaftlichen) Büchern? Vorschlag ähnliches CSS, wie:

/* Buchtabelle wie in (wissenschaftlichen) Büchern  */
table.Buchtabelle, table.BuchtabellePunktiert {
    margin: 1em 1em 1em 0;
    background: #ffffff;
    border-top:    2px #656463 solid;
    border-bottom: 2px #656463 solid;
    border-collapse: collapse;
}
.Buchtabelle td {
  border: 0px; padding:4px;
}
.BuchtabellePunktiert td {
  border-bottom: 1px dotted grey;padding:4px;
}
 
.Buchtabelle th, .BuchtabellePunktiert th{
    vertical-align:bottom;
    border-bottom:1px solid #656463;
    border-top:   1px solid #656463;
    border-left:0px;
    border-right:0px;
    padding: 4px;
}
.Buchtabelle th, .BuchtabellePunktiert th{
  background: #ffffff;
  text-align: center;
}
 
.Buchtabelle caption {
   /* font-weight: bold; */ /* eventuell zu fett */
}

Beispiel

Beschriftung für Tabelle

Spaltenkopf 1	Spaltenkopf 2	Spaltenkopf 3
1. Zeile: Zelle 1	1. Zeile: Zelle 2	1. Zeile: Zelle 3
2. Zeile: Zelle 1	2. Zeile: Zelle 2	2. Zeile: Zelle 3

--A.Plank 05:44, 1. Aug. 2010 (CEST)

Und zu was soll das gut sein? -- Chaddy · D – DÜP – 06:26, 1. Aug. 2010 (CEST)

Für kleinere Zusammenstellungen von Daten ist das übersichtlicher und sieht besser aus als wikitable. --Sepp (Diskussion) 13:18, 18. Feb. 2014 (CET)

toptextcells für th

"wikitable toptextcells" aktuell

th	td
td	th

"wikitable toptextcells" gemäß Vorschlag

th	td
td	th

Hallo, ich hätte gerne eine Ergänzung zur Klasse toptextcells: Kann bitte jemand die Definition auf <th>-Elemente ausweiten? Siehe auch WP:WVW#Vorlage:Infobox Rennstrecke, in Infoboxen wird nämlich oft die linke Zelle als th realisiert, meist ist gerade für sie das toptextcells in Infoboxen nötig.
meint -- ✓ ^Bergi 16:44, 10. Okt. 2010 (CEST)

Es könnte Absicht sein, dass th-Elemente im Hinblick auf vertical-align ausgenommen sind, schließlich sind sie es im Hinblick auf text-align auch. Wenn aber dieser Vorschlag umgesetzt wird, dann bitte die Definition so ersetzen:

.toptextcells td { vertical-align: top }
.toptextcells tbody { vertical-align: top }

Da vertical-align innerhalb von Tabellen ab tbody abwärts vererbt wird (HTML4, HTML5), hat dies denselben Effekt, verhindert aber, dass wir uns dasselbe Problem wie mit den Hintergrundfarben nochmal einhandeln. Gruß --Entlinkt 19:33, 10. Okt. 2010 (CEST)

Gute Idee, sollte man eventuell (gleich) noch thead und tfoot einbeziehen? Und: unterstützen alle Browser das tbody, es wird im Quelltext ja nicht ausgeliefert? -- ✓ ^Bergi 15:34, 11. Okt. 2010 (CEST)

In HTML gibt es immer ein tbody-Element, egal ob es im Quelltext notiert ist:

Omitting an element's start tag does not mean the element is not present; it is implied, but it is still there. ...

... If a tr element is put inside a table in the markup, it will in fact imply a tbody start tag before it.

thead und tfoot gibt es zurzeit nicht, also egal.

Ansonsten würden mich andere Meinungen interessieren. Gerade das Beispiel mit der Vorlage:Infobox Rennstrecke überzeugt mich noch nicht wirklich. Man betrachte diese Infobox mal im IE 8, in dem th { text-align: center } gilt (was übrigens standardkonform ist; in allen anderen Browsern verhält sich text-align auf eine merkwürdige Weise, die man in Standard-CSS gar nicht ausdrücken kann).

Das derzeitige (sinngemäße) th { vertical-align: middle } ist ein IMHO durchaus logisches Gegenstück zu th { text-align: center }. Und die Klasse wird sicherlich hundertfach verwendet; wer hat den Überblick, ob der Vorschlag überall passt? --Entlinkt 19:21, 11. Okt. 2010 (CEST)

Mit dem Browser meinte ich eigentlich, ob das auch die alten unterstützen. Deine Links richten sich auf „Working Drafts“ für „Spezifikationen“, dass die neueren Browser das schon so machen weiß ich auch. Aber die alten werden auch andere Probleme haben; und so entscheidend ist toptextcells jetzt auch nicht.

Ich denke nicht dass es Designprobleme geben wird, die Klasse wird in der Regel in Infoboxen und in Listen-in-Spalten-Tabellen eingesetzt, da wäre der Effekt durchaus erwünscht. Einen Komplettüberblick wird eh keiner geben könne. Das „logische Gegenstück“ überzeugt mich nicht, denn genau um diese völlige Zentriertheit aufzuheben ist toptextcells doch da. Ich bin für Umsetzen, zurückrudern kann man immer noch. Aus meiner Sicht überwiegen die Vorteile alle eventuell anfallenden Nachteile.
meint -- ✓ ^Bergi 19:13, 24. Okt. 2010 (CEST)

Zu Browsern: Ja, alle Browser unterstützen es (das Vererben von vertical-align von tbody an tr und weiter an td und th) schon seit den 90er-Jahren. Das veraltete valign-Attribut wurde schon in dieser Weise vererbt und sinngemäß in CSS übernommen.

Zum Vorschlag an sich: Siehe die beiden Beispiele oben rechts. Ich meine nicht, dass der Vorschlag den Infoboxen weiterhilft, weil die th-Zellen immer noch horizontal zentriert sind und in Infoboxen weder vertikal noch horizontal zentriert sein sollen, wenn die ganze linke Spalte aus th-Zellen besteht. Eigentlich sollen sich die Spalten in den Infoboxen nur dadurch unterscheiden, dass die Schrift in der linken Spalte fett ist. Ich weiß aber nicht, ob es überhaupt richtig ist, die linke Spalte aus th-Zellen zusammenzubauen und dann alle Formatierungseffekte außer der Fettschrift wieder abzuschalten. Die Entscheidung zwischen th und td ist eigentlich anhand der Semantik zu treffen, nicht anhand der Formatierung; wenn's nur um die Fettschrift geht, kann man auch td nehmen und den Inhalt zellenweise fett formatieren.

Soweit ich das sehe, sind es auch gar nicht so viele Infoboxen, bei denen die linke Spalte aus th-Zellen besteht (Gegenbeispiele sind die 3 meistbenutzten Infoboxen: Infobox Film, Infobox Fußballspieler, Infobox Verwaltungseinheit in Deutschland). Wie es semantisch am sinnvollsten ist, weiß ich leider selbst nicht ganz sicher, die Semantik ist aber bei allen Boxen gleich, insofern sollte eigentlich auch die Verteilung von th und td bei allen Boxen gleich sein. Gruß --Entlinkt 16:24, 31. Okt. 2010 (CET)

Das W3C verwendet das <th>-Tag auch neben <td>, genannt „Vertical headers“. Semantisch halte also nicht nur ich es für sinnvoll.

Designtechnisch ist es halt schöner, wenn auch die linken Zellen links oben ausgerichtet sind, oben vor allem halt bei mehrzeiliger Info im Feld daneben. Für links gibt es style="text-align:left;, das bei nicht-wikitables auch von der Tabelle an alle (auch th) Zellen vererbt wird, für oben ist die Klasse toptextcells das designierte Werkzeug.

Eventueller Kompromissvorschlag: table.infobox.toptextcells tbody { vertical-align: top; } sollte Auswirkungen auf „normale“ Tabellen beseitigen.

Ach ja: Wenn ich genau darüber nachdenke, müssten Infoboxen nicht semantisch korrekt so aufgebaut werden? :-)

<div class="infobox" style="display:table;">
  <dl style="display:table-row-group;">
    <div class="one-defintion" style="display:table-row;"><!-- kein passendes Element? -->
      <dt style="display:table-cell;">Name:</dt>
      <dd style="display:table-cell;">Alan Turing</dd>
    </div>
    …
  </dl>
  …
</div>

meint -- ✓ ^Bergi 18:23, 31. Okt. 2010 (CET)

w3schools gehört nicht zum W3C. Unabhängig davon ist mir schon klar, dass man th und td auch in einer Zeile mischen kann, aber man muss es anscheinend nicht (jedenfalls tun die allermeisten Infoboxen es nicht), und es löst bei der besagten Vorlage:Infobox Rennstrecke auch nicht das Problem, weil text-align im IE 8 (mindestens, evtl. auch 9), wie oben bereits gesagt, eben nicht von tr an th vererbt wird. Siehe auch: en:MediaWiki talk:Common.css/Archive 12#Table header inheritance in IE8.

Ob man das nun als Bug im IE 8 oder als Bug in allen anderen Browsern betrachtet (meiner Meinung nach eher letzteres), ist letztlich müßig, weil es einfach so ist und nicht zu ändern ist. Das Problem mit der Vorlage:Infobox Rennstrecke ist mit diesem Vorschlag nicht zu lösen, und wozu es sonst gut sein soll, sehe ich eben nicht.

Alternativvorschlag: In Vorlage:Infobox Rennstrecke die th durch td ersetzen und die Schrift in der linken Spalte mit der üblichen Wiki-Formatierung fett machen. Dann braucht es weder diese Anpassung noch text-align:left und funktioniert auch im IE 8. Gruß --Entlinkt 01:38, 18. Nov. 2010 (CET)

Ich bin da gelandet, weil ich eigentlich die vorgeschlagene Änderung gutgeheißen habe. Mein Beispiel ist die Vorlage:Infobox Whisky-Destillerie. Mit dem Beispiel unten bei header in der 1. Zeile bin ich aber unsicher geworden, welche Variante hier die bessere ist:

kurz	mit manuellem Umbruch	Das ist ein viel zu langer Headertext	noch eine Spalte	und noch eine

oder:

kurz	mit manuellem Umbruch	Das ist ein viel zu langer Headertext	noch eine Spalte	und noch eine

lg --Herzi Pinki 01:56, 18. Nov. 2010 (CET)

Vorlage:Infobox Whisky-Destillerie ist wieder was anderes, weil es eine wikitable ist und die th-Elemente deshalb auch farblich abgesetzt und in jedem Browser horizontal (Warum dann nicht auch vertikal?) zentriert sind. In der Vorlage:Infobox Rennstrecke ist offenbar beabsichtigt, dass die th-Elemente nur durch Fettschrift hervorgehoben sein sollen.

Infoboxen finde ich aber eigentlich gar nicht so entscheidend … es ist kein Akt, in einer Infobox ein paarmal style="vertical-align:top" einzufügen, wenn man das haben möchte. Sorgen mache ich mir eher über die unbekannte Zahl von Artikeln, in denen direkt class="wikitable toptextcells" benutzt wird. (Infoboxen wären idealerweise alle gleich aufgebaut und würden dieselben Klassen verwenden; siehe auch Wikipedia:Meinungsbilder/Vereinheitlichung der Infoboxen). --Entlinkt 02:17, 18. Nov. 2010 (CET)

Auch wenn ich die Zahl der Verwendungen von wikitable toptextcells ziemlich gering einschätze, gibt es immer noch die Möglichkeit auf table.infobox.toptextcells einzuschränken. Natürlich ist immer die Möglichkeit gegeben, das CSS über das style-Attribut überall einzeln einzusetzen. Im Sinne des guten Webdesigns und der Quelltextfereinfachung würde ich dies jedoch gerne über Stylesheets lösen. Statt umständlichen <td style="vertical-align:top;"><b>Text</b>… würde mir eher ein Konstrukt â la table.infobox td:first-child { vertical-align: top; font-weight: bold; } zusagen. Auch wegen diverser Probleme mit first-child wäre die Implementierung in die bereits vorhandene Klasse toptextcells aber imho am einfachsten. Zum IE-Bug: Eine Alternativlösung wäre auch eine eigene, neue Klasse toptextheaders. Wäre das OK?
meint -- ✓ ^Bergi 18:51, 18. Nov. 2010 (CET)

Selektoren mit 2 Klassen an einem Element wie table.infobox.toptextcells funktionieren im IE 6 nicht.

Im Sinne des guten Webdesigns wäre vor allem eine Vereinheitlichung der Infoboxen … Die Boxen müssen nicht alle plötzlich gleich aussehen, aber wenigstens das Markup (also die Verteilung von td und th) sollte meiner Meinung nach gleich sein, weil td und th semantisch nun mal nicht dasselbe sind und das Markup sich nach der Semantik und nicht nach dem Aussehen richten soll. Was nun semantisch sinniger ist, weiß ich nicht sicher, aber die Verwendungshäufigkeit spricht IMHO klar dafür, dass Infoboxen für beide Spalten td verwenden. Was wiederum heißt, dass die th in Vorlage:Infobox Rennstrecke nur dem Erzielen eines optischen Effekts (Fettschrift) dienen und somit der falsche Weg sind … Wenn aber die th in der linken Spalte semantisch sinnvoll wären, dann wären sie das in allen Infoboxen, was wiederum heißen würde, dass wir eine weitere Klasse zum Abschalten der Fettschrift bräuchten, weil sie in den meisten Boxen nicht gewünscht ist.

Alles in Allem kann das .toptextcells tbody { vertical-align: top } natürlich eingefügt werden (so wichtig isses nun auch wieder nicht, ob es irgendwo ein Problem damit gäbe, das wahrscheinlich eh kaum jemandem auffällt), löst aber meiner Meinung nach kein Problem. Das Problem mit der Vorlage:Infobox Rennstrecke löst es jedenfalls nur unvollständig, und denselben optischen Effekt (Zellen, die einfach nur fett, aber ansonsten gleich sind) kann man auch einfacher haben. --Entlinkt 21:43, 18. Nov. 2010 (CET)

en:Template:Wikicite (Vorlage für Nachweis)

Hallo, ich versuche diese Vorlage in die deutsche WP einzubauen. Diese Vorlage soll helfen aus dem Fließtext heraus auf ein Buch, das unter der Überschrift Literatur steht, zu zeigen und diese Zeile blau färben. Ähnlich wie es eben ein Einzelnachweis macht. Meine Testseiten sind zur Zeit Benutzer:Christian1985/Spielwiese/Vorlage:Referenz und Benutzer:Christian1985/Spielwiese#Testabschnitt. Das das Springen zum Buch klappt soweit, aber damit die entsprechende Zeile farbig hinterlegt wird, brauche ich noch die Zeile

span.ref:target { background: #def; }

CSS-Code. Diese müsste wahrscheinlich auf dieser Seite eingefügt werden. Aber ich gehe davon aus, dass es nicht gerne gesehen wird, wenn jeder an dieser Datei rumbastelt. Kann mir jemand weiterhelfen? --Christian1985 (Diskussion) 03:07, 4. Feb. 2011 (CET)

Die Seite ist eh gesperrt (und das aus gutem Grund). Bevor du solche Vorlagen einfügst, bitte erstmal absprechen und Konsens herstellen, etwa auf WP:FZW oder Hilfe Diskussion:Einzelnachweise. --91.22.243.115 12:05, 4. Feb. 2011 (CET)

Danke für die Reaktion, bis jetzt hatte ich nur in der Seite der Vorlagenwerkstadt probiert und dort keine Reaktion bekommen. Zur Zeit probiere ich es auf WP:FZW. Viele Grüße --Christian1985 (Diskussion) 16:22, 4. Feb. 2011 (CET)

metadata

metadata-inline kann entfallen, da inzwischen alles auf metadata umgestellt wurde (MediaWiki Diskussion:Gadget-Personendaten.css). --Fomafix 12:22, 23. Feb. 2012 (CET)

table.metadata {
	border: 1px solid #aaa;
}
.metadata-label {
	color: #aaa;
}

ist für Anwender ohne das Gadget wirkungslos. Es könnte daher nach MediaWiki:Gadget-Personendaten.css verschoben werden, damit es nicht für alle Benutzer immer geladen wird. Allerdings gibt es noch Benutzer, die sich die Metadaten mit eigenen CSS-Definitionen einblenden und vermutlich nicht das Gadget aktiviert haben. --Fomafix 12:22, 23. Feb. 2012 (CET)

Eine Suche nach \.metadata\b über alle JS/CSS-Benutzerseiten ergibt 1587 Seiten. Das ist etwas viel, würde ich sagen, um das zentral auszublenden. Der Umherirrende 17:08, 3. Mär. 2012 (CET)

Ich verstehe Deine Antwort nicht ganz. Ich habe gesagt: „metadata-inline kann entfallen“. Wird das noch irgendwo verwendet? .metadata { display: none; } muss selbstverständlich erhalten bleiben. --Fomafix (Diskussion) 18:43, 3. Mär. 2012 (CET)

Meine Antwort bezog sich auf die mögliche Verschiebung des Layouts und die Anmerkung darin, das es noch Benutzer in der eigenen CSS stehen haben. \.metadata-inline\b gibt Treffer auf 19 Benutzer-JS/CSS-Seiten, weil es so wohl in PDD's monobook.css drin vorkommt. Der Umherirrende 18:50, 3. Mär. 2012 (CET)

Aber eigentlich müsste man dafür ein Scan über Artikel/Vorlagen machen, nur habe ich die gerade nicht im Zugriff. Der Umherirrende 18:59, 3. Mär. 2012 (CET)

Vor einem Jahr habe ich alle metadata-inline auf metadata umgestellt und daraufhin metadata-inline auf MediaWiki:Gadget-Personendaten.css entfernen lassen. Das metadata-inline hier habe ich nur übersehen. Ob jemand noch eine nicht mehr benötigte CSS-Definition in seiner CSS-Datei hat, spielt keine Rolle für die Entfernung von metadata-inline hier. Entscheidend ist nur, ob metadata-inline noch in Artikeln oder Vorlagen verwendet wird. --Fomafix (Diskussion) 22:01, 3. Mär. 2012 (CET)

Da per Gadget sowieso nicht mehr sichtbar gemacht wird, habe ich es entfernt. Das Verschieben des Layouts für die Metadaten in das Gadget geht aufgrund der individuellen Einblendungen nicht, hier ist Abwärtskompatibiltät gefragt (Früher gab es das Gadget ja nicht, sondern nur per skin.css). Der Umherirrende 22:07, 3. Mär. 2012 (CET)

Abwärtskompatibilität ist gut und recht, aber wie lange wollen wir die beiden CSS-Definitionen table.metadata { border: 1px solid #aaa;} .metadata-label { color: #aaa;} hier noch für alle Benutzer laden lassen, statt sie in das Gadget zu übertragen? --Fomafix (Diskussion) 22:39, 3. Mär. 2012 (CET)

Keine Ahnung, da aber möglicherweise 1500 Benutzer betroffen sind, geht es aus meiner Sicht nicht. Muss erst eine Flurbereinigung her. Der Umherirrende 22:45, 3. Mär. 2012 (CET)

Es geht nur um einen grauen Rahmen und eine Schriftfarbe. Zu sehen sind die Informationen auch für die betroffenen Benutzer, die sich die Metadaten ohne Gadget einblenden. --Fomafix (Diskussion) 23:11, 3. Mär. 2012 (CET)

Ich fände es nicht so gut, wenn auf einmal die Personendaten ohne Rand daher kommen, ohne das man mir etwas gesagt hat, daher bin ich gegen die Änderung. Der Umherirrende 23:28, 3. Mär. 2012 (CET)

Ich will die Formatierung ja nicht abschaffen, sondern ins Gadget verschieben. Alternativ könnte die Formatierung auch in die Vorlage:Personendaten verschoben werden. Per mw:Manual:UserOptions.php könnte auch das Gadget für alle Benutzer aktiviert werden, die ".metadata" in ihren CSS-Dateien haben. --Fomafix (Diskussion) 23:39, 3. Mär. 2012 (CET)

Oder man nötigt die Benutzer mit selbstaktivierten Metadaten zum Aktivieren des Gadgets, indem in die Vorlage:Personendaten eine auffällige Meldung mit class="metadata nogadget" positioniert wird und blendet diese im Gadget mit .nogadget { display: none } aus. --Fomafix (Diskussion) 23:53, 3. Mär. 2012 (CET)

Ich würde den zuletzt gemachten Vorschlag im Prinzip unterstützen; allerdings nicht als „auffällige Meldung“:

1. Funktional bleibt für die Benutzer alles gleich; ggf. auch hier in der Common.css unverändert.
2. In die dadurch ein/ausgeblendete Box wird pfiffig eine Unterzeile/Unterbox eingeblendet, die nur diejenigen sehen können, die irgendetwas mit den fraglichen Elementen angestellt haben (Vorlagenprogrammierung).
3. In dieser Box befindet sich ein Kurzhinweis „Du verwendest veraltetes CSS – bitte entfernen“, das Linktitel für eine Unterseite von Vorlage:Personendaten ist, in der erklärt wird, dass die Leute
   • aus ihrer persönlichen CSS das entfernen sollen (Was ist das? Wie geht das? Was für Seiten?)
   • auf Helferlein ankreuzeln sollen, was sie haben wollen (Was für ein Ding? Wie heißt das? Wo muss ich mein Putin-Kreuz machen?).
4. Das Info-Link kann hier auf Common.css durch irgendein geniales .metadata #oldCSSMetadata sichtbar/unsichtbar gemacht werden.
5. 6–12 Monate abwarten.
6. Danach komplett entfernen.
   • Wir haben Tausende offenkundig inaktiver Benutzer, in deren JS/CSS sonstwelches vergammeltes Zeug herumsteht.
   • Wir können nicht jeden Mist von 2003 auf ewige Zeiten unterstützen.
   • Es wäre unfair, es technikunkundigen Leuten unterm Keyboard wegzuziehen, sie stundenlang rätseln und schließlich auf FzW aufschlagen zu lassen.
   • Wer dann nach einem halben Jahr nicht eingeloggt war, nicht auf Personenartikeln war, nichts getan hat … dem wird das auch nicht auffallen. Zumal es offenbar nur um einen Rahmen geht.
7. Das wird noch häufiger zu exorzieren sein.

HGZH --PerfektesChaos (D) 14:09, 5. Mär. 2012 (CET)

Ich finde das einen gigantischen Aufwand und das nur wegen einem Rahmen und etwas grauer Schrift. Ich vermute mal, dass es trotz eines Hinweistextes in 6–12 Monaten weiterhin über 1000 Treffer auf /\.metadata/ in den Benutzer-CSS-Dateien geben wird.

Meiner Meinung nach sollte die Formatierung einfach in die Vorlage verschoben werden. So wird das schließlich auch bei allen anderen Vorlagen gemacht. --Fomafix (Diskussion) 15:25, 5. Mär. 2012 (CET)

Falls jemand das CSS in die Vorlage verschiebt, dann bitte ich darum bei der Gelegenheit den Personendaten auch eine eindeutige ID zu geben, wenn man derzeit die PD im DOM finden will, muss man so komische Verrenkungen wie $('table.metadata:has(a[title="Hilfe:Personendaten"])') vornehmen. --Schnark 09:19, 6. Mär. 2012 (CET)

Das ist richtig. Ist id="Personendaten" in Ordnung? Oder gibt das ein Problem, falls mal eine Überschrift == Personendaten == existiert? Ist .metadata-label überhaupt noch notwendig, falls die Formatierung in der Vorlage ist? --Fomafix (Diskussion) 10:41, 6. Mär. 2012 (CET)

Großgeschriebene IDs sehen in meinen Augen immer etwas merkwürdig aus, sodass ich id="personendaten" bevorzugen würde. Dann käme es auch zu keiner Kollision mit Überschriften (zumindest nicht, wenn der Schreibende sich an die Rechtschreibregeln hält). Wenn man vorsichtig sein will, kann man immer noch per table#personendaten selektieren.

.metadata-label wird auch anderweitig benutzt, etwa in {{Infobox Gemeinde in Frankreich}} (die Suche findet noch mehr). --Schnark 11:04, 6. Mär. 2012 (CET)

Zur Id in den Personendaten: Viele Vorlagen haben eine id in der Form Vorlage_Personendaten. Würde das hier auch Sinn machen? oder besser nur Personendaten? Der Umherirrende 21:31, 10. Apr. 2012 (CEST)

Eine Id ist in der Zwischenzeit schon dazugekommen. Der Umherirrende 21:41, 15. Jan. 2013 (CET)

Ich würde es hier drin lassen, weil es zuviele Altlasten sind. Früher wurde es für die User.css beworben (weil es keine Alternativen gab), da kann man jetzt schlecht sagen, wir vernachlässigen diese Benutzer jetzt. Bereinigen der User.css von einem Admins wird wohl auch ungern gesehen. Besser wäre es, das Gadget bei den Benutzern zu aktivieren, das bekommt man aber nicht hin (und das ist auch gut so). Hier darf sich gerne jemand anders austoben. Der Umherirrende 21:41, 15. Jan. 2013 (CET)

Ich habe mich mal in der Form „ausgetobt“, dass der Rahmen jetzt in der Vorlage über die Klasse rahmenfarbe1 erzeugt wird. Aus der Common.css kann der Rahmen also im Prinzip entfernt werden, und ich fände das auch recht logisch, weil es dadurch möglich wird, mit class="metadata rahmenfarbeX" (X ≠ 1) abweichend formatierte Tabellen zu erzeugen (bislang geht das wegen der Spezifitäten nicht). Ich mach’s jetzt nur deshalb nicht, um abzuwarten, welche anderen Vorlagen sich auch darauf verlassen, dass der Rahmen hier erzeugt wird.

Wenn die Schriftfarbe auch von hier entfernt würde, hielte ich das (im Gegensatz zum Rahmen) für eine relativ geringe Beeinträchtigung, irgendwer würde sich bestimmt darüber ärgern, aber ich halte es für vertretbar. Mal sehen. --Entlinkt (Diskussion) 02:13, 26. Mai 2013 (CEST)

Ich habe die Schriftfarbe nach Vorlage:Personendaten verschoben und die Klasse metadata-label hier entfernt (alle anderen Verwendungen waren sowieso wirkungslos, weil sie sich auf Links bezogen, die trotz Klasse blau waren), möchte aber gerne auf das folgende, neue Problem hinweisen: Wikipedia:Technik/Werkstatt#Kollision zwischen MediaViewer und Personendaten-Gadget. --Entlinkt (Diskussion) 01:24, 9. Mai 2014 (CEST)

MediaWiki:Mobile.css: Farbdefinitionen etc.

• Ursprünglicher Titel: Tabellendarstellung (insbesondere der Hintergrundfarben) in der mobilen Version
• von: WP:Verbesserungsvorschläge/Feature-Requests

In der Version für Mobilgeräte werden Tabellen ungünstig dargestellt. In Eintracht Braunschweig werden die Tabellen mit den Saisondaten komplett gelb hinterlegt. Das in einzelnen Zeilen verwendete Attribut class="hintergrundfarbe5" wird ignoriert. Ist dies ein Bug (von was?) oder ein Feature? --cwbm 19:55, 31. Mär. 2013 (CEST)

Sollte vielleicht aus MediaWiki:Common.css auch zu MediaWiki:Mobile.css hinzugefügt werden. Was würde da noch alles Sinn ergeben?--se4598 / ? 22:58, 31. Mär. 2013 (CEST)

• Das ist offensichtlich der Grund. Gut gemacht!
• Die Frage wäre wohl eher, was aus Common.css nicht mobil gemacht werden solle.
  • Möglicherweise einige margin/padding platzsparender, und bei font-size müsste sich jemand zur Lesbarkeit äußern. Vielleicht cwbm als Versuchskarnickel; weitere Anregungen?
• Ich empfehle die Fortsetzung der Disku in der Skin-Werkstatt oder unter MediaWiki:Common.css.
  • MediaWiki:Mobile.js ist noch leer.

Schnee im Mai – April vorbei. --PerfektesChaos 12:34, 1. Apr. 2013 (CEST)

Nur kurz: Die mobile Darstellung kann man im Browser über http://de.m.wikipedia.org/ oder ?useformat=mobile testen (sagt aber nichts über die Kompatibilität mit Mobilgeräten aus)--se4598 / ? 14:58, 1. Apr. 2013 (CEST)

Warum nicht klein anfangen und erst einmal nur den Abschnitt mit allen Rahmen- und Hintergrundfarben kopieren. Einfach 1:1. Falsch kann das meiner Ansicht nach nicht sein. Über den Rest kann man immer noch sprechen. --TMg 20:44, 1. Apr. 2013 (CEST)

Habe mal etwas rüberkopiert. Der Umherirrende 14:36, 3. Apr. 2013 (CEST)

So meinte ich das, danke. Aber warum bewirkt das nichts? Die Datei MediaWiki:Mobile.css scheint dort gar nicht zu greifen. --TMg 18:26, 3. Apr. 2013 (CEST)

scheint zurzeit Bugzilla:46480 zu sein--se4598 / ? 19:36, 3. Apr. 2013 (CEST)

Der Bug steht auf FIXED. Ich kann jetzt nicht sagen, ob es schon live ist, sollte aber ansonsten am 8. Mai dabei sein. Der Umherirrende 09:40, 2. Mai 2013 (CEST)

toptextcells für th zum Zweiten

Beispiel-Infobox

Label 1 mit mehr als einer Zeile	Oben ausgerichtet
Label 2	Im Gegensatz dazu ist diese Zeile nicht oben ausgerichtet

Die Diskussion gab es weiter oben schon mal, aber sie schlief wie es scheint ein. Können wir die Regel bitte erweitern, so dass sie auch für Kopfzellen gilt? Aktuell ist das sehr verwirrend (siehe das Infobox-Beispiel rechts). --TMg 17:44, 9. Mai 2013 (CEST)

Wie genau erweitern? Ziemlich risikolos im Hinblick auf unerwartete Effekte, weil analog zum Vorhandenen wäre die Variante

.toptextcells td,
.toptextcells th {
	vertical-align: top;
}

Gefällt mir aber ehrlich gesagt nicht besonders, besser fände ich

table.toptextcells > * {
	vertical-align: top;
}

(ähnlich wie der Vorschlag im Abschnitt weiter oben, aber daran angepasst, dass sortierbare Tabellen mittlerweile auch thead- und tfoot-Elemente haben, vgl. tablesorter.js)

Vorteile der zweiten Variante:

• Wirkt sich nicht auf verschachtelte Tabellen aus
• Kann nur auf ganze Tabellen angewendet werden (Verwendungen bleiben im Hinblick auf zukünftige Änderungen überschaubar, bisher mögliche Anwendung auf einzelne Zeilen hat eh keinen Mehrwert gegenüber zeilenweisen style-Anweisungen oder valign)
• Kann durch Ausnutzen von Vererbung zeilen- oder zellenweise mit style="vertical-align: ..." oder sogar valign="..." überschrieben werden

Nachteile der zweiten Variante:

• Wirkt sich nicht auf verschachtelte Tabellen aus (unwahrscheinlich, aber es könnte sein, dass sich irgendwer irgendwo auf die bisherige Wirkung verlassen hat)
• Kann nur auf ganze Tabellen angewendet werden (dito)
• Funktioniert nicht im IE 6 (tut die wikitable-Klasse aus shared.css mittlerweile allerdings auch nicht mehr)

Gruß --Entlinkt (Diskussion) 20:42, 11. Mai 2013 (CEST)

Wie wäre es mit folgender Definition als Ersatz für die CSS-Klasse toptextcells:

thead,
tfoot,
tbody {
	vertical-align: inherit;
}

Damit kann {| style="vertical-align:top" verwendet werden. --Fomafix (Diskussion) 09:20, 12. Mai 2013 (CEST)

Hm, damit kann man mehr machen als mit toptextcells, die Klasse wäre dann nicht mehr nötig, müsste aber weiter unterstützt werden wegen der bisherigen Verwendungen, und explizites inherit funktioniert wohl selbst im IE 7 nicht (die automatische Vererbung aber schon, diese ist im IE irgendwie anders implementiert). --Entlinkt (Diskussion) 12:03, 12. Mai 2013 (CEST)

Ich habe jetzt mal was umgesetzt, das verändert natürlich auch bestehende Artikel, sollte aber wohl keine katastrophalen Folgen haben und lässt sich leicht individuell überschreiben (im Gegensatz zum Vorherigen auch zeilenweise und auch mit valign). Falls es sich bewährt, müsste Hilfe:Tabellen#toptextcells noch aktualisiert werden. --Entlinkt (Diskussion) 04:52, 18. Mai 2013 (CEST)

1. a b c d e f g h i j k l

2. a b c d e f g h i j k l

3. a b c d e f g h i j k l

Bei sortierbaren Tabellen ist das Ergebnis hässlich, siehe rechts: Das Pfeilsymbol zum Sortieren ist als Hintergrundbild implementiert und passt sich der obenbündigen Textausrichtung nicht an. Was tun?

1. So lassen
2. Nur <thead> von der obenbündigen Ausrichtung ausschließen
3. <thead> und <tfoot> von der obenbündigen Ausrichtung ausschließen
4. Zurücksetzen

--Entlinkt (Diskussion) 01:26, 20. Mai 2013 (CEST)

Aus Konsistenzgründen zunächst mal zurückgesetzt. --Entlinkt (Diskussion) 00:14, 23. Mai 2013 (CEST)

Altitalisch und Gotisch

sollten wieder eingefügt werden, aber ohne Browserweiche. Denn auch andere Browser außer dem IE benötigen diese Anweisungen, da sie sonst die Schriftzeichen nicht darstellen können. -- Liliana • 13:36, 13. Mai 2013 (CEST)

*Seufz* – Es geht um diesen Edit, der in fast allen Fällen nichts ändert, weil die Regel sowieso nur im IE 6 und 7 wirkte und keine einzige dieser drei Schriften unter Windows standardmäßig installiert ist und die beiden Klassen extrem selten verwendet werden (Vorlage:Altitalisch ist zurzeit 3-mal eingebunden, für Gotisch gibt es überhaupt keine Vorlage).

Aber Tatsache – unter Windows schafft es nur der Firefox; Internet Explorer 9, Chrome 26 und Opera 12.15 scheitern selbst dann, wenn die Schriften installiert sind. (Unter Linux schaffen es aber auch Chrome und Opera, muss also ein Windows-Bug sein.)

Für 3 Artikel lohnt sich eine Regel in der common.css, die bei 1,5 Millionen Artikelseiten mitgeladen wird, m. E. nicht wirklich. Die Schriften könnten wieder in direkt in die Vorlage eingefügt werden, wie es auch andere, selten verwendete Vorlagen in der Kategorie:Vorlage:mit Schriftfamilie derzeit tun. Aber selbst dann ist der Gewinn gering; die meisten Benutzer werden die Zeichen auch dann nicht sehen können, weil die Schriften ja in der Regel nicht installiert sind. Der Schaden für Firefox- und Nicht-Windows-Benutzer ist aber auch entsprechend gering. --Entlinkt (Diskussion) 14:19, 13. Mai 2013 (CEST)

Seit dem 9. Juli 2013 gibt es den Universal Language Selector, dieser fügt abhängig vom lang-Attribut fleißig font-family-Angaben ein. Beispiel:

Als Arabisch ausgezeichneter Text in abweichender Schriftart (Amiri)

Die von der Vorlage:Arabische Schrift eingesetzte Klasse spanAr ist damit wirkungslos geworden. Ich halte es angesichts dessen nicht mehr für sinnvoll, Vorlagen dieses Typs bzw. projektspezifische Klassennamen mit Schriftarten einzuführen, zu pflegen oder aufrecht zu erhalten. Es gibt eine neue MediaWiki-weite Infrastruktur für diesen Zweck und diese sollte dann auch genutzt werden, soweit der Bedarf besteht. --Entlinkt (Diskussion) 23:56, 10. Okt. 2013 (CEST)

Stellungnahme:

• Deklarationen fremdsprachlicher Textteile, bei denen nicht-ANSI-lateinische Schriften zu erwarten sind, haben in Vorlagen eingeschlossen zu werden.
  • Darüberhinaus liefert dies auch das jeweilige Attribut lang= und unterstützt damit Semantik und Screenreader.
  • Zur Quelltext-Vereinfachung dekorieren wir allerdings nicht jede englischsprachige oder französische Vokabel mit einer Vorlage.
• Gegen die Deklaration einer längeren Liste möglicher Schriftfamilien in Vorlagen ist nichts zu sagen.
  • Es sichert die Entnahme aller Schriftzeichen der Textstelle aus ein und demselben Font, während ansonsten die Schriftzeichen ggf. aus unterschiedlichen Fonts zusammengestoppelt werden, je nachdem wo zuerst ein Zeichen mit der entsprechenden Kodierung gefunden wird.
    • Beispiel: Polytonisches Griechisch; Firefox entnimmt die neugriechischen Zeichen der Grundschrift (vielleicht Arial), die dort fehlenden Zeichen der nächstbesten Spezialschriftart, weshalb gleiche Grundbuchstaben völlig anders aussehen können.
• Die Schriftfamilien sollten ausschließlich über style= in Vorlagen definiert werden und nicht mehr über class= in MediaWiki:.css wie hier.
  • Jede Zuordnung einer Schriftfamilie/Schriftarten-Aufzählung sollte nur an exakt einer Stelle im Projekt deklariert sein.
  • Die gemeinsame Nuzung einer Schriftarten-Aufzählung durch mehrere Vorlagen, wie sie zurzeit durch class= erreicht wird, kann auch durch eine gemeinschaftliche interne Untervorlage erzielt werden, die von allen im Artikel eingebundenen Vorlagenvariationen mitbenutzt wird.
  • In Vorlagen kann die Schriftfamilien-Aufzählung von allen (angemeldeten) Benutzern ergänzt werden.
• ULS
  • ULS ist zurzeit ausschließlich für die folgenden (asiatischen, nicht lateinisch basierten, nicht-CJK/griechisch/kyrillischen) Sprachen verfügbar: akk am ang ar arb arc as bh bho bn bo bpy bug cdo cr dv dz fa gom grc gu hbo he hi ii iu jv jv-java km kn kok lo mai mak ml mr my nan ne or pa pal peo sa saz si sux syc ta tcy te ti ur yi.
  • ULS wird ausgelöst durch das Attribut lang= und damit ist ohnehin erforderlich, die Textpassage in eine Vorlage einzuschließen. Die kann dann aber auch gleich für Schriftarten sorgen.
  • ULS arbeitet ausschließlich mit JavaScript.
  • ULS ist zurzeit noch recht ineffizient programmiert und erfordert bei jedem Seitenaufbau überflüssige Extra-Kommunikation.
  • Das Opt-Out für nichtlateinisch verschriftete Wikiprojekte auf Projekt-Ebene oder als Benutzer-Option wird deshalb gefordert. Gleichwohl sollen dann für seltene Textpassagen die traditionellen CSS-Lösungen greifen.
  • Für nicht angemeldete Leser ist es wohl zurzeit nicht aktiviert.
  • Die grundsätzliche Intention für ULS war zunächst gewesen, asiatische Wiki-Projekte mit Inhalten der oben genannten Schriftsysteme besser zu unterstützen. Wie sich das weiter entwickeln mag, ist bei WMF nicht durchschaubar.
  • Die Produktentwicklung erfolgt nicht durch die WMF-Kernteams, sondern ist von irgendwoher eingekauft oder über eine Kooperation mit undurchsichtigen Dritten und mit unbekanntem Ziel erfolgt. Direkten Einfluss auf die upstream-Definitionen haben WMF und die Wiki-Projekte anscheinend nicht.
  • Eine technische Dokumentation existiert nicht; nur Rätselraten über die Absichten aus dem Quellcode.
  • Fazit: ULS ist kein Pferd, auf das man setzen sollte.

Schönen Sonntag --PerfektesChaos 00:44, 13. Okt. 2013 (CEST)

Hervorheben von Linkzielen

Kann bitte jemand den Abschnitt

ol.references > li:target,
sup.reference:target {
	background: #def;
}

wie folgt erweitern?

ol.references > li:target,
sup.reference:target,
span.citation:target {
	background: #def;
}

Damit wäre dieser Abschnitt unserer Common.css identisch zur englischen Wikipedia. Die zusätzliche Zeile hebt auch Linkziele hervor, wenn sich diese innerhalb eines Literatur-Abschnitts befinden. Aktuell funktioniert es nur, wenn das Linkziel ein Einzelnachweis ist. --TMg 13:32, 24. Mai 2013 (CEST)

Sorry, ich kann nicht nachvollziehen, wo die Klasse citation herkommt. Aus einer Vorlage? Habe nur herausgefunden, dass das in der englischen Wikipedia hier eingefügt wurde. --Entlinkt (Diskussion) 17:55, 25. Mai 2013 (CEST)

Die „kommt“ nirgends her sondern wird von bestimmten Vorlagen verwendet, typischerweise von den Cite-Vorlagen oder auch Vorlage:Literatur, sofern man die Klasse dort einprogrammiert. Was aber auch nur dann Sinn ergibt, wenn die Klasse etwas bewirkt. Also ein kleines Henne-Ei-Problem. Ich schätze das so ein, dass diese kleine Erweiterung keinesfalls schaden kann oder für etwas Ungewolltes missbraucht werden kann. In den Templates muss sie anschließend wie angedeutet nachgepflegt werden. --TMg 00:52, 26. Mai 2013 (CEST)

OK, ich hab’s mittlerweile halbwegs verstanden: In en:Doukas (perma) gibt es eine Fußnote 1, die auf ein Kurzzitat verweist, und von dort geht es weiter auf ein Langzitat im Literaturabschnitt. In Dukas (Familie) (perma) gibt es dasselbe in kaputt. (Sorry, ich wollte es halt gern zunächst nachvollziehen können.)

Wenn man so zitiert, ist die Hervorhebung natürlich eine sinnvolle Sache. Zitationsweisen sind allerdings ein ziemlich vermintes Gelände (bis hin zu Editwars um bestimmte Vorlagen oder deren Verwendung; es gab mal einen um Vorlage:Cite web und Vorlage:Internetquelle zu einem Zeitpunkt, als sie quasi identisch waren).

Diese Zitationsweise hier erscheint mir in dewiki eher weniger üblich, kommt wohl hauptsächlich bei en-Importen vor. Ich habe so ein bisschen die Befürchtung, dass die Hervorhebung als Argument für irgendwas benutzt werden könnte. --Entlinkt (Diskussion) 11:59, 26. Mai 2013 (CEST)

nogrid

Die Klasse nogrid wird weiterhin benötigt, u.a. in Infoboxen wie hier. Ich bitte um Wiederherstellung. --Prüm 15:52, 1. Jun. 2013 (CEST)

Wofür wird dort überhaupt die Klasse prettytable benutzt? Die Definitionen werden größtenteils wieder überschrieben. Es ist nicht sinnvoll, eine Klasse zu verwenden, die ein Gitter erzeugt, das Gitter mit einer anderen Klasse wieder zu entfernen und dann mit Inline-CSS alles außer dem Gitter auch noch zu überschreiben. --Entlinkt (Diskussion) 16:34, 1. Jun. 2013 (CEST)

Was sinnvoll ist, war die Klasse. Du hättest sie nicht entfernen sollen, solange du die Verwendungen nicht gefixt hast. Im übrigen: If it ain't broke, don't fix it. --Prüm 17:12, 1. Jun. 2013 (CEST)

Das sehe ich anders. Der Ablauf ist folgender:

1. Die Klasse nogrid ist mal als Workaround für einen Bug in der Definition von prettytable eingeführt, aber niemals dokumentiert worden.
2. Dann wurde die Definition von prettytable unter dem Namen wikitable nach shared.css kopiert.
3. Mit rev:107669 vor über einem Jahr wurde die Definition von wikitable gefixt, so dass nogrid für den ursprünglich angedachten Zweck weder nötig ist noch überhaupt funktioniert. Die lokale Definition von prettytable behielt den Bug.
4. Kürzlich habe ich die lokale Definition von prettytable an die von wikitable angeglichen (denn ein Unterschied zwischen den beiden war nie beabsichtigt) und gleichzeitig nogrid entfernt, weil es ja nicht mehr funktioniert.
5. Während der langen Zeit haben Benutzer herausgefunden, dass man die subtilen, nicht dokumentierten Unterschiede zwischen den Klassen ausnutzen kann, um bestimmte Effekte zu erzielen, die überhaupt nicht vorgesehen sind. (Genau deshalb sollten die beiden Klassen synchron gehalten werden, auch wenn prettytable veraltet ist, weil es sonst immer irgendwo neu eingebaut werden wird.)

Ich bin dagegen, eine Klasse wieder einzuführen, ohne dass es einen klar ersichtlichen, sinnvollen Anwendungsfall dafür gibt. (Deshalb stelle ich die Frage, vielleicht gibt es ja doch einen.) Andernfalls können meiner Meinung nach beide Klassen – prettytable und nogrid – aus der Vorlage schlicht entfernt werden: Sie heben sich im Wesentlichen gegenseitig auf.

Beim Entfernen hatte ich mich auf die Aussage verlassen, dass nogrid seit März 2012 nicht mehr funktioniert, in die Vorlage ist das auch erst nachher eingefügt worden. Dass wikitable nogrid seit über einem Jahr nicht funktioniert, hat übrigens auch niemanden gestört. Gruß --Entlinkt (Diskussion) 17:27, 1. Jun. 2013 (CEST)

Ich muss mich (teilweise) korrigieren: Die Klasse nogrid war tatsächlich mal für kurze Zeit dokumentiert, nämlich unter Vorlage Diskussion:Prettytable/Bugs. Dort stand:

„Untertabellen übernehmen von der Haupttabelle den Rand (Rahmen) der Zellen. Abschalten kann man das für alle Zellen mit der Angabe class="nogrid" im Kopf der Untertabelle. Für einzelne Zellen mit Direktformatierung. In manchen Fällen können sich ebenfalls die Innenabstände der Tabellenzellen ändern (da diese auch von der Haupttabelle übernommen werden). Eine Lösung ist hier wiederum die Direktformatierung einzelner Zellen (CSS-Attribut padding:…).“

nogrid ist also wirklich nur ein Workaround für diesen Bug gewesen, die Seite ist aber sehr zügig nach Einführung der Klasse wieder gelöscht worden, so dass das kaum jemand mehr wusste.

Ich habe gesehen, dass du die Klassen aus der Vorlage mittlerweile wieder entfernt hast. Allerdings hatte die Infobox von der Klasse prettytable auch die Zellinnenabstände geerbt (was ebenfalls nur ein unerwünschter Nebeneffekt war, s. o.). Falls du für alle Zellen der Tabelle Innenabstände einstellen möchtest, kannst du dafür (bis es etwas besseres gibt) das Attribut cellpadding benutzen.

Gruß --Entlinkt (Diskussion) 12:53, 2. Jun. 2013 (CEST)

Links auf Wikidata in der Beobachtungsliste anders darstellen

Falls man in der Beobachtungsliste Wikidata eingeblendet hat, kriegt man beispielsweise solche Einträge:

• (Unterschied | Versionen) . . Benzol (Q2270); 18:18 . . Mahir256 (Diskussion | Beiträge) (Das Wikidata-Objekt wurde geändert)

Die Links sind gleich formatiert wie bei normalen Beobachtungslisten-Einträgen. Mit Ausnahme des Links auf den Wikipedia-Artikel, führen alle Links auf Wikidata. Ich finde, dass diese sechs Links anders dargestellt werden sollten, so dass dies für OMA direkt ersichtlich ist und nicht erst beim Klicken. --Leyo 18:28, 4. Jun. 2013 (CEST)

+1

Technikservice: <li class="wikibase-edit">

LG --PerfektesChaos 20:51, 4. Jun. 2013 (CEST)

Die Formatierung könnte ggf. so sein wie bei (Sprachlink hinzugefügt: ki:Oxygen). --Leyo 01:20, 5. Jun. 2013 (CEST)

−1

Für jemand wie dich, der ohnehin jede Menge Links mit besonderen Farben kennzeichnet, mag eine solche Hervorhebung sinnvoll sein. Meiner Ansicht nach muss der unwissende Benutzer, der keine Ahnung von Wikidata hat, auch keine Ahnung davon haben. Da ist eine Änderung, die sich (möglicherweise, und indirekt) auf den Artikel auswirkt, was geändert wurde, kann man sehen, wenn man auf „Unterschied“ klickt, kein Grund das irgendwie hervorzuheben. Zudem ist eine Hervorhebung in keiner Weise selbsterklärend, und ob die Nachfragen lauten „Warum führen manche Links auf der Beobachtungsliste zu einem anderen Wiki?“ oder „Warum sind manche Links auf der Beobachtungsliste blassblau (oder sonstwie) unterlegt?“ spielt keine große Rolle.

Die farbliche Unterscheidung von normaler Links und Links zu anderen Projekten ist ohnehin leicht zu übersehen bzw. nur wahrzunehmen, wenn man davon weiß. --Schnark 09:27, 5. Jun. 2013 (CEST)

Es geht ja nicht darum, die Links grün oder orange zu hinterlegen, wie ich dies für wenige ausgewählte Seiten mache. Aber nur schon aus Konsistenzgründen sollten doch alle Links zu anderen Projekten einheitlich sein. Wie du selbst sagst, ist der Unterschied eher klein. Daher würde sich wohl kaum jemand daran stören. Wenn man's weiss, ist's aber eine Hilfe. Beispielsweise sieht man so auch auf einen Blick, wo Popups funktioniert und wo nicht. --Leyo 09:52, 5. Jun. 2013 (CEST)

Bereits die Schwesterprojektlinks in Artikeln sind nicht einheitlich, siehe Wikipedia:Textbausteine/Schwesterprojekte. Wenn man's weiss, ist's aber eine Hilfe. – Oben argumentierst du, es solle für OMA direkt ersichtlich sein. Für wen soll diese Änderung denn nun sein? Für den Poweruser, der das ohnehin (evt. mit Hilfe) nach eigenen Vorstellungen in seiner eigenen common.css anpassen kann, oder für den normalen Benutzer, der sich nicht gut auskennt? --Schnark 10:12, 5. Jun. 2013 (CEST)

Ich beziehe mich betreffend Einheitlichkeit nur auf die Beobachtungsliste.

Vielleicht für mit guter Beobachtungsgabe ausgestattete OMAs? Es sollte so ausgestaltet sein, dass es nicht stört, aber doch erkennbar ist. Da muss man wohl in Kauf nehmen, dass es auch übersehen werden kann. --Leyo 10:21, 5. Jun. 2013 (CEST)

• Ich hätte an ein dunkles mittelgrau gedacht; oder kursiv, wenn es das schon für einen gleichartigen Zweck gibt.
• Service für alle Benutzer; wobei sich empfiehlt, Wikidata gleich ganz auszublenden, wenn man es überhaupt nicht wissen möchte.
• Die Unterscheidung, dass der edit nicht in unserem Artikel vorgenommen wurde und nur sehr indirekt inhaltliche Auswirkungen hätte, ist schon von Bedeutung und auch leicht nachvollziehbar. In aller Regel wird man die Info überlesen wollen, wenn man sich nicht besonders intensiv für dieses einzelne Lemma interessiert.

LG --PerfektesChaos 13:41, 5. Jun. 2013 (CEST)

Dein Formatvorschlag ist mir auch recht. Hauptsache, die Darstellung ist unterschiedlich, aber trotzdem nicht störend.

Unter WD:WD#Beobachtungsliste wurde übrigens zusätzlich ein D zur Kennzeichnung vorgeschlagen, analog K und B für kleine Edits und Botedits. --Leyo 18:37, 11. Jun. 2013 (CEST)

Kursiv kollidiert mit der Hervorhebung, die eine Reihen von Benutzern statt der fetten Hervorhebung von ungesehenen Änderungen gewählt haben, siehe Wikipedia:Fragen zur Wikipedia/Archiv/2012/Woche 19#Fettschrift in der Beobachtungsliste?. Natürlich kann man sich auf den Standpunkt stellen, dass jeder, der solche Änderungen für sich vornimmt, selbst schuld ist und diese gegebenenfalls anpassen muss, optimal ist es aber nicht. Ein D wäre tatsächlich das sinnvollste, in meinem Skript watchlist++ mache ich das auch so. --Schnark 09:34, 12. Jun. 2013 (CEST)

Auf diesen Standpunkt stelle ich mich tatsächlich. Es sollte IMO in allen Wikipedias gemacht werden. Unter bugzilla:50893 gibt es nun eine Anfrage dazu. Magst du oder sonst jemand diese bezüglich D ergänzen? --Leyo 18:25, 18. Jul. 2013 (CEST)

Es gibt zwei Irrtümer deinerseits: Ich bin nicht wirklich an Wikidata interessiert, und Bugzilla-Tickets für Wikidata bewirken nicht wirklich etwas. Der Umherirrende ist der bessere Ansprechpartner, da er es kürzlich überhaupt erst ermöglicht hat, dass weitere Flags wie etwa D verwendet werden können. --Schnark 09:17, 19. Jul. 2013 (CEST)

Ja, ich hatte mich letztens mal damit beschäftigt und als Problem gesehen, das man garkeine eigenen Kürzel wie N, K, B und ! ergänzen kann und dafür eine Möglichkeit geschaffen. Dies könnte man für die einfache Beobachtungsliste auch sicher schon aktivieren, auch wenn dann auf der gruppierten Beobachtungliste ein Leerzeichen in dem Bereich der Buchstaben mehr auftaucht.

Ich hatte auch mal versucht, die gruppierte Beobachtungsliste mit WikiData-Einträgen zu versehen, aber der Code in MediaWiki der für die gruppierte Beobachtungsliste vorhanden ist, lässt keine Möglichkeit der Überschreibung. Daher ist das etwas komplizierter. Zusätzlich stellte sich dann die Frage, wie gruppiert man das am besten? Soll der Benutzername, die Seitenänderung von WikiData mit in die erste Zeile? Sollen die WikiData-Einträge garnicht gruppiert werden oder eine eigene Gruppe machen, wenn es mehrere gibt, ansonsten eine einzelne Zeile? Der Umherirrende 16:11, 19. Jul. 2013 (CEST)

Das Change Set gerrit:74636 für das D wurde jetzt angenommen, damit könnte es ab dem 22. August entsprechend gekennzeichnet werden. Der Umherirrende 16:40, 16. Aug. 2013 (CEST)

Vielen Dank! Damit ist die Hälfte meiner Wünsche erfüllt. Die leicht andere Farbe für nicht-lokale Links hätte ich weiterhin gerne… :-) --Leyo 17:14, 16. Aug. 2013 (CEST)

Wobei ich eher glaube, das es der 29. August wird. Der Umherirrende 18:18, 20. Aug. 2013 (CEST)

Warten wir ab. Es gibt übrigens bugzilla:50893 bezüglich Linkfarben. --Leyo 23:34, 26. Aug. 2013 (CEST)

Das D erscheint nun auf der Beobachtungsliste. Der Umherirrende 20:15, 29. Aug. 2013 (CEST)

Toll, danke! Ist es Absicht, dass es im Gegensatz zum K und B nicht fett ist? In der en-WP passt es übrigens etwas weniger ins Schema, weil m und b klein geschrieben werden. --Leyo 07:31, 30. Aug. 2013 (CEST)

Im englischen ist es gemischt, Neue Seiten bekommen ein großes N, während bot und minor klein geschrieben werden. Daher würde ich nicht sagen, das ein großes D stört, aber ich kann auch nicht für die en.wp sprechen. Ändern könnten sie es lokal immer.

Das D wird ohne Styles ausgeliefert. Das Fett hatte ich nicht mehr in Erinnerung, weil ich es schon bei mir weggemacht habe (lenkt mich zu sehr ab). Andererseits weiß ich nicht, wie man in einer Extension ein neues ResourceLoader-Modul erstellt, was dann auf der Beobachtungsliste mit dem eigentlichen Modul geladen wird (Ein extra download davon wäre wohl zu viel des guten). Vermutlich ist ein Bug hier zielorientierter. Der Umherirrende 20:13, 5. Sep. 2013 (CEST)

Ich habe doch eine Möglichkeit gefunden: gerrit:74636, mal schauen, ob die Reviewer das auch mögen. Nach der Änderung wird es auch einfacher sein, CSS für die Linkfarbe einzufügen, weil es dann schon ein Modul gibt. Wobei im Bug ja erfragt wird, ob class="external" gesetzt werden kann. Da die Links aber schon plainlinks haben, wäre das irgendwie nicht sinnvoll. Der Umherirrende 21:27, 5. Sep. 2013 (CEST)

Schnarks Einwand halte im übrigen nicht für zutreffend, weil der unwissende Benutzer üblicherweise nicht in seinen Einstellungen herumgebastelt hat, um Wikidata-Links zu sehen. Oder andersrum, wer in Einstellungen | Beobachtungsliste das Häkchen vor Wikidata-Bearbeitungen in der Beobachtungsliste anzeigen gesetzt hat, ist nicht unwissend, sondern ist sich der Dichotomie auf der Beobachtungsliste durchaus bewußt. Mich stört übrigens, daß von der Beobachtungsliste aus Popups Wikidataeinträge nicht anzeigt. --Matthiasb – Vandale am Werk™ ^{(CallMyCenter)} 02:43, 6. Sep. 2013 (CEST)

Popups funktioniert bei keinen nicht-lokalen Links. Das war früher schon bei Interwikibots-Edits so, wo die betreffenden Interwikis in der Zusammenfassung verlinkt waren. --Leyo 10:55, 6. Sep. 2013 (CEST)

Kann freundlicherweise jemand angeben, was in die eigene common.css eingetragen werden muss, damit die Links auf Wikidata die IMO korrekte Farbe erhalten? Reicht ein Einzeiler mit der von PerfektesChaos ganz oben angegebenen Klasse? --Leyo 00:16, 16. Okt. 2013 (CEST)

Die Farbe allein bringt wirklich fast gar nichts. Ohne gleichzeitig das Pfeilsymbol hinter alle externen Wikidata-Links zu setzen, sind sie nicht zu unterscheiden. Ich hab mal etwas rumgespielt. Ist nicht ganz ausgereift, aber wer mag, kann das mal in seiner eigenen common.css ausprobieren. --TMg 17:13, 16. Okt. 2013 (CEST)

/* Wikidata-Zeilen in der Beobachtungsliste abblenden */
li.wikibase-edit {
	opacity:.6;
}
/* Korrekte externe Linkfarbe für Wikidata-Links */
li.wikibase-edit .plainlinks {
	color:#36B;
}
/* Buchstabe "D" durch das Wikidata-Logo ersetzen */
abbr.wikibase-edit {
	background:url(/media/wikipedia/commons/e/e8/Wikidata-favicon.png) 0 50% no-repeat;
	color:transparent;
	padding-right:8px;
}

Vielen Dank! Ich habe mich mal aufs mittlere beschränkt. Das erste übernehme ich bei Bedarf. À propos Bedarf: Ich sehe noch immer nicht ein, welche relevanten Gründe gegen die Aufnahme in der Common.css sprechen. Ein MB dazu wäre ja wohl ein Overkill… --Leyo 01:38, 19. Okt. 2013 (CEST)

Rahmenfarben für Tabellen

Spricht etwas dagegen, die Definitionen für die aktuell fünf Rahmenfarben so auszuweiten, dass auch die folgenden beiden Fälle funktionieren?

Zellenweise: Die aktuell einzige Methode, um die Rahmenfarbe einer wikitable zu verändern, ist das aufwändige individuelle Umfärben jeder einzelnen Zelle per | style="border-color:…;". Das Selbe sollte auch per | class="rahmenfarbe…" funktionieren.

Tabellenweise
Die Hintergrundfarbe lässt sich schon tabellenweit ändern, mit der Rahmenfarbe sollte das genauso funktionieren.

Schwierig ist das vor allem aufgrund der Spezifität. Die ist für die aktuell recht komplizierte Implementierung der wikitable-Stile leider sehr hoch. --TMg 13:54, 22. Aug. 2013 (CEST)

Eine Implementierung könnte zum Beispiel so aussehen:

.rahmenfarbe3,
table.rahmenfarbe3,
table.rahmenfarbe3 > * > tr > th,
table.rahmenfarbe3 > * > tr > td,
table > * > tr > th.rahmenfarbe3,
table > * > tr > td.rahmenfarbe3 { /* "Rot", auffällig */
	border-color: #c00000;
	border-width: 1px;
}

Allerdings fände ich es vielleicht eleganter, die wikitable-Definition so abzuändern, dass sie auf Vererbung setzt: 4 Jahre alter Vorschlag, der nie aufgegriffen wurde, weil er im IE <= 7 nicht funktioniert. Könnte man das mittlerweile akzeptieren? --Entlinkt (Diskussion) 19:53, 22. Aug. 2013 (CEST)

Test

Stimmt, den zweiten Selektor hätte ich glatt vergessen. Die width ist für alle außer den ersten Selektor eigentlich unnötig, aber so bleibt das CSS kurz und man hat weniger Redundanz. Also von meiner Seite freigegeben. ;-) Mit der Kurzform würde ich meinem Gefühl nach noch 1…2 Jahre warten. Die Auswirkung (alle Tabellen in der gesamten Wikipedia verlieren sämtliche inneren Rahmenlinien und Abstände) ist einfach zu groß. --TMg 20:33, 22. Aug. 2013 (CEST)

Im IE 6 funktioniert die jetzige wikitable-Definition sowieso schon seit rev:107669 nur noch teilweise (innere Rahmenlinien, Abstände und andere Dinge fehlen), die Klassen für Hintergrundfarben funktionieren seit März 2012 ebenfalls nicht mehr.

Betroffen wäre also nur der IE 7 und man kann die Vererbungsvariante mit einem Fallback versehen, so dass sich im IE 7 einfach nichts ändert (d. h. die inneren Rahmenlinien würden einfach grau bleiben). Genau genommen müsste man den Fallback für wikitable gar nicht implementieren, weil er in der shared.css schon vorhanden ist.

Muss natürlich nicht sein, aber ich bin ernsthaft am Überlegen, ob man das jetzt schon machen kann (das Umfärben wird wohl nicht so häufig gemacht werden und wenn doch, wird man trotzdem am Außenrahmen erkennen, dass das eine irgendwie hervorgehobene Tabelle sein soll; das Grau sollte auch zu jeder anderen Farbe einigermaßen passen).

Andernfalls wäre hier noch eine Variante ohne gedoppeltes width:

.rahmenfarbe1,
.rahmenfarbe2,
.rahmenfarbe3,
.rahmenfarbe4,
.rahmenfarbe5 {
	border-width: 1px;
}

/* [...] */

.rahmenfarbe3,
table.rahmenfarbe3,
table.rahmenfarbe3 > * > tr > th,
table.rahmenfarbe3 > * > tr > td,
table > * > tr > th.rahmenfarbe3,
table > * > tr > td.rahmenfarbe3 { /* "Rot", auffällig */
	border-color: #c00000;
}

/* [...] */

Gruß --Entlinkt (Diskussion) 22:25, 22. Aug. 2013 (CEST)

Ich sorge mich nicht nur um IE, sondern auch um obskure Mobilbrowser, die zwar mit dem gängigen > aus CSS2 etwas anfangen können, denen aber nicht jede Variation mit inherit bekannt ist. Und noch wichtiger: Wenn einer sowieso nur grauen Tabelle mal ein paar graue Linien fehlen oder Abstände kleiner sind, ist das zwar hässlich, aber der Inhalt bleibt der selbe. Wenn Farben fehlen, gehen schlimmstenfalls Inhalte verloren. Zwar sollte man Information niemals nur durch Farbunterschiede vermitteln, aber wie wir wissen, wird dieser einfache Barrierefreiheits-Grundsatz nicht immer beachtet. --TMg 21:34, 27. Aug. 2013 (CEST)

Ich bin nicht dagegen, aber auch noch nicht restlos überzeugt. Ich habe mal ein wenig herumprobiert und herausgefunden, dass der IE 7 zwar das Schlüsselwort inherit nicht versteht, aber entgegen den Regeln die Eigenschaft border-color durch die Tabelle hinweg vererbt, wenn man für die Zellen keine Rahmenfarbe festlegt. Das heißt, die folgende Anpassung der wikitable-Klasse würde das gewünschte Ziel erreichen und in allen mir bekannten und heute relevanten Browsern konsistente Ergebnisse erzielen (IE 6 außen vor, weil die gesamte Klasse dort sowieso auch jetzt schon nicht funktioniert):

Jetzige Definition in shared.css

Vorgeschlagene neue Definition

table.wikitable { margin: 1em 0; background-color: #f9f9f9; border: 1px #aaa solid; border-collapse: collapse; color: black; } table.wikitable > tr > th, table.wikitable > tr > td, table.wikitable > * > tr > th, table.wikitable > * > tr > td { border: 1px #aaa solid; padding: 0.2em; } table.wikitable > tr > th, table.wikitable > * > tr > th { background-color: #f2f2f2; text-align: center; } table.wikitable > caption { font-weight: bold; }

table.wikitable { margin: 1em 0; background-color: #f9f9f9; border: 1px #aaa solid; border-collapse: collapse; color: black; } table.wikitable > tr > th, table.wikitable > tr > td, table.wikitable > * > tr > th, table.wikitable > * > tr > td { border: 1px solid; padding: 0.2em; } table.wikitable > thead, table.wikitable > tfoot, table.wikitable > tbody, table.wikitable > * > tr, table.wikitable > tr > th, table.wikitable > tr > td, table.wikitable > * > tr > th, table.wikitable > * > tr > td { border-color: inherit; } table.wikitable > tr > th, table.wikitable > * > tr > th { background-color: #f2f2f2; text-align: center; } table.wikitable > caption { font-weight: bold; }

Als Vorteile sehe ich an, dass dies dann nicht nur mit den rahmenfarbeX-Klassen, sondern auch mit style-Attributen funktionieren würde und die lokalen Anpassungen auf einem Minimum gehalten werden können.

Wäre es sinnvoll, diese Änderung für den MediaWiki-Core vorzuschlagen? (Der Vorschlag oben ist absichtlich so kompliziert wie die jetzige MediaWiki-Definition geschrieben, damit es dazu passt, man könnte ihn auch vereinfachen.)

Welche Mobilbrowser sind es denn, die inherit nicht verstehen? Das war doch bereits 1998 in CSS2 standardisiert und sollte wirklich überall funktionieren. --Entlinkt (Diskussion) 10:16, 4. Okt. 2013 (CEST)

Zu Mobilbrowsern kann ich leider nichts sagen. Wenn aber inherit eingeführt wird, dann am besten für alle sinnvollen Attribute auf einmal. Folgende Attribute sollte geprüft werden: padding, border, vertical-align. --Fomafix (Diskussion) 12:17, 4. Okt. 2013 (CEST)

Hm, okay. Nach meinen Tests ist allerdings border-color die einzige Eigenschaft, bei der die Vererbung auch im IE 7 funktioniert. border-style und border-width funktionieren nicht, padding und vertical-align sowieso nicht; ich denke, der IE bildet damit das Verhalten der alten HTML-Attribute border und bordercolor einigermaßen sinnvoll nach:

• Äußere Rahmenlinien haben in reinen HTML-Tabellen immer denselben Stil (außen outset, innen inset).
• border=n setzt nur die Stärke der äußeren Linien, die inneren haben immer 1px.
• bordercolor=#rrggbb setzt die Farbe aller Rahmenlinien.

Ob man den IE 7 wirklich schon abhängen sollte, weiß ich nicht; wenn Bug 25378 gefixt wäre, wäre das leichter (bis jetzt kann noch jeder im IE den Button „Kompatibilitätsansicht“ drücken und sich damit einen verkappten IE 7 einhandeln und im Zweifelsfall das Layout zerschießen).

Vielleicht sollte man noch etwas abwarten, bis das in MediaWiki deaktiviert wird (oder man weiß, dass es nicht deaktiviert wird). Es wäre die Frage, ob man unterdessen die rahmenfarbeX-Klassen wie zu Anfang vorgeschlagen anpassen will. --Entlinkt (Diskussion) 17:48, 4. Okt. 2013 (CEST)

Parameterfehlermeldungen per Default ausblenden

Um mittels Lua Artikel auf falsche Parameter in Vorlagen überprüfen zu können, braucht es eine Möglichkeit, die Fehlermeldungen (analoges Beispiel bei Vorlage:Information) nur bestimmten Benutzern anzuzeigen bzw. vor allen anderen zu verbergen. Unter Wikipedia:Lua/Werkstatt#Breitere Anwendung von Modul:TemplatePar wurden verschiedene Varianten diskutiert. Eine Kopplung etwa an die Aktivierung des Metadaten-Gadgets würde nebst einer kleinen Erweiterung des Gadgets selbst auch eine Ergänzung des entsprechenden display:none in der Common.css bedingen. Gibt es Einwände dagegen oder Alternativvorschläge? --Leyo 19:18, 27. Aug. 2013 (CEST)

Mir leuchtet nicht so recht ein, warum die Meldung, dass man eine Vorlage gerade mit einem falschen Parameter verwenden will, dem Verursacher dieses Fehlers nicht angezeigt werden soll? Warum sollte das nicht jeder selbst beheben dürfen, statt dass sich ein paar wenige Benutzer die von anderen verursachten Fehler gebündelt aufhalsen? Wenn es um Altfälle geht, so sollten diese einer nach dem anderen zeitnah abgearbeitet werden. So lange kann die Warnung entweder sichtbar bleiben, oder man macht sie für alle unsichtbar und arbeitet sie nur per Wartungskategorie ab. Beides braucht keine Erweiterung des CSS. --TMg 21:43, 27. Aug. 2013 (CEST)

Es geht mir vor allem um die Altfälle. Bei einigen Infoboxen oder sonst häufig verwendeten Vorlagen gibt es bestimmt hunderte von Artikeln mit Parameterfehlern, so dass diese nicht zeitnah abgearbeitet werden können. Ein Leser sollte solche Fehlermeldungen nicht zu Gesicht bekommen. IMO kann die Anzeige auch vom Sichterrecht abhängig (MediaWiki:Group-editor.css, analog zu MediaWiki:Group-sysop.css) gemacht werden. --Leyo 23:44, 27. Aug. 2013 (CEST)

Ich habe nun MediaWiki:Group-editor.css angelegt, aber noch nirgends verwendet. Falls da etwas geändert werden soll (ist editoronly so OK?), bitte… --Leyo 23:28, 1. Sep. 2013 (CEST)

Oder sollte man besser MediaWiki:Group-autoconfirmed.css verwenden, damit mehr Benutzer (aber nicht Leser) die Fehlermeldungen angezeigt bekommen? Oder geht das wegen {{NUMBERINGROUP:autoconfirmed}} → 0 gar nicht? --Leyo 16:08, 5. Sep. 2013 (CEST)

Da die verlinkte CSS-Seite ja einen Kommentar diesbezüglich enthält, funktioniert das. Autoconfirmed wird erst zur Laufzeit geprüft, daher kann man das nicht zählen oder sich auf Spezial:Benutzer auswählen. Ob der aktuelle Benutzer autoconfirmed ist, kann aber festgestellt werden. Der Umherirrende 17:31, 5. Sep. 2013 (CEST)

Danke für die Antwort! --Leyo 18:33, 5. Sep. 2013 (CEST)

Ich möchte gern, dass es wp_editoronly usw. heißt; wie auch immer.

• Neu eingeführte Klassen sollten dieses Präfix benutzen.
• Grund: Wikipedia:Technik/Skin/CSS/Projektweite Selektoren #Namenskonvention
• Auf Wikipedia:Technik/Skin/CSS/Projektweite Selektoren sollte die neu definierte Klasse dokumentiert werden.
• Es lässt sich auch parallel eine wp_adminonly definieren (nur ein Wort und ein Komma mehr); und nach und nach dorthin migrieren. Sind eh nur ein halbes Dutzend Vorkommen.

VG --PerfektesChaos 21:18, 5. Sep. 2013 (CEST)

Ich habe nichts gegen wp_ als Präfix. Warten wir mal weitere Meinungen ab. --Leyo 23:54, 5. Sep. 2013 (CEST)

Und auch betreffend Festlegung der Sichtbarkeit mittels MediaWiki:Group-editor.css oder MediaWiki:Group-autoconfirmed.css wären weitere Meinungen erwünscht. Die Seite hat ja immerhin 110 Beobachter. Oder wäre ein Mini-MB unter FzW besser? --Leyo 00:33, 7. Sep. 2013 (CEST)

Zu den Klassennamen: Ich weiß nicht, ob man wp_ wirklich als Namenskonvention bezeichnen sollte; es wird in einigen Vorlagen verwendet, aber mehr als die genannten .wp_boppel und .wp_intro fallen mir gerade auch nicht ein, wobei „Boppel“ ein wenig nach einem Scherz klingt.

Die englische Wikipedia verwendet einheitliche Namen der Form <Gruppenname>-show, vgl. en:MediaWiki:Group-accountcreator.css, en:MediaWiki:Group-autoconfirmed.css und en:MediaWiki:Group-sysop.css

wp_ würde nie ein wikiübergreifender Standard werden, weil es nicht nur Wikipedien gibt, aber die Funktionalität ist nicht Wikipedia-spezifisch. Vielleicht wäre es nicht verkehrt, sich einfach der englischen Wikipedia anzuschließen: .editor-show, .sysop-show. --Entlinkt (Diskussion) 01:58, 19. Okt. 2013 (CEST)

Da gibt es ein Missverständnis: wp_ soll gerade nicht heißen: „wikiübergreifender Standard“, sondern „Projektweiter Selektor der deutschsprachigen Wikipedia“.

• Was wikiübergreifend ist, hat durch MediaWiki definiert zu werden.
• „Projektweiter Selektor“ meint: Nicht spezifisch für eine Redaktion, eine Infobox, eine einzelne Vorlage, einen bestimmten Benutzer.
• wp_talkpagetext gab es auch schon. Ich fordere ja gerade die deutliche Kennzeichnung aller neu eingeführter lokaler Selektoren in Abgrenzung von den weltweit gültigen; natürlich ist dies in der Vergangenheit ungenügend kenntlich gemacht worden und deshalb zurzeit selten.

Ich möchte gern, dass am Klassennamen sofort ersichtlich ist, wer sich das ausgedacht hat und wo nach der Definition zu suchen wäre.

• Wer hat ns-subject in die Welt gesetzt?
• Bilderwunsch ist ganz offensichtlich eine deutschsprachige und keine weltweite Schöpfung.
• mw-editsection ist ersichtlich in höheren Sphären definiert.
• Aber von wem ist action-edit?

Es gibt bei MW -zigtausende an Klassennamen, und niemand auf dem Planeten hat noch irgendeinen Durchblick, wo die wie gesetzt werden.

• Ein Verzicht auf Präfixe wäre dann tolerabel, wenn es für die deWP eine vollständige und zuverlässige Dokumentation geben würde.
• In den letzten zehn Jahren haben jedoch Dutzende von Admins und einfacher Benutzer irgendwas in den space geschossen, ohne sich jemals um eine Projektdokumentation und Registrierung oder gar Systematik zu kümmern. Die Definitionen sind auf -zig verschiedene Seiten verteilt, so dass man auch nicht einfach nachgucken kann, welche Stile etwa hier umseitig damit verknüpft wären.

Wenn schon bisher der totale Dschungel angerichtet wurde, dann sollten wenigstens alle neuen projektweiten Selektoren nicht aus dem Ärmel geschüttelt werden.

• Dazu gehört auch die Schreibweise: Einheitlich menschenfreundlich oder in einem Wort? floatright oder float-right und top-textcells oder am Stück toptextcells – adminonly oder sysop-only? Wer soll sich das denn noch alles merken können? Und wo nachschlagen?

Nicht-WP-Projekte interessieren mich bei unseren deWP-eigenen Definitionen nicht.

• Alles ohne Präfix oder erkennbare deutschsprachige Komponente wie Vorlage_ ist eine weltweite Definition durch MediaWiki.
• Was in irgendeinem anderem Projekt benutzt wird, ist irrelevant, solange es keine weltweit einheitliche Vorgabe durch MediaWiki gibt.
• Gerade die enWP hat vor einigen Jahren davor kapituliert, alle MediaWiki-Selektoren zu dokumentieren, und dabei gleichzeitig ihre begrenzte projektspezifische Dokumentation aufgegeben. Die können ihre privaten Selektoren heute auch nicht mehr von mw unterscheiden.

Definition meint:

1. Auslösung für bestimmte Elemente in bestimmten Situationen.
   • Wann? Wo generiert?
2. Optionale Zuweisung eines Stils zu diesem Selektor.
   • Wo spezifiziert? Standard-Erscheinungsbild?

LG --PerfektesChaos 12:57, 20. Okt. 2013 (CEST)

Ich denke nicht, dass es ein Missverständnis gibt, ich bin lediglich anderer Meinung.

Mir persönlich gefällt der Unterstrich in wp_ nicht. MediaWiki verwendet den Präfix mw- mit Bindestrich und benutzt den Unterstrich als Ersatz für bestimmte Interpunktionszeichen, die man in CSS-Selektoren sonst escapen müsste (Beispiel: class="page-Wikipedia_Hauptseite"). Wir haben dies für vorlagenspezifische IDs recht konsequent übernommen (Beispiel: id="Vorlage_Personendaten").

Ich würde in diesem Sinne aus Konsistenzgründen den Präfix wp- für Herkunftsangaben bevorzugen (soweit man eine Herkunftsangabe überhaupt für sinnvoll erachtet). Dagegen spricht, dass wp_boppel und wp_intro bereits mit Unterstrich in Verwendung sind. Die könnte man aber auch ohne Weiteres als historisch bedingte Altlasten betrachten. id="wp_talkpagetext" (ehemals in MediaWiki:Talkpagetext) ist nicht mehr in Verwendung.

Das Anliegen, die hier vorgeschlagene Klasse, Arbeitstitel meinetwegen editoronly, mit einem Herkunfts-Präfix zu versehen, habe ich schon verstanden, bin aber bis jetzt nicht wirklich überzeugt davon. In der englischen Wikipedia gibt es schon ein konsistentes Schema zur Benennung derartiger Klassen, das für uns nicht wirklich ungeeignet ist; wenn man es übernimmt, dann könnte sich daraus einmal ein wikiübergreifender Standard entwickeln, der einmal in MediaWiki übernommen werden könnte.

Nennt man die Klasse dagegen wp_editoronly oder wp-editoronly, dann weiß man mit Sicherheit, dass dies niemals ein wikiübergreifender Standard werden wird und schon dann divergieren oder zu einer Inkonsistenz führen wird, wenn eine Vorlage aus der deutschsprachigen Wikipedia ins deutschsprachige Wiktionary kopiert wird.

Klassen wie NavFrame werden in unzählige Wikis kopiert, darunter auch solche, die gar nichts mit Wikimedia zu tun haben (Beispiel: Teil 1, Teil 2). Ich weiß nicht, ob es besser wäre, wenn sie wp_NavFrame hieße: Entweder, Nachnutzer benennen sie um und müssen immer darauf achten, dass sie bei ihnen anders heißt oder sie benennen sie nicht um und haben dann eben eine sonderbar benannte Klasse in ihrem Wiki. Mir ist das nicht egal.

Dasselbe gilt auch in umgekehrter Richtung: class="sideBox" war mal in MediaWiki, ist aber entfernt worden und wird meines Wissens nur noch in diesem Wiki benutzt; hätte man die Klasse mw-sideBox genannt, dann hätten wir jetzt einen Präfix, der eine falsche Herkunft suggeriert. Herkunftspräfixe haben also nicht nur Vorteile.

So fürchterlich unübersichtlich finde ich die jetzige Situation auch gar nicht. Wikipedia-spezifische Klassennamen sind ohnehin problematisch, weil ihre Verwendung sich (mit oder ohne Präfix) nicht ohne großen Aufwand (Dump-Auswertung) nachverfolgen lässt und sollen allgemein sparsam verwendet werden.

Einem Anwender kann es eigentlich auch meistens egal sein, wo eine Klasse definiert ist, solange sie funktioniert. Das kann man auch durch Dokumentation lösen. Nur weil eine bestimmte Dokumentation nicht gut ist, heißt das nicht, dass es keine gute Dokumentation geben kann. Man muss auch nicht jeden erdenklichen Klassennamen zentral dokumentieren (bei vorlagenspezifischen Klassen und IDs mit Präfix Vorlage_, die nur „auf Vorrat“ angelegt und nie mit bestimmten Styles verknüpft wurden, ergibt das gar keinen Sinn), sondern nur die wenigen, die von allgemeinem Interesse sind. --Entlinkt (Diskussion) 15:03, 20. Okt. 2013 (CEST)

Sammelsurium unter dem Bearbeitungsfenster

Beispiel

1. Seit die Speichern- und Vorschau-Knöpfe in einem Kasten stecken (den finde ich super, nur um das auch zu erwähnen), ist die editTools genannte Zeichenleiste unterhalb des Bearbeitungsfensters weit weg gerückt. Aktuell sind die Zeichen viel näher an der Vorlagenliste als an allem anderen, aber damit haben sie gar nichts zu tun. Sie gehören logisch direkt an das Bearbeitungsfenster heran. Eigentlich sogar über den Speichern-Knopf, mindestens aber sollte der Abstand nach oben ganz entfernt und ggf. der Abstand nach unten minimal vergrößert werden.
2. Nebenher möchte ich mal fragen, welcher Prozentsatz der Benutzer (wenn überhaupt, vermutlich muss man eher nach Promille fragen) mit den unter jeder Vorschau auftauchenden Profiling-Daten etwas anfangen kann? Die Benutzer sind so oder so schon überfordert und nehmen das Wesentliche oft genug gar nicht wahr. Jedes zusätzliche „Rauschen“ lenkt noch stärker davon ab, deshalb halte ich es für angebracht, das zu reduzieren. Können wir die Zeile ausblenden und per Gadget optional machen?
3. Die Wartungskategorien werden bei einer Vorschau jetzt doppelt angezeigt? Ist das ein Versehen?

--TMg 12:08, 30. Aug. 2013 (CEST)

1. In der englischen Wikipedia befindet sich die Sonderzeichenleiste zwischen Bearbeitungsfenster und grauer Zusammenfassungsbox (en:MediaWiki:Gadget-charinsert.js), auf Commons wurde sie in die Toolbar des WikiEditors integriert (commons:MediaWiki:Edittools.js). Beides erscheint mir irgendwie sinnvoller, als was wir haben, ersteres wäre in MediaWiki:Onlyifediting.js wohl leichter umzusetzen.
2. Zu den Profiling-Daten habe ich keine Meinung, die wurden erst kürzlich eingeführt.
3. Die doppelte Anzeige der Wartungskategorien ist lustig, war mir noch gar nicht aufgefallen. Nur der untere, ältere Eintrag (in der grauen Box) reagiert auf die Einstellung „Zeige Wartungskategorien“. Der ausklappbare Eintrag ist neu.

Gruß --Entlinkt (Diskussion) 12:58, 30. Aug. 2013 (CEST)

+1

ad 2.

• Den PP report können nur ein bis zwei Dutzend Vorlagenprogrammierer sinnvoll nutzen; für diese ist das allerdings in gelegentlichen Fällen eine nette Erleichterung.
• Gleichwohl sind diese selbst in der Lage, eine standardmäßige Ausblendung sichtbar zu machen; ein Gadget braucht es dafür nicht. Ankündigung in der Vorlagenwerkstatt und Doku unter Hilfe:Vorlagenprogrammierung reicht völlig.
• Was stattdessen fehlt und seit langem in meiner Liste zu erstellender Hilfeseiten steht, ist die (deutschsprachige) Erklärung, was diese Werte bedeuten und wie sie zu interpretieren sind. Ohne diese Info ist die PP-Tabelle für Normalbenutzer ohnehin gaga. Von den aktiven Programmierern fürchte ich, dass es allenfalls ein halbes Dutzend systematisch nutzt.
• div.limitreport mag auf display:none gehen.

LG --PerfektesChaos 13:39, 30. Aug. 2013 (CEST)

Noch zu 1.: Auf FzW gab es einen m. E. sehr berechtigten Einwand, dass der Abstand zwischen Eingabefenster und Sonderzeichenleiste viel zu groß sei. Entweder man kürzt MediaWiki:Wikimedia-copyrightwarning wirklich drastisch oder man tauscht die beiden Boxen.

Zu 2.: Ok, klingt überzeugend. --Entlinkt (Diskussion) 13:48, 30. Aug. 2013 (CEST)

Ich habe auf [1] den Code für MediaWiki:Onlyifediting.js aktualisiert und getestet, durch die Änderung kommt die Sonderzeichenleiste über den URV-Warnungskasten, außerdem ist diese CSS-Änderung für die Abstände nötig (Zahlen können auch anders ausgewürfelt werden). Beim Kopieren bitte aufpassen, mir sind beim ersten Versuch ein paar Sonderzeichen (die Spacing Modifier Letters im Türkischen etc.) abhanden gekommen, ob meine Skripte, der CodeEditor, mein Browser oder das Wetter schuld waren, kann ich nicht beurteilen. --Schnark 10:48, 31. Aug. 2013 (CEST)

ad 2: Servicelink – VG --PerfektesChaos 15:44, 1. Sep. 2013 (CEST)

Mit meiner Änderung verschwanden die Sonderzeichen auf Special:Upload, ich habe das Skript auf beta.wmflabs entsprechend angepasst, es muss aber noch MediaWiki:Edittools-upload entsprechend [2] angelegt werden, MediaWiki:Edittools kann danach gelöscht werden. --Schnark 09:33, 2. Sep. 2013 (CEST)

Als ersten Schritt habe ich jetzt mal die Parser-Profiling-Daten ausgeblendet.

Die Sonderzeichenleiste würde nach Schnarks Vorschlag in die graue Box wandern, ich hatte eher daran gedacht, sie wie in der englischen Wikipedia zwischen Bearbeitungsfenster und graue Box zu setzen, allerdings fehlen in diesem Bereich IDs, weil die Elemente unsinnigerweise nur Klassen haben … Würde das trotzdem klappen? Falls nicht, wäre es mir in der grauen Box aber auch recht. --Entlinkt (Diskussion) 10:50, 9. Sep. 2013 (CEST)

Offenbar hat keiner Lust, die Leiste an eine andere Stelle zu schieben (ich auch nicht, ich finde sie dort, wo ich sie hingeschoben habe persönlich besser platziert als direkt unter der Eingabebox). Da das gegenwärtige Skript noch addOnloadHook (absurderweise gleich doppelt) verwendet, und diese Funktion in Kürze im Debug-Modus Warnungen darüber ausgeben wird, dass sie deprecated ist, wäre es schön, wenn das Skript bald aktualisiert würde. --Schnark 09:42, 4. Nov. 2013 (CET)

Die Leiste ist jetzt an der vorgeschlagenen Position. Gruß --Entlinkt (Diskussion) 21:29, 4. Nov. 2013 (CET)

Wer hatte die Position innerhalb des grauen Kastens vorgeschlagen? Sie kommt mir falsch vor. Eigentlich hat der Kasten den Sinn, alles zusammenzufassen, was für das Speichern notwendig ist: Zusammenfassung, ob es eine kleine Änderung ist und ob und wie man die Änderung vorab kontrollieren möchte. Das Einfügen von Zeichen in den Text ist so gesehen keine Funktion, die zu dieser Funktionsgruppe gehört. Die englischsprachige Wikipedia macht es (fast) richtig: Da ist die Zeichenleiste oberhalb des grauen Kastens (allerdings mit einer Lücke nach oben zum Bearbeitungsfenster, eine Lücke nach unten wäre logischer). --TMg 21:50, 4. Nov. 2013 (CET)

In en ist die Leiste wesentlich kompakter als bei uns. Ich habe daher die Befürchtung, dass die Leiste direkt unter dem Edit-Feld zu viel Aufmerksamkeit auf sich ziehen würde (so wichtig Typografie auch sein mag, die Zusammenfassungszeile ist wichtiger). Außerdem finde ich persönlich es etwas irritierend, wenn die Leiste zwischen den beiden Eingabefeldern steht, für die sie funktioniert und damit einmal nach oben und einmal nach unten wirkt. Wie dem auch sei, wenn du einen besseren Vorschlag hast, dann lass dir vom Umherirrenden Adminrechte auf http://de.wikipedia.beta.wmflabs.org geben und probiere ihn aus. --Schnark 09:23, 5. Nov. 2013 (CET)

Die Zeichen funktionieren in der Zusammenfassungszeile? Mal ganz ehrlich, wie viele Benutzer wissen und nutzen das? Wo sie jetzt ist, mittendrin zwischen der Zusammenfassungszeile, den Optionen und den Buttons, zieht sie genauso viel Aufmerksamkeit auf sich. Daran ändert die Position nicht viel. Ich finde sogar, dass die Leiste dort unverhältnismäßig viel mehr Aufmerksamkeit auf sich zieht, weil die Benutzer beim Abarbeiten der für das Speichern notwendigen Schritte unterbrochen werden. Um zu betonen, dass die Zeichen auch für die Zusammenfassung funktionieren, müsste die Leiste direkt unter der Zusammenfassung sein, über den Optionen (wobei die Positionierung der Zusammenfassungs-Vorschau zu beachten ist, die wahrscheinlich vor der Zeichenleiste bleiben müsste). Als am ehesten erwartungskonform empfinde ich wie gesagt die Position wie im Englischen, oder zur Not wieder unterhalb, einfach nur mit optimierten Abständen. Mehr wollte ich mit meiner ursprünglichen Meldung doch gar nicht erreichen. Was genau du mit „kompakter“ meinst, verstehe ich nicht ganz. Die Leiste ist bei uns genauso nur eine einzelne Zeile wie im Englischen. --TMg 16:34, 5. Nov. 2013 (CET)

Vorschlag von TMg

Ich hab mal einen Vorschlag erarbeitet. Im Einzelnen:

• Nicht vom kurzen Editfenster irritieren lassen. Das ist nur, um den Screenshot kompakter zu machen.
• Zeichenleiste klebt wie die Werkzeugleiste direkt am Editfenster, denn der primäre Zweck von beidem ist, den Inhalt des Editfenster zu beeinflussen.
• Innenabstand in der Zeichenleiste von 1px auf .2em (oder 2px) erhöht, damit das Selektionsfeld nicht so mit dem Rahmen verschwimmt.
• Rahmen auf silver umgestellt. Das ist minimal heller und konsistenter zu allen anderen Rahmen.
• Mit dem Hintergrund habe ich viel experimentiert. In Frage kommen u. a. das Grau vom Kasten darunter oder der blaue Verlauf aus der Werkzeugleiste. Ich bin ganz bewusst bei Weiß geblieben. Die Leiste rückt dadurch angenehm in den Hintergrund und die Betonung bleibt beim viel wichtigeren grauen Kasten. Ein sehr heller Verlauf wäre denkbar, das PNG aus der Werkzeugleiste lässt sich aber nicht 1:1 nutzen, da es eine graue Linie unten hat und nicht dafür gemacht ist, in der Höhe zu wachsen. Die Zeichenleiste bricht viel schneller auf 2 oder gar 3 Zeilen um.
• Zwischen Zeichenleiste und dem grauen Kasten ist ein 0.5em-Abstand, um die Trennung zwischen „Bearbeitung“ und „Speichern“ zu betonen. Man könnte auf die Lücke verzichten, aber dann wäre der Editor ein riesengroßer Kasten, in dem die schöne funktionale Gruppierung, die mit der Einführung des grauen Kastens entstanden ist, ziemlich untergeht.
• Wie oben schon angedeutet, halte ich es für nebensächlich, dass die Zeichenleiste auch auf die Zusammenfassung wirkt. Die Werkzeugleiste kann das nicht, deswegen rechnet wohl kaum jemand damit, dass die Zeichen das können. Durch eine andere Positionierung könnte man das betonen, ich bewerte die Nachteile aber als schwerwiegender.

Ich selbst habe mir den grauen Kasten übrigens so umgestaltet (roter Kasten weg, Beschriftung „Zusammenfassung“ weg, alle Abstände kompakter) und finde das äußerst angenehm. Das ist natürlich nur etwas für erfahrene Autoren. Für die meisten ist die reguläre Gestaltung des grauen Kastens meiner Meinung nach genau richtig. --TMg 18:43, 5. Nov. 2013 (CET)

Ich finde TMgs Vorschlag deutlich besser als die jetzige Lösung.--Saehrimnir (Diskussion) 00:03, 25. Nov. 2013 (CET)

Wie Benutzer:TMg schon anmerkte und wie es auch mir, trotz absoluter Unkenntnis dieser Geschichte hier auffiel: Die Edittoolleiste hat zwischen den Speicheroptionen (Zusammfassungszeile, Nur Kleinigkeiten wurden verändern, Seite speichern-Butto) nichts zu suchen und stört dort massiv. Es gibt keinerlei Grund, sie nicht unter dem Speichern-Button zu belassen, wo sie vorher war. Offensichtlich ist es nicht ohne weiteres möglich, sich den Urzustand künstlich wiederherstellen zu lassen. Dieser ist wiederum offensichtlich nicht nur von mir erwünscht. @Entlinkt: Bitte verschiebe die Edittoolleiste wieder unter die Buttons Seite speichern etc. wo sie vorher war und bisher anscheinend niemanden gestört hat. Solche Änderungen sind btw. in meinen Augen auch nichts für eine schnelle Nebenbei-Umsetzung, es handelt sich nicht um kosmetische Änderungen, die keinem auffallen. --Paulae 20:32, 25. Nov. 2013 (CET)

@Paulae: Es gibt meiner Meinung nach sehr wohl Gründe, die Leiste „nicht unter dem Speichern-Button zu belassen, wo sie vorher war“, und diese sind in diesem Diskussionsabschnitt auch dargelegt (um es kurz zu machen: die Distanz zwischen dem Bearbeitungsfenster und der Leiste ist zu groß und hat sehr wohl zu expliziten Beschwerden und Änderungswünschen auf WP:FzW und sonstwo geführt, insbesondere bei denjenigen, die den riesengroßen rot umrandeten Kasten mit der Copyrightwarnung nicht ausblenden).

Übrigens stand die Leiste auch noch gar nicht so besonders lange dort unten, sondern ist erst durch eine kürzliche Änderung an MediaWiki dorthin gewandert (auch das kann man diesem Abschnitt entnehmen) und die Verschiebung diente dem Zweck, sie wieder etwas näher dorthin wandern zu lassen, wo sie vorher war.

Mir selbst gefällt die Position, an die ich sie verschoben habe, auch sehr viel weniger als das, was TMg jetzt vorschlägt, aber zum Zeitpunkt, als ich sie verschoben habe, gab es TMg Vorschlag nicht, sondern nur einen Vorschlag von Schnark und da hat mich letztlich überzeugt, dass der Vorschlag wochenlang hier stand und niemand ihn abgelehnt oder eine konkrete Alternative vorgeschlagen hat.

Nun denn: Die Leiste ist jetzt wieder unter den Buttons, wo sie vermeintlich vorher schon lange war (tatsächlich allerdings nicht) und vermeintlich niemanden gestört hat (tatsächlich allerdings doch). Vielleicht schaffen wir es ja noch, eine konsensfähige Lösung zu finden; ich werde allerdings zunächst mal keine Zeit dafür haben. --Entlinkt (Diskussion) 02:10, 26. Nov. 2013 (CET)

Also 2008 stand sie offensichtlich bereits unter dem Speichern-Button, und ja, in meinen Augen ist das eine lange Zeit. Wo soll sie denn vor kurzem sonst gewesen sein? Der Unmut kam offenbar durch die Vergrößerung des Abstandes zustande, den man auch einfach hätte verringern können. Und nein, eine MediaWiki-Diskussionsseite über Common.css habe ich (wie sicher viele Benutzer, die hier hauptsächlich Artikel schreiben) nicht auf der Beo. --Paulae 10:05, 26. Nov. 2013 (CET)

(Nach BK) Danke, Entlinkt. Ich bin mir allerdings ziemlich sicher, dass die Zeichenleiste auch vor der MediaWiki-Änderung unter den Buttons war (2009, 2013). Hinzu kommt ein weiteres Problem: Die Änderung ließ die Buttons nach unten hüpfen. Beispiel: Es kommt vor, dass ich einen Abschnitt bearbeiten und sofort die Vorschau sehen will (das gibt es auch als Option, die habe ich aber absichtlich nicht aktiviert). Ich klicke also auf „Bearbeiten“, scrolle nach unten und versuche, „Vorschau zeigen“ anzuklicken. In den vergangenen Tagen kam es vor, dass mir der Knopf unter der Maus weg sprang, weil die Leiste alles verschob. Leider wird dieses Problem mit meinem obigen Lösungsvorschlag genauso auftreten, so dass ich mich inzwischen dagegen aussprechen muss. --TMg 10:09, 26. Nov. 2013 (CET)

Aufräumen, vielleicht noch dieses Jahr?

Es ist ja in der letzten Zeit schon sehr viel übersichtlicher geworden.

Kürzlich hatte ich auf einer verwandten Disku bereits einen Vorschlag gemacht, den ich nun hierher kopiere:

• Alle FR auf einem Haufen
• Alle table auf einem Haufen
• Alle TOC auf einem Haufen
• Lose Einzelregeln bündeln:

/* Diverse Ausblendungen
 *    #***-icon etc., .topicon
 *       Skinabhängige absolute Positionierungen
 *       [[MediaWiki Diskussion:Common.css/Archiv/1#Absolute Positionierungen]]
 *    .patrollink
 *       Eweiterung ist hier nicht aktiviert
 *       Optik ähnelt zu sehr den gesichteten Versionen
 *    .mw-special-Watchlist .mw-rollback-link
 *       Rollback-Knopf auf Beobachtungsliste
 *       dort nur von sehr beschränktem Nutzen
 *       führt zu sehr vielen Reverts aus Versehen
 *    .geo
 *       [[Vorlage:Coordinate]]
 *       "geo-microformat" zur semantischen Auszeichnung des Texts
 *       Inhalt dieses Tags ist nicht für den Leser bestimmt
 *    .limitreport
 *       [[Hilfe:Vorlagenbeschränkungen|Parser-Profiling-Daten]]
 *    .client-js .noscript
 *       <noscript>-Emulation via <div class="noscript"></div>
 */
#commons-icon,
#coordinates,
#editcount,
#issnlink,
#shortcut,
#spoken-icon,
.topicon,
.patrollink,
.mw-special-Watchlist .mw-rollback-link,
.geo,
.limitreport,
.client-js .noscript {
   display: none;
}

Bis dann --PerfektesChaos 20:50, 5. Nov. 2013 (CET)

Ausrichtung der Spalten in Tabellen

Nachdem bei dieser Diskussion keine weiteren Einwände kamen, wollte ich nun an dieser Stelle vorschlagen, CSS-Klassen für die Ausrichtung von Tabellenspalten in die Common.css aufzunehmen.

Zunächst zum Problem: Wenn Text und Zahlen in Tabellen gemischt werden, kommt es relativ häufig vor, dass einige Spalten links, andere zentriert und wieder anderer rechts ausgerichtet werden – hier mal ein Beispiel. Leider ist es momentan erforderlich, diese Ausrichtung für jede Zelle (!) einzeln zu definieren. Man kann zwar die Tabelle als ganzes auch zentriert ausrichten, dann muss aber jede nach links ausgerichtete Zelle wieder eine eigene Style-Anweisung bekommen. Das macht den Quelltext schwer lesbar und die Bearbeitung teilweise extrem mühselig.

CSS bietet das Element nth-child, welches dazu genutzt werden kann, bestimmte Spalten von Tabellen zu formatieren. Beispielsweise würde table.drittespaltezentriert td.nth-child(3) {text-align:center;} eine Klasse bereitstellen, die die dritte Spalte einer Tabelle zentriert, wenn der Tabelle diese Klasse zugewiesen wird. CSS-Klassen für die ersten 10 Spalten sollten die allermeisten Anwendungsfälle abdecken, zur Not gibt es ja immer noch die Möglichkeit, die bisherige Methode zu nutzen.

Alle üblichen Browser unterstützen heutzutage dieses Element, der letzte Internetexplorer, der dies nicht tat, war die Version 8, dessen Marktanteil liegt in Deutschland allerdings nur noch bei 3,2 Prozent, unter dem Strich ist es ohnehin nur ein gestalterisches Mittel.

Hier mal ein wenig Code, wie das ganze praktisch funktioniert:

<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 sollte nach Aufnahme der neuen Klassen so aussehen, eine Kombination mit wikitable ist problemlos möglich:

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

Ich möchte deshalb vorschlagen, Klassen für die Ausrichtung von Spalten in die Common.css aufzunehmen. Als Benennung würde ich s[1-10][lcr] vorschlagen – s für Spalte, dann die Nummer der Spalte auf die sich die Klasse bezieht und schließlich l für links, c für center und r für rechts. Es müssten also folgende Zeilen in die Commons.css aufgenommen werden:

table.s1l td:nth-child(1), table.s2l td:nth-child(2), table.s3l td:nth-child(3), table.s4l td:nth-child(4), table.s5l td:nth-child(5), table.s6l td:nth-child(6), table.s7l td:nth-child(7), table.s8l td:nth-child(8), table.s9l td:nth-child(9), table.s10l td:nth-child(10) { text-align: left; }
table.s1c td:nth-child(1), table.s2c td:nth-child(2), table.s3c td:nth-child(3), table.s4c td:nth-child(4), table.s5c td:nth-child(5), table.s6c td:nth-child(6), table.s7c td:nth-child(7), table.s8c td:nth-child(8), table.s9c td:nth-child(9), table.s10c td:nth-child(10) { text-align: center; }
table.s1r td:nth-child(1), table.s2r td:nth-child(2), table.s3r td:nth-child(3), table.s4r td:nth-child(4), table.s5r td:nth-child(5), table.s6r td:nth-child(6), table.s7r td:nth-child(7), table.s8r td:nth-child(8), table.s9r td:nth-child(9), table.s10r td:nth-child(10) { text-align: right; }

Viele Grüße --Sepp (Diskussion) 09:26, 25. Feb. 2014 (CET)

Den Wunsch einzelne HTML-Styles auf ganze Spalten auszudehnen, habe ich schon häufiger mal in der deutschsprachigen Wikipedia gelesen.

Wie sieht die Browserunterstützung deines Vorschlags aus? nth-child wird wohl in älteren IEs nicht funktionieren, daher sollte man es nicht nutzen (nth-child für die zebra-Klasse stellt eine Ausnahme da, weil die Tabelle auch ohne dies noch formattiert aussieht, nur ohne Streifen, aber trotzdem nutzbar. Wenn auf einmal die Zentrierung für Spalten fehlt, ist die Tabelle wohl nicht mehr nutzbar).

Die Notwendigkeit eine (un)begrenzte Anzahl an Regeln vorzuhalten, weil die Tabellen unterschiedlichste Anzahl an Spalten haben können, halte ich nicht für sinnvoll, weil es die CSS-Datei weiter aufbläht. Zusätzlich sind die Klassennamen nicht sprechend, so dass sie vom normalen Bearbeiter nicht verstanden und wohl auch nicht verstanden werden (s1l wird wohl "spalte 1 links" heißen). Später kommen auch noch Wünsche, das eine komplette Spalte in Fett oder kursiv oder verschiedenste Farben dargestellt werden sollte. Aus meiner Sicht bringt das kein großen Nutzen und man sollte hier weiterhin die Inline-Styles nutzen. Der Umherirrende 20:41, 12. Mär. 2014 (CET)

Danke für die Antwort. Zu den Punkten im Einzelnen:

• Browserunterstützung: Wie oben geschrieben, ab dem IE 9 funktioniert es. Der Marktanteil des IE≤8 liegt nur noch bei 3,5 Prozent. Grundsätzlich sind die Tabellen auch weiter nutzbar, wenn die Ausrichtung nicht stimmt, sie sehen nur (wie bei Zebra) nicht mehr so schick aus. Ich glaube, fehlende Zebras sind, wenn Zebra Sinn hat, viel schlimmer als die Ausrichtung.
• Anzahl Regeln: Ich sehe das Problem des Aufblähens der CSS Datei, allerdings nicht ganz, was daran allzu schlimm ist. Die wird doch eh nur alle paar Wochen mal neu geladen und das bisschen sollte auch keine wesentlichen Performanceprobleme in der Auswertung geben.
• Sprechende Namen: Diese wiederum blähen den Quelltext in den Artikeln ein wenig auf, erleichtern aber die Benutzung für neue Nutzer sehr. Kann ich mich auch mit anfreunden.
• Induktion weiterer Wünsche: Naja, nur weil dadurch neue unsinnige Begehrlichkeiten entstehen, brauchen ja nicht sinnvolle Dinge pauschal abgelehnt werden. Jedes Programm, das mit Tabellen umgeht, führt so ziemlich als erstes die Ausrichtung ein, sei es nun Excel, GoogleDocs oder LaTeX. Bei letzterem ist die Spaltenausrichtung auch eine der ganz wenigen Dinge, die überhaupt als direkte Formatierung unterstützt werden – weil sie halt recht unverzichtbar in Tabellen ist. Wenn Du Dir mal die händischen Formatierungen von Spalten hier in der Wikipedia anguckst, wirst Du auch feststellen, dass die Ausrichtung den mit weitem Abstand größten Anteil hat.

--Sepp (Diskussion) 14:13, 13. Mär. 2014 (CET)

Technischer Hinweis: In CSS ist es zurzeit nicht möglich, spaltenübergreifende Zellen (HTML-Attribut colspan) korrekt zu behandeln. Der Selektor td:nth-child(X) ist dafür nicht geeignet. Veranschaulichung:

„Spaltenzugehörigkeit“ gemäß CSS-Selektor td:nth-child(X)

Spalte 1	Spalte 2	Spalte 3	Spalte 4
Spalte 1		Spalte 2
Spalte 1	Spalte 2		Spalte 3

CSS zählt einfach stupide von links nach rechts, wodurch man eine komplett durcheinandergewürfelte Formatierung erhält, wenn man td:nth-child(X) als „Approximation“ für die Spaltennummer nimmt.

In CSS 4 ist ein Selektor :nth-column(X) vorgesehen, der dieses Problem lösen würde, aber meines Wissens noch in keinem einzigen Browser implementiert ist. Da in die Common.css eigentlich nur 100%-ig einwandfrei funktionierende Dinge gehören, scheidet der Vorschlag meiner Meinung nach aus (von den anderen Gegenargumenten abgesehen). Gruß --Entlinkt (Diskussion) 22:32, 3. Jun. 2014 (CEST)

Ich stimme völlig zu, CSS4 noch nicht zu verwenden. Ich kann aber beim besten Willen nicht die Argumentation hier nachvollziehen. Tabellen mit kompliziert zusammengefassten Zellen sind eher die Ausnahme und werden nur von ziemlich erfahrenen Benutzern angelegt. Es geht doch darum, die ganzen großen Tabellen besser wartbar zu machen, beispielsweise jene, die sich in den Listenartikeln befinden. Ich verstehe auch beim Besten Willen nicht, wo das Problem in einem „Aufblähen“ der Common.css liegt. Da ist ein riesiger Abschnitt nur für Taxoboxen drin, da ist die Unterstützung für das uralte prettytable-Zeug noch drin, aber etwas, was auf absehbare Zeit den Quelltext sehr vieler Seiten verschlanken und Daten leichter wartbar machen würde, darf nicht rein... Naja, ich sehe aber ein, dass ich zumindest jene, die diese Seite sowie die Hilfeseite zu den Tabellen frequentieren, anscheinend nicht überzeugen kann. Mal schauen, falls ich mal Zeit und Lust habe, würde ich es halt mal per Meinungsbild probieren. Bis dahin aber erstmal danke für die Antworten... --Sepp (Diskussion) 13:52, 4. Jun. 2014 (CEST)

"VERALTET: Nach Toolserver-Abschaltung entfernen"

... steht noch in der Seite. Die folgenden Zeilen sollten dann mal raus, oder? Bin gemeinsam mit anderen auf der Suche nach dem Grund für Fehlermeldungen wie "Ein Skript auf dieser Seite ist eventuell beschäftigt oder es antwortet nicht mehr." (hat damit aber wohl nichts zu tun). --Sitacuisses (Diskussion) 00:45, 3. Jul. 2014 (CEST)

Der Kommentar hat nichts mit den Fehlermeldungen zu tun. Die besagten Zeilen in der CSS-Datei sind einfach nur dazu da, dass Links auf den Toolserver nicht wie externe Links aussehen und sind durch die Abschaltung unnütz geworden. Fehler können sie aber nicht verursachen.

Ich hatte vor, die entsprechenden Zeilen zu entfernen, damit eventuell noch übrig gebliebene Links auf den Toolserver optisch auffallen. So ganz abgeschaltet ist der Toolserver aber nun wohl doch nicht, siehe Wikipedia:Kurier#Sammelstelle „Vermisste Tools“ vom Toolserver („[…] Ausnahmen: Merlbot, OSM-Projekte“). Deshalb habe ich sie jetzt erst mal noch drin gelassen, bis geklärt ist, welche Links noch aktiv sind.

(Gibt es überhaupt noch aktive verlinkbare Tools auf dem Toolserver oder sind die beiden Ausnahmen nur Bots, die auf dem Toolserver laufen?)

Gruß --Entlinkt (Diskussion) 04:28, 3. Jul. 2014 (CEST)

• +1
  • Das ist harmlos. Es verhindert nur, dass ein hinter das Link gemalt wird; reine Dekoration, kann mit dem Problem nichts zu tun haben.
  • Wir wären ohnehin unschuldig an Problemen auf Commons.
• Schau mal nach WP:JS #Fehlermeldungen – das gibt dir ggf. präziseren Aufschluss, was hängt.
  • Muss man aber möglicherweise tiefer einsteigen, um die richtige Info zu finden und Unwichtiges als solches einschätzen zu können.
  • Oft hilft auch die totale Cache-Leerung, wenn seit neuer Software-Version noch Benutzerskripte und andere inkompatible Überreste zurückgeblieben sind.
  • Die eine Meldung, die da wiedergegeben ist, ist nur ein Folgefehler. Mal zusehen, dass man in die fraglichen URL ein debug=true manipuliert bekommt, dann werden die Meldungen zielgenauer.
• Die Dekoration kann jetzt übrigens gelegentlich raus, wir haben Juli und das Teil ist nun extern.
  • Sollte man sogar eher für die nächsten Monate gelb unterlegen, damit auf den Projektseiten die Links gefixt werden können.
  • ~merl hat hinterlassen, er würde die neuen Tools bereitstellen und die Links selbst fixen; 250 URL in Projektseiten hätte er vor sich. Aber vielleicht fragt er einen Botbetreiber.
  • Manche Toolserver-Links sind mit mehr oder weniger funktionstüchtigen Weiterleitungen ausgestattet; mal mit und mal ohne Weiterreichen der aktuellen Parameter. Der Toolserver selbst wird keine Datenbankabfragen mehr vornehmen können. ~merl und OSM und so haben eine befristete Sonderregelung, weil die Folge-Architektur noch nicht fit ist.
  • Ich denke, von August bis Dezember 2014 sollte man auf den Projektseiten mal ein wenig drängeln und die Dinger gelb machen; sonst lassen die Leute die Weiterleitungen ewig stehen und bemerken das Problem nicht. Im Juli noch warten, bis weitere neue Tools robust sind.

LG --PerfektesChaos 10:19, 3. Jul. 2014 (CEST)

Das Skripte nicht antworten dürfte Bug 67420 gewesen sein. Ist zumindestens das zeitlich naheliegende Ereignis dazu. Der Umherirrende 19:56, 3. Jul. 2014 (CEST)

bugzilla:48858

Der Bug wird zwar in gerrit:164521 nicht genannt, für mich sieht es aber so aus, als ob er dadurch behoben wird. Benutzer:Entlinkt, du verstehst von uns hier vermutlich am besten, was Sache ist, schließt du gegebenenfalls den Bugreport entsprechend und wirst bei uns den Fix raus, sobald die Änderung hier live ist? --Schnark 11:06, 6. Okt. 2014 (CEST)

Ja, das ist prinzipiell der richtige Fix.

An der Sache ändert sich ständig irgendwas, und zwar in der Vergangenheit skinabhängig. (Daraus folgt unmittelbar, dass der Fehler in der Vergangenheit aus skinabhängig verschiedenen CSS-Dateien bzw. „Themes“ gekommen sein muss; momentan finde ich aber nur mehr resources/lib/jquery.ui/themes/smoothness/jquery.ui.core.css).

So ganz blicke ich jetzt selbst nicht mehr durch, aber ich werd’s im Auge behalten und den Workaround entfernen, sobald er nicht mehr nötig ist (in der Hoffnung, dass er dann auch unnötig bleibt). Gruß --Entlinkt (Diskussion) 18:57, 6. Okt. 2014 (CEST)

Hm. Die entsprechende Datei des Vector-Skins ist noch immer auf dem alten Stand, und ich vermute, dass diese die Core-Datei nicht ergänzt, sondern überschreibt. --Schnark 09:27, 7. Okt. 2014 (CEST)

Für Vector wurde folgendes gemerged: gerrit:176620/phab:T73601. @Schnark, Entlinkt: vielleicht ist das der fehlende Teil? Der Umherirrende 22:46, 5. Dez. 2014 (CET)

Ja, ist es. --Entlinkt (Diskussion) 06:24, 6. Dez. 2014 (CET)

@Entlinkt: Der Change ist gestern abend live gegangen. Vielleicht kannst du es nochmal prüfen und dann entfernen. 30 Tage muss man hier nicht warten, weil die Änderung an Modulen ja schneller gehen sollte. Vielen Dank. Der Umherirrende 21:48, 11. Dez. 2014 (CET)

Workaround entfernt. --Entlinkt (Diskussion) 01:02, 17. Dez. 2014 (CET)

Dieser Abschnitt kann archiviert werden. Entlinkt (Diskussion) 01:02, 17. Dez. 2014 (CET)

Editinginterface + Translateinterface

Mit gerrit:165039 habe ich den Satz wegen translatewiki.net aus der Nachricht MediaWiki:Editinginterface in die neue Nachricht MediaWiki:Translateinterface geschoben. Da die Nachrichten lokal vorhanden waren, habe ich das lokal auch gemacht. Jetzt würde ich gerne den Kasten um beide Texte haben, ohne eine Linie in der Mitte zu haben. Wie mach ich das am besten?

/* Warnmeldung bei der Bearbeitung von Seiten im MediaWiki-Namensraum */
.mw-editinginterface {
	background: #f9f9f9;
	border: 1px solid #c00000;
	padding: 2px;
}

müsste ersetzt werden. Vorschläg wäre:

/* Warnmeldung bei der Bearbeitung von Seiten im MediaWiki-Namensraum */
.mw-editinginterface,
.mw-translateinterface {
	background: #f9f9f9;
	border: 1px solid #c00000;
	padding: 2px;
}
.mw-editinginterface + .mw-translateinterface {
	border-top: none;
	margin-top: -8px;
}

Die Kästen treten nicht immer zusammen auf, nur dann wenn es auch etwas im translatewiki.net gibt, sonst ist nur der erste Kasten da. Über Kommentare würde ich mich freuen. Der Umherirrende 20:45, 31. Okt. 2014 (CET)