Quelltext der Seite MediaWiki Diskussion:Common.css/Archiv/2

{{Archiv}}

== Top-Alignment in Tabellenzellen ==

Hallo!

Für eine kleine aber lästige Alltagsaufgabe möchte eine Lösung im Commons.css vorschlagen. 

In der Praxis werden häufig Tabellen zum Layouten von Texten verwendet, z.B. bei den Hilfeseiten. Will man Fließtext an der oberen Zellbegrenzung ausrichten und nicht - wie standardmäßig - vertikal zentriert, dann ist man genötigt eine Menge <code>style</code>-Anweisungen zwischen die Tabelleninhalte zu streuen. Durch die Verwendung einer weiteren Klasse bliebe jedoch die Übersichtlicht im Tabelleninneren erhalten, ich würde hierfür <code>'''toptextcells'''</code> vorschlagen:

 /**
  * Tabellen, deren Zellinhalte an ihrer oberen Begrenzung ausgerichtet sind
  */
 .toptextcells td {
   vertical-align: top;
 }

Durch ihre Verwendung würde aus
{| style="background-color:transparent;"
! Tabellenquelltext
! Vorschau
|-
|
 <nowiki>{| class="wikitable"
| eins<br>zwei<br>drei<br>vier
| einzig
|}</nowiki>
|
{| class="wikitable"
| eins<br>zwei<br>drei<br>vier
| einzig
|}
|}
folgendes
{| style="background-color:transparent;"
! Tabellenquelltext
! Vorschau
|-
|
 <nowiki>{| class="wikitable </nowiki>'''toptextcells'''<nowiki>"
| eins<br>zwei<br>drei<br>vier
| einzig
|}</nowiki>
|
{| class="wikitable"
| style="vertical-align: top;" | eins<br>zwei<br>drei<br>vier
| style="vertical-align: top;" | einzig
|}
|}

Die Verwendung von <code>&lt;br&gt;</code> in den folgenden Beispielen ist etwas irreführend, wirklich wichtig wird die Formatierung, wenn man viel Fließtext in den Zellen hat.

Der '''Name''' <code>toptextcells</code> ist das Ergebnis ausführlicherer Überlegungen, ich hoffe damit nahe am Ziel angekommen zu sein, ihn absichtsbeschreibend (am Ort seiner Verwendung) und umlautfrei - in einfachem Englisch - zu gestalten und ihn so gut kombinierbar mit <code>wikitable</code> oder <code>sortable</code> zu machen. Sicherlich geht das auch noch besser.

Ich freue mich über Rückmeldungen. Grüße --[[Benutzer:Peu|Peu]] 09:48, 8. Jan. 2009 (CET)
: Ubrigens: Getestet und im Einsatz in eigenem Wiki mit Firefox 3 und IE 7 beide unter Windows, bzw. (bislang nur für mich sichtbar) mit meinem [[Benutzer:Peu/monobook.css|Benutzer-CSS]] hier:
{| class="wikitable toptextcells"
| eins<br>zwei<br>drei<br>vier
| einzig
|}
: Sollte es aufgenommen werden, würde ich die Hilfeseiten entsprechend ergänzen. Grüße --[[Benutzer:Peu|Peu]] 10:20, 15. Jan. 2009 (CET)

::Erscheint mir sinnvoll und valide, daher eingebaut. — [[Benutzer:Raymond|Raymond]] [[Benutzer Diskussion:Raymond|<sup>Disk.</sup>]] [[Benutzer:Raymond/Bewertung|<sup>Bew.</sup>]] 08:25, 16. Jan. 2009 (CET)
::: Danke! Teil 2 folgt (in Kürze) unter [[Hilfe:Tabellen]]. Grüße --[[Benutzer:Peu|Peu]] 12:51, 16. Jan. 2009 (CET)

:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Umherirrender|Der Umherirrende]] 17:16, 20. Mär. 2009 (CET)</small>

== Transparente Hintergründe für Tabellen außerhalb des Artikelnamensraum ==

Die Hintergrundfarbe von Seiten außerhalb des Artikelnamensraum werden bläulich eingefärbt. Bei einigen Tabellen ist der Hintergrund noch weiß, da diese standardmäßig nicht transparent sind, dort kann mit CSS-Definitionen nachgeholfen werden.
Weiße Hintergründe sind bei Versionsunterschiede und auf [[Spezial:Version]].
Es bietet sich an, dies bei dem nachfolgendem Block zu ergänzen:
<syntaxhighlight lang="css">
 /* Tabellenhintergründe transparent machen */
 /* Vor allem auf Spezialseiten, da diese eine andere Hintergrundfarbe haben. */
 /* Update 21. März 2008: Wurde mit [[rev:32269]] und [[rev:32270]] zentralisiert. */
 
 table.searchResultImage, table#mw-sitematrix-table, table.mw-specialpages-table,
 table.mw-listgrouprights-table, table.diff, table.TablePager_nav
  {
       background-color: transparent;
  }
</syntaxhighlight>
wird zu
<syntaxhighlight lang="css">
 /* Tabellenhintergründe transparent machen */
 /* Vor allem auf Spezialseiten, da diese eine andere Hintergrundfarbe haben. */
 /* Update 21. März 2008: Wurde mit [[rev:32269]] und [[rev:32270]] zentralisiert. */
 
 table.searchResultImage, table#mw-sitematrix-table, table.mw-specialpages-table,
 table.mw-listgrouprights-table, table.diff, td.diff-otitle, td.diff-ntitle, table.TablePager_nav,
 table#sv-software, table#sv-ext
  {
       background-color: transparent;
  }
</syntaxhighlight>

Vielen Dank. [[Benutzer:Umherirrender|Der Umherirrende]] 17:21, 20. Mär. 2009 (CET)

:Erl. — [[Benutzer:Raymond|Raymond]] [[Benutzer Diskussion:Raymond|<sup>Disk.</sup>]] [[Benutzer:Raymond/Bewertung|<sup>Bew.</sup>]] 10:04, 23. Mär. 2009 (CET)

::Danke. [[Benutzer:Umherirrender|Der Umherirrende]] 18:44, 23. Mär. 2009 (CET)
:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Umherirrender|Der Umherirrende]] 18:44, 23. Mär. 2009 (CET)</small>

== Sichtbare Zeilenzahl beim Upload ==
Hallo. Auf WP:FZW kam der Wunsch auf, die Höhe des Editfensters beim Upload zu vergrößern, so dass mehr als nur 6 Zeilen sichtbar sind. Da die Vorlage:Information bereits 9 Zeilen braucht, wären ca. 15 Zeilen wohl recht zweckmäßig. Dazu müsste man 

 #wpUploadDescription { height: 20em !important; } 

eintragen. Wäre das möglich ? <span class="signaturcaesium137">[[Benutzer:Cäsium137|Cäsium137]]&nbsp;[[Benutzer_Diskussion:Cäsium137|(D.)]]</span> 18:31, 17. Aug. 2009 (CEST)
:{{Pro}}. Bei meiner monobook.css war das <code>!important</code> übrigens nicht notwendig. --[[Benutzer:Leyo|Leyo]] 18:38, 17. Aug. 2009 (CEST)
*{{Pro}} gute Idee! --[[Benutzer:Ralf Roletschek|Marcela]] [[Bild:Miniauge.gif]]  18:45, 17. Aug. 2009 (CEST)

::Auf important sollte man in zentralen CSS versichten, da es die Überschreibbarkeit für die Benutzer verschlechert (diese müssten dann ebenfalls important nutzen). Ich würde sagen, man sollte nur die 9 Zeilen sichtbar machen, damit die Hochlader nicht in Versuchung kommen etwas darunter zu schreiben, was ja nicht nötig ist. --[[Benutzer:Umherirrender|Der Umherirrende]] 20:31, 17. Aug. 2009 (CEST)

!important Kann man weg lassen, aber nur 9 Zeilen sind nicht gut. Warum denn bevormunden ? Evtl. kommen noch EXIF-Angaben oder mehr als ein Lizenzbaustein hinein. Da muss man nicht nochmal editieren und gleich eine weitere Version der Seite erstellen. 

<small>(P.S. bitte keine Manipulation an meinen D-Beiträgen)</small> 

<span class="signaturcaesium137">[[Benutzer:Cäsium137|Cäsium137]]&nbsp;[[Benutzer_Diskussion:Cäsium137|(D.)]]</span> 20:39, 17. Aug. 2009 (CEST)
:Die Begrenzung auf eine sichtbare Fläche von 9 Zeilen soll ja nicht davon abhalten noch weitere hinzuzufügen. Meinetwegen auch 10, damit das hinzufügen einfacher ist.
:Entschuldigung. Ich sah deins als Kopiervorlage, die man verbessern kann. Administratoren kopieren auch gerne. --[[Benutzer:Umherirrender|Der Umherirrende]] 20:48, 17. Aug. 2009 (CEST)
::Man braucht den Platz darunter, um Lizenzbausteine einzubinden, die nicht in der Liste sind. --[[Benutzer:Ralf Roletschek|Marcela]] [[Bild:Miniauge.gif]]  20:53, 17. Aug. 2009 (CEST)

Dann schlage ich vor, wir fügen die Zeile 

 #wpUploadDescription { height: 20em;  } 

ein. Ok ? <span class="signaturcaesium137">[[Benutzer:Cäsium137|Cäsium137]]&nbsp;[[Benutzer_Diskussion:Cäsium137|(D.)]]</span> 00:15, 19. Aug. 2009 (CEST)
:[http://de.wikipedia.org/w/index.php?title=MediaWiki%3ACommon.css&diff=63876937&oldid=63289951 Done]. --[[Benutzer:Leyo|Leyo]] 20:21, 28. Aug. 2009 (CEST)

:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Umherirrender|Der Umherirrende]] 20:35, 28. Aug. 2009 (CEST)</small>



== Hintergrundfarben nach Übernahme von <code>wikitable</code> in core-css ==

Bei <code>wikitable</code> haben wir seit heute dunkle Titelzeilen, weil in http://de.wikipedia.org/skins-1.5/common/shared.css die Definition von [[:en:MediaWiki:Common.css]] übernommen wurde ([[rev:48842]]). Bei uns existieren daher nun die oben beschriebenen Probleme. Was tun? --[[Benutzer:Fomafix|Fomafix]] 12:47, 15. Jun. 2009 (CEST)

Hat diese CSS-Datei höhere oder niedrigere Priorität als die Common.css ? <span class="signaturcaesium137">[[Benutzer:Cäsium137|Cäsium137]]&nbsp;[[Benutzer_Diskussion:Cäsium137|(D.)]]</span> 23:48, 19. Jun. 2009 (CEST)
: Diese Datei wird nach den Dateien aus http://de.wikipedia.org/skins-1.5/common/ eingebunden. Dadurch lassen sich die Einstellungen von dort überschreiben. Ich habe das [http://de.wikipedia.org/w/index.php?title=Benutzer:Fomafix/monobook.css&diff=prev&oldid=61285993 ausprobiert]. Der IE6 versteht das so noch nicht. --[[Benutzer:Fomafix|Fomafix]] 00:05, 20. Jun. 2009 (CEST)

Die hier eingestellten H-Farben müssen '''ohne''' User-Anmeldung Lesbarkeit gewährleisten und möglichst neutral sein. <span class="signaturcaesium137">[[Benutzer:Cäsium137|Cäsium137]]&nbsp;[[Benutzer_Diskussion:Cäsium137|(D.)]]</span> 11:44, 6. Jul. 2009 (CEST)
: Die Farbe selbst ist nicht das Problem, da würde etwas dezent graues bevorzugen. <span style="border:1px solid black; background:#f2f2f2">#f2f2f2</span> ist neutral genug. Das Problem ist, dass jedes <code><nowiki><th></nowiki></code> jetzt immer diese Farbe hat, auch wenn die Tabelle oder die Zeile mit einer anderen Farbe belegt wurde. Selbstverständlich muss diese Definition daher genau in diese Datei, damit sie für alle Leser gleich gilt.
: Mit <code>table.wikitable tr.hintergrundfarbe6 th { background-color: #b3b7ff; }</code> könnte auch nachgeholfen werden. --[[Benutzer:Fomafix|Fomafix]] 12:54, 6. Jul. 2009 (CEST)
::Also müsste die Stelle
<syntaxhighlight lang="css">
 .hintergrundfarbe1 { /* Wie Inhaltsverzeichnis */
    background-color: #f9f9f9;
 }
 .hintergrundfarbe2 { /* "Weiß", für Nicht-Artikel-Seiten, neutral */
    background-color: #ffffff;
 }
 .hintergrundfarbe3 { /* "Gelb", auffällig */
    background-color: #ffff40;
 }
 .hintergrundfarbe4 { /* Sehr auffällig */
    background-color: #ffaa00;
 }
 .hintergrundfarbe5 { /* Neutral, abgesetzt */
    background-color: #e0e0e0;
 }
 .hintergrundfarbe6 { /* Allgemein „bunt“, für Hervorhebungen und Unterscheidungen */
    background-color: #b3b7ff;
 }
 .hintergrundfarbe7 { /* Allgemein „bunt“, für Hervorhebungen und Unterscheidungen */
    background-color: #ffcbcb;
 }
 .hintergrundfarbe8 { /* Allgemein „bunt“, für Hervorhebungen und Unterscheidungen */
    background-color: #ffebad;
 }
 .hintergrundfarbe9 { /* Allgemein „bunt“, für Hervorhebungen und Unterscheidungen */
    background-color: #b9ffc5;
 }
</syntaxhighlight>
auf folgendes ergänzt werden
 siehe unten
:Damit die hintergrundfarben in <code>wikitable</code> wieder funktionieren? Es wird ergänzt und nicht überschrieben, damit <code>div</code>s und <code>prettytable</code> weiterhin funktionieren. <code>prettytable</code> muss auch nicht ergänzt werden, da es aktuell funktioniert.
:Wie sieht das mit den rahmenfarben aus?
:Falls alles zusammen ist, sollte eine Bitte auf [[WP:AAF]] erstellt werden. [[Benutzer:Umherirrender|Der Umherirrende]] 10:57, 18. Jul. 2009 (CEST)
:: AAF ist nicht unbedingt nötig... Testet es aus, und wenn ihr meint, es sei vollständig, schreibt das hier. Ich kann dann selber noch mal testen und Umsetzen. --[[Benutzer:Guandalug|Guandalug]] 11:03, 18. Jul. 2009 (CEST)
:::Diese Lösung ermöglicht es zumindestens die hintergrundfarbe-Klassen wieder an wikitable zu nutzen. Wäre doch schonmal ein Schritt, oder nicht? [[Benutzer:Umherirrender|Der Umherirrende]] 14:44, 29. Jul. 2009 (CEST)

Das Thema ist nicht so einfach. Hintergrundfarben können auf drei verschiedene Arten gesetzt werden:
* Mit HTML: <code>bgcolor="#e0e0e0"</code> (Bereits bei [http://www.w3.org/TR/html4/present/graphics.html#h-15.1.1 HTML 4 Deprecated], aber trotzdem häufig verwendet)
* Mit CSS: <code>style="background-color: #e0e0e0"</code>
* Mit CSS-Klassen: <code>class="hintergrundfarbe5"</code>
Um eine Tabellenzelle mit einer Hintergrundfarbe einzufärben gibt es mehrere Stellen, wo diese Definitionen angebracht werden können:
* An der Tabellenzelle <code>td</code> bzw. <code>th</code>
* An der Tabellenzeile <code>tr</code>
* <s>Am Tabellenkörper <code>tbody</code></s> (entfällt, weil von MediaWiki nicht erlaubt)
* An der Tabelle <code>table</code>
* <s>An Elementen oberhalb der Tabelle</s> (entfällt, weil [http://de.wikipedia.org/skins-1.5/monobook/main.css Tabellen weiße Hintergrundfarbe] haben)
Die neue Definition von <code>wikitable</code> mit automatischer Hintergrundfarbe für Tabellenkopfzellen
<syntaxhighlight lang="css">
.wikitable th { background: #f2f2f2; }
</syntaxhighlight>
passt im Artikelnamensraum für bestimmt für 80 % aller Tabellen und sorgt für eine einheitliche Darstellung. Die [[Hilfe:Tabellen#Einfache Tabelle|derzeitige Empfehlung]] mit <code>class="hintergrundfarbe5"</code> für die erste Zeile könnte entfallen. Leider ist diese Definition so streng, dass sie alle Hintergrundfarben der Tabelle und der Tabellenzeile überdeckt und vom Autor nur noch mit CSS-Klassen oder CSS-Styles an der Tabellenkopfzelle direkt überschreiben werden kann:

{| class="wikitable"
|-
! style="background-color: red" | th mit <code>style="background-color: red"</code>
|}

Selbst das HTML-Attribut <code>bgcolor</code> an der Tabellenkopfzelle funktioniert beim Firefox nicht mehr:

{| class="wikitable"
|-
! bgcolor="red" | th mit <code>bgcolor="red"</code>
|}

Wenn wir nun die CSS-Klassen <code>hintergrundfarbe''x''</code> um die oben geschriebene Definition ergänzen, dann hätten wir folgende Situation bei <code>wikitable</code>:
* <code>bgcolor="…"</code> funktioniert nicht
* <code>style="background-color:…"</code> funktioniert nur bei Tabellenzellen, aber nicht bei Tabellenzeilen und bei <code>table</code>.
* <code>class=hintergrundfarbe''x''</code> funktioniert an Tabellenzellen und an Tabellenzeilen, überschreibt da aber die Farbe von Tabellenzellen, sodass dort Zellenformatierung nicht mehr wirkt:

{| class="wikitable"
|+ Tabelle mit <code>class="hintergrundfarbe5"</code> an der Zeile
|- class="hintergrundfarbe5"
! class="hintergrundfarbe6" | mit <code>class="hintergrundfarbe6"</code>
! ohne <code>class="hintergrundfarbe6"</code>
|}

Mit der obigen Erweiterung für der CSS-Klassen <code>hintergrundfarbe''x''</code> würden zwar einige übliche Fälle abgedeckt werden, aber das Verhalten wäre noch unnachvollziehbarer. Ich kann es daher nicht empfehlen.

Meiner Meinung nach ist der einzig sinnvolle Weg statt <code>wikitable</code> weiterhin <code>prettytable</code> zu verwenden, wenn die Hintergrundfarben geändert werden sollen. --[[Benutzer:Fomafix|Fomafix]] 22:23, 19. Jul. 2009 (CEST)
:Vielleicht kann man erzwingen das die Core-Definition geändert wird. Gibt es eine nicht so strikte Möglichkeit, das gleiche Ergebnis zu erzielen? Dann sollte man das auf [[bugzilla:|Bugzilla]] vorbringen. [[Benutzer:Umherirrender|Der Umherirrende]] 18:56, 20. Jul. 2009 (CEST)
:: Gibt es:
<syntaxhighlight lang="css">
 /* Hintergrundfarbe für Titelzellen --[[Benutzer:Fomafix|Fomafix]] 15:44, 15. Dez. 2008 (CET) */
 table.wikitable tr:not([class^="hintergrundfarbe"]):not([style]):not([bgcolor]) th:not([bgcolor]),
 table.prettytable tr:not([class^="hintergrundfarbe"]):not([style]):not([bgcolor]) th:not([bgcolor]) {
 	background-color: #f2f2f2;
 }
</syntaxhighlight>
:: Diese Darstellung wird aber nicht von allen Browsern verstanden. So versteht der Internet Explorer <code>[https://developer.mozilla.org/En/CSS/%3anot :not()]</code> nicht. Eine browserabhängige Darstellung ist noch schlechter, als eine unflexible, aber einheitliche Darstellung. --[[Benutzer:Fomafix|Fomafix]] 21:17, 20. Jul. 2009 (CEST)

Warum ist das in shared.css überhaupt mit table eingetragen ? Das hebt doch die Priorität unnötig an. Wenn es stört, dann muss es aus shared.css heraus und fretig. <span class="signaturcaesium137">[[Benutzer:Cäsium137|Cäsium137]]&nbsp;[[Benutzer_Diskussion:Cäsium137|(D.)]]</span> 22:44, 20. Jul. 2009 (CEST)
: Das <code>'''table.'''wikitable</code> hebt die CSS-Priorität zwar an, ändert an prinzipiellen Definition und deren Probleme nichts. Hervorgehobene Tabellenkopfzellen sind bei sicherlich 80 % aller Tabellen einen großen Vorteil, haben aber leider als Kollateralschaden eine eingeschränkte Flexibilität. --[[Benutzer:Fomafix|Fomafix]] 22:58, 20. Jul. 2009 (CEST)

<div style="text-decoration: line-through;">Wenn in http://de.wikipedia.org/skins-1.5/common/shared.css statt
<syntaxhighlight lang="css">
.wikitable th {
    background: #f2f2f2;
}
</syntaxhighlight>
besser
<syntaxhighlight lang="css">
.wikitable th {
    background-color: #f2f2f2;
}
</syntaxhighlight>
stehen würde, könnte mit
<syntaxhighlight lang="css">
.wikitable th[bgcolor] {
    background-color: auto;
}
</syntaxhighlight>
in [[MediaWiki:Common.css]] die [http://www.w3.org/TR/html4/present/graphics.html#adef-bgcolor veraltete HTML-Formatierung <code>bgcolor</code>] in <code>! bgcolor="#fedcba" | Überschrift</code> ermöglicht werden ohne [https://developer.mozilla.org/En/CSS/%3anot :not()] verwenden zu müssen. Der Internet Explorer 6 kann aber noch keine [http://de.selfhtml.org/css/formate/zentrale.htm#attributbedingte attributbedingte Formate]. Besser wäre es daher, wenn in den Artikeln [http://www.w3.org/TR/CSS21/colors.html#background <code>background-color</code> von CSS] verwendet wird. --[[Benutzer:Fomafix|Fomafix]] 13:58, 29. Jul. 2009 (CEST)
: Das <code>background: #f2f2f2;</code> aus http://de.wikipedia.org/skins-1.5/common/shared.css kann auch hier überschrieben werden durch das etwas seltsam aussehende:
<syntaxhighlight lang="css">
.wikitable th[bgcolor] {
background: transparent;
background-color: auto;
}
</syntaxhighlight>
: Damit wäre die HTML-Formatierung <code>bgcolor</code> an der Tabellenkopfzelle wieder möglich. --[[Benutzer:Fomafix|Fomafix]] 14:19, 29. Jul. 2009 (CEST)</div> Funktioniert so nicht. Da hat mich der Firebug getäuscht gehabt. Eine überschriebene HTML-Formatierung kann man nicht wieder her holen. Es geht nur mit <code>:not([bgcolor]) { background-color: #xxxxxx }</code>. Das ist aber alles unnötig, denn <code>bgcolor</code> ist veraltet und sollte durch CSS ersetzt werden. --[[Benutzer:Fomafix|Fomafix]] 15:07, 29. Jul. 2009 (CEST)

::[http://de.wikipedia.org/w/index.php?oldid=62751137 Testseite]. Es fällt auf, das es sogar einen Fall mit prettytable gibt, der nicht funktoniert: bgcolor am <code>table</code>. --[[Benutzer:Umherirrender|Der Umherirrende]] 14:31, 29. Jul. 2009 (CEST)
::: Danke für diese Testseite. --[[Benutzer:Fomafix|Fomafix]] 15:07, 29. Jul. 2009 (CEST)

Mit folgender CSS-Definition für die Hintergrundfarben
<syntaxhighlight lang="css">
 table.wikitable tr.hintergrundfarbe6 th,
 table.wikitable tr th.hintergrundfarbe6,
 .hintergrundfarbe6 { /* Allgemein „bunt“, für Hervorhebungen und Unterscheidungen */
    background-color: #b3b7ff;
 }
</syntaxhighlight>
würde sich das Problem kompensieren lassen, dass eine Zeilenhintergrundfarbe wegen der höheren Priorität eine Zellenhintergrundfarbe überschreibt. --[[Benutzer:Fomafix|Fomafix]] 16:53, 29. Jul. 2009 (CEST)

:Das wäre schonmal ein Anfang. Die Definition deckt viele weitere Fälle ab. Ich würde sagen, man könnte es zwischenzeitlich umsetzen, damit nicht überall prettytable gesetzt wird. Auf prettytable wollte man ja eigentlich verzichten. Zusätzlich ist es für außenstehende nicht nachvollziehbar, warum das eine funktioniert und das andere nicht, da ja beide gleich sein sollten. Das wirft später nur Fragen auf. [[Benutzer:Umherirrender|Der Umherirrende]] 17:30, 29. Jul. 2009 (CEST)

Bei <code>wikitable</code>-Tabellen kann derzeit auch nicht die Hintergrundfarbe der gesamten Tabelle mit den CSS-Klassen <code>hintergrundfarbe''x''</code> gesetzt werden:

{| class="wikitable hintergrundfarbe6"
|-
| wikitable-Tabelle mit hintergrundfarbe6
|}

während es bei <code>prettytable</code>-Tabellen funktioniert:

{| class="prettytable hintergrundfarbe6"
|-
| prettytable-Tabelle mit hintergrundfarbe6
|}

Die Ursache liegt darin, dass das core.css <code>'''table'''.wikitable</code> definiert und damit eine [http://www.w3.org/TR/CSS21/cascade.html#specificity höhere Priorität] hat. Beheben lässt sich das durch Anheben der Priorität: <code>body .hintergrundfarbe6</code> oder <code>table.hintergrundfarbe6, .hintergrundfarbe6</code>. --[[Benutzer:Fomafix|Fomafix]] 14:57, 30. Jul. 2009 (CEST)
:Das sieht gut aus und funktioniert. Dann wird die Definiton leider sehr umfangreich:
<syntaxhighlight lang="css">
 table.wikitable tr.hintergrundfarbe1 th,
 table.wikitable tr th.hintergrundfarbe1,
 table.hintergrundfarbe1,
 .hintergrundfarbe1 { /* Wie Inhaltsverzeichnis */
    background-color: #f9f9f9;
 }
 table.wikitable tr.hintergrundfarbe2 th,
 table.wikitable tr th.hintergrundfarbe2,
 table.hintergrundfarbe2,
 .hintergrundfarbe2 { /* "Weiß", für Nicht-Artikel-Seiten, neutral */
    background-color: #ffffff;
 }
 table.wikitable tr.hintergrundfarbe3 th,
 table.wikitable tr th.hintergrundfarbe3,
 table.hintergrundfarbe3,
 .hintergrundfarbe3 { /* "Gelb", auffällig */
    background-color: #ffff40;
 }
 table.wikitable tr.hintergrundfarbe4 th,
 table.wikitable tr th.hintergrundfarbe4,
 table.hintergrundfarbe4,
 .hintergrundfarbe4 { /* Sehr auffällig */
    background-color: #ffaa00;
 }
 table.wikitable tr.hintergrundfarbe5 th,
 table.wikitable tr th.hintergrundfarbe5,
 table.hintergrundfarbe5,
 .hintergrundfarbe5 { /* Neutral, abgesetzt */
    background-color: #e0e0e0;
 }
 table.wikitable tr.hintergrundfarbe6 th,
 table.wikitable tr th.hintergrundfarbe6,
 table.hintergrundfarbe6,
 .hintergrundfarbe6 { /* Allgemein „bunt“, für Hervorhebungen und Unterscheidungen */
    background-color: #b3b7ff;
 }
 table.wikitable tr.hintergrundfarbe7 th,
 table.wikitable tr th.hintergrundfarbe7,
 table.hintergrundfarbe7,
 .hintergrundfarbe7 { /* Allgemein „bunt“, für Hervorhebungen und Unterscheidungen */
    background-color: #ffcbcb;
 }
 table.wikitable tr.hintergrundfarbe8 th,
 table.wikitable tr th.hintergrundfarbe8,
 table.hintergrundfarbe8,
 .hintergrundfarbe8 { /* Allgemein „bunt“, für Hervorhebungen und Unterscheidungen */
    background-color: #ffebad;
 }
 table.wikitable tr.hintergrundfarbe9 th,
 table.wikitable tr th.hintergrundfarbe9,
 table.hintergrundfarbe9,
 .hintergrundfarbe9 { /* Allgemein „bunt“, für Hervorhebungen und Unterscheidungen */
    background-color: #b9ffc5;
 }
</syntaxhighlight>
:Dann wären die hintergrundfarbe-Klassen wieder funktiontstüchtig. Fehlt nur noch background-color und bgcolor am <code>th</code>. Ich schlage eine vorzeitige Umsetzung vor. --[[Benutzer:Umherirrender|Der Umherirrende]] 15:16, 30. Jul. 2009 (CEST)
:: Sieht jedenfalls auf den ersten Blick okay aus. Werde ich nachher mal testen... --[[Benutzer:Guandalug|Guandalug]] 15:19, 30. Jul. 2009 (CEST)

:::Und was ist da jetzt draus geworden? Das funktioniert nämlich immer noch nicht wirklich...
:::Zur Veranschaulichung ein Beispiel (sorry für den äußert intelligenten Tabelleninhalt, aber darum geht es jetzt nicht):
:::Mit wikitable:

<code>
<nowiki>{| class="wikitable"</nowiki><br />
<nowiki>|- class="hintergrundfarbe5"</nowiki><br />
<nowiki>!Hallo</nowiki><br />
<nowiki>!Blah</nowiki><br />
<nowiki>|- class="hintergrundfarbe5"</nowiki><br />
<nowiki>|Laber</nowiki><br />
<nowiki>|Quack</nowiki><br />
<nowiki>|}</nowiki></code>

:::ergibt:

{| class="wikitable"
|- class="hintergrundfarbe5"
!Hallo
!Blah
|- class="hintergrundfarbe5"
|Laber
|Quack
|}

:::Und das ganze nochmal mit prettytable:

<code>
<nowiki>{| class="prettytable"</nowiki><br />
<nowiki>|- class="hintergrundfarbe5"</nowiki><br />
<nowiki>!Hallo</nowiki><br />
<nowiki>!Blah</nowiki><br />
<nowiki>|- class="hintergrundfarbe5"</nowiki><br />
<nowiki>|Laber</nowiki><br />
<nowiki>|Quack</nowiki><br />
<nowiki>|}</nowiki></code>

:::ergibt:

{| class="prettytable"
|- class="hintergrundfarbe5"
!Hallo
!Blah
|- class="hintergrundfarbe5"
|Laber
|Quack
|}

:::Offenbar ignoriert wikitable definierte Tabellenfarben, wenn ein Ausrufezeichen zur Formatierung verwendet wird... Warum das? Und wer ändert das bitte, so dass wikitable wieder sinnvoll verwendet werden kann? -- [[Benutzer:Chaddy|Chaddy]] <small>· [[Benutzer Diskussion:Chaddy|D]]·[[Benutzer:Chaddy/Bewertung|B]]</small> - <small>[[Wikipedia:Dateiüberprüfung|''DÜP'']]</small> 20:46, 12. Aug. 2009 (CEST)
:::: [http://de.wikipedia.org/w/index.php?title=MediaWiki%3ACommon.css&diff=63289951&oldid=61807180 Da isses]. Tschuldigung, die Aufgabe war ohne Änderung vom Tablett gerutscht. Ist jetzt drin. Besser so? (Den Cache nicht vergessen) --[[Benutzer:Guandalug|Guandalug]] 21:45, 12. Aug. 2009 (CEST)
:::::Meine Testseite sieht schon besser aus. Damit funktionieren die Hintergrundfarben-Klassen wieder wie gewohnt. Weiß nicht, ob man das auf [[WP:NEU]] anpreisen sollte. [[Benutzer:Umherirrender|Der Umherirrende]] 22:02, 12. Aug. 2009 (CEST)

:::::Danke, jetzt geht´s wieder. @Der Umherirrende: Kann man denke ich schon auf WP:NEU anpreisen. -- [[Benutzer:Chaddy|Chaddy]] <small>· [[Benutzer Diskussion:Chaddy|D]]·[[Benutzer:Chaddy/Bewertung|B]]</small> - <small>[[Wikipedia:Dateiüberprüfung|''DÜP'']]</small> 22:21, 12. Aug. 2009 (CEST)

::::::Aber erst, wenn auch das Problem unten gelöst ist. -- [[Benutzer:Chaddy|Chaddy]] <small>· [[Benutzer Diskussion:Chaddy|D]]·[[Benutzer:Chaddy/Bewertung|B]]</small> - <small>[[Wikipedia:Dateiüberprüfung|''DÜP'']]</small> 22:25, 12. Aug. 2009 (CEST)

Das einzige Problem was noch besteht sind <code>bgcolor</code> und <code>background-color:</code> die man direkt am <code>th</code> schreibt. Wenn man <code>background</code> mit Farbe nutzt, dann funktioniert. Würde es Sinn machen, wenn die Core-Definition von <code>background</code> auf <code>background-color:</code> wechselt? Oder würde das andere Probleme verursachen? [[Benutzer:Umherirrender|Der Umherirrende]] 22:02, 12. Aug. 2009 (CEST)

:Stimmt, mit <code>bgcolor</code> und <code>background-color:</code> funktioniert´s noch nicht wieder richtig... -- [[Benutzer:Chaddy|Chaddy]] <small>· [[Benutzer Diskussion:Chaddy|D]]·[[Benutzer:Chaddy/Bewertung|B]]</small> - <small>[[Wikipedia:Dateiüberprüfung|''DÜP'']]</small> 22:25, 12. Aug. 2009 (CEST)

::[http://de.wikipedia.org/w/index.php?oldid=63382897 neue Testseite] mit mehr Fällen. Ich denke, ich habe jetzt alle möglichen abgedeckt. [[Benutzer:Umherirrender|Der Umherirrende]] 23:36, 12. Aug. 2009 (CEST)

:::Die fehlende Definition für
{| class="wikitable hintergrundfarbe6"
|-
! wikitable hintergrundfarbe6 <code>table tr th</code>
|-
| zweite Zeile
|}
:::lautet <syntaxhighlight lang="css" inline>table.hintergrundfarbe6 tr th</syntaxhighlight>. Damit sind mir keine Fälle mehr bekannt, wo die Hintergrundfarbe-Klassen noch Probleme haben. --[[Benutzer:Umherirrender|Der Umherirrende]] 19:46, 14. Aug. 2009 (CEST)
::::Traut sich keiner für diesen Punkt oder kann keiner das nachvollziehen? --[[Benutzer:Umherirrender|Der Umherirrende]] 20:10, 28. Aug. 2009 (CEST)
:::::Traut sich immer noch keiner? Falls es bedenken gibt, wäre es nett, sie mitzuteilen. [[Benutzer:Umherirrender|Der Umherirrende]] 17:31, 18. Sep. 2009 (CEST)
:::::: Ich denke, die derzeitige Definition reicht. Wenn jemand <code>class="wikitable hintergrundfarbe6"</code> angibt, dann soll die Farbe der Tabelle geändert werden, aber Tabellenköpfe dürfen weiterhin automatisch hervorgehoben werden. --[[Benutzer:Fomafix|Fomafix]] 18:09, 18. Sep. 2009 (CEST)
:::::::Ja, könnte man auch so lassen, ich dachte nur an Gleichheit zu prettytable. [[Benutzer:Umherirrender|Der Umherirrende]] 19:29, 14. Okt. 2009 (CEST)

:::Die Core-Definition zielt auf das <code>th</code>. Fügt man jetzt inlineCSS (<code>bgcolor</code>, <code>background-color</code> oder <code>background</code>) an übergeordnetet Elemente (<code>tr</code> oder <code>table</code>) hat die InlineCSS-Definitionen keine Wirkung, da sie die Core-Definition nicht überschreiben. InlineCSS hat anscheind nur am direkten Element die höchste Priorität. Die Kinderelmente erhalten diese Priorität nicht. Warum auch immer das so ist (gewollt oder ungewollt). Eine Lösung dafür kenne ich nicht. Ob man einen Bugreport für MediaWiki einstellen soll, damit sich die devs das anschauen, kann ich auch nicht sagen, wie erfolgversprechend das aussieht. [[Benutzer:Umherirrender|Der Umherirrende]] 20:07, 14. Aug. 2009 (CEST)
::::Sollte nur als Anreiz dienen, wenn kein Interesse da ist, dann ist es für mich erledigt. [[Benutzer:Umherirrender|Der Umherirrende]] 19:29, 14. Okt. 2009 (CEST)

:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Umherirrender|Der Umherirrende]] 19:29, 14. Okt. 2009 (CEST)</small>

== spezialseitenlinks entfettet ==

Mit [http://de.wikipedia.org/w/index.php?title=MediaWiki:Common.css&diff=50032878&oldid=49271765 dieser Änderung] wurden die fetten Links auf [[Spezial:Spezialseiten]] entfettet. Diese CSS zieht seit [[rev:49025]] nicht mehr. Es muss jetzt so lauten:
<syntaxhighlight lang="css">
/* Fettformatierung von Admin-Spezialseiten in [[Special:Specialpages]] abschalten */
 .mw-specialpagerestricted strong {
        font-weight:normal;
 }
</syntaxhighlight>
Es ist das <code>strong</code> hinter der Klasse hinzugekommen. Vielen Dank fürs ändern. [[Benutzer:Umherirrender|Der Umherirrende]] 19:27, 14. Okt. 2009 (CEST)

: {{Ok}} Erl. — [[Benutzer:Raymond|Raymond]] [[Benutzer Diskussion:Raymond|<sup>Disk.</sup>]] 19:45, 14. Okt. 2009 (CEST)
:<small>Archivierung dieses Abschnittes wurde gewünscht von: — [[Benutzer:Raymond|Raymond]] [[Benutzer Diskussion:Raymond|<sup>Disk.</sup>]] 19:45, 14. Okt. 2009 (CEST)</small>

== Artikelkoordinaten bei neuen Skins ==

<syntaxhighlight lang="css">
 #coordinates_3_ObenRechts, #issnlink, #editcount, #shortcut, #artikelstadium {
    display: none;
 }
</syntaxhighlight>
muss ergänzt werden um
<syntaxhighlight lang="css">
 #coordinates {
    display: none;
 }
</syntaxhighlight>
{{Vorlage|Coordinate}} verwendet nicht nur <code>#coordinates_3_ObenRechts</code>, sondern auch direkt <code>#coordinates</code>. Mit <code>display:none</code> hier wird gewährleistet, dass bei neuen Skins ohne Unterstützung für [[Vorlage:Coordinate]] die Artikelkoordinaten nicht im Fließtext angezeigt werden. Die Skins überschreiben den Wert dann mit <code>display:inline</code>. --[[Benutzer:Fomafix|Fomafix]] 13:18, 31. Aug. 2009 (CEST)
:[[Benutzer:Euku]] hat die Änderung [http://de.wikipedia.org/w/index.php?title=MediaWiki:Common.css&diff=72704531&oldid=71758068 übernommen]. --[[Benutzer:Fomafix|Fomafix]] 17:29, 3. Apr. 2010 (CEST)
:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Fomafix|Fomafix]] 17:29, 3. Apr. 2010 (CEST)</small>

== NavToggle ==
Wäre jemand mit entsprechender Berechtigung bitte so nett
 .NavToggle {
     font-size: x-small;
     float:right;
 }
zu
 <u>div</u>.NavToggle {
     font-size: x-small;
     float:right;
 }
umzuschreiben? Danke. -- [[Benutzer:Ishbane|Ishbane]] 16:47, 10. Mai 2010 (CEST)
: Derzeit wird JavaScript aus [[MediaWiki:Common.js]] folgendes erzeugt:
<syntaxhighlight lang="html4strict"><a class="NavToggle" id="NavToggle1" href="#">Ausklappen</a></syntaxhighlight>
: Zuerst muss daher die Änderung von [[Wikipedia:Administratoren/Anfragen#Vorschlag (Navigationsleisten)]] umgesetzt werden. --[[Benutzer:Fomafix|Fomafix]] 16:54, 10. Mai 2010 (CEST)
:: [[Benutzer:32X]] hat die Änderung [http://de.wikipedia.org/w/index.php?title=MediaWiki:Common.css&diff=74199188&oldid=73972325 rein] und gleich wieder [http://de.wikipedia.org/w/index.php?title=MediaWiki:Common.css&diff=74202340&oldid=74199188 raus], weil die Formatierung der Knöpfe nicht mehr funktioniert hat.
:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Fomafix|Fomafix]] 09:23, 11. Mai 2010 (CEST)</small>

== wikitable ↔ prettytable ==

Hallo, [[Wikipedia:Fragen_zur_Wikipedia#class.3D.22prettytable.22|hier]] bin ich darauf gestoßen, dass wiki- und prettytable nicht ganz gleich sind, sondern dass bei der prettytable noch ein <code>text-align: center;</code> aus [http://bits.wikimedia.org/skins-1.5/common/shared.css] fehlt. Braucht es das nicht oder wurde das einfach vergessen?<br />fragt --&thinsp;<big>[[Benutzer:✓|✓]]</big>&thinsp;<small><sup>[[Benutzer Diskussion:✓|Bergi]]</sup></small> 15:53, 5. Mär. 2010 (CET)
: Das wurde vermutlich nachträglich / später in wikitable eingeführt. Da 'prettytable' eh eine "aussterbende Klasse" sein soll, halte ich das auch für weniger tragisch. Im Gegenteil....  --[[Benutzer:Guandalug|Guandalug]] 16:18, 5. Mär. 2010 (CET)
::Wenn du einige Diskutanten liest, machen die das sicher zu einem Vorteil von prettytable und einem Grund, diese weiter einzusetzen :) Aber dann verhelfen wir einfach so zum Aussterben und löschen irgendwann (oder auch gerne jetzt gleich) die prettytable-Definitionen, dann bleibt den Ignoranten nichts anderes mehr übrig…<br />meint --&thinsp;<big>[[Benutzer:✓|✓]]</big>&thinsp;<small><sup>[[Benutzer Diskussion:✓|Bergi]]</sup></small> 18:37, 5. Mär. 2010 (CET)

:::Nein, das wäre überhaupt nicht gut, da so die ganzen noch nicht umgestellten Tabellen zerschossen werden würden... -- [[Benutzer:Chaddy|Chaddy]] <small>· [[Benutzer Diskussion:Chaddy|D]]·[[Benutzer:Chaddy/Bewertung|B]]</small> - <small>[[Wikipedia:Dateiüberprüfung|''DÜP'']]</small> 17:35, 10. Apr. 2010 (CEST)
:::P. S.: Und solange wikitable immer noch nicht richtig mit Farbdefinitionen umgehen kann, ist es eh die schlechtere Alternative... -- [[Benutzer:Chaddy|Chaddy]] <small>· [[Benutzer Diskussion:Chaddy|D]]·[[Benutzer:Chaddy/Bewertung|B]]</small> - <small>[[Wikipedia:Dateiüberprüfung|''DÜP'']]</small> 17:39, 10. Apr. 2010 (CEST)
::::Welche Konstellation von Farbdefinitionen fehlen noch, wo sollte man Energie für aufwenden? Siehe auch im [[#Hintergrundfarben nach Übernahme von wikitable in core-css|Archiv]] --[[Benutzer:Umherirrender|Der Umherirrende]] 20:36, 10. Apr. 2010 (CEST)

:::::Ja, die Diskussion kenne ich.
:::::Bei der Formatierung mit <code><nowiki>!</nowiki></code> funktiniert nur <code><nowiki>class="hintergrundfarbe5"</nowiki></code>, <code><nowiki>style="background-color:#fedbca;"</nowiki></code> und <code><nowiki>bgcolor="#DDEEFF"</nowiki></code> dagegen nicht (da erscheint dann die Standardfarbe).
:::::Ich verdeutliche das mal mit einem Beispiel:

:::::Mit wikitable:

<code>
<nowiki>{| class="wikitable"</nowiki><br />
<nowiki>|- style="background-color:#fedbca;"</nowiki><br />
<nowiki>! Test1</nowiki><br />
<nowiki>| Test2</nowiki><br />
<nowiki>|- bgcolor="#DDEEFF"</nowiki><br />
<nowiki>! Test3</nowiki><br />
<nowiki>| Test4</nowiki><br />
<nowiki>|- class="hintergrundfarbe5"</nowiki><br />
<nowiki>! Test5</nowiki><br />
<nowiki>| Test6</nowiki><br />
<nowiki>|}</nowiki>
</code>

{| class="wikitable"
|- style="background-color:#fedbca;"
! Test1
| Test2
|- bgcolor="#DDEEFF"
! Test3
| Test4
|- class="hintergrundfarbe5"
! Test5
| Test6
|}

:::::Mit prettytable:

<code>
<nowiki>{| class="prettytable"</nowiki><br />
<nowiki>|- style="background-color:#fedbca;"</nowiki><br />
<nowiki>! Test1</nowiki><br />
<nowiki>| Test2</nowiki><br />
<nowiki>|- bgcolor="#DDEEFF"</nowiki><br />
<nowiki>! Test3</nowiki><br />
<nowiki>| Test4</nowiki><br />
<nowiki>|- class="hintergrundfarbe5"</nowiki><br />
<nowiki>! Test5</nowiki><br />
<nowiki>| Test6</nowiki><br />
<nowiki>|}</nowiki>
</code>

{| class="prettytable"
|- style="background-color:#fedbca;"
! Test1
| Test2
|- bgcolor="#DDEEFF"
! Test3
| Test4
|- class="hintergrundfarbe5"
! Test5
| Test6
|}

:::::Da alle diese Formatierungen sehr weit verbreitet sind, sollte man sie schon auch mit wikitable unterstützen... -- [[Benutzer:Chaddy|Chaddy]] <small>· [[Benutzer Diskussion:Chaddy|D]]·[[Benutzer:Chaddy/Bewertung|B]]</small> - <small>[[Wikipedia:Dateiüberprüfung|''DÜP'']]</small> 21:01, 10. Apr. 2010 (CEST)

::::::Es scheint mir so, das wir das Problem nicht lokal beheben können. Eine Lösung wäre wünschenswert, wenn es wirklich eine häufige Verwendung ist. Sollte damit an die MediaWiki-Entwickler [[Hilfe:Bugzilla|herangetreten]] werden? Sollte jemand im verständlichen Englisch verfassen, ich bin dafür nicht geeignet. [[Benutzer:Umherirrender|Der Umherirrende]] 21:40, 10. Apr. 2010 (CEST)

:::::::Natürlich sind eher wenige Tabellen mit class="hintergrundfarbeX" aufgebaut. Das betrifft v. a. die Tabellen aus der Vor-wikitable-Zeit. Und durch c&p entstehen auch immer noch solche Tabellen. Z. B. die ganzen Fußballartikel sind eh z. T. noch mit zeimlich chaotischen Tabellenkonstrukten ausgestattet ([http://de.wikipedia.org/w/index.php?title=Fu%C3%9Fball-Europameisterschaft_der_Frauen_1989/Qualifikation&diff=prev&oldid=72977377])... -- [[Benutzer:Chaddy|Chaddy]] <small>· [[Benutzer Diskussion:Chaddy|D]]·[[Benutzer:Chaddy/Bewertung|B]]</small> - <small>[[Wikipedia:Dateiüberprüfung|''DÜP'']]</small> 23:37, 10. Apr. 2010 (CEST)

{| class="wikitable float-right"
! Kopfzelle
! Kopfzelle
|-
| Nichtkopfzelle
| Nichtkopfzelle
|-
! Kopfzelle
| Nichtkopfzelle
|-
| Nichtkopfzelle
! Kopfzelle
|}
:Das geschilderte Problem mit den Farben ist der Versuch, durch Setzen der Hintergrundfarbe einer Zeile (<code>tr</code>) die von wikitable gesetzte Hintergrundfarbe der Kopfzellen (<code>th</code>) zu verändern. Das kann nicht funktionieren und ist insofern kein Bug; soll die Hintergrundfarbe einer Zelle geändert werden, dann muss das Attribut auch an der (bzw. jeder einzelnen) Zelle stehen.
:In CSS wäre das nur zu lösen, indem wikitable anstelle der Kopfzellen die sie enthaltenden Zeilen färbt. Das ist unmöglich, weil es mangels ''parent selector'' keine Möglichkeit gibt, Tabellenzeilen zu finden, die aus Kopfzellen bestehen. Es gibt übrigens noch nicht mal eine Garantie, dass alle Zellen einer Zeile Kopfzellen sind, siehe Beispiel rechts.
:Eine Alternative wäre die Nutzung von <code>thead</code>-Elementen, dann könnte wikitable dort ansetzen und es ließe sich wahlweise an der Zeile oder an den einzelnen Zellen überschreiben. Das kann aber nur in MediaWiki selbst geschehen (Bugs [[:bugzilla:3156|3156]] und [[:bugzilla:4740|4740]]). Bis dahin bleiben eben nur die Möglichkeiten, Farben an die Zellen zu setzen oder auf Farben oder wikitable zu verzichten.
:Aber mal was anderes. wikitable ist zurzeit wie folgt definiert:
{|
! Globale shared.css
! Lokale common.css
! Ergebnis der Kaskade
|-
|
 table.wikitable {
 	margin: 1em 1em 1em 0;
 	background: #f9f9f9;
 	border: 1px #aaa solid;
 	border-collapse: collapse;
 }
 
 .wikitable th, .wikitable td {
 	border: 1px #aaa solid;
 	<del>padding: 0.2em;</del>
 }
 
 .wikitable th {
 	<ins>background: #f2f2f2;</ins>
 	<ins>text-align: center;</ins>
 }
 
 .wikitable caption {
 	font-weight: bold;
 }
|
 .wikitable {
 	margin: 1em 1em 1em 0;
 	background: #f9f9f9;
 	border: 1px #aaa solid;
 	border-collapse: collapse;
 	<ins>empty-cells: show;</ins>
 }
 
 .wikitable th, .wikitable td {
 	border: 1px #aaa solid;
 	<ins>padding: 0.3em;</ins>
 }
 
 .wikitable caption {
 	font-weight: bold;
 }
|
 table.wikitable, .wikitable {
 	margin: 1em 1em 1em 0;
 	background: #f9f9f9;
 	border: 1px #aaa solid;
 	border-collapse: collapse;
 }
 
 .wikitable {
 	empty-cells: show;
 }
 
 .wikitable th, .wikitable td {
 	border: 1px #aaa solid;
 	padding: 0.3em;
 }
 
 .wikitable th {
 	background: #f2f2f2;
 	text-align: center;
 }
 
 .wikitable caption {
 	font-weight: bold;
 }
|}
:Ist es überhaupt sinnvoll, wikitable lokal weiter mitzuschleppen? <code>empty-cells: show;</code> ist eh Standard. Der Unterschied im <code>padding</code> wäre zwar wahrnehmbar (bei 1em = 16px sind 0.3em = 5px und 0.2em = 3px), aber man würde sich wahrscheinlich schnell daran gewöhnen. Ansonsten macht es die Sache nur komplizierter. --[[Benutzer:Entlinkt|Entlinkt]] 04:09, 6. Jun. 2010 (CEST)

::Und wieso funktioniert das mit den Farben dann bei prettytable? :S -- [[Benutzer:Chaddy|Chaddy]] <small>· [[Benutzer Diskussion:Chaddy|D]]·[[Benutzer:Chaddy/Bewertung|B]]</small> - <small>[[Wikipedia:Dateiüberprüfung|''DÜP'']]</small> 07:42, 6. Jun. 2010 (CEST)

:::Ist das eine rhetorische Frage? Wie auch immer, die Antwort lautet: Weil prettytable den <code>th</code>s im Gegensatz zu wikitable keine Hintergrundfarbe gibt. Hier nochmal der Vergleich zwischen prettytable und wikitable:
{|
! prettytable (common.css)
! wikitable (shared.css und common.css zusammenkaskadiert)
|-
|
 .prettytable {
 	margin: 1em 1em 1em 0;
 	background: #f9f9f9;
 	border: 1px #aaa solid;
 	border-collapse: collapse;
 	empty-cells: show;
 }
 
 .prettytable th, .prettytable td {
 	border: 1px #aaa solid;
 	padding: 0.3em;
 }
 
 .prettytable caption {
 	font-weight: bold;
 }
|
 table.wikitable, .wikitable {
 	margin: 1em 1em 1em 0;
 	background: #f9f9f9;
 	border: 1px #aaa solid;
 	border-collapse: collapse;
 }
 
 .wikitable {
 	empty-cells: show;
 }
 
 .wikitable th, .wikitable td {
 	border: 1px #aaa solid;
 	padding: 0.3em;
 }
 
 .wikitable th {
 	<ins>background: #f2f2f2;</ins>
 	<ins>text-align: center;</ins>
 }
 
 .wikitable caption {
 	font-weight: bold;
 }
|}
:::Das Entfernen der Hintergrundfarbe der <code>th</code>s bei wikitable (einzig mögliche „Lösung“, wenn man die Farben unbedingt an die <code>tr</code>s setzen will) ist jedoch keine Option, weil an verschiedenen Stellen, wo wikitable verwendet wird, schon die individuell gesetzte Hintergrundfarbe entfernt oder erst gar keine gesetzt wurde, wo man sich also letztlich darauf verlässt, dass wikitable den <code>th</code>s eine Hintergrundfarbe gibt.
:::Meine Frage lautete zuletzt aber gar nicht, ob prettytable entfernt werden soll (dass das nicht geht, solange es noch verwendet wird, ist klar), sondern ob die lokale Definition von wikitable entfernt werden kann. Außer <code>padding: 0.3em;</code> tut sie nämlich zurzeit nichts, macht es aber unübersichtlicher und verhindert, dass zukünftige Bugfixes an shared.css sich hier auswirken. --[[Benutzer:Entlinkt|Entlinkt]] 15:25, 6. Jun. 2010 (CEST)

::::Nein, meine Frage war schon ernst gemeint. Danke für die Erklärung. -- [[Benutzer:Chaddy|Chaddy]] <small>· [[Benutzer Diskussion:Chaddy|D]]·[[Benutzer:Chaddy/Bewertung|B]]</small> - <small>[[Wikipedia:Dateiüberprüfung|''DÜP'']]</small> 17:26, 6. Jun. 2010 (CEST)

::Ich habe die lokale Definition von wikitable entfernt und prettytable einschließlich des <code>text-align: center;</code>, um das es in diesem Abschnitt ursprünglich ging, daran angepasst. (Eigentlich müsste es heißen: Fast entfernt, denn die lokale Variante kann – auch wenn das nicht sonderlich sinnvoll ist – auch auf andere Elemente als Tabellen angewendet werden, deshalb ist ein kleiner Teil stehen geblieben.) Der einzige Unterschied zwischen wikitable und prettytable ist nun die nicht vorhandene Hintergrundfarbe an Kopfzellen bei prettytable. --[[Benutzer:Entlinkt|Entlinkt]] 03:06, 11. Jun. 2010 (CEST)
:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Entlinkt|Entlinkt]] 03:06, 11. Jun. 2010 (CEST)</small>

== "metadata" und Tabellenzeilen ==

Spricht eigentlich etwas dagegen, die Klasse "metadata" auch für das Element "tr" zu definieren, so dass Tabellenzeilen ausgeblendet werden können? Bislang ist das nur für ganze Tabellen und Spans möglich.
* Vorteil: [[Vorlage:Infobox Verwaltungseinheit in Deutschland]] enthält einen Workaround mit einer Tabelle in der Tabelle, der dann entfernt bzw. ordentlich gelöst werden könnte.
* Nachteil: Es würde möglicherweise großflächig benutzt werden, auch wo es vielleicht nicht angebracht ist (Ausblenden von Infoboxzeilen, die besser nicht ausgeblendet sein sollten; Einführung neuer ausgeblendeter Infoboxparameter, die es besser gar nicht geben sollte etc. pp.)
Meinungen? --[[Benutzer:Entlinkt|Entlinkt]] 05:36, 21. Jan. 2010 (CET)

:Ich habe das umgesetzt, weil es mir sinnvoll erscheint, keine Einwände kamen und es mehrere Stellen gibt, an denen es wirklich gebraucht wird, um unsemantische Konstrukte zu vermeiden, mit denen das Fehlen dieses Features bisher umgangen wurde. --[[Benutzer:Entlinkt|Entlinkt]] 14:47, 22. Jun. 2010 (CEST)
:<small>Archivierung dieses Abschnittes wurde gewünscht von: --[[Benutzer:Entlinkt|Entlinkt]] 14:47, 22. Jun. 2010 (CEST)</small>

== Navigationsleistenverschmelzung ==

Nacheinander eingebundene Navigationsleisten verschmelzen automatisch oder können mit Hilfe der [[Vorlage:NaviBlock]] explizit verschmolzen werden. Zwischen den beiden Varianten gibt es nur zwei Unterschiede:

# Bei der automatischen Verschmelzung bleibt eine einfache Linie zwischen den Leisten erhalten, bei der expliziten verschwindet sie ganz (aber das doppelte Padding bleibt erhalten).
# Die automatische Verschmelzung funktioniert nicht im IE 6 (wohl aber im IE >= 7).

Zu dieser Situation gäbe es folgende Alternativen:

# Die automatische oder die explizite Verschmelzung abschaffen,
# bei der expliziten Verschmelzung die Linie hinzufügen (so dass beide Varianten sich gleich verhalten),
# bei der expliziten Verschmelzung das doppelte Padding auf ein einfaches reduzieren (so dass es beim unterschiedlichen Verhalten bleibt, aber IMHO besser aussieht).

Meinungen? --[[Benutzer:Entlinkt|Entlinkt]] 04:22, 27. Jun. 2010 (CEST)

: Irgendwelche Hacks, damit der IE6 nicht aus der Reihe fällt, halte ich für unnötig. Erstens ist [http://www.heise.de/ix/meldung/Internet-Explorer-6-soll-sterben-993065.html Microsoft um seine Ablösung bemüht] und zweitens sind das potentiell die Codefragmente, die dann wieder ewig mitgeführt werden, ohne dass sie für den größten Teil der Nutzer hilfreich währen. --[[Benutzer:32X|32X]] 08:29, 27. Jun. 2010 (CEST)
:: Wenn der IE6 trotzdem die Seite nutzen kann (also funktioniert) und dessen Nutzer halt nur mit kleineren optischen Einschränkungen leben müssen, stimme ich zu. IE6-Hacks werden nur da "gebraucht", wo ohne diese der IE6 die Mitarbeit in größerem Umfang verweigert. --[[Benutzer:Guandalug|Guandalug]] 11:44, 27. Jun. 2010 (CEST)

Was den IE 6 angeht, sind wir ungefähr derselben Meinung. Für IE-6-Nutzer sieht es ohne [[Vorlage:NaviBlock]] in jedem Fall so aus:
{{Navigationsleiste|TITEL=Leiste1|INHALT=Text1}}
<div class="NotANavFrame"></div>
{{Navigationsleiste|TITEL=Leiste2|INHALT=Text2}}
<div class="NotANavFrame"></div>
{{Navigationsleiste|TITEL=Leiste3|INHALT=Text3}}
Ich finde das hinnehmbar und sage es nur, damit auch jeder weiß, worum es geht. Eigentlich geht es um was ganz anderes, nämlich wie ein Block aus mehreren Leisten in modernen Browsern aussehen soll. Da gäbe es folgende Möglichkeiten:

Nur die Linien zwischen den Leisten verschmelzen (= jetzige Situation, wenn die Leisten ohne [[Vorlage:NaviBlock]] einfach so hintereinander stehen; durch Anpassungen wäre es möglich, dass es mit [[Vorlage:NaviBlock]], die dann eigentlich überflüssig wäre, ebenso so aussieht):
{{Navigationsleiste|TITEL=<span style="color: yellow;">Leiste1</span>|INHALT=Text1}}
{{Navigationsleiste|TITEL=<span style="color: yellow;">Leiste2</span>|INHALT=Text2}}
{{Navigationsleiste|TITEL=<span style="color: yellow;">Leiste3</span>|INHALT=Text3}}
Linien zwischen den Leisten ganz verschwinden lassen, aber doppelten Abstand beibehalten (= jetzige Situation, wenn [[Vorlage:NaviBlock]] genutzt wird und auch nur mit so einer Vorlage machbar):
<div class="BoxenVerschmelzen">
{{Navigationsleiste|TITEL=<span style="color: red;">Leiste1</span>|INHALT=Text1}}
{{Navigationsleiste|TITEL=<span style="color: red;">Leiste2</span>|INHALT=Text2}}
{{Navigationsleiste|TITEL=<span style="color: red;">Leiste3</span>|INHALT=Text3}}
</div>
Linien zwischen den Leisten ganz verschwinden lassen und einfacher statt doppeltem Abstand dazwischen (auch nur mit [[Vorlage:NaviBlock]] machbar, Aussehen hier simuliert):
<div class="BoxenVerschmelzen">
{{Navigationsleiste|TITEL=<span style="color: blue;">Leiste1</span>|INHALT=Text1}}
<div style="margin-top: -2px;">
{{Navigationsleiste|TITEL=<span style="color: blue;">Leiste2</span>|INHALT=Text2}}
</div>
<div style="margin-top: -2px;">
{{Navigationsleiste|TITEL=<span style="color: blue;">Leiste3</span>|INHALT=Text3}}
</div>
</div>
Gruß --[[Benutzer:Entlinkt|Entlinkt]] 14:50, 27. Jun. 2010 (CEST)

Bei der Variante ohne Linies + doppelten Abstand ist bei mir (aktuell FF 3.0) der Abstand innerhalb der grauen Balken 1-2/2-3 identisch zum Abstand der grauen Balken 1/3 zum Rahmen, weshalb mir diese Variante am Besten gefällt. Warum soll dies nur mit einer Vorlage machbar sein? Du kannst doch den Abstand erhöhen, wenn ein Naviblock Vorgänger ist, oder nicht? (habe mir die Klassen allerdings nicht näher angebaut) [[Benutzer:Merlissimo/Sig|Merl]][[Benutzer Diskussion:Merlissimo/Sig|issimo]] 15:14, 27. Jun. 2010 (CEST)
:Hm, ich verstehe nicht ganz. Beim vorletzten Block ist der Abstand zwischen den Leisten doppelt so groß, wie er sein soll (simpler Bug, es fehlt <code>div.BoxenVerschmelzen div.NavFrame { padding-top: 0; }</code>, für die erste Leiste mittels <code>div.BoxenVerschmelzen { padding-top: 2px; }</code> wieder aufzuheben); der letzte Block simuliert durch <code>margin-top: -2px</code>, wie es mit <code>padding-top: 0</code> aussehen würde.
:Der Grund, weshalb eine Lösung ohne Linie zwischen den Leisten ohne [[Vorlage:NaviBlock]] (bzw. Klasse <code>BoxenVerschmelzen</code>) m.&nbsp;E. nicht möglich ist, ist, dass man die untere Linie der jeweiligen Blöcke nicht wegbekommt, weil es keinen „previous sibling selector“ gibt. Aber wenn's doch irgendwie geht, gern. Gruß --[[Benutzer:Entlinkt|Entlinkt]] 15:39, 27. Jun. 2010 (CEST)

::Ich habe den Code noch etwas umsortiert und dokumentiert, so dass er leichter zu entziffern sein sollte. Es wäre außerdem ganz hilfreich, den Cache zu leeren, weil es [http://de.wikipedia.org/w/index.php?title=MediaWiki:Common.css&diff=76034970&oldid=76034375 bis vor Kurzem] noch einen anderen Verdopplungsbug gab, der den Verbliebenen teilweise maskierte.
::Letztlich geht es um einen ganz einfachen Bug der [[Vorlage:NaviBlock]]: Sie entfernt die Rahmen der eingeschlossenen Leisten und malt stattdessen einen neuen Rahmen um die ganze Kollektion, ohne sich darum zu kümmern, dass zwischen den Leisten doppeltes Padding übrig bleibt (sieht so aus wie oben im Block mit der roten Schrift).
::Nun gibt es aber leider zwei Möglichkeiten, den Bug zu fixen: Man kann zwischen den Leisten wieder Linien einfügen (sieht dann so aus wie in dem Block mit der gelben Schrift) oder das doppelte Padding halbieren (sieht dann so aus wie in dem Block mit der blauen Schrift). Da dies nicht nur ein Bugfix, sondern auch eine gestalterische Entscheidung ist, würde ich über Meinungen freuen. --[[Benutzer:Entlinkt|Entlinkt]] 23:57, 27. Jun. 2010 (CEST)
:::Ich hatte mal mit negativen Abstand versucht die untere Linie mit einer oberen Linie in Hintergrundfarbe zu überpinseln, aber das klappt nicht so wirklich gut. [[Benutzer:Merlissimo/Sig|Merl]][[Benutzer Diskussion:Merlissimo/Sig|issimo]] 15:48, 28. Jun. 2010 (CEST)
::::Ich hätte folgende Varianten anzubieten:
<syntaxhighlight lang="css">
/* Verschmelzung ohne [[Vorlage:NaviBlock]]:
 * - Linien zwischen den Leisten bleiben erhalten und werden nur übereinander
     positioniert
 * - Wird vom IE 6 komplett ignoriert, weil er den adjacent sibling selector
     nicht erkennt
 * - Funktioniert in allen anderen Browsern
 */
div.NavFrame + div.NavFrame {
	margin-top: -1px;
}
 
/* Verschmelzung ohne [[Vorlage:NaviBlock]]:
 * - Versuch, die Linien zwischen den Leisten zu entfernen. Die jeweils oberen
     werden entfernt, die unteren mit dem eh vorhandenen Hintergrund von
     div.NavHead übermalt
 * - Wird vom IE 6 komplett ignoriert
 * - Funktioniert in anderen Browsern auch nicht ganz, weil links und rechts
     noch Reste der unteren Linien durchschimmern. Einziger Ausweg: div.NavFrame
     einen nichttransparenten Hintergrund geben. Unverhältnismäßig?
 */
div.NavFrame + div.NavFrame {
	margin-top: -1px;
	border-top-style: none;
	padding-top: 0;
}
 
/* Verschmelzung mit [[Vorlage:NaviBlock]]:
 * - Linien zwischen den Leisten bleiben erhalten und werden nur übereinander
     positioniert
 * - Der Abstand zum Text ist streng genommen falsch, weil 1.5em sich auf
     font-size: 100% statt font-size: 95% bezieht, aber das ebenso falsche
     margin-top: -1px an der ersten Leiste sollte es ausgleichen
 * - Funktioniert in allen Browsern einschließlich IE 6, genau genommen wäre das
     Ganze in dieser Form nur noch ein IE-6-Workaround
 */
div.BoxenVerschmelzen {
	margin: 1.5em 0 0;
	border-style: none;
	clear: both;
}
div.BoxenVerschmelzen div.NavFrame {
	margin-top: -1px;
	border-style: solid;
	padding-top: 2px;
}
 
/* Verschmelzung mit [[Vorlage:NaviBlock]]:
 * - Rahmen der einzelnen Leisten werden komplett entfernt und durch einen neuen
     Rahmen am Container ersetzt
 * - Schriftskalierung muss am Container erfolgen, damit der Abstand zum Text
     stimmt
 * - Funktioniert in allen Browsern einschließlich IE 6
 */
div.BoxenVerschmelzen {
	margin: 1.5em 0 0;
	border: 1px solid #aaa;
	clear: both;
	padding-top: 2px;
	font-size: 95%;
}
div.BoxenVerschmelzen div.NavFrame {
	margin-top: 0;
	border-style: none;
	padding-top: 0;
	font-size: 100%;
}
</syntaxhighlight>
::::Ohne [[Vorlage:NaviBlock]] die Linien wegzubekommen, ist nicht so einfach; m.&nbsp;E. unmöglich, ohne irgendwo Kompromisse (Einfärbung bislang transparenter Hintergründe) zu machen. Ich würde das tendenziell eher sein lassen.
::::Es wäre dann eigentlich nur zu entscheiden, ob es mit der Vorlage anders aussehen darf und wie es dann aussehen soll. Die Umsetzung ist kein Problem. Gruß --[[Benutzer:Entlinkt|Entlinkt]] 21:53, 28. Jun. 2010 (CEST)

Ganz ehrlich, mir ist vorher nie aufgefallen, dass es da Unterschiede gibt. Wenn am Ende – außer dieser kleinen optischen – keine Verbesserung herauskommt, würde ich auf diese Arbeit verzichten. --<span style="font-size:inherit">[[Benutzer:32X|32X]]</span> 19:37, 2. Jul. 2010 (CEST)

:Es wurde die [http://de.wikipedia.org/w/index.php?title=Wikipedia:Fragen_zur_Wikipedia&diff=prev&oldid=76072504 Meinung geäußert], dass „ein Unterschied zum Normalzustand erkennbar sein“ solle. So habe ich das jetzt auch gemacht (keine Linien, aber Doppelpadding weg, weil es nach einem offensichtlichen Bug aussieht). Das erspart mir auch die Notwendigkeit, die [[Vorlage:NaviBlock/Doku|Vorlagendokumentation]] anzupassen. Falls die Linien allgemein bevorzugt werden, würde sich das schon bemerkbar machen, indem die Vorlage zunehmend nicht mehr benutzt wird. --[[Benutzer:Entlinkt|Entlinkt]] 23:18, 2. Jul. 2010 (CEST)
:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Entlinkt|Entlinkt]] 23:18, 2. Jul. 2010 (CEST)</small>

== Zusätzliche Absätze dank [[Vorlage:Link FA|Link FA]] und [[Vorlage:Link GA|Link GA]] ==

Die Ausblendung dieser Vorlagen mittels
<syntaxhighlight lang="css">/* hide the template */
#bodyContent span.FA {
	display: none;
}</syntaxhighlight>
kann aus zwei ganz offensichtlichen Gründen nicht funktionieren: Der Skin Modern hat kein #bodyContent, und für [[Vorlage:Link GA]] müsste auch span.GA berücksichtigt werden.

Es gibt aber noch einen subtileren Grund: MediaWiki besteht anscheinend auf einem Block-Element und erzeugt einen Absatz um die spans herum. Beispiel aus [[Bundespräsident (Deutschland)]]:
<syntaxhighlight lang="html4strict">
<p>
	<span id="interwiki-lt-fa" class="FA"></span>
	<span id="interwiki-vi-fa" class="FA"></span>
</p>
</syntaxhighlight>

Rein theoretisch könnte das sichtbaren zusätzlichen Whitespace am Artikelende verursachen. In der Praxis habe ich noch keinen gesehen; anscheinend fallen die margins dieses Absatzes mit anderen margins zusammen. Der Code sollte trotzdem angepasst werden. Es kann entweder der witzlose Ausblendungsversuch aus dieser Datei entfernt oder in der Vorlage span durch div ersetzt werden. Bei divs erzeugt MediaWiki keine Absätze drumherum. --[[Benutzer:Entlinkt|Entlinkt]] 14:19, 2. Jul. 2010 (CEST)

: Wenn ich es richtig nachvollzogen habe, dann entfernt MediaWiki leere Elemente (<code><nowiki><span></span></nowiki></code>), aber keinen leeren Elemente mit Attribut (<code><nowiki><span id="…"></span></nowiki></code>). Diese leeren Elemente mit Attribut werden hier verwendet, um Flags an JavaScript weiterzureichen. Ob dieses Element ein <code>span</code> oder ein <code>div</code> ist scheint egal zu sein. Browser zeigen leere Elemente anscheinend nicht an. Das <code>display:none</code> kann daher entfallen. Auf jeden Fall ist ein <code>div</code> hier sinnvoller als ein <code>span</code>. --[[Benutzer:Fomafix|Fomafix]] 14:57, 2. Jul. 2010 (CEST)

::Ich meinte vor allem das <code><nowiki><p></nowiki></code>-Element um alles herum. MediaWiki scheint darauf zu bestehen, dass sämtlicher Inhalt des Textfeldbereichs in Block-Elemente verpackt ist, und erzeugt <code><nowiki><p></nowiki></code>-Elemente, um das zu erzwingen. Dieses <code><nowiki><p></nowiki></code>-Element hat margins (sowohl in den User Agent Default Stylesheets als auch in den Skins) und würde sich durch Leerraum bemerkbar machen, wenn die margins nicht zufällig mit anderen zusammenfielen. Eigentlich sollte dieses <code><nowiki><p></nowiki></code> ausgeblendet werden, aber das ist nicht möglich, weil es sich nicht selektieren lässt. Mit divs statt spans kann verhindert werden, dass MediaWiki es überhaupt erzeugt. Die absolut positionierten Vorlagen haben übrigens dasselbe Problem. --[[Benutzer:Entlinkt|Entlinkt]] 15:03, 2. Jul. 2010 (CEST)
::: Genau wegen des automatischen <code>p</code>-Elementes bei <code>span</code> sind <code>div</code> hier sinnvoller als <code>span</code>. --[[Benutzer:Fomafix|Fomafix]] 15:11, 2. Jul. 2010 (CEST)
::: Vorsicht beim generellen Ändern von <code>span</code> auf <code>div</code> bei absolut positionierten Elementen. Wenn eine solches Element im Fließtext verwendet wird, dann muss es ein <code>span</code> sein. Sonst kann es in manchen Browsern zu Darstellungsfehler kommen. Für [[Vorlage:Coordinate]] habe ich da ein Variante einbauen lassen. --[[Benutzer:Fomafix|Fomafix]] 15:23, 2. Jul. 2010 (CEST)
:::: DAS ist in diesem Fall zum Glück egal - die Vorlage da wird gar nicht dargestellt.... ;) --[[Benutzer:Guandalug|Guandalug]] 16:18, 2. Jul. 2010 (CEST)
::::: Bei dieser Vorlage nicht, das ist klar. Hier ist daher auch auf jeden Fall ein <code>div</code> angebracht.<br />Meine Aussage von oben muss ich korrigieren. Leere Elemente können die Darstellung durchaus beeinflussen. Vor allem der <code>margin</code>, wie er bei <code>p</code>-Elementen vorhanden ist. Dieser Abstand bei Verwendung der Vorlage ist wohl bisher niemand aufgefallen. <code>div</code>-Elemente haben normalerweise kein <code>margin</code> und beeinflussen die Darstellung daher üblicherweise nicht. Ein <code>display:none</code> könnte sicherheitshalber weiterhin trotzdem angegeben werden. Es wäre auch im <code>style</code>-Attribut geeignet. --[[Benutzer:Fomafix|Fomafix]] 18:24, 2. Jul. 2010 (CEST)

::::@Fomafix, das Problem kenne ich, aber es betrifft meines Wissens nur [[Vorlage:Editcount]] ([http://de.wikipedia.org/w/index.php?title=Vorlage:Editcount&diff=prev&oldid=76235682 sollte so in Ordnung sein]), [[Vorlage:Coordinate]] (m.&nbsp;E. keine Änderung nötig) und [[Vorlage:CoordinateSky]] (vermutlich wie Editcount, muss ich mir aber noch ansehen).
::::Ansonsten bin ich derselben Meinung: Das überflüssige <code>&lt;p&gt;</code>-Element sollte weg, weil es durchaus Probleme bereiten kann (aktuell gibt es so ein Problem im Vector-Skin mit der CentralNotice). Also in den Vorlagen [[Vorlage:Link FA|Link FA]] und [[Vorlage:Link GA|Link GA]] div statt span, zur Sicherheit auch display:none (gern als style-Attribut, dann werden Artikel mit mehrfacher Einbindung dieser Vorlagen zwar etwas größer, aber das allgemeine Stylesheet bleibt klein), fertig. Änderungen an [[MediaWiki:Common.js]] sind, soweit ich das sehe, nicht nötig. Gruß --[[Benutzer:Entlinkt|Entlinkt]] 19:34, 2. Jul. 2010 (CEST)

:::::Ich hab’s getan ([http://de.wikipedia.org/w/index.php?title=Vorlage:Link_FA&diff=prev&oldid=76249509 1], [http://de.wikipedia.org/w/index.php?title=Vorlage:Link_GA&diff=prev&oldid=76249510 2], [http://de.wikipedia.org/w/index.php?title=MediaWiki:Common.css&diff=prev&oldid=76250743 3]), und es funktioniert anscheinend alles noch, was vorher funktionierte. In den Uraltskins (Cologneblue, Nostalgia, Standard/Klassik) funktioniert überhaupt nichts, aber das liegt nicht an dieser Änderung. --[[Benutzer:Entlinkt|Entlinkt]] 23:18, 2. Jul. 2010 (CEST)
:::::: Nein, das lag an (vermutlich) uralten Fehlern. Ich habe die mal [http://de.wikipedia.org/w/index.php?title=MediaWiki%3ACommon.js&action=historysubmit&diff=76254544&oldid=75748423 ausgemerzt]. Wär' zwar besser gewesen, den Support für das Uraltzeug ganz zu droppen, aber nun gut - SO kompliziert war der Bugfix auch nicht --[[Benutzer:Guandalug|Guandalug]] 00:41, 3. Jul. 2010 (CEST)
:::::::Danke für den Bugfix. Vielleicht lag es zum Teil auch an [[rev:68079]], die am Mittwoch live gegangen ist, aber so ganz blicke ich da nicht durch. Gruß --[[Benutzer:Entlinkt|Entlinkt]] 01:05, 3. Jul. 2010 (CEST)
:::::::: Das mit dem nun unbrauchbaren ''title'' mag daran gelegen haben - das fehlende ''style'' als Parameter nicht, und das sorgte für einen Ausstieg aus der Funktion. --[[Benutzer:Guandalug|Guandalug]] 10:05, 3. Jul. 2010 (CEST)
:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Entlinkt|Entlinkt]] 23:18, 2. Jul. 2010 (CEST)</small>

== font-family /**/: inherit; ==

Die verschiedenen CSS-Klassen für Schriftarten dienen hauptsächlich dazu, das Unvermögen des Windows/Microsoft Internet Explorers zu beheben, dass er keine passenden Schriftarten auswählen kann. In standardkonformen Browsern, die sehr wohl passende Schriftarten auswählen können, sollten diese CSS-Klassen keinen Effekt haben. Dies ist aber derzeit nicht so. Im Gegenteil: Diese CSS-Klassen können völlig unpassende Schriftarten einfügen, so dass die Typographie der Wikipedia-Artikel empfindlich gestört wird. Dies insbesondere in dem Fall, dass man die (meiner Ansicht nach ziemlich hässliche) Schriftart Code2000 installiert haben sollte.

Der jetzige Lösungsvorschlag unter [[Vorlage:Unicode#CSS]] sieht vor, dass man sich bei Wikipedia registrieren und dann die Seite [[Spezial:mypage/monobook.css]] anlegen muss. Das dünkt mich eine ziemliche Zumutung, wenn ich doch eigentlich einen standardkonformen Browser verwende, der die richtige Darstellung eigentlich problemlos zu Stande bringt. Wenn irgendjemand die Darstellung manuell verbessern müsste, dann doch ganz bestimmt nicht diejenigen, die einen standardkonformen Browser verwenden.

Unter [[MediaWiki Diskussion:Common.css/Archiv/1#Fonts]] steht zu lesen, dass der bis IE6 übliche CSS-Hack, nämlich das Hinzufügen von <code>font-family /**/: inherit;</code>, unter IE7 korrigiert worden ist, ohne dass IE7 die Fähigkeit zum Auswählen von Schriften erhalten hätte. Dieser CSS-Hack ist folglich am 22. März 2008 aus Common.css gelöscht worden: [http://de.wikipedia.org/w/index.php?title=MediaWiki:Common.css&diff=44020319]. Seither ist die Darstellung auf standardkonformen Browsern gestört. Ich meinte, wenn man schon unbedingt eine Extra-Behelfslösung für den Internet Explorer ins Common.css aufnimmt, dann doch bitte auf eine Art und Weise, die keine Probleme auf standardkonformen Browsern verursacht.

In der englischen Wikipedia haben sie eine derartige Lösung gefunden: [[:en:Template talk:IPA#Solution for IE6/7 problem]]. Sie belassen dort die Regel <code>font-family /**/: inherit;</code> in Common.css, gewährleisten aber die Darstellung unter IE7 durch eine Spezialregel in Common.js.

Mein Vorschlag:

# Wiedereinfügen von <code>font-family /**/: inherit;</code>. Dadurch ist eine korrekte Darstellung bis IE6 gewährleistet, ohne dass standardkonforme Browser beeinträchtigt würden.
# Einfügen einer speziellen Internet-Explorer-Regel in Common.js, so dass auch IE7 korrekte Schriftarten darstellt, ohne dass standardkonforme Browser beeinträchtigt würden.

Ich habe [[:en:MediaWiki:Common.js]] mit unserem Common.css verglichen und denke, der zusätzliche Code für Common.js müsste etwa wie folgt aussehen:

<pre>if (navigator.appName == "Microsoft Internet Explorer")
{
    /**
     * Ergänzung zu Common.css, ohne die Darstellung in standardkonformen Browsern zu stören.
     */
    if (document.createStyleSheet) {
        document.createStyleSheet().addRule('.Unicode', 'font-family: "Code2000","Sun-ExtA","Arial Unicode MS","NSimSun",sans-serif;');
        document.createStyleSheet().addRule('.Unicode1', 'font-family: "Code2001","Quivira","MPH 2B Damase",sans-serif;');
        document.createStyleSheet().addRule('.Unicode2', 'font-family: "Sun-ExtB","Code2002",sans-serif;');
        document.createStyleSheet().addRule('.IPA', 'font-family: "Quivira","Code2000","Sun-ExtA","DejaVu Sans","Gentium","Arial Unicode MS","Lucida Sans Unicode",sans-serif;');
        document.createStyleSheet().addRule('.IAST', 'font-family: "Code2000","SunExtA","Arial Unicode MS",sans-serif;');
        document.createStyleSheet().addRule('.altitalisch', 'font-family: "Quivira","Code2001","MPH 2B Damase",sans-serif;');
        document.createStyleSheet().addRule('.gotisch', 'font-family: "Quivira","Code2001","MPH 2B Damase",sans-serif;');
        document.createStyleSheet().addRule('.hebrew', 'font-family: "Quivira","Sun-ExtA","Arial Unicode MS","SBL Hebrew","Code2000","MPH 2B Damase",  sans-serif;');
        document.createStyleSheet().addRule('.spanAr', 'font-family: "Arial Unicode MS","Scheherazade","Code2000","DejaVu Sans",sans-serif;');
        document.createStyleSheet().addRule('.music-symbol', 'font-family: "Musical Symbols","Euterpe","Code2001",sans-serif;');
    }
}</pre>

Ich bin nicht sicher, ob alle diese CSS-Klassen wirklich benötigt werden. Ich hoffe, eine korrekte Darstellung für standardkonforme Browser kann wieder gewährleistet werden. -- [[User:J. 'mach' wust|mach]][[User talk:J. 'mach' wust|ᵗᵃˡᵏ]] 12:52, 1. Feb. 2010 (CET)

: [[Benutzer:Entlinkt|Entlinkt]] hat inzwischen zuverlässige CSS-Hacks für IE6 und IE7 eingebaut. --[[Benutzer:Fomafix|Fomafix]] 20:05, 7. Jan. 2011 (CET)
:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Fomafix|Fomafix]] 20:05, 7. Jan. 2011 (CET)</small>

== Nochmal Vorlage:Polytonisch ==

Gibt es eigentlich einen Grund dafür, dass Internet-Explorer-Schriftarten für class="polytonic" noch immer in [[Vorlage:Polytonisch]] definiert werden und nicht hier? Es ist schon unschön genug, dass eine Browser-spezifische Problemlösung ins CSS aufgenommen worden ist, aber diese Problemlösung könnte doch wenigstens zentral an einer Stelle (also hier) versammelt werden, anstatt sie über verschiedene Stellen zu verstreuen. -- [[User:J. 'mach' wust|mach]][[User talk:J. 'mach' wust|ᵗᵃˡᵏ]] 16:31, 21. Feb. 2010 (CET)
: Inzwischen ist alles in [[MediaWiki:Common.css]] mit CSS-Weichen und [[Vorlage:Polytonisch]] verwendet <code>class="polytonic</code>. --[[Benutzer:Fomafix|Fomafix]] 20:08, 7. Jan. 2011 (CET)
:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Fomafix|Fomafix]] 20:08, 7. Jan. 2011 (CET)</small>

== margin auch für float-left ==

Hallo, könnte bitte analog zu <code>margin: 1em 0 1em 1em;</code> bei float-right auch für die float-left-Definitionen ein entsprechendes (1em 1em 1em 0) margin hinzugefügt werden? --&thinsp;<big>[[Benutzer:✓|✓]]</big>&thinsp;<small><sup>[[Benutzer Diskussion:✓|Bergi]]</sup></small> 19:57, 17. Feb. 2011 (CET)
: [http://de.wikipedia.org/w/index.php?title=MediaWiki%3ACommon.css&action=historysubmit&diff=85427195&oldid=85360073 Erledigt]. --[[Benutzer:32X|32X]] 22:03, 17. Feb. 2011 (CET)
::Danke, das ging aber schnell! --&thinsp;<big>[[Benutzer:✓|✓]]</big>&thinsp;<small><sup>[[Benutzer Diskussion:✓|Bergi]]</sup></small> 22:38, 17. Feb. 2011 (CET)
:<small>Archivierung dieses Abschnittes wurde gewünscht von: --[[Benutzer:32X|32X]] 22:03, 17. Feb. 2011 (CET)</small>

== ul.float-right ==

Bitte <code>ul.float-right</code> und <code>ul.float-left</code> ergänzen, damit <code><nowiki><gallery class="float-right"></nowiki></code> wieder einen Abstand um die Bilder erzeugt ([[Hilfe:Bilder#Bilder pro Zeile und Ausrichtung]]). --[[Benutzer:Fomafix|Fomafix]] 00:13, 18. Feb. 2011 (CET)
: [http://de.wikipedia.org/w/index.php?title=MediaWiki:Common.css&diff=85481740&oldid=85427195 Erledigt.] --[[Benutzer:32X|32X]] 11:57, 19. Feb. 2011 (CET)
<code>ul.centered</code> muss auch noch ergänzt werden, damit <code><nowiki><gallery class="centered" perrow="4"></nowiki></code> wieder zentriert wird. Ohne <code>perrow</code> wird es damit noch nicht zentriert, aber das wird mit [[Bugzilla:27540|Bug 27540]] behoben. --[[Benutzer:Fomafix|Fomafix]] 18:09, 19. Feb. 2011 (CET)
: Ebenfalls [http://de.wikipedia.org/w/index.php?title=MediaWiki:Common.css&diff=85549853&oldid=85481740 erledigt.] Kommen noch weitere Bearbeitungswünsche Tröpfchenweise? --[[Benutzer:32X|32X]] 22:04, 20. Feb. 2011 (CET)
:<small>Archivierung dieses Abschnittes wurde gewünscht von: --[[Benutzer:32X|32X]] 22:04, 20. Feb. 2011 (CET)</small>

== toclimit ==

Wäre es vielleicht möglich, aus [[en:MediaWiki:Common.css]] die class "toclimit" hier einzufügen? Dann könnte man nämlich auch die Vorlage [[en:Template:TOClimit]] hier einbinden, mit der man bestimmte Überschriften-Ebenen im Inhaltsverzeichnis ausblenden kann. Gruß --[[Benutzer:D.H|D.H]] 12:42, 7. Dez. 2008 (CET)
: Seit [{{fullurl:MediaWiki:Common.css|diff=85664937&oldid=prev}} 23. Februar 2011] existieren die CSS-Definitionen und die [[Vorlage:TOC limit]]. --[[Benutzer:Fomafix|Fomafix]] 23:08, 1. Sep. 2011 (CEST)
:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Fomafix|Fomafix]] 23:08, 1. Sep. 2011 (CEST)</small>

== Protokollrelative URLs ==

Hallo, auf Wikipedia wurden die protokollrelativen URLs eingeführt (beispielsweise von fullurl erzeugt, auch &#123;&#123;SERVER&#125;&#125; hat jetzt ein external-Icon: [{{SERVER}}]). Das erfordert/ermöglicht einige Anpassungen:
<syntaxhighlight lang="css">
/* Bei URLs, die auf unser Projekt und verwandte Projekte verweisen, den Pfeil ausblenden
 * Dieser Pfeil dient nur dazu, auf externe Ziele hinzuweisen
 * Auf den Einsatz der Klasse "plainlinks" kann dadurch verzichtet werden
 */
div#content a.external[href^="//de.wikipedia.org"],
div#content a.external[href^="http://de.wikipedia.org"],
div#content a.external[href^="https://secure.wikimedia.org/wikipedia/de/"],
div#content a.external[href^="http://toolserver.org"],
#mw_content a.external[href^="//de.wikipedia.org"],
#mw_content a.external[href^="http://de.wikipedia.org"],
#mw_content a.external[href^="https://secure.wikimedia.org/wikipedia/de/"],
#mw_content a.external[href^="http://toolserver.org"] {
	background: none;
	padding-right: 0;
}</syntaxhighlight>
sowie
<syntaxhighlight lang="css">/* Anpassungen für [[:Template:Link_FA]] */
/* change the bullets for links to special articles */
#p-lang li.FA {
	/* hier immer auch linkFA_bullet in Common.js mit anpassen für die älteren skins! */
	list-style-image: url(//upload.wikimedia.org/wikipedia/commons/d/d0/Monobook-bullet-star-transparent.png);
}
/* change the bullets for links to special articles */
#p-lang li.GA {
	/* hier immer auch linkGA_bullet in Common.js mit anpassen für die älteren skins! */
	list-style-image: url(//upload.wikimedia.org/wikipedia/commons/a/a1/Monobook-bullet-star-gray.png);
}</syntaxhighlight>
Danke an den nächsten Admin für schnelle Umsetzung, --&thinsp;<big>[[Benutzer:✓|✓]]</big>&thinsp;<small><sup>[[Benutzer Diskussion:✓|Bergi]]</sup></small> 16:34, 28. Sep. 2011 (CEST)

: ist drin, falls nötig bitte meckern. -- [[Benutzer:D|∂]] 17:19, 28. Sep. 2011 (CEST)
[{{fullurl:MediaWiki:Common.css|diff=94156945&oldid=prev}} erledigt]. --[[Benutzer:Fomafix|Fomafix]] 12:53, 6. Okt. 2011 (CEST)
:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Fomafix|Fomafix]] 12:53, 6. Okt. 2011 (CEST)</small>

== Tabellensortierung ==

Durch 1.18 werden die Pfeile bei der Tabellensortierung durch ein background-image gesetzt. Ist jetzt zusätzlich eine Hintergrundfarbge für die Überschrift angegeben (''hintergrundfarbeX''), so überschreibt diese mit <code>background: none repeat scroll 0 0 <farbe>;</code> die Pfeile. Änderung in <code>background-color: <farbe>;</code> sollte das Problem beheben. --[[Benutzer:Steef389|Steef]]&nbsp;<sup>[[Benutzer_Diskussion:Steef389|389]]</sup> 11:49, 6. Okt. 2011 (CEST)

:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Guandalug|Guandalug]] 12:19, 6. Okt. 2011 (CEST)</small>

== CSS-Kommentare ==

Hallo, [{{fullurl:MediaWiki:Common.css|curid=1115645&diff=95637711}} hier] wurden [http://de.selfhtml.org/css/formate/einbinden.htm#kommentare ungeeignete Kommentarzeichen] verwendet.  Könnte das bitte jemand korrigieren?  Danke --[[Benutzer:Wiegels|Wiegels]] [[Benutzer Diskussion:Wiegels|„…“]] 23:57, 5. Nov. 2011 (CET)
:Ich war mal so frei und habe das korrigiert (ändert ja nichts an der Funktionsweise) - [[Benutzer:Hoo_man|Hoo man]] ([[Benutzer_diskussion:Hoo_man|Diskussion]]) 00:50, 6. Nov. 2011 (CET)
::Es ändert etwas an der Funktionsweise, vorher gab es Syntaxfehler, jetzt ist es richtig. [[Benutzer:Umherirrender|Der Umherirrende]] 11:27, 6. Nov. 2011 (CET)

:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Umherirrender|Der Umherirrende]] 11:27, 6. Nov. 2011 (CET)</small>

== Class gallery, gallerybox usw. ==

Hallo Zusammen, ich bin auf der Suche nach der CSS-Datei in der die CSS-Klassen gallery, gallerybox usw. definiert sind. Leider kann ich sie nirgends finden. Kann jemand von euch mir weiterhelfen? --[[Benutzer:Cepheiden|Cepheiden]] 17:31, 30. Nov. 2011 (CET)

: Mhh kaum hat man geschrieben, schon findet man die Datei http://de.wikipedia.org/w/skins-1.5/common/commonPrint.css. Aber wo bringe ich am Besten Änderungsvorschläge ein? --[[Benutzer:Cepheiden|Cepheiden]] 17:34, 30. Nov. 2011 (CET)

:: Wenn du sie in der Datei ändern willst, dann auf [[WP:VV]] oder gleich bei Bugzilla. Achte aber darauf, dass es zumindest in Vector gut aussieht, sonst wird es ignoriert. Wenn du sie global skinspezifisch überschrieben haben möchtest, ebenfalls WP:VV oder Bugzilla. Wenn du sie lokal (dewp) überschrieben haben möchtest, am besten hier (oder bei Skinspezifischem für Vector und Monobook auf der jeweiligen Disk), auf WP:VV oder WP:AA eher nicht. --&thinsp;[[Benutzer:✓|<big title="Benutzer:Bergi">✓</big>]]&thinsp;<small><sup>[[Benutzer Diskussion:✓|Bergi]]</sup></small> 17:50, 30. Nov. 2011 (CET)
: Unter http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/skins/common/shared.css?view=markup findest Du die zukünftigen CSS-Klassen für den Bildschirm und unter http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/skins/common/commonPrint.css?view=markup für die Druckversion. Die bei uns aktuell aktiven CSS-Dateien sind unter http://svn.wikimedia.org/viewvc/mediawiki/branches/wmf/1.18wmf1/skins/common/. --[[Benutzer:Fomafix|Fomafix]] 19:44, 30. Nov. 2011 (CET)

:: Ich danke euch, ich werde da mal schauen. Grüße --[[Benutzer:Cepheiden|Cepheiden]] 07:26, 5. Dez. 2011 (CET)
:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Fomafix|Fomafix]] 19:44, 30. Nov. 2011 (CET)</small>

== FirstHeading auf der Hauptseite ==

durch den Eintrag
<syntaxhighlight lang="css">
 /* Überschrift verbergen */
 body.page-Wikipedia_Hauptseite h1.firstHeading {
  display: none;
 }
</syntaxhighlight>
wird die Überschrift auf der Hauptseite ausgeblendet, dies finde ich sinnvoll. Nur wird durch die Anweisung auch die Überschrift in der Versionsgeschichte, im Diff und beim Bearbeiten unterdrückt. Dies lässt die Oberfläche dort etwas komisch aussehen. Kennt jemand eine Lösung, wie man mit CSS erreichen kann, das dort keine Ausblendung erfolgt? [[Benutzer:Umherirrender|Der Umherirrende]] 16:58, 19. Dez. 2008 (CET)
: Der Wunsch ist berechtigt. Derzeit kann mit CSS ein solches bedingtes Ausblenden nicht erreicht werden, denn es gibt mit CSS keine Möglichkeit zu wissen, was weiter unten auf der Seite kommt. Einzige Möglichkeit wäre MediaWiki zu erweitern und ein Kenner (CSS-Klassen) am body anbringen zu lassen, der angibt, welche Aktion derzeit angezeigt wird. Dann könnte MediaWiki aber auch selbst die Überschrift ausblenden.
: Einen bösen CSS-Hack habe ich aber, der ungefähr das gewünschte bewirkt:
<syntaxhighlight lang="css">
#hauptseite {
  position:relative;
  top:-4em;
  margin-bottom:-4em;
}
</syntaxhighlight>
: --[[Benutzer:Fomafix|Fomafix]] 13:35, 19. Jun. 2009 (CEST)
:: Im Zusammenhang: <s>[[bugzilla:24895|Bug 24895]]</s> [[bugzilla:4438|Bug 4438]] --[[Benutzer:Umherirrender|Der Umherirrende]] 21:56, 23. Aug. 2010 (CEST) <small>korrigiert von <big>[[Benutzer:✓|✓]]</big>&thinsp;<small><sup>[[Benutzer Diskussion:✓|Bergi]]</sup></small> 11:43, 24. Aug. 2010 (CEST)</small>
:::Notiz für den Fall, dass die Sache irgendwann einmal durch Einführung einer Klasse <code>action-view</code> am <code>body</code>-Element angegangen wird: Der IE 6 unterstützt keine Selektoren mit mehreren Klassen an einem Element bzw. wertet dann nur die letzte Klasse aus. Man darf also nicht <code>body.page-Wikipedia_Hauptseite.action-view</code> schreiben (das würde die Überschrift überall ausblenden), sondern <code>body.action-view.page-Wikipedia_Hauptseite</code> (dann bleibt es im IE 6 beim jetzigen Verhalten; anderen Browsern ist die Reihenfolge egal). --[[Benutzer:Entlinkt|Entlinkt]] 00:27, 27. Aug. 2010 (CEST)
:::: Funktioniert es beim IE6 richtig, wenn <code>action-view</code> am <code>html</code>-Element ist mit <code>html.action-view body.page-Wikipedia_Hauptseite</code>? --[[Benutzer:Fomafix|Fomafix]] 06:12, 27. Aug. 2010 (CEST)
::::: Ja, aber die DTDs von HTML4 und XHTML1 erlauben kein <code>class</code>-Attribut am <code>html</code>-Element. Funktionieren tut es trotzdem in allen Browsern, weshalb es in HTML5 erlaubt ist. Ich habe allerdings in [[:bugzilla:24915|Bug 24915]] angeregt, dann gleich alle Klassen von <code>body</code> nach <code>html</code> zu verschieben. Folglich würde es im IE 6 dann wieder nicht gehen.
::::: Testfall für den IE-6-Bug (an welchem Element die Klassen stehen, ist egal, der Bug betrifft alle Elemente mit multiplen Klassen):
<pre>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Multiple class testcase</title>
<style>
.green { background: lime }
.red.green { background: red }
</style>
</head>
<body>
<p class="green">This should be green, not red.</p>
</body>
</html>
</pre>
::::: Wie auch immer: Das Problem ist zurzeit mit CSS nicht lösbar, weil die verschiedenen „Ansichten“ einer Seite (URL-Parameter ''action'') in CSS nicht unterscheidbar sind. Mit JavaScript ginge es aber, weil die „Ansicht“ dort als <code>wgAction</code> verfügbar ist. Gruß --[[Benutzer:Entlinkt|Entlinkt]] 06:29, 27. Aug. 2010 (CEST)

Ab sofort hat der <code>body</code> die Klasse <code>action-view</code>, wenn die Seite betrachtet wird, der Vorschlag kann also mit obigem Code umgesetzt werden. --[[Benutzer:Schnark|Schnark]] 10:31, 6. Okt. 2011 (CEST)
: Ja, das funktioniert. Es muss dazu das bisherige
<syntaxhighlight lang="css">
body.page-Wikipedia_Hauptseite #catlinks,
body.page-Wikipedia_Hauptseite h1.firstHeading,
body.page-Wikipedia_Hauptseite #contentSub {
	display: none;
}
</syntaxhighlight>
ersetzt werden durch
<syntaxhighlight lang="css">
body.page-Wikipedia_Hauptseite #catlinks,
body.page-Wikipedia_Hauptseite.action-view h1.firstHeading,
body.page-Wikipedia_Hauptseite.action-view #contentSub {
	display: none;
}
</syntaxhighlight>
--[[Benutzer:Fomafix|Fomafix]] 11:08, 6. Okt. 2011 (CEST)
: Die CSS-Klasse <code>action-view</code> ist auch einem Versionsvergleich aktiv ([{{fullurl:Wikipedia:Hauptseite|diff=0&oldid=prev}} Beispiel]). Dort würde trotz der obigen Änderung weiterhin die Überschrift ausgeblendet werden. Zumindest wird die Überschrift bei allen anderen Aktionen ausgeblendet. Daher sollte die Änderung umgesetzt werden.
: Manchmal wird bei Versionsvergleichen zusätzlich die Aktion <code>historysubmit</code> angegeben ([{{fullurl:Wikipedia:Hauptseite|diff=0&oldid=prev&action=historysubmit}} Beispiel]). Diese Aktion entsteht, wenn in der Versionsgeschichte auf ''Gewählte Versionen vergleichen'' geklickt wird. Mit [[rev:108341]] wird die Aktion dort entfernt und es gilt dann bei Versionvergleichen überall die Aktion <code>view</code>.
: Der Code zum Erzeugen der CSS-Klasse ([[bugzilla:4438|Bug 4438]]) wird derzeit von [[rev:91871]] auf [[rev:108345]] umgeändert. An dem Ergebnis ändert das aber nichts. --[[Benutzer:Fomafix|Fomafix]] 11:17, 8. Jan. 2012 (CET)
:: Dirzuliebe [//de.wikipedia.org/w/index.php?title=MediaWiki:Common.css&diff=prev&oldid=98084936 geändert.] --[[Benutzer:32X|32X]] 12:42, 8. Jan. 2012 (CET)
:<small>Archivierung dieses Abschnittes wurde gewünscht von: --[[Benutzer:32X|32X]] 12:42, 8. Jan. 2012 (CET)</small>

== Potenzielle Konflikte bei verschachtelten Tabellen ==

Alle Regeln, die Selektoren wie <code>table tr</code> oder <code>table td</code> o.&nbsp;ä. nutzen, haben das Problem, dass sie nicht nur auf die aktuelle Tabelle, sondern auch auf etwaige verschachtelte Tabellen zutreffen. Zu beheben wäre das mit <code>table > tbody > tr</code> bzw. <code>table > tbody > tr > td</code>, was aber meist nicht gemacht wird, weil der IE 6 den Kindselektor <code>E > F</code> nicht versteht.

Bei der Definition der Zebra-Tabellen hätten wir allerdings ohne Weiteres die Möglichkeit, den potenziellen Konflikt zu vermeiden, weil die alternierende Selektion mittels Pseudoklasse <code>:nth-child()</code> im IE 6 sowieso nicht funktioniert (sie funktioniert noch nicht mal im IE 8). Wäre es deshalb sinnvoll, die Definition
<syntaxhighlight lang="css">
table.wikitable.zebra tr:nth-child(even) {
	background: white;
}
</syntaxhighlight>
durch
<syntaxhighlight lang="css">
.wikitable.zebra > tbody > :nth-child(even) {
	background: white;
}
</syntaxhighlight>
zu ersetzen? Momentan hätte das keine Nebenwirkungen. Falls in Zukunft irgendwann einmal <code>thead</code>- und <code>tfoot</code>-Elemente unterstützt würden, hätte es die Nebenwirkung, dass diese nicht gestreift wären. Das halte ich allerdings für einen Vorteil, weil sie dann wahrscheinlich anders abgesetzt wären und ein durchgehendes Alternieren über <code>thead</code>, <code>tfoot</code> und <code>tbody</code> hinweg sowieso nicht möglich ist. --[[Benutzer:Entlinkt|Entlinkt]] 05:35, 5. Aug. 2010 (CEST)
: Unter [[Wikipedia:Verbesserungsvorschläge/Archiv/2010/März#Alternierende Tabellen-Hintergrundfarbe bei sortierbaren Tabellen]] habe ich bereits die Verwendung von <code>></code> vorgeschlagen. Untertabellen bei Zebratabellen sind sicherlich unüblich, aber es ist trotzdem sinnvoll die Wirkung nur auf die aktuelle Tabelle zu beschränken.
: Weiter habe ich auf Probleme mit Hintergrundfarben der Form <code>|- class="hintergrundfarbe''x''"</code> an geraden Tabellenzeilen hingewiesen. Dieses Problem könnte entweder an der Definition von <code>.hintergrundfarbe''x''</code> mit <code>!important</code> oder mit Erhöhung der [http://www.w3.org/TR/CSS2/cascade.html#specificity Selektor-Spezifität] gelöst werden oder mit:
<syntaxhighlight lang="css">
.wikitable.zebra > tbody > :nth-child(even):not(.hintergrundfarbe1):not(.hintergrundfarbe2):not(.hintergrundfarbe3):not(.hintergrundfarbe4):not(.hintergrundfarbe5):not(.hintergrundfarbe6):not(.hintergrundfarbe7):not(.hintergrundfarbe8):not(.hintergrundfarbe9) {
	background: white;
}
</syntaxhighlight>
: --[[Benutzer:Fomafix|Fomafix]] 09:43, 5. Aug. 2010 (CEST)

::Untertabellen (mit nur einer Zeile) erzeugt zum Beispiel die [[Vorlage:Positionskarte]]. Dass es damit keine Probleme gibt, ist der Tatsache geschuldet, dass die Zebra-Definition nur gerade Zeilen einfärbt. Da dies letztlich Zufall ist, sollte es m.&nbsp;E. korrigiert werden.
::An individuell gefärbte Zeilen hatte ich jetzt gar nicht gedacht, weil sie sich mit Zebra-Tabellen m.&nbsp;E. ohnehin nicht besonders gut vertragen. Auf <code>!important</code> würde ich in dieser Datei eigentlich ganz gern verzichten, wenn es nicht unbedingt nötig ist, damit es als „letzte Option“ für Benutzerstylesheets erhalten bleibt.
::Wie wäre es mit folgendem:
<syntaxhighlight lang="css">
.wikitable.zebra > tbody > :nth-child(even):not([class*="hintergrundfarbe"]) {
	background: white;
}
</syntaxhighlight>
::So bleibt es relativ kurz und übersichtlich und löst m.&nbsp;E. alle Probleme. (Ein hypothetisches Problem gäbe es mit Klassen, die die Zeichenkette „hintergrundfarbe“ enthalten und etwas anderes bedeuten, aber das kommt wohl nirgends vor.) Gruß --[[Benutzer:Entlinkt|Entlinkt]] 17:25, 5. Aug. 2010 (CEST)
Bei MediaWiki werden derzeit die Definitionen für <code>wikitable</code> mit [[rev:107669]] und follow-ups auf den [http://www.w3.org/TR/CSS2/selector.html#child-selectors child selector] (neuerdings [http://www.w3.org/TR/css3-selectors/#child-combinators child combinator]) umgestellt. Daher solle die Definition hier auch umgestellt werden. --[[Benutzer:Fomafix|Fomafix]] 19:16, 8. Jan. 2012 (CET)

:<small>Archivierung dieses Abschnittes wurde gewünscht von: --[[Benutzer:32X|32X]] 21:52, 8. Jan. 2012 (CET)</small>

== Listen in Tabellen ==

{| class="wikitable toptextcells float-right" style="text-align:right;"
| normal
|
* Liste
|-
|
Text in &lt;p&gt;
|
* Liste
|-
|<p style="margin-top:.3em;">Text mit CSS</p>
|
* Liste
|}
Hallo, vor allem in Infoboxen gibt es Zeilen, in denen Text und Listen nebeneinanderstehen. Dabei fällt das ungleiche margin-top unangenehm auf; besser wird es wenn man per Zeilenumbruch den Text in einen Absatz zwingt (siehe rechts). Allerdings gibt es immer noch einen Unterschied zwischen .3 und .4em, den es zu beheben gilt. Ob man für beide Elemente 0.3 oder 0.4em macht ist mir egal, dennoch sollte man zum Systemtext so etwas hinzufügen:
<syntaxhighlight lang="css">
table ul, table p {
   margin-top: .3em;
}
/* oder auch etwas spezifischer, selbst wenn nicht alle den >-Selektor verstehen: */
td > ul, td > p {
   margin-top: .4em;
}</syntaxhighlight>
--&thinsp;<big>[[Benutzer:✓|✓]]</big>&thinsp;<small><sup>[[Benutzer Diskussion:✓|Bergi]]</sup></small> 20:08, 21. Aug. 2010 (CEST)

: [http://de.wikipedia.org/w/index.php?diff=85793039&oldid=85664937] Danke! --&thinsp;<big>[[Benutzer:✓|✓]]</big>&thinsp;<small><sup>[[Benutzer Diskussion:✓|Bergi]]</sup></small> 21:30, 26. Feb. 2011 (CET)

:<small>Archivierung dieses Abschnittes wurde gewünscht von: --[[Benutzer:32X|32X]] 21:52, 8. Jan. 2012 (CET)</small>

== weitere Projekt-URL ==

Hallo, könnte bitte jemand zu den entsprechenden Abschnitt mit http://upload.wikimedia.org ergänzen (zu Folgendem):
<syntaxhighlight lang="css">
/* Bei URLs, die auf unser Projekt und verwandte Projekte verweisen, den Pfeil ausblenden
 * Dieser Pfeil dient nur dazu, auf externe Ziele hinzuweisen
 * Auf den Einsatz der Klasse "plainlinks" kann dadurch verzichtet werden
 */
div#content a.external[href^="http://de.wikipedia.org"],
div#content a.external[href^="https://secure.wikimedia.org/wikipedia/de/"],
div#content a.external[href^="http://toolserver.org"],
div#content a.external[href^="http://upload.wikimedia.org"],
#mw_content a.external[href^="http://de.wikipedia.org"],
#mw_content a.external[href^="https://secure.wikimedia.org/wikipedia/de/"],
#mw_content a.external[href^="http://toolserver.org"],
#mw_content a.external[href^="http://upload.wikimedia.org/"] {
	background: none;
	padding-right: 0;
}</syntaxhighlight>--&thinsp;<big>[[Benutzer:✓|✓]]</big>&thinsp;<small><sup>[[Benutzer Diskussion:✓|Bergi]]</sup></small> 15:37, 13. Sep. 2010 (CEST)

:Wo besteht ein Bedarf dafür? In der Regel sollte sowieso auf die Beschreibungsseiten und nicht direkt auf die Dateien verlinkt werden. [[Special:Linksearch/upload.wikimedia.org]] listet hauptsächlich Diskussionsseiten und CSS- und JavaScript-Dateien auf (insgesamt 3749 Links). --[[Benutzer:Entlinkt|Entlinkt]] 02:20, 14. Sep. 2010 (CEST)
::<s>Natürlich ist der Bedarf nicht so groß wie bei den anderen Domains</s>, aber immer immerhin imho hoch genug um es dazuzunehmen. Auch auf Dateibeschreibungen wird auf upload… verlinkt. Wieso sollten Diskussionsseiten eigentlich nicht wichtig sein? Der einzige Grund für solche Links im ANR zu stehen ist wohl der Geohack. Ups: 2717 für http://de.wikipedia.org, 1109 für https://secure.wikimedia.org/wikipedia/de/ (und über 200000 für http://toolserver.org :-). --&thinsp;<big>[[Benutzer:✓|✓]]</big>&thinsp;<small><sup>[[Benutzer Diskussion:✓|Bergi]]</sup></small> 17:52, 14. Sep. 2010 (CEST)
:::Hm, ich dachte jetzt eigentlich mehr an Beispiele von Seiten, die besonders von dem Vorschlag profitieren würden, damit man sich ein Bild machen kann … Es stimmt zwar, dass Dateibeschreibungsseiten auf upload.wikimedia.org verlinken, die Links auf den Beschreibungsseiten haben aber kein <code>class="external"</code> und deshalb sowieso auch kein Symbol.
:::Die Rückfrage hat übrigens durchaus einen Grund. Viele Benutzer schalten diese Symbole für sich wieder ein. Bei Direktlinks auf Dateien wäre das Abschalten meiner Meinung nach auch deshalb nochmals unvorteilhafter, weil manche Dateitypen (Audio, Video, PDF) spezielle Symbole haben, die mit dem Vorschlag ebenfalls weg wären. Ich weiß nicht, ob das so gut ankommt. --[[Benutzer:Entlinkt|Entlinkt]] 20:57, 14. Sep. 2010 (CEST)
::::Mit Dateibeschreibung meinte ich so etwas wie [[:Datei:Grosses Landeswappen Baden Wuerttemberg.svg|hier]], die Links zu den Versionen kommen ja von MW und stehen nicht auf der Liste. Ob die Symbole ein- oder ausgeschalten sind, muss jeder selbst entscheiden, jedoch gehört upload auf alle Fälle zu den Projekten, und diese gemeinsam ein oder aus. Wegen der Dateitypen bin ich mir unsicher, doch die normalen Links sollten auf alle Fälle von dem [[Datei:Icon External Link.png]] befreit werden <small>(Es auf diese einzuschränken hätte allerdings hässliches CSS zur Folge)</small>. --&thinsp;<big>[[Benutzer:✓|✓]]</big>&thinsp;<small><sup>[[Benutzer Diskussion:✓|Bergi]]</sup></small> 17:13, 15. Sep. 2010 (CEST)
Weblinks auf ''upload.wikimedia.org'' nicht mit einem Symbol zu markieren finde ich unnötig. Es sind nur sehr wenige Links, die von dieser Änderung betroffen sind.
* Im Artikel [[Kaurischnecken]] werden diese Links als Quellenangaben verwendet. Dort sind Links auf ''upload.wikimedia.org'' genauso extern, wie Links auf ''en.wikipedia.org''. Wer interne Links haben will kann die internen Links auf die Dateibeschreibungsseiten verwenden: <code><nowiki>[[:Datei:…]]</nowiki></code>.
* Im Artikel [[Procol Harum]] wird http://upload.wikimedia.org/wikipedia/commons/1/1e/Air_%28Bach%29.ogg verlinkt. Sinnvoller wäre hier die Schreibweise <code><nowiki>{{filepath:Air (Bach).ogg}}</nowiki></code>. Seitdem protokollrelative Links aktiviert sind muss die Ausgabe hier mit <code>[…]</code> explizit als Weblink angegeben werden: [{{filepath:Air (Bach).ogg}}] statt {{filepath:Air (Bach).ogg}}. Weil die Dateiendung <code>.ogg</code> ist, erzeugt MediaWiki hier ein Lautsprechersymbol statt einem Pfeil. Mit der oben vorgeschlagenen Änderung würde das Symbol fehlen.
Ich sehe daher keine Änderung für notwendig. --[[Benutzer:Fomafix|Fomafix]] 15:22, 8. Jan. 2012 (CET)
::es gibt auch noch [[Media:Air (Bach).ogg]] oder auch {{Vorlage|Audio}}. Ein Direktlink auf .ogg hat den Nachteil, das kein Player da ist, nicht jeder Rechner kann das direkt abspielen. [[Benutzer:Umherirrender|Der Umherirrende]] 16:13, 8. Jan. 2012 (CET)
::: An <code><nowiki>[[Media:…]]</nowiki></code> habe ich gar nicht gedacht. Damit ist der oben genannte Vorschlag für ''upload.wikimedia.org'' definitiv unnötig. --[[Benutzer:Fomafix|Fomafix]] 17:50, 8. Jan. 2012 (CET)
:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Fomafix|Fomafix]] 15:22, 8. Jan. 2012 (CET)</small>

== Versionsunterschiede in nicht-verkleinerter Schriftgröße ==

Ich bitte darum, die Übernahme der Zeile 
 table.diff * td {font-size:100% !important;}
zu erwägen. Das Anzeigen der Unterschiede zwischen 2 oder mehr Versionen ist ein zentrales Werkzeug, das permanent benutzt und in dem v.a. sehr genau hingesehen wird. Die Verlängerung des jeweiligen Webdokuments ist durch die größere „Augenfreundlichkeit“ mE mehr als ausgeglichen. --[[Benutzer Diskussion:Hæggis|Hæ]]<span style="color:#002bb8">gg</span>[[Benutzer:Hæggis|is]] 22:35, 4. Okt. 2010 (CEST)
: Die Schriftgröße beim Versionsvergleich sollte für alle Benutzer in allen Wikis gleich sein. MediaWiki versucht her einen Kompromiss für alle Benutzer mit kleinem, wie mit großem Bildschirm zu erreichen. Deine persönliche Schriftgröße kannst Du in Deiner [[Benutzer:Hæggis/common.css]] oder [[Benutzer:Hæggis/vector.css]] selbst einstellen, wie Du bereits gemacht hast.
: Mit [[rev:106884]] und [[rev:107127]] wurde die Schriftgröße übrigens von <code>font-size: smaller;</code> auf <code>font-size: 88%;</code> geändert. --[[Benutzer:Fomafix|Fomafix]] 15:41, 8. Jan. 2012 (CET)
:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Fomafix|Fomafix]] 15:41, 8. Jan. 2012 (CET)</small>

== Miniatur-Grafiken mit transparentem Hintergrund ==

In der en:WP ist der Hintergrund von Thumbnails mit transparentem Hintergrund auf weiß eingestellt, so dass er sich von dem hellgrauen Rahmen abhebt:

 /* Makes the background of a framed image white instead of gray. */
 /* Only visible with transparent images. */
 div.thumb img.thumbimage {
     background-color: #fff;
 } 
optisches Ergebnis: [http://imageshack.us/photo/my-images/17/16756728.png/]

Bei uns fehlt diese Einstellung, dadurch ist der Grafikhintergrund im gleichen Grau wie der Rahmen: [http://imageshack.us/photo/my-images/593/48921746.png/]

Ich fänds schön wenn wir das hier so machen könnten wie die en:WP. Wenn man auf die Miniatur klickt, erhält man ja auch eine Grafik mit weißem Hintergrund. --[[Benutzer:PM3|PM3]] 00:05, 10. Mai 2011 (CEST)
: Ich finde das ist annehmbar und dafür (spart auch die Streitereien bei diversen Bildern ob der Hintergrund weiß oder transparent sein muss) --&nbsp;[[Benutzer:Perhelion|Perhelion]] 00:10, 10. Mai 2011 (CEST)

:: Ich kanns leider nicht selbst ändern. Liest hier ein Admin mit, der das machen kann? --[[Benutzer:PM3|PM3]] 05:08, 15. Mai 2011 (CEST)
[[Datei:Potencé et contre-potencé.png|miniatur|90px|Mäander]]
: {{Contra}} Es gibt Bilder, bei denen zwischen transparent und weiß unterschieden wird. Bei dem Bild rechts aus dem Artikel [[Mäander (Heraldik)]] ist die Spitze des Wappens bei weißem Hintergrund schlecht erkennbar. Außerdem hätten durch die obige Definition Galerien und Miniaturbilder nicht die gleiche Hintergrundfarbe. --[[Benutzer:Fomafix|Fomafix]] 08:59, 15. Mai 2011 (CEST)
::Im Moment haben Miniaturen und Vollgrafiken (klick mal auf die Minatur rechts!) nicht die gleiche Hintegrundfarbe. Natürlich ist das Ziel, dass die Anzeige überall gleich ist. Die Referenz kann aber doch nur die "Großanzeige" der Grafik sein, und Miniaturen und Galerien sollten das dann identisch wiedergeben. 
::Nunja, da das hier wohl auf die Schnelle nix wird, bekommen meine selbstgemachten Grafiken nun halt alle weiße Hintergründe. --[[Benutzer:PM3|PM3]] 09:39, 15. Mai 2011 (CEST)
::: Beim Skin Monobook haben die Bilder in Vollansicht auch einen farbigen Hintergrund: [{{fullurl:Datei:Potencé et contre-potencé.png|useskin=monobook}} Beispiel mit Monobook] --[[Benutzer:Fomafix|Fomafix]] 09:51, 15. Mai 2011 (CEST)
:::: Oops. Ok, das ist ein gutes Argument gegen meinen Vorschlag. --[[Benutzer:PM3|PM3]] 10:10, 15. Mai 2011 (CEST)
::::: In der französischen Wikipedia wird in der Vollbildansicht sogar noch ein Schachbrettmuster hinterlegt, damit transparente Flächen besser zu sehen sind: [[:fr:Fichier:Potencé et contre-potencé.png]]. --[[Benutzer:Fomafix|Fomafix]] 10:16, 15. Mai 2011 (CEST)
:::::: -> [[:fr:Fichier:Fukushima Dosis qtl1 en.svg]]
:::::: ... und sowas zwingt einen dann halt dazu, weiße Hintergründe in Grafiken einzufügen, bei denen es eigentlich nicht nötig wäre. Wenn man die dann auf einer Seite mit nicht-weißem Basishintergrund anzeigt, sieht es Scheiße aus. 
:::::: Es bräuchte wohl eine andere technische Lösung. Zum Beispiel einen zusätzlichen Paramter für Miniaturen, mit dem man festlegt ob transparente Hintergründe in der Farbe des Minatur-Rahmens oder des Text-Hintergrunds angezeigt werden sollen. --[[Benutzer:PM3|PM3]] 10:26, 15. Mai 2011 (CEST)

Mit [[Wikipedia:Projektneuheiten#Vorschau auf Version 1.19|MediaWiki 1.19]] werden alle Projekte in der Dateibeschreibungsseite ein gemustertes Hintergrundbild beim drüberfahren haben: „''(Softwareneuheit)'' Bei PNGs mit transparentem Hintergrund wird auf der Dateibeischreibungsseite der gemusterte Hintergrund in den transparenten Bildteilen erst angezeigt, wenn die Maus über dem Bild schwebt ([[translatewiki:File:Wappen Koeln.svg|Beispiel im Translatewiki]], [[Bugzilla:26470|Bug 26470]], [[rev:96270]]).“ --[[Benutzer:Fomafix|Fomafix]] 13:00, 6. Okt. 2011 (CEST)
: Ein Bild mit einem transparenten Hintergrund zu versehen, dann aber eine weißen Hintergrundfarbe zu fordern, ist nicht ganz konsistent. Die Hintergrundfarbe von Miniaturbildern ist ein helles Grau und ist daher meiner Meinung nach als neutraler Hintergrund geeignet – auch für das oben aufgeführte Diagramm. Eine generelle weiße Hintergrundfarbe für Miniaturbilder verhindert die Möglichkeit bei Bildern zwischen weiß und transparent zu unterscheiden, wie es bei dem oben aufgeführten Wappen zu sehen ist. Vielleicht bietet MediaWiki irgendwann mal die Möglichkeit bei Miniaturbildern die Hintergrundfarbe explizit individuell anzugeben. --[[Benutzer:Fomafix|Fomafix]] 14:29, 8. Jan. 2012 (CET)
:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Fomafix|Fomafix]] 14:29, 8. Jan. 2012 (CET)</small>

== Unicode-Fonts? ==

Bei mir werden alle '''<code>Class</code>'''es mit dem Pip "* " vor dem <code>html</code> nicht dargestellt. Getestet mit FF4 Windows7 und IE9, keine Ahnung was das für ein Workaround sein soll. --&nbsp;[[Benutzer:Perhelion|Perhelion]] 04:25, 9. Jun. 2011 (CEST)
:Das ist Absicht, da nur der IE6 und sonst kein anderer Browser diese Klasse auslesen soll. -- [[Benutzer:Prince Kassad|Prince Kassad]] 04:32, 9. Jun. 2011 (CEST)
:: Aja habe ich auch ebend gelesen "Browserweiche <= 6 und IE 7". Dann machen doch '''alle''' diese Vorlagen keinen wirklichen Sinn mehr. Ich frage mich wie ein Browser die richtige Schrift für ein bestimmtes Schriftbild, wie oben erwähnt [[MediaWiki Diskussion:Common.css/Archiv/1#Fontvorgaben für IPA, IAST usw.|#Fontvorgaben für IPA, IAST usw.]]. finden soll. Somit ist der ganze Abschnitt für den Restmüll. Die Vorlagen sind meines Wissen '''nicht''' nur für Sprachnotationen und '''Unicode'''. --&nbsp;[[Benutzer:Perhelion|Perhelion]] 04:41, 9. Jun. 2011 (CEST)
::: Die IE-Versionen 6 und 7 verwenden je nach Statistik noch ungefähr [http://gs.statcounter.com/#browser_version-DE-monthly-201106-201106-bar 3] bis [http://stats.wikimedia.org/archive/squid_reports/2011-05/SquidReportClients.htm 14] Prozent.
::: Wie ein Browser die richtige Schrift finden soll, ist [http://www.w3.org/TR/CSS2/fonts.html#algorithm in CSS spezifiziert]. Wenn nur Browser in Verwendung wären, die sich daran halten, bräuchte man die Vorlagen in der Tat nicht. Gruß --[[Benutzer:Entlinkt|Entlinkt]] 11:57, 9. Jun. 2011 (CEST)
Der Workaround ist nur für IE6 und IE7 aktiv und wird nur dort gebraucht. Für moderne Browser sind diese Definitionen hier unwirksam. Solange IE6 und IE7 von MediaWiki unterstützt werden ([[mw:Supported browsers]]), sollten diese Definitionen hier erhalten bleiben. Sobald die Unterstützung eingestellt wird, können diese Definitionen und alle anderen Workarounds entfernt werden. --[[Benutzer:Fomafix|Fomafix]] 13:54, 8. Jan. 2012 (CET)
:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Fomafix|Fomafix]] 13:54, 8. Jan. 2012 (CET)</small>

== Urls auf  verwandte Projekte ==

Hallo! könnte man die Urls auf verwandte Projekte um commons erweitern? Hintergrund: Wir wollen im Zuge von [[WP:Wiki loves monuments|WLM]] Links auf commons mit Parameterübergabe machen (etwa uselang), da das ganze nur als logo in den Listen erscheinen soll stört der Pfeil. LG --[[Benutzer:AleXXw|AleXXw]]<small> •שלום!•[[Benutzer_Diskussion:AleXXw|disk]]</small> 22:35, 23. Jul. 2011 (CEST)
+1 Es würden damit externe Links und die damit unnötige Zeichenfolgen wegfallen, siehe [[Benutzer:AleXXw/Test/2]] --[[User:Karl Gruber|K@rl]]  <small>(Verbessern ist besser als löschen)</small> 16:29, 24. Jul. 2011 (CEST)

und so? [[Datei:Icon - upload photo 2.svg|x16px|alt=Datei hochladen|link={{fullurl:commons:Special:Upload|uselang=de}}]] --[[Benutzer:Herzi Pinki|Herzi Pinki]] 19:10, 24. Jul. 2011 (CEST)
:Danke, so fullurl hatte ich auch mit http versucht... LG --[[Benutzer:AleXXw|AleXXw]]<small> •שלום!•[[Benutzer_Diskussion:AleXXw|disk]]</small> 06:49, 25. Jul. 2011 (CEST)
:: Pfeil wird nicht mehr angezeigt. --[[Benutzer:Fomafix|Fomafix]] 13:39, 8. Jan. 2012 (CET)
:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Fomafix|Fomafix]] 13:39, 8. Jan. 2012 (CET)</small>

== Hervorhebung der angeklickten Fußnoten ==

Ist es Absicht, das dies nicht im Internet Explorer funktioniert oder ist auch dies technischen Einschränkungen zu zuschreiben? Vielen Dank für eine Erklärung. [[Benutzer:Umherirrender|Der Umherirrende]] 21:53, 1. Sep. 2011 (CEST)

:IE kennt die dafür notwendige Pseudoklasse [https://developer.mozilla.org/En/CSS/:target <code>:target</code>] erst seit der Version 9. --[[Benutzer:Schnark|Schnark]] 09:29, 2. Sep. 2011 (CEST)

:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Fomafix|Fomafix]] 13:27, 8. Jan. 2012 (CET)</small>

== [[bugzilla:23902|Bug 23902]] ==

Auf der Vorderseite steht derzeit folgendes:
<syntaxhighlight lang="css">
/* [[bugzilla:23902]] */
.mw-search-formheader div.search-types ul li a {
	background: none !important;
	padding: 0.5em !important;
}
</syntaxhighlight>

Der [[bugzilla:23902|Bug 23902]] ist inzwischen geschlossen und hat auch anscheinend einen weitergehenden, nicht mehr existierenden Fehler beschrieben. Der Code behebt aber ein Darstellungsfehler bei [[Spezial:Suche]] mit https und dem Skin vector: https://de.wikipedia.org/wiki/Spezial:Suche?useskin=vector. Bei en ist dieser Darstellungsfehler sichtbar: https://en.wikipedia.org/wiki/Special:Search?useskin=vector. Nach Reitern zum Umschalten der Suche wird dort ein gelbes Vorhängeschloss angezeigt: https://bits.wikimedia.org/skins-1.18/vector/images/lock-icon.png

Der Darstellungsfehler wurde mit [[rev:98690]] für vector und andere Skins mit einer besseren Methode behoben, wie hier zu sehen ist: https://translatewiki.net/wiki/Special:Search?useskin=vector. Sobald die Änderung live ist, kann der oben aufgeführte Code bei uns entfernt werden. --[[Benutzer:Fomafix|Fomafix]] 13:53, 6. Okt. 2011 (CEST)
: [[rev:98690]] ist mit [[rev:107938]] live. Der oben aufgeführte Workaround kann hier nun entfernt werden. --[[Benutzer:Fomafix|Fomafix]] 13:09, 8. Jan. 2012 (CET)
:<small>Archivierung dieses Abschnittes wurde gewünscht von: --[[Benutzer:32X|32X]] 13:20, 8. Jan. 2012 (CET)</small>

== [[Spezial:Spezialseiten]] ==

[[MediaWiki:Common.css]] enthält derzeit folgende Definitionen für [[Spezial:Spezialseiten]]:
<syntaxhighlight lang="css">
/* Fettformatierung von Admin-Spezialseiten in [[Special:Specialpages]] abschalten */
.mw-specialpagerestricted strong {
	font-weight: normal;
}
/* Legende auf [[Special:Specialpages]] ebenfalls abschalten */
div.mw-specialpages-notes {
	display: none;
}
</syntaxhighlight>

=== Zugriffsbeschränkte Spezialseiten ===
Die erste Definition soll Spezialseiten für Benutzer mit erweiterten Rechten nicht fett darstellen. Neben Seiten für Administratoren betrifft das für Sichter die Seite [[Spezial:Ungesichtete Seiten]]. Die Definition ist aber nicht mehr wirksam, denn das <code>strong</code> ist nicht mehr vorhanden:

<syntaxhighlight lang="html4strict">
<li class="mw-specialpagerestricted"><a title="Spezial:Ungesichtete Seiten" href="/wiki/Spezial:Ungesichtete_Seiten">Ungesichtete Seiten</a></li>
</syntaxhighlight>

mit

<syntaxhighlight lang="css">
.mw-specialpagerestricted {
	font-weight: bold;
}
</syntaxhighlight>

Die Definition kann daher entfallen. Wer als Admin oder als Sichter sich über die fette Zeilen stört, kann sie sich selbst in seiner [[Spezial:Meine Benutzerseite/common.css|eigenen common.css]] ausblenden. Eine CSS-Definition in [[MediaWiki:Common.css]] wird für alle Benutzer für allen Seiten übertragen, obwohl sie nur für bestimmte Benutzer auf einer Seite wirksam ist. --[[Benutzer:Fomafix|Fomafix]] 17:43, 8. Jan. 2012 (CET)

=== Legende ===
Die zweite Definition blendet die folgende Legende aus [[MediaWiki:specialpages-note]] aus:

<div style="border:1px solid #777; padding:.4em; background-color:#eee;">
----
* Reguläre Spezialseiten
* <span class="mw-specialpagerestricted">Zugriffsbeschränkte Spezialseiten</span>
* <span class="mw-specialpagecached">Gecachte Spezialseiten (Deren Inhalt ist möglicherweise veraltet.)</span>
</div>

Auf der Legende werden ''Gecachte Spezialseiten'' gleich formatiert wie normale Spezialseiten. Eine Unterscheidung ist daher nicht möglich. ''Zugriffsbeschränkte Spezialseiten'' werden fett formatiert. Das Fett ist hier nicht zu sehen, weil die CSS-Definition von MediaWiki nur bei Spezialseiten geladen wird. Normale Benutzer sehen aber keine zugriffsbeschränkten Spezialseiten. Für normale Benutzer ist die Legende daher nicht sehr hilfreich.

Ein Ausblenden der Legende über [[MediaWiki:Common.css]] hat aber den Nachteil, dass diese zusätzliche CSS-Definition für alle Benutzer und für alle Seiten geladen werden muss. Vielleicht ist es daher besser diese Ausblendung über <code>style="display:none"</code> in [[MediaWiki:specialpages-note]] vorzunehmen. --[[Benutzer:Fomafix|Fomafix]] 17:43, 8. Jan. 2012 (CET)

: Die Umsetzung erfolgte vorschlagsgemäß. --[[Benutzer:32X|32X]] 07:54, 9. Jan. 2012 (CET)
:<small>Archivierung dieses Abschnittes wurde gewünscht von: --[[Benutzer:32X|32X]] 07:54, 9. Jan. 2012 (CET)</small>

== CSS-Filter für IE <= 6 und IE 7 ==

In normalen Browsern ist <code>html</code> das root-Element von HTML-Dokumenten:
<syntaxhighlight lang="html4strict">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="de" dir="ltr">
	<head>...</head>
	<body>...</body>
</html>
</syntaxhighlight>

Im Internet Explorer haben HTML-Dokumente ein zusätzliches Element, hier „msieroot“ genannt, das bis zum IE 7 nachweisbar ist:
<syntaxhighlight lang="html4strict">
<msieroot>
	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
		"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
	<!-- Kommentar ohne tieferen Sinn, nur um den IE zu ärgern -->
	<html xmlns="http://www.w3.org/1999/xhtml" lang="de" dir="ltr">
		<head>...</head>
		<body>...</body>
	</html>
</msieroot>
</syntaxhighlight>

Bis zum IE 6 kann man von „msieroot“ ausgehend <code>* html</code> selektieren. Im IE 7 wurde das oberflächlich unterbunden, aber <code>:first-child ~ html</code> funktioniert. Dabei selektiert <code>:first-child</code> die <code>DOCTYPE</code>-Deklaration (die auch in manchen anderen Browsern selektiert werden kann, jedoch nicht mit <code>:first-child</code>, weil sie in normalen Browsern kein Kind von irgendetwas ist), <code>~</code> überspringt etwaige Kommentare und <code>html</code> selektiert das eigentliche root-Element. Das vielerorts empfohlene <code>:first-child + html</code> funktioniert meist auch, würde aber fehlschlagen, wenn zwischen <code>DOCTYPE</code> und <code>html</code> ein Kommentar steht, weil der IE 7 nicht nur <code>DOCTYPE</code>-Deklarationen, sondern sogar Kommentare selektieren kann.

Andere CSS-Filter setzen auf Parserbugs, indem sie syntaktisch ungültiges oder unsinniges CSS einsetzen und hoffen, dass bestimmte Browser es nicht oder eben doch akzeptieren (was sich von Version zu Version ändern kann), oder auf Selektoren, die bestimmte Browser nicht unterstützen (aber in Zukunft unterstützen können). Dieser hier ist insofern „eleganter“, als er an einem völlig absurden Designfehler ansetzt, der bei keinem anderen Browser nachgewiesen wurde, und leicht nachvollziehbar ist, was im Hintergrund passiert. Microsoft hat eine Policy, solche Bugs in alten Versionen nicht zu fixen (und wäre dazu wohl auch gar nicht in der Lage, ohne das Design zu ändern). Normale Browser können die Regel normal parsen und werden bloß kein passendes Element finden; für sie muss nichts zurückgesetzt werden.

Natürlich dürfen solche Filter nur sparsam eingesetzt werden. Genutzt werden diese zurzeit bei den Schriftartenlisten. Dort ist es m.&nbsp;E. alternativlos, auf bestimmte Browserversionen abzuzielen, weil die Listen einen Mangel bestimmter Browserversionen (die Unfähigkeit, passende Schriftarten zu finden) zu kompensieren versuchen, der wenig mit CSS zu tun hat. In anderen Fällen gibt es oft bessere Alternativen oder keine echte Notwendigkeit für eine Browserweiche. Zu beachten ist außerdem, dass der IE 8 sich in der sogenannten „Kompatibilitätsansicht“ (aus der die Wikimedia-Domains zum Glück [http://lists.wikimedia.org/pipermail/wikitech-l/2010-January/046324.html gestrichen wurden]) wie ein IE 7 verhält und auch der IE 9 einen IE-7-Modus enthalten wird. --[[Benutzer:Entlinkt|Entlinkt]] 01:32, 30. Jun. 2010 (CEST)
: Zur Dokumentation ins Archiv. Weitere Informationen stehen unter [[:en:CSS filter]]. --[[Benutzer:Fomafix|Fomafix]] 16:30, 18. Jan. 2012 (CET)
:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Fomafix|Fomafix]] 16:30, 18. Jan. 2012 (CET)</small>

== hintergrundfarbe2 ==

Hallo, nachdem in sämtlichen nicht-monobook-Skins (und auch dem neuen Vector) die <span style="background-color:#FFF;">Standardhintergrundfarbe #FFF</span> ist, lohnt sich diese Definition doch überhaupt nicht. Ich würde daher vorschlagen, diese <span style="background-color:#E8E8E8;">Hintergrundfarbe auf ca. #E8E8E8</span> zu ändern. Gleichzeitig wird in der Monobook.css für nicht-ANR-Seiten wieder #FFF definiert. Darauf gekommen bin ich wegen [[WP:WVW#Vorlage:Kasten / Hintergrundfarbe|dieser Anfrage]]. Was haltet ihr davon? Wird diese Klasse oft verwendet, um irgendwo reines Weiß zu bekommen anstatt etwas abzuheben?<br />fragt --&thinsp;<big>[[Benutzer:✓|✓]]</big>&thinsp;<small><sup>[[Benutzer Diskussion:✓|Bergi]]</sup></small> 12:49, 3. Jul. 2010 (CEST)
: Mit<pre>{| class="wikitable hintergrundfarbe2"</pre> bekommt man auf allen Skins eine weiße Tabelle. Das ist doch in Ordnung. --[[Benutzer:Fomafix|Fomafix]] 23:21, 9. Jan. 2011 (CET)
:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Fomafix|Fomafix]] 16:30, 18. Jan. 2012 (CET)</small>

== Formatierung der tags abbr, acronym ==

[http://de.wikipedia.org/w/index.php?title=Vorlage%3AHöhe&action=historysubmit&diff=88806295&oldid=76476096 Diese Änderung] hat relativ viel Staub aufgewirbelt, da sie bei allen Höhen zu gepunkteten Unterstreichungen führt, etwa {{Höhe|100|AT}} Diskussionen [[Vorlage Diskussion:Höhe#punktig unterstrichen statt azzurro in Italien|hier]], und [[Wikipedia:Fragen_zur_Wikipedia/Archiv/2011/Woche_21#Punktierte_Unterstreichung|dort]]. Bis auf den Verursacher, der sich bisher nicht geäußert hat, gibt es eigentlich keine Stimme für eine Beibehaltung der Formatierung. Inzwischen wurde auch die zentrale css lt.  [[bugzilla:28979|Bug 28979]]  angepasst, allerdings noch nicht freigeschalten. Folgende css-Einträge machen die Formatierung wieder rückgängig, lassen aber das aus Sicht der Barrierefreiheit sinnvolle tag <nowiki><abbr></nowiki> bestehen:
<pre>
abbr, acronym { border-bottom:none; }
</pre>
Da diese Änderung die Dinge auch nicht schlimmer machen kann, bin ich mal so mutig.
--[[Benutzer:Herzi Pinki|Herzi Pinki]] 21:13, 28. Mai 2011 (CEST)

: Doch. [http://de.wikipedia.org/w/index.php?title=Wikipedia%3AFragen_zur_Wikipedia&action=historysubmit&diff=89385658&oldid=89385367 Kann sie]. -- [[Spezial:Beiträge/Zwiebelleder|<span style="text-shadow:gray 0.2em 0.2em 0.1em;">''ζ''</span>]] <small>21:50, 28. Mai 2011 (CEST)</small>
::Das ist der Zustand von zuvor. Mouseover zeigt die Abkürzung an. Der Hinweis auf den Mouseover war früher auch nicht da. Insoferne keine Verschlimmbesserung. Und ich hoffe, das ist ein Zustand, in dem in Ruhe weiterdiskutiert werden kann, lg --[[Benutzer:Herzi Pinki|Herzi Pinki]] 21:55, 28. Mai 2011 (CEST)
:::Kann es sein, dass Du [[bugzilla:28979|Bug 28979]] missverstanden hast? Dort geht es nicht darum, die Unterstreichung global zu entfernen, sondern lediglich darum, den vormals skinabhängigen Code zu kürzen und zu zentralisieren. In [[rev:88118]] ist vielleicht besser zu sehen, was wirklich gemacht wurde. Insofern ist [http://de.wikipedia.org/w/index.php?title=MediaWiki%3ACommon.css&action=historysubmit&diff=89385895&oldid=85793039 dies] keine Vorwegnahme. Die oben genannten Diskussionen geben es meiner Meinung nach auch nicht wirklich her, die Unterstreichung überall zu entfernen, sondern beziehen sich alle nur auf die [[Vorlage:Höhe]], wo entsprechendes Inline-CSS verwendet werden kann. --[[Benutzer:Entlinkt|Entlinkt]] 18:32, 8. Jun. 2011 (CEST)
::::Als ich diesen Bug eröffnet habe wollte ich durchaus eigentlich die Unterstreichung mitentfernt haben. Sobald ich aber den erzeugenden CSS-Code gesehen hatte, habe ich den Request auf die Entfernung des sinnlosen Codes gekürzt.
::::Die Verwendung des abbr-Tags ist semantisch korrekt und nur sinnvoll. In den meisten Browsern geht damit die Unterpunktelung - die im MediaWiki-CSS zusätzlich fest verankert ist - einher, was manche Benuter stört. Eine Entscheidung, wie als Abkürzung oder Erklärung gekennzeichnete Stellen formatiert werden, sollte jeder Benutzer (per User- oder Browser-CSS) selbst treffen können. Inline-CSS in Wikipedia-Seiten kommt dabei nicht infrage!!!
::::Die Einfügung einer de.WP-weiten, einheitlichen Formatierung ins common.css ist nur richtig, allerdings fehlt die Klasse <code>.explain</code>. Der Vorgriff auf den Bug ist dabei nur <code>color:inherit</code>, die Nicht-Unterpunktelung wurde aufgrund mehrfachen Wunsches eingefügt. Um den Benutzer/Leser-Wunsch zu manifestieren, sollte vielleicht eine Umfrage stattfinden, die die Rezeption klärt.
::::<small>Die "merkwürdige Formatierung" bzw. "Quelltextverunstaltung im Artikel [[Geschichte der niederländischen Rechtschreibung]] ist natürlich Unsinn, sie sollte genauso wie Abkürzungen behandelt werden und daher mit <code>class="explain"</code> [http://de.wikipedia.org/w/index.php?diff=89811912&oldid=87997410 versehen] werden, um dem User/der Gemeinschaft die genannten Möglichkeiten zu eröffnen.</small>
::::--<big>[[Benutzer:✓|✓]]</big>&thinsp;<small><sup>[[Benutzer Diskussion:✓|Bergi]]</sup></small> 21:49, 8. Jun. 2011 (CEST)
:::::''„Als ich diesen Bug eröffnet habe wollte ich durchaus eigentlich die Unterstreichung mitentfernt haben. Sobald ich aber den erzeugenden CSS-Code gesehen hatte, habe ich den Request auf die Entfernung des sinnlosen Codes gekürzt.“'' Das ist auch ganz gut so, weil man für globale Änderungen auch eine Begründung braucht und ich bisher (außer ''„hat in der [[Vorlage:Höhe]] Staub aufgewirbelt“'') keine sehe.
:::::&lt;abbr>-Elemente kommen aber nicht nur in der Vorlage:Höhe vor, sondern seit August 2009 zum Beispiel auch auf den Seiten [[Spezial:Letzte Änderungen]] und [[Spezial:Beobachtungsliste]] (vgl. [[rev:54242]]; der [http://de.wikipedia.org/w/index.php?title=Vorlage_Diskussion%3AH%C3%B6he&action=historysubmit&diff=88828931&oldid=88827459 Aussage] ''„diese Vorlage scheint die einzige nennenswerte Stelle in der WP zu sein, wo das abbr-tag überhaupt vorkommt“'' ist also unbedingt zu widersprechen). Dort haben wir jetzt neuerdings rote Ausrufezeichen ohne jedweden Hinweis auf den erklärenden Tooltip.
:::::''„Eine Entscheidung, wie als Abkürzung oder Erklärung gekennzeichnete Stellen formatiert werden, sollte jeder Benutzer (per User- oder Browser-CSS) selbst treffen können.“'' Kann man so sehen, wobei ich es dann aber immer am logischsten finde, gar nichts ins CSS zu schreiben, sondern es einfach beim Browserstandard zu belassen, zu dem bei allen mir bekannten Browsern die Unterstreichung gehört ([http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cabbr%20title%3D%22title%22%3E%26lt%3Babbr%3E%3C%2Fabbr%3E Test]). Das machen die Browser nicht zum Spaß so, sondern damit der Tooltip, der beim &lt;abbr>-Elemente [http://developers.whatwg.org/text-level-semantics.html#attr-abbr-title eine besondere Bedeutung hat], auch gefunden wird.
:::::''„Inline-CSS in Wikipedia-Seiten kommt dabei nicht infrage!!!“'' Kann man so sehen, ich finde Inline-CSS aber immer ganz praktisch, wenn eine einzelne Vorlage sich von allgemeinen Formatierungsweisen abkoppeln will. Es wird in der Wikipedia eh großflächig verwendet.'' „Die Einfügung einer de.WP-weiten, einheitlichen Formatierung ins common.css ist nur richtig, [...]“'' Warum? Wir haben doch eine globale (wikimediaweit einheitliche) Formatierung. Der Code hier macht es nicht einheitlicher, sondern weniger einheitlich. ''„[...] allerdings fehlt die Klasse .explain.“'' Und dafür haben wir aber ein überflüssiges &lt;acronym>-Element, das in MediaWiki noch nie verwendet und mit HTML5 komplett abgeschafft wurde. --[[Benutzer:Entlinkt|Entlinkt]] 13:01, 9. Jun. 2011 (CEST)
::::::Volle Zustimmung. Inline-CSS ist imho immer suboptimal, da es den eigentlichen Sinn von CSS-Files mit Selektoren untergräbt. In der WP ist es aber leider oft der einzige Weg (und über Vorlagen leicht einsetzbar, [[WP:VOR#Zweck|ohne Tagsuppe im Artikel]]), eine Gruppe von Elementen (z.B. Infoboxen) abweichend zu formatieren, da über das common.css die pöhsen konservativen Admins wachen. Ich persönlich hätte gerne viel mehr einsetzbare Klassen, für ''Klassen'' gleichartiger Elemente ließen sich private Skinänderungen viel einfacher durchführen (statt overrulen der inline-Attribute). Gerade die „Abkopplung von allgemeinen Formatierungsweisen“ halte ich aber für falsch (stell dir per inline-style linksfloatende Infoboxen vor, das halte ich für mit einzeln von der Norm abweichenden Unterpunktelungen vergleichbar). Bei der Höhen-Vorlage haben wir jetzt natürlich den Sonderfall, dass das bislang die einzige häufige Verwendung (in Artikeln) der Abkürzungsauszeichnung ist und deren inline-style die Norm darstellt. Vergleichbares, wie mein Beispiel oben, sollte durch semantische Auszeichnung und CSS-Files statt (artikel-)spezifische inline-styles formatiert werden, die bei einer Normänderung (und sei es User-CSS) nicht eingschlossen werden.
::::::Davon unabhängig ist es mein Vorschlag, die Community (und die Leser) zu befragen, ob sie die Unterpunktelung denn wollen oder nicht. Daraus soll dann erstmal die allgemeine Formatierungsnorm entstehen, nach der sich (Vorlagen)Bastler zu richten haben. Noch betrifft dies nur eine Vorlage, weitere Anwendungen könnten aber folgen. Dann will ich aufgrund der genannten Argumente nicht lauter (vielleicht doch voneinander abweichende) style-Attribute, sondern eine einheitliche (und leicht personalisierbare) Formatdefinition. Die „Veruneinheitlichung“ ist aber nur der technikaversen Community geschuldet, deren Urteil umgesetzt wird (meinen Bugrequest hätte ich als Frage an die globale Community verstanden <small>oder deren bugzilla-nutzenden Teil, was somit wieder Unsinn ist</small>). Auch ich wäre lieber beim Browserstandard geblieben. --<big>[[Benutzer:✓|✓]]</big>&thinsp;<small><sup>[[Benutzer Diskussion:✓|Bergi]]</sup></small> 15:53, 9. Jun. 2011 (CEST)

[[rev:88118]] und [[rev:88498]] von [[bugzilla:28979|Bug 28979]] sind live. Diese [{{fullurl:MediaWiki:Common.css|diff=89385895}} Änderung] kann damit teilweise entfallen. <code>color:inherit</code> ist nun wirkungslos und kann entfernt werden. <code>border-bottom:none</code> überschreibt allerdings das <code>border-bottom: 1px dotted black</code> von skins/common/shared.css, was auch Browser-Standard ist. --[[Benutzer:Fomafix|Fomafix]] 13:07, 7. Okt. 2011 (CEST)

: Das <code>color:inherit</code> kann auf jeden Fall entfernt werden, da inzwischen wirkungslos. Bitte entfernen. --[[Benutzer:Fomafix|Fomafix]] 14:14, 8. Jan. 2012 (CET)
: <code>border-bottom:none</code> ist Geschmackssache. Mir würde die gepunktete Linie besser gefallen, weil sie Browserstandard ist, von MediaWiki aktuell vorgegeben ist: https://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/skins/common/shared.css?revision=108215&view=markup#l55 und bei anderen Wikis so existiert. Ein Entfernen der Definition hier ist aber eine sichtbare Änderung. --[[Benutzer:Fomafix|Fomafix]] 14:14, 8. Jan. 2012 (CET)
:: Ich habe der Einfachheit halber beides entfernt, wenn es dagegen Widerstand gibt, kann die von den anderen Wikis abweichende Formatierung ggf. wieder eingefügt werden. --[[Benutzer:32X|32X]] 14:43, 8. Jan. 2012 (CET)
:::Ich habe die [[Vorlage:Höhe]] von <nowiki><abbr>-tag</nowiki> entkoppelt. Habe daher kein Problem mit der erfolgten Änderung. lg --[[Benutzer:Herzi Pinki|Herzi Pinki]] 16:15, 8. Jan. 2012 (CET)
::::Ich habe allerdings ein Problem mit der Entkopplung. Bitte entweder <code>border-bottom:none</code> wieder rein, oder mit der angemessenen Unterpunktelung leben (oder CSS-Gadget anbieten), dann würde ich gerne [//de.wikipedia.org/w/index.php?diff=98095371&oldid=93548937 diese Änderung] revertieren. @Fomafix: Ich kann dich ja verstehen und finde die Unterpunktelung ebenfalls sinnvoll, aber die „sichtbare Änderung“ führt leider zu unsinnigen Edits. --&thinsp;[[Benutzer:✓|<big title="Benutzer:Bergi">✓</big>]]&thinsp;<small><sup>[[Benutzer Diskussion:✓|Bergi]]</sup></small> 21:26, 8. Jan. 2012 (CET)
::::: Wenn die Unterpunktelung für Ärger sorgt und dadurch unsinnige Bearbeitungen gemacht werden, dann kann von mir aus auch die Ausblendung wieder rein. Hier ist sowieso nicht der richtige Ort um so etwas zu diskutieren. --[[Benutzer:Fomafix|Fomafix]] 01:55, 9. Jan. 2012 (CET)
:::::: Wo wäre sonst der richtige Ort? Oder meinst du bloß, hier ist zu wenig Publikum und du würdest die Thematik lieber in einer Umfrage oder auf FzW klären? --&thinsp;[[Benutzer:✓|<big title="Benutzer:Bergi">✓</big>]]&thinsp;<small><sup>[[Benutzer Diskussion:✓|Bergi]]</sup></small> 19:24, 9. Jan. 2012 (CET)

Einen Kompromissvorschlag habe ich aber noch. Beim Drüberfahren kann die Unterpunktelung angezeigt werden:
<syntaxhighlight lang="css">
abbr:not(:hover), acronym:not(:hover) { border-bottom:none; }
</syntaxhighlight>
Da der Internet Explorer <code>:not()</code> erst ab [https://developer.mozilla.org/en/CSS/:not#Browser_compatibility Version 9.0] unterstützt, müsste eine Formulierung ohne <code>:not()</code> verwendet werden:
<syntaxhighlight lang="css">
abbr, acronym { border-bottom:none; }
abbr:hover, acronym:hover { border-bottom:1px dotted black; }
</syntaxhighlight>
Vielleicht wäre es für Unterpunktelungsgegner auch akzeptabel, wenn die Unterpunktelung statt <span style="border-bottom:1px dotted black;">schwarz</span> in einem dezentem <span style="border-bottom:1px dotted #ccc;">hellgrau</span> gemacht wird nur beim darüberfahren schwarz hervorgehoben wird:
<syntaxhighlight lang="css">
abbr, acronym { border-bottom:1px dotted #ccc; }
abbr:hover, acronym:hover { border-bottom:1px dotted black; }
</syntaxhighlight>
Für die [[Vorlage:Höhe]] finde ich aber auch Inline-CSS akzeptabel. Mit Inline-CSS sind aber optische Spielereien mit <code>:hover</code> nicht möglich.

Wenn der Code in [[MediaWiki:Common.css]] eingefügt wird, sollte er mit einem entsprechenden Kommentar versehen sein. --[[Benutzer:Fomafix|Fomafix]] 01:55, 9. Jan. 2012 (CET)

:Mir ist eigentlich egal, ob keine Unterpunktelung, eine beim Drüberfahren oder Hervorheben der Unterpunktelung beim Drüberfahren verwendet wird. Wichtig wäre mir das Verwenden von semantischen Tags und keine Notwendigkeit von inline-CSS (damit sie auch in "normaler Darstellung" außerhalb von Vorlagen eingesetzt werden können). Persönlich reicht mir der <code>cursor:help</code> (fehlt derzeit leider) ohne Unterpunktelung, das hellgrau finde ich aber ebenfalls elegant. Bitte stelle aber möglichst schnell den Zustand wie vor deiner Änderung wieder oder einen deiner beiden Kompromissvorschläge her. --&thinsp;[[Benutzer:✓|<big title="Benutzer:Bergi">✓</big>]]&thinsp;<small><sup>[[Benutzer Diskussion:✓|Bergi]]</sup></small> 19:24, 9. Jan. 2012 (CET)
:: <code>cursor:help</code> ist bereits in [https://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/skins/common/shared.css?revision=108215&view=markup#l55 skins/common/shared.css].
:: Hier geht es primär um Darstellung von <code>abbr</code> für die normale Verwendung im Fließtest ohne Inline-CSS. Eine manuelle Auszeichnung im Fließtext ohne die übliche Unterpunktelung ist nicht wahrnehmbar und wird daher vielleicht gerade deswegen sogar als Unnötig aus dem Wikitext entfernt. Die übliche kräftige Unterpunktelung sorgt bei häufiger Verwendung für Irritation und birgt die Gefahr, dass daher die Elemente aus dem Wikitext entfernt werden. Eine normale und sinnvolle Verwendung von <code>abbr</code> im Fließtext wird vermutlich häufige Abkürzungen nicht bei jedem Vorkommen auszeichnen, sondern nur beim ersten Auftreten. So wird es zumindest beim normalen Verlinken auch gemacht. Unter http://www.w3.org/TR/html5/text-level-semantics.html#the-abbr-element sind einige Hinweise zur Verwendung von <code>abbr</code> aufgeführt.
:: Die [[Vorlage:Höhe]] erzeugt bei jeder Verwendung den gleichen Code und hat damit bei jeder Verwendung die gleiche Darstellung. Was spricht denn dagegen, dass bei der [[Vorlage:Höhe]] Inline-CSS verwendet wird, um dort eine störende ständige Wiederholung der Unterpuntelung zu unterdrücken? Vielleicht ist diese ständige Wiederholung mit dem obigen Kompromiss aber auch nicht mehr so störend. --[[Benutzer:Fomafix|Fomafix]] 22:20, 10. Jan. 2012 (CET)

Die derzeitige MediaWiki-Definition gibt mir aber noch etwas zu denken:
<syntaxhighlight lang="css">
/* Default style for semantic tags */
abbr,
acronym,
.explain {
	border-bottom: 1px dotted black;
	cursor: help;
} 
</syntaxhighlight>

Die Rahmenfarbe ist schwarz:
: <span style="color:red">Roter Text mit <span style="border-bottom: 1px dotted black">border-bottom: 1px dotted black</span>.</span>

Besser wäre als Rahmenfarbe die aktuelle Textfarbe:
: <span style="color:red">Roter Text mit <span style="border-bottom: 1px dotted">border-bottom: 1px dotted</span>.</span>

Würde das bei allen Browsern funktionieren? --[[Benutzer:Fomafix|Fomafix]] 22:20, 10. Jan. 2012 (CET)

:Du meinst <code>border-bottom-color: inherit;</code> für unser CSS? Sieht imho nicht so gut aus, in der üblichen Form innerhalb eines [[Weblink|<span style="cursor:help; border-bottom: 1px dotted;" title="Hypertextverknüpfung">Link</span>s]]. Aber mir egal, hauptsache das abbr-Tag ist wieder ohne großes Geschrei nutzbar. --&thinsp;[[Benutzer:✓|<big title="Benutzer:Bergi">✓</big>]]&thinsp;<small><sup>[[Benutzer Diskussion:✓|Bergi]]</sup></small> 22:41, 10. Jan. 2012 (CET)
:: Findest Du „[[Roter Link|Roter <span style="cursor:help; border-bottom: 1px dotted black;" title="Hypertextverknüpfung">Link</span>]]“ besser als „[[Roter Link|Roter <span style="cursor:help; border-bottom: 1px dotted;" title="Hypertextverknüpfung">Link</span>]]“? Ich finde die an die Textfarbe angepasste Linie besser und dezenter.
:: <code>border-bottom-color: inherit;</code> bewirkt allerdings etwas anderes. Damit wird die Rahmenfarbe des darüberliegenden Elementes übernommen. Das darüberliegende Element hat als Rahmenfarbe wiederum als Standardwert die Schriftfarbe des Elements. Ein Unterschied ergibt sich daher, wenn das aktuelle Element eine andere Schriftfarbe hat, als das darüberliegende Element:
::# <span style="color:red">Roter Text mit <span style="color:green; border-bottom: 1px dotted">color:green; border-bottom: 1px dotted</span>.</span>
::# <span style="color:red">Roter Text mit <span style="color:green; border-bottom: 1px dotted; border-bottom-color:inherit">color:green; border-bottom: 1px dotted; border-bottom-color:inherit</span>.</span>
:: Der Initialwert der Rahmenfarbe ist die aktuelle Schriftfarbe. Vor CSS3 gibt es aber kein Schlüsselwort, mit dem auf den Initialwert zurückgesetzt werden kann. Mit CSS3 gibt es mit <code>[http://www.w3.org/TR/css3-color/#currentcolor currentColor]</code> eine explizite Möglichkeit den Initialwert anzugeben. Hier ist es aber besser, wenn in MediaWiki das <code>black</code> bei <code>border-bottom</code> entfernt wird. Das ist meiner Meinung nach bei [[rev:88118]] vergessen worden. Ich werde das in MediaWiki ändern lassen, wenn Du nichts dagegen hast.
::: Ich habe es mal gemeldet: [[rev:88118#c29360]] --[[Benutzer:Fomafix|Fomafix]] 17:07, 11. Jan. 2012 (CET)
:::: Zusätzlich habe ich es mit [[bugzilla:33703|Bug 33703]] gemeldet und ist mit [[rev:108866]] umgesetzt worden. Die Änderung wird voraussichtlich mit MediaWiki 1.19 aktiv werden. --[[Benutzer:Fomafix|Fomafix]] 16:58, 14. Jan. 2012 (CET)
:: Bei uns lokal können wir uns eine Abschwächung der Unterpunktelung überlegen. Eine Halbtransparenz wäre besser, als ein Hellgrau. --[[Benutzer:Fomafix|Fomafix]] 15:49, 11. Jan. 2012 (CET)

Erst mal Danke für euer Bemühen. Mir ist es wurscht, wie die Formatierung aussieht (finde aber das dezente Grau elegant), ich will aber nicht, dass wegen einer unpassenden Formatierung die Vorlagen entfernt werden. Da sind wir uns wohl einig.<br />
Mal so ne Frage, warum muss das bei Vorlage:Höhe sein, und die ganzen km², m³, ha, l, pa, kcal im Fließtext kommen ungeschoren davon? Es geht um eine logische Auszeichnung, nicht um die Frage, wie einfach oder komplziert das umzusetzen ist. Ist schon klar, dass das zentral in einer Vorlage einfach und an hunderttausend Stellen im Fließtext aufwändig ist. Aber logisch sehe ich da nicht viel Unterschied. Die Regel die hier angewandt wird, heißt alle Abkürzungen sind in das <nowiki><abbr>-tag</nowiki> einzubetten. oder? <br />
Zur Vorlage:Höhe, es gab auch den Vorschlag, die Auszeichnung von link=true abhängig zu machen. Dieser Par. ermöglicht den Link auf die Einheit an steuerbaren Stellen, also dann auch die Unterpunktelung an steuerbaren Stellen. Die anderen Verwendungen ohne link=true haben dann weder einen Link noch eine Unterpunktelung. Trotzdem könnte das <nowiki><abbr>-tag</nowiki> mit inline CSS verwendet werden, sodass sreenreader ihre Sache richtig machen können. Das entspricht wohl Formafix's Vorschlag von oben. Auch bei anderen Abkürzungen / Einheiten im Fließtext müsste dann so verfahren werden, d.h <abbr title="Kilogramm">kg</abbr>, in der Folge aber <abbr title="Kilogramm" style="border-style:none">kg</abbr>. Der Screenreader sollte ja immer Kilogramm vorlesen und niemals kg. Es ist die wohl zentrale Frage, ob wir das <nowiki><abbr>-tag</nowiki> für Accessibility generell forcieren sollen. CSS Spielereien sind da fast schon nebensächlich. --[[Benutzer:Herzi Pinki|Herzi Pinki]] 01:32, 11. Jan. 2012 (CET)
: Muss für Screenreader jede Abkürzung mit <code>abbr</code> versehen werden? --[[Benutzer:Fomafix|Fomafix]] 15:49, 11. Jan. 2012 (CET)
:: Ich denke nicht, SI-Einheiten wird er sicher auch so vorlesen können. Natürlich fände ich eine durchgängige Verwendung des Tags angenehm (und es muss luat spec auch nicht immer mit <code>title</code> versehen sein), im normalen Text ist sie aber kaum durchzusetzen. In der Vorlage:Höhe ist mir die Auszeichnung so wichtig, da dort viele ungewohnte/seltene Abkürzungen vorkommen.
:: Auf inline-CSS würde ich gerne verzichten. Es ist schwierig zu überschreiben, und macht die Formatierung inkonsistent. Auch wenn es hier verlockend erscheint, da dieser Stil erstmal bloß aus einer zentralen Vorlage stammt, sollte man nicht schon uneinheitlich anfangen. Deshalb halte ich auch wenig von dem Vorschlag, es nur in Links zu unterpunkteln: Diese sind sowieso schon hervorgehoben, und man kann (als Ottonormaluser) auch keinen Unterschied zu nicht unterpunktelten Links finden; „dann lieber die Vorlage unverlinkt verwenden“…
:: Könnten wir uns vielleicht darauf einigen, die hellgraue Unterpunkelung auszuprobieren, und wenn mehrere negative Rückmeldungen eintreffen auf <code>none</code> zurückzustellen? --&thinsp;[[Benutzer:✓|<big title="Benutzer:Bergi">✓</big>]]&thinsp;<small><sup>[[Benutzer Diskussion:✓|Bergi]]</sup></small> 16:14, 11. Jan. 2012 (CET)

Ich würde folgende Definition vorschlagen:
<syntaxhighlight lang="css">
abbr, acronym {
	border-bottom-color: #ccc; /* Fallback für alte Browser: https://developer.mozilla.org/en/CSS/color_value#Browser_Compatibility */
	border-bottom-color: rgba(75%, 75%, 75%, .5);
}
abbr:hover, acronym:hover {
	border-bottom-color: inherit; /* Internet Explorer 8 */
	border-bottom-color: currentColor;
}
</syntaxhighlight>

Beispiele:
<div style="padding:1em; color:black; background:white;">Schwarz auf Weiß: <span style="border-bottom: 1px dotted; border-bottom-color: #ccc;">#ccc</span>, <span style="border-bottom: 1px dotted; border-bottom-color: #ccc; border-bottom-color: rgba(75%, 75%, 75%, .5);">rgba(75%, 75%, 75%, .5)</span>. Hover: <span style="border-bottom: 1px dotted; border-bottom-color: #ccc; border-bottom-color: rgba(75%, 75%, 75%, .5); border-bottom-color: inherit; border-bottom-color: currentColor;">currentColor</span>.</div>
<div style="padding:1em; color:white; background:black;">Weiß auf Schwarz: <span style="border-bottom: 1px dotted; border-bottom-color: #ccc;">#ccc</span>, <span style="border-bottom: 1px dotted; border-bottom-color: #ccc; border-bottom-color: rgba(75%, 75%, 75%, .5);">rgba(75%, 75%, 75%, .5)</span>. Hover: <span style="border-bottom: 1px dotted; border-bottom-color: #ccc; border-bottom-color: rgba(75%, 75%, 75%, .5); border-bottom-color: inherit; border-bottom-color: currentColor;">currentColor</span>.</div>
<div style="padding:1em; color:red; background:white;">Rot auf Weiß: <span style="border-bottom: 1px dotted; border-bottom-color: #ccc;">#ccc</span>, <span style="border-bottom: 1px dotted; border-bottom-color: #ccc; border-bottom-color: rgba(75%, 75%, 75%, .5);">rgba(75%, 75%, 75%, .5)</span>. Hover: <span style="border-bottom: 1px dotted; border-bottom-color: #ccc; border-bottom-color: rgba(75%, 75%, 75%, .5); border-bottom-color: inherit; border-bottom-color: currentColor;">currentColor</span>.</div>
<div style="padding:1em; color:red; background:black;">Rot auf Schwarz: <span style="border-bottom: 1px dotted; border-bottom-color: #ccc;">#ccc</span>, <span style="border-bottom: 1px dotted; border-bottom-color: #ccc; border-bottom-color: rgba(75%, 75%, 75%, .5);">rgba(75%, 75%, 75%, .5)</span>. Hover: <span style="border-bottom: 1px dotted; border-bottom-color: #ccc; border-bottom-color: rgba(75%, 75%, 75%, .5); border-bottom-color: inherit; border-bottom-color: currentColor;">currentColor</span>.</div>
--[[Benutzer:Fomafix|Fomafix]] 17:07, 11. Jan. 2012 (CET)
: Ich habe einen Workaround für den Internet Explorer bis zur Version 8 eingebaut und Beispiele mit roter Vordergrundfarbe hinzugefügt. --[[Benutzer:Fomafix|Fomafix]] 21:31, 11. Jan. 2012 (CET)
::{{Pro}} rgba ist genial :-) Nur grau auf grau funktioniert halt nicht. --&thinsp;[[Benutzer:✓|<big title="Benutzer:Bergi">✓</big>]]&thinsp;<small><sup>[[Benutzer Diskussion:✓|Bergi]]</sup></small> 21:56, 11. Jan. 2012 (CET)

* In allen systematischen und strukturellen Fragen stimme ich voll und ganz mit Bergi überein.
* Ich habe nichts dagegen, wenn dem nichtsahnenden Leser durch eine permanente dezent leichtgraue Unterpunktelung (weißer Hintergrund) die Möglichkeit eines Tooltips angezeigt wird. Niemand kann ahnen, dass ausgerechnet die müA mit einem Tooltip versehen wären und es sich lohnen würde, genau auf dieses Fleckchen seinen Mauszeiger zu bewegen.
* Die tags wären allerdings nicht in die Vorlage:Höhe oder irgendeine andere fachliche Vorlage einzufügen. Vielmehr wünsche ich mir dafür eine <nowiki>{{abbr}}</nowiki> (Arbeitstitel). Nur für diese wäre die Verwendung des Features zulässig, das ich seit zehn Jahren schätze und das außerhalb der WP auf wenigen inhaltsvermittelnden Websites üblich ist. Eine zentrale Vorlage sollte dann mit einer Klasse arbeiten (sie selbst kann ja keine Klassendefinition setzen), die auf dieser Seite hier belegt wird. Benutzer können dann die dezente Standardvorgabe durch neonmagenta-Hintergrund oder unsichtbar überschreiben. Während den Vorlagenbearbeitern das hier und da ausgestreute &lt;abbr> unverständlich sein könnte, wäre eine <code><nowiki>{{Abkürzung mit Erläuterung als Tooltip}}</nowiki></code> selbsterklärend und hätte eine Doku-Seite; könnte auch unmittelbar im ANR benutzt werden.
* Ohne jetzt inhaltlich Vorlage:Höhe durchgelesen zu haben, fällt mir auf, dass dies normalerweise über ein Wikilink gelöst wird. Nimmt man <nowiki>[[Meter über Adria|m.ü.A.]]</nowiki>, bekommt man sogar einen Tooltip, notfalls nach Einrichtung einer entsprechenden WL-Seite.
VG --[[Benutzer:PerfektesChaos|PerfektesChaos]] 10:06, 13. Jan. 2012 (CET)
: Hier geht es aber zunächst um die Formatierung von <code>abbr</code> ohne zusätzliches Inline-CSS. Ob das nun aus einer Vorlage kommt oder direkt im Quellcode eingegeben ist, ist hier egal. Die obige Argumentationskette ist aber schlecht. Sinngemäß:
:* Vorlage:Höhe soll abbr verwenden, weil semantisch richtig.
:* Vorlage:Höhe soll keine Linie erzeugen, weil die Vorlage sonst durch die Zahl ersetzt wird.
:* Inline-CSS ist böse und darf nicht für Vorlagen verwendet werden.
:* Also muss darf die globale Formatierung von abbr keine Unterpunktelung erzeugen.
: Die hellgraue Unterpuntelung ist nun ein hoffentlich geeigneter Kompromiss. --[[Benutzer:Fomafix|Fomafix]] 10:23, 13. Jan. 2012 (CET)
:: Eine dezente Unterpunktelung finde ich auch besser. Eine separate Vorlage ist ein anderes Problem, was man später klären sollte, da nunmal bereits jetzt die Möglichkeit besteht das <code><nowiki><abbr></nowiki></code>-Tag zu nutzen, sollte man zuerst klären wie dieses visuell dargestellt wird bevor man einen neuen Diskussionspunkt aus der Taufe hebt, da durch eine Vorlage ja das Tag nicht verschwindet. --[[Benutzer:Mps|Mps]] 13:30, 13. Jan. 2012 (CET)
::: Mit separaten Vorlagen für einzelne HTML-Elemente wäre ich vorsichtig. Wir haben auch keine [[Vorlage:Fett]] mit <code><nowiki>'''{{{1}}}'''</nowiki></code>, <code><nowiki><b>{{{1}}}</b></nowiki></code> oder <code><nowiki><strong>{{{1}}}</strong></nowiki></code> oder eine [[Vorlage:Unterstrichen]] mit <code><nowiki><u>{{{1}}}</u></nowiki></code> oder <code><nowiki><span style="text-decoration:underline">{{{1}}}</span></nowiki></code>. Allerdings haben wir eine [[Vorlage:Overline]] mit <code><nowiki><span style="text-decoration:overline">{{{1}}}</span></nowiki></code>. Das ganze Vorlagenthema ist aber hier die falsche Seite. --[[Benutzer:Fomafix|Fomafix]] 13:45, 13. Jan. 2012 (CET)
:<small>Archivierung dieses Abschnittes wurde gewünscht von: --&thinsp;[[Benutzer:✓|<big title="Benutzer:Bergi">✓</big>]]&thinsp;<small><sup>[[Benutzer Diskussion:✓|Bergi]]</sup></small> 18:58, 23. Jan. 2012 (CET)</small>

== Hintergrundfarben bei wikitable mit MediaWiki 1.19 ==

Mit [[rev:107669]] wurde die [http://www.w3.org/TR/css3-selectors/#specificity Spezifität] der CSS-Selektoren erhöht. Damit mit den CSS-Klassen <code>hintergrundfarbe<var>x</var></code> die Hintergrundfarben von Tabellenköpfen weiterhin überschrieben werden können, muss hier die Spezifität auch erhöht werden:

Bisher:
<syntaxhighlight lang="css">
tr.hintergrundfarbe1 th,
tr th.hintergrundfarbe1,
table.hintergrundfarbe1,
.hintergrundfarbe1 { /* Wie Inhaltsverzeichnis */
	background-color: #f9f9f9;
}
tr.hintergrundfarbe2 th,
tr th.hintergrundfarbe2,
table.hintergrundfarbe2,
.hintergrundfarbe2 { /* "Weiß", für Nicht-Artikel-Seiten, neutral */
	background-color: #ffffff;
}
tr.hintergrundfarbe3 th,
tr th.hintergrundfarbe3,
table.hintergrundfarbe3,
.hintergrundfarbe3 { /* "Gelb", auffällig */
	background-color: #ffff40;
}
tr.hintergrundfarbe4 th,
tr th.hintergrundfarbe4,
table.hintergrundfarbe4,
.hintergrundfarbe4 { /* Sehr auffällig */
	background-color: #fa0;
}
tr.hintergrundfarbe5 th,
tr th.hintergrundfarbe5,
table.hintergrundfarbe5,
.hintergrundfarbe5 { /* Neutral, abgesetzt */
	background-color: #e0e0e0;
}
tr.hintergrundfarbe6 th,
tr th.hintergrundfarbe6,
table.hintergrundfarbe6,
.hintergrundfarbe6 { /* Allgemein „bunt“, für Hervorhebungen und Unterscheidungen */
	background-color: #b3b7ff;
}
tr.hintergrundfarbe7 th,
tr th.hintergrundfarbe7,
table.hintergrundfarbe7,
.hintergrundfarbe7 { /* Allgemein „bunt“, für Hervorhebungen und Unterscheidungen */
	background-color: #ffcbcb;
}
tr.hintergrundfarbe8 th,
tr th.hintergrundfarbe8,
table.hintergrundfarbe8,
.hintergrundfarbe8 { /* Allgemein „bunt“, für Hervorhebungen und Unterscheidungen */
	background-color: #ffebad;
}
tr.hintergrundfarbe9 th,
tr th.hintergrundfarbe9,
table.hintergrundfarbe9,
.hintergrundfarbe9 { /* Allgemein „bunt“, für Hervorhebungen und Unterscheidungen */
	background-color: #b9ffc5;
}
</syntaxhighlight>

Neu:
<syntaxhighlight lang="css">
table > * > tr.hintergrundfarbe1 > th,
table > * > tr > th.hintergrundfarbe1,
table.hintergrundfarbe1,
.hintergrundfarbe1 { /* Wie Inhaltsverzeichnis */
	background-color: #f9f9f9;
}
table > * > tr.hintergrundfarbe2 > th,
table > * > tr > th.hintergrundfarbe2,
table.hintergrundfarbe2,
.hintergrundfarbe2 { /* "Weiß", für Nicht-Artikel-Seiten, neutral */
	background-color: #ffffff;
}
table > * > tr.hintergrundfarbe3 > th,
table > * > tr > th.hintergrundfarbe3,
table.hintergrundfarbe3,
.hintergrundfarbe3 { /* "Gelb", auffällig */
	background-color: #ffff40;
}
table > * > tr.hintergrundfarbe4 > th,
table > * > tr > th.hintergrundfarbe4,
table.hintergrundfarbe4,
.hintergrundfarbe4 { /* Sehr auffällig */
	background-color: #fa0;
}
table > * > tr.hintergrundfarbe5 > th,
table > * > tr > th.hintergrundfarbe5,
table.hintergrundfarbe5,
.hintergrundfarbe5 { /* Neutral, abgesetzt */
	background-color: #e0e0e0;
}
table > * > tr.hintergrundfarbe6 > th,
table > * > tr > th.hintergrundfarbe6,
table.hintergrundfarbe6,
.hintergrundfarbe6 { /* Allgemein „bunt“, für Hervorhebungen und Unterscheidungen */
	background-color: #b3b7ff;
}
table > * > tr.hintergrundfarbe7 > th,
table > * > tr > th.hintergrundfarbe7,
table.hintergrundfarbe7,
.hintergrundfarbe7 { /* Allgemein „bunt“, für Hervorhebungen und Unterscheidungen */
	background-color: #ffcbcb;
}
table > * > tr.hintergrundfarbe8 > th,
table > * > tr > th.hintergrundfarbe8,
table.hintergrundfarbe8,
.hintergrundfarbe8 { /* Allgemein „bunt“, für Hervorhebungen und Unterscheidungen */
	background-color: #ffebad;
}
table > * > tr.hintergrundfarbe9 > th,
table > * > tr > th.hintergrundfarbe9,
table.hintergrundfarbe9,
.hintergrundfarbe9 { /* Allgemein „bunt“, für Hervorhebungen und Unterscheidungen */
	background-color: #b9ffc5;
}
</syntaxhighlight>
--[[Benutzer:Fomafix|Fomafix]] ([[Benutzer Diskussion:Fomafix|Diskussion]]) 09:18, 1. Mär. 2012 (CET)
:Ist [https://de.wikipedia.org/w/index.php?title=MediaWiki:Common.css&diff=100353458&oldid=100224849 geändert]. [[Benutzer:Umherirrender/Sig|Der Umherirrende]] 20:44, 1. Mär. 2012 (CET)

:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Umherirrender/Sig|Der Umherirrende]] 20:44, 1. Mär. 2012 (CET)</small>

== Sichtungskommentar mit MediaWiki 1.19 ==

Mit MediaWiki 1.19 haben sich die Klassen und IDs für den Sichtungskommentar geändert. Damit der Sichtungskommentar weiterhin komplett ausgeblendet ist, muss nun sowohl das Eingabefeld, als auch der Hinweis „Kommentar:“ ausgeblendet werden. Dies wird folgendermaßen erreicht:

Bisher:
<syntaxhighlight lang="css">
/* Standardmäßige Ausblendung der Flagged-Revisions-Kommentarbox */
#mw-fr-commentbox {
	display: none;
}
</syntaxhighlight>

Neu:
<syntaxhighlight lang="css">
/* Standardmäßige Ausblendung der Flagged-Revisions-Kommentarbox */
.fr-comment-box {
	display: none;
}
</syntaxhighlight>

--[[Benutzer:Fomafix|Fomafix]] ([[Benutzer Diskussion:Fomafix|Diskussion]]) 10:03, 1. Mär. 2012 (CET)
:Auch wenn ich die Box eigentlich nützlich findet, habe ich die Änderung [https://de.wikipedia.org/w/index.php?title=MediaWiki:Common.css&diff=100354370&oldid=100353781 gemacht], weil man es wohl als De-Facto-Standard ansehen kann (Niemals/Kaum aktiv gewesen, seit dem es die Box gibt). [[Benutzer:Umherirrender/Sig|Der Umherirrende]] 21:13, 1. Mär. 2012 (CET)

:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Umherirrender/Sig|Der Umherirrende]] 21:13, 1. Mär. 2012 (CET)</small>

== wikitable ohne table-Element ==

<code>wikitable</code> ist seit langem zentral in [//svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/skins/common/shared.css?view=markup#l467 skins/common/shared.css] definiert. Hier lokal haben wir aber noch folgende Definition:

<syntaxhighlight lang="css">
.wikitable {
	background: #f9f9f9;
	border: 1px solid #aaa;
	border-collapse: collapse;
	margin: 1em 1em 1em 0;
}
</syntaxhighlight>

Alle gesetzten Eigenschaften sind in der zentralen Definition bereits enthalten und können daher lokal entfallen. Es gibt aber ein entscheidenden Unterschied. Die zentrale Definition hat den Selektor <code>table.wikitable</code>, während wir lokal den Selektor <code>.wikitable</code> haben. Damit kann die lokale Definition auch bei anderen Elementen als <code>table</code> eingesetzt werden.

Wird irgendwo die CSS-Klasse <code>wikitable</code> bei anderen Elementen außer <code>table</code> eingesetzt? --[[Benutzer:Fomafix|Fomafix]] ([[Benutzer Diskussion:Fomafix|Diskussion]]) 10:44, 2. Mär. 2012 (CET)
: Ich habe gerade in einem aktuellen Dump die Verwendung von <code>wikitable</code> untersucht. Neben den normalen Verwendungen bei <code>{|</code> wird <code>wikitable</code> bei zweimal bei <code>math</code>, einmal bei <code>div</code>, einmal bei <code>span</code> und ca. 60mal bei <code>gallery</code>. Die Verwendungen bei <code>math</code>, <code>div</code> und <code>span</code> habe ich entfernt. Die Verwendungen bei <code>gallery</code> sollten auch noch entfernt werden.
: Die oben aufgeführte lokale Definition von <code>.wikitable</code> kann entfernt werden. --[[Benutzer:Fomafix|Fomafix]] ([[Benutzer Diskussion:Fomafix|Diskussion]]) 21:17, 10. Apr. 2012 (CEST)
::Mit der Absicherung klingt das sinnvoll. [//de.wikipedia.org/w/index.php?title=MediaWiki:Common.css&diff=101905789&oldid=101055536 Erledigt]. [[Benutzer:Umherirrender/Sig|Der Umherirrende]] 21:28, 10. Apr. 2012 (CEST)
:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Umherirrender/Sig|Der Umherirrende]] 21:28, 10. Apr. 2012 (CEST)</small>

== Änderungen an zentralen StyleSheets ==

Mit [[rev:66646]] (und ein paar weiteren) wurden zentrale StyleSheets-Definitionen verfeinert. Mir ist (auf dem translatewiki) aufgefallen, das die Einfärbung der verschiedenen Namensräumen mit CSS nicht mehr funktioniert. Daher sollte eine Prüfung alle lokalen StyleSheets der deutschsprachigen Wikipedia durchgeführt werden, um keine bösen Überraschungen zu erfahren. In [[MediaWiki:Monobook.css]] muss auf jeden Fall etwas geändert werden ([[rev:66670]]/[http://de.wikipedia.org/w/index.php?title=Benutzer%3AUmherirrender%2Fmonobook-sul.css&action=historysubmit&diff=74596811&oldid=74306935 Beispielfix]). Vielen Dank. [[Benutzer:Umherirrender|Der Umherirrende]] 20:42, 20. Mai 2010 (CEST)
: Bei [[MediaWiki:Monobook.css]] hat [[Benutzer:Entlinkt|Entlinkt]] Anpassungen [http://de.wikipedia.org/w/index.php?title=MediaWiki:Monobook.css&diff=74748616&oldid=74502295 vorgenommen].
: Diese Problematik bringt mich auf die Idee unsere CSS-ID-Definitionen zu untersuchen. In [[MediaWiki:Common.css]] werden einige CSS-IDs definiert, die nicht auf bestimmte HTML-Elemente beschränkt sind. Es sind daher manche Überschriften nicht möglich. Beispiel:
 == gelesen ==
: Eine Einschränkung auf das entsprechende <code>div</code>/<code>span</code>-Element verhindert zumindest, dass Überschriften davon betroffen sind. --[[Benutzer:Fomafix|Fomafix]] 09:56, 25. Mai 2010 (CEST)
::Wobei sich bei "gelesen" die Frage, stellt, wo das noch verwendet wird. Das Verbergen der Sitenotice scheint heutzutage anders zu laufen. Daher ist ein entfernen hilfreicher, oder habe ich was übersehen? [[Benutzer:Umherirrender|Der Umherirrende]] 15:35, 6. Jun. 2010 (CEST)
:::<code>#gelesen</code> wurde am 19. Dezember 2005 [http://de.wikipedia.org/w/index.php?title=MediaWiki:Common.css&diff=next&oldid=11775438 hinzugefügt], am gleichen Tag einmal [http://de.wikipedia.org/w/index.php?title=MediaWiki:Sitenotice&diff=11791419&oldid=11791293 verwendet] und am nächsten Tag wieder [http://de.wikipedia.org/w/index.php?title=MediaWiki:Sitenotice&diff=11813968&oldid=11791518 entfernt], aber nicht mehr aus [[MediaWiki:Common.css]] entfernt. Eine weitere Verwendung konnte ich nicht finden. Die Definition <code>#gelesen</code> sollte daher entfernt werden. --[[Benutzer:Fomafix|Fomafix]] 10:39, 9. Jun. 2010 (CEST)
::::Und weg ist es, vielen Dank für die Recherche. Ich bin immer dankbar für Hinweise, was hier noch entfernt werden kann. Gruß --[[Benutzer:Entlinkt|Entlinkt]] 11:30, 9. Jun. 2010 (CEST)
: Es gibt noch weitere CSS-ID-Definitionen ohne Einschränkung auf ein Element. Beispielsweise hat die Überschrift
 === editpage-copywarn ===
: hat einen lustigen roten Kasten. Verhindert werden kann das, indem <code>div#editpage-copywarn</code> statt <code>#editpage-copywarn</code> definiert wird. --[[Benutzer:Fomafix|Fomafix]] 12:21, 9. Jun. 2010 (CEST)
::Ich habe nochmal welche [https://de.wikipedia.org/w/index.php?title=MediaWiki:Common.css&diff=103370319&oldid=103369397 angepasst]. Sollte damit erstmal erledigt sein, falls noch welche Fehlen, einfach wieder aufmachen. [[Benutzer:Umherirrender/Sig|Der Umherirrende]] 11:21, 18. Mai 2012 (CEST)

:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Umherirrender/Sig|Der Umherirrende]] 11:21, 18. Mai 2012 (CEST)</small>

== Ausblendung der Flagged-Revisions-Backlog-Sitenotice ==

… mittels <code>#mw-oldreviewed-notice { display: none; }</code> funktioniert nicht, weil es nur ein div in einer Tabellenzelle ausblendet. Die Tabelle an sich und vor allem der [Verbergen]-Link in der anderen Zelle bleiben und hängen ohne Bezug zu irgendwas herum. (Zum Glück betrifft das nur Sichter und anscheinend auch die nur auf [[Spezial:Beobachtungsliste]] und [[Spezial:Letzte Änderungen]]). --[[Benutzer:Entlinkt|Entlinkt]] 05:11, 12. Jun. 2010 (CEST)
:Das wurde schon an mehreren Stellen angemerkt, aber kein Admin hat sich getraut, das Ausblenden zu entfernen. Seit [[rev:67414]] dürfte sich das ganze aber sowieso erledigt haben (Ist nur noch nicht live). Meinetwegen kann die Definition sofort raus.[[Benutzer:Umherirrender|Der Umherirrende]] 12:36, 12. Jun. 2010 (CEST)
::In [[rev:67414]] ist aber nur die Sitenotice entfernt worden, die es bei einem generellen Rückstand gibt, es gibt aber auch noch eine andere Sitenotice, die sich auf ungesichtete Seiten auf der Beobachtungsliste bezieht und nicht entfernt wurde. Deren ID wurde in [[rev:60676]] von mw-oldreviewed-notice nach mw-fr-oldreviewed-notice und in [[rev:67414]] nochmals nach mw-fr-watchlist-pending-notice geändert, so dass die Ausblendung gar nicht mehr funktionieren wird. Das Ding sieht übrigens so aus:
{| style="width: 100%;"
|-
| style="width: 80%;" | <div style="background-color: #feecd7; border: 1px solid #900; margin: 5px; padding: 3px;">Es sind aktuell [http://de.wikipedia.org/w/index.php?title=Spezial:Seiten_mit_ungesichteten_Versionen&watched=1 ungesichtete Bearbeitungen] von gesichteten Seiten auf deiner Beobachtungsliste. '''Deine Aufmerksamkeit ist nötig!'''</div>
| style="width: 20%; text-align: right;" | [Verbergen]
|}
::Gruß --[[Benutzer:Entlinkt|Entlinkt]] 04:01, 13. Jun. 2010 (CEST)
:::Schuldige, du schriebst von Backlog, da habe ich nur an die eine Sitenotice gedacht (Früher gabe es nur eine, und die andere hat man zwischenzeitlich ja nie gesehen). Ich denke aber trotzdem, dass das ausblenden standardmäßig entfernt werden kann, da es ja [Verbergen] gibt und man es heutzutage ja eh schon klickt, auch wenn man nicht sieht was dann verborgen wird. [[Benutzer:Umherirrender|Der Umherirrende]] 14:39, 13. Jun. 2010 (CEST)
::::Das Layout der Nachricht wurde neutralisiert und scheint so keinen zu stören, daher denke ich mal, das dies hier erledigt ist. [[Benutzer:Umherirrender/Sig|Der Umherirrende]] 10:54, 18. Mai 2012 (CEST)
:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Umherirrender/Sig|Der Umherirrende]] 10:54, 18. Mai 2012 (CEST)</small>

== gesichtete Versionen, Teil 2 ==

Hallo! irgenjemand hat in der [http://de.wikipedia.org/w/extensions/FlaggedRevs/client/flaggedrevs.css flaggedrevs.css] ein
<syntaxhighlight lang="css">li.fr-hist-stable-margin { 
margin-top: 2em;
}</syntaxhighlight>
verbrochen. Erreicht wird damit, dass in der Versionsgeschichte die ungesichteten Versionen durch einen deutlichen Abstand von der ersten markierten abgehoben werden. Zusammen mit der gelben Hinterlegeung ist das aber völlig überflüssig, und selbst wenn es als sinnvoll gesehen wird ist der Abstand viel zu groß. Bitte als Bug melden oder hier lokal rückgängig machen.<br />meint --&thinsp;<big>[[Benutzer:✓|✓]]</big>&thinsp;<small><sup>[[Benutzer Diskussion:✓|Bergi]]</sup></small> 20:06, 21. Jun. 2010 (CEST)
: Das war mir auch störend aufgefallen - ich habs erst mal lokal (bei mir) übersteuert. Wie sehen die anderen das - Wikiweit gegensteuern? --[[Benutzer:Guandalug|Guandalug]] 21:12, 21. Jun. 2010 (CEST)
::Ich habe es auch selber überschrieben, da es aber anscheind keinen wikiweit stört, würde ich es einfach so lassen. [[Benutzer:Umherirrender/Sig|Der Umherirrende]] 11:08, 18. Mai 2012 (CEST)
:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Umherirrender/Sig|Der Umherirrende]] 11:08, 18. Mai 2012 (CEST)</small>

== div.flaggedrevs_short-Widget ==

Dieses Ding, das in allen [[Spezial:Seiten mit ungesichteten Versionen|Seiten mit ungesichteten Versionen]] prangt, hat (von Anfang an übrigens, also seit Mai 2008) drei extrem schwerwiegende Bugs:

# Es nutzt <code>float:right</code>, aber viele Artikel enthalten als allererstes Tabellen, die ebenfalls <code>float:right</code>, aber nicht <code>clear:right</code> benutzen, weil sie nicht damit rechnen, dass von oben etwas hereinfloatet. (Streng genommen kein Bug der FlaggedRevs, aber zumindest überraschendes Verhalten.) Wirkung: Die Tabellen rutschen nach links, rechts davon entstehen riesige Leerräume.
# Es hat einen ausklappbaren Teil, der aus dem <code>#contentSub</code>-Bereich heraus nach unten absolut positioniert ist, ohne auch nur zu versuchen, sich irgendwie gegen Vorlagen am Artikelanfang, die – warum auch immer – <code>position:relative</code> nutzen, zu schützen. (Diesen Bug habe ich gerade mit Müh und Not so umgangen, dass es in allen Browsern einschließlich der [http://therealcrisp.xs4all.nl/meuk/IE-zindexbug.html fehlerhaften] funktionieren sollte).
# Wenn JavaScript deaktiviert ist, ist der ausklappbare Teil immer ausgeklappt und verdeckt Artikelinhalte.

Letztes ist völlig inakzeptabel. Für Monobook wurde das umgangen, indem die ganze Box mit <code>position:relative</code> nach oben verschoben wurde, was das Problem aber nur verlagert. Dort oben steht sie nämlich im Bereich, der eigentlich für lange Lemmata reserviert ist, direkt unterhalb der Koordinaten und überschneidet sich mit dem Icon der [[Vorlage:Gesprochene Version]], weshalb die Box auch noch ein wenig nach links verschoben werden musste. In den anderen Skins war das Problem zu keinem Zeitpunkt in irgendeiner Form „gelöst“.

Unter „[[Spezial:Einstellungen]] → Bearbeitungsberechtigung“ gibt es eine Option „Verwende die detaillierte Übersicht, um den Markierungstatus von Seiten anzuzeigen“. Aktiviert man sie, verhält sich die Box völlig anders: Sie hat die drei oben aufgeführten Probleme nicht und nimmt zwar etwas mehr Raum ein, ragt aber auf der anderen Seite nicht in die Artikel hinein.

Meiner Meinung nach sollte zumindest den Benutzern, die JavaScript aktiviert haben, diese Variante standardmäßig angeboten werden; wegen der anderen, nicht ganz so schlimmen Probleme vielleicht sogar allen Benutzern. Dass ohne JavaScript Inhalte überdeckt werden, kann überhaupt nicht angehen. Bis eine bessere Lösung verfügbar ist, würde ich vorschlagen, den ausklappbaren Teil mitsamt des Pfeilsymbols standardmäßig für alle aus- und nur mit JavaScript wieder einzublenden, denn der ausklappbare Teil enthält keine lebensnotwendigen Informationen. Diejenigen, die JavaScript deaktiviert haben ''und'' die Zusatzinfos brauchen, können dann zur sogenannten „detaillierten Übersicht“ wechseln. --[[Benutzer:Entlinkt|Entlinkt]] 06:40, 24. Jun. 2010 (CEST)
:Heißt jetzt <code>flaggedrevs_short</code> und dürfte in der Zwischenzeit (fast 2 Jahre) ordentlich aussehen. [[Benutzer:Umherirrender/Sig|Der Umherirrende]] 11:07, 18. Mai 2012 (CEST)
:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Umherirrender/Sig|Der Umherirrende]] 11:07, 18. Mai 2012 (CEST)</small>

== Navbox ==

Um die '''Navbox''' von Transwiki hier korrekt einzubinden, wäre die folgende CSS-Einbindung hilfreich, da eine Konvertierung in Styles umständlich wäre. Die Transwiki-Navbox ist in meiner [[Benutzer:Weltforce/Vorlagenwerkstatt|Vorlagenwerkstatt]] verfügbar, bedarf aber die genannte Einbindung, um im korrekten Format zu funktionieren. Nach der Einbindung des Codes ist die Entwicklung dann so gut wie abgeschlossen. – ''gez.'' [[Benutzer:Weltforce|welt'''force'''<big>™ </big>]] | <sub>[[Benutzer Diskussion:Weltforce|<big><big>☣</big></big> Disc.]]</sub> 12:18, 7. Mai 2012 (CEST)

:Geht es dabei um [[:en:Template:NavBox]]? Bist du dir sicher, das diese hier (in der deutschsprachigen Wikipedia) gewünscht ist? Ich habe schon häufiger gelesen, das solche Gruppierungen nicht erwünscht seien. [[Benutzer:Umherirrender/Sig|Der Umherirrende]] 18:27, 7. Mai 2012 (CEST)
::Es geht dabei um die speziell an '''Transwiki''' angepasste NavBox. Ich habe nirgendwo gesehen, dass die Navbox unerwünscht wäre, im Gegenteil, manche finden es ganz nützlich. Wer das nicht mag, muss es halt nicht erstellen. Außerdem: solche Gruppierungen sind eigentlich nur positiv anzusehen. Findest du irgendwo einen Nachteil daran? – ''gez.'' [[Benutzer:Weltforce|welt'''force'''<big>™ </big>]] | <sub>[[Benutzer Diskussion:Weltforce|<big><big>☣</big></big> Disc.]]</sub> 21:13, 7. Mai 2012 (CEST)
:::Was versteht du hier unter "Transwiki"? Eine Box die über alle Wikis verfügbar ist? Welchen Vorlagennamen strebst du an? <code>collapseButton</code> gibt es bei uns garnicht. Als Diskussion gibt es beispielsweise [[Wikipedia:WikiProjekt_Vorlagen/Werkstatt/Archiv_2008/2#Vorlage_Navbox_aus_der_englischen_Wikipedia]] und sicher viele weitere. Sind zwar alle schon etwas älter, aber ich weiß nicht, ob sich die Meinung schon geändert hat. Ich werde das nicht umsetzen, möchte aber auch keinem im Weg stehen. [[Benutzer:Umherirrender/Sig|Der Umherirrende]] 21:31, 7. Mai 2012 (CEST)
::::Die Vorlage soll für Navigationsleisten zu Wahlen verwendet werden. Bisher sieht es hier so aus:
{{Navigationsleiste Wahlen in Tansania}}
Das Vorbild [[:en:Template:Tanzanian elections]] basiert auf der NavBox-Vorlage und sieht doch aufgeräumter aus. Selbst wenn die Vorlage nur für Wahlen verwendet werden soll, dann gibt es da schon an die 250 Verwendungsmöglichkeiten --[[Benutzer:Antemister|Antemister]] ([[Benutzer Diskussion:Antemister|Diskussion]]) 21:40, 7. Mai 2012 (CEST)

Transwiki ist ein WikiProjekt der englischen WP, welches sich zur Aufgabe genommen hat, viele Vorlagen sprachenübergreifend zur Verfügung zu stellen.  Zu deinem Beispiel: Ich sehe keinen Konsens, dass es unerwünscht ist. Wie schon gesagt, wenn Benutzer einen Mehrwert sehen, dann sollen sie's machen. Wenn die Vorlage komplett fertiggestellt ist, werde ich sie vorraussichtlich wieder nach Vorlage:Navbox verschieben. Ein Beispiel für eine Anwendung:

Tom Clancy's Splinter Cell:
Bücher: 1 | 2 | 3
Filme: 1 | 2 | 3
Orte und Schauplätze: 1 | 2 | 3
Figuren: 1 | 2 | 3

Wobei "Tom Clancy's Splinter Cell" der Titel ist, "Bücher, Filme usw." die Boxen und "1,2,3" die Links. Grüsse, – ''gez.'' [[Benutzer:Weltforce|welt'''force'''<big>™ </big>]] | <sub>[[Benutzer Diskussion:Weltforce|<big><big>☣</big></big> Disc.]]</sub> 22:04, 7. Mai 2012 (CEST)
:Ihr wollt also jedem Wiki die englischen Vorlagen aufdrücken? Okay, wenn das hilft. Ich empfehle einen deutschen Vorlagennamen, um die Akzeptanz zu erhöhen und die [[WP:Oma]] nicht zu überfordern. [[Benutzer:Umherirrender/Sig|Der Umherirrende]] 17:49, 8. Mai 2012 (CEST)
:: Hallo, ich bin gegen die Einführung der Vorlage, weil ihre Existenz dazu verführen würde, [[Wikipedia:Themenring|Themenringe]] zu erstellen, beispielsweise „Tom Clancy’s Splinter Cell“.  Mit den vorhandenen Navigationsleisten kommen wir gut hin.  --[[Benutzer:Wiegels|Wiegels]] [[Benutzer Diskussion:Wiegels|„…“]] 18:24, 8. Mai 2012 (CEST)
Worin siehst du einen Themenring, dass in einer Box ''sowohl'' "Bücher" ''als auch'' "Filme" aufgelistet sind? Klar, wir kommen gut hin, mit Windows 98 kommen wir doch auch gut, doch es fragt sich, kommen wir damit ''besser'' hin? Ich weise nochmal darauf hin, dass die Navleisten natürlich auch weiterhin verwendet werden müssen; es empfiehlt sich lediglich bei gewissen Themen, die Navbox zu verwenden. Außerdem:  Siehe "Wahlen in Tansania" oben: Lieber das oder eine Navbox? @Umherirrender: Ich habe mir den Namen "Navigationsbox" überlegt (Abkürzung Navbox, da Navigationsleiste auch mit NavLeiste abgekürzt wird). Die Parameter werden natürlich ins Deutsche genommen. Hier:
<pre>
{{Navigationsbox
|Name       = 
|Titel      = 
|Bild      = 
|Untertitel      = 
|Klasse  = hlist

|Gruppe1     = 
|Liste1      = 

|Gruppe2     = 
|Liste2      = 
 ...
|Gruppep20    = 
|Liste20     = 

|Anmerkung      =
}}</pre> – ''gez.'' [[Benutzer:Weltforce|welt'''force'''<big>™ </big>]] | <sub>[[Benutzer Diskussion:Weltforce|<big><big>☣</big></big> Disc.]]</sub> 19:04, 8. Mai 2012 (CEST)
:Ist das hier der richtige Ort für diese Anfrage? Oder sollte ich sie bei den Administratoren-Anfragen stellen, da hier offensichtlich nicht viele Admins aktiv sind... – ''mfg.'' [[Benutzer:Weltforce|welt'''force'''<big>™ </big>]] 17:03, 10. Mai 2012 (CEST)
::Unabhängig davon solltest du aber schauen, das <code>.collapseButton</code> auf unsere Bedürfnisse angepasst wird, weil es die Klasse hier nicht gibt, braucht es auch kein CSS dazu. Musst dir die hier genutzte Klasse heraussuchen. Ob man <code>.mw-collapsible-toggle</code> zentral ändern sollte, ist auch so die Frage. [[Benutzer:Umherirrender/Sig|Der Umherirrende]] 18:08, 10. Mai 2012 (CEST)
:::Gut, ich kümmere mich darum. Den CSS-Code werde ich anpassen, bei meiner eigenen common.css testen und dann hier nochmal posten. Kann ein bisschen dauern. – ''mfg.'' [[Benutzer:Weltforce|welt'''force'''<big>™ </big>]] 18:57, 10. Mai 2012 (CEST)
::::Gegen den langen Vorlagennamen spricht nichts. Ich würde außerdem vorschlagen, das alle, die die neue [[Vorlage:Navigationsbox]] verwenden, auch mit dem Präfix "Vorlage:Navigationsbox " anfangen, sowie (überwiegend) alle Navigationsleisten mit "Vorlage:Navigationsleiste " beginnen. [[Benutzer:Umherirrender/Sig|Der Umherirrende]] 20:28, 18. Mai 2012 (CEST)
----
So, die Vorlage ist nun meinerseits '''endgültig''' abgeschlossen. Die Vorlage wurde komplett ins Deutsche genommen:
<pre>
{{Navigationsbox
|Name       = 
|Titel      = 
|Bild      = 
|Untertitel      = 

|Gruppe1     = 
|Inhalt1      = 

|Gruppe2     = 
|Inhalt2      = 
 ...
|Gruppe20    = 
|Inhalt20     = 

|Weiteres      =
}}</pre> '''Wer es testen möchte: den folgenden Code in die eigene ''common.css'' kopieren und dann [[Benutzer:Weltforce/Vorlagenwerkstatt/Sandbox|diese]] Seite anschauen.'''

<syntaxhighlight lang="css">/* Navigationsbox CSS */
.navbox {                     /* Container Style */
    border: 1px solid #aaa;
    width: 100%; 
    margin: auto;
    clear: both;
    font-size: 88%;
    text-align: center;
    padding: 1px;
}
.navbox-inner,
.navbox-subgroup {
    width: 100%;
}
.navbox th,
.navbox-title,
.navbox-abovebelow {
    text-align: center;       /* Name und Undertitel */
    padding-left: 1em;
    padding-right: 1em;
}
th.navbox-group {             /* Gruppen */
    white-space: nowrap;
    /* @noflip */
    text-align: right;
}
.navbox,
.navbox-subgroup {
    background: #fdfdfd;      /* Hintergrundfarbe */
}
.navbox-list {
    border-color: #fdfdfd;    /* muss mit Hintergrundfarbe übereinstimmen */
}
.navbox th,
.navbox-title {
    background: #ccccff;      /* Level 1 color */
}
.navbox-abovebelow,
th.navbox-group,
.navbox-subgroup .navbox-title {
    background: #ddddff;      /* Level 2 color */
}
.navbox-subgroup .navbox-group,
.navbox-subgroup .navbox-abovebelow {
    background: #e6e6ff;      /* Level 3 color */
}
.navbox-even {
    background: #f7f7f7;      /* Even row striping */
}
.navbox-odd {
    background: transparent;  /* Odd row striping */
}
table.navbox + table.navbox {  /* 1px Rand */
    margin-top: -1px;
}
.navbox .hlist td dl,
.navbox .hlist td ol,
.navbox .hlist td ul,
.navbox td.hlist dl,
.navbox td.hlist ol,
.navbox td.hlist ul {
    padding: 0.125em 0;       /* Adjust hlist padding in navboxes */
}
.navbox .hlist dd,
.navbox .hlist dt,
.navbox .hlist li {
    white-space: nowrap;      /* Nowrap list items in navboxes */
    white-space: normal !ie;  /* IE < 8 no-wraps entire list, so disable it */
}
.navbox .hlist dd dl,
.navbox .hlist dt dl,
.navbox .hlist li ol,
.navbox .hlist li ul {
    white-space: normal;      /* But allow parent list items to be wrapped */
}
ol + table.navbox,
ul + table.navbox {
    margin-top: 0.5em;        /* Prevent lists from clinging to navboxes */</syntaxhighlight>Ich habe den Code ein wenig optimiert. – ''mfg.'' [[Benutzer:Weltforce|welt'''force'''<big>™ </big>]] 20:59, 10. Mai 2012 (CEST)
:Tut mir leid für meine Ungeduldsamkeit, aber ich möchte das Projekt vorantreiben: kann sich ein Admin das mal anschauen? – ''mfg.'' [[Benutzer:Weltforce|welt'''force'''<big>™ </big>]] 20:03, 12. Mai 2012 (CEST)

:: Weltforce, das ist nicht etwas, was ein Admin sich anschauen und beurteilen sollte, sondern jemand, der es versteht. Ein Admin kann es, falls verabschiedet und in einer eindeutigen Form vorliegend, dann nur irgendwo einfügen. [[Benutzer:-jkb-|-jkb-]] 18:11, 22. Mai 2012 (CEST)
::: Das ist mir schon klar, ich habe die Vorlage schließlich an die deutsche Wikipedia angepasst. Der Code oben liegt vor und funktioniert korrekt und browserunabhängig. Da die Common.css nur von Admins bearbeitet werden kann, stelle ich lediglich einen Bearbeitungsantrag. Der Code liegt in einer eindeutigen Form vor. --[[Benutzer:Weltforce|welt]][[BD:Weltforce|'''force''']]<big>™</big> 18:36, 22. Mai 2012 (CEST)
:::: Ich kann dein Ansinnen verstehen. Eine Trennung von Darstellung und Inhalt durch CSS-Klassen ist im Allgemeinen sinnvoll. In MediaWiki sieht zur Trennung von Darstellung und Inhalt Vorlagen vor. CSS-Klassen gibt es zwar auch, aber nur eine zentrale Definition für alle Seiten, die auch bei allen Seiten geladen werden muss. Wenn mal mit HTML5 das <code>[http://www.w3.org/TR/html5/the-style-element.html#the-style-element style]</code>-Element mit dem Attribut <code>[http://www.w3.org/TR/html5/the-style-element.html#attr-style-scoped scoped]</code> auch im Wikitext verwendet werden darf, dann sieht sie Sache anders aus. Bei deiner Vorlage lassen sich die CSS-Definitionen integrieren. Eine Notwendigkeit diese in die zentrale Common.css zu stellen sehe ich nicht. --[[Benutzer:Fomafix|Fomafix]] ([[Benutzer Diskussion:Fomafix|Diskussion]]) 20:03, 22. Mai 2012 (CEST)
::::: Gut, ich mache es mal. Dabei gibt es jedoch den Nachteil, dass der ohnehin schon komplizierte Quelltext noch verquellter ist.... --[[Benutzer:Weltforce|welt]][[BD:Weltforce|'''force''']]<big>™</big> 21:03, 22. Mai 2012 (CEST)

:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Weltforce|weltforce]] ([[Benutzer Diskussion:Weltforce|Diskussion]]) 13:50, 18. Jun. 2012 (CEST)</small>

== Hauptseite ==
<syntaxhighlight lang="css">
#hauptseite table {
	background: transparent;
}
</syntaxhighlight>
kann entfallen, denn seit [[bugzilla:26708|Bug 26708]]/[[rev:80495]] haben Tabellen eine transparente Hintergrundfarbe. --[[Benutzer:Fomafix|Fomafix]] ([[Benutzer Diskussion:Fomafix|Diskussion]]) 10:52, 26. Jun. 2012 (CEST)
:Ich habe es nur flüchtig überflogen, aber steht da nicht ''+* (bug 26708) Remove background-color:white from tables in Monobook and Vector''? Was ist mit den anderen Skins? --[[Benutzer:Weltforce|weltforce]] ([[Benutzer Diskussion:Weltforce|Diskussion]]) 01:41, 27. Jun. 2012 (CEST)
:: Siehe [[bugzilla:26708#c4]]. --[[Benutzer:Fomafix|Fomafix]] ([[Benutzer Diskussion:Fomafix|Diskussion]]) 08:30, 27. Jun. 2012 (CEST)
:::Ist nachvollziehbar, obwohl ich nur die "Hauptskins" getestet habe, denke aber mal, das passt. Ist [http://de.wikipedia.org/w/index.php?title=MediaWiki:Common.css&diff=104957391&oldid=103370319 angepasst]. [[Benutzer:Umherirrender/Sig|Der Umherirrende]] 20:24, 28. Jun. 2012 (CEST)

:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Umherirrender/Sig|Der Umherirrende]] 20:24, 28. Jun. 2012 (CEST)</small>

== id "artikelstadium" ==

Die id "artikelstadium" wird in [[Wikipedia:Bewertungsbausteine|Bewertungsbausteine]] verwendet, um die Platzierung am oberen Rechten Rand zu erreichen. Das Problem ist aber, das diese id auch mehrfach auf einer Seite vorhanden sein könnte ([[Berlin]]). Das sollte man aber vermeiden um kein invalides XHTML zu erzeugen. Vorschlag: id behalten (für Abwartskompatibilität) und zusätzlich eine Klassendefinition raus machen und die entsprechenden Vorlagen ändern. Es muss dabei nur daran gedacht werden, das in Common.css komplett auszublenden und bei den einzelnen Skins wieder einzublenden. Vielen Dank. [[Benutzer:Umherirrender|Der Umherirrende]] 20:12, 22. Nov. 2009 (CET)

:Mir aufgefallen: Bei einer Abwahl kommen sich die Bildchen zZt in die Quere (zumindest bei mir): http://de.wikipedia.org/w/index.php?title=Mare_Imbrium&oldid=67138478. Ist das so gewünscht oder Beifang der neuen Kandidaturenseite? → [[Benutzer:Man77|'''««''']]&nbsp;Man77&nbsp;[[Benutzer Diskussion:Man77|'''»»''']] 23:45, 22. Nov. 2009 (CET)
::Das konnte ich [http://de.wikipedia.org/w/index.php?title=Vorlage%3AKandidat&action=historysubmit&diff=67181403&oldid=66501609 beheben], jetzt verdeckt das Kandidatur-Icon das Exzellent. [[Benutzer:Umherirrender|Der Umherirrende]] 20:33, 23. Nov. 2009 (CET)
::: Wozu soll dass <code>none</code> gut sein? Es erzeugt ein zusätzliches <code>div</code> ohne Funktion. --[[Benutzer:Fomafix|Fomafix]] 10:06, 24. Nov. 2009 (CET)
::::Ich habe nur Quelltexte verglichen und da war mir der Unterschied aufgefallen. Ein Unterschied ist aber bei mir sichtbar (IE8). [[Benutzer:Umherirrender|Der Umherirrende]] 21:37, 24. Nov. 2009 (CET)
::::: Ohne das <code>none</code> ist durch den Zeilenumbruch ein störendes <code>p</code>-Element eingefügt worden. Ich’s [http://de.wikipedia.org/w/index.php?title=Vorlage:Kandidat&diff=67228273&oldid=67181403 entfernt]. --[[Benutzer:Fomafix|Fomafix]] 22:23, 24. Nov. 2009 (CET)
: <code>id="artikelstadium"</code> hat als <code>id</code> und nicht als <code>class</code> einen guten Grund, denn ein Artikel kann nur in einem Stadium sein. Allerdings wird diese Kennzeichnung von anderen Vorlagen auch verwendet (missbraucht), vorallem auch für die Ab-/Anwahl des Stadiums. Auch meiner Meinung nach sollte zusätzlich eine CSS-Klasse für alle absolut positionierten Elemente angelegt werden. Diese Klasse sollte in [[MediaWiki:Common.css]] mit <code>display:none;</code> ausgeblendet sein und in den Skins mit <code>display:block; position:absolute; right:''x''em; top:''y''em;</code> die rechte obere Ecke festgelegt werden. Von dort aus können die einzelnen Bildchen mit <code>margin</code> positioniert werden, so dass sie sich nicht überdecken, bzw. bewusst überdecken und mit <code>z-index</code> in der Reihenfolge festgelegt werden. Diese Definitionen können dann entweder in die Vorlagen oder per <code>id</code> in die Skins. Was wäre ein geeigneter Name für eine solche CSS-Klasse? --[[Benutzer:Fomafix|Fomafix]] 10:06, 24. Nov. 2009 (CET)
:* <code>ObenRechts</code>
:* <code>position_absolute</code>
:* <code>bapperlecke</code>
:: [[:en:MediaWiki:Monobook.css|<ins>en:</ins>MediaWiki:Monobook.css]] bzw. [[:en:MediaWiki:Vector.css|<ins>en:</ins>MediaWiki:Vector.css]] verwenden dazu <code>div.topicon</code>. --[[Benutzer:Fomafix|Fomafix]] 14:17, 23. Apr. 2010 (CEST)

:::Bestandsaufnahme zum Thema „absolut positionierte Elemente“:
:::* Es gab eine [[Wikipedia:Fragen zur Wikipedia/Archiv/2010/Woche 17#Auszeichnungen im Vektor-Skin|Diskussion auf FzW]], die als [http://de.wikipedia.org/w/index.php?title=Wikipedia:Fragen_zur_Wikipedia&diff=prev&oldid=74262809 „eingeschlafen“] archiviert wurde.
:::* Es gibt zurzeit 6 einschlägige IDs (#artikelstadium, #coordinates, #coordinates_3_ObenRechts, #editcount, #issnlink, #shortcut) und eine [[:Kategorie:Vorlage:mit absoluter Positionierung|Kategorie]] mit 20 Vorlagen und einer MediaWiki-Systemnachricht.
:::* Bei den IDs außer #artikelstadium sehe ich keinen aktuen Handlungsbedarf, sie werden zwar teils in mehreren Vorlagen verwendet, was vielleicht nicht ganz sauber ist, aber es sind Vorlagen, die sich dem Sinn nach ausschließen.
:::* Bei der ID #artikelstadium, verwendet in den Vorlagen [[Vorlage:Baustelle|Baustelle]], [[Vorlage:Exzellent|Exzellent]], [[Vorlage:Exzellentes Bild|Exzellentes Bild]], [[Vorlage:Gesprochene Version|Gesprochene Version]], [[Vorlage:Informativ|Informativ]], [[Vorlage:Kandidat|Kandidat]], [[Vorlage:Lesenswert|Lesenswert]], [[Vorlage:Listenreview|Listenreview]], [[Vorlage:Review|Review]] und der Systemnachricht [[MediaWiki:Sharedupload-desc-here]], gibt es jedoch jede Menge potenzielle und reale Konflikte: Artikel, die schon eine Auszeichnung haben und für eine andere kandidieren oder als gesprochene Version vorliegen, ausgezeichnete Bilder, die auf Commons liegen usw. All den vorgenannten Vorlagen ist gemein, dass sie oben rechts nur ein Icon, keinen Text anzeigen und an anderer Stelle auf der Seite, wo sie eingebunden sind, einen Baustein erzeugen.
:::Ich würde deshalb nun doch auch eine Klasse für diese Icons befürworten, unter der Voraussetzung, dass sie wirklich ''nur'' für Icons, nicht wie die anderen IDs für irgendwelchen Text verwendet wird. <code>topicon</code>, das in [[:en:MediaWiki:Monobook.css]] und [[:en:MediaWiki:Vector.css]] (Fomafix, du meinst doch sicher auch :en?) verwendet wird, halte ich für den geeignetsten Namen, der bisher ins Gespräch gebracht wurde. Gruß --[[Benutzer:Entlinkt|Entlinkt]] 20:40, 19. Mai 2010 (CEST)
:::: Ja, ich habe :en [http://de.wikipedia.org/w/index.php?title=MediaWiki_Diskussion:Common.css&diff=73512157&oldid=73347859 gemeint]. Dort wird <code>display:block</code> mit <code>!important</code> verstärkt, weil das <code>display:none</code> nicht in Common.css sondern im <code>style="…"</code> steht. Das hat den Vorteil, dass bei der [http://de.m.wikipedia.org/wiki/ mobilen Variante] die absolut positionierten Elemente nicht angezeigt werden, weil dort Common.css nicht eingebunden wird. Eigentlich wäre es besser, wenn es dafür eine [[MediaWiki:Mobile.css]] geben würde, oder gibt es das bereits? --[[Benutzer:Fomafix|Fomafix]] 21:10, 19. Mai 2010 (CEST)
::::: Ach wie schön, gerade heute erst habe ich die Option „Inline-CSS in der Vorlage“ aus der Kategoriebeschreibung [http://de.wikipedia.org/w/index.php?title=Kategorie:Vorlage:mit_absoluter_Positionierung&diff=74545013&oldid=73971950 entfernt], weil es bei uns, obwohl die Möglichkeit [[MediaWiki Diskussion:Common.css/Archiv/1#Absolute Positionierungen|seit 2006 bekannt ist]], nirgendwo so gemacht wird. Warum eigentlich nicht? Ja, die Idee ist interessant, vor allem für diese Bapperlbegleiticons, weil sie keinerlei Inhalt transportieren und ohne CSS nutzlos vor dem eigentlichen Bapperl stehen. Für die anderen absolut positionierten Elemente, die auch Text enthalten, der nirgendwo sonst angezeigt wird, vielleicht weniger (im Einzelfall zu überlegen). Ich persönlich würde die Klasse aber erstmal wie die IDs hier in Common.css ausblenden und für Vector implementieren (darum ging es ja ursprünglich in der FzW-Diskussion, für die Mobile-Variante wird dadurch nichts schlechter), es sei denn, wir könnten hier kurzfristig klären, ob <code>!important</code> in Vector.css & Co. unbedenklich ist. Können Benutzer es denn dann noch ohne Weiteres für sich überschreiben? Spielen alle Browser dabei mit? Gruß --[[Benutzer:Entlinkt|Entlinkt]] 21:55, 19. Mai 2010 (CEST)
:::::: Ich kenne keine Browser-Probleme mit [http://www.w3.org/TR/CSS2/cascade.html#important-rules !important]. <code>!important</code> kann mit <code>!important</code> überschrieben werden. --[[Benutzer:Fomafix|Fomafix]] 22:19, 19. Mai 2010 (CEST)
::::::: Okay, ich zögere bloß, weil ich nicht weiß, warum es bisher nicht so gemacht wurde. Weil niemand darauf kam oder weil es doch keine so tolle Idee ist? Allzu viel Zeit sollten wir uns damit wegen der bekannten 31 Tage aber auch nicht lassen. Wenn sonst niemand zeitnah Stellung nehmen mag, würde ich dazu tendieren, es der Einfachheit halber wie gehabt in Common.css auszublenden, dann können die Deklarationen von #artikelstadium in den Skins, in denen sie vorhanden sind (Monobook, Modern, [[MediaWiki:Standard.css|Klassik]]) 1:1 auf div.topicon ausgeweitet werden. Ändern kann man das später immer noch. Nochmal angefasst werden sollten die CSS-Dateien sowieso, um irgendwann nach den 31 Tagen #artikelstadium zu entfernen. --[[Benutzer:Entlinkt|Entlinkt]] 06:28, 20. Mai 2010 (CEST)

Keine Resonanz zu <code>!important</code>? Dann würde ich das für den Moment zurückstellen. Aber mal was anderes: Es gibt ja insgesamt 10 Vorlagen mit Icons. 8 davon beziehen sich im weitesten Sinne auf ein „Artikelstadium“ (Baustelle, Exzellent, Exzellentes Bild, Informativ, Kandidat, Lesenswert, Listenreview, Review). Von denen soll immer nur eines sichtbar sein, notfalls durch Übereinanderlegen. Und es gibt zwei „Ausreißer“:  [[Vorlage:Gesprochene Version]] und [[MediaWiki:Sharedupload-desc-here]]. Ausreißer insofern, als die beiden mit den anderen 8 kombinierbar sein sollen. Ich sehe zwei saubere Lösungen:
* Alle 10 Icons bekommen dieselbe Klasse (Namensvorschlag: <code>.topicon</code>). Die beiden „Ausreißer“ bekommen ''zusätzlich'' IDs (Namensvorschläge: <code>#spoken-icon</code> und <code>#commons-icon</code> zwecks Konsistenz mit der englischen Wikipedia). In den einzelnen Skins wird <code>div.topicon</code> so definiert, wie bisher <code>#artikelstadium</code> definiert war. Auch in den einzelnen Skins werden die „Ausreißer“ davon abgeleitet, indem nur die einschlägigen Deklarationen (<code>margin-right:</code> oder <code>margin-top:</code>, je nachdem, ob sie horizontal oder vertikal versetzt sein sollen) überschrieben werden.
* Nur die 8 Icons, die sich auf ein „Artikelstadium“ beziehen, bekommen dieselbe Klasse (Namensvorschlag: <code>.artikelstadium</code> zwecks Kontinuität). Die beiden „Ausreißer“ werden über IDs völlig unabhängig davon positioniert.
Der erste Vorschlag ist insofern eleganter, als er mit weniger Code auskommt und sich leichter auf zukünftige Iconwünsche erweitern lässt (aber, schon aus Platzgründen, auch nicht grenzenlos, das sollte den Iconwünschern gleich klar sein). Dafür wäre der zweite Vorschlag näher am jetzigen Zustand und ließe sich auf Umwegen auch kompakt schreiben: <code>div.artikelstadium, #spoken-icon, #commons-icon { /* Grundposition */ }</code>, darunter <code>#spoken-icon, #commons-icon { /* abweichende Position */ }</code>. Meinungen dazu? --[[Benutzer:Entlinkt|Entlinkt]] 19:56, 23. Mai 2010 (CEST)

Mangels anderslautendem Feedback setze ich jetzt folgendes um:
* Ich definiere eine neue Klasse <code>div.topicon</code>, hier in Common.css mit dem Inhalt <code>display:none</code> und in den drei Skins, in denen bisher die ID <code>#artikelstadium</code> definiert war, nämlich Monobook, Klassik und Modern, mit demselben Inhalt wie <code>#artikelstadium</code>. Diese Klasse legt in Zukunft die „Grundposition“ für ''alle'' absolut positionierten Icons fest – auch diejenigen, die nicht an der Grundposition stehen können oder sollen. Aber auch nur für Icons, ''nicht'' für andere absolut positionierte Elemente, die es bereits gibt oder in Zukunft gewünscht werden.
* Aus den betroffenen Vorlagen und der Systemnachricht entferne ich ''alle'' positionierungsrelevanten CSS-Anweisungen – insbesondere auch <code>top:23px</code> aus [[Vorlage:Gesprochene Version]] und <code>right:30px</code> aus [[MediaWiki:Sharedupload-desc-here]]. Alle Icons werden also standardmäßig an derselben Stelle („übereinander“) positioniert. Das liegt daran, dass meiner Meinung nach nicht skinunabhängig entscheidbar ist, ob zwei Icons neben- oder übereinander stehen sollen bzw. überhaupt Platz haben.
* In den drei betroffenen Skins – Monobook, Klassik und Modern – definiere ich IDs <code>#spoken-icon</code> und <code>#commons-icon</code>, mit denen das Icon aus [[Vorlage:Gesprochene Version]] gegenüber der Grundposition nach unten und das Icon aus [[MediaWiki:Sharedupload-desc-here]] nach links verschoben werden. Dies entspricht dem Verhalten der bis jetzt in den Vorlagen stehenden, von mir so vorgefundenen CSS-Anweisungen. Dass dieses Verhalten suboptimal ist, ist mir bewusst (ich würde empfehlen, <code>#spoken-icon</code> und <code>#commons-icon</code> an dieselbe Stelle zu setzen), aber ich habe ja nicht das Ziel, alle Skins zu verbessern, sondern falsches HTML zu korrigieren und die Umsetzung für Vector zu erleichtern. Wer es in „seinem“ Skin anders haben möchte, möge es dann also gern ändern.
* Ich begrenze die Größenangaben der Icons in den betroffenen Vorlagen und der Systemnachricht in Breite ''und'' Höhe, damit die Skins den notwendigen Platz zuverlässig reservieren können. Bislang haben die meisten Icons nur eine Breitenbegrenzung auf 15 Pixel und sind quadratisch. Zwei Ausnahmen gibt es: Das im März 2010 unsauber [http://de.wikipedia.org/w/index.php?title=MediaWiki:Sharedupload-desc-here&diff=71969994&oldid=71192614 eingebaute] Commons-Logo hat nur eine Breitenbegrenzung auf 14 Pixel und ist stark hochformatig (1376/1024 * 14 Pixel = 19 Pixel). Das Icon der [[Vorlage:Baustelle]] hat nur eine Breitenbegrenzung auf 20 Pixel, ist aber meiner Meinung nach eine völlig unnötige Spielerei, schließlich ist diese Vorlage in der Regel eh am Seitenanfang eingebunden (der Sprung vom Icon zum Baustein hat übrigens auch nie funktioniert, weil das Linkziel des Icons nicht mit der ID des Bausteins übereinstimmt), ich entferne es. Um dem Commons-Logo etwas entgegenzukommen, aber zugleich die Änderung für die viel länger bestehenden Auszeichnungsicons gering zu halten, wähle ich 16 Pixel.
* Wer irgendwelche Probleme bemerkt, möge bitte vor allem anderen den Hinweis aus [[MediaWiki:Clearyourcache]] versuchen. Aus demselben Grund sollte <code>#artikelstadium</code> sowohl in den CSS-Dateien als auch in den Vorlagen noch 31 Tage stehen bleiben.
--[[Benutzer:Entlinkt|Entlinkt]] 02:48, 25. Mai 2010 (CEST)

: Wird <code>#artikelstadium</code> noch irgendwo verwendet oder kann das nach zwei Jahren nun aus [[MediaWiki:Standard.css]], [[MediaWiki:Monobook.css]], [[MediaWiki:Modern.css]] und [[MediaWiki:Common.css]] entfernt werden? --[[Benutzer:Fomafix|Fomafix]] ([[Benutzer Diskussion:Fomafix|Diskussion]]) 12:32, 18. Mai 2012 (CEST)
::Wurde heute aus den einzelnen Skins entfernt: [https://de.wikipedia.org/w/index.php?title=MediaWiki:Modern.css&curid=3274751&diff=112835977&oldid=111373029 Modern], [https://de.wikipedia.org/w/index.php?title=MediaWiki:Monobook.css&curid=231457&diff=112835975&oldid=107617488 Monobook] und [https://de.wikipedia.org/w/index.php?title=MediaWiki:Standard.css&curid=511481&diff=112835972&oldid=75052355 Standard]. [[Benutzer:Umherirrender/Sig|Der Umherirrende]] 11:05, 12. Jan. 2013 (CET)
:::Ja, die Wiedereinblendung in den einzelnen Skins habe ich jetzt mal rausgenommen, weil die betroffenen Benutzer genug Zeit hatten, ihre Benutzerseiten anzupassen (die ID wurde im Wesentlichen nur noch auf Benutzerseiten verwendet, das hatte ich seinerzeit mal überprüft) und weil das Ganze in Vector sowieso noch nie funktioniert hat.
:::Wenn man jetzt auch noch die Ausblendung hier und in [[MediaWiki:Mobile.css]] entfernt, würde das Icon auf den betroffenen Seiten an unerwünschter Stelle erscheinen. Sollten wir das trotzdem machen? --[[Benutzer:Entlinkt|Entlinkt]] ([[Benutzer Diskussion:Entlinkt|Diskussion]]) 16:13, 12. Jan. 2013 (CET)
::::Ich habe es entfert: [http://de.wikipedia.org/w/index.php?title=MediaWiki:Common.css&diff=113010836&oldid=111525066 Common.css] und [http://de.wikipedia.org/w/index.php?title=MediaWiki:Mobile.css&diff=113010839&oldid=111423701 Mobile.css]. Dann sieht man die vorkommen noch und die Benutzer können die Sachen von ihrer Benutzerseite entfernen. Es wäre vermutlich auch ungern gesehen, wenn das einfach so entfernt wird. [[Benutzer:Umherirrender/Sig|Der Umherirrende]] 21:36, 15. Jan. 2013 (CET)
:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Umherirrender/Sig|Der Umherirrende]] 21:36, 15. Jan. 2013 (CET)</small>

== Ergänzung von allgemeinen CSS-Code ==

Hallo. Ich möchte einen Antrag auf Ergänzung von CSS-Code auf [[MediaWiki:common.css]] stellen. '''Der CSS-Code befindet sich unter [[Benutzer:Weltforce/common.css/hlist.css]]. Bitte reinkopieren.''' Zuerst: die Funktion, die ich gerne hinzufügen möchte, nennt sich ''hlist''.

hlist ist eine CSS-Funktion, mit der man Listenelemente in Aufzählungselementen umwandeln kann.
<syntaxhighlight lang="html5"><div class="hlist">
* Test1
* Test2
* Test3
</div></syntaxhighlight>
würde hlist dann als<br />
<code>Test1 '''·''' Test2 '''·''' Test3</code><br />
ausgeben.

Dieser Code kann nicht oder nur sehr sehr aufwendig in ''equivalent style statements'' umgewandelt werden; daher die Bitte, die CSS-Datei anzupassen. Hintergrund der ganzen Sache ist, dass es in Tabellen keine automatische Umwandlung von Zeilenumbrüchen in Leerzeichen gibt, wie man sie kennt. hlist könnte daher in Tabellen angewendet werden. Da die [[Vorlage:Erweiterte Navigationsleiste|Erweiterte Navigationsleiste]] hier technisch gesehen eine Tabelle ist, findet sie dort auch großen Nutzen. Man müsste dann z.B. nicht mehr <syntaxhighlight lang="html5">[[Color TV-Game 6]] • [[Coleco Telstar]] • [[Magnavox Odyssey]] • [[Pong]]</syntaxhighlight> schreiben, sondern könne einfach 
<syntaxhighlight lang="css">* [[Color TV-Game 6]]
* [[Coleco Telstar]]
* [[Magnavox Odyssey]]
* [[Pong]]</syntaxhighlight>
schreiben. Dies würde die Übersichtlichkeit stark verbessern.

Ein weiterer interessanter Nutzen findet sich in der herkömmlichen [[Vorlage:Navigationsleiste]]. Man müsste dort nicht mehr
<syntaxhighlight lang="css">[[Hochmut]]&nbsp;&#124;
[[Geiz]]&nbsp;&#124;
[[Neid]]&nbsp;&#124;
[[Zorn]]&nbsp;&#124;
[[Wollust]]&nbsp;&#124;
[[Völlerei]]&nbsp;&#124;</syntaxhighlight>
schreiben, sondern könne das einfach über
<syntaxhighlight lang="css">* [[Hochmut]]
* [[Geiz]]
* [[Neid]]
* [[Zorn]]
* [[Wollust]]
* [[Völlerei]]</syntaxhighlight>machen. Ist das nicht komfortabler?
Grüße, [[Benutzer:Weltforce|weltforce]] ([[Benutzer Diskussion:Weltforce|Diskussion]]) 02:27, 17. Jun. 2012 (CEST)
:Anmerkung: wenn man diese Funktion in style-Elemente umwandelt, würde das eine Menge Code-Vergewaltigung mit <code><nowiki><ul style="display:inline;"><li style="blahblahblah">...</li><li style="blahblahblah">...</li><li style="blahblahblah">...</li></ul></nowiki></code> usw ergeben. Deshalb die Bitte, das per CSS-Datei zu lösen. Ich bitte um zügige Bearbeitung. --[[Benutzer:Weltforce|weltforce]] ([[Benutzer Diskussion:Weltforce|Diskussion]]) 19:06, 17. Jun. 2012 (CEST)

Diese Ergänzungen sind nicht nötig, da sie keine wirkliche Verbesserung der Darstellung bringen. [[Spezial:Beiträge/88.130.210.5|88.130.210.5]] 17:20, 18. Jun. 2012 (CEST)
:Ach, warum haben wir dann überhaupt noch Vorlagen? Dies geht um die Übersichtlichkeit in der Vorlage intern. Und es geht darum, dass man solche Aufzählungselemente einfacher programmieren kann, was somit auch einsteigerfreundlicher ist. --[[Benutzer:Weltforce|weltforce]] ([[Benutzer Diskussion:Weltforce|Diskussion]]) 17:23, 18. Jun. 2012 (CEST)
::Übrigens irrst du dich wegen der Darstellung: es bewirkt, dass die Listenpunkte anders angezeigt werden. Und die Markierung der Listenpunkte selbst wurde deaktiviert. Verstanden? Wenn du dich hier beteiligen willst, solltest du überhaupt erst mal testen, was es bringt und was es macht und besser noch überhaupt ein wenig CSS verstehen. --[[Benutzer:Weltforce|weltforce]] ([[Benutzer Diskussion:Weltforce|Diskussion]]) 17:27, 18. Jun. 2012 (CEST)
:::Wenn du dich hier beteiligen willst, solltest du <u> vor </u> Änderungen die Diskussion suchen und nicht pampig reagieren, wenn du darauf hingewiesen wirst. Ich sehe diese Anfrage als erledigt an. Ob ich css verstehe oder nicht kannst du nicht beurteilen und spielt auch keine Rolle. [[Spezial:Beiträge/88.130.217.111|88.130.217.111]] 21:38, 18. Jun. 2012 (CEST)
::::Da bemühst sich jemand, um eine Kleinigkeit zu verbessern und bekommt einen Textbaustein einer IP an den Kopf geworfen, verbunden mit dem Vorwurf, er wäre pampig gewesen, als er sich die unnötige Mühe machte, auf diesen auch noch zu reagieren. Tststs --[[Benutzer:Roter Frosch|Tommes]] <small><sup>([[BD:Roter Frosch|<span style="color:#800000">Roter Frosch</span>]])</sup></small> 10:33, 19. Jun. 2012 (CEST)

Das Hinzufügen von neuen CSS-Klassen sollte gut überlegt sein, denn ein späteres Ändern oder Entfernen ist nur schwer möglich. Definitionen hier werden bei jedem Artikel geladen und verlangsamen die Ladezeit.

Ich bin gegen diese Erweiterung und zwar aus folgenden Gründen:
# Ich finde es problematisch, wenn die gewohnte Darstellung einer Liste in einem bestimmten Kontext völlig anders aussieht.
# Die intuitive Wikisyntax zur Erzeugung von <div style="background-color: #F9F9F9; border: 1px dashed #2F6FAB; padding: 0.5em">[[Color TV-Game 6]] • [[Coleco Telstar]] • [[Magnavox Odyssey]] • [[Pong]]</div> ist <div style="background-color: #F9F9F9; border: 1px dashed #2F6FAB; padding: 0.5em"><nowiki>[[Color TV-Game 6]] • [[Coleco Telstar]] • [[Magnavox Odyssey]] • [[Pong]]</nowiki></div>
# Eine Aufzählungsliste ist hier zwar semantisch interessant, aber ich finde sie unflexibel und nicht notwendig, da ich keinen Nutzen sehe.
# Nicht alle Browser kommen mit diesen CSS-Definitionen zurecht.
# Die CSS-Klasse scheint nicht für Artikeltext gedacht zu ein, sondern für nur Vorlagen.
# Die prinzipielle Funktion dieser CSS-Definitionen könnte auch mit einer Vorlage erzeugt werden:
Statt
<pre><div class="hlist">
* Erstens
* Zweitens
</div></pre> folgendes:
<pre>{{hlist
| Erstens
| Zweitens
}}</pre>
--[[Benutzer:Fomafix|Fomafix]] ([[Benutzer Diskussion:Fomafix|Diskussion]]) 11:18, 19. Jun. 2012 (CEST)
:Ich wäre mit so einer Vorlage durchaus zufrieden, kann sie aber nicht erstellen. Wenn du es machen könntest, wäre ich sehr dankbar. Glaub mir, in manchen Fällen wirst du solche Listen wünschen wollen. Ich könnte dir sogar ein gutes Beispiel nennen. Browser-Kompatabilität sollte kein Problem darstellen; der Code ist auch für IE angepasst. --[[Benutzer:Weltforce|weltforce]] ([[Benutzer Diskussion:Weltforce|Diskussion]]) 16:08, 19. Jun. 2012 (CEST)
:: <code>content</code> erfordert IE8: https://developer.mozilla.org/En/CSS/content --[[Benutzer:Fomafix|Fomafix]] ([[Benutzer Diskussion:Fomafix|Diskussion]]) 16:11, 19. Jun. 2012 (CEST)

[[Benutzer:Intforce/common.css/hlist.css]] ist schon länger auf Wunsch des Benutzers gelöscht, daher hat sich diese Anfrage wohl auch erledigt. [[Benutzer:Umherirrender/Sig|Der Umherirrende]] 19:50, 8. Mär. 2013 (CET)
:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Umherirrender/Sig|Der Umherirrende]] 19:50, 8. Mär. 2013 (CET)</small>



== Sun-ExtA ==
=== Analyse ===
Ich möchte anregen, den Gebrauch von Sun-ExtA zu minimieren, da dieser Font -- zumindest für IPA -- zu Darstellungsproblemen führt. Um zu sagen, wo genau er verschwinden soll, und wo stehenbleiben, müsste ich zuerst mal wissen, was Unicode, Unicode1 und Unicode2 machen sollen. Auf jeden Fall würde ich ihn bei IPA rausschmeißen wollen. Eigentlich gehört er doch nur bei CJK berücksichtigt, aber gerade dafür scheint keine zentrale Klasse definiert zu sein.

Siehe auch:
* [[Benutzer_Diskussion:Prince_Kassad#Sun-ExtA]]
* [[Wikipedia:Fragen_zur_Wikipedia#IPA-Template/CSS/Font]]

--[[Benutzer:Pjacobi|Pjacobi]] 22:44, 20. Mai 2009 (CEST)
:Unicode, Unicode1 und Unicode2 entsprechen den Planes 0, 1 und 2 in der [[Liste der Unicode-Blöcke]]. Ich hätte ja am liebsten die Klassen nach Schriftsystem aufgeteilt (so wie es z. B. im Wiktionary praktiziert wird), da damit Schriftprobleme vermieden werden können. -- [[Benutzer:Prince Kassad|Prince Kassad]] 22:57, 20. Mai 2009 (CEST)

Was genau stimmt da nicht ? Welche Zeichen sind betroffen ? Der WP-Editor spinnt hier. Ein Teil der Zeichen wird da nicht gezeigt:
{{IPA|ɐɑɒɓɔɕɖɗɘəɚɛɜɝɞɟɠɡɢɣɤɥɦɧɨɩɪɫɬɭɮɯɰɱɲɳɴɵɶɷɸɹɺɻɼɽɾɿʀʁʂʃʄʅʆʇʈʉʊʋʌʍʎʏʐʑʒʓʔʕʖʗʘʙʚʛʜʝʞʟʠʡʢʣʤʥʦʧʨʩʪʫʬʭʮʯ}}

Der Vorteil der Sun-ExtA ist halt, dass sie eine gute Abdeckung der Unicode-Ebene 0 auch für nichtchinesische Zeichen bietet. Für IPA ist sie allerdings nicht nötig, da gibt es genug anderes. [[Benutzer:Gismatis|Gismatis]] 04:12, 21. Mai 2009 (CEST)

:Die Reihe oben ist nicht betroffen. Vieleicht werden auch "nur" in IPA-Angaben Zeichen benutzt, die gar nicht IPA sind. Die Stelle, wo es mir deutlich aufgefallen ist: Vergleich: [[Datei:IPA-Vergleich-Burmese.png]]. --[[Benutzer:Pjacobi|Pjacobi]] 09:32, 21. Mai 2009 (CEST)

Kann es sein, dass die letzten 7 Zeichen des Blocks, welche der Editor nicht richtig zeigt, oft Ersatzzeichen genommen werden ? [[Benutzer:Cäsium137|Cäsium137]]&nbsp;[[Benutzer_Diskussion:Cäsium137|(D.)]] 14:19, 21. Mai 2009 (CEST)

:à (U+00E0) und (á U+00E1) sind tatsächlich keine IPA-Zeichen und sie werden mit Sun-ExtA grundsätzlich falsch dargestellt, nämlich mit der Form ɑ, das einen anderen Laut repräsentiert. Ich habe diese Buchstaben durch die Tonzeichen ˦ (U+02E6) und ˨ (U+02E8) [http://de.wikipedia.org/w/index.php?title=Birmanische_Sprache&diff=60285668&oldid=60225569 ersetzt]. Die sind unproblematischer als die Akzente und verleiten weniger zu Lesefehlern (Die Akzente könnten für steigende bzw. fallende Töne gehalten werden). Das normale a (U+0061) wird auch in Sun-ExtA richtig dargestellt (Hier fehlt leider ein eindeutiges Unicode-Zeichen). Es gibt also auch bei IPA keinen Grund, Sun-ExtA nicht zu verwenden. Die mysteriösen Punktwolken müssen auf jeden Fall im Auge behalten werden. [[Benutzer:Gismatis|Gismatis]] 16:58, 21. Mai 2009 (CEST)

::Es sind aber tatsächlich auch zwei IPA-Zeichen betroffen: <span style="font-family: Sun-ExtA">ɑɡ</span>. Zwar gibt es keine Punktwolken wie bspw. beim ü, aber trotzdem werden sie nicht korrekt dargestellt. -- [[Benutzer:Prince Kassad|Prince Kassad]] 17:21, 21. Mai 2009 (CEST)

:::Bei mir werden diese Zeichen richtig dargestellt. Hast du vielleicht eine ältere Version? [[Benutzer:Gismatis|Gismatis]] 18:23, 21. Mai 2009 (CEST)

Man könnte noch 'Sun-ExtA' mit 'DejaVu Sans' tauschen, aber die Vollständigkeit hat Vorrang vor den dahinter gelisteten Fonts mit nur 89 von 96 Zeichen. [[Benutzer:Cäsium137|Cäsium137]]&nbsp;[[Benutzer_Diskussion:Cäsium137|(D.)]] 14:26, 21. Mai 2009 (CEST)

:Du musst eine veraltete Version von DejaVu Sans haben. Meine Kopie weist alle 96 Zeichen auf. -- [[Benutzer:Prince Kassad|Prince Kassad]] 16:53, 21. Mai 2009 (CEST)

Du hast mich missverstanden: Ich meinte, 'DejaVu Sans' kann vor 'Sun-ExtA' weil es ebenfalls auch alle 96 Zeichen hat. die nachfolgenden aber nicht mehr. [[Benutzer:Cäsium137|Cäsium137]]&nbsp;[[Benutzer_Diskussion:Cäsium137|(D.)]] 00:28, 22. Mai 2009 (CEST)

OK, jetzt habe ich zusätzlich zum IPA- ein Verständnisproblem. 
* [[˦]] und [[˨]] sind rot!
* Laut unserem IPA-Artikel sind ˦ und ˨ gleichbedeutend mit den composing characters " ́" und " ̀". Letztere sind aber m.E. im Erscheinungsbild vorzuziehen. Ist es wirklich nötig, wegen des Defekts von Sun-ExtA überall von Letzteren auf Erstere umzustellen?
* Übrigens sind auch bei [[Internationales_Phonetisches_Alphabet#Töne_und_Intonation]] die Sun-ExtA-Fehler zu sehen.
Aber mal ganz pragmatisch gefragt: Warum schmeißen wir nicht einfach Sun-ExtA bei der CSS class IPA raus?
--[[Benutzer:Pjacobi|Pjacobi]] 17:35, 21. Mai 2009 (CEST)

:Ich finde die Stabzeichen besser, aber die anderen gehen natürlich auch. Was läuft denn da bei IPA bloß schief? Tauchen diese Probleme noch bei anderen Schriften auf? Wie gesagt, Sun-ExtA ist bei IPA nicht nötig. [[Benutzer:Gismatis|Gismatis]] 18:23, 21. Mai 2009 (CEST)

Wenn du eine der davor gelisteten Schriften auf deinem System hast, dann kommt SunExtA gar nicht zur Wirkung. Nur, wenn weder 'Quivira' noch Code2000' und, nach der von mir vorgeschlagenen Vertauschung, auch nicht 'DejaVu Sans' auf seinem Rechner hat, der bekommt IPA mit SunExtA gezeigt. [[Benutzer:Cäsium137|Cäsium137]]&nbsp;[[Benutzer_Diskussion:Cäsium137|(D.)]] 00:28, 22. Mai 2009 (CEST)

: Völlig korrekt, aber was hat das mit der Frage zu tun, ob der (für diesen Bereich fehlerhafte) Font SunExtA aus der Liste entfernt werden soll? --[[Benutzer:Pjacobi|Pjacobi]] 00:30, 22. Mai 2009 (CEST)


Die Schrift ist drin, da die anderen dahinter nicht komplett sind. Einfach als "letzte Möglichkeit vor der Unvollständigkeit". Besser Sun-ExtA als nur einen Teil der Zeichen und "Kästchen" sehen. [[Benutzer:Cäsium137|Cäsium137]]&nbsp;[[Benutzer_Diskussion:Cäsium137|(D.)]] 00:38, 22. Mai 2009 (CEST)

:: Das überzeugt nicht, insbesondere wegen der Beobachtung, dass die enwiki-Einstellungen bei mir noch nie zu Problemen mit IPA geführt haben. ("Charis SIL", "Doulos SIL", Gentium, GentiumAlt, "DejaVu Sans", Code2000, "TITUS Cyberbit Basic", "Arial Unicode MS", "Lucida Sans Unicode", "Chrysanthi Unicode") --[[Benutzer:Pjacobi|Pjacobi]] 00:55, 22. Mai 2009 (CEST)

Ohne Nummern kann ich das nicht nachvollziehen. Welche Zeichen genau (Hex-Nummern) werden von Sun-ExtA wie falsch dargestellt ? [[Benutzer:Cäsium137|Cäsium137]]&nbsp;[[Benutzer_Diskussion:Cäsium137|(D.)]] 00:43, 22. Mai 2009 (CEST)


Die Vokale mit Akut, Makron, Gravis, Hatschek oder Zirkumflex. Anscheinend unabhängig davon, ob sie precomposed eingegeben sind oder nicht:
{| class="wikitable" 
| {{IPA|&nbsp;́}} ''([[Akut]]) oder'' {{IPA-Zeichen|˦}}
| U+0301 ''oder'' U+02E6
| hoch
| {{IPA-Phon|é}}
|-
| {{IPA|&nbsp;̄}} ''([[Makron]]) oder'' {{IPA-Zeichen|˧}}
| U+0304 ''oder'' U+02E7
| mittel
| {{IPA-Phon|ē}}
|-
| {{IPA|&nbsp;̀}} ''([[Gravis (Typografie)|Gravis]]) oder'' {{IPA-Zeichen|˨}}
| U+0300 ''oder'' U+02E8
| niedrig
| {{IPA-Phon|è}}
|-
| {{IPA|&nbsp;̌}} ''([[Hatschek]])''
| U+030C
| steigend
| {{IPA-Phon|ě}}
|-
| {{IPA|&nbsp;̂}} ''([[Zirkumflex]])''
| U+0302
| fallend
| {{IPA-Phon|ê}}
|}
--[[Benutzer:Pjacobi|Pjacobi]] 00:55, 22. Mai 2009 (CEST)

:Wer bitte schön hat das geschrieben? Die Akzente sind nicht in IPA, und werden für verschiedene, teils sogar komplett gegensätzliche Töne benutzt. -- [[Benutzer:Prince Kassad|Prince Kassad]] 19:14, 22. Mai 2009 (CEST)

Das sind doch keine Zeichen vom Block IPA-Extensions. Der geht von U+0250 bis U+02AF = 96 Zeichen. Danach folgen

U-02B0 bis U+02FF "Spacing Modify Letters" und U+0300 bis U+036F der Block "Combining Diacritical Marks". [[Benutzer:Cäsium137|Cäsium137]]&nbsp;[[Benutzer_Diskussion:Cäsium137|(D.)]] 01:03, 22. Mai 2009 (CEST)

: Es geht mir nicht um den ''Unicode Block IPA-Extensions'', sondern um IPA. Und in IPA werden, wenn ich nicht völlig falsch liege, ein ganzer Haufen Zeichen verwendet, die nicht im ''Unicode Block IPA-Extensions'' liegen. Und wenn ein Font diese völlig falsch darstellt, dann ist er nicht zur Darstellung von IPA geeignet. Die obige Tabelle ist ein Ausschnitt aus [[Internationales_Phonetisches_Alphabet#Töne_und_Intonation]]. --[[Benutzer:Pjacobi|Pjacobi]] 01:08, 22. Mai 2009 (CEST)

Also ich sehe da keine großen Unterschiede. Ich generiere mal ein Vergleichsbild. [[Benutzer:Cäsium137|Cäsium137]]&nbsp;[[Benutzer_Diskussion:Cäsium137|(D.)]] 01:31, 22. Mai 2009 (CEST)

=== Sun-ExtA und IPA (2) ===
Hier der Vergleich (groß, damit man was sieht):

[[Datei:IPA-Vergleich.png|1000px]]

Was ist da schlimm ? [[Benutzer:Cäsium137|Cäsium137]]&nbsp;[[Benutzer_Diskussion:Cäsium137|(D.)]] 01:35, 22. Mai 2009 (CEST)

: Der Fehler tritt bei großen Schriftgrößen nicht auf! Irgendwo zwischen 14pt und 10pt wechselt die Anzeige bei SunExt auf die "Punktwolken" die Du in meinem Screenshot oben siehst. --[[Benutzer:Pjacobi|Pjacobi]] 01:38, 22. Mai 2009 (CEST)

Ach so. Ich habe es getestet. Es tritt bei 10, 9 und 8 (nicht bei 11 und nicht bei 7) auf. Aber nur, wenn die Anzeige im Textverarbeitungsprogramm auch auf 100% steht. Stellt sich die Frage nach der generellen Nutzung. Taucht anscheinend nur bei den "Kombizeichen" auf [[Benutzer:Cäsium137|Cäsium137]]&nbsp;[[Benutzer_Diskussion:Cäsium137|(D.)]] 01:47, 22. Mai 2009 (CEST)

P.S. Die SIL-Schriften sind nicht frei. Die würde ich nicht favorisieren. [[Benutzer:Cäsium137|Cäsium137]]&nbsp;[[Benutzer_Diskussion:Cäsium137|(D.)]] 01:57, 22. Mai 2009 (CEST)

: [http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=OFL SIL Open Font License (OFL)]. --[[Benutzer:Pjacobi|Pjacobi]] 09:53, 22. Mai 2009 (CEST)

Dann weis ich nicht, warum ich Spam-Mail mit Bezug auf angebliche Demolizenz und Werbung für Produkte bekommen habe, nachdem ich sie mal heruntergeladen habe. [[Benutzer:Cäsium137|Cäsium137]]&nbsp;[[Benutzer_Diskussion:Cäsium137|(D.)]] 16:08, 22. Mai 2009 (CEST)

Zum Thema: Wer kennt noch andere Zeichen, bei denen das auftritt ? [[Benutzer:Cäsium137|Cäsium137]]&nbsp;[[Benutzer_Diskussion:Cäsium137|(D.)]] 16:12, 22. Mai 2009 (CEST)

: Spam-Mails: Das kann ich Dir nicht sagen, ich habe solche Mails nie bekommen.
: So oder so, SunExtA muss aus der CSS Class IPA rausfliegen. Die jetzige Lage ist ja, dass für Nicht-MSIE-Benutzer die IPA-Anzeige durch die explizite Fontliste in der CSS Class ''schlechter'' und nicht besser wird als ganz ohne explizite Font-Angabe. Und die MSIE-Benutzer wären mit der Liste aus enwiki besser bedient. Sogar Schriftarten ohne U+02AE und U+02AF sind gegenüber SunExtA vorzuziehen, denn diese beiden Zeichen bringen es gerade mal auf je zweimaliges Auftreten im Artikelnamensraum, wohingegen die Kombinationen mit U+030? (die von SunExtA falsch dargestellt werden) wesentlich häufiger sind. 
: --[[Benutzer:Pjacobi|Pjacobi]] 16:17, 22. Mai 2009 (CEST)

Ich bin nicht drauf angewiesen. von mir aus kann sie weg. Weshalb soll die Klasse sonst schlechter sein ? Code2000 und Quivira sind doch recht gute Schriften.[[Benutzer:Cäsium137|Cäsium137]]&nbsp;[[Benutzer_Diskussion:Cäsium137|(D.)]] 18:07, 22. Mai 2009 (CEST)

Vorher evtl. Nachschauen, ob es keine neue Version mit Bugfix gibt. [[Benutzer:Cäsium137|Cäsium137]]&nbsp;[[Benutzer_Diskussion:Cäsium137|(D.)]] 18:50, 22. Mai 2009 (CEST)

:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Entlinkt|Entlinkt]] ([[Benutzer Diskussion:Entlinkt|Diskussion]]) 11:43, 11. Mai 2013 (CEST)</small>

== Vorlage für arabische Schriften bzw. "spanAr" ==

Servus!

Nachdem [[Wikipedia:Fragen_zur_Wikipedia/Archiv/2009/Woche_37#Umstellung_der_Darstellung_arabischer_Schrift.3F FZW]] nicht gefruchtet hat, frag ich mal hier, weil ich glaube, selbst auch ein bisschen klüger geworden zu sein.

Kurz worum's geht: Seit ca. 12.9. werden auf meinem PC arabische Schriften anders dargestellt als früher, und zwar in einer anderen Schriftart, wenn folgende Bedingungen erfüllt sind:
*das arabische Zeichen ist nicht "exotisch" (vgl [[Liste arabisch-basierter Alphabete]], d.h. i.d.R. es kommt im Farsi oder Arabischen)
*die Vorlage {{Vorlage|arabische Schrift}} wird verwendet, z.B. per {{Vorlage|ar}} u.s.w.

Soweit kein Problem bzw. Geschmackssache. Das Problem ist nun, dass, wenn in einem Wort sowohl Buchstaben verwendet werden, die den erstgenannten Punkt erfüllen, als auch solche, die dies nicht tun, erhalte ich über die Vorlagen von Punkt 2 am Bildschirm einen Darstellungsmischmasch. Die exotischeren Zeichen werden "alt" dargestellt, die gängigen "neu". Grenzen ein solches und ein solches Zeichen innerhalb eines Wortes aneinander, werden sie nicht verbunden. 

Außerdem, wenn ich schon beim Meckern bin, gibt es ein ähnliches Darstellungsproblem im Editierfenster, nämlich werden exotische Zeichen nicht "dazuverbunden".

Zum Illustrieren folgende Tabelle (Beispiel: "Sindhi" auf [[Sindhi]]) mit Screenshot von mir:

[[Datei:Sindhi Darstellung.JPG|right|upright=2.5|thumb|Screenshot]]
{| class="wikitable"
!Darstellung ohne Vorlage
|‏سنڌي‎
|-
!Darstellung mit Vorlage
|{{arabische Schrift|‏سنڌي‎}}
|-
!Darstellung im Editierfenster
|<code>‏سنڌي‎</code>
|-
|colspan=2|'''Darstellungssoll:''' vgl. [[:File:Wikinews-logo-sd.png]] rechts unten
|}

Meine bloße Vermutung ist, dass das erstgenannte Problem mit ''spanAr'' zusammenhängt, mehr Hoffnung gibt mir die Vorlage ''arabische Schrift'' nicht. Im zweiten Fall scheint die Schriftart im Editierfenster mit exotischen Schriften einfach überfordert zu sein, was schlicht und ergreifend lästig ist.

Für jegliche Hilfe und/oder Info dankend, → [[Benutzer:Man77|'''««''']]&nbsp;Man77&nbsp;[[Benutzer Diskussion:Man77|'''»»''']] 18:09, 28. Sep. 2009 (CEST)

:Bei mir ist die Darstellung stets gleich, das heißt unverbunden, ob angemeldet oder nicht. Das Zeichen <big>ڌ</big> muss ja sehr exotisch sei, da von meinen Schriftarten nur MPH 2B Damase und Sun-ExtA über eine Glyphe verfügen. Und selbst, wenn ich diese Schriftarten für alle Zeichen verwende, wird nichts verbunden, wobei man das von Multischriftenfonts vielleicht auch nicht erwarten darf. Aber welche Schriftart ist das denn bei dir ohne Vorlage, wenn es verbunden wird? Dann könntest du mit der Angabe <code>.spanAr {font-family: "Name der Schriftart" !important;}</code> in deinen persönlichen CSS-Einstellungen die Verwendung dieser Schriftart erzwingen. [[Benutzer:Gismatis|Gismatis]] 22:27, 28. Sep. 2009 (CEST)

:1. Text (ohne Vorlage) verwendet Arial. 2. Text (mit Vorlage) verwendet DejaVu Sans, welcher kein [[Sindhi]] unterstützt.<br>Ich bin mir nicht sicher, wie in diesem Fall vorzugehen ist. Durch die eigene Monobook kann man zwar die Deklarationen überschreiben, aber hier triffts ja anonyme Benutzer.<br>Vielleicht sollten wir hier von unserer neuen Möglichkeit gebrauch machen, Schriftarten in Webseiten einzubinden. -- [[Benutzer:Prince Kassad|Prince Kassad]] 22:57, 28. Sep. 2009 (CEST)

::Am liebsten wär mir eine Lösung, die das Problem endgültig und für alle löst, momentan mach ich's mal (etwas widerwillig) mit Monobook, damit mir beim Lesen nicht schlecht wird ;)
::Wobei hinzuzufügen ist, dass selbst Unicode [[:File:Image-Arwi.jpg|noch nicht alles]] berücksichtigt. → [[Benutzer:Man77|'''««''']]&nbsp;Man77&nbsp;[[Benutzer Diskussion:Man77|'''»»''']] 14:34, 29. Sep. 2009 (CEST)

:::joa, es fehlen auch noch Zeichen für die weißrussische arabische Schrift. Aber die sollte für uns nicht so wichtig sein.<br>Das Einbetten einer eigenen Schriftart sollte das Problem endgültig lösen, wir brauchen nur 1. eine Schriftart und 2. irgendwo Platz, um sie zu hosten. -- [[Benutzer:Prince Kassad|Prince Kassad]] 18:06, 29. Sep. 2009 (CEST)

:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Entlinkt|Entlinkt]] ([[Benutzer Diskussion:Entlinkt|Diskussion]]) 11:43, 11. Mai 2013 (CEST)</small>

== Mein Glück ==

soll ich hier [[Wikipedia:WikiProjekt_Vorlagen/Werkstatt/Archiv_2010/2#Gliederungsziffern_im_Inhaltsverzeichnis_verbergen|versuchen]]. Weiß jemand von den Web-Ingenieuren Rat? Auch für Verweise auf Seiten oder Mitarbeiter, die etvl. weiterhelfen können, bin ich sehr dankbar. Gruß, [[Benutzer Diskussion:Hæggis|Hæ]]<span style="color:#002bb8">gg</span>[[Benutzer:Hæggis|is]] 14:32, 19. Apr. 2010 (CEST)

: Hallo Hæggis, brauchst du das für dich oder möchtest du, dass eine solche Einstellung für alle Benutzer gilt?  Im ersten Fall kannst du folgendes in [[Spezial:Meine Benutzerseite/monobook.css|deine persönliche CSS-Datei]] schreiben:
: <code lang="css">body.ns-4 span.tocnumber { display: none; }</code>
: Die CSS-Klasse ns-4 steht hier für den Wikipedia-[[Hilfe:Namensräume|Namensraum]].  Viele Grüße --[[Benutzer:Wiegels|Wiegels]] [[Benutzer Diskussion:Wiegels|„…“]] 14:56, 19. Apr. 2010 (CEST)

:: Hallo Wiegels, genau da liegt ja das problem: Es wird als Seitencode für alle Benutzer in Form einer __NONUMTOC__-Zeile gebraucht, evtl. auch einer Vorlage (IV soll rechts eingebunden werden). Konkret ist es für eine Neustrukturierung der Überschriften in der [[Wikipedia_Diskussion:Hauptseite/Artikel_des_Tages|AdT-Disk]] gedacht: Wenn fortan nur noch die Kalendertage ohne „(2./3./…) Alternativvorschlag“ vornan stehen, verwirren die Gliederungsziffern nur, die zusätzliche Übersicht wäre dahin. Ohne Gliederungsziffern wärs das non plus ultra, schöner (soweit ein IV „schön“ sein kann ;) gehts kaum. -- [[Benutzer Diskussion:Hæggis|Hæ]]<span style="color:#002bb8">gg</span>[[Benutzer:Hæggis|is]] 17:29, 19. Apr. 2010 (CEST)

::: Um das zu erzielen, könnte man auf der Vorderseite folgenden Code einsetzen:
::: <code lang="css">.page-Wikipedia_Diskussion_Hauptseite_Artikel_des_Tages .tocnumber { display: none; }</code>
::: Es ließe sich auch erreichen, dass nur die Nummerierung ab oder auf der zweiten Ebene entfällt, aber ich glaube, das könnte Leser eher wieder verwirren.  --[[Benutzer:Wiegels|Wiegels]] [[Benutzer Diskussion:Wiegels|„…“]] 17:47, 19. Apr. 2010 (CEST)

:::: Bevor die Server explodieren, weil ich irgendwas falsch eingesetzt hab – könntest du das [[Esoterische Programmiersprache|Hexenwerk]] büdde vorerst auf [[Benutzer:Cum Deo/AdT/Designentwürfe]] lenken, damit ich daran experimentieren kann? Gruß, [[Benutzer Diskussion:Hæggis|Hæ]]<span style="color:#002bb8">gg</span>[[Benutzer:Hæggis|is]] 18:14, 19. Apr. 2010 (CEST)

::::: Mit Vorderseite meinte ich [[MediaWiki:Common.css]], die wir beide nicht bearbeiten können.  Zum Testen fügst du bitte in [[Spezial:Meine Benutzerseite/monobook.css|deine persönliche CSS-Datei]], in der ich nicht schreiben darf, folgendes ein und besuchst anschießend die [[Benutzer:Cum Deo/AdT/Designentwürfe|Testseite]].  Mit dem hierüber genannten Code kannst du aber auch die originale Artikel-des-Tages-Diskussion testen.
::::: <code lang="css">.page-Benutzer_Cum_Deo_AdT_Designentwürfe .tocnumber { display: none; }</code>
::::: --[[Benutzer:Wiegels|Wiegels]] [[Benutzer Diskussion:Wiegels|„…“]] 18:54, 19. Apr. 2010 (CEST)
:::::: Et funktioniert! Dankesehr, sieht einfach klasse aus, danke.
:::::: Kann bitte jemand… ach, ich frag [[Wikipedia:Administratoren/Anfragen#Gliederungsziffern_in_einem_zahlengeschw.C3.A4ngerten_IV_verbergen|direkt]]. -- [[Benutzer Diskussion:Hæggis|Hæ]]<span style="color:#002bb8">gg</span>[[Benutzer:Hæggis|is]] 16:13, 11. Mai 2010 (CEST)

Die Commons.css sollte, außer der Hauptseite, keine seitenindividuelle Anpassungen erhalten. Das Thema ist mehrere Jahre alt, sollte daher erledigt sein. [[Benutzer:Umherirrender/Sig|Der Umherirrende]] 19:53, 8. Mär. 2013 (CET)

:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Entlinkt|Entlinkt]] ([[Benutzer Diskussion:Entlinkt|Diskussion]]) 11:43, 11. Mai 2013 (CEST)</small>

== Modern und #mw_content (war: Externe-Links-Pfeil in Nicht-Monobook-Skins) ==

class="plainlinks" hat sich in letzter Zeit wieder weiter verbreitet, obwohl es bei Links auf de.wikipedia.org, toolserver.org und stable.toolserver.org nicht nötig sein sollte. Liegt wohl daran, dass der Code
<syntaxhighlight lang="css">
 #content a[href^="http://de.wikipedia.org"],
 #content a[href^="http://toolserver.org"],
 #content a[href^="http://stable.toolserver.org"] {
	background: none !important;
	padding: 0 !important;
}
</syntaxhighlight>
bei Modern und Vector nicht funktioniert. Was tun? --[[Benutzer:Entlinkt|Entlinkt]] 22:35, 23. Apr. 2010 (CEST)
:Bin ich blind, oder funktioniert es doch? (http://de.wikipedia.org hat unter Vector keinen Pfeil) --<span class='Person'>[[Benutzer:Euku|Euku]]:[[Benutzer_Diskussion:Euku|<sup>⇄</sup>]]</span> 23:44, 23. Apr. 2010 (CEST)
: [https://developer.mozilla.org/en/CSS/Attribute_selectors Attributselektoren] nach [http://www.w3.org/TR/css3-selectors/#attribute-selectors CSS3] können nicht alle Browser. --[[Benutzer:Fomafix|Fomafix]] 23:50, 23. Apr. 2010 (CEST)

::Sorry, vielleicht habe ich da irgendwas beim Testen mit Vector durcheinandergebracht, aber bei Modern bleibt der Pfeil wirklich erhalten ([http://de.wikipedia.org/w/index.php?title=MediaWiki_Diskussion:Common.css&oldid=73531311&useskin=modern#Externe-Links-Pfeil_in_Nicht-Monobook-Skins Beispiel]). Und zwar in demselben Browser, in dem es bei Monobook und Vector funktioniert (Firefox 3.6.3). Gruß --[[Benutzer:Entlinkt|Entlinkt]] 23:55, 23. Apr. 2010 (CEST)
::: Bei Modern heißt es nicht <code>#content</code>, sondern <code>#mw_content</code>. --[[Benutzer:Fomafix|Fomafix]] 00:04, 24. Apr. 2010 (CEST)
::::Und das heißt …? Dass es gar nicht nach Common.css gehört, da nicht „100%ig funktionierend (browser-, auflösungs- und skinunabhängig)“? Ich frage deshalb nach, weil mir in letzter Zeit mehrfach aufgefallen ist, dass plainlinks wieder gesetzt wurde, wo es nicht nötig sein sollte ([http://de.wikipedia.org/w/index.php?title=Vorlage:Fullurl&diff=73235191&oldid=71590766 Beispiel]). Gruß --[[Benutzer:Entlinkt|Entlinkt]] 00:12, 24. Apr. 2010 (CEST)
:::::stable.toolserver.org existiert übrigens nicht mehr.
:::::Ich habe bei mir lokal ausprobiert, dass man in die skin.css/js auch Vorlagen einbinden kann. So könnte man eine Unterseite machen, die in monobook/vector eingebunden wird um Redundanzen zu vermeiden. War aber bisher zu ängstlich das hier einfach umzusetzen. Müsste man erstmal im Testwiki ausprobieren. [[Benutzer:Merlissimo/Sig|Merl]][[Benutzer Diskussion:Merlissimo/Sig|issimo]] 00:57, 24. Apr. 2010 (CEST)
:Überall wird in letzter Zeit das plainlinks entfernt, mit der Begründung "da in Commons.css" und ich (=modern-Nutzer) seh' immer mehr Pfeile. Gibt es bald eine Lösung? [[Benutzer:Merlissimo/Sig|Merl]][[Benutzer Diskussion:Merlissimo/Sig|issimo]] 05:34, 9. Jun. 2010 (CEST)
::Die ordentliche Lösung steht in [[:bugzilla:14954#c4|Bug 14954, Kommentar 4]]: Würde Modern dieselben IDs und Klassen wie der Rest der Welt verwenden, gäbe es das Problem gar nicht.
::Eine nicht so ordentliche, aber funktionierende Lösung wäre, für Modern eben auch #mw_content hinzuzufügen. Ich frage mich aber eh, wozu die Einschränkung auf #content überhaupt gut sein soll. Zwar haben alle Skins außer Modern #content, aber es bedeutet nicht immer dasselbe:
::* Chick, Monobook, Myskin, Simple, Vector: #content geht von der Sitenotice bis zu den Kategorien (also quasi wirklich nur „Inhalt“)
::* Cologneblue, Standard: #content ist ein direktes Kindelement von body und umfasst alles außer der Seitenleiste (insbesondere auch Kopf- und Fußleiste); die Entsprechung zu #content in neueren Skins ist #article
::* Nostalgia: #content ist ein direktes und (abgesehen von einem Skript) das einzige Kindelement von body; die Entsprechung zu #content in neueren Skins ist #article
::Es zu entfernen, würde das Problem auch lösen. Diese Sache mit den Pfeilen ist übrigens auch nicht das Einzige, das in Modern nicht funktioniert. Offensichtlich natürlich alles mit #content, aber es gibt auch subtileres (zum Beispiel funktioniert die Ausblendung der Überschrift auf der Hauptseite nicht, weil Modern nur eine ID, aber nicht wie die anderen neueren Skins auch eine Klasse "firstHeading" hat und die Ausblendung über die Klasse erfolgt). --[[Benutzer:Entlinkt|Entlinkt]] 09:56, 9. Jun. 2010 (CEST)
:::Mal so allgemein zum ID-Konzept: Um Redundanz in den Skins zu vermeiden könnte man eine js/css anlegen, die dann in monobook und vector als Vorlage eingebunden wird (was auch funktioniert). Dann wäre es aus common raus. [[Benutzer:Merlissimo/Sig|Merl]][[Benutzer Diskussion:Merlissimo/Sig|issimo]] 12:47, 10. Jun. 2010 (CEST)

::::Ich meine, das konkrete Problemchen mit den Linksymbolen nun gelöst zu haben (die Dopplung mit #content und #mw_content ist zwar nicht so schön, aber harmlos; es funktioniert in allen Skins). Das Problem ist aber wesentlich allgemeiner. Vorhin ist mir zum Beispiel aufgefallen, dass die Regel mit dem Kommentar ''Expand URLs for printing'' aus [https://secure.wikimedia.org/skins-1.5/common/commonPrint.css commonPrint.css] in Modern nicht funktioniert, weil sie nur von #content ausgeht. Deshalb werden in Modern sämliche Links ohne die URL in Klammern ausgedruckt. Solche Fehler können im Prinzip überall stecken. --[[Benutzer:Entlinkt|Entlinkt]] 05:19, 7. Jul. 2010 (CEST)

Seit [[rev:111647]] gibt es die skinunabhängige ID <code>#mw-content-text</code>. Die einzelnen Skins verwenden zwar immer noch unterschiedliche IDs, um die Pfeile einzufügen, aber zum Abschalten können wir die einheitliche ID nehmen, weil sie eigentlich überhaupt nur gebraucht wird, um hier die Spezifität hochzuschrauben. --[[Benutzer:Entlinkt|Entlinkt]] ([[Benutzer Diskussion:Entlinkt|Diskussion]]) 19:17, 25. Mai 2013 (CEST)
:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Entlinkt|Entlinkt]] ([[Benutzer Diskussion:Entlinkt|Diskussion]]) 19:17, 25. Mai 2013 (CEST)</small>

== imagemap-inline: inline-block möglich? ==

Kennt jemand Nebenwirkungen, wenn man die display-Eigenschaft der Klasse von ''inline'' auf ''inline-block'' ändern würde?

Ich habe gerade Probleme bei
<div class="imagemap-inline"><imagemap>
Datei:Abies grandis cross section.JPG|100x100px
default [[Commons:Commons:Kandidaten für exzellente Bilder#File:Abies_grandis_cross_section.JPG|FPC+]]
</imagemap>
<imagemap>
Datei:Celastrina argiolus 1(loz).jpg|100x100px
default [[Commons:Commons:Kandidaten für exzellente Bilder#File:Celastrina_argiolus_1(loz).jpg|FPC+]]
</imagemap>
<imagemap>
Datei:Cetonia aurata (Linnaeus 1761).jpg|100x100px
default [[Commons:Commons:Kandidaten für exzellente Bilder#File:Cetonia_aurata_(Linnaeus_1761).jpg|FPC+]]
</imagemap></div>
wo sich das (i) wegen inline nicht mehr auf dem Bild befindet. Würde die Einführung einer neuen Klasse gerne vermeiden. [[Benutzer:Merlissimo/Sig|Merl]][[Benutzer Diskussion:Merlissimo/Sig|issimo]] 20:26, 21. Jul. 2010 (CEST)

:In der jetzigen Form funktioniert die Klasse vor allem auch deshalb nicht, weil Imagemaps aus zwei verschachelten divs bestehen und <code>.imagemap-inline div</code> beide selektiert. Korrekterweise sollte nur das äußere selektiert werden. Meinen Tests zufolge würde in den aktuellsten Versionen von Firefox, IE, Google Chrome und Opera folgendes funktionieren:
<syntaxhighlight lang="css">
.imagemap-inline div {
	display: block; /* jetzige Definition aufheben */
}
.imagemap-inline > div {
	display: inline-block; /* bessere Definition */
}
</syntaxhighlight>
:Nebenwirkungen:
:* Ältere Browser (IE 6/7, Firefox 2) unterstützen <code>inline-block</code> nicht, es kann aber u.&nbsp;U. durch Ausnutzung proprietärer Eigenschaften (hasLayout für IE und irgendwas mit <code>-moz-</code> für Firefox) emuliert werden;
:* Die Selektion mit <code>.imagemap-inline > div</code> ist auch nicht ganz zuverlässig (sie würde fehlschlagen, wenn zwischen dem Element, auf das die Klasse angewendet wird, und der Imagemap noch irgendein Wrapper ist), aber alternativlos, weil das äußere div, das wir erwischen wollen, keine Klasse oder dergleichen hat.
:Gruß --[[Benutzer:Entlinkt|Entlinkt]] 22:09, 21. Jul. 2010 (CEST)
::Mist. Ich hatte bei CSS 2 nachgeschaut und gerade erst gemerkt, das w3c dort inzwischen unter http://www.w3.org/TR/CSS2/ das 2.1 Dokument anzeigt, weil ich nicht mehr auf die Überschrift geachtet habe. Ich bin aber gerade auch zu blöd die letzte 2.0 Spezifikation zu finden. Unter http://www.w3.org/TR/#tr_CSS ist sie nicht aufgeführt. [[Benutzer:Merlissimo/Sig|Merl]][[Benutzer Diskussion:Merlissimo/Sig|issimo]] 22:58, 21. Jul. 2010 (CEST)
::Hab's gefunden unter http://www.w3.org/TR/1998/REC-CSS2-19980512/visuren.html#q7 . Aber wer hat sich bloß den Hintergrund beim Inhaltsverzeichnis http://www.w3.org/TR/1998/REC-CSS2-19980512/cover.html einfallen lassen? [[Benutzer:Merlissimo/Sig|Merl]][[Benutzer Diskussion:Merlissimo/Sig|issimo]] 23:02, 21. Jul. 2010 (CEST)
:::Im ursprünglichen CSS 2 von 1998 gibt es kein <code>display: inline-block</code> und auch kein Äquivalent dazu, das ist eine Neuerung von CSS 2.1.
:::Die jetzige Definition ist m.&nbsp;E. ziemlich nutzlos, weil sie nur in Verbindung mit <code>desc none</code> mehr oder weniger funktioniert (dann und nur dann gibt es das störende innere div nicht, und die Dokumentation unter [[Hilfe:Bilder#Bilder im Fließtext („inline“)]] behauptet auch gar nicht, dass es mit etwas anderem als <code>desc none</code> funktioniert) und man dann aber auch einfach Bildlinksyntax wie in <code><nowiki>[[Datei:...|link=...]]</nowiki></code> verwenden kann.
:::Im IE 6/7 kann man <code>display: inline-block</code> emulieren, indem man <code>display: inline</code> verwendet und dem Element zugleich [http://onhavinglayout.fwpf-webdesign.de/ Layout gibt], <del>was wegen der vorhandenen Breiten- und Höhenangaben eh schon der Fall ist</del>. In alten Firefox-Versionen verhält sich <code>display: -moz-inline-box</code> ähnlich wie <code>display: inline-block</code>.
:::Das Hauptproblem ist aber die Selektion: Wie erwischt man das äußere div und lässt das innere in Ruhe. <code>.imagemap-inline > div</code> wäre eine meistens (fast immer) passende Annäherung, aber im IE 6 geht selbst das nicht, weil er den <code>E&nbsp;&gt;&nbsp;F</code>-Combinator nicht versteht. Das wäre nur zu umgehen, indem das äußere div softwareseitig mit einer Klasse versehen wird. --[[Benutzer:Entlinkt|Entlinkt]] 23:22, 21. Jul. 2010 (CEST)

Dies hier wäre ein ziemlich übler, aber validierender Hack, der in allen nennenswerten Browsern außer Firefox 2 funktioniert:
<syntaxhighlight lang="css">
/* Jetzige Definition aufheben */
.imagemap-inline div {
	display: block;
}
/* Bessere Definition für Browser, die inline-block unterstützten (IE >= 8,
   Firefox >= 3, WebKit, Opera), dient im IE 7 nur als hasLayout-Auslöser */
.imagemap-inline > div {
	display: inline-block;
}
/* IE 7 */
:first-child ~ html .imagemap-inline > div {
	display: inline;
}
/* IE 6 */
* html .imagemap-inline div {
	display: inline-block; /* hasLayout-Auslöser */
}
* html .imagemap-inline div {
	display: inline;
}
* html .imagemap-inline div div {
	display: block;
}
</syntaxhighlight>
Ich sehe keine Möglichkeit, Firefox 2 mit validem CSS voll zu unterstützen. Da müsste man sich zwischen drei Optionen entscheiden:
* Auf proprietäre <code>-moz</code>-Eigenschaften zurückgreifen;
* inline als Fallback, damit wenigstens der Fall <code>desc none</code> weiterhin funktioniert (wobei die Kombination <code>desc none</code> und imagemap-inline aber eh unsinnig ist, seit man bei normalen Bildeinbindungen das Linkziel ändern kann);
* kein expliziter Fallback, gleichbedeutend mit block als Fallback.
Gruß --[[Benutzer:Entlinkt|Entlinkt]] 01:23, 22. Jul. 2010 (CEST)
:Hast du irgendwo gefunden, welche Browser moz-inline-block unterstützen? https://developer.mozilla.org/en/CSS/-moz-inline-box existiert nicht und https://developer.mozilla.org/en/CSS/display sagt ''Never supported reliably.''. Insofern fällt die Möglichkeit wohl aus.
:Die Wiki-Klammer-Link-Syntax kann ich wegen der Lizenz nicht verwenden, weil die Bilder nicht PD sind.
:Problem ist, dass es keine Möglichkeit gibt ".imagemap-inline div" als inline zu belassen und man mit block-Fallback sämtliche alt-Kompatibilität zerstört.
:Ich glaube wir sollten dem imagemap-div mal eine Klasse verpassen lassen.
:Ansonsten sehe ich derzeit keinen sinnvollen Anwendungsfall von imagemap-inline, weil die einzige Möglichkeit mit desc none per Klammersyntax mit leerem link-Parameter ersetzt werden sollte. Müsste man den Syntaxkorrekturleuten mal sagen, damit das langfristig eliminiert wird. [[Benutzer:Merlissimo/Sig|Merl]][[Benutzer Diskussion:Merlissimo/Sig|issimo]] 02:11, 22. Jul. 2010 (CEST)
::Statt -moz-inline-block sollte es -moz-inline-box <del>oder -moz-inline-stack</del> heißen. Mit den proprietären Eigenschaften kenne ich mich aber auch nicht besonders gut aus, weil ich sie normalerweise nicht benutze. Was mit -moz beginnt, unterstützen jedenfalls nur Gecko-Browser. Es würde in diesem Fall nur dazu dienen, eine standardisierte Eigenschaft für ältere Browserversionen zu emulieren, in denen etwas ähnliches wie das Gewünschte proprietär implementiert war.
::Ein Fallback mit inline wäre m.&nbsp;E. durchaus möglich, indem man ganz am Anfang entweder
<syntaxhighlight lang="css">
.imagemap-inline > div {
	display: inline;
}
</syntaxhighlight>
::oder (umständlicher)
<syntaxhighlight lang="css">
.imagemap-inline div {
	display: inline;
}
.imagemap-inline div div {
	display: block;
}
</syntaxhighlight>
::ergänzt. Eine Klasse für den Container habe ich mit [[:bugzilla:24483|Bug 24483]] bereits angefragt, erscheint mir so oder so sinnvoll.
::Gruß --[[Benutzer:Entlinkt|Entlinkt]] 02:26, 22. Jul. 2010 (CEST)
:::Ja ich meine -box, hab mich verschrieben, die Linkadresse war aber korrekt. Deine beiden Varianten funktionieren aber bei mir nicht. Da hatte ich natürlich schon alles - was mir einfiel - ausprobiert, aber die Bilder erscheinen damit immer untereinander und nicht in einer Zeile.
:::[http://de.wikipedia.org/w/index.php?title=Hilfe%3ABilder&action=historysubmit&diff=76931317&oldid=76705252 Aus der Hilfe habe ich die jetzige Möglichkeit entfernt]. Sehe dort keinen Nutzen mehr. Man könnte höchstens inline-thumbs erzeugen, was mit der anderen Syntax nicht möglich ist, aber das braucht niemand. [[Benutzer:Merlissimo/Sig|Merl]][[Benutzer Diskussion:Merlissimo/Sig|issimo]] 02:45, 22. Jul. 2010 (CEST)
::::Sorry, mit Dokumentation zu -moz-* kann ich nicht wirklich dienen. [http://blog.mozilla.com/webdev/2009/02/20/cross-browser-inline-block/ Hier] steht ein bisschen was (und am Ende invalides CSS, wobei man den IE-6/7-Teil leicht valide machen kann, aber bei -moz-* keine Chance), gefunden mit den Suchbegriffen "Cross-Browser Inline-Block".
::::Welche Varianten funktionieren wann nicht? Die beiden inline-Fallback-Varianten funktionieren dann nicht, wenn Firefox 2 benutzt wird und desc ≠ none ist; in dieser Konstellation funktioniert das Bisherige aber auch nicht. desc = none funktioniert damit weiterhin, insofern wäre es für Firefox 2 (Marktanteil irgendwo bei 0,5 bis 1 %) zumindest keine Verschlechterung und für die anderen eine Verbesserung. Gruß --[[Benutzer:Entlinkt|Entlinkt]] 03:13, 22. Jul. 2010 (CEST)
:::::-moz-inline-stack ist wohl eher nicht das Gewünschte. In http://www.webmasterworld.com/css/3685812.htm steht ein bisschen was über den Unterschied zwischen -moz-inline-box und Standard-inline-block. --[[Benutzer:Entlinkt|Entlinkt]] 03:45, 22. Jul. 2010 (CEST)

Wird die Klasse <code>imagemap-inline</code> überhaupt noch benötigt? Die Hauptmotivation für den [[Wikipedia:Verbesserungsvorschläge/Archiv/2007/Juli#imagemap_inlinen (erl.)|ursprünglichen Vorschlag aus 2007]] war wohl das Unterdrücken der standardmäßigen Verlinkung auf die Bildbeschreibungsseite bei kleinen Icons. Mittlerweile verwenden wir dafür schon seit ein paar Jahren keine Imagemaps mehr, sondern <code>&#x5B;[Datei:...|link=]]</code>. Laut [[Spezial:Suche/imagemap-inline|Suchfunktion]] wird die Klasse im Wesentlichen noch in der veralteten [[Vorlage:Imagemap]] und in substituierten Bausteinen auf Benutzerseiten verwendet. --[[Benutzer:Entlinkt|Entlinkt]] ([[Benutzer Diskussion:Entlinkt|Diskussion]]) 04:52, 18. Mai 2013 (CEST)

:Ich habe die Klasse jetzt [https://de.wikipedia.org/w/index.php?title=MediaWiki:Common.css&diff=122757175&oldid=122728166 entfernt], siehe auch [https://de.wikipedia.org/w/index.php?title=Wikipedia:Technik/Werkstatt&diff=122757301&oldid=122755469 hier]. --[[Benutzer:Entlinkt|Entlinkt]] ([[Benutzer Diskussion:Entlinkt|Diskussion]]) 05:06, 23. Sep. 2013 (CEST)
:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Entlinkt|Entlinkt]] ([[Benutzer Diskussion:Entlinkt|Diskussion]]) 05:06, 23. Sep. 2013 (CEST)</small>

== Fußnoten-Darstellung ==

Hi, ich beziehe mich nochmal auf [[MediaWiki Diskussion:Common.css/Archiv/1#Darstellung der Fußnoten|diese Diskussion]]. Damals (2006) wurde die Darstellung der Fußnoten-Zahlen geändert, damit die Zeilen nicht unterschiedlich hoch sind. Die Lösung finde ich suboptimal - z.B. weil das extra dafür vorgesehene <code>vertical-align:super</code> nicht benutzt wird und somit auch syntaktisch unklar ist, was das eigentlich ist. Außerdem führt diese Darstellung zu teilweise fehlenden Zahlen bei Opera dank eines sehr absurden Bugs. Bei der Lösung der en.wikipedia gibt es beide Probleme nicht.

Statt 
<syntaxhighlight lang="css">
.reference, .references sup 
{ 
font-size: 91%;
vertical-align: text-top;
position: relative;
top: -0.3em;
white-space: nowrap;
}
</syntaxhighlight> 
nutzen die 
<syntaxhighlight lang="css">sup.reference 
{
font-weight: 400;
font-style: normal;
}

sup, sub 
{ 
line-height: 1em;
}
</syntaxhighlight>

Die Verkleinerung der Schrift wird nicht mittels font-size sondern mittels line-height erreicht (die auf 1em statt auf 1.5em gesetzt wird). Dann muss weiter nichts relativ positioniert werden und dank des Standard-vertical-align stellen auch potentielle Browser, die das alles nicht kennen, das ganze halbwegs gut dar. Ich wollte jetzt nicht einfach mutig sein (nachdem ich gesehen habe, was damals für eine Diskussion darüber herrschte *g*) und stelle das daher hier mal zur Debatte. In der en.wikipedia scheint es gut zu funktionieren. --[[Benutzer:APPER|APPER]]\[[Benutzer Diskussion:APPER|<sup><big>☺☹</big></sup>]] 02:52, 31. Dez. 2009 (CET)
: Wenn’s auf en.wp benutzt wird, muss es ja ordentlich getestet worden sein. Hier sehen die Fußnoten ja wirklich scheußlich aus. Ich würde sagen: Ändern und auf eventuelle Meldungen bei FzW warten. Gruß, --Revo [[Benutzer Diskussion:Revolus|<small>''Echo der Stille''</small>]] [[File:Blue ribbon.svg|8px|link=:en:Blue Ribbon Online Free Speech Campaign]] 11:33, 4. Jan. 2010 (CET)
: Ja, <syntaxhighlight lang="css" inline>vertical-align: text-top;</syntaxhighlight> macht Probleme. <syntaxhighlight lang="css" inline>sup, sub { line-height: 1em; }</syntaxhighlight> ist gut. <syntaxhighlight lang="css" inline>font-weight: 400;</syntaxhighlight> verstehe ich nicht. Unter [[:en:MediaWiki:Common.css]] steht <syntaxhighlight lang="css" inline>sup.reference { font-weight: normal; font-style: normal; }</syntaxhighlight>. --[[Benutzer:Fomafix|Fomafix]] 16:36, 4. Jan. 2010 (CET)
:: <small>font-weigth:400 entspricht etwas dünner als normal: [http://de.selfhtml.org/css/eigenschaften/schrift.htm#font_weight]. --Revo [[Benutzer Diskussion:Revolus|<small>''Echo der Stille''</small>]] [[File:Blue ribbon.svg|8px|link=:en:Blue Ribbon Online Free Speech Campaign]] 19:46, 4. Jan. 2010 (CET)</small>
::: Ah, danke. <syntaxhighlight lang="css" inline>font-weight: 400;</syntaxhighlight> entspricht exakt <syntaxhighlight lang="css" inline>font-weight: normal;</syntaxhighlight> nach [http://www.w3.org/TR/CSS21/fonts.html#font-boldness CSS 2.1] und [http://www.w3.org/TR/2009/WD-css3-fonts-20090618/#font-weight-the-font-weight-property CSS3]. <syntaxhighlight lang="css" inline>font-weight: normal;</syntaxhighlight> finde ich aber leserlicher. --[[Benutzer:Fomafix|Fomafix]] 20:18, 4. Jan. 2010 (CET)
::::Ich hatte das nicht direkt aus der css genommen, sondern aus Dragonfly, Operas "Entwicklerwerkzeugen" - kann sein, dass Opera die "normal"-Angabe an der Stelle schon in 400 umgerechnet hat. --[[Benutzer:APPER|APPER]]\[[Benutzer Diskussion:APPER|<sup style="line-height: 1em;"><big>☺☹</big></sup>]] 02:11, 6. Jan. 2010 (CET)

Also richtig begeistert bin ich noch nicht; in Google Chrome wirken die Fußnoten im Text jetzt tiefergestellt („wirken“, weil sie in Wirklichkeit ja nur kleiner und exakt auf der Grundlinie sind), während sie im Firefox, Safari und Opera hochgestellt sind. Kann man das nicht irgendwie so machen, dass es zumindest in den State-of-the-art-Browsern gleich aussieht? [[Benutzer:PDD|&mdash; <sup>PDD</sup> &mdash;]] 19:24, 5. Jan. 2010 (CET)
:Kann ich nicht nachvollziehen. Bei mir sieht das in Chrome genauso aus wie in anderen Browsern (hochgestellt). Caching-Problem? --[[Benutzer:APPER|APPER]]\[[Benutzer Diskussion:APPER|<sup style="line-height: 1em;"><big>☺☹</big></sup>]] 02:11, 6. Jan. 2010 (CET)
:: Nö. Andere Version? Bei mir Chrome 4.0.266.0. [[Benutzer:PDD|&mdash; <sup>PDD</sup> &mdash;]] 02:15, 6. Jan. 2010 (CET)

»Keine Vergrößerung der Zeilenhöhe durch hochgestellte Zahlen der Fußnoten« soll bewirkt werden, aber derzeit ist dort »line-height: 1em« fest voreingestellt. Dadurch wird die Höhe jeder Zeile, die Fußnotenziffern enthält, hässlicherweise um etwa 1 bis 2 Pixel verrutscht (ich verwende die monobook.css mit Verdana unter Firefox 3.6.2 und MacOS 10.5.8). Diese auffallend unregelmäßigen Zeilenabstände nerven beim Lesen enorm und sind absolut unprofessionell. Gleichmäßige, korrekte Zeilenabstände hingegen erzeugt »line-height: 0em« – siehe de.wikipedia.org/wiki/Benutzer:Memex/monobook.css – jedenfalls bei mir. Ich bitte um Stellungnahme bzw. Korrektur. |[[Benutzer:Memex|Memex]] 16:39, 29. Mär. 2010 (CEST)
: Richtig, bei dem derzeitigen <code>sub, sup { line-height: 1em; }</code> werden bei meinem Firefox auch die Zeilenabstände auch um etwa 1 bis 2 Pixel vergrößert. <code>sub, sup { line-height: 0; }</code> vermeidet das Problem bei den Fußnoten im Fließtext, hat erzeugt aber ein Problem mit dem Zeilenabstand, wenn eine ganze Zeile in <code>sup</code> geschrieben ist:<br />Erste Zeile<br /><sup style="line-height:1">sup mit line-height:1</sup><br />Zweite Zeile<br /><sup style="line-height:0">sup mit line-height:0</sup><br />Dritte Zeile<br />--[[Benutzer:Fomafix|Fomafix]] 16:54, 29. Mär. 2010 (CEST)
:: Wozu sollte man denn ganze Zeilen in Superskript setzen? Für kleineren Text verwendet man Absatzformate mit entsprechender Schriftgröße usw. Ansonsten muss eben ein spezieller Stil für Fußnotenziffern her, denn so geht das nicht weiter. Habe selbst jedoch keinerlei Erfahrung mit dem hiesigen CSS-Konzept und wohl auch keine Änderungsrechte. Ist der offizielle CSS-Designer ansprechbar? |[[Benutzer:Memex|Memex]] 18:09, 29. Mär. 2010 (CEST)

:::<code>line-height:0</code> erscheint mir nicht wirklich korrekt. In den meisten aktuellen/standardkonformen Browsern schadet das zwar nicht, müsste aber vor dem IE (bis einschließlich Version 7) versteckt werden, weil er fälschlicherweise ganze Zeilen kollabiert, die nur aus hoch- oder tiefgestelltem Text bestehen (vgl. Beispiel von Fomafix oben).
:::<code>line-height:1</code> erscheint mir als der sinnvollste Wert und erzielt nach meinen Tests in allen Browsern außer Firefox einwandfreie Ergebnisse. Firefox verwendet offenbar einen suboptimalen Algorithmus für die <code>&lt;sub></code>/<code>&lt;sup></code>-Positionierung und verlässt sich auf Angaben in den Fonts, die teilweise falsch sind. Dies wird in [[:bugzilla:55555|Bug 55555]] thematisiert.
:::Außerdem gibt es noch [[:bugzilla:49965|Bug 49965]] bezüglich <code>line-height:0</code>, was hier wirksam würde, wenn es global gemacht wird; als lokale Anpassung würde ich das nicht machen, weil es zu problematisch ist. --[[Benutzer:Entlinkt|Entlinkt]] ([[Benutzer Diskussion:Entlinkt|Diskussion]]) 01:09, 19. Okt. 2013 (CEST)

Ich halte dieses Thema mit [[:bugzilla:49965|Bug 49965]] bzw. [[:gerrit:121953]] für erledigt (bis auf den Modern-Skin, d.&nbsp;h. sobald der Fix live ist, werde ich die entsprechende Regel von hier nach [[MediaWiki:Modern.css]] verschieben). Und selbst wenn es nicht erledigt wäre, sehe ich keinen Grund, es lokal und nicht global zu lösen. --[[Benutzer:Entlinkt|Entlinkt]] ([[Benutzer Diskussion:Entlinkt|Diskussion]]) 03:52, 30. Mär. 2014 (CEST)
:<small>Archivierung dieses Abschnittes wurde gewünscht von: [[Benutzer:Entlinkt|Entlinkt]] ([[Benutzer Diskussion:Entlinkt|Diskussion]]) 03:52, 30. Mär. 2014 (CEST)</small>