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?

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.

Definiert sind rahmenfarbe1 bis rahmenfarbe5 und hintergrundfarbe1 bis hintergrundfarbe9.

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.

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 MediaWiki Diskussion:Common.css#c-✓-2010-07-29T11:35:00.000Z-float-right11Beantworten

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 MediaWiki Diskussion:Common.css#c-Fomafix-2010-07-29T12:07:00.000Z-✓-2010-07-29T11:35:00.000Z11Beantworten

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 MediaWiki Diskussion:Common.css#c-✓-2010-07-29T13:23:00.000Z-Fomafix-2010-07-29T12:07:00.000Z11Beantworten

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 MediaWiki Diskussion:Common.css#c-Fomafix-2010-07-30T11:30:00.000Z-✓-2010-07-29T13:23:00.000Z11Beantworten

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 MediaWiki Diskussion:Common.css#c-✓-2010-07-30T12:51:00.000Z-Fomafix-2010-07-30T11:30:00.000Z11Beantworten

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 MediaWiki Diskussion:Common.css#c-Entlinkt-2010-07-30T17:31:00.000Z-✓-2010-07-30T12:51:00.000Z11Beantworten

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 MediaWiki Diskussion:Common.css#c-Entlinkt-2010-08-06T16:32:00.000Z-✓-2010-07-30T12:51:00.000Z11Beantworten

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 MediaWiki Diskussion:Common.css#c-✓-2010-08-07T10:11:00.000Z-Entlinkt-2010-08-06T16:32:00.000Z11Beantworten

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 MediaWiki Diskussion:Common.css#c-Fomafix-2010-08-07T12:38:00.000Z-✓-2010-08-07T10:11:00.000Z11Beantworten

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 MediaWiki Diskussion:Common.css#c-Entlinkt-2010-08-08T02:17:00.000Z-Fomafix-2010-08-07T12:38:00.000Z11Beantworten

@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 MediaWiki Diskussion:Common.css#c-✓-2010-08-08T10:46:00.000Z-float-right11Beantworten

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 MediaWiki Diskussion:Common.css#c-Entlinkt-2010-08-08T12:56:00.000Z-✓-2010-08-08T10:46:00.000Z11Beantworten

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 MediaWiki Diskussion:Common.css#c-Entlinkt-2010-08-08T14:48:00.000Z-Entlinkt-2010-08-08T12:56:00.000Z11Beantworten

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 MediaWiki Diskussion:Common.css#c-Fomafix-2012-01-09T01:14:00.000Z-float-right11Beantworten

Es gibt bereits in MediaWiki die Klassen floatleft und floatright (ohne Bindestrich). --Fomafix MediaWiki Diskussion:Common.css#c-Fomafix-2012-01-30T16:13:00.000Z-Fomafix-2012-01-09T01:14:00.000Z11Beantworten

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:

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

<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 MediaWiki Diskussion:Common.css#c-Fomafix-2012-01-30T21:15:00.000Z-float-right11Beantworten

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) MediaWiki Diskussion:Common.css#c-Entlinkt-2013-05-12T15:52:00.000Z-Fomafix-2012-01-30T21:15:00.000Z11Beantworten

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) MediaWiki Diskussion:Common.css#c-Fomafix-2013-05-12T15:57:00.000Z-Entlinkt-2013-05-12T15:52:00.000Z11Beantworten

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) MediaWiki Diskussion:Common.css#c-Entlinkt-2013-05-14T19:05:00.000Z-Fomafix-2013-05-12T15:57:00.000Z11Beantworten

Eine lange Diskussion. Versuch einer Zusammenfassung des aktuellen Standes (zwecks Vereinfachung beschränke ich mich auf float-right und ignoriere float-left):

• Wir haben eine lokal definierte Klasse float-right, ursprünglich eingefügt im Januar 2007 mit diesem Edit und um Abstände ergänzt im März desselben Jahres mit diesem Edit nach dieser Diskussion. Man kann der Diskussion entnehmen, dass die Klasse in erster Linie zur Kombination mit wikitable als Ersatz für Vorlage:Prettytable-R gedacht war. Dies erklärt die Wahl der Abstände, es sind schlicht und einfach exakt dieselben wie in der gelöschten Vorlage. Der Selektor wurde später geändert, um weitere Verwendungen zu ermöglichen, so dass die Definition derzeit folgendermaßen lautet:

  div.float-right,
  table.float-right,
  ul.float-right,
  .float-right {
  	clear: right;
  	float: right;
  	margin: 1em 0 1em 1em;
  }
  

• Das MediaWiki-eigene CSS definiert eine Klasse floatright mit einer völlig anderen Entstehungsgeschichte. Die Definition ist auf verschiedene Dateien verteilt. Hier eine Zusammenstellung der Teile aus mediawiki.legacy/shared.css und mediawiki.skinning/content.css:

  div.floatright,
  table.floatright {
  	border: 0; /* ??? */
  	clear: right;
  	float: right;
  	margin: 0 0 .5em .5em;
  	position: relative; /* ??? */
  }
  div.floatright p {
  	font-style: italic; /* ??? */
  }
  

  

  Diese Klasse verwendet MediaWiki für rechts ausgerichtete Bilder wie das nebenstehende Beispiel. Ich vermute, dass sie für andere Verwendungen eigentlich überhaupt nicht vorgesehen ist; wegen der mit ??? kommentierten Teile ist sie für andere Verwendungen nur sehr eingeschränkt geeignet. Es ist völlig unklar, wofür diese Teile überhaupt gut sein sollen; bei Bildern sind sie weder nützlich noch störend, aber bei anderen Verwendungen wären sie störend.
• Der Thread begann mit der Frage, ob wir die Abstände in unserer Definition ändern sollten, befasste sich später aber auch mit der Frage, warum es überhaupt zwei unterschiedlich definierte Klassen gibt. Die letztgenannte Frage ist meiner Meinung nach spätestens hiermit beantwortet.
• Ich kann nicht mehr rekonstruieren, was mich in meinem letzten Beitrag von 2013 geritten hat, zu meinen, dass wir beides zusammenführen könnten. Momentan bin ich der Meinung, dass wir das nicht tun sollten, da die Klassen verschiedenen Zwecken dienen und floatright vermutlich sogar nur für MediaWiki-interne Zwecke vorgesehen ist. Unabhängig davon sollten die mit ??? kommentierten Teile meiner Meinung nach aus der Definition von floatright gestrichen werden, da sie nutzlos sind, aber das ist nicht unser Problem.
• Was bleibt, ist die Frage, ob wir in unserer Definition von float-right die Abstände anders einstellen sollten. Hier war und bin ich der Meinung, dass eine komplizierte Heuristik wie im ursprünglichen Vorschlag nicht in Frage kommt, sondern allenfalls eine generelle Änderung (d. h. eine Änderung, die den Selektor in Ruhe lässt und nur den margin-Wert verändert).

--Entlinkt (Diskussion) MediaWiki Diskussion:Common.css#c-Entlinkt-2016-04-23T04:05:00.000Z-float-right11Beantworten

Der initialen Beschwerde über das Aussehen würde ich nicht folgen.

Das größere Problem ist der grottige Einsatz in Artikeln, mit dem die Leute versuchen, das so aussehen zu lassen wie in ihren Papierzeitschriften.

Nix tun. Eher ein paar von den Dingern mit Überbreite zurückbauen auf normale linksbündige, dann passt das auch auf Smartphones und bei schmalen Bidschirmfenstern.

Wenn schon, dann 1em nach links und oben/unten 0.5em.

Wir haben auch noch knapp 100 floatright – das sind vermutlich Verwechslungen. Teilweise stehen noch margins mit bei.

• Bei den Gemeinderatswahlen in Semmering (Niederösterreich) sehe ich keine Verschlechterung; egal ob mit oder ohne margin.

LG --PerfektesChaos MediaWiki Diskussion:Common.css#c-PerfektesChaos-2016-04-23T20:01:00.000Z-Entlinkt-2016-04-23T04:05:00.000Z11Beantworten

Aus Transparenzgründen habe ich mal aus den gelöschten Versionen der beiden ehemaligen Vorlagen zusammengetragen, in welchen Zeiträumen welche margin-Werte galten und welche Benutzer sie jeweils eingestellt haben. Eventuell können daraus irgendwelche Rückschlüsse gezogen werden. (Zeiträume von weniger als einem Tag habe ich vernachlässigt, d. h. die Tabelle enthält keine Tests und keine Änderungen, die sofort zurückgesetzt wurden.)

Auf jeden Fall kann man den Schluss ziehen, dass die jetzigen Abstände made by Augiasstallputzer (Diskussion • Beiträge • gelöschte Beiträge • hochgeladene Dateien • SBL-Log • Sperr-Logbuch • globale Beiträge • SUL • Logbuch • sperren) sind. Dies ist auch der Benutzer, der später den Botlauf zur Umstellung auf CSS durchgeführt hat.

Ich würde darüber hinaus auch den Schluss ziehen, dass ein kleinerer margin-top-Wert auf jeden Fall zumindest denkbar ist. Ob es eine gute Idee wäre, das nach so vielen Jahren noch zu versuchen, weiß ich allerdings nicht. --Entlinkt (Diskussion) MediaWiki Diskussion:Common.css#c-Entlinkt-2016-04-23T23:32:00.000Z-PerfektesChaos-2016-04-23T20:01:00.000Z11Beantworten

• Das .floatright, .floatleft { border: 0 } wurde in gerrit:333910 entfernt.
• Das .floatright p, .floatleft p { font-style: italic } wurde in gerrit:452192 entfernt.
• Für das .floatright, .floatleft { position: relative } habe ich mit gerrit:562836 eine Entfernung vorgeschlagen. --Fomafix (Diskussion) MediaWiki Diskussion:Common.css#c-Fomafix-2020-01-08T14:53:00.000Z-Entlinkt-2016-04-23T04:05:00.000Z11Beantworten

gerrit:562836 ist nun gemerged und deployt. floatright und floatleft beinhalten nun kein position: relative mehr. Absolute Positionierungen bei der Überschrift wie bei Koordinaten sind nun wie bei float-right und float-left möglich. --Fomafix (Diskussion) MediaWiki Diskussion:Common.css#c-Fomafix-2020-03-20T14:06:00.000Z-Entlinkt-2016-04-23T04:05:00.000Z11Beantworten

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) MediaWiki Diskussion:Common.css#c-Christian1985-2011-02-04T02:07:00.000Z-en:Template:Wikicite (Vorlage für Nachweis)11Beantworten

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 MediaWiki Diskussion:Common.css#c-91.22.243.115-2011-02-04T11:05:00.000Z-Christian1985-2011-02-04T02:07:00.000Z11Beantworten

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) MediaWiki Diskussion:Common.css#c-Christian1985-2011-02-04T15:22:00.000Z-91.22.243.115-2011-02-04T11:05:00.000Z11Beantworten

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 MediaWiki Diskussion:Common.css#c-TMg-2013-05-24T11:32:00.000Z-Hervorheben von Linkzielen11Beantworten

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) MediaWiki Diskussion:Common.css#c-Entlinkt-2013-05-25T15:55:00.000Z-TMg-2013-05-24T11:32:00.000Z11Beantworten

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 MediaWiki Diskussion:Common.css#c-TMg-2013-05-25T22:52:00.000Z-Entlinkt-2013-05-25T15:55:00.000Z11Beantworten

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) MediaWiki Diskussion:Common.css#c-Entlinkt-2013-05-26T09:59:00.000Z-TMg-2013-05-25T22:52:00.000Z11Beantworten

Infolge der Softwareänderung gerrit:196172 (Frühjahr 2015) und einer Änderung in der englischen Wikipedia (September 2015) würde die Anfrage heute wahrscheinlich lauten, folgendes einzufügen:

.citation:target {
	background-color: #def;
	background-color: rgba(0, 127, 255, .133);
}

--Entlinkt (Diskussion) MediaWiki Diskussion:Common.css#c-Entlinkt-2016-03-28T00:31:00.000Z-Zusammenfassung zu .citation11Beantworten

Spricht etwas dagegen, die Definitionen für die aktuell fünf Rahmenfarben so auszuweiten, dass auch die folgenden beiden Fälle 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 MediaWiki Diskussion:Common.css#c-TMg-2013-08-22T11:54:00.000Z-Rahmenfarben für Tabellen11Beantworten

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) MediaWiki Diskussion:Common.css#c-Entlinkt-2013-08-22T17:53:00.000Z-TMg-2013-08-22T11:54:00.000Z11Beantworten

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 MediaWiki Diskussion:Common.css#c-TMg-2013-08-22T18:33:00.000Z-Rahmenfarben für Tabellen11Beantworten

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) MediaWiki Diskussion:Common.css#c-Entlinkt-2013-08-22T20:25:00.000Z-TMg-2013-08-22T18:33:00.000Z11Beantworten

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 MediaWiki Diskussion:Common.css#c-TMg-2013-08-27T19:34:00.000Z-Entlinkt-2013-08-22T20:25:00.000Z11Beantworten

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) MediaWiki Diskussion:Common.css#c-Entlinkt-2013-10-04T08:16:00.000Z-TMg-2013-08-27T19:34:00.000Z11Beantworten

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) MediaWiki Diskussion:Common.css#c-Fomafix-2013-10-04T10:17:00.000Z-Entlinkt-2013-10-04T08:16:00.000Z11Beantworten

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) MediaWiki Diskussion:Common.css#c-Entlinkt-2013-10-04T15:48:00.000Z-Fomafix-2013-10-04T10:17:00.000Z11Beantworten

Ich habe mittlerweile gelernt, dass auf Diskussionsseiten vor sich hingammelnde Abschnitte mit konkreten Codevorschlägen gefährlich sind, weil die Gefahr besteht, dass sie Jahre später noch umgesetzt werden, obwohl sie problematisch sind. Unter anderem haben wir neuerdings eine Regel, die in 3 von 4 Skins eine farbliche Kleinständerung von Links auf der Beobachtungsliste bewirkt, im vierten Skin allerdings eine größere und IMHO falsche Änderung, und die nach zwei Jahren vor sich hingammelnder Diskussion noch umgesetzt wurde, obwohl sogar dabei stand, dass sie nicht ausgereift ist.

Deshalb: Ich halte ganz konkret meinen eigenen Codevorschlag vom Oktober 2013, der bei uns lokal inherit-Verhaltensweisen für wikitable einführen würde, für eine nicht nur nicht besonders gute, sondern sogar ziemlich üble Sache und habe längst aufgehört, ihn zu testen. Auch die Aussagen zur Browserkompatibilität sind völlig veraltet.

Da es rund um wikitable in der Vergangenheit viel Ärger und Verwirrung gab und der jetzige Zustand („wikitable kommt von MediaWiki und ist bei uns genau so wie überall sonst“) nun schon eine ganze Weile besteht und meiner Meinung nach recht gut funktioniert, bin ich mittlerweile der Meinung, dass wir an der wikitable-Definition überhaupt gar nichts lokal verändern sollten.

Allenfalls könnte ich mir noch vorstellen, unsere lokal definierten Klassen für Rahmenfarben zu ändern, so dass sie mit wikitable kombiniert werden können. Das war ja auch der ursprüngliche Vorschlag, würde allerdings die 5 Definitionen ziemlich aufblähen. (Mein Vorschlag vom Oktober 2013 vermeidet das Aufblähen an 5 Stellen und bläht dafür nur an einer Stelle auf, hat dafür aber eine ganze Reihe von anderen Nachteilen; ich beschränke mich hier mal auf den Punkt, dass so eine Änderung an einer im MediaWiki-Core definierten Klasse natürlich aktuell gehalten und allgemein zugänglich dokumentiert werden müsste, was erfahrungsgemäß nicht geschieht.) --Entlinkt (Diskussion) MediaWiki Diskussion:Common.css#c-Entlinkt-2016-04-23T00:10:00.000Z-Rahmenfarben für Tabellen11Beantworten

Bitte den ganzen „hauptseite“ Quatsch entfernen, dabei gleich prettytable (die 50 Einbindungen die es noch gibt wird man schon verkraften und dann evtl. auch eher bemerken...) Ich besuche die Hauptseite zweimal im Jahr und dennoch rattert der Schwall an Definitionen bei jedem Seitenaufruf hoch und runter, selbst die En hat sowas nicht obwohl dort die .css mehr als doppelt so groß ist.

/* Bitte KEINE weiteren Definitionen dieser Art für Boxen hier, das gehört in entsprechende Vorlagen! */
/* Hier 20 Mal Trivialitäten wie „text-align:center“ zu definieren verlangsamt alles und ist nicht */
/* Sinn der Sache. (Und wer nicht weiß warum, hat's nicht verstanden.) */

Des Weiteren sollten mehr gleiche Definitionen mit einem Komma gesammelt werden.[1] ↔ User: Perhelion MediaWiki Diskussion:Common.css#c-Perhelion-2015-06-02T12:28:00.000Z-Entschlacken (opt)11Beantworten

#Aufräumen, vielleicht noch dieses Jahr?

• Solange Entlinkt nicht wieder aktiv wird, wird hier auch nicht viel passieren. So viele Admins, die in CSS sattelfest sind und hier aufräumen wollten haben wir nicht.

Was bringt dich auf 50 prettytable?

• WD:Technik/Baustellen/prettytable und wikitable – ich zähle 37.750 Artikel.

Was soll dieser Abschnitt denn jetzt bewirken? --PerfektesChaos MediaWiki Diskussion:Common.css#c-PerfektesChaos-2015-06-02T13:26:00.000Z-Perhelion-2015-06-02T12:28:00.000Z11Beantworten

Oh* da habe ich mich wohl verlesen und etwas untertrieben. ^^ Ich finde es aber schon beachtlich, wie Meme so funktionieren. prettytable war (wohl eigentlich?) nie in einer deutschen Anleitung für Wiki-Syntax (und da wo sie wohl irgendwie erfunden wurde in En ist sie schon gelöscht)!? Der Abschnitt soll bewirken, dass wir alle Energie und Zeit sparen und uns leichtertige Verschwendung von Ressourcen bewusst machen. Das mit der Hauptseite ist wirklich der Overkill schlecht hin, was man unter CSS technischen Kosten/Nutzen versteht. Ich würde alle classes auf der Seite auflösen und bei längeren einen Baustein erstellen (z.B. wie {{Bausteindesign8}}...) PS: Wenn etwas dagegen spricht würde ich einen Phab-Task extra für die deutsche Hauptseite eröffnen. VG ↔ User: Perhelion MediaWiki Diskussion:Common.css#c-Perhelion-2015-06-02T18:46:00.000Z-PerfektesChaos-2015-06-02T13:26:00.000Z11Beantworten

Was zum Henker hat eine deWP-Hauptseite auf Phab verloren?

Was immer du vorhast, es gehört auf unsere Hauptseiten-Disk.

Und ohne einen in Vorlagenprogrammierung und CSS erfahrenen Admin, der sich der Sache annähme, wird da Null bei rauskommen, egal wie viel du wo diskutierst.

Nebenbei ist <kbd> reserviert für die semantische Bedeutung Tastatureingabe und kein Ersatz für tt oder code.

LG --PerfektesChaos MediaWiki Diskussion:Common.css#c-PerfektesChaos-2015-06-02T19:01:00.000Z-Perhelion-2015-06-02T18:46:00.000Z11Beantworten

Mittlerweile kann man wohl alles in Phab eintragen (und die Hauptseite oder die globale CSS ist ja wohl nicht unwichtig!?), vor allem da dort die "kompetenten Leute" sitzen im Gegensatz zu hier (wie du sagst).

Ja du hast Recht, ich sollte das zuerst auf der Hauptseite vortragen.

Dass es keine kleine Minderheit von technisch "wissenden" Admins gibt, hatte ich nicht gewagt zu befürchten.

Ja, das ist die Sache die ich nicht verstehe, dass Elemente als deprecated eingestuft sind und es dafür keinen wirklichen Ersatz gibt.

LG ↔ User: Perhelion MediaWiki Diskussion:Common.css#c-Perhelion-2015-06-03T12:25:00.000Z-PerfektesChaos-2015-06-02T19:01:00.000Z11Beantworten

• Was du auf Phab mit irgendeinem Japaner auf Englisch ausdiskutierst, ist völlig wuascht; egal ob du es dürftest oder nicht.
  • Du müsstest dir überlegen, wer in die Programmierung unserer Hauptseite eingreifen soll.
  • Das kann nur ein hiesiger Admin sein.
  • Der hätte aber Phab nicht auf der Beo, sondern nur unsere Seiten.
  • Insofern ein von vornherein zum Scheitern verurteilter Arbeitsprozess.
  • Eher: Such dir erst einen Admin, der genug CSS usw. kann und Langeweile hätte, und wenn du den hast, geh die Details an, und zwar hierzuwiki.
• HTML5 ist in die Semantik gegangen; und zwar nur noch.
  • HTML 2, 3 und überwiegend auch noch 4 waren typografisch/darstellend.
  • Die optische Wirkung erfolgt jetzt nur noch, indem du ausschließlich <span> verwendest und jedem einzelnen Element per class oder style das optische Aussehen mitgibst. Die unterschiedlichen Elemente ordnen nur noch die unterschiedlichen Bedeutungen zu.
  • Insofern braucht es keinen Ersatz zu geben, und dieses ganze Gedöns von deprecated ist für ein Wiki völlig verfehlt. Nimm <code> und gut ist.
• Der Kontext, wo es herstammt, ist konfus, aber das Teil gefällt mir:

LG --PerfektesChaos MediaWiki Diskussion:Common.css#c-PerfektesChaos-2015-06-03T13:14:00.000Z-Perhelion-2015-06-03T12:25:00.000Z11Beantworten

Ich halte nichts davon, thematisch fremde Dinge per Komma-Schreibweise zu verbinden, damit die Seite entschlackt wird. Für die Wartbarkeit ist es erheblich besser, wenn jede einzelne Anweisung ein Kommentar hat und man damit weiß, wofür sie da ist.

Das die Hauptseite keine eigene Seite für CSS-Anpassungen hat, ist unschön, aber nicht zu ändern. Es soll auch Benutzer geben, die über die Hauptseite einsteigen (als Lesezeichen) oder sie sogar als Startseite im Browser verwenden. Es soll auch Benutzer geben, die persönliche Anpassungen für die Hautpseite in der user.css haben, die dann auch nicht mehr so einfach wirken. Daher resultiert für mich kein Änderungsbedarf aus diesem Abschnitt. Der Umherirrende MediaWiki Diskussion:Common.css#c-Umherirrender-2015-07-17T19:28:00.000Z-Perhelion-2015-06-02T12:28:00.000Z11Beantworten

Ich benutze diesen Thread einfach mal, um hier ein ganz und gar subjektives Code-Review zu deponieren. Keine der folgenden Bewertungen soll aussagen, dass irgendetwas gemacht werden soll oder muss, sondern es sind nur Ideen. Zeilennummern beziehen sich auf diese Version.

--Entlinkt (Diskussion) MediaWiki Diskussion:Common.css#c-Entlinkt-2016-03-28T05:18:00.000Z-Entschlacken (opt)11Beantworten

Danke Entlinkt. Dabei möchte ich erst mal nur auf den Kommentar vom Umherirrenden eingehen, ich sehe das ganz anders (ich verstehe immer noch nicht wieso man standardmäßig alle seine Beiträge als geringfügig markiert, so sehe ich niemals Antworten von ihm (in der Beo) ist ja auch nicht so, dass dies nicht erwünscht ist).

Die Hauptseite kann wie jede andere "Projekt"-Seite CSS per Vorlage oder sogar prädestiniert direkt CSS einbinden. Es ergibt gar keinen Sinn hier globale Definitionen für eine einzelne Seite zu fordern, das führt diese Technik und diese Seite ein Stück weit ad absurdum. Die Definitionen können alle in Vorlagen versteckt werden (zumal auch der Umherirrende eh generell eine Trennung/Zerstückelung bevorzuzugen scheint). Und falls es wirklich einen Layout-Engpass gibt, gibt es immer noch eine (wohl seit letztem Jahr neue) Technik, nur für einzelne Seiten CSS (oder sogar JS, Lua) anzulegen. Grüße ↔ User: Perhelion MediaWiki Diskussion:Common.css#c-Perhelion-2016-03-28T21:05:00.000Z-Entlinkt-2016-03-28T05:18:00.000Z11Beantworten

In Bezug auf das Hauptseiten-CSS würde ich gern auf das Folgende hinweisen: Zunächst mal kann man diesbezüglich wohl durchaus den Standpunkt vertreten, dass das externe CSS tatsächlich sinnvoll sei (zwecks Anpassbarkeit); außerdem ist es die Umsetzung eines Meinungsbilds (von 2006) und deshalb etwas heikel (spezialisierte Wikijuristen können sagen, dass das Meinungsbild nicht nur das Aussehen der Hauptseite, sondern auch die Umsetzung durch externes CSS vorgibt, vielleicht hätten sie damit sogar recht – habe ich jetzt nicht nachgeprüft).

Darüber hinaus werden die Definitionen aber auch in großem Maßstab außerhalb der Hauptseite verwendet (Suchanfrage, 2000 Treffer in allen Namensräumen).

• Zum weitaus größten Teil sind das die Seiten der Kategorie:Wikipedia:Hauptseite/Archiv. Diese Seiten kann man nicht einfach brechen, weil das den Zweck der Kategorie ad absurdum führen würde. Sicherlich ließe sich hierfür eine Lösung finden.
• Es gibt allerdings auch Portalseiten: Portal:Segeln, Portal:Segeln/Mitarbeit, Portal:Wirtschaft/Projekt:Wiwiwiki Organizational Behaviour/t. Die erste dieser drei Seiten hat sogar eine Auszeichnung. Man müsste sich darauf einstellen, dass für jede einzelne betroffene Seite einzeln ausdiskutiert werden muss, warum dort überhaupt etwas geändert werden muss und wenn ja, was – mit offenem Ergebnis. Man sollte nämlich nicht so naiv sein, zu glauben, dass ein Beschluss auf einer CSS-Diskussionsseite „Wir entfernen jetzt das Hauptseiten-CSS“ einfach so akzeptiert wird. Wikipedianer (speziell :de-Wikipedianer) sind Besitzstandswahrer und geben nicht so einfach her, was sie einmal hatten. Im Zweifelsfall kommt das „Argument“ If it ain't broke, don't fix it.
• Für mich persönlich das größte Hindernis sind allerdings die 88 Benutzerseiten (Suchanfrage). Ganz ehrlich: Die Auseinanderzusetzung damit kommt für mich auf keinen Fall in Betracht. Während Wikipedianer bei Artikeln und Vorlagen „nur“ besitzstandswahrend auftreten, können sie richtig widerwärtig werden, sobald es um ihre Benutzerseiten geht. Als Beispiel verweise ich mal auf die Diskussion unter en:Template talk:Top icon#Sorting. Dort geht es darum, dass kleine Icons auf Benutzerseiten nach einer grob vergleichbaren Umstellung (von einem CSS-Hack auf das dafür vorgesehene Softwarefeature) in einer anderen Reihenfolge als vorher angezeigt werden und Benutzer fordern, dass das Ganze zwecks Wiederherstellung des Aussehens ihrer Benutzerseite zurückgedreht wird, obwohl im Vorfeld explizit davor gewarnt wurde, dass der CSS-Hack jederzeit brechen kann.
  So absurd dies auch sein mag (und so idiotisch es auch sein mag, sich zwecks Gestaltung der eigenen Benutzerseite auf eine ID namens hauptseite zu verlassen), ist dies die Realität. Es hat irgendwann einmal funktioniert (und deshalb – so sagen es manche – bis in alle Ewigkeit weiter zu funktionieren) … Nein, hier fällt die Abwägung zwischen Optimierung und Lebenszeit/Lebensqualität für mich ganz klar zugunsten der Lebenszeit/Lebensqualität aus.

In diesem Punkt (Hauptseiten-CSS) wäre es wahrscheinlich strategisch günstig, ein allgemeines (optisches) Redesign der Hauptseite abzuwarten und zu schauen, ob in diesem Zusammenhang dann eine bessere Lösung für das CSS gefunden werden kann.

Dies habe ich jetzt deshalb so ausführlich dargelegt, um nochmal klarzumachen, dass jede einmal hier einfügte Ergänzung im Worst-Case niemals wieder entfernt werden kann. Das ist ein allgemeineres Problem als das Hauptseiten-CSS und betrifft selbst solche Ergänzungen, die für ihren eigentlich vorgesehenen Zweck überhaupt nicht mehr funktionieren (vgl. nogrid-Beispiel). Gruß --Entlinkt (Diskussion) MediaWiki Diskussion:Common.css#c-Entlinkt-2016-04-17T23:47:00.000Z-Perhelion-2016-03-28T21:05:00.000Z11Beantworten

Sobald aus phab:T483 etwas wird, könnte man das CSS für die Hauptseite zum größten Teil in eine Vorlage auslagern und dann dort einbinden, wo es gebraucht wird. --Schnark MediaWiki Diskussion:Common.css#c-Schnark-2016-04-18T07:57:00.000Z-Entlinkt-2016-04-17T23:47:00.000Z11Beantworten

Daran wird aktuell gearbeitet? Ist ja krass. Weitere denkbare Anwendungsanfälle:

• Vorlagen mit eigenem CSS, das noch nicht in andere Vorlagen bzw. direkt in Artikel geleakt ist:
  • Vorlage:TOC nonum
  • Vorlage:TOC limit
• Systemnachrichten (falls es dort funktioniert)

Gruß --Entlinkt (Diskussion) MediaWiki Diskussion:Common.css#c-Entlinkt-2016-04-18T16:23:00.000Z-Schnark-2016-04-18T07:57:00.000Z11Beantworten

Danke erstmal für die ausführlichere Darlegung, das sieht für mich alles überaus vorsichtig aber besonnen aus (ich glaube als WMF-Mitarbeiter würdest du es schwer haben :P). Rücksicht auf irgendwelche "Userhacks" ist wohl tatsächlich das Maximum der Gefühle (vllt auch einfach aus dem Grund dass man sich als etwas technisch Versierter aus der schlichten Erfahrung her keiner Illusion mehr ergibt).

@MB: also das MB was ich gefunden habe, ging einzig "um das Layout" an sich, nicht um die technische Umsetzung. ↔ User: Perhelion MediaWiki Diskussion:Common.css#c-Perhelion-2016-04-18T18:41:00.000Z-Entlinkt-2016-04-18T16:23:00.000Z11Beantworten

Das hauptseitenartig formatierte ausgezeichnete Portal:Segeln lebt noch. (Ein paar – sinnvolle – Formaledits sind übrigens eine ganz gute Strategie, um das herauszukriegen.)

Meiner Meinung nach sollten wir am Hauptseiten-CSS vorerst nichts ändern, bis eines der folgenden Ereignisse eintritt: (1) Optisches Redesign der Hauptseite aus der Community heraus oder (2) neue Softwaremöglichkeiten (phab:T483). Sonst würde die Frage aufgeworfen werden, warum wir hier etwas ändern bzw. andere etwas ändern sollen, und ob wir nichts Besseres zu tun haben.

Wenn sich äußere Umstände ändern, werden die „Mitbenutzer“ des Hauptseiten-CSS vielleicht sogar selbst eine Änderung wünschen, im Zweifelsfall ist eine Änderung dann leichter zu begründen. Momentan wäre die einzige Alternative sowieso Inline-CSS, was nicht nur Vorteile hat (phab:T37704).

Zum Hauptseiten-CSS ist das auch alles, was mir momentan einfällt … aber meiner Meinung nach dürfte zum Beispiel der Abschnitt „Verunstaltung von Thumbnails in Taxoboxen“ bald reif zum Entfernen sein. Da müsste man sich nur die Zeit nehmen, alles sorgfältig zu durchsuchen. Gruß --Entlinkt (Diskussion) MediaWiki Diskussion:Common.css#c-Entlinkt-2016-04-18T23:20:00.000Z-Perhelion-2016-04-18T18:41:00.000Z11Beantworten

Ich entferne jetzt die Regel „Verunstaltung von Thumbnails in Taxoboxen“, also folgendes:

table.taxobox div.thumb,
table.taxobox div.thumb * {
	background: #f9f9f9;
	border: none;
	float: none;
	margin: 0 auto;
	padding: 0;
}
table.taxobox div.magnify {
	display: none;
}
table.taxobox div.thumbcaption {
	text-align: center;
}

Begründung: Wikipedia-Archäologie.

• Dies bestand (im Wesentlichen) seit Mai 2005.
• Gründe, warum es eingefügt wurde, findet man noch immer auf der Seite Wikipedia Diskussion:Taxoboxen. Irgendwie scheint es wohl damals darum gegangen zu sein, dass man sich nicht einigen konnte, ob das Bild in einer Taxobox ein Thumbnail sein sollte oder nicht. Das Ergebnis war dann diese Regel, die bewirkt, dass Thumbnails in Taxoboxen nicht wie Thumbnails aussehen.
• Zur damaligen Zeit bestanden Taxoboxen aus Tabellen (basierend auf einer Formatvorlage) direkt im Artikel, dies wurde irgendwann 2007 auf Vorlagenprogrammierung umgestellt.
• In der programmierten Vorlage wurde die Bildeinbindung dann im Januar 2008 von den Biologen selbst umgestellt und ist seither kein Thumbnail mehr gewesen. Bereits dadurch ist der eigentliche Zweck dieser Regel entfallen.
• In den Jahren 2013 und 2014 habe ich einige Sekundärverwendungen bereinigt, insbesondere Bachkantaten und Viren.
• Im Juli 2014 habe ich die Regel als veraltet markiert, dagegen gab es nie Widerstand.
• Die letzte produktive Verwendung im Artikelnamensraum betraf den Artikel FINO-Forschungsplattformen und wurde soeben korrigiert.
• Suchanfrage für verbleibende Verwendungen: 127 Treffer in allen Namensräumen für den String "taxobox". Das ist genau genug, da die Klasse zu Zeiten ihrer aktiven Verwendung außerhalb von Vorlagen nicht mit anderen Klassen kombiniert wurde. Ein Großteil der Treffer enthält überhaupt keine Thumbnails oder betrifft uralte, längst obsolete Diskussionen oder die Bildeinbindung ist sowieso defekt. Nach Abzug solcher Treffer verbleiben 49 Benutzerseiten:

• Ich habe den Eindruck, dass das Entfernen der Regel bei keiner einzigen dieser Seiten ein ernsthaftes Problem darstellt, da es sich entweder um aufgelassene Entwürfe handelt, wo man die Taxobox sowieso auf die Vorlage umstellen müsste, oder der jeweilige Benutzer nicht mehr aktiv ist.
• Das Entfernen der Regel hat folgende Vorteile: Das allgemeine CSS wird übersichtlicher und es entfällt ein seit Ewigkeiten nicht mehr dokumentierter „Spezialeffekt“.
• Alte – zum größten Teil sehr alte – Artikelversionen sehen durch das Entfernen anders aus als vorher, sind aber immerhin noch lesbar.

--Entlinkt (Diskussion) MediaWiki Diskussion:Common.css#c-Entlinkt-2016-04-19T03:30:00.000Z-Entschlacken (opt)11Beantworten

Einige Benutzer finden die Schriftgröße für MathML rendering zu klein. Wikipedia:Umfragen/Technische W%C3%BCnsche 2015/Topw%C3%BCnsche#Schriftgr.C3.B6.C3.9Fe mathematischer Formeln vereinheitlichen .5BUmfrage 2015.5D11 Die Schriftgröße kann über den folgenden Parameter angepasst werden.

math {
font-size: 118%;
}

Ob nun 118 oder 116 Prozent besser passt hängt vom persönlichen Geschmack ab. Ich würde vorschlagen mit 118 zu beginnen und dann ggf weiter anzupassen.

PS: Bei antworten bitte das ping template verwenden, danke. --physikerwelt (Diskussion) MediaWiki Diskussion:Common.css#c-Physikerwelt-2016-02-22T15:52:00.000Z-Schriftgröße für MathML11Beantworten

enwiki benutzt nun 118% --physikerwelt (Diskussion) MediaWiki Diskussion:Common.css#c-Physikerwelt-2016-03-04T11:22:00.000Z-Physikerwelt-2016-02-22T15:52:00.000Z11Beantworten

@Umherirrender:, @Raymond:--physikerwelt (Diskussion) MediaWiki Diskussion:Common.css#c-Physikerwelt-2016-03-05T13:39:00.000Z-Physikerwelt-2016-02-22T15:52:00.000Z11Beantworten

Die Standardschriftgröße der häufig genutztesten Browser ist 16. Bei Bruchteilen von 16 kommen dann in der Regel gerade Zahlen heraus: 118.75% = 19/16 => in den meisten Fällen Schriftgröße 19 statt Standard 16.  Frohes Schaffen — Boshomi ⌨   MediaWiki Diskussion:Common.css#c-Boshomi-2016-04-18T17:21:00.000Z-Physikerwelt-2016-03-05T13:39:00.000Z11Beantworten

Die Standardschriftgröße des Wurzelelements ist 16px, falls der Benutzer dies nicht verstellt hat. Die MediaWiki-Skins ändern dies aber, und zwar auf ziemlich unterschiedliche Weise. Derzeit so, wie in der folgenden Tabelle dargestellt. Bitte hierbei auch folgendes beachten:

• Relative Angaben in em oder % beziehen sich immer auf das Elternelement im DOM und nicht etwa auf die Standardgröße des Wurzelelements.
• Ist für ein Element keine Schriftgröße definiert, wird die des Elternelements geerbt.
• In CSS gilt immer 72pt = 96px = 1in, also insbesondere 3pt = 4px.
• Die Bedeutung von x-small ist hier spezifiziert, faktisch gilt aber derzeit in allen mir bekannten Browsern x-small = 10px.
• Nicht-ganze Pixelwerte werden während des Vererbungsprozesses nicht gerundet, sondern erst ganz am Ende.

Speziell das, was in Monobook passiert, will man eigentlich gar nicht glauben, es ist aber wirklich so. Der von Benutzern eingegebene Wikitext befindet sich dann letztlich bei allen Skins in dem Element div#mw-content-text – mit je nach Skin sehr unterschiedlicher Schriftgröße. Gruß --Entlinkt (Diskussion) MediaWiki Diskussion:Common.css#c-Entlinkt-2016-04-18T17:39:00.000Z-Boshomi-2016-04-18T17:21:00.000Z11Beantworten

Bei Vector war div#bodyContent einst (April 2014) auch .8125em, denn das hatte ich in meinem common.js auf 0.875 ausgebessert. Schriftgröße 13 war mir zu klein. Frohes Schaffen — Boshomi ⌨   MediaWiki Diskussion:Common.css#c-Boshomi-2016-04-18T18:56:00.000Z-Entlinkt-2016-04-18T17:39:00.000Z11Beantworten

Also, um mal wieder zum eigentlichen Thema zurückzukommen:

Aufgrund der Diskussion in phab:T132607 und aufgrund von Edokters Aussage hier liegt die zu klein aussehende Schrift überhaupt nicht an der Schriftgröße, sondern an der vom Browser benutzten Schriftart, und Edokter hat den Wert 118% so zusammengehackt, dass es „in Firefox“ (ohne Angabe eines Betriebssystems) gut aussieht.

Es ist ein bekanntes Phänomen, dass Benutzer eine zu geringe Schriftgröße bemängeln, dies in Wirklichkeit aber an der Schriftart liegt (vergleiche dazu beispielsweise diese Diskussion). Dies kommt dadurch zustande, dass unterschiedliche Schriftarten bei nominell gleicher Größe aufgrund ihrer Gestaltung unterschiedlich groß aussehen.

Insofern muss man leider sagen, dass in der Umfrage über etwas abgestimmt wurde, was technisch evtl. überhaupt nicht möglich ist (Vereinheitlichung der wahrgenommenen Schriftgröße geht nicht, wenn der Browser verschiedene Schriftarten verwendet, die höchstwahrscheinlich auch noch vom Schriftarten-Angebot des Betriebssystems abhängen). Dies (Abstimmen für eine Sache, die gar nicht umsetzbar ist) ist ein grundsätzliches Problem bei Umfragen und Meinungsbildern über technische Themen.

Ob wir den Hack übernehmen sollten – ich weiß es nicht. Aber wenn wir ihn übernehmen, wäre ich jetzt aus dem Bauch heraus erstmal dafür, ihn 1:1 zu übernehmen und auch in Zukunft Änderungen nachzuziehen, da ich nicht sehe, dass jemand bei uns bereit wäre, das Ganze zu pflegen. (Inhaltlich habe ich das Ganze noch gar nicht geprüft.) --Entlinkt (Diskussion) MediaWiki Diskussion:Common.css#c-Entlinkt-2016-04-18T20:30:00.000Z-Boshomi-2016-04-18T18:56:00.000Z11Beantworten

Etwas weniger von der Schriftart abhängig wäre font-size-adjust. Aber irgendetwas in dieser Richtung in die common.css aufzunehmen, widerstrebt mir. Wenn das CSS nicht in die Extension aufgenommen wird, weil es eben keinen für alle Nutzer guten Wert gibt, dann sollte die Reaktion nicht sein, dass alle Wikis sich auf einen Wert einigen und den dann per Copy&Paste&Zufall irgendwie in globalen CSS-Dateien verteilen. --Schnark MediaWiki Diskussion:Common.css#c-Schnark-2016-04-19T09:07:00.000Z-Entlinkt-2016-04-18T20:30:00.000Z11Beantworten

Ich weise auch hier wieder auf die Datei modules/libpref/init/all.js des Mozilla-Quellcodes hin. Ich bin zwar weit davon entfernt, den Mozilla-Quellcode zu verstehen, vermute aber sehr stark, dass in dieser Datei konfiguriert ist, welche Schriftarten Firefox für MathML benutzt. Konkret meine ich die Einträge mit Inhalt x-math. Natürlich ist das plattformabhängig und deshalb durch die folgenden Präprozessor-Symbole eingeschränkt: XP_WIN, XP_MACOSX, MOZ_B2G und ANDROID.

Auf der Seite https://developer.mozilla.org/en-US/docs/Web/MathML/Authoring#Mathematical_fonts wird übrigens nahegelegt, gleich die Schriftart für das ganze Dokument passend zu den Formeln zu setzen. Gruß --Entlinkt (Diskussion) MediaWiki Diskussion:Common.css#c-Entlinkt-2016-04-19T23:37:00.000Z-Schnark-2016-04-19T09:07:00.000Z11Beantworten

Das ganze Thema ist nicht einfach. Wenn ihr eine gute Lösung findet wie man die CSS Datei ändern kann, würde ich mich über ein Pull request freuen. Hier nochmal der Link zum Beta Cluster http://en.wikipedia.beta.wmflabs.org/wiki/Math --physikerwelt (Diskussion) MediaWiki Diskussion:Common.css#c-Physikerwelt-2016-04-24T15:39:00.000Z-Physikerwelt-2016-02-22T15:52:00.000Z11Beantworten

Die Datei wäre wohl über gerrit: zu ändern, da sie im Wikimedia-GIT liegt. Der Umherirrende MediaWiki Diskussion:Common.css#c-Umherirrender-2016-05-07T13:27:00.000Z-Physikerwelt-2016-04-24T15:39:00.000Z11Beantworten

Hinweis: Unter phab:T132607#2233714 kann man mittlerweile nachlesen, warum in enwiki ausgerechnet der Wert 118% gewählt wurde, und zwar deshalb, weil die x-Höhe von Arial (angeblich) gerade 118 Prozent der x-Höhe von Times New Roman beträgt.

Mit anderen Worten: Der Wert ist genau auf bestimmte Schriftarten abgestimmt, die derzeit auf Windows-Systemen weit verbreitet sind, jedoch nicht auf anderen Systemen und möglicherweise auch nicht auf zukünftigen Windows-Systemen.

Falls eine Regel in der Art der hier vorgeschlagenen aufgenommen wird, sollte das Zustandekommen des gewählten Werts also unbedingt in einem Kommentar dokumentiert werden. Andernfalls wird folgendes passieren:

In den derzeit verbreiteten Windows-Systemen mag der gewählte Wert eine Angleichung der Schriftgrößen bewirken, aber mit den Jahren werden sich neue Betriebssysteme mit neuen Schriftarten etablieren, so dass der gewählte Wert keine Angleichung mehr bewirkt, sondern etwas anderes (zum Beispiel eine Formeldarstellung, die größer als der Haupttext ist). Wenn kein Kommentar vorhanden ist, gerät die ursprüngliche Intention der Regel in Vergessenheit und man beginnt zu glauben, ihr Zweck sei eine vergrößerte Formeldarstellung. Nachdem dieser Zustand ein paar Jahre bestanden hat, kann man die Regel nicht mehr ändern oder entfernen, weil irgendwer die vergrößerte Formeldarstellung unbedingt behalten will.

Gruß --Entlinkt (Diskussion) MediaWiki Diskussion:Common.css#c-Entlinkt-2016-06-19T08:32:00.000Z-Umherirrender-2016-05-07T13:27:00.000Z11Beantworten

Ich schlage die folgende Codeänderung vor:

.IPA a {
	text-decoration: none;
}

.IPA a:not(:hover):not(:focus) {
	text-decoration: none;
}

Zur Erklärung: Einfügt wurde die Regel 2008 mit dem Kommentar „Übernommen von commons. Soll bei Leuten mit "Auto-Link-Unterstreichen" helfen“, eine zugehörige Diskussion konnte ich nicht finden. Tatsächlich existierte die Regel in commons:MediaWiki:Common.css zum damaligen Zeitpunkt nicht (und existiert auch jetzt nicht), sehr wohl existiert sie aber zum Beispiel in en:MediaWiki:Common.css.

Der Zweck der Regel ist vermutlich folgender: Einerseits enthalten IPA-Ausspracheangaben oft diakritische Zeichen und sind daher schwer zu lesen, wenn sie unterstrichen sind. Andererseits gibt es eine – möglicherweise nicht jedem bekannte – Benutzereinstellung (auf Spezial:Einstellungen#mw-prefsection-rendering unten im Abschnitt „Erweiterte Optionen“), mit der man auswählen kann, ob Links unterstrichen sein sollen oder nicht. Diese Benutzereinstellung ist in ResourceLoaderUserCSSPrefsModule.php implementiert.

Standardmäßig sind Links in den Skins Wikipedia:Hauptseite?useskin=vector11, Wikipedia:Hauptseite?useskin=monobook11 und Wikipedia:Hauptseite?useskin=modern11 normalerweise nicht unterstrichen, werden aber beim Hovern (Überfahren mit der Maus) und in Vector und Monobook auch beim Fokussieren (z. B. mit den Tabulatortasten) unterstrichen. Nur in Wikipedia:Hauptseite?useskin=cologneblue11 sind Links standardmäßig immer unterstrichen. Die Regel soll wohl in erster Linie bei denjenigen Benutzern die Linkunterstreichung entfernen, die die entsprechende Benutzereinstellung oder den Cologneblue-Skin verwenden (zusammengefasst unter der Bezeichnung „Auto-Link-Unterstreichen“).

Leider schießt sie aber über das Ziel hinaus und entfernt bei allen Benutzern sowohl den Hover-Effekt als auch den Focus-Effekt (Beispiel: [ˈbaɪ̯ʃpiːl]). Ich habe dies unter Vorlage:IPA und Wikipedia:Lautschrift#Darstellung in Browsern dokumentiert, weil es seit 8 Jahren der Realität entspricht, finde es aber extrem störend, da ich den violetten Farbton besuchter Links nur schwer von schwarz unterscheiden kann und daher gewohnheitsmäßig den Hover-Effekt nutze, um Links zu erkennen, was bei IPA-Links durch unsere Regel verunmöglicht wird.

Deshalb, und weil der jetzige Zustand ursprünglich vermutlich auch gar nicht beabsichtigt war, sondern durch reine Unachtsamkeit entstanden ist, schlage ich vor, beide Effekte mit obengenannter Codeänderung wiederherzustellen. (Mich persönlich stört das Entfernen des Focus-Effekts weniger als das Entfernen des Hover-Effekts, aber wenn wir die Nebeneffekte der Regel schon beseitigen, können wir das gleich vollständig tun.) --Entlinkt (Diskussion) MediaWiki Diskussion:Common.css#c-Entlinkt-2016-04-22T02:26:00.000Z-Änderungsvorschlag: Hover- und Focus-Effekte bei IPA-Links wiederherstellen11Beantworten

Das :not() würde dazu führen, dass die Regel in IE <= 8 und FF <= 3 gar nicht mehr wirkt. Ich glaube nicht, dass die Zahl der Benutzer solch altertümlicher Browser mit Cologneblue bzw. "Links unterstreichen: immer" groß ist, aber wer weiß. Auch bin ich mir unsicher, ob die Unterstreichung wirklich auch beim Fokusieren zu sehen sein sollte. Beim Hovern kann man den Text ohnehin nicht wirklich lesen, da die Maus ihn teilweise verdeckt, sodass die Unterstreichung auch nicht weiter stört, fokusieren kann man den Link aber wie gesagt auch mit der Tastatur. Auch das wird sicher nicht von vielen gemacht, allerdings ist in meinen Augen die Nützlichkeit des Links auf die Liste der IPA-Zeichen jetzt auch nicht gerade so überwältigend groß, dass es unbedingt erforderlich ist, dass der Link immer deutlich als Link zu erkennen ist. Tendenziell bin ich also eher gegen eine Änderung. --Schnark MediaWiki Diskussion:Common.css#c-Schnark-2016-04-22T07:53:00.000Z-Entlinkt-2016-04-22T02:26:00.000Z11Beantworten

Nur mal so der Vollständigkeit halber:

• Die Klasse wird unter anderem auch in MediaWiki:Onlyifediting.js verwendet (also in der Werkzeugleiste unter dem Bearbeitungsfenster, zum Einfügen einzelner IPA-Zeichen).
• Die Klasse wird auch in IPA-fremden Vorlagen verwendet:
  • Vorlage:EUH-Sätze/Format
  • Vorlage:H-Sätze/Format
  • Vorlage:P-Sätze/Format
  • Vorlage:R-Sätze/Format
  • Vorlage:S-Sätze/Format
  • Vorlage:Türkische Provinzen Karte

Für IPA-fremde Vorlagen würde die Attraktivität der Klasse durch die vorgeschlagene Änderung stark sinken (ich vermute sogar, dass sie dort nur wegen des Abschaltens der Effekte verwendet wurde). Beim Focus-Effekt bin ich selbst unsicher (ich hatte das im Vorschlag zuerst nicht drin und habe es dann aufgenommen, damit klar ist, wie man diesen Effekt behandeln kann). Allerdings ist durch den Focus-Effekt derzeit bei fast allen Links folgendes möglich: Aktiviert man den Link mit der Maus und lässt ihn wieder los, bleibt der Link unterstrichen (bis man irgendwo anders klickt). So kann man bestimmte Links temporär „markieren“, auch das wird durch die Definition verhindert. Andererseits haben die meisten Browser schon eine eigene Hervorhebung für Links, die mit der Tastatur fokussiert wurden.

Falls :not() ein Problem ist, lässt sich die vorgeschlagene Änderung (sinngemäß) auch ohne dies formulieren, das würde ich aber eher nicht machen (da es den Code weiter aufblähen würde) und es in dem Fall lieber beim status quo belassen. --Entlinkt (Diskussion) MediaWiki Diskussion:Common.css#c-Entlinkt-2016-04-22T14:41:00.000Z-Schnark-2016-04-22T07:53:00.000Z11Beantworten

Ja, die Klasse IPA wurde in die Chemie-Vorlagen nur eingeführt, um die Unterstreichung zu entfernen: [2]

Dass bei nicht unterstrichenen Links die Unterstreichung auch beim Hovern und Fokusieren fehlt, ist übrigens konsistent mit MW: elements.css entfernt die Unterstreichung von Links für einige Sprachen mit arabischer Schrift, und zwar nach der Regel, die die Unterstreichung für Hover und Fokus setzt. Ich unterstelle einfach mal, dass es dort Absicht ist. --Schnark MediaWiki Diskussion:Common.css#c-Schnark-2016-04-23T07:11:00.000Z-Entlinkt-2016-04-22T14:41:00.000Z11Beantworten

Das halte ich in der Tat für ein stichhaltiges Argument.

• Beispiellink mit class="IPA" (durch lokale Regel formatiert)
• Beispiellink mit lang="ar" (durch Regel in mediawiki.skinning/elements.css formatiert)

Die Arabisch-Regel in mediawiki.skinning/elements.css kommt übrigens ebenfalls in der Werkzeugleiste unter dem Bearbeitungsfenster zur Geltung. Und ja, der Effekt dieser Regel ist beabsichtigt, sogar durch eine aktuelle Änderung aus dem Dezember 2015. Hätte ich auch sehen können.

Unter diesen Umständen denke ich, dass man die Definition unserer Regel belassen kann. --Entlinkt (Diskussion) MediaWiki Diskussion:Common.css#c-Entlinkt-2016-04-23T15:55:00.000Z-Schnark-2016-04-23T07:11:00.000Z11Beantworten

Wenn ich das nach kurzer Durchsicht ohne intensive Analyse des Gesamtprojekts richtig verstanden habe, dann gibt es zwei Fälle:

1. Wikilink mit Tooltip (Chemie usw.), bei denen die Unterstreichung die Tooltip-Hinweis-Bepunktelung stört.
2. Exotische Schriftsysteme, die bei Unterstreichung schlecht zu entziffern sind.

• Für den ersten Fall bräuchte es eine neu zu schaffende

  Vorlage:Wikilink mit Tooltip|1=Wikilink|2=Tooltip|3=Linktext

<span title="{{{2}}}">
   [[{{{1}}}|<span style="text-decoration:none">{{#if:{{{3|}}}|{{{3}}}|{{{1}}}}}</span>]]
</span>

mit 1,2 Pflicht und 3 optional – mal so freihändig ins Blaue gedacht.

• Für den zweiten Fall wären analog explizit auszurüsten:
  • Vorlage:IPA
  • Vorlage:Arabische Schrift
  • <div> in .js
• Sobald das geschehen ist, kann die Klassenregel raus.
  • Im Übrigen nennt man so eine Klasse nicht IPA, sondern no-decoration, himmelherrgottnochmal.

LG --PerfektesChaos MediaWiki Diskussion:Common.css#c-PerfektesChaos-2016-04-23T19:46:00.000Z-Änderungsvorschlag: Hover- und Focus-Effekte bei IPA-Links wiederherstellen11Beantworten

Vorsicht: text-decoration ist eine ganz, ganz fiese CSS-Eigenschaft, die im Gegensatz zu vielen anderen Eigenschaften der Textformatierung nicht vererbt, sondern propagiert wird. Es ist daher nicht möglich, allein mit text-decoration:none im Inline-CSS die Unterstreichung eines Elements zu entfernen, wenn ein Elternelement text-decoration:underline vorgibt. Um das per Inline-CSS zu erreichen, muss man schon zu härteren Mitteln wie display:inline-block greifen. Demonstration:

Vermutlich wurde die Klassendefinition vor vielen Jahren geschaffen, weil die Lösung mit display:inline-block seinerzeit nicht in allen Browsern existierte oder nicht bekannt war. Darüber hinaus hätte die Lösung mit display:inline-block auch Nebenwirkungen, unter anderem werden normale Zeilenumbrüche unmöglich. Darüber hinaus bin ich aber nach wie vor der Meinung, dass Vorlagen in aller Regel die gewöhnliche Linkformatierung nicht verändern sollten (und es auch nicht brauchen, da Links unter „gewöhnlichen“ Umständen sowieso fast nie unterstrichen sind). Im Zweifelsfall versucht man einfach, den Link woanders unterzubringen aus ausgerechnet an einer Stelle, wo eine Unterstreichung so schlimm wäre, dass sie mit allen Mitteln verhindert werden muss. Bei diesem Thread ging es mir um den Umgang mit Altbestand. Gruß --Entlinkt (Diskussion) MediaWiki Diskussion:Common.css#c-Entlinkt-2016-04-23T20:59:00.000Z-PerfektesChaos-2016-04-23T19:46:00.000Z11Beantworten

Dass der Weg über die Klassendefinition gewählt wurde, liegt mit hoher Wahrscheinlichkeit daran, dass außer dir niemand den display:inline-block-Trick kannte. Wieder was gelernt, danke dafür! --Schnark MediaWiki Diskussion:Common.css#c-Schnark-2016-04-25T08:41:00.000Z-Entlinkt-2016-04-23T20:59:00.000Z11Beantworten

WP-Archäologie:

• Das Verhalten bei inline-block (von dem mein Hinterkopf mal was gelesen hatte, das mir jetzt spontan aber nicht mehr präsent war) hatte sich erst in der Ära HTML5 rumgesprochen.
• Die IPA-Regel ist aber so uralt, dass damals noch IE6 Standardbrowser der Wikipedianer war und viele noch grausigere Dingsdas umherschwirrten, die solche feinziselierten Unterscheidungen noch nicht machten. Ich hatte sie auch noch nicht antizipiert und nur mein Netscape-Modell parat.

Chemie-Design:

• Das ist so leserunfreundlich wie nur was.
• Man muss schon eine Nase für die Gestaltungsideen von Wikipedianern haben sowie einen Browser mit Statuszeile, um dahinterzukommen, dass das auch anklickbare Wikilinks sind.

Gleichwohl, nach Ersatz durch eine Vorlage für Vorlagen wie oben skizziert und diese mit entsprechendem Warnvermerk versehen kann die Klasse wie dargestellt überall rausgenommen werden. Ein JS-Gadget kann sich alternativ ein Gadget-CSS dazuholen, falls das nötig wäre. Ich verwende seit fünf Jahren editToolStrIns und hatte noch nie bewusst wahrgenommen, dass beim hover was unterstrichen sei; aber wer dauerhaft alle Links unterstreicht, mag beim ≥ ein Unterscheidungsproblem bekommen.

LG --PerfektesChaos MediaWiki Diskussion:Common.css#c-PerfektesChaos-2016-04-25T14:39:00.000Z-Schnark-2016-04-25T08:41:00.000Z11Beantworten

Seit einiger Zeit hat gibt es in der Linken Spalte den Abschnitt "In anderen Projekten", falls ein entsprechender Eintrag auf Wikidata existiert:

Eigentlich sollte es möglich sein vor dem jeweiligen Projekt die das entsprechen Symbol einzufügen, wie etwa in frwiki der Fall ist. Siehe z.B. Fische, fr:Poisson  Frohes Schaffen — Boshomi ⌨   MediaWiki Diskussion:Common.css#c-Boshomi-2016-05-21T16:14:00.000Z-Symbole für "In anderen Projekten"11Beantworten

Als offizielles Softwarefeature ist der Kasten „In anderen Projekten“ in der Seitenleiste relativ neu (Februar 2016). Allerdings haben wir schon seit Februar 2010 (also 6 Jahre länger) die Vorlage:InterProjekt, die zusammen mit etwas JavaScript in MediaWiki:Common.js einen Kasten „Schwesterprojekte“ für exakt denselben Zweck erzeugt. Der ältere, durch die Vorlage erzeugte Kasten war und ist beispielsweise auf der Seite Wikipedia:Fragen zur Wikipedia prominent sichtbar und hatte nie Icons. Daher stellt sich zunächst einmal die Frage, warum der neuere Kasten jetzt Icons haben soll. (Unabhängig von der Icon-Frage sollte natürlich das Problem der doppelten Kästen irgendwie gelöst werden, das ist aber eine andere Baustelle.)

Die Einträge in der Seitenleiste befinden sich weit außerhalb des skinunabhängigen Textfeldbereichs; vgl. hierzu den Hinweiskasten oben. Daher sind die Icons in der französischen Wikipedia über fr:MediaWiki:Vector.css realisiert worden; andere Skins wurden nicht berücksichtigt. So ist das Ganze zunächst einmal wenigstens nicht falsch; wenn wir das aber auch machen, dann sollten wir schon wissen, für welche Skins wir es machen und warum wir ausgerechnet diese Auswahl treffen.

Ich persönlich bin sehr zufrieden mit dem – bis auf die Nachfolger der „LinkFA/LinkGA“-Icons – einheitlichen und Blickfang-freien Erscheinungsbild der Seitenleiste. Für die Einführung der „LinkFA/LinkGA“-Icons wurden übrigens seinerzeit Meinungbilder für notwendig gehalten: LinkFA (2006), LinkGA (2009).

Auch an der konkreten Umsetzung in fr:MediaWiki:Vector.css gefällt mir etwas nicht besonders, nämlich die Verwendung von position:relative. Das kann zu subtilen Fehlern in der z-Richtung führen und lässt sich wohl mit Recht als „Hack“ bezeichnen, da es wohl noch nicht einmal notwendig ist, um das optische Ergebnis zu erreichen. Am „Richtigsten“ erscheint natürlich die Verwendung von list-style-image; da müsste man ausprobieren, ob das optisch annehmbar funktioniert (wenn man die Icons denn überhaupt haben möchte). Im Zweifelsfall würde ein negativer margin-left-Wert wohl zu demselben optischen Ergebnis führen wie position:relative, aber mit weniger Potenzial für Nebenwirkungen, und wäre insofern besser (wenn man die Icons denn überhaupt haben möchte).

Gruß --Entlinkt (Diskussion) MediaWiki Diskussion:Common.css#c-Entlinkt-2016-05-21T17:29:00.000Z-Boshomi-2016-05-21T16:14:00.000Z11Beantworten

Nachtrag: Die Umsetzung mit position:relative in fr:MediaWiki:Vector.css ist eindeutig falsch, weil dies dazu führt, dass sowohl die linke wie auch die rechte Kante jedes betroffenen <li>-Elements um 18px nach links rutschen (d. h. der Platz für Text in jedem <li> schrumpft auf der rechten Seite um 18px); natürlich möchte man aber erreichen, dass jedes <li> auf der linken Seite um 18px für das Icon wächst und dass der Platz für Text unverändert bleibt. --Entlinkt (Diskussion) MediaWiki Diskussion:Common.css#c-Entlinkt-2016-05-21T17:56:00.000Z-Entlinkt-2016-05-21T17:29:00.000Z11Beantworten

Wir haben diese Icons schon bei den Textbausteine für Schwesterprojekte, eine Umsetzung wäre damit konsequent. Die Vorlage {{InterProjekt}} ist meiner Meinung wäre beinahe Löschkandidat, hat nur noch wegen der Verwendungen im BNR eine Daseinsberechtigung. Frohes Schaffen — Boshomi ⌨   MediaWiki Diskussion:Common.css#c-Boshomi-2016-05-21T19:14:00.000Z-Entlinkt-2016-05-21T17:56:00.000Z11Beantworten

Natürlich ist die Seitenleiste etwas völlig anderes als der Abschnitt „Weblinks“ im Textfeldbereich. Man merkt dies schon daran, dass die Benutzergruppen, die diese Dinge jeweils bearbeiten dürfen, verschieden sind.

Das Argument der Konsequenz hätte auch schon während der letzten 6 Jahre gegolten, wenn es denn gilt. Mit dem Argument der Konsequenz kann man aber genauso gut auch begründen, dass die Icons nicht aufgenommen werden sollten, da die meisten anderen Einträge der Seitenleiste auch keine Icons haben.

Meine Meinung: In der Entwicklung der MediaWiki-Software wird nicht nur beiläufig, sondern aktiv daran gearbeitet, die Benutzeroberfläche möglichst einfach und „sauber“ zu halten, möglichst wenige verschiedene Icons zu haben, und auch möglichst wenige Farben. Dies gilt ganz besonders für den Vector-Skin und ist IMHO eine gute und unterstützenswerte Sache. Nun sind wir zwar nicht die MediaWiki-Entwickler und könnten natürlich jedes Designziel konterkarieren, sollten dies aber meiner Meinung nach nicht tun.

Soweit ich das sehe, gibt es im Vector-Skin hauptsächlich die folgenden Bilder in Navigationsbereichen:

• Wikipedia-Logo oben links (grau, wie der Hintergrund der Seitenleiste)
• Watchstar-Icon oben rechts (hellblau, wie der Hintergrund der Tab-Leiste)
• Lupe im Suchfeld oben rechts (grau, wie das Suchfeld)
• Stilisierter Kopf und Echo-Icons oben (grau, wie der Hintergrund der Kopfleiste)
• Stilisiertes Spracheinstellungs-Rädchen links (grau, wie der Hintergrund der Seitenleiste)
• WMF- und MediaWiki-Icons in der Fußleiste (bunt)

Es sollte direkt auffallen, dass bunte Bilder nur ganz weit unten auftreten, wo sie sowieso kaum auffallen. Alle anderen Icons sind farblich an ihre Umgebung angepasst. Sicherlich ist dies kein Zufall.

Hinzu kommen noch die gelben und grauen Sternchen bei den Interwiki-Links zur Hervorhebung ausgezeichneter Artikel in anderen Sprachen. Diese passen m. E. bereits nicht wirklich ins Konzept, sind aber wohl noch akzeptabel, weil sie klein und einfarbig sind und nur in zwei verschiedenen Farben auftreten. Außerdem handelt es sich bei diesen um einen ehemals in fast allen Wikis verbreiteten Hack, der in die Software aufgenommen wurde, was immer noch besser ist als lokale Hacks in hunderten von Wikis.

Der Vorschlag in diesem Abschnitt lautet nun ganz konkret, die bisher von bunten Bildern völlig freie Seitenleiste so aussehen zu lassen wie :fr:#p-wikibase-otherprojects. Dadurch würde ein IMHO völlig willkürlich gewählter (und für mich persönlich komplett belangloser) Bereich der Seitenleiste in einer Art und Weise mit bunten Bildern ausgestattet, die dem bisherigen Design völlig zuwiderläuft und diesen Bereich über jedes vernünftige Maß hinaus betont.

Aus diesen Gründen spreche ich mich deutlich gegen diesen Vorschlag aus, und zwar für alle Skins, ganz besonders aber für den Vector-Skin, da die beeinträchtigenden Wirkungen des Vorschlags dort am größten wären. Gruß --Entlinkt (Diskussion) MediaWiki Diskussion:Common.css#c-Entlinkt-2016-05-21T20:47:00.000Z-Boshomi-2016-05-21T19:14:00.000Z11Beantworten

Alles gute Argumente. Mir persönlich würde es trotzdem gut gefallen, wenn wir Icons wie im frwiki-Beispiel auch bei uns hätten. Manche Menschen orientieren sich eben schneller an Symbolen als an Text. Es gibt übrigens ein oranges Icon in der Werkzeugleiste: Der Link zum Atom-Feed. — Raymond ^Disk. MediaWiki Diskussion:Common.css#c-Raymond-2016-05-21T21:19:00.000Z-Entlinkt-2016-05-21T20:47:00.000Z11Beantworten

Das Atom-Icon ist um einiges kleiner (12x12px) als die Projekt-Icons in frwiki (unterschiedliche Breiten von 14px bis 16px und ebenfalls unterschiedliche Höhen); die LinkFA/LinkGA-Nachfolgeicons sind ebenfalls kleiner (sogar nur 9px breit, also gerade so groß wie ein übliches Aufzählungszeichen). Zudem tritt das Atom-Icon nur einzeln auf, die LinkFA/LinkGA-Icons könnten theoretisch in Scharen auftreten, tun dies aber in der Praxis selten, während die Projekt-Icons schon auf der Hauptseite in Scharen auftreten.

Im Vector-Skin ist eine Textzeile in der Seitenleiste unter normalen Bedingungen (Browserschriftgröße 16px) genau 19px hoch, die Projekt-Icons in frwiki erreichen diese Höhe fast, berühren sich dadurch fast und ergeben dadurch eine Zusammenballung. Merklich kleiner kann man sie aber auch nicht machen, da sie dann nicht mehr erkennbar wären. Die Umsetzung in frwiki fällt zumindest nach meinen Maßstäben auf jeden Fall als „nicht wirklich professionell“ auf, und meiner Meinung nach ist für dieses Anliegen auch keine wirklich professionell aussehende Lösung möglich.

Orientierungstechnisch sind die Projekt-Links übrigens (genau wie die Sprachlinks) alphabetisch sortiert, mit der Ausnahme von Wikispecies. Was das soll, ist nicht klar (→ Bug?), aber an sich ist Wikispecies laut Wikipedia:Textbausteine/Schwesterprojekte bei uns sowieso nicht erwünscht. --Entlinkt (Diskussion) MediaWiki Diskussion:Common.css#c-Entlinkt-2016-05-22T00:50:00.000Z-Raymond-2016-05-21T21:19:00.000Z11Beantworten

Ich fände das sinnvoll und schliesse mich Raymond und Boshomi an. Ich hatte neulich auf Wikipedia_Diskussion:Kurier/Archiv/2016/02#Rubrik "Andere Projekte" ähnliches vorgeschlagen, nämlich eine graue Version, so in etwa:

Andere Projekte

Commons

Wikidata

Wikiquote

Wiktionary

Die frwiki setzt kleine icons neben die commons-links, die das besser auffindbar machen (graue icons würden mir allerdings schon reichen) und ruwiki klebt commons- und wikidata-link direkt untereinander. Beides zusammen hätte ich gerne in dewiki! --Atlasowa (Diskussion) MediaWiki Diskussion:Common.css#c-Atlasowa-2016-05-21T21:47:00.000Z-Symbole für "In anderen Projekten"11Beantworten

Eine „psychologisierende“ These:

Ich sehe in unserer Community das grundsätzliche Problem, dass „man“ (?) mit fast jeder (sichtbaren) Softwareänderung oder -neuerung unzufrieden ist, sie nicht so akzeptieren will, wie sie ist und stattdessen relativ willkürlich daran herumändern will.

Beispiel 1: Seit frühestens irgendwann Ende 2012, vielleicht auch erst Anfang 2013 kann man sich auf der Beobachtungsliste Wikidata-Edits anzeigen lassen. Allerdings wurde im Juni 2013 festgestellt, dass die Farbe nicht gefällt und unbedingt für alle Benutzer geändert werden muss.

Beispiel 2: Seit August 2013 zeigt MediaWiki beim Bearbeiten von Seiten unterhalb des Textfelds die Parser-Profiling-Daten an. Noch im gleichen Monat wurde festgestellt, dass dies nicht gefällt und für alle Benutzer ausgeblendet werden soll. Ich habe mich damals – das Verhaltensmuster noch nicht kennend – tatsächlich dazu hinreißen lassen, diese Ausblendung vorzunehmen. Daher kennt in unserem Wiki kaum jemand dieses Feature.

Beispiel 3: Seit Februar 2016 gibt es die Schwesterprojekt-Links als Softwarefeature. Drei Monate später gefällt es nicht und soll für alle Benutzer mit Icons versehen werden.

Speziell zu den Schwesterprojekten fällt mir noch folgendes ein: Wir haben oben auf der Seite Spezial:Letzte Änderungen einen Kasten, der unter anderem auch Schwesterprojekt-Links enthält. Dieser Kasten sah heute vor 10 Jahren so aus und sieht jetzt so aus. Soll heißen: Das Aussehen hat sich in 10 Jahren nicht geändert, die Schwesterprojekt-Links haben keine Icons und ich habe auch nirgends vernommen, dass jemand dort Icons wünscht. Warum? Weil jeder den Kasten ohne Icons kennt.

Jetzt gibt es zwei Möglichkeiten: Entweder, jemand baut die vorgeschlagenen Icons ein. Das wird ziemlich sicher einigen Leuten nicht gefallen, dann gibt es Diskussionen, aber in ein paar Jahren kennt jeder das neue Feature mit Icons und nimmt es hin, dass die Icons da sind. Oder aber, es baut niemand die vorgeschlagenen Icons ein. Auch das würde einigen Leuten nicht gefallen, aber in ein paar Jahren kennt jeder das neue Feature ohne Icons und nimmt es so hin. Und die nächste sichtbare Softwareänderung kommt bestimt, da geht das Ganze wieder von vorne los.

Ach, noch etwas: Ich habe mir mal die Hauptseiten aller 51 Wikipedien angesehen, die von unserer Hauptseite verlinkt sind. Nur auf 4 davon habe ich Icons wie die vorgeschlagenen gefunden: da:, fr:, frp:, sv:. Wenn man jetzt noch die Seiten da:MediaWiki:Vector.css, fr:MediaWiki:Vector.css und frp:MediaWiki:Vector.css miteinander vergleicht, kann man feststellen, dass alle drei denselben Code mit denselben Fehlern verwenden. Mit anderen Worten: da: und frp: haben von fr: kopiert, also wollten sie die Icons wohl haben, aber so wichtig, den Code mal auf Sinnhaftigkeit zu prüfen, war es ihnen doch nicht.

Interessant ist die Lösung der schwedischen Wikipedia. Dort ist das Ganze nämlich ein Gadget mit einem CSS-Teil und einem JavaScript-Teil. Die haben sich anscheinend tatsächlich Gedanken darüber gemacht. Bei den anderen deutet meiner Meinung nach ehrlich gesagt nicht so viel darauf hin. Gruß --Entlinkt (Diskussion) MediaWiki Diskussion:Common.css#c-Entlinkt-2016-05-22T05:23:00.000Z-Atlasowa-2016-05-21T21:47:00.000Z11Beantworten

OT zu Beispiel 2: Kennen tu ich's, vermisst habe ich es auch schon, und letzlich als HTML-Kommentar in der feritgen Seite gefunden, zusammen mit dem "Transclusion expansion time report". Da ich jetzt weiß, warum ich ihn vermisste, werde ich das vorraussichtlich in meiner global.css wieder einblenden, auch wenn ich den andere Report dadurch vermutlich vergessen werde. Ich würde mich aber freuen, wenn das auf allen Wikis gleich werden könnte; Sich also nur die Nutzer, die vom Standard abweichen wollen, anpassen müssen, statt alle Benutzer: Die, die es anders wollen, um es auch in anderen Wikis anders zu haben, und die, die es "normal" haben wollen, um es auch hier zu haben… Zum eigentlichen Thema stimme ich dir zu. Auch wenn ich mir vorstellen kann, dass die Icons in anderen Schriftsystemen hilfreich sein könnten – Aber so gering, dass mir selbst bei einer guten Umsetzung wahrscheinlich wegen der Einheitlichkeit keine Icons lieber wären. --nenntmichruhigip (Diskussion) MediaWiki Diskussion:Common.css#c-Nenntmichruhigip-2016-05-22T11:16:00.000Z-Entlinkt-2016-05-22T05:23:00.000Z11Beantworten

Wenn man mal über den Tellerrand hierzuwiki schauen möchte:

• T103102 (Story) Take in other projects sidebar out of beta features
• T66315 Move "Data item" link outside of sidebar toolbox: "the link feels out of place after "Page information" and before "Cite this page" (completely different audiences). (...) A possible fix is to add the link to the "in other projects" sidebar..."

Gibt es auch einen Phabricator-task für die "other projects" logos? Das könnte dann ordentliches Layout für alle svwiki, dawiki, frwiki usw. schaffen, die icons/logos haben wollen. --Atlasowa (Diskussion) MediaWiki Diskussion:Common.css#c-Atlasowa-2016-05-22T21:45:00.000Z-Symbole für "In anderen Projekten"11Beantworten

Ein nicht unbeträchtlicher Teil der Links auf andere Projekte in der Seitenleiste sind Commons-Kategorien, die genau die Artikel enthaltenen Bilder zeigen. Willkürliches Beispiel, das ich durch ein paar Klicks auf "Zufälliger Artikel" gefunden habe: Victor Razafimahatratra So etwas durch ein Icon hervorzuheben, ist einfach nur – tut mir Leid – Leserverarschung.

Unabhängig jedoch von der Frage, ob man die Icons will oder nicht – eine Softwarefunktion, die es in allen Wikis gibt, sollte auch in allen Wikis gleich aussehen, Alleingänge einzelner Wikis, noch dazu bei Funktionen, die der Vernetzung verschiedener Wikis dienen dienen, sind nicht zielführend. --Schnark MediaWiki Diskussion:Common.css#c-Schnark-2016-05-23T07:35:00.000Z-Atlasowa-2016-05-22T21:45:00.000Z11Beantworten

Inwieweit sich die Schweden Gedanken gemacht haben, ist etwas fraglich, ich glaube, dass der Code anfällig für XSS ist. Müsste ich jetzt noch ein bisschen rumprobieren und dann dort einen finden, der sich dafür verantwortlich fühlt. --Schnark MediaWiki Diskussion:Common.css#c-Schnark-2016-05-23T10:11:00.000Z-Atlasowa-2016-05-22T21:45:00.000Z11Beantworten

• Der Vorschlag die Formatierung über alle Projekt hinweg zentral durch die Mediawiki-Software vorzunehmen scheint mir vernünftiger, als Einzelanpassungen für jedes einzelne Wiki und jeden einzelnen Skin extra.
• Zu commons: da kommt auch was vernünftiges dabei heraus, siehe etwa SMS_Moltke_(1910), das war bei mir der erste zufällige Artikel mit Commons in der linken Spalte. Ob da wirklich was vernünftiges herauskommt, hängt von den Inhalten ab, die die Benutzer eingeben. Bei commons könnte es vernünftig sein, das erst dann anzuzeigen, wenn mindestens 2 Dateien vorhanden sind. Aber auch das sollte möglichst zentral geregelt werden. Frohes Schaffen — Boshomi ⌨   MediaWiki Diskussion:Common.css#c-Boshomi-2016-05-24T13:27:00.000Z-Schnark-2016-05-23T10:11:00.000Z11Beantworten

@Elya, Raymond: Diese Farbgebung ist hoffentlich nicht ernst gemeint, oder? Abgesehen davon, dass ich dieses Türkis als hässlich empfinde (aber persönliches Empfinden ist natürlich erst einmal kein Maßstab für oder gegen eine Änderung), ist der Kontrast zwischen Hintergrund und Text viel zu schwach. http://webaim.org/resources/contrastchecker/ kommt auf 2,09:1, während nach WCAG als Minimum 4,5:1 gefordert wird und in MW die Einhaltung des strengeren Wertes 7:1 angestrebt wird.

Das ist keine Hervorhebung, sondern versteckt den Hinweis, dass es sich um Ergebnisse aus einer anderen Sprachversion handelt, ziemlich effektiv vor allen Benutzern mit Sehschwächen. Und es wäre schön, wenn solche Änderungen an zentralen Stylesheets erst diskutiert werden, und nicht nach „mir gefällt diese Farbe, also mache ich das so“ ohne Berücksichtigung wichtiger Standards eingebracht würden. --Schnark MediaWiki Diskussion:Common.css#c-Schnark-2016-07-29T07:27:00.000Z-Hervorhebung von Suchergebnissen in anderen Sprachen11Beantworten

Hallo @Schnark: Danke für dein konstruktives Feedback. Welche Farben schlägst du konkret vor, um eine deutliche Abgrenzung zu den lokalen Suchergebnissen zu erreichen? Ich selber nutze oft knallige Farben, die aber nicht auf Gegenliebe stoßen. Und nun ist es wohl zu dezent. Im übrigen hielt ich ein zügiges Handeln nach Einführung der Funktion für notwendig, da die Standardausgabe gar kein Styling enthält und der kurz, zusätzliche Satz einfach übersehen wurde. An dem noch nicht perfekten Styling können wir nun weiterarbeiten.

Interessant übrigens die heute Abend auf der Kurier-Diskussion vorgestellte Suchergebnisliste sowohl mit einem lokaken als auch einem englischsprachigen Ergebnis. — Raymond ^Disk. MediaWiki Diskussion:Common.css#c-Raymond-2016-07-29T18:27:00.000Z-Schnark-2016-07-29T07:27:00.000Z11Beantworten

Andererseits wurde das irgendwo auch schon als "knallig-bunt" (oder so ähnlich) beschrieben. Ich schlage vor, die Anzeige der Suchergebnisse selbst anders zu gestalten (Selektor z.B. .mw-search-interwiki-header + .mw-search-results; vllt ein Rahmen?), das sollte allerdings bei allen Projekten gleich sein, also schon von MediaWiki so kommen -> Phab-Task. --nenntmichruhigip (Diskussion) MediaWiki Diskussion:Common.css#c-Nenntmichruhigip-2016-07-29T23:17:00.000Z-Raymond-2016-07-29T18:27:00.000Z11Beantworten

„Und so bunt!“ war wohl der Wortlaut von @Manorainjan. Btw @Leyo: Bei Special:Search/Dicodin werden keine anderssprachigen Suchergebnisse angezeigt, weil es mit Dioxin einen ähnlich geschriebenen deutschsprachigen Artikel gibt… --nenntmichruhigip (Diskussion) MediaWiki Diskussion:Common.css#c-Nenntmichruhigip-2016-07-29T23:24:00.000Z-Nenntmichruhigip-2016-07-29T23:17:00.000Z11Beantworten

Tja, wenn ich die Suche ausführe, kommt ein Ergebnis in Türkis ;-) Wobei ich mal vorsichtig nachfrage, ob es "Suchergebnisse von der englischen Wikipedia." heißen sollte? Oder nur Ergebnisse? Oder aus der en:? Oder 'englischsprachigen' Wikipedia? --Manorainjan (Diskussion) MediaWiki Diskussion:Common.css#c-Manorainjan-2016-07-30T00:20:00.000Z-Nenntmichruhigip-2016-07-29T23:24:00.000Z11 PS: Dicodin ist ein 1A-Testcase ;-)Beantworten

Wenn man den auszugsweise angezeigten Text in den Suchergebnissen liest, dann sollte man auch ohne irgendeine Hervorhebung feststellen können, dass es sich nicht um deutsche Artikel handelt. Und wenn man das nicht tut, bevor man eine Weiterleitung anlegt, dann muss man mit fehlerhaften Weiterleitungen rechnen, unabhängig davon, ob die Ergebnisse aus einer anderen Sprache stammen oder nicht. Das ist daher in meinen Augen kein Argument dafür, irgendeine Hervorhebung einzubauen.

Hintergrundfarben zur Hervorhebung werden hier nur äußerst selten eingesetzt. Die einzigen Hinweise mit buntem Hintergrund, die mir einfallen, sind der Hinweis, wenn man unangemeldet eine Seite bearbeitet (wobei die farbliche Hervorhebung nur im Quelltext-Editor vorhanden und sehr schwach ist) und der Hinweis auf neue Nachrichten auf der eigenen Diskussionsseite. Der Hinweis, dass die Suchergebnisse aus einer anderen Sprache stammen, ist nun wirklich nicht so wichtig, dass eine ungewöhnlich starke Hervorhebung gerechtfertigt ist. Mein Farbvorschlag lautet also: Schwarz auf Weiß, so wie fast alle anderen Hinweise auch.

Wenn wirklich eine Hervorhebung notwendig sein sollte, dann käme ein border-top: 3px solid #c00000; in Frage, das wäre im Aussehen konsistent mit lokalen Dateibeschreibungsseiten, wo durch eine Linie dieser Farbe lokale und Commons-Inhalte abgetrennt werden.

Bei Funktionen, die einer stärkeren Vernetzung der einzelnen Wikis dienen, halte ich Konsistenz zwischen den einzelnen Sprachen für sehr wichtig. Man kann eine Hervorhebung lokal kurz testen, aber eine dauerhafte Umsetzung muss über ein Phab-Ticket erfolgen, wie Nenntmichruhigip schon geschrieben hat.

Die Qualität des eingefügten CSS-Codes ist sichtbar schlechter als der Rest des Stylesheets: Es fehlt ein dokumentierender Kommentar, Leerzeichen sind uneinheitlich gesetzt, es sind unnötige Eigenschaften (border: none) enthalten, es gibt vermeidbare !important. --Schnark MediaWiki Diskussion:Common.css#c-Schnark-2016-07-30T06:47:00.000Z-Manorainjan-2016-07-30T00:20:00.000Z11Beantworten

Da ich in meinem früheren Leben auch 'n Bisschen programmiert habe, und mich erinnere, dass die WP diverse Skins anbietet, scheint es mir erforderlich, mit den hoffentlich irgendwie standardisierten Auszeichnungen für diese Skins zu arbeiten, damit es in jedem Skin passend aussieht. --Manorainjan (Diskussion) MediaWiki Diskussion:Common.css#c-Manorainjan-2016-07-30T09:58:00.000Z-Nenntmichruhigip-2016-07-29T23:24:00.000Z11Beantworten

Ähm, was wird das jetzt hier? Warten wir jetzt einfach so lange ab, bis jeder Versuch diese „Hervorhebung“ zu revertieren oder zumindest vernünftiger zu gestalten, mit „War schon immer so, bleibt also so“ abgelehnt werden kann? Soweit ich sehen kann, hat noch immer niemand eine Phabricator-Task mit der Bitte um Hervorhebung des Hinweises in allen Wikis angelegt (und das sollte jemand machen, der auf Nachfragen, warum eine solche Hervorhebung notwendig ist, auch eine sinnvolle Antwort nennen kann). Was an sich ja auch nicht verwundert, denn Raymonds Variante verwendet ja kräftige Warnfarben, während Elya genau gegenteilig gestaltete, sodass offenbar noch nicht einmal unter den Befürwortern einer Hervorhebung Einigkeit darüber besteht, was eigentlich ihr Zweck sein soll. --Schnark MediaWiki Diskussion:Common.css#c-Schnark-2016-08-01T06:37:00.000Z-Schnark-2016-07-29T07:27:00.000Z11Beantworten

Kein Aussitzen, sondern ich hatte mir noch mehr Meinungen erhofft übers Wochenende. Aber eben auch in der Wikipedia gilt: Sommer, Sonne, Ferienzeit :-) Und du hast Recht, den Task hätte ich schon vor dem Wochenende schreiben können, jetzt nachgeholt mit Phab:T141768. Und ich habe deinen Vorschlag mit der roten Linie aufgegriffen. Ein guter Kompromiss, damit kann ich leben :-) — Raymond ^Disk. MediaWiki Diskussion:Common.css#c-Raymond-2016-08-01T15:00:00.000Z-Schnark-2016-08-01T06:37:00.000Z11Beantworten

Bei der endgültigen Implementierung darf dann aber ruhig noch etwas Innenabstand nach oben dazu, bisher klebt der Text für meine Augen unangenehm nah an der roten Linie. Ist aber nicht so wichtig. -- hgzh MediaWiki Diskussion:Common.css#c-Hgzh-2016-08-01T15:08:00.000Z-Raymond-2016-08-01T15:00:00.000Z11Beantworten

Einige in MW verwendeten Farben wurden leicht geändert um sie an die Farbpalette anzupassen. Da sich einige der in Common.css verwendeten Farben explizit auf diese Farben beziehen (prettytable, "wie Inhaltsverzeichnis"), sollten sie übernommen werden. Ich schlage folgende Änderungen vor (alles Grautöne):

Die anderen Farben unterscheiden sich recht stark von denen der Farbpalette, sodass ich dort keine Änderung vornehmen würde. --Schnark MediaWiki Diskussion:Common.css#c-Schnark-2016-12-09T09:56:00.000Z-Farben11Beantworten

Ein paar Vorschläge wurden jetzt schon per Adminanfrage umgesetzt (betrifft f9f9f9, aaa und e0e0e0). -- hgzh MediaWiki Diskussion:Common.css#c-Hgzh-2016-12-09T10:10:00.000Z-Schnark-2016-12-09T09:56:00.000Z11Beantworten

@MBq: Willst du auch die anderen Farben erledigen? Zumal du ja gerade die hintergrundfarbe1 durch ein fehlendes f vorne kaputt (=weiß) gemacht hast? --Schnark MediaWiki Diskussion:Common.css#c-Schnark-2016-12-09T10:32:00.000Z-Hgzh-2016-12-09T10:10:00.000Z11Beantworten

Danke fürs Aufpassen. Ja, die anderen kann ich auch gleich ändern. -- MBq ^Disk MediaWiki Diskussion:Common.css#c-MBq-2016-12-09T11:00:00.000Z-Schnark-2016-12-09T10:32:00.000Z11Beantworten

Und vielleicht gleich noch MediaWiki:Mobile.css hinterher. Dort fehlen auch die kompletten Definitionen für prettytable und Navigationsleisten, weshalb diese in der mobilen Ansicht nahezu unformatiert daherkommen: prettytable und Navigationsleiste am Seitenende. -- hgzh MediaWiki Diskussion:Common.css#c-Hgzh-2016-12-09T11:08:00.000Z-MBq-2016-12-09T11:00:00.000Z11Beantworten

Arbeit zieht Arbeit nach sich ;-) Schau bitte mal, ob [3] so stimmt und ob ich nichts vergessen habe. Die Ergänzung im mobilen css müsstest Du mir genauer vorgeben. -- MBq ^Disk MediaWiki Diskussion:Common.css#c-MBq-2016-12-09T11:13:00.000Z-Hgzh-2016-12-09T11:08:00.000Z11Beantworten

Kopiere aus Common.css ab ".rahmenfarbe1" bis zum Kommentar über ".IPA a" (nicht einschließlich) und ersetze den entsprechenden Block in MediaWiki:Mobile.css damit, also dort ebenfalls ab ".rahmenfarbe1" bis zum Kommentar über ".metadata" (ebenfalls nicht einschließlich). --Schnark MediaWiki Diskussion:Common.css#c-Schnark-2016-12-10T09:00:00.000Z-MBq-2016-12-09T11:13:00.000Z11Beantworten

gemacht. -- MBq ^Disk MediaWiki Diskussion:Common.css#c-MBq-2016-12-10T14:34:00.000Z-Schnark-2016-12-10T09:00:00.000Z11Beantworten

Nur mal so, weil’s mir zufälligerweise aufgefallen ist: Ich bin der Meinung, dass sich mit der kürzlichen Farbänderung eine Art „Bug“ in die MediaWiki-eigene wikitable-Definition eingeschlichen hat.

Konkret: Wenn bei einer Tabelle die Rahmenfarbe der Gesamttabelle von der Rahmenfarbe der einzelnen Zellen abweicht, dann kommt per CSS-Spezifikation eine Art Algorithmus zur Anwendung, um die gezeichnete Rahmenfarbe zu bestimmen. Nach diesem Algorithmus übertrumpft bei wikitable die Rahmenfarbe der einzelnen Zellen diejenige der Gesamttabelle. Beispiel:

Dies bedeutet, dass die mit gerrit:324534 versuchte Änderung des Grautons von #aaa nach #a2a9b1 tatsächlich wirkungslos ist (man überprüfe hier, dass das #aaa bei den Zellen stehen gelassen wurde und daher das #a2a9b1 der Gesamttabelle übertrumpft). Mag jemand schauen, ob da noch mehr solche Fehler gemacht wurden und einen Bugreport schreiben? Mir fehlt gerade RL-bedingt leider die Zeit dafür. Gruß --Entlinkt (Diskussion) MediaWiki Diskussion:Common.css#c-Entlinkt-2016-12-14T03:21:00.000Z-Farben11Beantworten

Richtig analysiert. Die unterschiedlichen Rahmenfarben treten auch bei einer wikitable-Tabelle bei leeren Zellen auf. Beispiel:

Optisch kann ich den Unterschied zwar nicht wahrnehmen, aber mit einer Farbpipette kann ich am Rahmen der leeren Zelle rechts unten die Farbe #A2A9B1 entnehmen, während ich am Rahmen den befüllten Zellen die Farbe #AAAAAA entnehmen kann. Ich habe zu diesem Fehler gerrit:327144 eingestellt. --Fomafix (Diskussion) MediaWiki Diskussion:Common.css#c-Fomafix-2016-12-14T06:21:00.000Z-Entlinkt-2016-12-14T03:21:00.000Z11Beantworten

Der Patch wurde angenommen, vielen Dank! --Entlinkt (Diskussion) MediaWiki Diskussion:Common.css#c-Entlinkt-2016-12-14T18:09:00.000Z-Fomafix-2016-12-14T06:21:00.000Z11Beantworten

Braucht’s die noch?--XanonymusX (Diskussion) MediaWiki Diskussion:Common.css#c-XanonymusX-2017-04-26T19:08:00.000Z-div.sideBox11Beantworten

Prima vista: Nö.

Danke für den Hinweis.

Scheint es nur noch auskommentiert in Vorlage:DDR-Jahreshitparade zu geben.

• Kam die Klasse nicht sogar mal aus dem Musikbereich? Ich erinnere mich dunkel an gelöschte Vorlagen, irgendwelche früheren Charts?
• Vorlage:DDR-Jahreshitparade scheint mir dann auch gleich komplett Löschkandidat zu sein, nicht mehr benutzte Vorlage, aber das ist eher dein Metier als Musiker.

@Entlinkt: Benutzer:Entlinkt/sideBox

VG --PerfektesChaos MediaWiki Diskussion:Common.css#c-PerfektesChaos-2017-04-26T19:18:00.000Z-XanonymusX-2017-04-26T19:08:00.000Z11Beantworten

Offenbar war die Klasse ja Vorgängerversion der heutigen Vorlage:Infobox Chartplatzierungen (vor meiner Zeit). Wird heute nur noch für optisch suboptimale Darstellungen von „DDR-Charts“ verwendet, wie mir bei meiner aktuellen Band-Infobox-Aufräumaktion aufgefallen ist. Hatte zuletzt eine kurze Diskussion darüber mit Vanellus, daher hier mal der Hinweis auch an ihn. Grundsätzlich sollte die Klasse vollständig in die Vorlage übergeführt worden sein, wäre auch in diesen Fällen wohl ein vollwertiger Ersatz. Gruß--XanonymusX (Diskussion) MediaWiki Diskussion:Common.css#c-XanonymusX-2017-04-26T19:28:00.000Z-PerfektesChaos-2017-04-26T19:18:00.000Z11Beantworten

43-mal im ANR.--XanonymusX (Diskussion) MediaWiki Diskussion:Common.css#c-XanonymusX-2017-04-26T19:43:00.000Z-PerfektesChaos-2017-04-26T19:18:00.000Z11Beantworten

Sowas im ANR ist Käse.

Scheint auch Junge bekommenn zu haben, war mal nur 1 Treffer gewesen.

Bot in den ANR schicken, oder Mini-(Unter-)vorlage mit den noch benötigten Regeln basten, und die statt der class inline einfügen oder so, oder anders lösen. Was muss an Ostrock denn anders sein als beim Westrock?

VG --PerfektesChaos MediaWiki Diskussion:Common.css#c-PerfektesChaos-2017-04-26T20:02:00.000Z-XanonymusX-2017-04-26T19:43:00.000Z11Beantworten

Mir ist die Vorlage persönlich egal (stammt auch nicht von mir), wichtig ist nur eine Ersatzlösung, keine Löschung der Informationen. --Vanellus (Diskussion) MediaWiki Diskussion:Common.css#c-Vanellus-2017-04-27T05:12:00.000Z-PerfektesChaos-2017-04-26T20:02:00.000Z11Beantworten

• Also, für mein laienhaftes Ohr wirkt das, was in den 43 Artikeln über Silly, City, Pankow, Puhdys, Karat & Co. dargestellt wird, wie die ungeboxte Info für Vorlage:Infobox Chartplatzierungen.
• Müssten halt drei Freiwillige jeden Tag einen Artikel aufmotzen, und in zwei Wochen wäre die Altlast abgewickelt.
• Daraufhin werden über zehn Millionen Seiten eine Hundertstelsekunde effizienter, weil sie nicht mehr nach diesem Spezifikum für ein halbes Hundert Seiten durchsucht werden müssen.

VG --PerfektesChaos MediaWiki Diskussion:Common.css#c-PerfektesChaos-2017-04-27T08:21:00.000Z-div.sideBox11Beantworten

Die zwei Nicht-DDR-Fälle sind schnell erledigt. Das Problem mit den DDR-Fällen ist, dass sie nicht mit der WP:FVC konform gehen und daher wohl erstmal diskutiert werden müssen (zum einen, weil DDR-Charts als solche nicht existier(t)en; zum anderen, weil wir es hier mit Jahrescharts zu tun haben, die weder für Chartbox noch -tabelle wirklich geeignet sind). Das dürfte sich also noch ein bisschen hinziehen.--XanonymusX (Diskussion) MediaWiki Diskussion:Common.css#c-XanonymusX-2017-04-27T17:21:00.000Z-PerfektesChaos-2017-04-27T08:21:00.000Z11Beantworten

• Wir warten schon seit Jahren drauf, dass die letzten Altfälle erschwinden; da käme es auf ein paar Wochen auch nicht mehr an.
• Es scheint nur um die Überschrift zu gehen? Also dass „Chartplatzierungen“ nicht angemessen wäre, und es „Sozialistische Musikbeliebtheit“ sein solle, oder die oben schon auftauchende „Jahreshitparade (DDR)“?
  • Die beiden sowieso auf dieselbe Basisvorlage Album und Single verlinkenden Einträge für einzelne Zeilen scheinen sich hier ebenfalls verwenden zu lassen. Halt ohne 4=Wo. mit konstantem 1=DDR.
  • Damit hätte man in der neuen Technik ein einheitliches Erscheinungsbild.
  • In Silly (Band) stehen beide sideboxen übereinander.
  • Die Vorlage:Infobox Chartplatzierungen könnte man kopieren und ausweiden, diverse Parameter eliminieren. DVD & DDR gab es wohl nicht gleichzeitig. Die Kopie bekäme eine neue Überschrift, und ob das jetzt Titel oder Singles oder Alben wären müsstet ihr sehen.
  • Die Kopie könnte in die ungenutzte Vorlage:DDR-Jahreshitparade reingeschrieben werden.
  • Damit gäbe es einheitliche Optik, einheitliche Vorlagenbedienung und einheitliche Systematik für NSW und DDR. Bei den symtembedingt notwendigen Unterschieden und Eigenheiten.

VG --PerfektesChaos MediaWiki Diskussion:Common.css#c-PerfektesChaos-2017-04-27T18:20:00.000Z-XanonymusX-2017-04-27T17:21:00.000Z11Beantworten

Bin schon weit gekommen, bleiben noch acht etwas umfangreichere Fälle.--XanonymusX (Diskussion) MediaWiki Diskussion:Common.css#c-XanonymusX-2017-05-01T23:23:00.000Z-PerfektesChaos-2017-04-27T18:20:00.000Z11Beantworten

Gut, @PerfektesChaos: endlich konnte ich mich dazu aufraffen, die beiden umfangreichsten Fälle auch noch zu erledigen! Damit ist die Klasse jetzt nicht mehr in Verwendung und kann wohl weg. Gruß--XanonymusX (Diskussion) MediaWiki Diskussion:Common.css#c-XanonymusX-2017-07-26T16:26:00.000Z-XanonymusX-2017-05-01T23:23:00.000Z11Beantworten

Hallo zusammen! Ich bin bei verschiedenen Gelegenheiten (AKtionsseiten, Vorlagen, Buttons) immer wieder auf das Problem gestoßen, dass es schwierig bis unmöglich ist, einfach mal einen Block negativ (also heller Text auf dunklem Hintergrund) zu setzen.

Natürlich kann man Text- und Hintergrundfarbe in jedem Container per Inline-CSS einstellen. Dummerweise betrifft das aber nicht die im Text enthalten Links. Die werden dann weiterhin Blau dargestellt und das ist auf dunklen Hintergrundfarben kaum zu lesen. Die Methode ein <span style="color:#FFF">...</span> in jeden einzelnen Link zu schreiben ist nicht wirklich praktikabel, wenn dieser Links (wie in vielen Vorlagen) auch mal nutzergeneriert sein können.

Ich würde daher vorschlagen, für negative Inhaltselemente einen Standardklasse anzulegen, die so aussehen könnte:

.negative {
    background-color: #000;
    color: #FFF;
}

.negative.negative.negative a{
    color: currentColor;
    text-decoration: underline;
}

Ergänzung: Hab's mittlerweile mal getestet. Das Tripeln des Selectors ist hier notwendig, um ohne !important die überpräziesen Selektoren im MediaWiki-CSS zu überschreiben. // Martin K. (Diskussion) MediaWiki Diskussion:Common.css#c-Martin Kraft-2017-07-26T16:00:00.000Z-Standardklasse für Negativ-Satz?11Beantworten

Die Tatsächliche Hintergrundfarbe könnte man dann entweder via Inline-Style angepassen. Oder wir legen gleich einen Satz Vorlagen für die dunklen CI-Farben an.

Was haltet Ihr davon? Oder gibt es am Ende schon eine ähnliche Lösung, die ich beim durchforsten des CSS übersehen habe? // Martin K. (Diskussion) MediaWiki Diskussion:Common.css#c-Martin Kraft-2017-05-06T15:18:00.000Z-Standardklasse für Negativ-Satz?11Beantworten

Ich glaube nicht, dass wir pauschal die Browser beim Leser in über zehn Millionen Seiten dazu auffordern sollten, die dargestellte Seite daraufhin zu untersuchen, ob „einfach mal ein Block negativ“ darzustellen sei.

Insbesondere gibt es ein den Lesern vertrautes Farbschema, wie ihre noch nicht besuchten Links, schon besuchten Links, Weiterleitungen, interne Links markiert wären; und Fortgeschrittene markieren neben BKS auch Verlinkungen in bestimmte Namensräume, innerhalb derselben Seite usw.

• Alles das wird von dem Vorschlag locker unterlaufen und rigoros beiseitegeschoben.
• Eben weil die Farbgebungen unserer Verlinkungen darauf abgestimmt sind, dass der Text in dunkleren Farben gehalten ist, also auf einigermaßen hellem Hintergrund erwartet wird, verbietet es sich, „einfach mal einen Block negativ“ darzustellen, sofern er Verlinkungen enthält.

Der zusätzliche Erkenntnisgewinn von weißer Schrift auf großflächig schwarzem Grund will mir auch grad nicht einleuchten. Für eine kleine Fläche, etwa eine Überschrift oder einen Warnhinweis, kann man das aus Jux ja mal machen, aber ohne Links, und dann reicht lokales inline.

VG --PerfektesChaos MediaWiki Diskussion:Common.css#c-PerfektesChaos-2017-05-06T15:37:00.000Z-Martin Kraft-2017-05-06T15:18:00.000Z11Beantworten

Ich glaube Du verstehst mich falsch:

• Es geht hier nicht darum, ganze Artikel oder Diskussionsabschnitte negativ zu stellen.
• Es geht vielmehr um ein Werkzeug, mit denen diejenigen arbeiten können, die Portale, Meta- und Wartungsseiten, Hinweisbausteine, Warnungen und der gleichen gestalten – Z.B. den DÜP-Baustein, z.B. die WLM-Seite, z.B. die sich aktuell in monotoner unübersichtlichkeit ergehenden Lizenzvorlagen für Bilder.
  Und da macht Negativ-Satz mitunter schon sehr viel Sinn und ist im übrigen Netz auch für entsprechende Anwendungszwecke auch etabliert. Es ist einfach ineffizient und wartungs-verkomplizierend, die Leute in solchen Fällen zu irgendwelchen Inline-Spans oder zum Verzicht auf dunklere Hintergrundfarben zu nötigen. Dass in diesem Projekt im Jahre 2017 Farben immer noch vor allem als blase Pastelltöne eingestetzt werden, wodurch alles so aussieht als wären wir gestalterisch irgendwo in den frühen 2000ern hängen geblieben, liegt ja vor allem daran, dass sich die Alternative (nämlich Negativsatz) z.Z. nur mit murksigen Workarrounds bewerkstelligen lässt. Im Zeitalter von Material- und Flat-Design ist das mMn weder zeitgemäß noch entspricht es den Nutzererwartungen. Der Wikipedia-Style-Guide ist da schon viel weiter, nur wurde das leider nie konsequent in Vektor umgesetzt.

Ich halte das daher nach wie vor für eine gute Idee. Zumal es mMn auch keine echten Nachteile hat. Die paar Zeilen CSS tun niemandem weh und beeinträchtigen ja auch keine der vorhanden Darstellungen. Aber sie würden die Sache für diejenigen, die dieses Feature gebrauchen können, wirklich erheblich vereinfachen. // Martin K. (Diskussion) MediaWiki Diskussion:Common.css#c-Martin Kraft-2017-05-06T17:22:00.000Z-PerfektesChaos-2017-05-06T15:37:00.000Z11Beantworten

+1 zu Martin Kraft. Ich sehe die Nützlichkeit auch durchaus gegeben und fände es sinnvoll eine solche Standardklasse anzulegen. — DCB (Diskussion • Bewertung) MediaWiki Diskussion:Common.css#c-DCB-2017-05-08T22:17:00.000Z-Martin Kraft-2017-05-06T17:22:00.000Z11Beantworten

Ich stimme in dem einen Punkt zu, dass ein gut gemachtes dunkles Design eine Bereicherung sein kann. Aber hier sehe ich deutlich mehr Nacht- als Vorteile:

• Du willst die Textfarbe und die Hintergrundfarbe an getrennten Stellen angeben. Wie groß ist die Wahrscheinlichkeit, dass in der Mobilversion, in einer App oder einer sonstigen alternativen Nutzung genau eine der beiden Definitionen verloren geht und man dann weiß auf weiß oder schwarz auf schwarz hat?
• Alle Links in weiß und unterstrichen klingt erst einmal sinnvoll bei dunklem Hintergrund. Aber wie unterscheide ich Links zu vorhandenen und fehlenden Artikeln? Besuchte und unbesuchte? Was ist bei Benutzern, die die Linkfarben vom Browserstandard überschreiben lassen? Was ist mit Benutzern, die auf andere Weise (etwas mittels Benutzer:PDD/monobook-clean.css) andere Linkfarben setzen?
• In allen aktuellen Skins wirkt ein dunkler Hintergrund als Fremdkörper, der mehr störend als irgendwie anders auffällt.

Im Fazit ergibt sich für mich, dass das ganze deutlich mehr Wartung erfordern würde als sich in Anbetracht des begrenzten Einsatzgebietes rechtfertigen lässt. –Schnark MediaWiki Diskussion:Common.css#c-Schnark-2017-05-09T10:02:00.000Z-DCB-2017-05-08T22:17:00.000Z11Beantworten

• Wie Du in meinem Code-Vorschlag oben sehen kannst, würde ich eine Default-Hintergrundfarbe festlegen, so das dieser Fall eigentlich nicht auftreten kann. Alternativ könnte man auch mit mehreren Farb-Klassen arbeiten, die dann komplett autark ohne inline-CSS funktionieren.
• Für die Einsatzzwecke, für die wir diesen Negativsatz benötigen spielt die Unterscheidung zwischen vorhanden und fehlenden Artikeln eh keine Rolle. Es geht ja nicht um ein großflächiges Umfärben des ANR, sondern kleinere Blöche auf Funktionsseiten.
• Es geht doch gerade um Layout-Elemete die wie Buttons, Warnhinweise oder Tab-Bars aus dem aktuellen Design hervorstechen sollen. Und wie man z.B. an dem mw-ui-Buttons sieht, werden solche Elemente dem aktuellen CD zu Folge doch heute schon negativ gesetzt.
• Das Argument, dass dies deutlich mehr Wartung erfordere kann ich nicht nachvoll ziehen. Es ist doch genau das Gegenteil der Teil der Fall: Eine zentral wartbare Klasse für Negativ-Satz ist doch um mehrere Zehnerpotenzen wartbarer als über hunderte Seiten verteilte <span style="color:#FFF">-Schnippsel?!

// Martin K. (Diskussion) MediaWiki Diskussion:Common.css#c-Martin Kraft-2017-05-12T17:37:00.000Z-Schnark-2017-05-09T10:02:00.000Z11Beantworten

„Die Tatsächliche Hintergrundfarbe könnte man dann entweder via Inline-Style angepassen.“ hast du geschrieben. Und damit werden Hintergrund- und Textfarbe getrennt. Würde man die von dir vorgeschlagenen Zeilen in die Common.css einfügen und dann irgendwo schreiben <div class="negative" style="background-color: #222;">…</div>, sähe das Ergebnis im Desktopbrowser so aus, wie du es dir vorstellst, in der Mobilversion wäre es nicht sichtbar.

Füge die von dir vorgeschlagenen Codezeilen einfach mal in deine private common.css ein, lege Benutzerunterseiten an, die die neue Klasse verwenden und betrachte das Ergebnis in verschiedenen Browsern. In der Mobilversion. Mit verschiedenen Browsereinstellungen bezüglich Farbeinstellungen. Mit alten Browsern (https://analytics.wikimedia.org/dashboards/browsers/#all-sites-by-browser/browser-family-and-major-tabular-view kommt für letztes Jahr auf absurde 3 % für IE 8 und älter). Dann stell dir vor, die Mobilversion ändert mal wieder die Art, wie sie mit Inline-Styles umgeht. Stell dir vor, dass in Zukunft vielleicht mal ein Skin eingeführt wird, der von Haus aus einen dunklen Hintergrund hat. Stell dir vor, dass eine CSS-Anpassung notwendig würde, aber niemand Lust oder Ahnung hat, wie sie umzusetzen ist.

Vor ein paar Monaten ist dir aufgefallen, dass Vorlage:Button problematisch ist. Dreimal darfst du raten, welcher aktuelle Wettbewerb die Vorlage trotzdem prominent verwendet. Glaubst du ernsthaft, dass der Einsatz deiner vorschlagen „negativ“-Klasse in der mittelfernen Zukunft weniger problematisch würde? –Schnark MediaWiki Diskussion:Common.css#c-Schnark-2017-05-13T06:16:00.000Z-Martin Kraft-2017-05-12T17:37:00.000Z11Beantworten

• Ehm ... wir sprechen hier von den Eigenschaften color und background-color. Das ist CSS der allerersten Stunden. Es gibt keinen auch nur ansatzweise CSS-fähigen Browser, der das nicht unterstützt.
• Wenn Dir die Kombination von Inline- und normalem CSS-Bauchgrummen beschert, dann dürftest Du eigentlich vor lauter Bauchschmerzen kaum noch laufen können ;) Das wird in diesem Projekt nämlich dauernd gemacht.
  Aber sei's drum: Sprechen wir also darüber, feste Klassen für die wesentlichen CD-Farben im Negativsatz anzulegen. Da dürfte es ja keine Probleme geben, oder?
• Und was sie Mobil-Vesion angeht: Sinnigerweise sollte man die gleichen Klassen dann auch in der Mobile.css anlegen. Genauso, wie das mit den nicht CS-konformen pastelligen Farbklassen auch gemacht wurde.

// Martin K. (Diskussion) MediaWiki Diskussion:Common.css#c-Martin Kraft-2017-05-17T13:26:00.000Z-Schnark-2017-05-13T06:16:00.000Z11Beantworten

P.S.: Das Argument „Man dürfe so etwas nicht machen, weil sich ja irgendwann mal der Skin ändern könne“ halte ich für wenig zielführend. Das gilt nämlich nicht nur für alles, was in der commons.css steht sondern auch für jeden einzelnen Inline-Style. In so einen Fall müssten wir da eh nochmal ran. Dafür ist es ja ein Wiki.

P.P.S.: Es ist übrigens kein Wunder, dass so etwas wie {{Button}} immer wieder verwendet wird, wenn nicht klar und deutlich kommuniziert, durch was sie ersetzt werden sollte und das auch konsequent umsetzt. So gesehen handelt es sich auch bei den nicht CI-konformen Pastell-Klassen .hintergrundfarbeXY um fiesesten, nichtsemantischen, wartungsfeindlichen Legacy-Code, der dringend überarbeitet und ersetzt werden sollte. Und der hiesige Vorschlag, wäre eine Möglichkeit dafür.

Du bist bislang mit keiner Silbe auf die wesentlichen Gegenargumente eingegangen:

1. Es gibt ein breites Feld an spezifischen Link-Farben, die auf dunkle Schriftfarbe abzielen, namentlich für unbesuchte, besuchte, Wiki-interne, externe Weblinks, Weiterleitungen und schließlich redlinks, ergänzt durch vielfältige benutzerdefinierte bedeutungstragende Linkschriteinfärbungen, die alle alle miteinander einen maximal pastellfarbenen Hintergrund voraussetzen.
2. Du willst eine winzige Handvoll Seiten mit dunklem Hintergrund ausstatten, wofür über zehn Millionen anderer Seiten im Browser jedes Lesers daraufhin durchsucht werden sollen, ob sie zu den paar Dingern gehören würden.
3. Du willst nicht nur einen kleinen Textbereich ausstatten, sondern anscheinend den gesamten Inhaltsbereich, der jedoch in einem unverändert hellfarbenen beliebigen Desktop-Skin bzw. heller Mobil-Umgebung steht. Super-Design.

Du kannst maximal einen kleinen Bereich dunkel hinterlegen, nicht aber beliebigen Freitext. Nur in einem engen Bereich, in dem es auch keine besonderen Verlinkungen gäbe, und wo du die Benutzer- und Browser-Eigenschaft „Link bereits besucht“ auch noch unterpflügst zum Nachteil der Navigationsqualität, kann dein Plan überhaupt sinnvoll sein. Dafür setzen wir jedoch seit Ewigikeiten direkten inline-style ein, und mehr braucht es dafür auch nicht.

VG --PerfektesChaos MediaWiki Diskussion:Common.css#c-PerfektesChaos-2017-05-17T14:13:00.000Z-Schnark-2017-05-13T06:16:00.000Z11Beantworten

So wie es aussieht, scheint es immer noch nicht klar zu sein, worum es mir eigentlich geht?! Und das obwohl ich das schon mehrfach beschrieben habe – daher nochmal:

• Es geht NICHT darum, ganze Seiten mit einem dunklen Hintergrund zu gestalten.
• Es geht darum, (dort wo es Sinn macht) einzelne Seitenelement negativ gestalten zu können. Es geht um so etwas wie:
  • DÜP-Bausteine, Lizenzhinweise, Löschvermerke
  • Hinweiskästen auf Funktionsseiten
  • Tabs
  • Banner
  • Teaser
  • usw.

Es geht also nicht um ein Werkzeug für den ANR, sondern um etwas, was vor allem im Meta-Bereich eingesetzt wird. Und bei diesen Anwendungsfällen, spielen Rotlinks, Besuchte-Links usw. ein untergeordnete bis keine Rolle. Und es macht wirklich keinen Sinn bei all diesen Anwendungsfällen jeden einzelnen Link intern noch mal mit einem Inline-Style-Span zu versehen.

Zu 2. sei gesagt, dass es (a) gar nicht so wenige Seiten sind, auf denen man so etwas einsetzen könnte. Und (b) machen die paar Zeilen CSS den Bock nun wirklich nicht fett, wenn man bedenkt, dass wir umseitig neben etlichen Modulen, die nur auf einer Seite oder in einer Vorlage eine Rolle spielen, ganze 75 Zeilen CSS allein für die Hauptseite mitladen. // Martin K. (Diskussion) MediaWiki Diskussion:Common.css#c-Martin Kraft-2017-05-17T16:17:00.000Z-PerfektesChaos-2017-05-17T14:13:00.000Z11Beantworten

Alles, was du da aufgezählt hast, kannst du dir jederzeit selbst in Elemente stecken und mit inline-style versehen, und das haben andere schon vor mehr als einem Jahrzehnt hie und da mal realisiert, in dunkelviolett, dunkelbraun, navyblue oder was immer; mit weißer oder gelber Schrift und Verlinkung. Projektweiter Definitionen für alle Seiten, wegen derer du hier vorstellig geworden bist, bedarf es nicht. Und die einzige Hintergrundfarbe, die du vorgesehen hast, ist nachtschwarz. VG --PerfektesChaos MediaWiki Diskussion:Common.css#c-PerfektesChaos-2017-05-17T18:09:00.000Z-Martin Kraft-2017-05-17T16:17:00.000Z11Beantworten

Ach komm, Du weißt so gut wie ich, dass Inline-Styles per se ein Anti-Pattern sind. Kein ernstzunehmender Frontend-Entwickler würde die als Best-Practice propagieren, sondern die Hände über dem Kopf zusammenschlagen, wenn er eine Website warten müsste, in der diese so exzessive eingesetzt würden wie hier. Wir machen das hier-zu-Wiki doch auch nur, weil es halt nicht anders geht.

Und gerade deshalb ist es sinnvoll für Standard-Fälle Standard-Klassen bereit zustellen, um so den unsinnig exzessiven Einsatz von Inlinestyles zu reduzieren und einen halbwegs leserlichen Wikitext gewährleisten.

Der CSS-Code, den ich oben gepostet habe, war nur eine Diskussionsgrundlage und nicht die fertige Lösung. Ich hatte ja schon angedeutet, dass wir das gerne über Standardklassen für alle offiziellen CI-Farben regeln können. Und von mir aus kann ich da auch einen entsprechend getesten Code-Vorschlag präsentieren. Das macht aber nur Sinn, wenn es hier nicht auf Fundamentalsopposition hinausläuft. // Martin K. (Diskussion) MediaWiki Diskussion:Common.css#c-Martin Kraft-2017-05-17T18:21:00.000Z-PerfektesChaos-2017-05-17T18:09:00.000Z11Beantworten

Da in WikiText (scheinbar?) nur fixe Bildgrößen gesetzt werden können, gibt es gerade bei Infoboxen häufig das Problem, dass...

• ..auf kleinen Auflösungen zu große Bilder das Layout unnötig aufspreizen und ggf. sogar horizontales Scrollen verursachen.
• ..zu kleine Bilder verwendet werden, die dann in großen Auflösungen umgeben von zwei großen Leerräumen winzig in der Mitte sitzen.

Ich glaube Ihr stimmt mir zu dass das suboptimal ist. Auf normalen Websites umgeht man das durch ein Fuides Layout und responsive Techniken wir srcset (wovon ich hier garnicht erst träume). Als ersten Schritt zur Lösung des Problem würde ich vorschlagen, hier eine Klasse einzubauen, mit deren Hilfe man Bilder fluid runterskalieren lassen kann. D.h. man baut die Bilder in der größten sinnvollen Auflösung ein und sobald diese größer ist als der zur Verfügung stehende Raum, werden sie runterskaliert.

Hier mein Implementierungsvorschlag:

.fluid-img {
    max-width:100%;
}
.fluid-img>img, .fluid-img>.image>img {
    max-width:100%;
    width: auto!important; /* Überschreibt width-Attribut in HTML */
    height: auto!important; /* Überschreibt height-Attribut in HTML */
}

In Wikitext sähe dass dann so aus:

<div class="fluid-img">[[Datei:Solar_system_scale-2.jpg|600px]]</div>

Was haltet Ihr davon? // Martin K. (Diskussion) MediaWiki Diskussion:Common.css#c-Martin Kraft-2017-07-26T14:55:00.000Z-Standardklasse für responsive herunterskalierende Bilder11Beantworten

Ich verstehe davon nichts, aber wenn es die beiden genannten Probleme löst, wäre es toll! --Neitram ✉ MediaWiki Diskussion:Common.css#c-Neitram-2017-07-26T14:59:00.000Z-Martin Kraft-2017-07-26T14:55:00.000Z11Beantworten

Ich bin mir nicht sicher, Martin, ob die Richtung stimmt. Es sind mindestens 2 Fälle zu unterscheiden:

• Infoboxen mit festen Bildbreiten. Da mag dein Ansatz für funktionieren
• Bilder im Fließtext, idR rechts: Diese sollten *immer* ohne feste Bildgröße eingebunden sind, höchstens mit hochkant bzw. hochkant=Skalierungsparameter relativ gesetzt werden. — Raymond ^Disk. MediaWiki Diskussion:Common.css#c-Raymond-2017-07-26T16:36:00.000Z-Martin Kraft-2017-07-26T14:55:00.000Z11Beantworten

Diese CSS-Klasse dürfte vor allem in Vorlagen und bei anderen Layout-Sonderfällen zum Einsatz kommen. Für die normalen Vorschaubilder im Textinhalt ist sie nicht gedacht – und es käme wohl kaum ein Autor auf die Idee, dort den obigen HTML-Code einzusetzen.

Aber mal abgesehen davon muss man hier zwischen der WikiText-Eingabe und der HTML-Ausgabe unterschieden. Denn auch wenn im WikiText keine fixe Bildbreite gesetzt wird, rendert MediaWiki eine fest Pixel-Breite (i.d.R. 220px) ins HTML. Und das ist das, was der Browser letzten Endes interpretiert. Dummerweise sperren diese fixen Bildgrößen dann erbarmungslos die Container (Info-Boxen, Tabellen, etc.) auf, in denen die Bilder sitzen, oder sorgen sogar dafür, dass die Bilder ihre Container und andere Elemente überlappen.

Auf „normalen“ Websites behebt man dieses Problem, indem man Bilder grundsätzlich ohne Höhen und Breiten-Attribute ausgibt und irgendwo im CSS das hier stehen hat:

img { max-width:100%; }

Das wäre auch in MediaWiki sinnvoll, aber ich bezweifle, dass es in absehbarer Zeit dazu kommt. Leider (und das ist das eigentliche Problem) lässt die statische Größenausgabe selbst im Bedarfsfall nicht mit Inline-CSS überstimmen, weil die <img src="">-Tags direkt von MediaWiki inkl. der Höhen und Breitenangaben erzeugt werden, ohne dass man ihnen irgendein CSS mitgeben könnte. Das bekommt also nur mit einem richtigen StyleSheet in den Griff.

Aus meiner Sicht wäre daher ein CSS-Hack, wie der oben, die einzige Möglichkeit, um bei Bedarf ein fluides Verhalten von Bilder zu erzwingen. // Martin K. (Diskussion) MediaWiki Diskussion:Common.css#c-Martin Kraft-2017-07-26T18:03:00.000Z-Raymond-2017-07-26T16:36:00.000Z11Beantworten

P.S.: Bei Interesse kann ich Euch gerne einen Login zu meinem Test-Wiki zukommenlassen. Da habe ich diesen Vorschlag hier und den oben drüber schon mal testweise implementiert. // Martin K. (Diskussion) MediaWiki Diskussion:Common.css#c-Martin Kraft-2017-07-26T18:23:00.000Z-Raymond-2017-07-26T16:36:00.000Z11Beantworten

Ich habe noch nicht restlos das Ziel der Aktion verstanden. Ich bin aber der Auffassung, dass

1. das ggf. auf MediaWiki-Ebene vom dortigen MultiMedia-Team angepackt und diesem verdeutlicht werden sollte;
2. wir hier keine privaten Bastel-Hack-Wege in Seiten der dewiki etablieren sollten;
3. wir insbesondere nicht die projektweit in über zehn Millionen Seiten eingebundenen CSS-Konstrukte mit Angelegenheiten belasten sollten, die dann in zwei oder drei Seiten mal benutzt würden.

Im Übrigen wäre hier die Etablierung einer werbenden deutsch-englischen Benutzerseite anzuraten, die das Problem verdeutlicht, und Beispielanwendungen zeigt, nebst Code-Sequenzen. die sich dann jeder temporär in sein privates CSS injizieren kann, um die Effekte live auszuprobieren, nebst Verlinkung von Hintergrundmaterial.

• Insbesondere ist mir auch nicht klar, warum der o. a. Code !important enthalten müsse.

VG --PerfektesChaos MediaWiki Diskussion:Common.css#c-PerfektesChaos-2017-07-26T18:17:00.000Z-Standardklasse für responsive herunterskalierende Bilder11Beantworten

1. Mal abgesehen von MediaViewer hat das MultiMedia-Team (so es ein solches überhaupt noch gibt) meiner Wahrnehmung nach in den letzten 5 Jahren nichts substanzielles mehr an der Medienanzeige im Desktop-Frontend verbessert. Vielversprechende Ansätze wie Winter verschwanden wieder in der Schublade, Innovationen gab es wenn dann auf der mobilen Seite oder in der App. Hier in Vector herrscht Grabesstille. Und wenn ich die WMDE-Techniker mit denen ich mich darüber unterhalten habe richtig verstehe, wird sich daran in absehbarer Zeit nichts ändern.
   Kein Wundern, dass andere Sprach-Communities (wie die en.WP) mittlerweile selbst in erheblichem Umfang an ihrem Layout und den Bilddarstellungen rumdoktorn – leider mit einem sehr durchwachsenen Ergebnis.
2. Wenn es darum geht „keine privaten Bastel-Hack-Wege in Seiten der dewiki etablieren“ bist Du leider 15 Jahre zu spät dran ;)
   Dieses Wiki inkl. seiner Vorlagen steckt voller „Bastel-Hack-Wege“. Die hier (aus Ermangelung vernünftiger Alternativen) bis zum Exzess eingesetzten Inline-Styles sind nichts anderes als „Bastel-Hack-Wege“, die bei jedem Front-Endentwickler, den ich kenne das blanke Grausen hervorrufen.
   Da kann jede gut durchdachte und vernünftig dokumentierte globale CSS-Klasse nur dazu beitragen, den Code in diesem Projekt wartbarer zu machen und weitere Inline-CSS-Hacks zu verhindern.
3. Die hier vorgeschlagen Lösung belastet keine einzige Inline-CSS-Konstrukution, weil sie ja überhaupt nur dann zur Anwendung kommt, wenn der Anwender ausdrücklich die CSS-Klasse .fluid-img verwendet. Und wenn er das im von ihm selbst verantworteten Code (z.B. einer Infobox-Vorlage) tut, dann muss er dabei, wie bei allen anderen Änderungen auch, die Konsequenzen bedenken.
4. User-CSS ist keine Lösung. Weil die oben beschrieben Probleme unser Nachnutzer in vielgrößerem Maße betreffen als die hier aktiven Autoren. Schau Dir den doch einfach mal den Artikel Sonnensystem in einem schmalen Browserfenster an.
5. Die !important Anweisung habe ich hier eingefügt, weil ich mir nicht sicher war ob MediaWiki die Bildgrößen in bestimmten Fällen auch per Inline-CSS setzt. Wenn das immer nur HTML-Attribute sind können sie (nach meinen jüngsten Tests) auch weg.

Ich bin der festen Überzeugung, dass wir bei solchen Problem zweigleisig fahren müssen:

• Auf der einen Seite müssen wir natürlich dafür werben, dass die WMF und WMDE das Responsive Webdesign des Desktop-Frontends endlich angehen. Und bei den technischen Wünschen habe ich genau das auch schon getan. Nur leider wird das bestenfalls mittel- bis langfristig Wirkung zeigen.
• Und deshalb müssen wir auf der anderen Seite dort, wo Probleme besonders offensichtlich sind, selbst auf dem kleinen Dienstweg Lösungen implementieren, die verhindern, dass die fünft größte Website der Welt nicht auf vielen Geräten total zerschossen aussieht, und eine halbwegs zeitgemäße Darstellung ermöglichen. // Martin K. (Diskussion) MediaWiki Diskussion:Common.css#c-Martin Kraft-2017-07-26T18:50:00.000Z-PerfektesChaos-2017-07-26T18:17:00.000Z11Beantworten

P.S.: Ich habe mir gerade mal angesehen, wie die das in der Mobilversion lösen. Und siehe da, dort steht im CSS im Endeffekt genau das, was auch ich hier vorschlage – mit dem kleinen aber feinen Unterschied, das es nicht dezent bei Bedarf durch eine Klassen eingebaut werden kann, sondern einmal brachial über alles drübergebügelt wird (!important inkl.).

.content a > img {
    max-width: 100% !important;
    height: auto !important;
}

Soviel also zum Thema „Warten bis die WMF eine sauberer Lösung vorlegt.“. // Martin K. (Diskussion) MediaWiki Diskussion:Common.css#c-Martin Kraft-2017-07-26T18:57:00.000Z-PerfektesChaos-2017-07-26T18:17:00.000Z11Beantworten

P.P.S.: Zum Thema Inline-CSS:

Please don't do this, unless you really have to! It is really bad for maintenance (you might have to update the same information multiple times per document), and it also mixes your presentational CSS information with your HTML structural information, making the CSS harder to read and understand. Keeping your different types of code separated and pure makes for a much easier job for all who work on the code.

The only time you might have to resort to using inline styles is when your working environment is really restrictive (perhaps your CMS only allows you to edit the HTML body.)

Mozilla CSS Dokumenation / Unterstreichung durch Martin K. (Diskussion) 21:13, 26. Jul. 2017 (CEST)

OT: Ich hab’ keine Ahnung, was „Winter“ war, aber Timeless soll wohl irgendwie ähnlich sein :-) --nenntmichruhigip (Diskussion) MediaWiki Diskussion:Common.css#c-Nenntmichruhigip-2017-07-26T19:27:00.000Z-PerfektesChaos-2017-07-26T18:17:00.000Z11Beantworten

• Was die Mär angeht von „Inline-CSS ist bööööööse, nimm immer projektweite Klassen“:
  • Das stimmt für Websites, die wenige unterschiedliche Elemente in allen ihren Seiten anbieten.
  • Das trifft nicht für uns zu, die wir zigtausende unterschiedliche Formatierungen haben, mal für Feuerwehrautos, mal für das Thema Borussia-Mönchengladbach, mal für Laub- und Nadelwälder, mal für tibetische Schrift.
  • Wenn wir das tun würden, was hier vorgeschlagen wurde, dann landen wir bei Zigtausenden von Klassen mit lustigen Namenskonventionssystemen und einem CSS-Wust von 50 MB, die in jeder der über zehn Millionen Inhaltsseiten präsent sein müsste und bei der Hunderttausende von Selektoren in jeder Seite vom Browser durchzuprobieren wären. Wobei nur eine Handvoll wirklich greifen würde.
  • Das nicht begriffen zu haben und mit Super-responsive-web-designer-Phrasen anzukommen entwertet das Begehr.
• Wenn wir für jede Idee, die irgendwer hat und auf einem Dutzend Seiten einbauen will, jedesmal die umseitige projektweite und von Admins zu pflegende Seite um neue Definitionen erweitern würden, dann käme man bei genau diesem Müll raus.
• In den ersten Jahren der deWP hatte man mal den Riesen-Riesen-Fehler begangen, und für allerlei Vorlagen statt Inline-CSS jedesmal die umseitigen Definitionen erweitert.
  • Was zur konfusen Aufblähung führte und nicht mehr wartbar wurde.
  • Um sowas wieder loszuwerden, wird teilweise ein Dutzend Jahre extrem aufwändiger Pflegearbeit benötigt.
• Wenn umseitig etwas neu hineinkommen soll, dann muss die Notwendigkeit für sehr viele Seiten und sehr viele Situationen bei vielen Benutzern dargelegt werden.
  • Das ist bislang nicht ansatzweise der Fall.
• Eine übersichtliche Darlegung, was eigentlich wann wo passieren und bewirken soll, ist bisher nicht erfolgt.
  • Dafür ist hier auch der falsche Ort.
  • Es ist durch Screenshots zu verdeutlichen und Nutzungsstatistiken sind nachzuweisen.
  • Ein lokaler Hack wird umseitig ohnehin nicht mehr reingepfuscht; wenn das wirklich ein ernsthaftes Problem sei, dann müsste sich ja auch das WebDesign-Team von Mediawiki leicht überzeugen lassen, und dann kann das ja auch weltweit bereitgestellt und gepflegt werden.

VG --PerfektesChaos MediaWiki Diskussion:Common.css#c-PerfektesChaos-2017-07-26T20:04:00.000Z-Standardklasse für responsive herunterskalierende Bilder11Beantworten

• Zum Thema Inline-Styles:
  • Es gibt nicht nur die Optionen Inlines-Styles oder Projektweite Klassen. Es wäre durchaus machbar Themen oder Namensraum spezifische CSS-Dokumente einzubinden. Dass dieses schon seit Jahren angedachte Projekt noch immer nicht ausgerollt, liegt sicher auch daran, dass es sich die meisten im hießigen Inline-Style-Wildwuchs bequem eingerichtet haben. Der Eindruck drängt sich jedenfalls auf, wenn man bedenkt, dass hier Vorschläge wie dieser oder der oben drüber refelxartig mit dem Beamtendreisatz abgeblockt werden.
  • Zeige mir mal irgendeine umfangreiche Website, die so massiv über Inlne-Styles formatiert wird wie die Wikimedia Wikis. Zeige mir ein Lehrbuch, eine Doku oder einen W3C-Draft der die Verwendung von Inline-Styles in einem so massiven Ausmaß empfiehlt.
  • Dass es hier "zigtausende unterschiedliche Formatierungen" gibt, ist mMn kein schützenswerter Zustand sondern Teil des Problems. Wenn man z.B. früh genug eine saubere CSS-Bibliothek für Infoboxen etabliert hätte, hätte man sich hunderte Inline-Style-Orgien unterschiedlichster Qualität genauso sparen können, wie die Hacks, die dafür nötig sind diesen Murks mobil und in der App anzuzeigen.
  • "Wenn wir das tun würden, was hier vorgeschlagen wurde" hätten wir irgendwann ein vernünftiges CSS-Framework (vgl. Bootstrap, Skeleton oder Foundation), dass uns hundertausende KB an InlineStyle-Murks ersparen würde. Und nein: Wir können nicht darauf warten, dass das irgendwann mal vom WMF-Himmel fällt.
  • Dass ich hier immer wieder für responsive Lösungen plädiere sind keine hohlen Phrasen, sondern die Erfahrung aus mehr als 12 Jahren Berufs- und mehr als 3 Jahren Hochschullehrerfahrung in diesem Bereicht.
• Es geht nicht um irgendeine Idee für ein paar dutzend Seiten, sondern um eine generalisierte Lösung die in theoretisch in allen Infobox-Vorlagen mit Bild Anwendung finden könnte. Und die sind in einigen hundertausend Seiten eingebunden.
• Nochmal: Es ist keine Insellösung für eine Vorlage, sondern eine Standard-Klasse, die in Dutzenden Vorlagen und zehntausenden Seiten Verwendung finden könnte.
• s.o.
• Es wurde beschrieben worum es geht. Und es wurde dargestellt, dass genau diese Funktionalität im Mobile-Skin bereits angewandt wird. Was willst Du denn noch wissen?

// Martin K. (Diskussion) MediaWiki Diskussion:Common.css#c-Martin Kraft-2017-07-26T21:22:00.000Z-PerfektesChaos-2017-07-26T20:04:00.000Z11Beantworten

P.S.: Ich finde es übrigens interessant, dass man sich hier an ein paar Zeilen Code stört, die auf tausenden Seiten Verwendung finden könnten aber scheinbar kein Problem damit hat, das bei jedem Seiten Aufruf 60 Zeilen CSS mitausgeliefert werden, die exakt auf einer Seite einer Rolle spielen: Der Hauptseite.

P.P.S.: Um abschätzen zu können welche Last dieser Inline-Style Unsinn verursacht, sollte man sich einfach mal test weise anschauen, wie viel in davon in den einzelnen Artikel gebaut ist:

• Im Artikel Sonnensystem sind es 64 Style-Attribute mit 1.621 Zeichen.
• Im Artikel Deutschland 417 Attribute mit 9.325 Zeichen.
• Im Artikel Liste der Kulturdenkmale in Berlin-Kreuzberg 1.118 Attribute mit 36.434 Zeichen .

Das läppert sich also ganz schön.Falls es mal jemand mal selbst aus probieren will:

var allInlineStyles = [];

$('.mw-body [style]').each(function () {
    allInlineStyles.push( $(this).attr('style') );
});

var str = allInlineStyles.join('\n');
console.log(allInlineStyles.length, ' style attributes\n',
            str.length,' characters \n',
            str);

Im Zuge einer normalen Wikipedia-Recherche kommt da so einiges a KB zusammen. Auf jeden Fall deutlich mehr als in der umseitigen Datei, die im Gegensatz zu den Styles im Artikel nur einermal geladen wird und dann gecached ist.
@PerfectesChaos: Hälst Du das wirklich für eine sinnvolle Lösung? // Martin K. (Diskussion) MediaWiki Diskussion:Common.css#c-Martin Kraft-2017-07-26T22:02:00.000Z-PerfektesChaos-2017-07-26T20:04:00.000Z11Beantworten

Ich darf auf mw:Extension:TemplateStyles verweisen? Mit der Technik kann Seiten- und Vorlagespezifisches CSS gepflegt werden. Damit kann dann auch die Common.css deutlich entschlackt werden. Immerhin schon auf Betalabs aktiv, siehe WP:NEU#Bald™. Ein genauer Zeitplan zur Einführung hier habe ich nocht gefunden. Aber wir können da ja schonmal was vorbeireiten :-) — Raymond ^Disk. MediaWiki Diskussion:Common.css#c-Raymond-2017-07-26T21:49:00.000Z-PerfektesChaos-2017-07-26T20:04:00.000Z11Beantworten

@Raymond: Danke, die Extension kannte ich schon. Da wurde bei solchen Gelegenheiten ja schon oft drauf verwiesen, nur scheint mir da ein RollOut im Wiki nicht wirklich absehbar und falls ja findet sich hier sicher wieder irgendwer, der das Zugunsten der ach so tollen Inline-Styles reglementieren möchte.

Die hier vorgeschlagene Lösung würde übrigens die hier vorgeschlagene CSS-Ergänzung nicht überflüssig machen: Wenn Dinge so oft eingesetzt werden, wie es bei dieser Funktion absehbar ist, dann macht es keinen Sinn, sie redundant in zig Vorlagen-StyleSheets zu deklarieren. Dann macht man das besser einmal global.

Und meines Erachtens ist die Tatsache, dass man im mobilen Skin genau das getan hat, ein deutliches Indiz dafür, dass es diesen Bedarf gibt. // Martin K. (Diskussion) MediaWiki Diskussion:Common.css#c-Martin Kraft-2017-07-26T22:23:00.000Z-Raymond-2017-07-26T21:49:00.000Z11Beantworten

 Kontra. Wenn ich es recht verstehe, sind Infoboxen u. A. dazu gedacht, für ein einigermaßen einheitliches Erscheinungsbild im Layout zu sorgen. Die Annahme eines solchen Vorschlags wäre geeignet, diesen Aspekt völlig zu konterkarrieren. MagentaGreen (Diskussion) MediaWiki Diskussion:Common.css#c-MagentaGreen-2017-07-26T21:47:00.000Z-Standardklasse für responsive herunterskalierende Bilder11Beantworten

@MagentaGreen: Inwiefern sollte es denn ein einheitliches Erscheinungsbild konterkarrieren, bloß weil die enthalten Bilder jetzt fluide als statisch angezeigt werde? Grundsätzlich sind globale StyleSheets sind doch gerade, dazu da ein einheitliches Erscheinungsbild sicher zustellen?! Und dass es bisher keine vernünftigen Standardstile gibt, ist doch gerade der Grund dafür, dass die Infoboxen in diesem Projekt alles andere als Einheitlich sind. // Martin K. (Diskussion) MediaWiki Diskussion:Common.css#c-Martin Kraft-2017-07-26T22:04:00.000Z-MagentaGreen-2017-07-26T21:47:00.000Z11Beantworten

• @Martin, Inline-Styles
  • Bei deiner Berechnung hast du entweder einen Riesen-Riesen-Denkfehler gemacht und es immer noch nicht begriffen, oder du arbeitest vorsätzlich mit manipulativen Zahlen.
  • Der Grund, warum es in den Artikeln solche Inline-Styles gibt, ist, dass sie in genau diesem Artikel benötigt werden.
  • Die Styles, die in einem Artikel über Berlin und Kulturdenkmäler benutzt werden, gehören zu Berlin und Denkmälern.
  • In einem Artikel über Wien und Naturschutzgebiete mag grün für Natur anstehen, und zu den Tönungen der Stadtfarben hat man vielleicht wieder andere Wünsche.
  • Deine Vorstellung eines Verzichts auf Inline-Styles läuft darauf hinaus, dass die Grundfarbe des Heimtrikots des Hamburger Sportvereins einen Klassennnamen bekäme, die zweite Farbe einen weiteren Klassennnamen, das gleiche Paar für das Auswärtstrikot zwei weitere, dies genauso für alle Vereine der FIFA bis zum letzten Drittligisten, nach dem Soccer auch für Basketball, Baseball und Eishockey. Genauso haben SPÖ, SPD, die SDAP in der Weimarer Republik eine bestimmte Parteifarbe; jede Partei in jedem Staat in politischen Epochen ebenfalls einen Klassennamen.
  • Da du nicht wissen kannst, worum es in einem Artikel geht, willst du alle diese Klassen umseitig auflisten; damit auch die marineblaue Kennfarbe für Infoboxen über Kriegsschiffe in dem Artikel über Spanische Literatur mitgeliefert wird.
  • Das Namenssystem für alle diese Klassen sollen die Admins dann nebst Farbwerten auf Zuruf umseitig einpflegen.
  • Dabei kommen für eine Wikipedia unseres Zuschnitts, die sich nicht monothematisch nur mit Briefmarkensammlungen beschäftigt, utopische Dimensionen heraus, die auf jede gelesene Seite anzuwenden sind.
  • Da die Inline-Styles spezifisch für den Inhalt der Seite sind, werden genau die benötigten jeder Seite mitgeliefert.
  • Für die Ausrichtung einer Tabellenzelle ist es gehupft wie gesprungen, ob da Inline steht style="text-align:center" oder nach Art der Hochschullehrer class="table-cell-centered", aber das erste wird in jeder HTML-Anleitung erklärt und bedarf keiner Nachforschung, wo die Stildefinition herkommt und wie sie in welchem Wiki in welchem Jahrzehnt heißt und wie viele Jahre sie noch unterstützt werden würde – es funktioniert robust und stand-alone.
  • Alles das stellst du unfairerweise als Nachteil hin, und behauptest, Jazzmusik müsse unbedingt das Auswärtstrikot von Manchester United kennen und als CSS-Klasse mitgeliefert bekommen, sonst wäre das eines Hochschullehrers unwürdig. Was soll Charlie Parker denn mit der Trikotfarbe anfangen, oder mit dem Grünton für B’90/G?
• Benutzer, teils auf Sichterrechte beschränkt, können fast alle Vorlagen bearbeiten.
  • Diese ermöglichen seit anderthalb Jahrzehnten nur Inline-Styles.
  • Die Vorlagen sorgen innerhalb ihres thematischen Bereichs für Einheitlichkeit.
  • Klassendefinitionen in der Gesamt-Seite sind aus guten Gründen auf Admin-Rechte begrenzt.
• Das Projekt ist demokratisch organisiert, und jedes Fachgebiet hat das Recht, sich seine Infoboxen nach eigenen Ideen zu gestalten und zu programmieren.
  • Für Navileisten bieten wir Vorlage:Navigationsleiste als Basisfunktionalität an (mehr als eine halbe Milluion Einbindungen); freiwillig gäbe es seit 2006 auch Vorlage:Infobox – wird aber kaum benutzt, und es gibt hier keinen Oberhochschullehrer, der die Fachgebiete dazu zwingen könnte oder davon abhalten könnte, sich ihre Infoboxen so zu programmieren, wie sie das möchten.
  • Die Benutzer und gar die gefürchteten Haupt- und Erstautoren sind sehr frei, Artikel und andere Seiten so zu gestalten und zu formatieren, wie sie das für richtig halten, und werden sich von Martin K. sicher keine responsiven Vorschriften machen lassen. Nicht wenige lehnen sogar Vorlagen und Technik völlig ab.
• In den Kinderjahren der WP wurden einige Fehler gemacht.
  • Einer der Fehler war gewesen, für einzelne Vorlagen und für einzelne Themengebiete Klassendefinitionen anzubieten, statt auf Inline-Styles zu verweisen, die von den Benutzern in den Themengebieten selbst verwaltet werden könen.
  • Woraufhin die Stildefinitionen einfach frech für völlig andere Zwecke missbraucht wurden; siehe ein Abschnitt tiefer.
  • Weshalb man eine einmal definierte Klasse praktisch nie wieder los wird, und die Admins bei der Betreuung des umseitigen CSS dann allen verwendenden Seiten hinterherrennen sollen? Oder wer soll das deiner Meinung nach alles pflegen? Oder jede einmal definierte Klasse solle in alle Ewigkeit weitergepflegt werden, und immer neue dazukommen?
  • Die Hauptseite ist auch so ein Fehler gewesen, und der ganze Block ist sicher allererster Kandidat für eine 1:1-Auslagerung in die neue seitenpezifische Klassendefinition; bis dahin bleibt es beim Status quo und wird nicht verbastelt.
  • Es gibt wohl 10–11 Millionen Vorderseiten und wahrscheinlich 5 Millionen Diskussionsseiten und deren Archive, plus Spezialseitenaufrufe. Ein CSS, das mit einer Chance unter 1:15000000 einen Selektor trifft, ist einfach unwirtschaftlich und eine Frechheit gegenüber allen, die irgendeine der anderen Seiten lesen wollen.
• Lektionen haben wir gelernt:
  • Wir machen kein projektweites CSS mehr, das nur eine Handvoll Seiten treffen wird.
  • Wir machen keine Parallelentwicklungen mehr zu für alle Wikis weltweit verwendbares CSS.
  • Beispielsweise gibt es eine weltweit gepflegte und in allen Seiten verfügbare wikitable. Unsere sehr ähnliche aber doch nicht immer 1:1 kompatible prettytable ist seit einem Jahrzehnt veraltet, steckt aber immer noch in vielen Köpfen oller Wikipedianer drin, wird immer wieder neu verbaut und ist trotz aller Bemühungen immer noch in 10 % der Artikel mit formatierten Tabellen vorhanden.
  • Wir überlegen deshalb sehr sorgfältig, ob es wirklich unumgänglich ist, umseitig neue „‎Standardklassen“ zu definieren, die dann sonstwo verbaut werden und die wir auf Jahrzehnte nicht mehr loswerden und separat pflegen müssen; und ob das auch genügend viele Seiten erreichen würde. Insbesondere wenn bereits absehbar wäre, dass es mittelfristig eine wieder anders strukturierte MediaWiki-Lösung geben würde.
• Das umseitige CSS ist dazu da, die Angelegenheiten zu definieren, die deutschsprachig definitiv anders sind als in der weltweiten Wiki-Software; es wird nach und nach zurückgebaut und ist idealerweise eines Tages eine leere Seite.
• @Martin, MediaWiki
  • Wo ist eigentlich die Tasknummer deines Vorschlags?
  • Das müsste ja alle Webseiten betreffen, die im letzten Vierteljahrhundert erstellt wurden und auf einen hochauflösenden Bildschirm treffen. Ein Browser weiß, was für ein Bildschirm vorliegt; ist denn ausgeschlossen, dass Browser demnächst das aus eigenen Stücken angemessen darstellen werden? Sie kennen ja das Verhältnis von Schriftgröße zu Pixeln, und das wäre ja offenbar alles.

VG --PerfektesChaos MediaWiki Diskussion:Common.css#c-PerfektesChaos-2017-07-27T00:00:00.000Z-Standardklasse für responsive herunterskalierende Bilder11Beantworten

Vorab: Dir ist aber schon klar, dass Du hier im Endeffekt gegen das Paradigma der Trennung von Design und Inhalt und die Grundidee der Cascading Style Sheets an argumentierst? Falls ja: Ist Dir bewusst, dass Du mit der Ablehnung dieser Prinzipien unter denen, die sich professionell mit der Gestaltung und Programmierung von Websites beschäftigen, ziemlich allein auf weiter Flur stehen dürftest?

• Ich hatte das JavaScript, mit dem ich diese Zahlen ermittelt habe, oben gepostet. Falls da eine Denkfehler drin sein sollte (was natürlich nicht ausgeschlossen ist), sag mir bitte wo (Das wäre in jedem Fall redlicher als mir hier Manipulation zu unterstellen). Um meine User-Styles und irgendwelche Spezial-Scripte auszuschließen habe, ich die Seiten übrigens unangemeldet in einem aktuellen Firefox im Inkognito-Modus getestet, und zwar nachdem sie vollständig geladen waren.
  Ich glaube als jemand, der vorallem an den Vorlagen selbst arbeitet, unterschätzt Du massiv, wie oft hier gerade die kleineren Vorlagen und mit Inline-Styles versehenen Elemente eingesetzt werden.
• Dass Styles in einem Artikel benötigt werden, ist kein Argument für Inline-Styles. Selbst wenn sie (was bei Vorlagen-Styles praktisch nie vorkommt) nur in einem einzigen Artikel verwendet würden, könnte man das häufig mittels eines echten StyleSheets besser lösen.
• Gerade die Denkmallisten sind ein hervorragendes Beispiel für den Irrsinn von Inline-Styles und anderen Code-Redundanzen, weil optisch praktisch identische Element hunderte Male auf einer Seite eingefügt werden. Mit vernünftigen CSS wäre dass alles kein Problem, weil das Aussgehen genau einmal definiert würde, mit Inline-Styles hingegen wird das Aussehen mit jedem neuen Element erneut definiert. Und das ist nicht nur aus Bandbreiten- sondern auch aus Performance-Sicht absurd.
  Die Liste_der_Kulturdenkmale_in_Berlin-Kreuzberg ist da noch nicht mal besonders schlimm, weil sie nur auf Tabellen und nicht auf Vorlagen basiert. Aber auch hier wird z.B. {{Coordinate}} 371mal eingebunden. Und das erzeugt dann bei jedem einzelnen Eintrag für einen winzigen Button diesen Wusts hier:

<span id="Denkmal_09030459_.28Ensemble_Chamissoplatz.29" class="plainlinks-print" title="Koordinate"><span style="white-space: nowrap;"><span style="color: blue; padding: 0px 3px 0px 0px; cursor: pointer;" class="wmamapbutton noprint" title="Ort auf interaktiver Karte anzeigen" alt="">♁</span><a class="external text" href="//tools.wmflabs.org/geohack/geohack.php?pagename=Liste_der_Kulturdenkmale_in_Berlin-Kreuzberg&amp;language=de&amp;params=52.487803_N_13.391712_E_region:DE-BE_type:landmark_dim:500&amp;title=Denkmal+09030459+%28Ensemble+Chamissoplatz%29" style="white-space: normal;">Lage</a></span></span>

In einer Vorlagen basierenden Liste sieht das ganze noch viel schlimmer aus. Unter Liste der Kulturdenkmäler in Frankfurt-Altstadt z.B. komme ich auf 684 Style-Attribute mit 22.211 Styles und das obwohl die Liste sehr viel kürzer ist und {{Denkmalliste Hessen Tabellenzeile}} "nur" 104mal eingebunden wurde. Dummerweise ertzeugt aber jede dieser Einbettung für eine einzelne Zeile das hier:

<tr style="vertical-align:top;" class="vcard">
<td style="background-color:#eee; text-align:center; vertical-align:middle;"><a href="/wiki/Datei:Frankfurt_Am_Main-Berliner_Strasse_60_Kornmarkt_4_von_Suedwesten-20110615.jpg" class="image" title="Berliner Straße 60 / Kornmarkt 4, von Südwesten gesehen"><img alt="Berliner Straße 60 / Kornmarkt 4, von Südwesten gesehen" src="//upload.wikimedia.org/wikipedia/commons/thumb/3/3b/Frankfurt_Am_Main-Berliner_Strasse_60_Kornmarkt_4_von_Suedwesten-20110615.jpg/120px-Frankfurt_Am_Main-Berliner_Strasse_60_Kornmarkt_4_von_Suedwesten-20110615.jpg" srcset="//upload.wikimedia.org/wikipedia/commons/thumb/3/3b/Frankfurt_Am_Main-Berliner_Strasse_60_Kornmarkt_4_von_Suedwesten-20110615.jpg/180px-Frankfurt_Am_Main-Berliner_Strasse_60_Kornmarkt_4_von_Suedwesten-20110615.jpg 1.5x, //upload.wikimedia.org/wikipedia/commons/thumb/3/3b/Frankfurt_Am_Main-Berliner_Strasse_60_Kornmarkt_4_von_Suedwesten-20110615.jpg/240px-Frankfurt_Am_Main-Berliner_Strasse_60_Kornmarkt_4_von_Suedwesten-20110615.jpg 2x" data-file-width="4500" data-file-height="3000" width="120" height="80"></a><br>
<span id="Ehemaliges_Haus_Breslau"><span id="Anker:Ehemaliges_Haus_Breslau"></span></span><span id="Berliner_Stra.C3.9Fe.C2.A060.28.3D_Kornmarkt.C2.A04.29"><span id="Anker:Berliner_Stra.C3.9Fe.C2.A060.28.3D_Kornmarkt.C2.A04.29"></span></span></td>
<td>Ehemaliges Haus Breslau</td>
<td data-sort-value="Berliner Strasse 60(= Kornmarkt 4)"><a href="/wiki/Berliner_Stra%C3%9Fe_(Frankfurt_am_Main)" title="Berliner Straße (Frankfurt am Main)">Berliner Straße</a>&nbsp;60<br>
(= <a href="/wiki/Kornmarkt_(Frankfurt_am_Main)" title="Kornmarkt (Frankfurt am Main)">Kornmarkt</a>&nbsp;4)<br>
<span id="Ehemaliges_Haus_Breslau" class="plainlinks-print" title="Koordinate"><span style="white-space: nowrap;"><span style="color: blue; padding: 0px 3px 0px 0px; cursor: pointer;" class="wmamapbutton noprint" title="Ort auf interaktiver Karte anzeigen" alt="">♁</span><a class="external text" href="//tools.wmflabs.org/geohack/geohack.php?pagename=Liste_der_Kulturdenkm%C3%A4ler_in_Frankfurt-Altstadt&amp;language=de&amp;params=50.111444_N_8.679646_E_region:DE-HE_type:landmark&amp;title=Ehemaliges+Haus+Breslau" style="white-space: normal;">Lage</a></span></span></td>
<td><span id="Berliner_Strasse_060"><span id="Anker:Berliner_Strasse_060"></span></span>Büro- und Geschäftshaus an der neugeschaffenen Ost-West-Achse. Fassade durch Fensterbänder horizontal betont, zurückgesetztes Dachgeschoss.<sup id="cite_ref-Kaiser_2000-8_24-4" class="reference"><a href="#cite_note-Kaiser_2000-8-24">[24]</a></sup></td>
<td><span style="display:none" class="sortkey">1954!</span>1954<sup id="cite_ref-Kaiser_2000-8_24-5" class="reference"><a href="#cite_note-Kaiser_2000-8-24">[24]</a></sup></td>
</tr>

Dass der von Vorlagen generierte Code so ausladend ist, liegt natürlich nicht ausschließlich aber doch zu einem erheblichen Teil am exzessiven Inline-Style-Gebrauch. Und mMn käme es einer Realitätsleugung gleich, wenn man dieses offensichtliche Problem abstreiten würde.

• Ich sehe weder in der Liste der Naturschutzgebiete in Wien noch im Artikel Wien irgendwelche Kontext abhängigen Farben. Kann es sein, dass Du hier den Inhalt (namentlich das Bildmaterial) mit dem dem Layout durcheinander wirfst (s.o.)?
• Mal abgesehen davon, dass ich Inline-Styles gar nicht kategorisch ausschließen (das wäre unrealistisch) sondern nur so weit wie möglich eindämmen will, verwechselst Du auch beim Hamburger SV Inhalt und Layout. Das Aussehen der Trikot ist aus Gestalterischer Sicht ein Bild-Inhalt (auch wenn der hier aus diversen Einzelteilen zusammengebastelt wird), der so in genau einem Artikel zur Anwendung kommt. Das hat mit dem hiesigen Thema genauso wenig etwas zu tun, wie irgendwelche Diagramme oder SVGs.
• Ungeachtet der Tatsache, dass es mMn eh viel zu viele nicht unbedingt selbsterklärende Farbcodes in InfoBoxen gibt, wäre das Styling von Infoboxen über Themen, wie die Marine oder spanische Literatur wäre ein Anwendungsfall für die von Raymond verlinkte Style-Extension (wenn die denn mal kommt).
• Habe ich gefordert hier für Hunderte Farben Klassen anzulegen? Nein, das habe ich nicht! Mir geht es hier um Standardklassen für Standardanwendungsfälle. Also genau das, was in üblichen CSS-Frameworks auch definiert wird.
• Die Behauptung, ich wolle hier alles in der Commons.css regeln, ist nichts weiter als eine Strohmannargument. Das habe ich nirgendwo gefordert.
• Es gibt nur sehr wenige Fälle in denen Stile wirklich nur auf exakt einer Seite und dort auch nur exakt einmal angewendet werden. Gerade für Vorlagen trifft dies nie zu.
• Wenn Du wirklich meinst, dass es mir darum ging die Inline-Styles 1:1 gegen eine Klasse auszutauschen, hast Du scheinbar das Konzept der Trennung von Code und Design nicht verstanden. Natürlich ist es sinnlos in hunderten Tabellenzellen statt style="text-align:center" class="table-cell-centered". Sinn voll wäre es, der Tabelle eine Klasse zu geben, über der sie dann die wesentlichen Formatierung für alle Zeilen und Zellen einmal vernünftig definiert würden:

table.type-a>tr>td{
    padding: .5em 1em;
}
table.type-a>tr>td:firstchild{
    text-align: center;
}
table.type-a>tr:nth-child(2n){
    background-color:#F0F0F0;
}

Das was Du als „robust bezeichnest“ würden andere „unwartbar“ nennen. Wie Du im Thread eins weiter unten siehst, ist es ziemlich einfach, herauszufinden wo eine bestimmte Klasse überall verwendet wird. Entsprechend einfach liesen sich Fehler aufspüren und ggf. mit einem Bot-Lauf diese Klasse gegen eine andere austauschen.
Bei Inline-Styles ist das nicht so einfach möglich. Wenn man hier merkt, dass eine bestimmte Formatierungsart in einem Rendering die komplette Seite zerschießt, dann reicht es nicht das einmal irgendwo zentral zu ändern, dann kann man nichtmal mit einer einfachen Suche herausfinden, wo überall das Problem auftritt. Dann muss man mühsam durch tausende Seiten gehen, in den Einzel-Anweisungen stehen, die irgendwas damit zu tun haben könnten, um diese dann jeweils einzeln zu debuggen. Und da darauf keiner Lust hat, bleiben die Fehler halt drin und/oder werden von denjenigen, die die mobile Ansicht verantworten mit wüsten !importants überschrieben. Oder was glaubst Du, warum im Minerva CSS ganze 53mal !important steht?!

• Wie gesagt, die Behauptung, ich wolle alles in ein CSS stecken ist ein Strohmann!
• Die einfachen Benutzer die für Ihren Bereich eine Vorlage erstellen, erledigen das mangels Alternativen i.d.R. via Copy'n'Paste aus irgendeiner Vorlage, die so ähnlich aussieht. Und wenn wenn da Inline-Style-Murks drin steht, dann nehmen sie diesen Murks und kleben noch etwas mehr Murks dran, damit es irgendwie so aussieht, wie sie das gerne hätten. Wenn in den der kopierten Vorlage aber Klassen verwendet würden, und es irgendwo auch noch eine Vernünftige Doku zu diesen Klassen und einen CSS-Baukasten gäbe aus dem man sich einfach bedienen könnte, dann würden diese Nutzer auch das einfach kopieren und einsetzen.
  Dass es hier so viel Inline-Styles angesetzt werden, liegt mEn vor allem daran, dass es hier schon so viele Inline-Styles gibt und vernünftige Alternativen für den Otto-Normal-Autor nicht auffindbar sind.
• Natürlich wurden in den Kinder Jahren der WP viele Fehler gemacht:
  • Aber die Behauptung, es wäre besser gewesen sofort zu 100% auf InlineStyles, wird jedem, der sich auch nur ansatzweise mit Frontend-Entwicklung beschäftigt, zum Kopfschütteln und Lachen bringen. Das ist schlicht wirdersinnig.
  • Ich haben keine Ahnung, wie das mit der Vergabe von Klassennamen damals ablief, aber offensichtlich nicht so, wie es eigentlich sein sollte.
  • In einer idealen Welt hätte man in der Wikipedia von Anfang an Design und Inhalt strickt von einander getrennt und einen vernünftigen Prozess für die Erstellung neuer Content-Module etabliert. Das hätte nicht nru den Autoren erhebliche Mengen für sie unsinniger Arbeit abgenommen, sondern auch sicher gestellt, dass sich das Interface dieser Enzyklopädie über die Jahre kontinuierlich weiterentwickelt und qualitativ verbessert hätte.
    So wie es heute ist, leben die Autoren in der Wahnvorstellung, sie würden das Aussehen der Artikel maßgeblich festlegen und übersehen dabei, dass das was sie auf ihrem Desktop-Monitor sehen nicht mal die halbe Wahrheit ist. Nicht nur, das die mobile Version heute oft mehr Leser hat als die Desktop-Version und die Inhalte mit gestrippten Inline-Styles auch auf zig anderen Plattformen verwurstet werden, auch der Vector-Skin läuft auch auf unterschiedlichen Viewport-Größen nun mal unterschiedlich (von Monobook ganz zu schweigen). Und deshalb haben die Bebilderungs- und Designdiskussionen bei denen verschieden Autoren jeweils auf Basis der Ansicht auf ihrem Computer argumentieren etwas von absurdem Theater: Das ist wie in der Geschichte mit den Blinden und dem Elefanten.
  • Lass einfach mal die Strohmänner weg!
• Gilt das nicht für alles andere, was da umseitig steht genauso. Mal abgesehen von Hauptseiten CSS entdecke ich da jedenfalls kaum einen Style, der nicht theoretisch auch in anderen Wikipedia-Sprachversionen angewandt werden könnte.
• Zu „@Martin, MediaWiki“ worauf auch immer sich das beziehen würde:
  • Ich habe diverse Technische Wünsche eingereicht (die Du z.T. auch kommentiert hast) und verschiedentlich mit den zugehörigen Stellen in der WMF und bei WMDE darüber gesprochen. Um das ganze in Phabricator als Projekt in Phabricator anzulegen und mühseelig über Jahre und Monate voranzudrücken fehlt mir leider die Zeit – ich mach das hier nämlich nicht hauptamtlich.
    Zumal solche Top-Down-Lösungen hier doch eh immer wieder auf Widerstand stoßen. Denk nur mal an die letzten „Innovationen“ der WMF, vom VisualsEditor über dem MediaViewer bis hin zu sowas lächerlich kleinem wie dem Typographic-Refresh! Leider gibt es in diesem Projekt einen unglaublichen Strukturkonservatismus was die Technik angeht. Statt darüber nachzudenken, wie man sie sinnvoll implementieren und gewinnbringend einsetzen könnte. Werden Neuerungen fast immer reflexartig abgeblockt (und auch diese Diskussion ist leider ein Beispiel dafür).
    Und deshalb bin ich der Überzeugung, dass man solche Dinge hier besser im Bottom-Up-Verfahren einführt: Nämlich in dem man sinnvolle Angebote machte, deren Nutzung den Autoren reale Vorteile bringt und so idealerweise eine Sogwirkung erzeugt, die dann irgendwann zu einer projektweiten Anpassung führt.
  • Dass Browser alle Styles strippen und die Website einfach so anzeigen, wie sie sie für lesbar halten gibt es bereits: Es nennt sich Lesemodus. Aus Sicht des Website-Anbieters ist das aber nichts anders eine Bankrotterklärung, weil es letztlich nichts anderes heißt, als dass man selbst unfähig, ist eine funktionale und lesbare Nutzeroberfläche zur Verfügung zu stellen. Dass Vector sich seit seiner Einführung kaum nennenswert weiterenwickelt ist sicher auch einer der Gründe dafür, dass der Desktop-Version die Leser (und damit die potentiellen Autoren) weglaufen.

Es wäre daher schön, wenn Du Deine Fundamentalopposition gegen jede klassenbasierende Stylvereinheitlichung mal überdenken könntest. // Martin K. (Diskussion) MediaWiki Diskussion:Common.css#c-Martin Kraft-2017-07-27T09:13:00.000Z-PerfektesChaos-2017-07-27T00:00:00.000Z11Beantworten

@Martin Kraft: Da hier schon diverse Leute Contra gegeben haben, vermutlich weil sie sich nicht vorstellen können, wo das Problem genau liegt (ich übrigens auch nicht), wäre es klasse, wenn du Screenshots mit vorher/nachher zur Verfügung stellen könntest.

Und zur allgemeinen Info: Phab:T133410 für das Deployment der TemplateStyles-Extension. Sieht glaube ich gar nicht so schlecht aus, das noch dieses Jahr zu bekommen. — Raymond ^Disk. MediaWiki Diskussion:Common.css#c-Raymond-2017-07-27T10:24:00.000Z-Standardklasse für responsive herunterskalierende Bilder11Beantworten

Grundsätzlich betrifft das Problem jede Info-Box, Tabelle oder Box, die fluide wäre, wenn sie nicht ein Bild mit fester Größe enthalten würde. Dieses sorgt dann dafür, dass entweder der ganze Container aus der Seite oder über andere Dinge drüberragt und/oder gleich samt seinem Textinhalt abgeschnitten wird.

Das Problem ist deshalb nicht so offensichtlich, weil es meistens dadurch umgangen wird, dass nur anachronistisch winzig Bilder eingesetzt werden, weil größere bei kleineren Auflösung eben mangels Skalierbarkeit das Layout zerlegen würden.

Um das zu sehen musst einfach nur mal irgendeinen Seite auf machen in der breite Bilder und Tabellen eingebunden sind und dann Dein Browserfenster schmal (<800px) ziehen. Im Firefox kann manmit Str-M einen Modus öffenen in dem sich das gut simulieren lässt:

• Auslöser war der Artikel Sonnensystem in diesem Zustand
• Weitere auf die schnelle gefundene Beispiele wären: Wikipedia:Wiki_Loves_Monuments_2016/Deutschland/Preisträger 8die großen Bilder), Alpenvereinseinteilung der Ostalpen (die Karte)

// 12:58, 27. Jul. 2017 (CEST)

@Martin Kraft: Sorry, das hilft mir nicht weiter. Wie sähe es denn mit deiner Lösung aus? Ohne konkrete Screenshots vorher/nachher kommen wir hier nicht weiter, fürchte ich. — Raymond ^Disk. MediaWiki Diskussion:Common.css#c-Raymond-2017-07-27T11:05:00.000Z-Raymond-2017-07-27T10:24:00.000Z11Beantworten

Also gut, hier ein Screenshot der alten Version des Artikels Sonnensystem. Oben, so murksig wie war (man beachte das "Das"), und unten, wie genau dieselbe Infobox aussähe, wenn man das Bild mit Hilfe der hiesigen Klasse fluide gemacht hätte. In einem breiten Viewport sähen beide Versionen identisch aus.

Damit keine Missverständnisse aufkommen: Es geht hier nicht um einen HotFix für irgendwelche existierenden Detail-Probleme (die sind im fraglichen Artikel durch eine fixe Verkleinerung des Bildes mittlerweile behoben). Es geht um einen Standard-Klasse, die es uns erlauben würde zukünftig in diversen Vorlagen mit fluide skalierenden Bildern zu arbeiten und es so ermöglicht, Bildmaterial ganz anders einzusetzen, ohne dabei in Gefahr zu laufen die Seite auf kleineren Auflösungen zu zerstören. // Martin K. (Diskussion) MediaWiki Diskussion:Common.css#c-Martin Kraft-2017-07-27T11:36:00.000Z-Standardklasse für responsive herunterskalierende Bilder11Beantworten

Vielen Dank Martin, das macht die Problematik und die mögliche Lösung doch gleich für alle viel deutlicher :-) — Raymond ^Disk. MediaWiki Diskussion:Common.css#c-Raymond-2017-07-27T11:57:00.000Z-Martin Kraft-2017-07-27T11:36:00.000Z11Beantworten

@Raymond: Hast Du die TemplateStyles schon in irgendeinem Wiki zu Laufen bekommen.

Mein TestWiki wirft zwar keinen Fehler, aber es verarbeitet leider auch die Tags nicht korrekt. Statt einfach den Style anzuwenden steht da bloß "Vorlagenspezifisches Stylesheet:" und ein leerer grauer Kasten. Was für mich so aussieht, als würde er versuchen einfach die WikiSeite mit dem CSS-Code einzubetten.

Nun hab ich zugegebenermaßer auch "nur" MediaWiki 1.28.2 laufen. Aber das ist immerhin die jüngste stabile Version. Und wenn die jetzt darüber nachdenken, dass in die Wikimedia Wikis ausszurollen, sollte man das da doch zumindest mal testen können, oder? // Martin K. (Diskussion) MediaWiki Diskussion:Common.css#c-Martin Kraft-2017-07-27T13:00:00.000Z-Martin Kraft-2017-07-27T11:36:00.000Z11Beantworten

@Martin Kraft: Auf die Schnelle mal in meinem lokalen Testwiki, allerdings im Master, also 1.30alpha, getestet. Funktioniert. — Raymond ^Disk. MediaWiki Diskussion:Common.css#c-Raymond-2017-07-27T14:44:00.000Z-Martin Kraft-2017-07-27T13:00:00.000Z11Beantworten

Dann liegt's an der Version. Ist diese 1.30alpha so stabil, dass man damit vernünftig testen kann und kann man die einfach über die bestehende Installatipon drüberladen oder hat sich da was an der Datenbank geändert? // Martin K. (Diskussion) MediaWiki Diskussion:Common.css#c-Martin Kraft-2017-07-27T14:57:00.000Z-Raymond-2017-07-27T14:44:00.000Z11Beantworten

Bin gerade auf dem Sprung: Lass uns doch gemeinsam im Beta-Testwiki testen. Schau dir mal an:

https://de.wikipedia.beta.wmflabs.org/wiki/Vorlage:Test

https://de.wikipedia.beta.wmflabs.org/wiki/Vorlage:Test/style.css

https://de.wikipedia.beta.wmflabs.org/wiki/Benutzer:Raymond

Du darfst gerne an allen Seiten, auch meiner Benutzerseite dort, herumexperimentieren. — Raymond ^Disk. MediaWiki Diskussion:Common.css#c-Raymond-2017-07-27T15:17:00.000Z-Martin Kraft-2017-07-27T14:57:00.000Z11Beantworten

Danke - sieht wirklich vielversprechend aus. Wäre ein Traum, wenn das live ginge bevor die diesjährige WEM-Kampagne startet.

Auch wenn es den hiesigen Vorschlag nicht obsolet macht. Bei wirklich regelmäßig verwendete Features macht eine globale Definition nämlich immer noch mehr Sinn, als es zig mal in irgendwelchen Vorlagen-Stylesheets zu definieren. // Martin K. (Diskussion) MediaWiki Diskussion:Common.css#c-Martin Kraft-2017-07-27T16:35:00.000Z-Raymond-2017-07-27T15:17:00.000Z11Beantworten

Drei Punkte:

1. MediaWiki master (1.30alpha): Im Prinzip läuft Wikipedia & Co damit. Jede Woche wird ein wmf-Branch vom Master erstellt und phasenweise auf die Wikis ausgerollt. Am einfachsten ist es, wenn du ein Testwiki dir einrichtest und das via Git mit dem Code befüllst. Dann ich es eine Frage von Sekunden, die Installation upzudaten. Datenbankupdates sind zwischen der 1.28 und 1.30alpha wahrscheinlich, jetzt aber nicht geprüft.

2. Inhaltlich kann ich selber nicht beurteilen, ob dein CSS-Code richtig ist. Da müssen Experten ran.

3. Lass uns das ganze auf https://de.wikipedia.beta.wmflabs.org testen. — Raymond ^Disk. MediaWiki Diskussion:Common.css#c-Raymond-2017-07-27T19:53:00.000Z-Martin Kraft-2017-07-27T16:35:00.000Z11Beantworten

Verstehe nicht ganz: Was genau möchtest Du da testen?

Die Ergänzung der commons.css (die darf ich auch da nicht editieren) und die Einbindung in die Artikel? Oder eine Simulation des selbigen mittels der neuen Extension?

Hast Du da Adminrechte und könntest mir die oben genannten Artikel darüber importieren? // Martin K. (Diskussion) MediaWiki Diskussion:Common.css#c-Martin Kraft-2017-07-27T21:00:00.000Z-Raymond-2017-07-27T19:53:00.000Z11Beantworten

Ich dachte an eine Simulation des selbigen mitteils der neuen Extension. Gerade eben getestet: Es können in einer Vorlage mehrere TemplateStyles eingebunden werden: https://de.wikipedia.beta.wmflabs.org/w/index.php?title=Vorlage:Test&diff=20565&oldid=20554 . D.h. Styling für *alle* Infoboxen kann in https://de.wikipedia.beta.wmflabs.org/wiki/Vorlage:Test/fluid.css definiert werden und Styling nur für bestimmte Infoboxen kann jeweils separat definiert werden. Dadurch verringert sich der Pflegeaufwand, wenn man das zentrale Styling für alle Infoboxen anpassen muss/möchte. Und die Common.css bleibt von vielem verschont. Admin bin ich dort, kann gerne morgen was rüberkopieren. — Raymond ^Disk. MediaWiki Diskussion:Common.css#c-Raymond-2017-07-27T21:43:00.000Z-Martin Kraft-2017-07-27T21:00:00.000Z11Beantworten

• @Statistische Angaben zu Bytes:
  • Es wurde 00:02, 27. Jul. 2017 mit der Länge von Inline-Style-Werten argumentiert.
  • Dabei wurde suggeriert, dass all diese Inline-Style-Angaben den Code aufblähen würden, und man dies durch die Verwendung projektweiter Klassendefinitionen einsparen könnne.
  • Ich hatte dir bereits dargelegt, dass derartige Klassendefinitionen mitnichten erwas einsparen, sondern nur Unmengen an Klassendefinitionen in jeder Seite bereitstellen müssen, und die Sache nur unendlich verkomplizieren.
  • Nun gut, nehmen wir mal Grasshopper Club Zürich und als Teilmenge der Vereinsfarben die Farben der Trikots.

• Jedes Kleinkind wird kapieren, dass der Klassenselektor länger ist als der Inline-Style; bei sonst gleicher Wirkung.
• Der wiedergegebene JS-Code zählt nur die Werte, also links immer 18 Bytes, der Klassenbezeichner hat um 30 Bytes.
• Es wird vorgetäuscht, die Kennzeichnung der Elemente mit Inline-Style würde Bytes kosten, wenn man dafür hingegen Klassenbezeichner verwenden würde, könne man all das einsparen und käme mit Null Bytes heraus.
• Tatsächlich muss aber jedes einzelne Element mit einem eindeutigen Selektor versehen werden, und er ist bald doppelt so lang wie das Inline-Style. Hinzu kommt, dass irgendwo noch die Zuordnung von ID und Stildefinition erfolgen muss.
• Den Aufwand für die eigene Idee mit Null Bytes darzustellen, aber den Inline-Styles angeblichen Mehraufwand zuzurechnen, ist unredlich.
• In den fraglichen Seiten tauchen vorwiegend minimale typografische Zuweisungen auf, namentlich in Tabellenzellen style="text-align:right" etc. – diese jeweils zu ersetzen durch class="table-cell-align-right" macht es weder kürzer noch übersichtlicher, sondern erfordert nur die langjährige/ewige Pflege und Bereitstellung eines welt- oder projektweiten Klassenbezeichners table-cell-align-right.
• Zusammenfassend: Die Auswertung war hochgradig manipulativ.

• <templatestyles src="Foo/style.css" />
  • Das wird mitnichten zukünftig der Notwendigkeit entheben, projektweit eindeutige konfliktfreie Klassenbezeichner zu koordinieren.
  • In derselben darzustellenden Zielseite können mehrere solche Vorlagen (oder gar direkte Element-Einbindungen) auftreten. Werden in diiesen die gleichen Klassenbezeichner mit unterschiedlichen Zuweisungen verwendet, dann obsiegt (kaskadierend) derjenige, der zuletzt eingebunden wurde, also mutmaßlich die im Wikitext zuletzt auftretende Anforderung.
  • Vieeel Spaß schonmal.
• Definiere es nur an einem Ort
  • Das ist der Hintergrund von „Trennung von Design und Inhalt“, und wenn das once-only-Paradigma erfüllt ist, dann ist es automatisch auch die „Trennung von Design und Inhalt“.
  • Das machen wir aber schon seit ewig; oder versuchen es weitgehend durchzusetzen.
  • Überleg dir mal, was Vorlage:Wahldiagramm/Partei/DE oder Vorlage:Hilfe/style wohl machen. Inline, aber das langt völlig und bedarf keiner projektweiten Klassenschemata.
  • Ob das Ziel nun mit dem HTML-Attribut class= oder style= erreicht wird, ist völlig irrelevant und nur Gegenstand deiner verbohrten Verteufelungsideologie.
• Mit Please don't do this, unless you really have to! It is really bad for maintenance und deinen Unterstreichungen hast du höchstpersönlich die Inline-Styles verdammt; darauf antworte ich dir hier.
• Dein CSS-Code-Beispiel mit der Tabelle hinkt völlig.
  • Es geht von dem einen Spezialfall aus, in dem genau die erste Spalte vielleicht zentriert sein möge, die anderen aber unverändert bleiben. Für genau diesen einen bietest du eine Lösung an.
  • Wir haben aber eine enorme Viefalt von Tabellen; seien es Chartplatzierungen, Wahlergebnisse oder volkswirtschaftliche Daten, und die technischen Daten von Güterzuglokomotiven; mal quer und mal hochkant angeordnet.
  • Da ist dann die siebte Spalte zentriert, die achte linksbündig, die neunte rechtsbündig, die zehnte wieder anders.
  • Für jedes Schema jeder Tabelle willst du dann dein Klassensystem vorbereitet halten – ich repariere seit Jahren Tabellen in unserem ANR und weiß, dass du definitiv dein Klassensystem nicht in eine für Bearbeiter verständliche Form bringen wirst, die dann auch noch jedes ESC-Ergebnis abdecken würde. Es wird dir noch nicht einmal gelingen, alle Konfigurationen von momentan vorhandenen Tabellen zu versorgen; geschweige denn jede zukünftig noch hinzukommende.
  • Du kannst auch keinem Autor vermitteln, er dürfe für seine Inhalte nur die drei oder fünf Tabellenformate verwenden, die du erlaubst, weil du danach keine Lust mehr hattest, Klassenstile zu unterstützen; die zweitausend anderen erforderlichen Tabellenstrukturen sind dann verboten – oder müssten konventionell formatiert werden. Dann können wir aber auch gleich universell eine einheitliche Methode benutzen, die immer funktioniert und wo man sich nicht erst in irgendwelche abstrakten Systeme einarbeiten muss, um am Ende zu festzustellen, das es damit doch nicht geht.
  • Wenn wir Tabellen formatieren wollen, setzen wir übrigens gern Vorlagen ein, die dann nur noch die inhaltlichen Daten erhalten und diese dann (mit den von dir niedergemachten Inline-Styles) formatieren, größer oder kleiner, mittig oder rechtsbündig darstellen und Verlinkungen generieren: Kategorie:Vorlage:Tabellenformatierung‎ Du findest da auch viel Denkmallisten: Kategorie:Vorlage:Denkmaltabelle. Dass das längst nicht überall eingesetzt wird, weiß ich auch; es macht erstmal eine erhebliche geistige Investition erforderlich, um ein derartiges Schema konzeptionell für die eigene Thematik zu erarbeiten. Mit deinem Klassensystem wäre das noch weitaus komplizierter. Es ist für die Tabellenvorlagen absolut wurscht, ob die Programmierung der Vorlage direkt inline erfolgt oder über eine nochmal gesonderte Abstaktionsebene als Klasse. Das mit dem Inline kapiert aber jeder sofort; auch jeder spätere Bearbeiter, der das pflegen und warten muss – was bei einem abstrahierten Klassensystem für jede Vorlage nicht der Fall ist und die meisten, die sich mühsam in die Vorlagennanpassung reingefummelt hatten, rigoros vor die Tür setzt. (Nebenbei sind genau diese Vorlagen die Trennung von Inhalt und Design, mit Mehrwert bei Verlinkungen usw.)
• Deine ganzen Vorstellungen sind blanke Theoretisiererei und gehen weit am Horizont der Artikelautoren vorbei.
  • Die haben ein fachliches Interesse an ihrem Artikelthema und wollen eine möglichst einfache und verständliche und robuste Syntax haben; und haben keinerlei Lust, sich in irgendwelche Designphilosophien hineinzudenken. Du nennst das „einen unglaublichen Strukturkonservatismus was die Technik angeht“ – unsere Autoren sind aber Japanologen oder Chemiker oder Automechaniker und keine Web-Designer oder Informatik-Philosophen. Wenn du das immer noch nicht gerafft hast, ist es dein Pech.
  • Die Wikis sind typografisch und nicht semantisch orientiert. Theoetisch müsste auch jedes Fremdwort oder fremdsprachliche Sequenz mit lang= markiert werden, jeder Werktitel mit <cite> und dessen Parametern eingefasst werden, jedes Zitat statt in Anführungszeichen in <q> und mit dessen Parameter eingeschlossen werden. Das ist alles viel zu kompliziert – das Wiki beruht auf einer simplen, unmittelbar einsichtigen Syntax, und die Autoren und insbeondere die Newcomer stöhnen trotzdem, dass das alles viel viel zu kompliziert und zu schwierig wäre.
  • Und da obendrauf willst du noch deine Klassendefinitionssysteme draufsatteln, die dann projektweit zu koordinieren wären. Mit mir nur, wo unvermeidlich; genauso, wie wir Lua nur dort einsetzen, wo herkömmliche Vorlagenprogrammierung es nicht mehr sinnvoll liefern kann.
  • Nur rund ein Prozent der Zitationen ist per Vorlage formatiert; der ganze Rest handgeklöppelt in Elemantarsyntax. Das ist ein Zustand, den ich auch bedenklich finde, aber ich kann die Autoren nicht umfrittieren. Auf der aktuellen Kurierdisk kannst du nachlesen, dass es eine lautstarke kleine Minderheit gibt, die hier Vorlagen strikt ablehnt und alles in Basis-Typografie formatiert haben will; du könntest dir ja mal überlegen, was Normalautoren von deinen Theorien begreifen. Projektweit gäbe es grad mal eine Handvoll Leute, die deine Ideen nachvollziehen können, und die haben schon genug anderes zu tun und zu pflegen.
  • Zitat: Dass es hier "zigtausende unterschiedliche Formatierungen" gibt, ist mMn kein schützenswerter Zustand – du bist hier aber nicht in einer Firma, in der du als Arbeitgeber deinen ausgebildeten Mitarbeitern Anweisungen geben kannst, nach welchen Klassenbibliotheken sie was formatieren müssen, sondern in einem wilden Haufen, in dem seit anderthalb Jahrzehnten jeder Laie mit möglichst null Vorkenntnissen und Voraussetzungen drauflosschreiben kann, wie er mag. Was Zigtausende getan haben, und was erfolgreich zum Aufbau und zur Pflege von über zwei Millionen Artikeln geführt. Ansonsten gibt es hier keinen Style Guide, keine Vorschriften und Vorgaben für nichts, und nur ein Hauch an Konventionen für die Gestaltungen und Formatierungen ist halbwegs anerkannt. Man kann sich noh nicht einmal darauf einigen, wie die Überschriften am Ende des Artikels heißen sollen und in welcher Reihenfolge sie zum Vorteil der Leser anzuordnen wären, und auch die WP:ZR werden teilweise nur widerstrebend beachtet, und es gibt immer noch ein Dutzend Einzelkämpfer, die sie ablehnen und es in „ihren“ Artikeln aber partout anders haben wollen. Gleiches gilt für die Entwicklung der Vorlagen, die sich etwa als Infoboxen zu Tausenden nach individuellen Vorstellungen und Vorkenntnnissen (bzw. mit Null Vorkenntnnissen) vieler Hunderter Beteiligter aus dem Nichts entwickelt hatten. Und dann kommt ein Dutzend Jahre später ein Hochschullehrer angedappelt und doziert was von sauberen CSS-Bibliotheken, an die sich alle von vornherein hätten halten müssen – du hast ersichtlich weder irgendwelche Ahnung von den Vorlagen (wie sich auch an deinem Editcount ablesen lässt) noch davon, wie das Projekt und die Leute hier ticken.
• Übrigens ist ein Klassensystem eine nette Sache für ein kleines, überschaubares Webprojekt, mit bis zu einem Dutzend gelernter Informatiker und Web-Designer, die es ausschließlich betreuen.
  • Ich war live dabei, als die Style Sheets in HTML.2 eingeführt wurden, hatte das als Erleichterung begrüßt, und sehe das als sehr sinnvollen Unterbau an.
  • Für ein Wiki aber eher nur dort, wo es um weltweit gepflegte technologische Basics geht.
  • Ach ja, duu bist uns immer noch die Tasknummer deines Vorschlags bei MediaWiki schuldig geblieben.
• Das Übrige ist bereits beantwortet; lies es nach.
• Es steht dir frei, uns eine Neuprogrammierung von Vorlage:Coordinate vorzustellen und <span style="white-space: nowrap;"> usw. durch <span class="template-Coordinate-link-wmflabs-tools-geohack"> zu ersetzen, wenn du meinst, dass das die Welt verbessert.
  • Wobei da heute schon lauter class= drinstehen.
  • Du erwartest aber hoffentlich nicht, dass unsere Admins diese Klassendefintion jetzt umseitig aufnehmen, die nächste Ewigkeit pflegen und in sämtliche >15 Millionen Seiten einspeisen, obwohl die Vorlage in „nur“ etwas über einer halben Million vorkommt.
    
    Einschub @PerfektesChaos: Die Funktionsweise eines Browser-Caches ist Dir aber schon geläufig, oder? Es ist völlig egal ob diese Datei hier 10 oder 15 Millionen-Mal eingebunden ist, so lange sie pro Nutzer nur einmal geladen wird und dann im Cache liegt. Es ist aber nicht egal, wenn das, was hier ein einziges mal stehen könnten, immer wieder inline in 10 Millionen unterschiedlichen HTML-Dateien ausgeliefert wird! // Martin K. (Diskussion) MediaWiki Diskussion:Common.css#c-Martin Kraft-2017-07-28T11:03:00.000Z-Martin Kraft-2017-07-27T11:36:00.000Z11Beantworten
  • Allerdings haben wir mit dieser Vorlage völlig andere Probleme und werden in den nächsten Jahren noch Riesenärger damit bekommen, wogegen deine Linkdekorationssorgen absolut lächerlich sind.
• Im Übrigen wiederhole ich es gern: Keine deutschsprachigen Sonderwege für weltweite Basis-Technologie, die du uns hier mal kurz mit großem Getöse vor den Latz knallst, und dann jetzt schon ankündigst, dich vom Acker zu machen und uns deine Ruinen hier zur Wartung und Pflege zu hinterlassen, und dann sollen wir noch an deiner Stelle bei MediaWiki das für dich „im Bottom-Up-Verfahren einführen“. Das kannst du hübsch alleine machen. Unsere Autoren werden von deiner Glanzleistung herzlich wenig mitbekommen (es scheint auch noch nie auf FZW oder sonstwo jemandem aufgefallen zu sein, aus TWS ist nichts bekannt); wer keinen hochauflösenden Bildschirm hat und darauf im Vollbildmodus Wikiseiten anguckt (ich habe zwar erstere, mache aber nicht zweites) bemerkt keinerlei Unterschied. Wenn das so dringend benötigt würde, wie du es darstellst, dann würde MediaWiki ja sofort darauf anspringen und es mit Kusshand blitzefix entgegennehmen.

VG --PerfektesChaos MediaWiki Diskussion:Common.css#c-PerfektesChaos-2017-07-28T08:33:00.000Z-Standardklasse für responsive herunterskalierende Bilder11Beantworten

Vorab nur kurz:

@PerfektesChaos: Geht es Dir um eine sachliche Lösung, oder darum meinen Vorschlag mit unlauteren rethorischen Mitteln zu diskreditieren um ihn genauso plump auflaufen zu lassen wie den oben drüber?

Ich habe es oben wirklich schon x-mal geschrieben:
Es geht mir ausdrücklich NICHT darum, jeden Sch***ß in die common.css zu schreiben! Es geht um ein klar abgegrenztes Set von Standard-Styles, die so oft eingesetzt werden können, dass eine globale Definition Sinn macht. Es geht also um das, was in üblicherweise in einem CSS-Framework definiert wird!
Und es geht mir definitiv NICHT um diese albernen Fußball-Tricot-zusammenstückel-Codes.

Kannst Du also bitte damit aufhören, hier einen Strohmann nachdem anderen aufzubauen, und zu einer sachlichen lösungsorientierten Diskussion zurückfinden?! // Martin K. (Diskussion) MediaWiki Diskussion:Common.css#c-Martin Kraft-2017-07-28T09:03:00.000Z-PerfektesChaos-2017-07-28T08:33:00.000Z11Beantworten

P.S.: Dass Du hier wiederholt einzelne Inline-Style-Zuweisungen mit einzelnen Klassenzuweisungen vergleichst, belegt nur, dass dass Du entweder die Grundidee von Cascading Stylesheets nicht verstanden hast, oder Dich absichtlich dumm stellst, weil Du überhaupt keine Interesse an eine zielorientierten Lösung hast. Ich bin mittlerweile echt genervt von Deiner destruktiven Diskussionsweise, die im Endeffekt nichts anderes ist als die kindische Verteidigung Deiner Hauptautorenschaft an der umseitigen CSS-Datei.

Ich verbringe einen nicht unerheblichen Teil meines Arbeitslebens damit CSS zu programmieren und CSS-Zuweisungen, die so trivial sind, wir die von denen Du da oben ausgehst, kommen nur sehr, sehr selten vor:

.eine-einzelne-klasse{
    eine-einzelne-eigenschaft: $ein-wert;
}

Um ein vielfaches häufiger gibt es sowas hier:

.eine-klasse{
    eigenschaftA: $wert-1;
    eigenschaftB: $wert-2;
    eigenschaftC: $wert-3;
    eigenschaftD: $wert-4;
}
.eine-klasse > a{
    eigenschaftC: $wert-5;
    eigenschaftD: $wert-6;
}
.eine-klasse > a ::after{
    content: " »"
    eigenschaftC: $wert-5;
    eigenschaftD: $wert-6;
}

Und das ist weder kürzer noch überhaupt mit einem Inline-Style zu bewerkstelligen.

Machen wir doch einfach mal einen Test - versuchen wir es mal konstruktiv:

<div style="dein css">[[Datei:Solar_system_scale_2_wide.jpg|frameless|hochkant=8]]</div>

Wie würdest Du denn mit Deinen tollen Inline-Styles das Problem lösen, dass dieses Bild hier bei geringeren Auflösungen über den Seitenrand ragt ohne dass es auf allen Auflösungen dieselbe kleine Größe hat, die auf der kleinsten Auflösung gerade noch so ins Fenster passt. Ich bin gespannt auf Deine Lösung! // 11:23, 28. Jul. 2017 (CEST)

Da es hier scheinbar ein paar Missverständisse im Bezug auf Styledeklarationen, CSS-Frameworks und sinnvolles Kaskadieren gibt, hier mal ein Beispiel, wie man die von PerfektesChaos beschrieben Tabellen-Ausrichtungsprobleme lösen könnte, ohne für jede Tabelle einen Spezialfall anzulegen oder den Code in für Laien nur schwer wartbarem Inline-Styles zu spicken.

In einem CSS-Framework würde man das so lösen, in dem man ein einziges Mal global die folgende Klassensammlung anlegt:

table.cell-center td{ text-align:center; }
table.cell-right td{ text-align:right; }
table.cell-left td{ text-align:left; }

table.col-1-center td:nth-of-type(1){ text-align:center; }
table.col-1-right td:nth-of-type(1){ text-align:right; }
table.col-1-left td:nth-of-type(1){ text-align:left; }

table.col-2-center td:nth-of-type(2){ text-align:center; }
table.col-2-right td:nth-of-type(2){ text-align:right; }
table.col-2-left td:nth-of-type(2){ text-align:left; }

/* usw. bis zur maximal angenommen Anzahl von Tabellen-Spalten */

Und das würde es einem erlauben in allen einfachen Tabellen einen Wikitext/Inline-Style-Mischmasch wie diesen hier, in dem in z.T. hunderten Zeilen identische Style-Anweisungen stehen,...

{| class="wikitable"
|-
| style="text-align:right"| Some Content
| style="text-align:left"| Some Content
| style="text-align:right"| Some Content
| style="text-align:center"| Some Content
| style="text-align:right"| Some Content
| style="text-align:right"| Some Content
|-
| style="text-align:right"| Some Content
| style="text-align:left"| Some Content
| style="text-align:right"| Some Content
| style="text-align:center"| Some Content
| style="text-align:right"| Some Content
| style="text-align:right"| Some Content
|-
| style="text-align:right"| Some Content
| style="text-align:left"| Some Content
| style="text-align:right"| Some Content
| style="text-align:center"| Some Content
| style="text-align:right"| Some Content
| style="text-align:right"| Some Content
|-
| usw...
|}

...durch diesen deutlich kürzeren, besser lesbaren und vor allem einfach abänderbaren Code zu ersetzen:

{| class="wikitable cell-right col-2-left col-4-center"
|-
| Some Content
| Some Content
| Some Content
| Some Content
| Some Content
| Some Content
|-
| Some Content
| Some Content
| Some Content
| Some Content
| Some Content
| Some Content
|-
| Some Content
| Some Content
| Some Content
| Some Content
| Some Content
| Some Content
|-
| usw...
|}

Und der einzige Preis, den man dafür zahlen müsste, wäre es, diese absurde „Globale Styles sind grundsätzlich böse“-Haltung aufzugeben. // Martin K. (Diskussion) MediaWiki Diskussion:Common.css#c-Martin Kraft-2017-07-28T10:28:00.000Z-Eine Lösung für die Tabellen-Ausrichtungsprobleme11Beantworten

Aber das macht doch den Quelltext voll schlecht lesbar, weil dann kann man ja gar nicht mehr sich an den style-Attributen orientieren tun </sarcas> --nenntmichruhigip (Diskussion) MediaWiki Diskussion:Common.css#c-Nenntmichruhigip-2017-07-28T20:00:00.000Z-Martin Kraft-2017-07-28T10:28:00.000Z11Beantworten

Also hier mal ein konkreter Vorschlag für ein CSS-Framework zur horizontalen und vertikalen Spaltenausrichtung in Tabellen mit bis zu 16 Spalten (das sollte ja eigentlich für unsere Zwecke ausreichen):

/* Horizontale Ausrichtung */

table.cell-left tr>*,
table.col1-left tr>:nth-child(1),
table.col2-left tr>:nth-child(2),
table.col3-left tr>:nth-child(3),
table.col4-left tr>:nth-child(4), 
table.col5-left tr>:nth-child(5),
table.col6-left tr>:nth-child(6),
table.col7-left tr>:nth-child(7),
table.col8-left tr>:nth-child(8),
table.col9-left tr>:nth-child(9),
table.col10-left tr>:nth-child(10),
table.col11-left tr>:nth-child(11), 
table.col12-left tr>:nth-child(12),
table.col13-left tr>:nth-child(13),
table.col14-left tr>:nth-child(14), 
table.col15-left tr>:nth-child(15), 
table.col16-left tr>:nth-child(16) { 
    text-align:left; 
}

table.cell-center tr>*,
table.col1-center tr>:nth-child(1),
table.col2-center tr>:nth-child(2),
table.col3-center tr>:nth-child(3),
table.col4-center tr>:nth-child(4), 
table.col5-center tr>:nth-child(5),
table.col6-center tr>:nth-child(6),
table.col7-center tr>:nth-child(7),
table.col8-center tr>:nth-child(8),
table.col9-center tr>:nth-child(9),
table.col10-center tr>:nth-child(10),
table.col11-center tr>:nth-child(11), 
table.col12-center tr>:nth-child(12),
table.col13-center tr>:nth-child(13),
table.col14-center tr>:nth-child(14), 
table.col15-center tr>:nth-child(15), 
table.col16-center tr>:nth-child(16) { 
    text-align:center; 
}

table.cell-right tr>*,
table.col1-right tr>:nth-child(1),
table.col2-right tr>:nth-child(2),
table.col3-right tr>:nth-child(3),
table.col4-right tr>:nth-child(4), 
table.col5-right tr>:nth-child(5),
table.col6-right tr>:nth-child(6),
table.col7-right tr>:nth-child(7),
table.col8-right tr>:nth-child(8),
table.col9-right tr>:nth-child(9),
table.col10-right tr>:nth-child(10),
table.col11-right tr>:nth-child(11), 
table.col12-right tr>:nth-child(12),
table.col13-right tr>:nth-child(13),
table.col14-right tr>:nth-child(14), 
table.col15-right tr>:nth-child(15), 
table.col16-right tr>:nth-child(16) { 
    text-align:right; 
}

/* Verticale Ausrichtung */

table.cell-top tr>*,
table.col1-top tr>:nth-child(1),
table.col2-top tr>:nth-child(2),
table.col3-top tr>:nth-child(3),
table.col4-top tr>:nth-child(4), 
table.col5-top tr>:nth-child(5),
table.col6-top tr>:nth-child(6),
table.col7-top tr>:nth-child(7),
table.col8-top tr>:nth-child(8),
table.col9-top tr>:nth-child(9),
table.col10-top tr>:nth-child(10),
table.col11-top tr>:nth-child(11), 
table.col12-top tr>:nth-child(12),
table.col13-top tr>:nth-child(13),
table.col14-top tr>:nth-child(14), 
table.col15-top tr>:nth-child(15), 
table.col16-top tr>:nth-child(16) { 
    vertical-align: top; 
}
table.cell-middle tr>*,
table.col1-middle tr>:nth-child(1),
table.col2-middle tr>:nth-child(2),
table.col3-middle tr>:nth-child(3),
table.col4-middle tr>:nth-child(4), 
table.col5-middle tr>:nth-child(5),
table.col6-middle tr>:nth-child(6),
table.col7-middle tr>:nth-child(7),
table.col8-middle tr>:nth-child(8),
table.col9-middle tr>:nth-child(9),
table.col10-middle tr>:nth-child(10),
table.col11-middle tr>:nth-child(11), 
table.col12-middle tr>:nth-child(12),
table.col13-middle tr>:nth-child(13),
table.col14-middle tr>:nth-child(14), 
table.col15-middle tr>:nth-child(15), 
table.col16-middle tr>:nth-child(16) { 
    vertical-align: middle; 
}
table.cell-bottom tr>*,
table.col1-bottom tr>:nth-child(1),
table.col2-bottom tr>:nth-child(2),
table.col3-bottom tr>:nth-child(3),
table.col4-bottom tr>:nth-child(4), 
table.col5-bottom tr>:nth-child(5),
table.col6-bottom tr>:nth-child(6),
table.col7-bottom tr>:nth-child(7),
table.col8-bottom tr>:nth-child(8),
table.col9-bottom tr>:nth-child(9),
table.col10-bottom tr>:nth-child(10),
table.col11-bottom tr>:nth-child(11), 
table.col12-bottom tr>:nth-child(12),
table.col13-bottom tr>:nth-child(13),
table.col14-bottom tr>:nth-child(14), 
table.col15-bottom tr>:nth-child(15), 
table.col16-bottom tr>:nth-child(16) { 
    vertical-align: bottom; 
}