MediaWiki Diskussion:Common.css/Archiv/2

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[MediaWiki Diskussion:Common.css/Archiv/2#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/MediaWiki_Diskussion:Common.css/Archiv/2#Thema_1

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 style-Anweisungen zwischen die Tabelleninhalte zu streuen. Durch die Verwendung einer weiteren Klasse bliebe jedoch die Übersichtlicht im Tabelleninneren erhalten, ich würde hierfür toptextcells vorschlagen:

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

Durch ihre Verwendung würde aus

Tabellenquelltext	Vorschau
{| class="wikitable" | eins<br>zwei<br>drei<br>vier | einzig |}	eins zwei drei vier einzig

folgendes

Tabellenquelltext	Vorschau
{| class="wikitable toptextcells" | eins<br>zwei<br>drei<br>vier | einzig |}	eins zwei drei vier einzig

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

Der Name toptextcells 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 wikitable oder sortable zu machen. Sicherlich geht das auch noch besser.

Ich freue mich über Rückmeldungen. Grüße --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-CSS hier:

eins zwei drei vier

einzig

Sollte es aufgenommen werden, würde ich die Hilfeseiten entsprechend ergänzen. Grüße --Peu 10:20, 15. Jan. 2009 (CET)

Erscheint mir sinnvoll und valide, daher eingebaut. — Raymond ^{Disk. Bew.} 08:25, 16. Jan. 2009 (CET)

Danke! Teil 2 folgt (in Kürze) unter Hilfe:Tabellen. Grüße --Peu 12:51, 16. Jan. 2009 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 17:16, 20. Mär. 2009 (CET)

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:

 /* 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;
  }

wird zu

 /* 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;
  }

Vielen Dank. Der Umherirrende 17:21, 20. Mär. 2009 (CET)

Erl. — Raymond ^{Disk. Bew.} 10:04, 23. Mär. 2009 (CET)

Danke. Der Umherirrende 18:44, 23. Mär. 2009 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 18:44, 23. Mär. 2009 (CET)

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 ? Cäsium137 (D.) 18:31, 17. Aug. 2009 (CEST)

 Pro. Bei meiner monobook.css war das !important übrigens nicht notwendig. --Leyo 18:38, 17. Aug. 2009 (CEST)

•  Pro gute Idee! --Marcela 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. --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.

(P.S. bitte keine Manipulation an meinen D-Beiträgen)

Cäsium137 (D.) 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. --Der Umherirrende 20:48, 17. Aug. 2009 (CEST)

Man braucht den Platz darunter, um Lizenzbausteine einzubinden, die nicht in der Liste sind. --Marcela 20:53, 17. Aug. 2009 (CEST)

Dann schlage ich vor, wir fügen die Zeile

#wpUploadDescription { height: 20em;  } 

ein. Ok ? Cäsium137 (D.) 00:15, 19. Aug. 2009 (CEST)

Done. --Leyo 20:21, 28. Aug. 2009 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 20:35, 28. Aug. 2009 (CEST)

Hintergrundfarben nach Übernahme von wikitable in core-css

Bei wikitable 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? --Fomafix 12:47, 15. Jun. 2009 (CEST)

Hat diese CSS-Datei höhere oder niedrigere Priorität als die Common.css ? Cäsium137 (D.) 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 ausprobiert. Der IE6 versteht das so noch nicht. --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. Cäsium137 (D.) 11:44, 6. Jul. 2009 (CEST)

Die Farbe selbst ist nicht das Problem, da würde etwas dezent graues bevorzugen. #f2f2f2 ist neutral genug. Das Problem ist, dass jedes <th> 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 table.wikitable tr.hintergrundfarbe6 th { background-color: #b3b7ff; } könnte auch nachgeholfen werden. --Fomafix 12:54, 6. Jul. 2009 (CEST)

Also müsste die Stelle

 .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;
 }

auf folgendes ergänzt werden

siehe unten

Damit die hintergrundfarben in wikitable wieder funktionieren? Es wird ergänzt und nicht überschrieben, damit divs und prettytable weiterhin funktionieren. prettytable 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. 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. --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? 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: bgcolor="#e0e0e0" (Bereits bei HTML 4 Deprecated, aber trotzdem häufig verwendet)
• Mit CSS: style="background-color: #e0e0e0"
• Mit CSS-Klassen: class="hintergrundfarbe5"

Um eine Tabellenzelle mit einer Hintergrundfarbe einzufärben gibt es mehrere Stellen, wo diese Definitionen angebracht werden können:

• An der Tabellenzelle td bzw. th
• An der Tabellenzeile tr
• Am Tabellenkörper tbody (entfällt, weil von MediaWiki nicht erlaubt)
• An der Tabelle table
• An Elementen oberhalb der Tabelle (entfällt, weil Tabellen weiße Hintergrundfarbe haben)

Die neue Definition von wikitable mit automatischer Hintergrundfarbe für Tabellenkopfzellen

.wikitable th { background: #f2f2f2; }

passt im Artikelnamensraum für bestimmt für 80 % aller Tabellen und sorgt für eine einheitliche Darstellung. Die derzeitige Empfehlung mit class="hintergrundfarbe5" 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:

th mit style="background-color: red"

Selbst das HTML-Attribut bgcolor an der Tabellenkopfzelle funktioniert beim Firefox nicht mehr:

th mit bgcolor="red"

Wenn wir nun die CSS-Klassen hintergrundfarbex um die oben geschriebene Definition ergänzen, dann hätten wir folgende Situation bei wikitable:

• bgcolor="…" funktioniert nicht
• style="background-color:…" funktioniert nur bei Tabellenzellen, aber nicht bei Tabellenzeilen und bei table.
• class=hintergrundfarbex funktioniert an Tabellenzellen und an Tabellenzeilen, überschreibt da aber die Farbe von Tabellenzellen, sodass dort Zellenformatierung nicht mehr wirkt:

Tabelle mit class="hintergrundfarbe5" an der Zeile

mit class="hintergrundfarbe6"	ohne class="hintergrundfarbe6"

Mit der obigen Erweiterung für der CSS-Klassen hintergrundfarbex 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 wikitable weiterhin prettytable zu verwenden, wenn die Hintergrundfarben geändert werden sollen. --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 vorbringen. Der Umherirrende 18:56, 20. Jul. 2009 (CEST)

Gibt es:

 /* 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;
 }

Diese Darstellung wird aber nicht von allen Browsern verstanden. So versteht der Internet Explorer :not() nicht. Eine browserabhängige Darstellung ist noch schlechter, als eine unflexible, aber einheitliche Darstellung. --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. Cäsium137 (D.) 22:44, 20. Jul. 2009 (CEST)

Das table.wikitable 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. --Fomafix 22:58, 20. Jul. 2009 (CEST)

Wenn in http://de.wikipedia.org/skins-1.5/common/shared.css statt

.wikitable th {
    background: #f2f2f2;
}

besser

.wikitable th {
    background-color: #f2f2f2;
}

stehen würde, könnte mit

.wikitable th[bgcolor] {
    background-color: auto;
}

in MediaWiki:Common.css die veraltete HTML-Formatierung bgcolor in ! bgcolor="#fedcba" | Überschrift ermöglicht werden ohne :not() verwenden zu müssen. Der Internet Explorer 6 kann aber noch keine attributbedingte Formate. Besser wäre es daher, wenn in den Artikeln background-color von CSS verwendet wird. --Fomafix 13:58, 29. Jul. 2009 (CEST)

Das background: #f2f2f2; aus http://de.wikipedia.org/skins-1.5/common/shared.css kann auch hier überschrieben werden durch das etwas seltsam aussehende:

.wikitable th[bgcolor] {
background: transparent;
background-color: auto;
}

Damit wäre die HTML-Formatierung bgcolor an der Tabellenkopfzelle wieder möglich. --Fomafix 14:19, 29. Jul. 2009 (CEST)

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 :not([bgcolor]) { background-color: #xxxxxx }. Das ist aber alles unnötig, denn bgcolor ist veraltet und sollte durch CSS ersetzt werden. --Fomafix 15:07, 29. Jul. 2009 (CEST)

Testseite. Es fällt auf, das es sogar einen Fall mit prettytable gibt, der nicht funktoniert: bgcolor am table. --Der Umherirrende 14:31, 29. Jul. 2009 (CEST)

Danke für diese Testseite. --Fomafix 15:07, 29. Jul. 2009 (CEST)

Mit folgender CSS-Definition für die Hintergrundfarben

 table.wikitable tr.hintergrundfarbe6 th,
 table.wikitable tr th.hintergrundfarbe6,
 .hintergrundfarbe6 { /* Allgemein „bunt“, für Hervorhebungen und Unterscheidungen */
    background-color: #b3b7ff;
 }

würde sich das Problem kompensieren lassen, dass eine Zeilenhintergrundfarbe wegen der höheren Priorität eine Zellenhintergrundfarbe überschreibt. --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. Der Umherirrende 17:30, 29. Jul. 2009 (CEST)

Bei wikitable-Tabellen kann derzeit auch nicht die Hintergrundfarbe der gesamten Tabelle mit den CSS-Klassen hintergrundfarbex gesetzt werden:

wikitable-Tabelle mit hintergrundfarbe6

während es bei prettytable-Tabellen funktioniert:

prettytable-Tabelle mit hintergrundfarbe6

Die Ursache liegt darin, dass das core.css table.wikitable definiert und damit eine höhere Priorität hat. Beheben lässt sich das durch Anheben der Priorität: body .hintergrundfarbe6 oder table.hintergrundfarbe6, .hintergrundfarbe6. --Fomafix 14:57, 30. Jul. 2009 (CEST)

Das sieht gut aus und funktioniert. Dann wird die Definiton leider sehr umfangreich:

 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;
 }

Dann wären die hintergrundfarbe-Klassen wieder funktiontstüchtig. Fehlt nur noch background-color und bgcolor am th. Ich schlage eine vorzeitige Umsetzung vor. --Der Umherirrende 15:16, 30. Jul. 2009 (CEST)

Sieht jedenfalls auf den ersten Blick okay aus. Werde ich nachher mal testen... --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:

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

ergibt:

Hallo	Blah
Laber	Quack

Und das ganze nochmal mit prettytable:

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

ergibt:

Hallo	Blah
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? -- Chaddy · D·B - DÜP 20:46, 12. Aug. 2009 (CEST)

Da isses. Tschuldigung, die Aufgabe war ohne Änderung vom Tablett gerutscht. Ist jetzt drin. Besser so? (Den Cache nicht vergessen) --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. Der Umherirrende 22:02, 12. Aug. 2009 (CEST)

Danke, jetzt geht´s wieder. @Der Umherirrende: Kann man denke ich schon auf WP:NEU anpreisen. -- Chaddy · D·B - DÜP 22:21, 12. Aug. 2009 (CEST)

Aber erst, wenn auch das Problem unten gelöst ist. -- Chaddy · D·B - DÜP 22:25, 12. Aug. 2009 (CEST)

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

Stimmt, mit bgcolor und background-color: funktioniert´s noch nicht wieder richtig... -- Chaddy · D·B - DÜP 22:25, 12. Aug. 2009 (CEST)

neue Testseite mit mehr Fällen. Ich denke, ich habe jetzt alle möglichen abgedeckt. Der Umherirrende 23:36, 12. Aug. 2009 (CEST)

Die fehlende Definition für

wikitable hintergrundfarbe6 table tr th
zweite Zeile

lautet table.hintergrundfarbe6 tr th. Damit sind mir keine Fälle mehr bekannt, wo die Hintergrundfarbe-Klassen noch Probleme haben. --Der Umherirrende 19:46, 14. Aug. 2009 (CEST)

Traut sich keiner für diesen Punkt oder kann keiner das nachvollziehen? --Der Umherirrende 20:10, 28. Aug. 2009 (CEST)

Traut sich immer noch keiner? Falls es bedenken gibt, wäre es nett, sie mitzuteilen. Der Umherirrende 17:31, 18. Sep. 2009 (CEST)

Ich denke, die derzeitige Definition reicht. Wenn jemand class="wikitable hintergrundfarbe6" angibt, dann soll die Farbe der Tabelle geändert werden, aber Tabellenköpfe dürfen weiterhin automatisch hervorgehoben werden. --Fomafix 18:09, 18. Sep. 2009 (CEST)

Ja, könnte man auch so lassen, ich dachte nur an Gleichheit zu prettytable. Der Umherirrende 19:29, 14. Okt. 2009 (CEST)

Die Core-Definition zielt auf das th. Fügt man jetzt inlineCSS (bgcolor, background-color oder background) an übergeordnetet Elemente (tr oder table) 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. 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. Der Umherirrende 19:29, 14. Okt. 2009 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 19:29, 14. Okt. 2009 (CEST)

spezialseitenlinks entfettet

Mit dieser Änderung wurden die fetten Links auf Spezial:Spezialseiten entfettet. Diese CSS zieht seit rev:49025 nicht mehr. Es muss jetzt so lauten:

/* Fettformatierung von Admin-Spezialseiten in [[Special:Specialpages]] abschalten */
 .mw-specialpagerestricted strong {
        font-weight:normal;
 }

Es ist das strong hinter der Klasse hinzugekommen. Vielen Dank fürs ändern. Der Umherirrende 19:27, 14. Okt. 2009 (CEST)

 Ok Erl. — Raymond ^Disk. 19:45, 14. Okt. 2009 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: — Raymond ^Disk. 19:45, 14. Okt. 2009 (CEST)

Artikelkoordinaten bei neuen Skins

 #coordinates_3_ObenRechts, #issnlink, #editcount, #shortcut, #artikelstadium {
    display: none;
 }

muss ergänzt werden um

 #coordinates {
    display: none;
 }

{{Coordinate}} verwendet nicht nur #coordinates_3_ObenRechts, sondern auch direkt #coordinates. Mit display:none 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 display:inline. --Fomafix 13:18, 31. Aug. 2009 (CEST)

Benutzer:Euku hat die Änderung übernommen. --Fomafix 17:29, 3. Apr. 2010 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 17:29, 3. Apr. 2010 (CEST)

NavToggle

Wäre jemand mit entsprechender Berechtigung bitte so nett

.NavToggle {
    font-size: x-small;
    float:right;
}

zu

div.NavToggle {
    font-size: x-small;
    float:right;
}

umzuschreiben? Danke. -- Ishbane 16:47, 10. Mai 2010 (CEST)

Derzeit wird JavaScript aus MediaWiki:Common.js folgendes erzeugt:

<a class="NavToggle" id="NavToggle1" href="#">Ausklappen</a>

Zuerst muss daher die Änderung von Wikipedia:Administratoren/Anfragen#Vorschlag (Navigationsleisten) umgesetzt werden. --Fomafix 16:54, 10. Mai 2010 (CEST)

Benutzer:32X hat die Änderung rein und gleich wieder raus, weil die Formatierung der Knöpfe nicht mehr funktioniert hat.

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 09:23, 11. Mai 2010 (CEST)

wikitable ↔ prettytable

Hallo, hier bin ich darauf gestoßen, dass wiki- und prettytable nicht ganz gleich sind, sondern dass bei der prettytable noch ein text-align: center; aus [1] fehlt. Braucht es das nicht oder wurde das einfach vergessen?
fragt -- ✓ ^Bergi 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.... --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…
meint -- ✓ ^Bergi 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... -- Chaddy · D·B - DÜP 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... -- Chaddy · D·B - DÜP 17:39, 10. Apr. 2010 (CEST)

Welche Konstellation von Farbdefinitionen fehlen noch, wo sollte man Energie für aufwenden? Siehe auch im Archiv --Der Umherirrende 20:36, 10. Apr. 2010 (CEST)

Ja, die Diskussion kenne ich.

Bei der Formatierung mit ! funktiniert nur class="hintergrundfarbe5", style="background-color:#fedbca;" und bgcolor="#DDEEFF" dagegen nicht (da erscheint dann die Standardfarbe).

Ich verdeutliche das mal mit einem Beispiel:

Mit wikitable:

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

Test1	Test2
Test3	Test4
Test5	Test6

Mit prettytable:

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

Test1	Test2
Test3	Test4
Test5	Test6

Da alle diese Formatierungen sehr weit verbreitet sind, sollte man sie schon auch mit wikitable unterstützen... -- Chaddy · D·B - DÜP 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 herangetreten werden? Sollte jemand im verständlichen Englisch verfassen, ich bin dafür nicht geeignet. 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 ([2])... -- Chaddy · D·B - DÜP 23:37, 10. Apr. 2010 (CEST)

Kopfzelle	Kopfzelle
Nichtkopfzelle	Nichtkopfzelle
Kopfzelle	Nichtkopfzelle
Nichtkopfzelle	Kopfzelle

Das geschilderte Problem mit den Farben ist der Versuch, durch Setzen der Hintergrundfarbe einer Zeile (tr) die von wikitable gesetzte Hintergrundfarbe der Kopfzellen (th) 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 thead-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 3156 und 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; padding: 0.2em; } .wikitable th { background: #f2f2f2; text-align: center; } .wikitable caption { font-weight: bold; }	.wikitable { margin: 1em 1em 1em 0; background: #f9f9f9; border: 1px #aaa solid; border-collapse: collapse; empty-cells: show; } .wikitable th, .wikitable td { border: 1px #aaa solid; padding: 0.3em; } .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? empty-cells: show; ist eh Standard. Der Unterschied im padding 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. --Entlinkt 04:09, 6. Jun. 2010 (CEST)

Und wieso funktioniert das mit den Farben dann bei prettytable? :S -- Chaddy · D·B - DÜP 07:42, 6. Jun. 2010 (CEST)

Ist das eine rhetorische Frage? Wie auch immer, die Antwort lautet: Weil prettytable den ths 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 { background: #f2f2f2; text-align: center; } .wikitable caption { font-weight: bold; }

Das Entfernen der Hintergrundfarbe der ths bei wikitable (einzig mögliche „Lösung“, wenn man die Farben unbedingt an die trs 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 ths 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 padding: 0.3em; tut sie nämlich zurzeit nichts, macht es aber unübersichtlicher und verhindert, dass zukünftige Bugfixes an shared.css sich hier auswirken. --Entlinkt 15:25, 6. Jun. 2010 (CEST)

Nein, meine Frage war schon ernst gemeint. Danke für die Erklärung. -- Chaddy · D·B - DÜP 17:26, 6. Jun. 2010 (CEST)

Ich habe die lokale Definition von wikitable entfernt und prettytable einschließlich des text-align: center;, 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. --Entlinkt 03:06, 11. Jun. 2010 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Entlinkt 03:06, 11. Jun. 2010 (CEST)

"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? --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. --Entlinkt 14:47, 22. Jun. 2010 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Entlinkt 14:47, 22. Jun. 2010 (CEST)

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:

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

Zu dieser Situation gäbe es folgende Alternativen:

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

Meinungen? --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 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. --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. --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:

Leiste1

Text1

Leiste2

Text2

Leiste3

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):

Leiste1

Text1

Leiste2

Text2

Leiste3

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):

Leiste1

Text1

Leiste2

Text2

Leiste3

Text3

Linien zwischen den Leisten ganz verschwinden lassen und einfacher statt doppeltem Abstand dazwischen (auch nur mit Vorlage:NaviBlock machbar, Aussehen hier simuliert):

Leiste1

Text1

Leiste2

Text2

Leiste3

Text3

Gruß --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) Merlissimo 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 div.BoxenVerschmelzen div.NavFrame { padding-top: 0; }, für die erste Leiste mittels div.BoxenVerschmelzen { padding-top: 2px; } wieder aufzuheben); der letzte Block simuliert durch margin-top: -2px, wie es mit padding-top: 0 aussehen würde.

Der Grund, weshalb eine Lösung ohne Linie zwischen den Leisten ohne Vorlage:NaviBlock (bzw. Klasse BoxenVerschmelzen) m. 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ß --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 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. --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. Merlissimo 15:48, 28. Jun. 2010 (CEST)

Ich hätte folgende Varianten anzubieten:

/* 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%;
}

Ohne Vorlage:NaviBlock die Linien wegzubekommen, ist nicht so einfach; m. 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ß --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. --32X 19:37, 2. Jul. 2010 (CEST)

Es wurde die 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 Vorlagendokumentation anzupassen. Falls die Linien allgemein bevorzugt werden, würde sich das schon bemerkbar machen, indem die Vorlage zunehmend nicht mehr benutzt wird. --Entlinkt 23:18, 2. Jul. 2010 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Entlinkt 23:18, 2. Jul. 2010 (CEST)

Zusätzliche Absätze dank Link FA und Link GA

Die Ausblendung dieser Vorlagen mittels

/* hide the template */
#bodyContent span.FA {
	display: none;
}

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):

<p>
	<span id="interwiki-lt-fa" class="FA"></span>
	<span id="interwiki-vi-fa" class="FA"></span>
</p>

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. --Entlinkt 14:19, 2. Jul. 2010 (CEST)

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

Ich meinte vor allem das <p>-Element um alles herum. MediaWiki scheint darauf zu bestehen, dass sämtlicher Inhalt des Textfeldbereichs in Block-Elemente verpackt ist, und erzeugt <p>-Elemente, um das zu erzwingen. Dieses <p>-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 <p> 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. --Entlinkt 15:03, 2. Jul. 2010 (CEST)

Genau wegen des automatischen p-Elementes bei span sind div hier sinnvoller als span. --Fomafix 15:11, 2. Jul. 2010 (CEST)

Vorsicht beim generellen Ändern von span auf div bei absolut positionierten Elementen. Wenn eine solches Element im Fließtext verwendet wird, dann muss es ein span sein. Sonst kann es in manchen Browsern zu Darstellungsfehler kommen. Für Vorlage:Coordinate habe ich da ein Variante einbauen lassen. --Fomafix 15:23, 2. Jul. 2010 (CEST)

DAS ist in diesem Fall zum Glück egal - die Vorlage da wird gar nicht dargestellt.... ;) --Guandalug 16:18, 2. Jul. 2010 (CEST)

Bei dieser Vorlage nicht, das ist klar. Hier ist daher auch auf jeden Fall ein div angebracht.
Meine Aussage von oben muss ich korrigieren. Leere Elemente können die Darstellung durchaus beeinflussen. Vor allem der margin, wie er bei p-Elementen vorhanden ist. Dieser Abstand bei Verwendung der Vorlage ist wohl bisher niemand aufgefallen. div-Elemente haben normalerweise kein margin und beeinflussen die Darstellung daher üblicherweise nicht. Ein display:none könnte sicherheitshalber weiterhin trotzdem angegeben werden. Es wäre auch im style-Attribut geeignet. --Fomafix 18:24, 2. Jul. 2010 (CEST)

@Fomafix, das Problem kenne ich, aber es betrifft meines Wissens nur Vorlage:Editcount (sollte so in Ordnung sein), Vorlage:Coordinate (m. 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 <p>-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 Link FA und 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ß --Entlinkt 19:34, 2. Jul. 2010 (CEST)

Ich hab’s getan (1, 2, 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. --Entlinkt 23:18, 2. Jul. 2010 (CEST)

Nein, das lag an (vermutlich) uralten Fehlern. Ich habe die mal 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 --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ß --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. --Guandalug 10:05, 3. Jul. 2010 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Entlinkt 23:18, 2. Jul. 2010 (CEST)

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 font-family /**/: inherit;, 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: [3]. 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 font-family /**/: inherit; in Common.css, gewährleisten aber die Darstellung unter IE7 durch eine Spezialregel in Common.js.

Mein Vorschlag:

1. Wiedereinfügen von font-family /**/: inherit;. Dadurch ist eine korrekte Darstellung bis IE6 gewährleistet, ohne dass standardkonforme Browser beeinträchtigt würden.
2. 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:

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;');
    }
}

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. -- machᵗᵃˡᵏ 12:52, 1. Feb. 2010 (CET)

Entlinkt hat inzwischen zuverlässige CSS-Hacks für IE6 und IE7 eingebaut. --Fomafix 20:05, 7. Jan. 2011 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 20:05, 7. Jan. 2011 (CET)

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. -- machᵗᵃˡᵏ 16:31, 21. Feb. 2010 (CET)

Inzwischen ist alles in MediaWiki:Common.css mit CSS-Weichen und Vorlage:Polytonisch verwendet class="polytonic. --Fomafix 20:08, 7. Jan. 2011 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 20:08, 7. Jan. 2011 (CET)

margin auch für float-left

Hallo, könnte bitte analog zu margin: 1em 0 1em 1em; bei float-right auch für die float-left-Definitionen ein entsprechendes (1em 1em 1em 0) margin hinzugefügt werden? -- ✓ ^Bergi 19:57, 17. Feb. 2011 (CET)

Erledigt. --32X 22:03, 17. Feb. 2011 (CET)

Danke, das ging aber schnell! -- ✓ ^Bergi 22:38, 17. Feb. 2011 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: --32X 22:03, 17. Feb. 2011 (CET)

ul.float-right

Bitte ul.float-right und ul.float-left ergänzen, damit <gallery class="float-right"> wieder einen Abstand um die Bilder erzeugt (Hilfe:Bilder#Bilder pro Zeile und Ausrichtung). --Fomafix 00:13, 18. Feb. 2011 (CET)

Erledigt. --32X 11:57, 19. Feb. 2011 (CET)

ul.centered muss auch noch ergänzt werden, damit <gallery class="centered" perrow="4"> wieder zentriert wird. Ohne perrow wird es damit noch nicht zentriert, aber das wird mit Bug 27540 behoben. --Fomafix 18:09, 19. Feb. 2011 (CET)

Ebenfalls erledigt. Kommen noch weitere Bearbeitungswünsche Tröpfchenweise? --32X 22:04, 20. Feb. 2011 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: --32X 22:04, 20. Feb. 2011 (CET)

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ß --D.H 12:42, 7. Dez. 2008 (CET)

Seit 23. Februar 2011 existieren die CSS-Definitionen und die Vorlage:TOC limit. --Fomafix 23:08, 1. Sep. 2011 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 23:08, 1. Sep. 2011 (CEST)

Protokollrelative URLs

Hallo, auf Wikipedia wurden die protokollrelativen URLs eingeführt (beispielsweise von fullurl erzeugt, auch {{SERVER}} hat jetzt ein external-Icon: [4]). Das erfordert/ermöglicht einige Anpassungen:

/* 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;
}

sowie

/* 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);
}

Danke an den nächsten Admin für schnelle Umsetzung, -- ✓ ^Bergi 16:34, 28. Sep. 2011 (CEST)

ist drin, falls nötig bitte meckern. -- ∂ 17:19, 28. Sep. 2011 (CEST)

erledigt. --Fomafix 12:53, 6. Okt. 2011 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 12:53, 6. Okt. 2011 (CEST)

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 background: none repeat scroll 0 0 <farbe>; die Pfeile. Änderung in background-color: <farbe>; sollte das Problem beheben. --Steef ³⁸⁹ 11:49, 6. Okt. 2011 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Guandalug 12:19, 6. Okt. 2011 (CEST)

CSS-Kommentare

Hallo, hier wurden ungeeignete Kommentarzeichen verwendet. Könnte das bitte jemand korrigieren? Danke --Wiegels „…“ 23:57, 5. Nov. 2011 (CET)

Ich war mal so frei und habe das korrigiert (ändert ja nichts an der Funktionsweise) - Hoo man (Diskussion) 00:50, 6. Nov. 2011 (CET)

Es ändert etwas an der Funktionsweise, vorher gab es Syntaxfehler, jetzt ist es richtig. Der Umherirrende 11:27, 6. Nov. 2011 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 11:27, 6. Nov. 2011 (CET)

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? --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? --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. -- ✓ ^Bergi 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/. --Fomafix 19:44, 30. Nov. 2011 (CET)

Ich danke euch, ich werde da mal schauen. Grüße --Cepheiden 07:26, 5. Dez. 2011 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 19:44, 30. Nov. 2011 (CET)

FirstHeading auf der Hauptseite

durch den Eintrag

 /* Überschrift verbergen */
 body.page-Wikipedia_Hauptseite h1.firstHeading {
  display: none;
 }

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? 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:

#hauptseite {
  position:relative;
  top:-4em;
  margin-bottom:-4em;
}

--Fomafix 13:35, 19. Jun. 2009 (CEST)

Im Zusammenhang: Bug 24895 Bug 4438 --Der Umherirrende 21:56, 23. Aug. 2010 (CEST) korrigiert von ✓ ^Bergi 11:43, 24. Aug. 2010 (CEST)

Notiz für den Fall, dass die Sache irgendwann einmal durch Einführung einer Klasse action-view am body-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 body.page-Wikipedia_Hauptseite.action-view schreiben (das würde die Überschrift überall ausblenden), sondern body.action-view.page-Wikipedia_Hauptseite (dann bleibt es im IE 6 beim jetzigen Verhalten; anderen Browsern ist die Reihenfolge egal). --Entlinkt 00:27, 27. Aug. 2010 (CEST)

Funktioniert es beim IE6 richtig, wenn action-view am html-Element ist mit html.action-view body.page-Wikipedia_Hauptseite? --Fomafix 06:12, 27. Aug. 2010 (CEST)

Ja, aber die DTDs von HTML4 und XHTML1 erlauben kein class-Attribut am html-Element. Funktionieren tut es trotzdem in allen Browsern, weshalb es in HTML5 erlaubt ist. Ich habe allerdings in Bug 24915 angeregt, dann gleich alle Klassen von body nach html 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):

<!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>

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 wgAction verfügbar ist. Gruß --Entlinkt 06:29, 27. Aug. 2010 (CEST)

Ab sofort hat der body die Klasse action-view, wenn die Seite betrachtet wird, der Vorschlag kann also mit obigem Code umgesetzt werden. --Schnark 10:31, 6. Okt. 2011 (CEST)

Ja, das funktioniert. Es muss dazu das bisherige

body.page-Wikipedia_Hauptseite #catlinks,
body.page-Wikipedia_Hauptseite h1.firstHeading,
body.page-Wikipedia_Hauptseite #contentSub {
	display: none;
}

ersetzt werden durch

body.page-Wikipedia_Hauptseite #catlinks,
body.page-Wikipedia_Hauptseite.action-view h1.firstHeading,
body.page-Wikipedia_Hauptseite.action-view #contentSub {
	display: none;
}

--Fomafix 11:08, 6. Okt. 2011 (CEST)

Die CSS-Klasse action-view ist auch einem Versionsvergleich aktiv (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 historysubmit angegeben (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 view.

Der Code zum Erzeugen der CSS-Klasse (Bug 4438) wird derzeit von rev:91871 auf rev:108345 umgeändert. An dem Ergebnis ändert das aber nichts. --Fomafix 11:17, 8. Jan. 2012 (CET)

Dirzuliebe geändert. --32X 12:42, 8. Jan. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: --32X 12:42, 8. Jan. 2012 (CET)

Potenzielle Konflikte bei verschachtelten Tabellen

Alle Regeln, die Selektoren wie table tr oder table td o. ä. 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 table > tbody > tr bzw. table > tbody > tr > td, was aber meist nicht gemacht wird, weil der IE 6 den Kindselektor E > F 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 :nth-child() im IE 6 sowieso nicht funktioniert (sie funktioniert noch nicht mal im IE 8). Wäre es deshalb sinnvoll, die Definition

table.wikitable.zebra tr:nth-child(even) {
	background: white;
}

durch

.wikitable.zebra > tbody > :nth-child(even) {
	background: white;
}

zu ersetzen? Momentan hätte das keine Nebenwirkungen. Falls in Zukunft irgendwann einmal thead- und tfoot-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 thead, tfoot und tbody hinweg sowieso nicht möglich ist. --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 > 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 |- class="hintergrundfarbex" an geraden Tabellenzeilen hingewiesen. Dieses Problem könnte entweder an der Definition von .hintergrundfarbex mit !important oder mit Erhöhung der Selektor-Spezifität gelöst werden oder mit:

.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;
}

--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. E. korrigiert werden.

An individuell gefärbte Zeilen hatte ich jetzt gar nicht gedacht, weil sie sich mit Zebra-Tabellen m. E. ohnehin nicht besonders gut vertragen. Auf !important 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:

.wikitable.zebra > tbody > :nth-child(even):not([class*="hintergrundfarbe"]) {
	background: white;
}

So bleibt es relativ kurz und übersichtlich und löst m. 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ß --Entlinkt 17:25, 5. Aug. 2010 (CEST)

Bei MediaWiki werden derzeit die Definitionen für wikitable mit rev:107669 und follow-ups auf den child selector (neuerdings child combinator) umgestellt. Daher solle die Definition hier auch umgestellt werden. --Fomafix 19:16, 8. Jan. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: --32X 21:52, 8. Jan. 2012 (CET)

Listen in Tabellen

normal	Liste
Text in <p>	Liste
Text mit CSS	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:

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;
}

-- ✓ ^Bergi 20:08, 21. Aug. 2010 (CEST)

[5] Danke! -- ✓ ^Bergi 21:30, 26. Feb. 2011 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: --32X 21:52, 8. Jan. 2012 (CET)

weitere Projekt-URL

Hallo, könnte bitte jemand zu den entsprechenden Abschnitt mit http://upload.wikimedia.org ergänzen (zu Folgendem):

/* 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;
}

-- ✓ ^Bergi 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). --Entlinkt 02:20, 14. Sep. 2010 (CEST)

Natürlich ist der Bedarf nicht so groß wie bei den anderen Domains, 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 :-). -- ✓ ^Bergi 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 class="external" 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. --Entlinkt 20:57, 14. Sep. 2010 (CEST)

Mit Dateibeschreibung meinte ich so etwas wie 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 befreit werden (Es auf diese einzuschränken hätte allerdings hässliches CSS zur Folge). -- ✓ ^Bergi 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: [[:Datei:…]].
• Im Artikel Procol Harum wird http://upload.wikimedia.org/wikipedia/commons/1/1e/Air_%28Bach%29.ogg verlinkt. Sinnvoller wäre hier die Schreibweise {{filepath:Air (Bach).ogg}}. Seitdem protokollrelative Links aktiviert sind muss die Ausgabe hier mit […] explizit als Weblink angegeben werden: [6] statt //upload.wikimedia.org/wikipedia/commons/1/1e/Air_%28Bach%29.ogg. Weil die Dateiendung .ogg 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. --Fomafix 15:22, 8. Jan. 2012 (CET)

es gibt auch noch Media:Air (Bach).ogg oder auch {{Audio}}. Ein Direktlink auf .ogg hat den Nachteil, das kein Player da ist, nicht jeder Rechner kann das direkt abspielen. Der Umherirrende 16:13, 8. Jan. 2012 (CET)

An [[Media:…]] habe ich gar nicht gedacht. Damit ist der oben genannte Vorschlag für upload.wikimedia.org definitiv unnötig. --Fomafix 17:50, 8. Jan. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 15:22, 8. Jan. 2012 (CET)

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. --Hæggis 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 font-size: smaller; auf font-size: 88%; geändert. --Fomafix 15:41, 8. Jan. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 15:41, 8. Jan. 2012 (CET)

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: [7]

Bei uns fehlt diese Einstellung, dadurch ist der Grafikhintergrund im gleichen Grau wie der Rahmen: [8]

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. --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) -- Perhelion 00:10, 10. Mai 2011 (CEST)

Ich kanns leider nicht selbst ändern. Liest hier ein Admin mit, der das machen kann? --PM3 05:08, 15. Mai 2011 (CEST)

Mäander

 Kontra 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. --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. --PM3 09:39, 15. Mai 2011 (CEST)

Beim Skin Monobook haben die Bilder in Vollansicht auch einen farbigen Hintergrund: Beispiel mit Monobook --Fomafix 09:51, 15. Mai 2011 (CEST)

Oops. Ok, das ist ein gutes Argument gegen meinen Vorschlag. --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. --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. --PM3 10:26, 15. Mai 2011 (CEST)

Mit 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 (Beispiel im Translatewiki, Bug 26470, rev:96270).“ --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. --Fomafix 14:29, 8. Jan. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 14:29, 8. Jan. 2012 (CET)

Unicode-Fonts?

Bei mir werden alle Classes mit dem Pip "* " vor dem html nicht dargestellt. Getestet mit FF4 Windows7 und IE9, keine Ahnung was das für ein Workaround sein soll. -- Perhelion 04:25, 9. Jun. 2011 (CEST)

Das ist Absicht, da nur der IE6 und sonst kein anderer Browser diese Klasse auslesen soll. -- 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 #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. -- Perhelion 04:41, 9. Jun. 2011 (CEST)

Die IE-Versionen 6 und 7 verwenden je nach Statistik noch ungefähr 3 bis 14 Prozent.

Wie ein Browser die richtige Schrift finden soll, ist in CSS spezifiziert. Wenn nur Browser in Verwendung wären, die sich daran halten, bräuchte man die Vorlagen in der Tat nicht. Gruß --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. --Fomafix 13:54, 8. Jan. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 13:54, 8. Jan. 2012 (CET)

Urls auf verwandte Projekte

Hallo! könnte man die Urls auf verwandte Projekte um commons erweitern? Hintergrund: Wir wollen im Zuge von 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 --AleXXw •שלום!•disk 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 --K@rl (Verbessern ist besser als löschen) 16:29, 24. Jul. 2011 (CEST)

und so? --Herzi Pinki 19:10, 24. Jul. 2011 (CEST)

Danke, so fullurl hatte ich auch mit http versucht... LG --AleXXw •שלום!•disk 06:49, 25. Jul. 2011 (CEST)

Pfeil wird nicht mehr angezeigt. --Fomafix 13:39, 8. Jan. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 13:39, 8. Jan. 2012 (CET)

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. Der Umherirrende 21:53, 1. Sep. 2011 (CEST)

IE kennt die dafür notwendige Pseudoklasse :target erst seit der Version 9. --Schnark 09:29, 2. Sep. 2011 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 13:27, 8. Jan. 2012 (CET)

Bug 23902

Auf der Vorderseite steht derzeit folgendes:

/* [[bugzilla:23902]] */
.mw-search-formheader div.search-types ul li a {
	background: none !important;
	padding: 0.5em !important;
}

Der 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. --Fomafix 13:53, 6. Okt. 2011 (CEST)

rev:98690 ist mit rev:107938 live. Der oben aufgeführte Workaround kann hier nun entfernt werden. --Fomafix 13:09, 8. Jan. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: --32X 13:20, 8. Jan. 2012 (CET)

Spezial:Spezialseiten

MediaWiki:Common.css enthält derzeit folgende Definitionen für Spezial:Spezialseiten:

/* 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;
}

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 strong ist nicht mehr vorhanden:

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

mit

.mw-specialpagerestricted {
	font-weight: bold;
}

Die Definition kann daher entfallen. Wer als Admin oder als Sichter sich über die fette Zeilen stört, kann sie sich selbst in seiner 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. --Fomafix 17:43, 8. Jan. 2012 (CET)

Legende

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

---

• Reguläre Spezialseiten
• Zugriffsbeschränkte Spezialseiten
• Gecachte Spezialseiten (Deren Inhalt ist möglicherweise veraltet.)

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 style="display:none" in MediaWiki:specialpages-note vorzunehmen. --Fomafix 17:43, 8. Jan. 2012 (CET)

Die Umsetzung erfolgte vorschlagsgemäß. --32X 07:54, 9. Jan. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: --32X 07:54, 9. Jan. 2012 (CET)

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

In normalen Browsern ist html das root-Element von HTML-Dokumenten:

<!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>

Im Internet Explorer haben HTML-Dokumente ein zusätzliches Element, hier „msieroot“ genannt, das bis zum IE 7 nachweisbar ist:

<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>

Bis zum IE 6 kann man von „msieroot“ ausgehend * html selektieren. Im IE 7 wurde das oberflächlich unterbunden, aber :first-child ~ html funktioniert. Dabei selektiert :first-child die DOCTYPE-Deklaration (die auch in manchen anderen Browsern selektiert werden kann, jedoch nicht mit :first-child, weil sie in normalen Browsern kein Kind von irgendetwas ist), ~ überspringt etwaige Kommentare und html selektiert das eigentliche root-Element. Das vielerorts empfohlene :first-child + html funktioniert meist auch, würde aber fehlschlagen, wenn zwischen DOCTYPE und html ein Kommentar steht, weil der IE 7 nicht nur DOCTYPE-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. 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 gestrichen wurden) wie ein IE 7 verhält und auch der IE 9 einen IE-7-Modus enthalten wird. --Entlinkt 01:32, 30. Jun. 2010 (CEST)

Zur Dokumentation ins Archiv. Weitere Informationen stehen unter en:CSS filter. --Fomafix 16:30, 18. Jan. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 16:30, 18. Jan. 2012 (CET)

hintergrundfarbe2

Hallo, nachdem in sämtlichen nicht-monobook-Skins (und auch dem neuen Vector) die Standardhintergrundfarbe #FFF ist, lohnt sich diese Definition doch überhaupt nicht. Ich würde daher vorschlagen, diese Hintergrundfarbe auf ca. #E8E8E8 zu ändern. Gleichzeitig wird in der Monobook.css für nicht-ANR-Seiten wieder #FFF definiert. Darauf gekommen bin ich wegen dieser Anfrage. Was haltet ihr davon? Wird diese Klasse oft verwendet, um irgendwo reines Weiß zu bekommen anstatt etwas abzuheben?
fragt -- ✓ ^Bergi 12:49, 3. Jul. 2010 (CEST)

Mit

{| class="wikitable hintergrundfarbe2"

bekommt man auf allen Skins eine weiße Tabelle. Das ist doch in Ordnung. --Fomafix 23:21, 9. Jan. 2011 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 16:30, 18. Jan. 2012 (CET)

Formatierung der tags abbr, acronym

Diese Änderung hat relativ viel Staub aufgewirbelt, da sie bei allen Höhen zu gepunkteten Unterstreichungen führt, etwa 100 m ü. A. Diskussionen hier, und 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. 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 <abbr> bestehen:

abbr, acronym { border-bottom:none; }

Da diese Änderung die Dinge auch nicht schlimmer machen kann, bin ich mal so mutig. --Herzi Pinki 21:13, 28. Mai 2011 (CEST)

Doch. Kann sie. -- ζ 21:50, 28. Mai 2011 (CEST)

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 --Herzi Pinki 21:55, 28. Mai 2011 (CEST)

Kann es sein, dass Du 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 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. --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 .explain. Der Vorgriff auf den Bug ist dabei nur color:inherit, 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.

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 class="explain" versehen werden, um dem User/der Gemeinschaft die genannten Möglichkeiten zu eröffnen.

--✓ ^Bergi 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.

<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 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 (Test). Das machen die Browser nicht zum Spaß so, sondern damit der Tooltip, der beim <abbr>-Elemente 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 <acronym>-Element, das in MediaWiki noch nie verwendet und mit HTML5 komplett abgeschafft wurde. --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, 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 oder deren bugzilla-nutzenden Teil, was somit wieder Unsinn ist). Auch ich wäre lieber beim Browserstandard geblieben. --✓ ^Bergi 15:53, 9. Jun. 2011 (CEST)

rev:88118 und rev:88498 von Bug 28979 sind live. Diese Änderung kann damit teilweise entfallen. color:inherit ist nun wirkungslos und kann entfernt werden. border-bottom:none überschreibt allerdings das border-bottom: 1px dotted black von skins/common/shared.css, was auch Browser-Standard ist. --Fomafix 13:07, 7. Okt. 2011 (CEST)

Das color:inherit kann auf jeden Fall entfernt werden, da inzwischen wirkungslos. Bitte entfernen. --Fomafix 14:14, 8. Jan. 2012 (CET)

border-bottom:none 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. --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. --32X 14:43, 8. Jan. 2012 (CET)

Ich habe die Vorlage:Höhe von <abbr>-tag entkoppelt. Habe daher kein Problem mit der erfolgten Änderung. lg --Herzi Pinki 16:15, 8. Jan. 2012 (CET)

Ich habe allerdings ein Problem mit der Entkopplung. Bitte entweder border-bottom:none wieder rein, oder mit der angemessenen Unterpunktelung leben (oder CSS-Gadget anbieten), dann würde ich gerne 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. -- ✓ ^Bergi 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. --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? -- ✓ ^Bergi 19:24, 9. Jan. 2012 (CET)

Einen Kompromissvorschlag habe ich aber noch. Beim Drüberfahren kann die Unterpunktelung angezeigt werden:

abbr:not(:hover), acronym:not(:hover) { border-bottom:none; }

Da der Internet Explorer :not() erst ab Version 9.0 unterstützt, müsste eine Formulierung ohne :not() verwendet werden:

abbr, acronym { border-bottom:none; }
abbr:hover, acronym:hover { border-bottom:1px dotted black; }

Vielleicht wäre es für Unterpunktelungsgegner auch akzeptabel, wenn die Unterpunktelung statt schwarz in einem dezentem hellgrau gemacht wird nur beim darüberfahren schwarz hervorgehoben wird:

abbr, acronym { border-bottom:1px dotted #ccc; }
abbr:hover, acronym:hover { border-bottom:1px dotted black; }

Für die Vorlage:Höhe finde ich aber auch Inline-CSS akzeptabel. Mit Inline-CSS sind aber optische Spielereien mit :hover nicht möglich.

Wenn der Code in MediaWiki:Common.css eingefügt wird, sollte er mit einem entsprechenden Kommentar versehen sein. --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 cursor:help (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. -- ✓ ^Bergi 19:24, 9. Jan. 2012 (CET)

cursor:help ist bereits in skins/common/shared.css.

Hier geht es primär um Darstellung von abbr 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 abbr 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 abbr 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. --Fomafix 22:20, 10. Jan. 2012 (CET)

Die derzeitige MediaWiki-Definition gibt mir aber noch etwas zu denken:

/* Default style for semantic tags */
abbr,
acronym,
.explain {
	border-bottom: 1px dotted black;
	cursor: help;
}

Die Rahmenfarbe ist schwarz:

Roter Text mit border-bottom: 1px dotted black.

Besser wäre als Rahmenfarbe die aktuelle Textfarbe:

Roter Text mit border-bottom: 1px dotted.

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

Du meinst border-bottom-color: inherit; für unser CSS? Sieht imho nicht so gut aus, in der üblichen Form innerhalb eines Links. Aber mir egal, hauptsache das abbr-Tag ist wieder ohne großes Geschrei nutzbar. -- ✓ ^Bergi 22:41, 10. Jan. 2012 (CET)

Findest Du „Roter Link“ besser als „Roter Link“? Ich finde die an die Textfarbe angepasste Linie besser und dezenter.

border-bottom-color: inherit; 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:

1. Roter Text mit color:green; border-bottom: 1px dotted.
2. Roter Text mit color:green; border-bottom: 1px dotted; border-bottom-color:inherit.

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 currentColor eine explizite Möglichkeit den Initialwert anzugeben. Hier ist es aber besser, wenn in MediaWiki das black bei border-bottom 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 --Fomafix 17:07, 11. Jan. 2012 (CET)

Zusätzlich habe ich es mit Bug 33703 gemeldet und ist mit rev:108866 umgesetzt worden. Die Änderung wird voraussichtlich mit MediaWiki 1.19 aktiv werden. --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. --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.
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 <abbr>-tag einzubetten. oder?
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 <abbr>-tag 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 kg, in der Folge aber kg. Der Screenreader sollte ja immer Kilogramm vorlesen und niemals kg. Es ist die wohl zentrale Frage, ob wir das <abbr>-tag für Accessibility generell forcieren sollen. CSS Spielereien sind da fast schon nebensächlich. --Herzi Pinki 01:32, 11. Jan. 2012 (CET)

Muss für Screenreader jede Abkürzung mit abbr versehen werden? --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 title 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 none zurückzustellen? -- ✓ ^Bergi 16:14, 11. Jan. 2012 (CET)

Ich würde folgende Definition vorschlagen:

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;
}

Beispiele:

Schwarz auf Weiß: #ccc, rgba(75%, 75%, 75%, .5). Hover: currentColor.

Weiß auf Schwarz: #ccc, rgba(75%, 75%, 75%, .5). Hover: currentColor.

Rot auf Weiß: #ccc, rgba(75%, 75%, 75%, .5). Hover: currentColor.

Rot auf Schwarz: #ccc, rgba(75%, 75%, 75%, .5). Hover: currentColor.

--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. --Fomafix 21:31, 11. Jan. 2012 (CET)

 Pro rgba ist genial :-) Nur grau auf grau funktioniert halt nicht. -- ✓ ^Bergi 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 {{abbr}} (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 <abbr> unverständlich sein könnte, wäre eine {{Abkürzung mit Erläuterung als Tooltip}} 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 [[Meter über Adria|m.ü.A.]], bekommt man sogar einen Tooltip, notfalls nach Einrichtung einer entsprechenden WL-Seite.

VG --PerfektesChaos 10:06, 13. Jan. 2012 (CET)

Hier geht es aber zunächst um die Formatierung von abbr 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. --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 <abbr>-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. --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 '''{{{1}}}''', <b>{{{1}}}</b> oder <strong>{{{1}}}</strong> oder eine Vorlage:Unterstrichen mit <u>{{{1}}}</u> oder <span style="text-decoration:underline">{{{1}}}</span>. Allerdings haben wir eine Vorlage:Overline mit <span style="text-decoration:overline">{{{1}}}</span>. Das ganze Vorlagenthema ist aber hier die falsche Seite. --Fomafix 13:45, 13. Jan. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: -- ✓ ^Bergi 18:58, 23. Jan. 2012 (CET)

Hintergrundfarben bei wikitable mit MediaWiki 1.19

Mit rev:107669 wurde die Spezifität der CSS-Selektoren erhöht. Damit mit den CSS-Klassen hintergrundfarbex die Hintergrundfarben von Tabellenköpfen weiterhin überschrieben werden können, muss hier die Spezifität auch erhöht werden:

Bisher:

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;
}

Neu:

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;
}

--Fomafix (Diskussion) 09:18, 1. Mär. 2012 (CET)

Ist geändert. Der Umherirrende 20:44, 1. Mär. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 20:44, 1. Mär. 2012 (CET)

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:

/* Standardmäßige Ausblendung der Flagged-Revisions-Kommentarbox */
#mw-fr-commentbox {
	display: none;
}

Neu:

/* Standardmäßige Ausblendung der Flagged-Revisions-Kommentarbox */
.fr-comment-box {
	display: none;
}

--Fomafix (Diskussion) 10:03, 1. Mär. 2012 (CET)

Auch wenn ich die Box eigentlich nützlich findet, habe ich die Änderung gemacht, weil man es wohl als De-Facto-Standard ansehen kann (Niemals/Kaum aktiv gewesen, seit dem es die Box gibt). Der Umherirrende 21:13, 1. Mär. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 21:13, 1. Mär. 2012 (CET)

wikitable ohne table-Element

wikitable ist seit langem zentral in skins/common/shared.css definiert. Hier lokal haben wir aber noch folgende Definition:

.wikitable {
	background: #f9f9f9;
	border: 1px solid #aaa;
	border-collapse: collapse;
	margin: 1em 1em 1em 0;
}

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 table.wikitable, während wir lokal den Selektor .wikitable haben. Damit kann die lokale Definition auch bei anderen Elementen als table eingesetzt werden.

Wird irgendwo die CSS-Klasse wikitable bei anderen Elementen außer table eingesetzt? --Fomafix (Diskussion) 10:44, 2. Mär. 2012 (CET)

Ich habe gerade in einem aktuellen Dump die Verwendung von wikitable untersucht. Neben den normalen Verwendungen bei {| wird wikitable bei zweimal bei math, einmal bei div, einmal bei span und ca. 60mal bei gallery. Die Verwendungen bei math, div und span habe ich entfernt. Die Verwendungen bei gallery sollten auch noch entfernt werden.

Die oben aufgeführte lokale Definition von .wikitable kann entfernt werden. --Fomafix (Diskussion) 21:17, 10. Apr. 2012 (CEST)

Mit der Absicherung klingt das sinnvoll. Erledigt. Der Umherirrende 21:28, 10. Apr. 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 21:28, 10. Apr. 2012 (CEST)

Ä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/Beispielfix). Vielen Dank. Der Umherirrende 20:42, 20. Mai 2010 (CEST)

Bei MediaWiki:Monobook.css hat Entlinkt Anpassungen 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 div/span-Element verhindert zumindest, dass Überschriften davon betroffen sind. --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? Der Umherirrende 15:35, 6. Jun. 2010 (CEST)

#gelesen wurde am 19. Dezember 2005 hinzugefügt, am gleichen Tag einmal verwendet und am nächsten Tag wieder entfernt, aber nicht mehr aus MediaWiki:Common.css entfernt. Eine weitere Verwendung konnte ich nicht finden. Die Definition #gelesen sollte daher entfernt werden. --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ß --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 div#editpage-copywarn statt #editpage-copywarn definiert wird. --Fomafix 12:21, 9. Jun. 2010 (CEST)

Ich habe nochmal welche angepasst. Sollte damit erstmal erledigt sein, falls noch welche Fehlen, einfach wieder aufmachen. Der Umherirrende 11:21, 18. Mai 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 11:21, 18. Mai 2012 (CEST)

Ausblendung der Flagged-Revisions-Backlog-Sitenotice

… mittels #mw-oldreviewed-notice { display: none; } 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). --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.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:

Es sind aktuell ungesichtete Bearbeitungen von gesichteten Seiten auf deiner Beobachtungsliste. Deine Aufmerksamkeit ist nötig!

[Verbergen]

Gruß --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. 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. Der Umherirrende 10:54, 18. Mai 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 10:54, 18. Mai 2012 (CEST)

gesichtete Versionen, Teil 2

Hallo! irgenjemand hat in der flaggedrevs.css ein

li.fr-hist-stable-margin { 
margin-top: 2em;
}

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.
meint -- ✓ ^Bergi 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? --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. Der Umherirrende 11:08, 18. Mai 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 11:08, 18. Mai 2012 (CEST)

div.flaggedrevs_short-Widget

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

1. Es nutzt float:right, aber viele Artikel enthalten als allererstes Tabellen, die ebenfalls float:right, aber nicht clear:right 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.
2. Es hat einen ausklappbaren Teil, der aus dem #contentSub-Bereich heraus nach unten absolut positioniert ist, ohne auch nur zu versuchen, sich irgendwie gegen Vorlagen am Artikelanfang, die – warum auch immer – position:relative nutzen, zu schützen. (Diesen Bug habe ich gerade mit Müh und Not so umgangen, dass es in allen Browsern einschließlich der fehlerhaften funktionieren sollte).
3. 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 position:relative 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. --Entlinkt 06:40, 24. Jun. 2010 (CEST)

Heißt jetzt flaggedrevs_short und dürfte in der Zwischenzeit (fast 2 Jahre) ordentlich aussehen. Der Umherirrende 11:07, 18. Mai 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 11:07, 18. Mai 2012 (CEST)

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 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. weltforce™ | _{☣ Disc.} 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. 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. weltforce™ | _{☣ Disc.} 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? collapseButton 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. Der Umherirrende 21:31, 7. Mai 2012 (CEST)

Die Vorlage soll für Navigationsleisten zu Wahlen verwendet werden. Bisher sieht es hier so aus:

Wahlen und Volksabstimmungen in Tansania

Tanganjika	Präsidentschaftswahlen 1962 Parlamentswahlen 1958/1959 • 1960
Tansania	Präsidentschaftswahlen 1965 • 1970 • 1975 • 1980 • 1985 • 1990 • 2000 • 2005 • 2010 • 2015 • 2020 Parlamentswahlen 1965 • 1970 • 1975 • 1980 • 1985 • 1990 • 1995 • 2000 • 2005 • 2010 • 2015 • 2020       Volksabstimmungen 2010

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 --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. weltforce™ | _{☣ Disc.} 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. 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, Themenringe zu erstellen, beispielsweise „Tom Clancy’s Splinter Cell“. Mit den vorhandenen Navigationsleisten kommen wir gut hin. --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:

{{Navigationsbox
|Name       = 
|Titel      = 
|Bild      = 
|Untertitel      = 
|Klasse  = hlist

|Gruppe1     = 
|Liste1      = 

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

|Anmerkung      =
}}

– gez. weltforce™ | _{☣ Disc.} 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. weltforce™ 17:03, 10. Mai 2012 (CEST)

Unabhängig davon solltest du aber schauen, das .collapseButton 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 .mw-collapsible-toggle zentral ändern sollte, ist auch so die Frage. 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. weltforce™ 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. Der Umherirrende 20:28, 18. Mai 2012 (CEST)

---

So, die Vorlage ist nun meinerseits endgültig abgeschlossen. Die Vorlage wurde komplett ins Deutsche genommen:

{{Navigationsbox
|Name       = 
|Titel      = 
|Bild      = 
|Untertitel      = 

|Gruppe1     = 
|Inhalt1      = 

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

|Weiteres      =
}}

Wer es testen möchte: den folgenden Code in die eigene common.css kopieren und dann diese Seite anschauen.

/* 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 */

Ich habe den Code ein wenig optimiert. – mfg. weltforce™ 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. weltforce™ 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. -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. --weltforce™ 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 style-Element mit dem Attribut scoped 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. --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.... --weltforce™ 21:03, 22. Mai 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: weltforce (Diskussion) 13:50, 18. Jun. 2012 (CEST)

Hauptseite

#hauptseite table {
	background: transparent;
}

kann entfallen, denn seit Bug 26708/rev:80495 haben Tabellen eine transparente Hintergrundfarbe. --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? --weltforce (Diskussion) 01:41, 27. Jun. 2012 (CEST)

Siehe bugzilla:26708#c4. --Fomafix (Diskussion) 08:30, 27. Jun. 2012 (CEST)

Ist nachvollziehbar, obwohl ich nur die "Hauptskins" getestet habe, denke aber mal, das passt. Ist angepasst. Der Umherirrende 20:24, 28. Jun. 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 20:24, 28. Jun. 2012 (CEST)

id "artikelstadium"

Die id "artikelstadium" wird in 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. 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? → «« Man77 »» 23:45, 22. Nov. 2009 (CET)

Das konnte ich beheben, jetzt verdeckt das Kandidatur-Icon das Exzellent. Der Umherirrende 20:33, 23. Nov. 2009 (CET)

Wozu soll dass none gut sein? Es erzeugt ein zusätzliches div ohne Funktion. --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). Der Umherirrende 21:37, 24. Nov. 2009 (CET)

Ohne das none ist durch den Zeilenumbruch ein störendes p-Element eingefügt worden. Ich’s entfernt. --Fomafix 22:23, 24. Nov. 2009 (CET)

id="artikelstadium" hat als id und nicht als class 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 display:none; ausgeblendet sein und in den Skins mit display:block; position:absolute; right:xem; top:yem; die rechte obere Ecke festgelegt werden. Von dort aus können die einzelnen Bildchen mit margin positioniert werden, so dass sie sich nicht überdecken, bzw. bewusst überdecken und mit z-index in der Reihenfolge festgelegt werden. Diese Definitionen können dann entweder in die Vorlagen oder per id in die Skins. Was wäre ein geeigneter Name für eine solche CSS-Klasse? --Fomafix 10:06, 24. Nov. 2009 (CET)

• ObenRechts
• position_absolute
• bapperlecke

en:MediaWiki:Monobook.css bzw. en:MediaWiki:Vector.css verwenden dazu div.topicon. --Fomafix 14:17, 23. Apr. 2010 (CEST)

Bestandsaufnahme zum Thema „absolut positionierte Elemente“:

• Es gab eine Diskussion auf FzW, die als „eingeschlafen“ archiviert wurde.
• Es gibt zurzeit 6 einschlägige IDs (#artikelstadium, #coordinates, #coordinates_3_ObenRechts, #editcount, #issnlink, #shortcut) und eine 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 Baustelle, Exzellent, Exzellentes Bild, Gesprochene Version, Informativ, Kandidat, Lesenswert, Listenreview, 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. topicon, 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ß --Entlinkt 20:40, 19. Mai 2010 (CEST)

Ja, ich habe :en gemeint. Dort wird display:block mit !important verstärkt, weil das display:none nicht in Common.css sondern im style="…" steht. Das hat den Vorteil, dass bei der 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? --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 entfernt, weil es bei uns, obwohl die Möglichkeit 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 !important 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ß --Entlinkt 21:55, 19. Mai 2010 (CEST)

Ich kenne keine Browser-Probleme mit !important. !important kann mit !important überschrieben werden. --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, 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. --Entlinkt 06:28, 20. Mai 2010 (CEST)

Keine Resonanz zu !important? 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: .topicon). Die beiden „Ausreißer“ bekommen zusätzlich IDs (Namensvorschläge: #spoken-icon und #commons-icon zwecks Konsistenz mit der englischen Wikipedia). In den einzelnen Skins wird div.topicon so definiert, wie bisher #artikelstadium definiert war. Auch in den einzelnen Skins werden die „Ausreißer“ davon abgeleitet, indem nur die einschlägigen Deklarationen (margin-right: oder margin-top:, 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: .artikelstadium 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: div.artikelstadium, #spoken-icon, #commons-icon { /* Grundposition */ }, darunter #spoken-icon, #commons-icon { /* abweichende Position */ }. Meinungen dazu? --Entlinkt 19:56, 23. Mai 2010 (CEST)

Mangels anderslautendem Feedback setze ich jetzt folgendes um:

• Ich definiere eine neue Klasse div.topicon, hier in Common.css mit dem Inhalt display:none und in den drei Skins, in denen bisher die ID #artikelstadium definiert war, nämlich Monobook, Klassik und Modern, mit demselben Inhalt wie #artikelstadium. 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 top:23px aus Vorlage:Gesprochene Version und right:30px 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 #spoken-icon und #commons-icon, 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, #spoken-icon und #commons-icon 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 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 #artikelstadium sowohl in den CSS-Dateien als auch in den Vorlagen noch 31 Tage stehen bleiben.

--Entlinkt 02:48, 25. Mai 2010 (CEST)

Wird #artikelstadium 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? --Fomafix (Diskussion) 12:32, 18. Mai 2012 (CEST)

Wurde heute aus den einzelnen Skins entfernt: Modern, Monobook und Standard. 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? --Entlinkt (Diskussion) 16:13, 12. Jan. 2013 (CET)

Ich habe es entfert: Common.css und 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. Der Umherirrende 21:36, 15. Jan. 2013 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 21:36, 15. Jan. 2013 (CET)

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.

<div class="hlist">
* Test1
* Test2
* Test3
</div>

würde hlist dann als
Test1 · Test2 · Test3
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 Erweiterte Navigationsleiste hier technisch gesehen eine Tabelle ist, findet sie dort auch großen Nutzen. Man müsste dann z.B. nicht mehr

[[Color TV-Game 6]] • [[Coleco Telstar]] • [[Magnavox Odyssey]] • [[Pong]]

schreiben, sondern könne einfach

* [[Color TV-Game 6]]
* [[Coleco Telstar]]
* [[Magnavox Odyssey]]
* [[Pong]]

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

[[Hochmut]] |
[[Geiz]] |
[[Neid]] |
[[Zorn]] |
[[Wollust]] |
[[Völlerei]] |

schreiben, sondern könne das einfach über

* [[Hochmut]]
* [[Geiz]]
* [[Neid]]
* [[Zorn]]
* [[Wollust]]
* [[Völlerei]]

machen. Ist das nicht komfortabler?

Grüße, 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 <ul style="display:inline;"><li style="blahblahblah">...</li><li style="blahblahblah">...</li><li style="blahblahblah">...</li></ul> usw ergeben. Deshalb die Bitte, das per CSS-Datei zu lösen. Ich bitte um zügige Bearbeitung. --weltforce (Diskussion) 19:06, 17. Jun. 2012 (CEST)

Diese Ergänzungen sind nicht nötig, da sie keine wirkliche Verbesserung der Darstellung bringen. 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. --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. --weltforce (Diskussion) 17:27, 18. Jun. 2012 (CEST)

Wenn du dich hier beteiligen willst, solltest du vor Ä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. 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 --Tommes ^{(Roter Frosch)} 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:

1. Ich finde es problematisch, wenn die gewohnte Darstellung einer Liste in einem bestimmten Kontext völlig anders aussieht.
2. Die intuitive Wikisyntax zur Erzeugung von
   Color TV-Game 6 • Coleco Telstar • Magnavox Odyssey • Pong
   ist
   [[Color TV-Game 6]] • [[Coleco Telstar]] • [[Magnavox Odyssey]] • [[Pong]]
3. Eine Aufzählungsliste ist hier zwar semantisch interessant, aber ich finde sie unflexibel und nicht notwendig, da ich keinen Nutzen sehe.
4. Nicht alle Browser kommen mit diesen CSS-Definitionen zurecht.
5. Die CSS-Klasse scheint nicht für Artikeltext gedacht zu ein, sondern für nur Vorlagen.
6. Die prinzipielle Funktion dieser CSS-Definitionen könnte auch mit einer Vorlage erzeugt werden:

Statt

<div class="hlist">
* Erstens
* Zweitens
</div>

folgendes:

{{hlist
| Erstens
| Zweitens
}}

--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. --weltforce (Diskussion) 16:08, 19. Jun. 2012 (CEST)

content erfordert IE8: https://developer.mozilla.org/En/CSS/content --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. Der Umherirrende 19:50, 8. Mär. 2013 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 19:50, 8. Mär. 2013 (CET)

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

--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. -- 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: ɐɑɒɓɔɕɖɗɘəɚɛɜɝɞɟɠɡɢɣɤɥɦɧɨɩɪɫɬɭɮɯɰɱɲɳɴɵɶɷɸɹɺɻɼɽɾɿʀʁʂʃʄʅʆʇʈʉʊʋʌʍʎʏʐʑʒʓʔʕʖʗʘʙʚʛʜʝʞʟʠʡʢʣʤʥʦʧʨʩʪʫʬʭʮʯ

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. 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: . --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 ? 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) 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. Gismatis 16:58, 21. Mai 2009 (CEST)

Es sind aber tatsächlich auch zwei IPA-Zeichen betroffen: ɑɡ. Zwar gibt es keine Punktwolken wie bspw. beim ü, aber trotzdem werden sie nicht korrekt dargestellt. -- Prince Kassad 17:21, 21. Mai 2009 (CEST)

Bei mir werden diese Zeichen richtig dargestellt. Hast du vielleicht eine ältere Version? 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. 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. -- 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. 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? --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. 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. 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? --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. 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") --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 ? 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:

́ (Akut) oder ​˦​	U+0301 oder U+02E6	hoch	​[⁠é⁠]​
̄ (Makron) oder ​˧​	U+0304 oder U+02E7	mittel	​[⁠ē⁠]​
̀ (Gravis) oder ​˨​	U+0300 oder U+02E8	niedrig	​[⁠è⁠]​
̌ (Hatschek)	U+030C	steigend	​[⁠ě⁠]​
̂ (Zirkumflex)	U+0302	fallend	​[⁠ê⁠]​

--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. -- 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". 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. --Pjacobi 01:08, 22. Mai 2009 (CEST)

Also ich sehe da keine großen Unterschiede. Ich generiere mal ein Vergleichsbild. Cäsium137 (D.) 01:31, 22. Mai 2009 (CEST)

Sun-ExtA und IPA (2)

Hier der Vergleich (groß, damit man was sieht):

Was ist da schlimm ? 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. --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 Cäsium137 (D.) 01:47, 22. Mai 2009 (CEST)

P.S. Die SIL-Schriften sind nicht frei. Die würde ich nicht favorisieren. Cäsium137 (D.) 01:57, 22. Mai 2009 (CEST)

SIL Open Font License (OFL). --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. Cäsium137 (D.) 16:08, 22. Mai 2009 (CEST)

Zum Thema: Wer kennt noch andere Zeichen, bei denen das auftritt ? 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.

--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.Cäsium137 (D.) 18:07, 22. Mai 2009 (CEST)

Vorher evtl. Nachschauen, ob es keine neue Version mit Bugfix gibt. Cäsium137 (D.) 18:50, 22. Mai 2009 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Entlinkt (Diskussion) 11:43, 11. Mai 2013 (CEST)

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 {{Arabische Schrift}} wird verwendet, z.B. per {{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:

Screenshot

Darstellung ohne Vorlage	‏سنڌي‎
Darstellung mit Vorlage	سنڌي
Darstellung im Editierfenster	‏سنڌي‎
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, → «« Man77 »» 18:09, 28. Sep. 2009 (CEST)

Bei mir ist die Darstellung stets gleich, das heißt unverbunden, ob angemeldet oder nicht. Das Zeichen ڌ 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 .spanAr {font-family: "Name der Schriftart" !important;} in deinen persönlichen CSS-Einstellungen die Verwendung dieser Schriftart erzwingen. 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.
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.
Vielleicht sollten wir hier von unserer neuen Möglichkeit gebrauch machen, Schriftarten in Webseiten einzubinden. -- 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 noch nicht alles berücksichtigt. → «« 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.
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. -- Prince Kassad 18:06, 29. Sep. 2009 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Entlinkt (Diskussion) 11:43, 11. Mai 2013 (CEST)

Mein Glück

soll ich hier 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ß, Hæggis 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 deine persönliche CSS-Datei schreiben:

body.ns-4 span.tocnumber { display: none; }

Die CSS-Klasse ns-4 steht hier für den Wikipedia-Namensraum. Viele Grüße --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 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. -- Hæggis 17:29, 19. Apr. 2010 (CEST)

Um das zu erzielen, könnte man auf der Vorderseite folgenden Code einsetzen:

.page-Wikipedia_Diskussion_Hauptseite_Artikel_des_Tages .tocnumber { display: none; }

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. --Wiegels „…“ 17:47, 19. Apr. 2010 (CEST)

Bevor die Server explodieren, weil ich irgendwas falsch eingesetzt hab – könntest du das Hexenwerk büdde vorerst auf Benutzer:Cum Deo/AdT/Designentwürfe lenken, damit ich daran experimentieren kann? Gruß, Hæggis 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 deine persönliche CSS-Datei, in der ich nicht schreiben darf, folgendes ein und besuchst anschießend die Testseite. Mit dem hierüber genannten Code kannst du aber auch die originale Artikel-des-Tages-Diskussion testen.

.page-Benutzer_Cum_Deo_AdT_Designentwürfe .tocnumber { display: none; }

--Wiegels „…“ 18:54, 19. Apr. 2010 (CEST)

Et funktioniert! Dankesehr, sieht einfach klasse aus, danke.

Kann bitte jemand… ach, ich frag direkt. -- Hæggis 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. Der Umherirrende 19:53, 8. Mär. 2013 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Entlinkt (Diskussion) 11:43, 11. Mai 2013 (CEST)

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

 #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;
}

bei Modern und Vector nicht funktioniert. Was tun? --Entlinkt 22:35, 23. Apr. 2010 (CEST)

Bin ich blind, oder funktioniert es doch? (http://de.wikipedia.org hat unter Vector keinen Pfeil) --Euku:^⇄ 23:44, 23. Apr. 2010 (CEST)

Attributselektoren nach CSS3 können nicht alle Browser. --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 (Beispiel). Und zwar in demselben Browser, in dem es bei Monobook und Vector funktioniert (Firefox 3.6.3). Gruß --Entlinkt 23:55, 23. Apr. 2010 (CEST)

Bei Modern heißt es nicht #content, sondern #mw_content. --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 (Beispiel). Gruß --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. Merlissimo 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? Merlissimo 05:34, 9. Jun. 2010 (CEST)

Die ordentliche Lösung steht in 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). --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. Merlissimo 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 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. --Entlinkt 05:19, 7. Jul. 2010 (CEST)

Seit rev:111647 gibt es die skinunabhängige ID #mw-content-text. 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. --Entlinkt (Diskussion) 19:17, 25. Mai 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Entlinkt (Diskussion) 19:17, 25. Mai 2013 (CEST)

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

wo sich das (i) wegen inline nicht mehr auf dem Bild befindet. Würde die Einführung einer neuen Klasse gerne vermeiden. Merlissimo 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 .imagemap-inline div 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:

.imagemap-inline div {
	display: block; /* jetzige Definition aufheben */
}
.imagemap-inline > div {
	display: inline-block; /* bessere Definition */
}

Nebenwirkungen:

• Ältere Browser (IE 6/7, Firefox 2) unterstützen inline-block nicht, es kann aber u. U. durch Ausnutzung proprietärer Eigenschaften (hasLayout für IE und irgendwas mit -moz- für Firefox) emuliert werden;
• Die Selektion mit .imagemap-inline > div 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ß --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. Merlissimo 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? Merlissimo 23:02, 21. Jul. 2010 (CEST)

Im ursprünglichen CSS 2 von 1998 gibt es kein display: inline-block und auch kein Äquivalent dazu, das ist eine Neuerung von CSS 2.1.

Die jetzige Definition ist m. E. ziemlich nutzlos, weil sie nur in Verbindung mit desc none 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 desc none funktioniert) und man dann aber auch einfach Bildlinksyntax wie in [[Datei:...|link=...]] verwenden kann.

Im IE 6/7 kann man display: inline-block emulieren, indem man display: inline verwendet und dem Element zugleich Layout gibt, was wegen der vorhandenen Breiten- und Höhenangaben eh schon der Fall ist. In alten Firefox-Versionen verhält sich display: -moz-inline-box ähnlich wie display: inline-block.

Das Hauptproblem ist aber die Selektion: Wie erwischt man das äußere div und lässt das innere in Ruhe. .imagemap-inline > div wäre eine meistens (fast immer) passende Annäherung, aber im IE 6 geht selbst das nicht, weil er den E > F-Combinator nicht versteht. Das wäre nur zu umgehen, indem das äußere div softwareseitig mit einer Klasse versehen wird. --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:

/* 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;
}

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 -moz-Eigenschaften zurückgreifen;
• inline als Fallback, damit wenigstens der Fall desc none weiterhin funktioniert (wobei die Kombination desc none 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ß --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. Merlissimo 02:11, 22. Jul. 2010 (CEST)

Statt -moz-inline-block sollte es -moz-inline-box oder -moz-inline-stack 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. E. durchaus möglich, indem man ganz am Anfang entweder

.imagemap-inline > div {
	display: inline;
}

oder (umständlicher)

.imagemap-inline div {
	display: inline;
}
.imagemap-inline div div {
	display: block;
}

ergänzt. Eine Klasse für den Container habe ich mit Bug 24483 bereits angefragt, erscheint mir so oder so sinnvoll.

Gruß --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.

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. Merlissimo 02:45, 22. Jul. 2010 (CEST)

Sorry, mit Dokumentation zu -moz-* kann ich nicht wirklich dienen. 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ß --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. --Entlinkt 03:45, 22. Jul. 2010 (CEST)

Wird die Klasse imagemap-inline überhaupt noch benötigt? Die Hauptmotivation für den 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 [[Datei:...|link=]]. Laut Suchfunktion wird die Klasse im Wesentlichen noch in der veralteten Vorlage:Imagemap und in substituierten Bausteinen auf Benutzerseiten verwendet. --Entlinkt (Diskussion) 04:52, 18. Mai 2013 (CEST)

Ich habe die Klasse jetzt entfernt, siehe auch hier. --Entlinkt (Diskussion) 05:06, 23. Sep. 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Entlinkt (Diskussion) 05:06, 23. Sep. 2013 (CEST)

Fußnoten-Darstellung

Hi, ich beziehe mich nochmal auf 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 vertical-align:super 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

.reference, .references sup 
{ 
font-size: 91%;
vertical-align: text-top;
position: relative;
top: -0.3em;
white-space: nowrap;
}

nutzen die

sup.reference 
{
font-weight: 400;
font-style: normal;
}

sup, sub 
{ 
line-height: 1em;
}

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. --APPER\^☺☹ 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 Echo der Stille 11:33, 4. Jan. 2010 (CET)

Ja, vertical-align: text-top; macht Probleme. sup, sub { line-height: 1em; } ist gut. font-weight: 400; verstehe ich nicht. Unter en:MediaWiki:Common.css steht sup.reference { font-weight: normal; font-style: normal; }. --Fomafix 16:36, 4. Jan. 2010 (CET)

font-weigth:400 entspricht etwas dünner als normal: [9]. --Revo Echo der Stille 19:46, 4. Jan. 2010 (CET)

Ah, danke. font-weight: 400; entspricht exakt font-weight: normal; nach CSS 2.1 und CSS3. font-weight: normal; finde ich aber leserlicher. --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. --APPER\^☺☹ 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? — ^PDD — 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? --APPER\^☺☹ 02:11, 6. Jan. 2010 (CET)

Nö. Andere Version? Bei mir Chrome 4.0.266.0. — ^PDD — 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. |Memex 16:39, 29. Mär. 2010 (CEST)

Richtig, bei dem derzeitigen sub, sup { line-height: 1em; } werden bei meinem Firefox auch die Zeilenabstände auch um etwa 1 bis 2 Pixel vergrößert. sub, sup { line-height: 0; } vermeidet das Problem bei den Fußnoten im Fließtext, hat erzeugt aber ein Problem mit dem Zeilenabstand, wenn eine ganze Zeile in sup geschrieben ist:
Erste Zeile
^{sup mit line-height:1}
Zweite Zeile
^{sup mit line-height:0}
Dritte Zeile
--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? |Memex 18:09, 29. Mär. 2010 (CEST)

line-height:0 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).

line-height:1 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 <sub>/<sup>-Positionierung und verlässt sich auf Angaben in den Fonts, die teilweise falsch sind. Dies wird in Bug 55555 thematisiert.

Außerdem gibt es noch Bug 49965 bezüglich line-height:0, was hier wirksam würde, wenn es global gemacht wird; als lokale Anpassung würde ich das nicht machen, weil es zu problematisch ist. --Entlinkt (Diskussion) 01:09, 19. Okt. 2013 (CEST)

Ich halte dieses Thema mit Bug 49965 bzw. gerrit:121953 für erledigt (bis auf den Modern-Skin, d. 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. --Entlinkt (Diskussion) 03:52, 30. Mär. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Entlinkt (Diskussion) 03:52, 30. Mär. 2014 (CEST)