MediaWiki Diskussion:Vector.css/Archiv

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:Vector.css/Archiv#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

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

pre: larger

Hi, aber die bisherige Lösung regt mich auf. Kann bei solch einem Fix nicht vorher auch mal ein Blick auf die anderen Browser geworfen werden? Wegen eines Firefox-Bugs wird die Schriftgröße für alle anderen Browser unerträglich groß gemacht?

Ich habe jetzt einen Fix durchgeführt, der hoffentlich für alle Browser funktioniert (da er eigentlich nichts ändert). Der Firefox-Bug sollte damit umgangen sein und alles korrekt groß dargestellt sein. --APPER\^☺☹ 15:07, 5. Apr. 2010 (CEST)

Sorry Apper für die Aufregung, meine Schuld. Es war mir nicht bewusst, dass nur der FF betroffen ist, da der falsche Fix bereits seit Oktober 2009 auf Commons live ist, anscheinend ohne Beschwerden. Danke für deine Korrektur. — Raymond ^Disk. 18:06, 5. Apr. 2010 (CEST)

Hm, okay, wenn das schon so lange auf Commons aktiv ist (hatte nicht geguckt, wie lange), dann ist es ja eigentlich auch okay, das nicht weiter zu testen. Zeigt, wie wenig anscheinend der Vector-Skin dort getestet wird... --APPER\^☺☹ 23:26, 5. Apr. 2010 (CEST)

Wurde Softwareseitig gelöst und die Umgehungslösung wieder entfernt. Der Umherirrende 16:14, 14. Mai 2010 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 16:14, 14. Mai 2010 (CEST)

Editcounter

Hallo, auch aus der MB.css für hier, funzt in meiner vector.css einwandfrei:

/* Formatierung für [[Wikipedia:Editcount]]-Vorlagen und [[Vorlage:ISSN-Link]] (Schriftgröße 85%) */
#editcount,
#issnlink {
     display: inline;
     position:absolute; z-index:1; border:none; background:none; right:12px; top:0.3em; float:right; margin:0.0em;
     padding:0.0em; line-height:1.5em; text-align:right; text-indent:0; font-size:85%; text-transform:none; white-space:normal;
}

--FGodard|✉|± 19:54, 27. Mai 2010 (CEST)

In Monobook überschneidet sich der Editcounter mit den Koordinaten. Ursprünglich wurde die Positionierung der Koordinaten 1:1 für den Editcounter kopiert. Später wurde die Positionierung der Koordinaten minimal geändert, überschneiden tun sie sich aber trotzdem noch. Vollständige Liste der aktuell 6 Seiten, auf denen die Überschneidung zu sehen ist: 1, 2, 3, 4, 5, 6.

Meiner Meinung nach sollten wir für einen Editcounter auf sage und schreibe 6 Benutzerseiten keine Kompromisse eingehen, die die gesamte Wikipedia betreffen, sondern das Ding wieder an dieselbe Stelle wie die Koordinaten setzen. Und wir sollten #coordinates und #editcount diesmal auch gleich in einer Zeile schreiben, damit sie dauerhaft an derselben Stelle bleiben. Über die Koordinaten wird im Abschnitt #geo diskutiert. Gruß --Entlinkt 22:06, 27. Mai 2010 (CEST)

Ich habe den Editcounter und alle anderen Textelemente an die Stelle der Koordinaten gesetzt – die noch immer problematisch ist, aber dass sie alle an dieselbe Stelle gehören, halte ich für klar, und so fallen die Probleme dann vielleicht auch eher auf. --Entlinkt 21:49, 1. Jun. 2010 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Entlinkt 21:49, 1. Jun. 2010 (CEST)

Schriftgröße von vector.js, vector.css / Programmcode

Hallo, seit Einführung von vector ist bei mir die Schriftgröße beim Betrachten von Seiten wie meiner vector.js (oder monobook.js) und Seiten mit Programmiercode

 also sowas

sehr klein. Könnte man das standardmäßig wieder hochstellen? Grüße von Jón + 14:00, 13. Jun. 2010 (CEST)

Das ist in der Tat winzig (Firebug berechnet 10.4px für code und 13.6px für den umgebenden Text - unschön). Mal analysieren, wo da gedreht werden muss, ohne Seiteneffekte zu erzeugen. --Guandalug 14:06, 13. Jun. 2010 (CEST)

Oha. Ich habs in meinem Firefox behoben (lokal) - der Internet-Explorer hatte den "Fehler" gar nicht. Unter Extras/Einstellungen/Inhalt/Schriftart/Erweitert war für die Festbreitenschriftart eine deutlich kleinere Schriftgröße als Standard ausgewählt als für die sonstigen Texte. Dann wundert's nicht, dass die Seite seltsam aussah. Das sollte die Wikipedia aber nicht künstlich übersteuern..... --Guandalug 14:28, 13. Jun. 2010 (CEST)

Firefox und, soweit ich weiß, auch Google Chrome haben für Serifen und Serifenlose standardmäßig 16px eingestellt, für Dicktengleiche nur 13px. Sollte jeder selbst einstellen. Ich persönlich habe an den Schriftgrößen in meinen Browsern nie gedreht und mich an die kleine Monospace-Schrift gewöhnt und fände es gar nicht witzig, wenn hier dran gedreht wird. Gruß --Entlinkt 15:02, 13. Jun. 2010 (CEST)

So meinte ich das, Entlinkt. Reparatur: Firefox - Einstellungen. Sonst würden wir andere Browser bevormunden für etwas, wozu die WP gar nix kann. --Guandalug 15:13, 13. Jun. 2010 (CEST)

Sehr schön ;-) http://bits.wikimedia.org/skins-1.5/vector/main-ltr.css enthält übrigens bereits den Workaround pre, code, tt { font-family: monospace, sans-serif; }, der bewirkt, dass unter Ausnutzung eines ganz anderen Bugs in diesen Browsern in pre-, code- und tt-Elementen die für serifenlose Schriften eingestellte Größe benutzt wird, obwohl sie in einer Monospace-Schrift dargestellt werden. Für source-„Elemente“ wirkt er aber nicht, weil für sie (die in HTML auch nur pre-Elemente sind) an anderer Stelle wieder font-family: monospace; gesetzt wird (also das künstliche und die Einstellungen durcheinanderbringende font-family: sans-serif; wieder entfernt wird). Eher sollte auch dieser Workaround entfernt werden, weil er auf sehr subtile und kaum durchschaubare Weise in die Benutzereinstellungen eingreift. Das kann aber nicht hier lokal erfolgen. Gruß --Entlinkt 15:40, 13. Jun. 2010 (CEST)

Auch hierzu meine Zustimmung. Kannst du das weiterleiten? (Nicht, dass ich da große Hoffnung habe, aber...) --Guandalug 16:15, 13. Jun. 2010 (CEST)

Ich bin noch am Überlegen. (Der Workaround wurde auf Betreiben von hier global installiert). --Entlinkt 16:19, 13. Jun. 2010 (CEST)

Oh. --Guandalug 16:21, 13. Jun. 2010 (CEST)

Ich bin gerade ziemlich baff, was für Browserbugs es gibt und wie sie ausgenutzt werden, um die Defaulteinstellungen der Browser (die man fragwürdig finden kann, aber IMHO besser direkt im Browser ändert) zu umgehen. Zum Testen:

* Dieser Satz steht in einer Monospace-Schrift und die Schriftgröße richtet sich nach der im Browser eingestellten Größe für Monospace-Schriften. So verhalten sich zum Beispiel <syntaxhighlight>-Abschnitte.

* Dieser Satz steht in einer Monospace-Schrift, aber die Schriftgröße richtet sich in Firefox und Google Chrome nach der für serifenlose Schriften eingestellten Größe. So verhalten sich zum Beispiel <pre>-, <code>- und <tt>-Abschnitte, die nicht weiter gestylt sind.

Was es alles gibt. --Entlinkt 17:23, 13. Jun. 2010 (CEST)

Diesen Bug auszunutzen halte ich für extrem fragwürdig.... --Guandalug 17:26, 13. Jun. 2010 (CEST)

Von der Technik habe ich ja keine Ahnung, aber wenn ich in meinen Browser-Einstellungen spielen muss, damit es wieder so wie vorhin unter Monobook ist, läuft doch was falsch. Außerdem ist auch seltsamerweise auch so, dass wenn ich wie oben angegeben die Schriftgröße in den Firefox-Einstellungen vergrößere, auch die Schrift im Bearbeiten-Modus viel größer wird. Offenbar hängen diese Schrifteinstellungen also zusammen, weshalb ich das auch gleich wieder zurückgesetzt habe. Könnte man das also bitte hier wieder auf den ursprünglichen Zustand stellen? Grüße von Jón + 17:32, 13. Jun. 2010 (CEST)

Im Gegenteil, man sollte es im Monobook auch "reparieren"..... damit die FF-Defaults das sind, was sie sein sollen: Die Schriftgrößenvorgaben. Was können wir dafür, dass der FF da so dusselig voreingestellt ist? --Guandalug 17:43, 13. Jun. 2010 (CEST)

Das ist aber extrem leserunfreundlich. Kann man die beiden Sachen nicht entkoppeln und die source-Umgebung größer machen? Grüße von Jón + 18:42, 13. Jun. 2010 (CEST)

Eben nicht. Wer die klein macht ist ja grade der Firefox - Opera und Internet Explorer tun's nicht. Das ist (IMHO) ein fehler in den Firefox - Defaults. --Guandalug 18:44, 13. Jun. 2010 (CEST)

Gut, mag ja sein. Aber im Monobook hat alles wunderbar funktioniert, trotz Firefox-Bug. Kann man das nicht wieder so einstellen? Gibt es ansonsten noch eine sinnvolle Möglichkeit? Grüße von Jón + 18:50, 13. Jun. 2010 (CEST)

Eben. Im Monobook hat man genau diesen Bug ausgenutzt. Blöd wird's dann, wenn Firefox den Bug repariert. Ich persönlich halte das für extrem unsauber gelöst im Monobook. --Guandalug 18:54, 13. Jun. 2010 (CEST)

@Jón (und andere), die Denkweisen „wieder so wie vorhin unter Monobook“ und „im Monobook hat alles wunderbar funktioniert“ sind völlig verkehrt, denn Vector ist nicht Monobook 2.0, sondern ein neuer Skin, mit dem das Ziel verfolgt wird, Wikipedia barriereärmer zu machen. Monobook machte (das braucht man gar nicht beschönigen) völlig absurde Sachen mit den Schriftgrößen, angefangen damit, dass es die Basisgröße auf das Mininum verkleinerte und anschließend um 127% vergrößerte (Abschnitte mit den Kommentaren „We take advantage …“ und „Scale back up …“ in http://bits.wikimedia.org/skins-1.5/monobook/main.css), womit die Browsereinstellungen zielsicher außer Gefecht gesetzt werden, woran sich bloß alle irgendwie gewöhnt haben. Zu einem barrierearmen Design gehört aber, dass Browsereinstellungen befolgt werden (und allenfalls herauf- oder herunterskaliert werden, aber so, dass eine Änderung der Einstellungen wirksam bleibt), und genau deswegen macht Vector das und verschiedene andere Dinge nicht mehr. Dass sich eine Änderung der Größeneinstellung nicht nur an einer Stelle, sondern überall auswirkt, ist völlig korrekt und genau Sinn der Sache. Wenn du sie nur gezielt an einer Stelle ändern willst, dann ist eine Änderung der generellen Browsereinstellung natürlich nicht das richtige Mittel, sondern das kann nur in Special:Mypage/vector.css erfolgen. Da müsstest du dir einen geeigneten CSS-Selektor überlegen, der nur die Elemente erwischt, die du auch ändern möchtest. --Entlinkt 20:21, 13. Jun. 2010 (CEST)

Entsetzlich kleine, für mich unlesbare Schrift (Safari 4 auf Mac). Ich schlage allerdings vor, daß vor weiteren Änderungen erst einmal eine verläßliche Datenbasis geschaffen wird mittels Screenshots der verschiedenen Browser/Systeme. Gibts jemanden, der das sammeln und auswerten kann? --slowtiger 10:55, 14. Jun. 2010 (CEST)

Wie auch immer: die Schrift des neuen Designs ist definitiv zu klein. Die Extraportion font-size:80% wie im bodyContent machen die Site nahezu unlesbar. Ich denke mal das kann nicht im Sinne des Erfinder sein. (getestet im Firefox)

--Nuddlegg 11:20, 16. Jun. 2010 (CEST)

Können wir uns hier in diesem Abschnitt bitte auf die Monospace-Problematik beschränken? Die allgemeine Schriftgröße ist ein ganz anderes Problem. Die Dinge sollten nicht vermischt werden, weil sie sonst sehr anstrengend zu diskutieren sind.

Kern des Monospace-Problems ist, dass quasi alle Browser Monospace-Schriften standardmäßig viel kleiner als normalen Text anzeigen, nämlich 16px für normalen Text und 13px für Monospace. In Monobook fiel das nicht so stark auf, weil Monobook alle Schriften erst auf die absolute Mindestgröße verkleinerte und anschließend auf 127% vergrößerte, was zu klein eingestellte Schriften zwar verhindert, aber auch andere Darstellungsfehler auslöst (die man übrigens bemerkt, wenn man mal eine Weile Vector benutzt hat und zurück zu Monobook geht).

Um die standardmäßig zu kleine Browsereinstellung zu umgehen, wurde in Vector ein Hack eingebaut, der die Browsereinstellung für Monospace-Schriften außer Kraft setzt, so dass auch für Monospace-Schriften die Einstellung für normalen Text gelten soll. Allerdings erfasst dieser Hack nicht alles, weil er nur Elemente (keine Klassen, keine IDs, keine Kontexte) selektiert und von spezifischeren Selektoren, die es hier und da gibt, überschrieben wird. Bei <source> tritt genau dieser Effekt auf, weil die SyntaxHighlight-GeSHi-Erweiterung den Hack wieder außer Kraft setzt.

Nun gibt es für Betroffene mehrere Möglichkeiten:

• In Special:Mypage/vector.css folgendes reinschreiben. Dadurch wird der Hack auch für GeSHi aktiviert:

pre.css.source-css, /* MediaWiki:*.css, User:*.css */
pre.javascript.source-javascript, /* MediaWiki:*.js, User:*.js */
div.mw-geshi pre, /* source enclose="pre" */
div.mw-geshi div, /* source enclose="div" */
span.mw-geshi /* source enclose="none" */ {
	font-family: monospace, sans-serif !important;
}

• Im Browser die Schriftgröße für Monospace-Schriften erhöhen. Dadurch werden die Schriften aber nicht nur für GeSHI größer, sondern überall, wo der Hack nicht wirkt.

Gruß --Entlinkt 17:03, 17. Jun. 2010 (CEST)

Danke Entlinkt! Leider wird mit diesem Hack allerdings nur das unter source lang="css" eingeschlossene bei mir vergrößert, bei monobook.js etc. bleibt es weiterhin klein. Grüße von Jón + 19:35, 17. Jun. 2010 (CEST)

Noch zwei Selektoren ergänzt, so besser? (Die Liste kann übrigens noch quasi beliebig länger werden. Ich hoffe, man sieht daran, wie problematisch der Hack ist. Vielleicht wär’s doch einfacher, ihn zu entfernen und die Leute ihre Schriftgrößen im Browser korrigieren zu lassen. Wenn’s dann im Bearbeiten-Fenster zu groß ist, können sie es eben für das Bearbeiten-Fenster wieder kleiner machen.) --Entlinkt 19:54, 17. Jun. 2010 (CEST)

Der Workaround befindet sich nun in MediaWiki:Geshi.css → erledigt. Denen, die ihn in ihre persönliche Special:Mypage/vector.css aufgenommen haben, würde ich empfehlen, ihn von dort zu entfernen. --Entlinkt 16:38, 22. Jun. 2010 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Entlinkt 16:38, 22. Jun. 2010 (CEST)

Bapperl

Die Bapperl für die Artikelauszeichung in der rechten oberen Ecke fehlt auch noch. Hier der Vorschlag von Gnu1742:

#artikelstadium {
     display: block; position:absolute; z-index:1; border:none; background:none; right:12px;
     top:-3.3em; float:right; margin:0.0em;padding:0.0em; line-height:1.5em; text-align:right;
     text-indent:0; font-size:90%; text-transform:none; white-space:normal;}

--Fomafix 11:24, 30. Mär. 2010 (CEST)

Mit diesem Vorschlag landet das Icon mitten in der Sitenotice (die man auch künstlich sichtbar machen kann, etwa mit var wgNotice = "Lorem ipsum"; in Special:Mypage/vector.js). --Entlinkt 18:37, 26. Mai 2010 (CEST)

Für Icons ist die absolute Positionierung mit CSS vom Tisch, Fortsetzung unter MediaWiki Diskussion:Vector.js#Icons oben rechts. --Entlinkt 03:37, 26. Jul. 2010 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Entlinkt 03:37, 26. Jul. 2010 (CEST)

Schriftgröße

Die Schriftgröße für den normalen Text fällt bei mir (FireFox 3.5) immernoch merklich kleiner aus als bei MonoBook.

Bei Opera 10.x passt es und die Schrift ist gleich groß.

-- Biezl ✉ 20:24, 13. Jul. 2010 (CEST)

Wenn das so ist, dann ist in den beiden Browsern nicht dieselbe Schriftgröße eingestellt (Vorteil von Vector gegenüber Monobook und auch diversen anderen Skins: Die Schriften skalieren wieder normal). Wähle in beiden Browsern dieselbe Schriftgröße (Standard sind 16px), und sie werden gleich aussehen. Gruß --Entlinkt 22:02, 13. Jul. 2010 (CEST)

Ich meinte in Vector fällt die Schrift bei FF kleiner aus als bei MonoBook und FF. Beides mal FireFox und trotzem unterschiedliche Schriftgröße sind schon seltsam. -- Biezl ✉ 22:27, 13. Jul. 2010 (CEST)

Welche Schriftgröße ist denn nun eingestellt? Bei 16px sollte das eigentlich nicht der Fall sein. Bei weniger als 16px natürlich schon, weil Monobook die Schrift erst auf x-small verkleinert und dann auf 127% (bezogen auf x-small) vergrößert, was bei einer Schriftgröße < 16px zu einer gedämpften Verkleinerung und bei einer sehr kleinen Einstellung sogar zu einer Vergrößerung führen kann. Im Klartext: Die Schriftgröße in Monobook ist überhaupt nicht von der Normalgröße abgeleitet, sondern es ist das 1,27-fache einer extrem kleinen Schrift. Vector dagegen verkleinert direkt und immer auf das 0,8-fache der Normalgröße. Im Einzelnen hatte ich das hier aufgedröselt. --Entlinkt 23:17, 13. Jul. 2010 (CEST)

Spannend, bei 16px passt es und ist gleich. Allerdings ist meine Schriftgröße 17px und eben bei Vector kleiner. Jetzt habe ich noch weiter verglichen und mir fiel auf, das bei 17px MonoBook auch verglichen mit anderen Webseiten eine größere Schrift aufweist. Dann liegt es wohl an der Interpretation von FF. Trotzdem entgeht mir der Sinn, warum ein textlastiges Medium wie Wikipedia eine Schrift kleiner als Normal hat. -- ein Brilletragender  Biezl ✉ 17:44, 14. Jul. 2010 (CEST)

PS: 18px bringens auch nicht, da rundet FF wohl auf die Pixel ab, sprich Wikipedia ist genauso klein wie mit 17px, google dagegen schön groß. Das ist schon ziemlich dämlich

PPS: Runden ist was schönes:

• 18px x 0,8 = 14,4 ≈ 14
• 17px x 0,8 = 13,6 ≈ 14

PPPS: Bei x-small hast du womöglich einen Fehler drin, denn der Faktor sollte 1/1,44 statt 1/1,6 sein (Quelle), oder ist eventuell gar nicht standardisiert (Quelle).

PPPPS:Habe gerade MonoBook mit FireBug durchexerziert und gerechnet. Für 16px liegt der Faktor von x-small bei 1/1,6 allerdings bei 17px liegt er nur noch bei 1/1,33 hängt also bei FireFox irgendwie von der gewählten Schriftgröße ab!?

Also erstmal zum Grund der Verkleinerung: Aus historischen Gründen haben leider alle Browser für normale Schriften die absurde (viel zu große) Grundeinstellung 16px und für Monospace-Schriften 13px (letzteres wäre in Ordnung, ist aber im Verhältnis zu den normalen Schriften absurd klein). Aus diesem Grunde ist es Usus, dass Webseiten die Schrift verkleinern. Monobook tut das, indem es auf x-small verkleinert und dies auf 127% vergrößert. Vector tut es, indem es die Grundeinstellung (medium) auf 80% verkleinert. Bei Vector ist die Verkleinerung also proportional zu medium, bei Monobook jedoch proportional zu x-small, und x-small ist nicht proportional zu medium, also skaliert Monobook nicht proportional zur Einstellung im Browser.

Daran mag man sich von Monobook her zwar vielleicht gewöhnt haben, aber Vector macht es nun mal anders, und darauf wird man sich wohl einstellen (oder eben einen anderen Skin benutzen) müssen. Es gibt 9 Skins, und jeder einzelne macht das mit den Schriften anders. Gruß´--Entlinkt 00:51, 15. Jul. 2010 (CEST)

PS: Ich finde die Diskussion zwar durchaus interessant, sehe aber nicht, was wir hier tun können. Was wir im Prinzip ändern könnten, sind die Skalierungsfaktoren (wie das geht, steht im Intro der Seite Wikipedia:Usability-Initiative/Feedback), aber nicht die Tatsache, dass bei diesem Skin die Schriften proportional zu medium skalieren. Das zu ändern, würde erfordern, den ganzen Skin umzukrempeln und geht deutlich über die Möglichkeiten lokaler Anpassungen hinaus. Dir würde ich empfehlen, in Special:Mypage/vector.css für #bodyContent die Schriftgröße direkt in px festzulegen. Gruß --Entlinkt 01:07, 15. Jul. 2010 (CEST)

PSS: Zur allgemeinen Nachvollziehbarkeit und auch, weil die Schriftgrößen immer wieder als Argument gegen Vector missbraucht werden, habe ich mal mit Firefox 4.0 Beta 1 die Browsereinstellungen von 9px bis 18px durchgespielt:

medium	x-small	Ergebnis in Monobook (127%*x-small)	Ergebnis in Vector (0.8*medium)
9px	9px	11.43px	7.2px
10px	9px	11.43px	8px
11px	9px	11.43px	8.8px
12px	9px	11.43px	9.6px
13px	10px	12.7px	10.4px
14px	10px	12.7px	11.2px
15px	10px	12.7px	12px
16px	10px	12.7px	12.8px
17px	12.75px	16.1925	13.6px
18px	13.5px	17.145	14.4px

Wie man sieht, hängt x-small zwar von medium ab, aber nicht proportional. Der Effekt ist, dass es in Monobook keinen Unterschied macht, ob man 9px, 10px, 11px oder 12px im Browser eingestellt hat. Man bekommt immer 11.43px; bei 9px, 10px und 11px bekommt man also sogar mehr, als man im Browser eingestellt hat. Hat man 13px, 14px, 15px oder 16px eingestellt, bekommt man 12.7px heraus. Hat man aber 17px eingestellt, gibt es einen absurd großen Sprung auf 16.2px: Man macht im Browser die Schrift 1px größer und bekommt 3.5px mehr.

Bei Vector ist der Zusammenhang dagegen proportional. Macht man im Browser die Schrift kleiner, bekommt man auch etwas kleineres heraus, macht man sie dagegen größer, bekommt man auch eine größere Schrift zurück. Die, die behaupten, mit Vector wären die Schriften kleiner geworden, sind ganz einfach die, die in ihrem Browser eine zu kleine Schrift eingestellt haben und durch Monobook daran gehindert wurden, dass die Einstellung wirken konnte.

Was man nun besser findet, ist wohl Ansichtssache. Ich sehe durchaus, dass Monobook einen gewissen Schutz vor falschen Benutzereinstellungen bietet, aber den Preis, dass die Skalierung dadurch völlig kaputtgeht, fanden die Designer des neuen Skins wohl zu hoch, und das ist dann eben so. Gruß --Entlinkt 01:48, 15. Jul. 2010 (CEST)

Die Skalierung ist völlig kaputt, und das geht klar zu Lasten der Benutzerfreundlichkeit. Es gibt keinen vernünftigen Grund, "falsche Browsereinstellungen" wikipediaseitig zu korrigieren, schon gar nicht mit absurden Ergebnissen wie von Voreinstellung 17px (wie bei mir) auf Wikipedia 13.6px. Das ist klare Kaputtoptimierung und unbrauchbar. In Monobook war das besser, weil wenigstens die kleinste Schrift als Maßstab genommen wurde, eigentlich ist das aber sowieso unnütz. Jeder Nutzer sollte sich seine bevorzugte Schriftgröße selbst per Browsereinstellung anpassen können, relative Schriftgrößen sollten nur für kleiner oder größer darzustellende Inhalte verwendet werden, absolute Schriftgrößen überhaupt nicht. --Prüm 16:53, 15. Jul. 2010 (CEST)

Schrott ist wohl erstmal die Kombination aus FireFox und x-small in MonoBook. Wie es bei anderen Browser ausschaut wurde hier noch gar nicht erörtert. Nicht Standardisiert, sprich Absolut nich vorhersehbar. -- Biezl ✉ 17:00, 15. Jul. 2010 (CEST)

Prüm, wenn du an einer technischen Diskussion interessiert bist, möchte ich dich bitten, den ganzen Abschnitt noch ein-, zwei- oder dreimal zu lesen. Ich habe in der Tabelle die Zeile für 16px farbig hervorgehoben, damit man besser sieht, dass für fast alle Benutzer die Schrift nicht kleiner, sondern größer geworden ist. Wirklich zu verstehen ist das ganze allerdings nicht nur anhand der Tabelle, sondern man müsste auch den Text lesen.

Dass du mit einer Browsereinstellung von 17px in Monobook eine sehr große Schrift bekommst, liegt einfach daran, dass Monobook nicht proportional skaliert, sondern zwischen 16px und 17px einen riesigen Sprung macht. Stellst du auf 16px, die Größe, die fast alle Benutzer eingestellt haben, um, dann wirst du sehen, dass die Schrift in Monobook um 3.5px kleiner wird, obwohl du sie nur 1px kleiner gemacht hast.

Solltest du allerdings nur an Politik gegen den Skin interessiert sein, dann bitte ich dich, dies auf Wikipedia:Meinungsbilder/Standard-Skin Vector oder Monobook zu tun. Dort ist der Platz für Politik, hier ist Platz für Technik. Gruß --Entlinkt 17:05, 15. Jul. 2010 (CEST)

Mir ist klar, dass Dich meine Einwände gegen Schriftenskalierung nicht sonderlich interessieren (soviel zum genauen Lesen). Nimm aber bitte zur Kenntnis, das ich Standardantworten wie "benutz halt einen anderen Browser" oder "stell halt eine andere Standardschriftgröße ein" nicht akzeptiere. --Prüm 17:27, 15. Jul. 2010 (CEST)

Prüm, es tut mir leid, aber man merkt deinen Beiträgen an, dass du nicht weißt, wovon hier die Rede ist. Ich versuch's deshalb noch einmal auf einer einfacheren Ebene: Monobook und Vector haben dasselbe Ziel, die im Browser eingestellte Schriftgröße von 16px auf ungefähr 13px zu verkleinern. Dieses Ziel erreichen beide. Auch in Monobook bekommen diejenigen Benutzer, die 16px eingestellt haben, also fast alle, 12.7px; in Vector bekommen sie 12.8px, also sogar noch ein bisschen mehr. Die Proteste mit dem Inhalt „Schriften viel zu klein“ können definitionsgemäß nur von Benutzern stammen, die etwas anderes als 16px eingestellt haben. Für diese Gruppe – eine Minderheit – ändert sich jetzt natürlich alles, aber nicht zum Schlechteren: Es ist nun möglich, proportional zu skalieren. In Monobook ist das unmöglich. Es gibt keine Browsereinstellung, mit der man in Monobook auf 14px oder 15px kommen kann, weil Monobook von 12.7px direkt auf 16.2px springt. Das tut Vector nicht. An dieser Stelle muss man sich nun ganz einfach entscheiden, ob man das zur Kenntnis nimmt und sogar davon profitiert, indem man in Vector Schriftgrößen einstellen kann, die man in Monobook überhaupt nicht einstellen kann, oder ob man mauert und sagt „ich habe 1px mehr eingestellt und bekam bisher 3.5px mehr und will, dass das so bleibt“. Letzteres ist ziemlich aussichtslos, weil kein Techniker sich davon beeindrucken lassen wird. Gruß --Entlinkt 17:35, 15. Jul. 2010 (CEST)

Alles schön und gut, aber was ist mit denen, die zur Schonung ihrer Augen oder wegen ihrer Bildschirmauflösung mit einer Schriftgröße wie 16 oder 17px arbeiten wollen? Wie ich den Rückmeldungen entnehme, gibt es nicht wenige davon. Die bekommen dann dank Vector mickrige 13 oder 14px. Sollen die dann standardmäßig viel zu große 20 oder 22px einstellen, nur damit sie mit Wikipedia arbeiten können? --Prüm 17:44, 15. Jul. 2010 (CEST)

Ja, natürlich, was auch sonst? Wer bisher 16px eingestellt hatte, bekam auch bisher in Monobook 12.7px heraus, und das mit voller Absicht. Um 16px zu bekommen, musste man auch bisher etwas größeres einstellen. Dass 1px mehr ausreichte, um 3.5px mehr herauszubekommen, war (bzw. ist; Monobook wurde ja nicht abgeschafft) eine Lücke, auf die sich zu verlassen schon immer falsch war und die mit Vector geschlossen wurde. Wenn du meinst, dass die Browsereinstellung überhaupt nicht verkleinert werden sollte, dann kannst du das für dich mittels #bodyContent { font-size: 1em; } in Special:Mypage/vector.css erreichen. Als Standardeinstellung wird das wohl nicht kommen, weil es für die, die 16px eingestellt haben (also fast alle) eine riesige Vergrößerung bedeuten und zu Beschwerden über zu große Schriften führen würde. (Selbst die Vergrößerung von 12.7px auf 12.8px hat bereits zu Beschwerden über zu große Schriften geführt; bei 100% gibt es wegen der Rundung noch keinen Unterschied, aber 90% von 12.7px sind gerundet 11px, während 90% von 12.8px gerundet 12px ergeben. Im Gegensatz zu deinem Problem betrifft diese minimale Vergrößerung sogar alle Benutzer.) --Entlinkt 17:55, 15. Jul. 2010 (CEST)

Das war mir neu, dass Webseiten auf Leute optimiert werden, die nicht in der Lage sind, ihre Browsereinstellungen anzupassen. Soweit ich bisher wußte, liegt der übliche Rahmen, in dem Schriftgrößen per css skaliert werden, übrigens bei maximal 10%. 20% sind stark erklärungsbedürftig und durch die Minderheit derer, die mit kaputten Einstellungen surfen, IMHO nicht gerechtfertigt. --Prüm 18:06, 15. Jul. 2010 (CEST)

Das hat aber nichts mehr mit MonoBook zu tun wie bereits mehrfach erwähnt zielt die Skalierung darauf ab, das bei Normaleinstellung 13px erreicht werden. Außerdem scheinen sehr viele Webdesigner diese Regel nicht zu kennen (heise.de, spiegel.de, tagesschau.de....). Ob es nicht günstiger wäre wenn WP eine größrere Schrift verpasst wäre ist eine andere. -- Biezl ✉ 18:19, 15. Jul. 2010 (CEST)

Zum Thema Schriftgrößen hat jeder seine Meinung. Der eine meint, man dürfe den Haupttext überhaupt nicht verkleinern, der nächste sagt, 90% [von medium] seien gerade noch akzeptabel, der übernächste meint, 80% gingen auch noch. Du hast insoweit recht, als 80% vermutlich wirklich das Minimum sind, bis zu dem man gehen kann. Es hilft allerdings niemandem weiter, sich über die Defaulteinstellungen der Browser zu ärgern. Die 16px haben historische Gründe (Netscape Navigator, der Browser, den einst jeder benutzte, hatte 16px, alle heutigen Browser haben sie übernommen), und sie sind – dieser Meinung waren auch die, die Monobook entworfen haben – zu groß. Eine Verkleinerung ist völlig üblich, es geht nur um das Wie. Wir können nicht einfach die Verkleinerung rauswerfen und sagen, jetzt müssen alle, die es wie vorher haben möchten, in ihrem Browser eine kleinere Schrift einstellen. Das müssten dann nämlich wirklich fast alle. Wir haben ja schon genug Schwierigkeiten damit, dass jetzt die wenigen, die eine größere Schrift haben möchten, ihre Einstellung vergrößern müssen. Es würde alles nur noch schlimmer werden. Gruß --Entlinkt 19:10, 15. Jul. 2010 (CEST)

Auf jeden Fall sollte die Kritik berücksichtigt werden. Ich weise hier nur auf Wikipedia:Umfragen/Neue Oberfläche#…die Schriftart und -größe? hin, wo gefühlte 30-40% die kleiner gewordene Schrift bemängeln. Wenn überhaupt, dann sollte die Skalierung im gleichen Rahmen erfolgen wie auf anderen vielbesuchten Seiten im Netz. --Prüm 20:03, 15. Jul. 2010 (CEST)

Man kann nicht beschließen, dass Kritik berücksichtigt werden soll, wenn das Ziel der Kritik unerreichbar ist. Man kann nicht einfach kritisieren „mir persönlich passten die Schriften bisher und jetzt nicht mehr, also zurück“, wenn der Vorzustand für andere schlechter war. Man kann nicht einfach sagen, schau her, da haben 30-40% unterschrieben, und deshalb muss jetzt etwas gemacht werden. Was Monobook macht, ist keine Lösung, sondern nur für eine Minderheit besser. Die 30-40% sind auch nicht repräsentativ, sondern es ist zu berücksichtigen, dass speziell in diesem Wiki (nicht Wikimedia- oder gar weltweit) ein gruppendynamischer Prozess gegen Vector in Gang gesetzt wurde, der von den technischen Gegebenheiten völlig losgelöst ist. Bei den 30-40% haben sicher auch Leute unterschrieben, bei denen die Schrift nicht kleiner geworden ist und die nur unterschrieben haben, weil sie am gruppendynamischen Prozess teilnehmen möchten. Und es fehlen die, die mit den Schriftgrößen zufrieden sind und keine Veranlassung haben, an einer derartigen Umfrage überhaupt teilzunehmen. Eine Umfrage, die als Anlass für grundlegende Veränderung dienen kann, müsste schon wesentlich solider organisiert sein. Gruß --Entlinkt 20:15, 15. Jul. 2010 (CEST)

Wenn also 16px der Standard ist und 13px das Ziel, dann wäre der Faktor 13/16 = 0,8125 die korrekte Wahl. Damit führt auch jede Änderung der Vorgabe zwischen 14px und 18px zu einer Änderung Schriftgröße. Zudem finde ich harmoniert bei großen Schriften Vector dann besser mit der Schriftgröße von anderen Seiten wie google und so.

Vorgabe (medium)	Faktor 0,8	Faktor 0,8125
14	11,2	11,4
15	12	12,2
16	12,8	13
17	13,6	13,8
18	14,4	14,6

Persönlich fände ich zudem eine Zielgröße von 14px (also 14/16) gut, da es die Lesbarkeit schon verbessert und ich in klein-kompakt keinen Nutzwert sehe.

Grüße -- Biezl ✉ 16:46, 15. Jul. 2010 (CEST)

Vorsicht, es ist zwar möglich, aber sehr gefährlich, den Skalierungsfaktor zu ändern. 0.8125em hätten sicher ihre Vorteile, aber ich weiß nicht, ob Vector wirklich auf genau 13px abzielt oder ob es darauf abzielt, bei Standardeinstellungen möglichst nah an Monobook zu sein. Die Vergrößerung von 12.7px auf 12.8px bei medium = 16px ist bereits nicht unproblematisch, weil sie dazu führt, dass eine weitere Verkleinerung auf 90%, wie sie in vielen Vorlagen vorkommt, in Monobook 11px ergibt, in Vector jedoch 12px. Mit 0.8125em statt 0.8em wäre dieser Effekt noch stärker (bislang braucht man 89%, bei falsch rundenden Browsern 88%, um auf 11px zu kommen, mit 0.8125em müsste man noch weiter runtergehen). Ich denke, die Diskussion wäre am besten mit den Entwicklern des Skins zu führen. Als lokale Anpassung halte ich das für zu riskant. Gruß --Entlinkt 19:10, 15. Jul. 2010 (CEST)

Und wo kann ich mit den Entwicklern diskutieren, Bugreport? Ich finde es schon seltsam, das ich für alle anderen Seiten auf eine (hier wirklich absurd) große Schrift stellen muss, nur um bei WP wenigstens auf auf augenfreundliche 15px zu kommen. 19px als Schriftgröße gibts bei keinem Browser, drum muss ich in dem Fall schon rauf auf 20px schalten.

Save the Pixels -- Biezl ✉ 19:35, 15. Jul. 2010 (CEST)

Siehe mw:Communication. Ich vermute allerdings, dass man dir sagen wird, dass Vector ursprünglich für hartkodierte Schriftgrößen konzipiert war und das jetzige System wegen Bug 20175 entstanden ist. Mit einer schnellen Änderung würde ich nicht rechnen (und wenn sie doch kommt, damit rechnen, dass dadurch vieles kaputtgeht – es wäre günstiger gewesen, das vor der allgemeinen Einführung, die lange genug angekündigt war, zur Sprache zu bringen). Was „augenfreundlich“ ist, ist auch Ansichtssache – die Mehrheit hat weder in Monobook noch in Vector jemals etwas anderes als 13px gesehen. In manchen Browsern kann man übrigens wie in Textverarbeitungsprogrammen durchaus Werte eingeben, die im Dropdownmenü nicht vorgesehen sind. Und man kann in Special:Mypage/vector.css direkt px eingeben. Musste man mit Monobook ja auch, wenn man 15px wollte. Gruß --Entlinkt 20:07, 15. Jul. 2010 (CEST)

Erstmal Danke für die Infos im Allgemeinen. Anfangs hab ich nichts gemacht, weil es genügend Diskussionen/Beschwerden gab und noch einer der bloß quasselt dort nur im Weg stünde. Irgendwie ist mir nicht aufgefallen, das das alles irgendwie so Vector-Hasser waren, die ausschließlich rumpöbeln und selbst nichts gescheit machen. Eine noch ganz andere Geschichte ist IE6/7 und größere Schrift um nicht zu sagen gigantisch. -- Biezl ✉ 20:25, 15. Jul. 2010 (CEST)

Es gibt inzwischen Bug 24402. Ich sehe keinen Sinn darin, die lokale Diskussion fortzusetzen, weil wahrscheinlich eh nichts dabei herauskommt. Es hat anscheinend niemand vor, eine so weit reichende Änderung lokal zu machen. Gruß --Entlinkt 18:02, 17. Aug. 2010 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Entlinkt 18:02, 17. Aug. 2010 (CEST)

„Vermeide hässliche weiße Ränder bei Float-Objekten auf nicht-weißen Hintergründen“

Eine unendliche Geschichte: MediaWiki zeichnet weiße Rahmen um floatierte Thumbnails, damit die Linien der Überschriften nicht bis an die Bilder stoßen. Dabei ist weiß nicht wörtlich als weiß, sondern als wie der Seitenhintergrund, Hauptsache nicht transparent zu verstehen. Ohne diese Rahmen sieht es so aus:

Testüberschrift

Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.

Mit den Rahmen soll es eigentlich so aussehen (Simulation):

Testüberschrift

Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.

In Monobook wurde vor vielen Jahren die Hintergrundfarbe geändert und namensraumabhängig gemacht, wodurch die Rahmen zu einem Problem („hässlich weiße Ränder“) wurden. Anstatt ihnen nun einfach auch namensraumabhängig dieselbe Farbe wie dem Seitenhintergrund zu geben, wurden sie entfernt und durch transparente Außenabstände ersetzt. Effektiv wurde damit ein beabsichtigtes und IMHO durchaus sinnvolles Feature kaputtgemacht. Schließlich wurde die Rahmenentfernung aus MediaWiki:Monobook.css hierher kopiert, obwohl Vector sie eigentlich gar nicht braucht, weil die Hintergrundfarbe immer weiß ist.

Einen sichtbaren Unterschied gibt es eigentlich nur, wenn ein Thumbnail in einer Box (div, Tabelle usw.) steht, die einen abweichenden Hintergrund hat. Es wäre nicht so schwer, die Auswirkungen dieses Codes zu begrenzen, indem man die Rahmen nur für solche Bilder transparent macht, die auch eine Box drumherum haben:

#bodyContent * div.thumb {
	border-color: transparent;
}

Möchten wir das (vielleicht auch auf anderem Wege, Vorschläge erbeten) versuchen? Gruß --Entlinkt 18:36, 14. Jul. 2010 (CEST)

Ich verwende seit zwei Jahren die Standardeinstellung von MediaWiki bei Monobook, also mit weißen Rahmen. Eine namensraumspezifische Einfärbung des Rahmens habe ich unterlassen und mich daran gewöhnt, dass auf Diskussionsseiten die Bilder einen weißen Rahmen haben. Ganz unproblematisch ist ein solcher weißer Rahmen aber nicht. Ich finde im Moment gerade aber keine Beispiele. --Fomafix 09:49, 15. Jul. 2010 (CEST)

Problematisch ist der Rahmen dann, wenn er auf einem nicht-weißen Hintergrund erscheint, zum Beispiel auf der Seite Portal:Hund. Dazu kann es meines Erachtens nur kommen, wenn ein Thumbnail nicht direkt in #bodyContent steht, weil #bodyContent immer weiß ist, was sich (außer durch Eingriffe in die CSS-Dateien) auch nicht beeinflussen lässt. Die Fälle sind deshalb ziemlich leicht zu unterscheiden:

• #bodyContent * div.thumb kann einen andersfarbigen Hintergrund haben
• #bodyContent > div.thumb hat immer einen weißen Hintergrund

Gruß --Entlinkt 14:51, 15. Jul. 2010 (CEST)

Die Probleme mit der Hintergrundfarbe sind nicht die einzigen Probleme. Im Gegensatz zu margin kollabiert ein border nicht mit anderen Abständen. Bei Fließobjekten spielt das wahrscheinlich keine Rolle, da dort eh nichts kollabiert. Bildern mit none haben class="thumb tnone" und bekommen von MediaWiki standardmäßig ein border:solid, der für einen Abstand sorgt, den wir derzeit nicht haben.

Eine Selektion mit #bodyContent * div.thumb funktioniert zwar (sogar beim IE6), erzeugt aber ein uneinheitliches Verhalten, das verwirrend sein kann. Neben Bildern sind prinzipiell auch alle Infoboxen dem Problem der Überschriftenlinie betroffen. Bei den üblichen Infoboxen mit nur einer Tabelle gibt es allerdings keine Möglichkeit einen weißen Rand per CSS zu aktivieren. --Fomafix 15:45, 15. Jul. 2010 (CEST)

(BK) #bodyContent * div.thumb ist extrem problematisch als Selektor, denn in der Voransicht gibt es noch eine zusätzliche Box div id="wikiPreview" innerhalb von div id="bodyContent", sodass der Selektor für alle Bilder gelten würde. --Fomafix 16:23, 15. Jul. 2010 (CEST)

Okay, mir fällt inzwischen auch ein weiteres (potenzielles, nie tatsächlich beobachtetes) Problem ein: Folgt auf ein floatiertes Thumbnail-Bild eine ungeclearte Box mit farbigem Hintergrund, dann ragt das Bild in die Box und es entsteht eine Konstellation, die man nicht selektieren kann.

Dass auch unfloatierte Thumbnails einen Rahmen bekommen, ist mir beim Testen auch aufgefallen, halte ich allerdings für einen Bug in MediaWiki. Bei unfloatierten Objekten kann es nicht zu einem Zusammenstoß mit anderen Objekten kommen, sie brauchen deshalb überhaupt keinen Rahmen (der Abstand kann, wie sonst auch üblich, ausschließlich über margin geregelt werden), und für sie ist auch keine Rahmenstärke (border-width) definiert. Deshalb greift der Initialwert border-width: medium (ergibt in der Regel 3px), was vermutlich gar nicht beabsichtigt ist.

Mit den Abständen gibt es übrigens noch eine Inkonsistenz: Bei floatierten Thumbnails setzt dieser Code für margin dieselben Werte, die standardmäßig border-width wären, ignoriert aber, dass es standardmäßig auch margin gibt. Dadurch werden die Abstände um floatierte Thumbnails an einigen Stellen kleiner, als sie standardmäßig sind, weil der Betrag, der sonst margin wäre, ganz wegfällt.

Wenn dieser Code allerdings bleibt, sollte er vielleicht nach MediaWiki:Common.css verschoben werden, weil er hier und in MediaWiki:Monobook.css und in MediaWiki:Modern.css gleich dreimal vorhanden ist. Gruß --Entlinkt 16:12, 15. Jul. 2010 (CEST)

MediaWiki definiert den weißen Rahmen in den Skins. Die Ersetzung durch margin sollte deshalb auch in den Skins geschehen. Eine Verschiebung nach MediaWiki:Common.css halte ich daher nicht für sinnvoll. Die Summe der Dateigrößen der geladenen CSS-Dateien und die Anzahl der CSS-Definitionen je Skin verändert sich dadurch auch nicht. --Fomafix 21:27, 15. Jul. 2010 (CEST)

Es ist ähnlich wie mit den Symbolen für externe Links: Die Definition, die die Icons einfügt, ist in den einzelnen Skins, die Definition der Klasse plainlinks zum Entfernen derselben Icons in shared.css. Ich denke, es liegt entweder daran, dass die weißen Rahmen älter als die Datei shared.css sind (shared.css gibt es erst seit Juni 2007, die weißen Rahmen muss es 2005 schon gegeben haben), oder daran, dass die shared.css beim Drucken nicht mitgeladen wird. Ich sehe nichts, was dagegen spricht, die Rahmenentfernung nach Common.css zu verschieben. Der Code ist in allen Skins gleich. Die englische Wikipedia und Commons haben ihn auch in Common.css (Commons benutzt allerdings border-color: transparent statt margin). --Entlinkt 22:39, 15. Jul. 2010 (CEST)

Genau das Problem mit der Überlappung hatte ich im Kopf. Es ist zwar recht selten aber möglich: --Fomafix 21:27, 15. Jul. 2010 (CEST)

Testüberschrift

Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.

#include <stdio.h>

int main(void)
{
  printf("Lorem ipsum\n");
  return 0;
}

---

Ich habe eine alternative Lösung, die ohne weiße Rahmen auskommt und auch für alle anderen Fließobjekte wie Infoboxen funktioniert:

Testüberschrift

Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.

---

#include <stdio.h>

int main(void)
{
  printf("Lorem ipsum\n");
  return 0;
}

Der Trick liegt in

h1, h2, h3, h4, h5, h6 { overflow:hidden }

Damit wird auch verhindert, dass die [Bearbeiten]-Knöpfe bei mehrfachen Fließobjekte verschoben werden, wenn sie – wie bei MediaWiki üblich – am rechten Rand sind. (oldEditsectionLinks = true;). Bei <hr/> gibt es eh keine Probleme mit dem Abstand. --Fomafix 09:28, 21. Jul. 2010 (CEST)

Beim Internet Explorer 6 bewirkt das overflow:hidden in diesem Fall nichts. --Fomafix 09:43, 21. Jul. 2010 (CEST)

Ein seltenen aber sichtbaren Unterschied durch overflow:hidden gibt es bei mehrzeiligen Überschriften, in die teilweise ein Fließelement hineinragt.

Testüberschrift

Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.

Lange Überschrift mit overflow:hidden. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.

Dieser Fall ist allerdings äußerst selten und die Darstellung ist auch nicht problematisch. --Fomafix 19:38, 21. Jul. 2010 (CEST)

Beim Internet Explorer 6 bewirkt display:inline-block das gleiche Verhalten:

Testüberschrift

Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.

Lange Überschrift mit display:inline-block;overflow:hidden. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.

Allerdings muss das display:inline-block (mit den üblichen CSS-Hacks) auf den IE6 beschränkt werden, weil es bei anderen Browsern stört. --Fomafix 13:34, 22. Jul. 2010 (CEST)

Vielen Dank für die Recherche. Ich sehe inzwischen auch, dass der MediaWiki-Normalzustand zu problematisch ist.

Zwei technische Bemerkungen:

• overflow: hidden wurde als Fix für Bug 1629 bereits versucht und wieder zurückgenommen, weil es damals inakzeptable Nebenwirkungen hatte: Im IE/Mac funktioniert overflow: hidden nur bei divs, alle anderen Elemente werden komplett unsichtbar. Da der IE/Mac nun quasi tot ist, kann man das evtl. ignorieren. In Firefox 2 gibt es Probleme mit Sprachen, die von rechts nach links geschrieben werden.
• display: inline-block funktioniert im IE6 deshalb, weil es ein hasLayout-Auslöser ist. Es muss nicht vor anderen Browsern versteckt, sondern kann einfach wieder zurückgesetzt werden (dies muss in einer separaten Regel geschehen, damit der hasLayout-Status erhalten bleibt, und ist es deshalb mit style-Attributen nicht nachzubilden, aber in einem echten Stylesheet ohne Weiteres möglich). Bekannt ist dieser Hack unter dem Namen „TripSwitch“ (Demonstration).

Da das zugrundeliegende Problem alle Wikis und alle Skins betrifft, sollte es meiner Meinung nach direkt in MediaWiki und skinunabhängig gelöst werden, also in shared.css (+ commonPrint.css, weil shared.css bei der Druckversion nicht mitgeladen wird). Man müsste es also upstream melden und die mit den einzelnen Skins involvierten Entwickler an einen Tisch bekommen. Gruß --Entlinkt 15:00, 22. Jul. 2010 (CEST)

Ja, richtig. Es sollte direkt in MediaWiki geändert werden. Bei ar:نيويورك (مدينة) gibt es derzeit auch Probleme mit falsch positionierten Editlinks, die durch overflow:hidden – zumindest bei einem Firefox 3.5 – behoben werden. Neue Darstellungsfehler kann ich nicht feststellen. --Fomafix 16:12, 22. Jul. 2010 (CEST)

→ Bug 8814. --Entlinkt 01:48, 24. Jul. 2010 (CEST)

overflow:hidden hat das Problem, dass lange nicht umbrechbare Wörter hinter einem Fließobjekt verschwinden könnten. Statt wie bisher so

Infobox

Überschrift mit langem Wort. Loremipsumdolorsitametconsetetursadipscingelitr, sed diam nonumy eirmod

würde das mit overflow:hidden so aussehen:

Infobox

Überschrift mit langem Wort. Loremipsumdolorsitametconsetetursadipscingelitr, sed diam nonumy eirmod

Beim Firefox könnte mit min-width:-moz-min-content verhindert werden, dass ein langes Wort von einem Fießobjekt verdeckt würde:

Infobox

Überschrift mit langem Wort. Loremipsumdolorsitametconsetetursadipscingelitr, sed diam nonumy eirmod

Andere Browser bleiben da allerdings außen vor. --Fomafix 22:25, 25. Jul. 2010 (CEST)

Beim Firefox ist mir eine negative Veränderung durch overflow:hidden aufgefallen: Es ist nicht mehr möglich eine Textstelle mit der Maus zu markieren, die in einer Überschrift beginnt und außerhalb der Überschrift endet. Umgekehrt zu markieren ist weiterhin möglich. Bei der Diff-Ansicht gibt es übrigens das gleiche Problem, da dort auch overflow:auto verwendet wird. --Fomafix 09:00, 28. Jul. 2010 (CEST)

overflow:hidden für Überschriften (Bug 26449) und margin statt border:white bei Thumbs (Bug 26423) ist mit r79010 und Follow-Ups und r79087 und Follow-Ups im Trunk aktiv. --Fomafix 00:53, 28. Dez. 2010 (CET)

Durch overflow:hidden fehlt bei dem Titel des Artikels AUCTeX der untere Querbalken des tiefergesetzten „E“. Bei der Titelzeile ist das overflow:hidden eigentlich nicht notwendig. Mit h1#firstHeading { overflow:visible } konnte es hier wieder aufgehoben werden. --Fomafix 08:54, 27. Jan. 2011 (CET)

Alle Bugs sind inzwischen live und alle Workarounds entfernt. --Fomafix 00:31, 28. Jan. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 00:31, 28. Jan. 2012 (CET)

MW1.17

Seit MediaWiki 1.17 können folgende Definitionen entfallen:

Bug 26423 → r79010, r79011

/* Vermeide hässliche weiße Ränder bei Float-Objekten auf nicht-weißen Hintergründen. */
div.thumb {
	border: none;
}
div.tright {
	margin: 0.5em 0 0.8em 1.4em;
}
div.tleft {
	margin: 0.5em 1.4em 0.8em 0;
}

Bug 20706 → r76322

/* Vervollständigung für [[rev:69336]] bzw. [[bugzilla:20706]] */
kbd,
samp {
	font-family: monospace, "Courier New";
}

--Fomafix 22:22, 19. Feb. 2011 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Guandalug 09:09, 21. Feb. 2011 (CET)

.topicon einen tick höher?

Vorschlag: nach

/* showTopicon in [[MediaWiki:Vector.js]] */
div.topicon {

folgendes einfügen:

        position: relative;
        top: -10px;

Ziel: Die Lesenswert- und Exzellenz-Icons rutschen ein bisschen höher und überlagern nicht mehr die Koordinaten. Hintergrund ist diese Meldung auf den Adminanfragen. Gruss, --MBq ^Disk 20:52, 27. Dez. 2012 (CET)

Hi, das Problem scheinen eher die Koordinaten zu sein, die durch die Gegend hüpfen .aufgrund von blah blah blah, und nicht das topicon. Siehe [1]. --Courier New (Diskussion) 18:48, 28. Dez. 2012 (CET)

Erledigt dank Deinem Vorschlag --MBq ^Disk 13:47, 30. Dez. 2012 (CET)

Meiner Meinung nach ist das nicht erledigt, es gibt hier einen echten Bug. Die Icons sollten eigentlich ganz oben rechts ausgerichtet sein und waren es auch mal, sind es aber seit der Umstellung auf HTML5 nicht mehr, weil der neue Doctype in jedem Browser den strikt standardkonformen Rendering-Modus auslöst (im Gegensatz zum vorher benutzten Doctype, der den sogenannten almost standards mode ausgelöst hat; Hindergrundinfos hier und dort).

Der offensichtliche Fix

div.topicon img {
	display: block;
}

ist leider nicht möglich, weil er MediaWiki:Specialpage-helplink zerschießen würde. Zwei andere mögliche Fixes (die ich jetzt nicht ausführlich in jedem Browser getestet habe, die aber grundsätzlich funktionieren sollten) wären

div.topicon img {
	vertical-align: top;
}

oder (im IE erst ab Version 9)

div.topicon > a:only-child > img {
	display: block;
}

Meinungen? --Entlinkt (Diskussion) 04:26, 14. Jan. 2013 (CET)

Andere Variante implementiert:

div.topicon {
	line-height: 1;
}

--Entlinkt (Diskussion) 23:39, 6. Jun. 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Entlinkt (Diskussion) 23:39, 6. Jun. 2013 (CEST)

Jump-to-Nav-Anpassung

Die Regel #jump-to-nav { margin: 0; } (Diff, Diskussion) setzt eine Regel aus commonInterface.css außer Kraft, die aus gutem Grund existiert: Die Screenreader-Links (die bei unangemeldeten Benutzern immer vorhanden sind) bewirken jetzt eine sichtbare Vergrößerung des (m. E. sowieso schon zu großen) Abstands unterhalb der Hauptüberschrift. --Entlinkt (Diskussion) 17:57, 20. Mai 2013 (CEST)

Bug 48687 gemeldet und derweil lokal durch absolute Positionierung umgangen. --Entlinkt (Diskussion) 23:39, 6. Jun. 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Entlinkt (Diskussion) 23:39, 6. Jun. 2013 (CEST)

Wertangabe ohne Einheit?

Hallo, hier wurde für die line-height-Eigenschaft ein neuer Wert ohne Einheit festgelegt. Das ist mir bisher unbekannt (außer bei 0). Ist das sinnvoll und funktioniert das? --Wiegels „…“ 23:54, 19. Aug. 2013 (CEST)

Ja, line-height: 1.5 bedeutet einfach, dass die Zeile 1,5-mal so hoch sein soll wie die Schriftgröße und dass dieses Verhältnis weitervererbt werden soll. line-height: 1.5em dagegen würde bedeuten, dass die Zeile 1,5-mal so hoch sein soll wie die Schriftgröße und dass der daraus resultierende absolute Wert weitervererbt wird. In diesem Fall sollte das aber egal sein, weil es sowieso nichts weiterzuvererben gibt. Gruß --Entlinkt (Diskussion) 01:23, 20. Aug. 2013 (CEST)

Wieder etwas gelernt. Vielen Dank für diese Erklärung! --Wiegels „…“ 01:35, 20. Aug. 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Wiegels „…“ 10:47, 2. Aug. 2014 (CEST)

#bodyContent

Der Selector #bodyContent soll durch .mw-body-content ersetzt werden (gerrit:130525 und gerrit:129563). Das sollte hier ebenfalls umgesetzt werden. Aufgrund von Caching sollte hier ebenfalls für 31 Tage eine Doppeldefinition gemacht werden. --Fomafix (Diskussion) 12:00, 31. Mai 2014 (CEST)

Die 31-Tage-Doppeldefinition ist nicht nötig (es kann zwar 31 Tage dauern, bis sich Änderungen am HTML verbreiten, aber Stylesheets werden unmittelbar nach einem Update neu geladen). Es genügt, den Selektor zu ersetzen, sobald gerrit:130525 live ist (vorher darf das aber nicht passieren, weil der ID-Selektor stärker als der Klassen-Selektor ist).

Gruß --Entlinkt (Diskussion) 16:13, 31. Mai 2014 (CEST)

Stimmt. Eine Doppeldefinition für 31 Tage als ID und als Klasse im HTML und im CSS ist nicht notwendig. --Fomafix (Diskussion) 22:37, 8. Jun. 2014 (CEST)

gerrit:130525 ist gemerged. --Fomafix (Diskussion) 23:52, 8. Jul. 2014 (CEST)

geändert. --Fomafix (Diskussion) 09:09, 18. Jul. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix (Diskussion) 09:09, 18. Jul. 2014 (CEST)

geo

Bitte wie in MediaWiki:Common.css folgendes einfügen:

 /* Im Projekt WP:GEO benutzt die [[Vorlage:Coordinate]] das «geo-microformat» zur semantischen
 Auszeichnung des Texts. Der Inhalt dieses [[Tag (Informatik)|Tags]] ist nicht für den Leser bestimmt. */
 .geo {display:none;}

oder gewünschtes anders erzielen ;-) -- visi-on 12:29, 25. Aug. 2009 (CEST)

Sorry Falsch!

bitte aus MediaWiki:Monobook.css:

/* Absolute Positionierungen für Monobook.css */
/* Bitte [[MediaWiki Diskussion:Common.css#Absolute Positionierungen]] beachten */
 
/* Koordinaten-Vorlagen */
#coordinates_3_ObenRechts {
      display: inline;
}

#coordinates {
   display:inline;
   position:absolute; z-index:1; border:none; background:none; right:12px; top:0.2em; float:right; margin:0 18px 0 0;
   padding: 0 0.1em 0 0; line-height:11px; text-align:right; text-indent:0; font-size:10px; text-transform:none; white-space:nowrap;
}

übernehmen -- visi-on 15:51, 25. Aug. 2009 (CEST)

Diese Position für die Koordinaten passt bei Vector nicht mehr, da in http://de.wikipedia.org/skins-1.5/vector/main-ltr.css #bodyContent { position: relative; } und nicht mehr wie bei http://de.wikipedia.org/skins-1.5/monobook/main.css #content { position: relative; } gilt. Die Artikelkoordinaten würden so unterhalb des Artikelnamens und damit viel zu weit unten angezeigt werden. Außerdem fehlen für die Bapperl wie Exzellente Artikel auch noch die CSS-Definitionen. --Fomafix 12:28, 31. Aug. 2009 (CEST)

Mein Vorschlag lautet:

#coordinates_3_ObenRechts {
	display: inline;
}

#coordinates {
	display:inline;
	position:absolute; z-index:1; border:none; background:none; right:0; top:-3em; float:right; margin:0;
	padding:0; line-height:11px; text-align:right; text-indent:0; font-size:10px; text-transform:none; white-space:nowrap;
}

Damit stehen die Koordinaten ungefähr auf der Linie der Überschrift. Es könnte nur bei langen Überschriften und schmalen Browserfenstern Problem geben. --Fomafix 12:53, 31. Aug. 2009 (CEST)

Alternativ auch #coordinates { top: -1.4em; }, wie bei #contentSub { margin-bottom: 1.4em; } aus http://de.wikipedia.org/skins-1.5/vector/main-ltr.css. Damit werden die Artikelkoordinaten direkt unterhalb der Linie unter der Überschrift angezeigt. --Fomafix 13:08, 31. Aug. 2009 (CEST)

Es wäre auch durch

#content { position: relative; }
#bodyContent { position: static; }

das Verhalten von Monobook nachzubauen. --Fomafix 15:09, 31. Aug. 2009 (CEST)

Ich teste diese Einstellung nun schon fast ein dreiviertel Jahr. Allerdings verwende ich den Skin Vector sehr selten und habe andere Browser noch nicht überprüft. Nachdem sich immer noch nichts getan hat und Vector demnächst als Standard aktiviert wird, habe ich unter Wikipedia:Administratoren/Anfragen#Skin Vector nach Admins mit CSS-Kenntnissen gesucht. --Fomafix 23:01, 28. Mär. 2010 (CEST)

Benutzer:Euku hat den Vorschlag übernommen. --Fomafix 11:46, 3. Apr. 2010 (CEST)

Überschneidung mit dem Lemma

Problem mit dem aktuellen Zustand: Wird ein Artikel über eine Weiterleitung aufgerufen, gibt es eine Überschneidung mit dem Lemma, siehe Screenshot rechts. --Entlinkt 02:03, 26. Mai 2010 (CEST)

Stimmt. Das Problem steckt in dem <div id="contentSub">-Block. Ich habe folgenden Workaround gefunden:

#contentSub, #contentSub2 { overflow: hidden; }

Damit verschiebt sich die obere Ecke und für die Koordinaten reicht top:0, um unter die Linie zu bleiben. line-height:11px kann auf line-height:10px reduziert werden. Für das z-index:1 sehe ich keine Notwendigkeit und kann entfallen, denn es sorgt für für Probleme mit dem Aktionsmenu von Vector. Zusammengefasst ergibt sich damit folgendes:

#contentSub, #contentSub2 { overflow: hidden; } /* Workaround bei leerem Element */
#coordinates {
	display:inline;
	position:absolute; border:none; background:none; right:0; top:0; float:right; margin:0; padding:0;
	line-height:10px; text-align:right; text-indent:0; font-size:10px; text-transform:none; white-space:nowrap;
}

Ich teste die Einstellungen gerade --Fomafix 13:35, 26. Mai 2010 (CEST)

Situation mit #contentSub { overflow: hidden; }

Mit diesem Vorschlag entspricht es in Firefox und Opera meinen Erwartungen (Koordinaten immer knapp, aber ausreichend unter der Linie der Überschrift), bei Google Chrome und Weiterleitungen auch, aber bei Google Chrome und Nichtweiterleitungen hängen die Koordinaten über den Text (im Screenshot oben). --Entlinkt 18:37, 26. Mai 2010 (CEST)

Die Browser scheinen bei einem leeren Element mit margin > 0 mit der Positionierung durcheinanderzukommen. Ein alternativer Workaround ist #contentSub:after { content: "\A0"; }. Damit wird das Element nie leer. Ich teste es. --Fomafix 15:09, 27. Mai. 2010 (CEST)

Bei der Position unterhalb der Linie gibt es generell das Problem, dass dort bereits die Bedienelemente zum Sichten bei ungesichteten Versionen angezeigt werden. --Fomafix 15:14, 27. Mai 2010 (CEST)

Ich teste daher die Koordinaten direkt oberhalb der Linie mit #coordinates { top:-1.5em; }. Bei extrem langen Titeln kann es jetzt natürlich zu einer Überlappung mit dem Titel kommen. Auch eine Position auf Höhe der Linie und mit weißer Hintergrundfarbe zum verdecken der Line wäre denkbar: #coordinates { top:-1em; line-height:10px; background-color:white; padding-left:0.3em; }. Allerdings gibt es auch hier Überlappung mit den Unterlängen des Titels. --Fomafix 15:51, 27. Mai 2010 (CEST)

Eine weitere Methode um die absolute Positionierung fixen ist

#siteSub {
	display:block;
	visibility:hidden;
	margin:0;
	padding:0;
	line-height:0;
}

Da in der englischsprachigen Wikipedia #siteSub normalerweise nicht ausgeblendet ist, gibt es dort diese Probleme mit der Positionierung bei Vector nicht. --Fomafix 22:50, 27. Mai 2010 (CEST)

Koordinaten über der Linie fände ich schade. Unter der Linie fand ich sie anfangs überraschend, gewöhnte mich aber sehr schnell daran, und dann gefielen sie mir dort ausgesprochen gut. Dann sieht man nämlich auch, dass sie zum Artikel gehören und nicht irgendwie außerhalb stehen, und Zusammenstöße mit dem Lemma sind ausgeschlossen. Könnte man nicht dafür die Sichtungsbox (#mw-revisiontag, evtl. auch andere) etwas nach unten schieben, um Platz für die Koordinaten zu schaffen?

Beide Workarounds (#contentSub:after { content: "\A0"; } und das zuletzt genannte mit #siteSub) lösen das Problem, zuverlässig dieselbe Stelle zu treffen, aber in Google Chrome erzeugen beide ein neues Problem, nämlich zusätzlichen, unharmonisch wirkenden Leerraum zwischen der Linie der Überschrift und der ersten Textzeile. Bei dem Workaround mit #contentSub habe ich keine Weg gefunden, das zu vermeiden, aber bei dem Workaround mit #siteSub würde ein zusätzliches height:0 helfen. Ganz weg ist der zusätzliche Leerraum dann zwar immer noch nicht, aber er fällt kaum mehr auf. --Entlinkt 23:38, 27. Mai 2010 (CEST)

Ich finde diese Workarounds ziemlich frustrierend und wacklig. Die englische Wikipedia „trifft“ auch nur im Artikelnamensraum immer dieselbe Stelle, weil #siteSub im Artikelnamensraum eingeblendet ist. Im Vorlagennamensraum klappt das nicht, vergleiche etwa en:Template:Coord (Koordinaten unter der Linie) mit der Weiterleitung en:Template:Coor dms (Koordinaten auf der Linie). Hier bei uns ist es nicht üblich, #siteSub („aus Wikipedia, der freien Enzyklopädie“) einzublenden. Um denselben Effekt wie in der englischen Wikipedia zu erreichen, müssten wir es erst mit display:block einblenden und dann mit visibility:hidden unsichtbar machen und dann mit Tricks den Leerraum so klein machen, dass er nicht auffällt. Das ist doch übertrieben. Ich tendiere deshalb inzwischen zu der von Fomafix oben schon erwähnten Möglichkeit

#content { position: relative; }
#bodyContent { position: static; }

Damit würden wir lokal rev:52855 rückgängig machen. Ist zwar auch nicht optimal, aber unter der Linie ist der Platz ohnehin beengt. Mit dieser Variante würden wir ohne weitere Workarounds im Innenabstand (padding) von #content landen, was wahrscheinlich von nichts anderem besetzt ist, und hätten dort 1em Platz für eine Zeile, noch über der Sitenotice. Mehr als eine Zeile hätten wir an der anderen Stelle auch nicht. Gruß --Entlinkt 17:21, 29. Mai 2010 (CEST)

Mit diesem CSS-Gefrickel geht’s irgendwie nicht weiter. In fr:MediaWiki:Common.js (Permalink, Funktionen IconesDeTitre und moveCoord) ist ein interessanter JavaScript-Ansatz zu finden. Ich habe versucht, das an unsere Verhältnisse anzupassen, dabei herausgekommen ist folgendes:

addOnloadHook(function() {
	// Icons einsammeln und umdrehen, damit die visuelle Reihenfolge der Reihenfolge im Wikitext entspricht
	var items = getElementsByClassName(document.getElementById("bodyContent"), "div", "topicon");
	items.reverse();
	// Textelemente einsammeln und hinzufügen
	var textElementIds = new Array("coordinates", "issnlink", "shortcut", "editcount");
	for (var i=0; i<textElementIds.length; i++) {
                var textElement = document.getElementById(textElementIds[i]);
                if (!textElement) continue;
		items = items.concat(textElement);
	}
	// Lemma finden und Dinge davorsetzen
	var h1 = document.getElementById('firstHeading');
	for (var i=0;  i<items.length; i++) {
		var item = items[i];
		h1.parentNode.insertBefore (item, h1);
	}
});

Dazu gehört ein CSS, das rudimentär so aussehen könnte:

#coordinates, #editcount, #issnlink, #shortcut,
#artikelstadium, .topicon, #commons-icon, #spoken-icon {
	display: inline;
	position: static;
	float: right;
	margin-left: 0.2em;
}

Außer den Nachteilen, die JavaScript immer hat, sehe ich eigentlich nur Vorteile. Die Elemente ordnen sich „natürlich“ an und nehmen nicht mehr zusätzlichen Platz in Anspruch, als sie wirklich brauchen; bei kurzen Titeln gar keinen, bei langen Titeln eher dezent. Nun würde mich interessieren:

1. Ist JavaScript an dieser Stelle überhaupt akzeptabel?
2. Wenn ja, soll es eine Fallback-Lösung nur mit CSS geben?
3. Taugt die Implementation etwas? Ist die Position vor der ersten Überschrift angemessen? Browserkompatibilität? Bugs? Denkfehler? Optimierungsmöglichkeiten?
4. Wie kann man das ausreichend testen? Vielleicht erst mal als Gadget verfügbar machen?

Gruß --Entlinkt 01:54, 4. Jun. 2010 (CEST)

Daran hatte ich auch schon immer gedacht. Auf jedenfall CSS-Fallback. Aber das ist ja kein Problem. appendcss() mit display none und dann an die Stelle setzen.

Bei meinen Änderungen hatte ich schonmal vor eine js-Datei zu erstellen, die nur bei Sichtern eingebunden wird, da diese Gruppe weiß, wo man Bugs meldet. Letztendlich habe ich jedoch immer selbst alles ausgetestet. Schreib's doch erstmal auf eine Unterseite bei dir, dann kann man sehen, wie kompliziert das ist und den nötigen Testaufwand entsprechend abschätzen. Meistens reicht's wenn eine handvoll drüberschaut und man mutig ist. Merlissimo 02:05, 4. Jun. 2010 (CEST)

Ich teste den vorstehenden Code zurzeit (.js perma, .css perma). Ein CSS-Fallback ist auf der Vorderseite quasi schon vorhanden. Da fehlen zwar die Icons, und die Textelemente liegen bei langen Titeln über dem Titel, aber das finde ich persönlich jetzt nicht so dramatisch. --Entlinkt 02:31, 4. Jun. 2010 (CEST)

Ich habe noch ein bisschen weiter herumgespielt und bin inzwischen hier angelangt. Die Änderungen:

• Es ist nun in allen Skins lauffähig, auch in den ganz alten, die keine ID #firstHeading am Lemma haben.
• Es beeinträchtigt nun das allgemeine CSS nicht mehr, nutzt es aber, soweit sinnvoll, und überschreibt nur die Eigenschaften, die auch überschrieben werden müssen, indem es sie direkt an die Elemente setzt. Benutzer, die JavaScript deaktiviert haben, sehen die Elemente wie bisher entweder gar nicht oder absolut positioniert.
• In Vector sieht es meiner Meinung nach einwandfrei aus.
• In Monobook und Modern bereiten Vorlage:Gesprochene Version und MediaWiki:Sharedupload-desc-here noch Probleme, weil die Klasse .topicon und die ID #spoken-icon nicht an demselben div, sondern an zwei verschachtelten divs stehen. Das ist nur ein temporärer Workaround, bis die veraltete ID #artikelstadium weg kann (31 Tage ab dem 25. Mai), und sollte dann direkt in den Vorlagen gelöst werden.
• In Modern passen außerdem Hintergrund- und Vordergrundfarbe der Textelemente nicht zusammen.
• In den älteren Skins, in denen die Textelemente bisher gar nicht unterstützt wurden, sind sie nicht gestylt und deshalb z. B. die Koordinaten ungewohnt groß.

Offen sind die Fragen, ob so etwas als Standardlösung für Vector in Betracht kommt und ob diese Implementation in Betracht kommt. Ist das Skript schnell genug, gibt es noch Möglichkeiten, es schneller zu machen? Dafür reichen meine JavaScript-Kenntnisse nicht aus. Gruß --Entlinkt 17:19, 5. Jun. 2010 (CEST)

Eine weitere Methode die Verschiebung der absoluten Positionierung ohne und mit Weiterleitung (#contentSub leer oder nicht) zu verhindern wäre

#bodyContent {
	display: inline-block;
}

Zumindest beim Firefox sorgt das für eine korrekte und einheitliche absolute Positionierung. --Fomafix 13:07, 28. Jul. 2010 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: hgzh 13:14, 19. Apr. 2022 (CEST)

Hintergrundfarbe Diskussionsseiten

Auf Wikipedia:Usability-Initiative/Feedback#Unterscheidung von Diskussionsseiten wurde vorgeschlagen, Diskussionsseiten wie in monobook zur besseren Unterscheidung einen bläulichen Hintergrund zu geben. Ich gebe den Vorschlag einfach mal weiter, technisch sollte das ja kein Problem sein. --Schnark 10:12, 9. Jun. 2010 (CEST)

Ich bin eher dagegen. Kein einziger Skin außer Monobook macht sowas, und auch in Monobook ist das nicht die Normaleinstellung, sondern wurde anno dazumal aus einer spontanen Laune heraus hier lokal übernommen, und zwar mit der Bemerkung „Farbtest“ und, wie man dem Kommentar im Quelltext entnehmen kann, aus dem persönlichen Stylesheet von en:User:Lupo (Difflink). Ein tatsächlich positiver Effekt auf die Usability ist m. E. nicht nachgewiesen, sondern es haben sich einfach viele von Monobook daran gewöhnt. Vector ist aber ein neuer Skin, und man kann sich sehr schnell an die einheitliche Farbe gewöhnen. Wer die Seiten wie in Monobook namensraumabhängig farbig haben will, kann das auch in sein persönliches CSS schreiben oder ein Gadget draus machen. --Entlinkt 10:43, 9. Jun. 2010 (CEST)

Das sehe ich wie Entlinkt. Gegebenenfalls kann man das in ein Gadget verwandeln (für die CSS-Laien), aber global würde ich das nicht einstellen wollen. --Guandalug 10:55, 9. Jun. 2010 (CEST)

Halte ich ehrlich gesagt für sinnvoll. Das erlaubt es schneller zwischen ANR und anderen Namensräumen zu unterscheiden. Eventuell lässt sich auch eine andere Form der Markierung finden, aber prinzipiell ist die Information „du befindest dich gerade im Meta-Bereich“ hilfreich. --Church of emacs D B 11:06, 9. Jun. 2010 (CEST)

Sehe ich genauso. Es ist für Neulinge auch ein zusätzlicher Hinweis, dass es verschiedene NR gibt. Gerade diese können z.B. auch BNR, ANR etc. nicht unterscheiden bzw. der Unterschied ist ihnen nicht bewusst und sie erstellen irgendwo ihre Artikel. --Euku:^⇄ 11:32, 9. Jun. 2010 (CEST)

Wie Neulinge das sehen, können wohl auch nur Neulinge sagen (und wer weiß, dass in Monobook – aber auch nur dort und nicht in jedem Wiki – der Namensraum 0 weiß und alle anderen blaugrau sind, ist definitionsgemäß kein Neuling), aber ich habe da so meine Zweifel, ob das usabilitymäßig wirklich etwas bringt, das auch objektivierbar ist. Die Trennung zwischen Enzyklopädie und Metabereich ist auch nicht so klar an den Namensräumen festzumachen. Artikel sind Enzyklopädie, die Hauptseite ist im Projektnamensraum, aber auch Enzyklopädie, Kategorien sind m. E. Enzyklopädie (stehen ja in jedem Artikel unten und sind nicht als „extern“ markiert; wäre auch fragwürdig, weil sie wieder zurück zu Artikeln führen), Portale sind grenzwertig (werden zwar in Artikeln als „externe Links“ dargeboten, präsentieren aber trotzdem enzyklopädische Inhalte), Listen sind zwar Enzyklopädie, aber eigentlich keine „Artikel“, sondern eher sowas wie Anhänge usw. Dass jemand Diskussionsseiten und echte Metaseiten wie die Löschkandidaten oder die Vandalismusmeldung mit dem enzyklopädischen Bereich verwechselt, ist vielleicht auch eher konstruiert. --Entlinkt 23:57, 9. Jun. 2010 (CEST)

Dann beobachte sie doch mal, da sie letztlich doch keiner fragt. Dann wird man feststellen, dass es (wie z.B. hier) nicht selbsterklärend ist, trotz Unterschied. Klar, die Trennung der NR ist nicht 100% rein, aber es würde schon unabhängig von der Erfahrung helfen, wenn man eine visuelle Trennung zwischen DS- + BNR + WP-NR und dem Rest hat. --Euku:^⇄ 10:55, 10. Jun. 2010 (CEST)

Jedes Beispiel einer Namensraumverwechslung durch einen Neuling aus der Zeit, als Monobook der Standardskin war, belegt meiner Meinung nach eher, dass die Färbung nichts bringt, sondern eine Spielerei für alte Hasen ist, dies es so gewohnt sind und unruhig werden, wenn man ihnen ihr Spielzeug wegnimmt. Und diese Spielerei fordert Opfer: Beim Debuggen eines ganz anderen Problems ist mir gerade zufällig aufgefallen, dass die aktuelle Centralnotice zur Skinumstellung für Monobookler einen transparenten Hintergrund hat, obwohl sie eigentlich einen #FCFCFC-Hintergrund (leichtes Grau) haben soll. Und zwar, weil Monobook diverse Tabellen, die auf die Standardhintergrundfarbe (und das ist – auch in Monobook – weiß) abgestimmt sind, transparent macht, um den Schaden der namensraumsabhängig wechselnden Farbe zu begrenzen. Dabei erwischt es aber leider auch ein paar Tabellen, die absichtlich nicht transparent sind. Große Klasse! So schwer ist der „Zurück zur alten Oberfläche“-Link für die, die überhaupt keinen Neuanfang machen wollen, doch nun auch wieder nicht zu finden, oder? --Entlinkt 00:56, 13. Jun. 2010 (CEST)

Falls sich ein Administrator von Zahlen beeindrucken lässt: In der Umfrage waren 52 (85 %) Benutzer gegen die einheitliche Farbe, 9 (15 %) dafür. Ob diese Zahlen die oben angeführten Argumente überstimmen, muss aber ein eventuell handelnder Administrator selbst überlegen. --Schnark 11:57, 9. Sep. 2010 (CEST)

Ich weiß ja nicht, wovon sich andere Admins beeindrucken lassen, aber meiner Meinung nach ist die Umfrage ziemlich wertlos.

• Teilgenommen haben fast nur angemeldete Benutzer. Ich sehe da auf Anhieb nur eine IP-Äußerung, und die lautete "schwaches  Kontra Sinn?" => Extremer Bias.
• Die Umfrage wurde genau am Tag der Skinumstellung erstellt und gestartet, obwohl davor ein Jahr (!) Zeit war, sich mit Vector zu befassen; von der Erstellung bis zur ersten Stimmabgabe vergingen sage und schreibe 20 Minuten. => Nochmals Bias + Schnellschuss.
• In kaum einem anderen Wiki scheinen die Hintergrundfarben irgendwen zu interessieren. Abweichende Farben habe ich bislang nur in der italienischen Wikipedia gesehen. Kann gerne ergänzt werden; insbesondere würde mich interessieren, wie viele Wikis den Seitenhintergrund, aber nicht die Tabs umfärben und damit das Konzept ruinieren.
• Auf Anhieb fiel mir in der Umfrage ein Nick auf, der neulich an anderer Stelle kundgetan hat, es sei eine "weise Entscheidung", Vector nicht zu benutzen (vulgo Bashing); derselbe begründete seine Stimmabgabe in der Umfrage mit der Aussage "Da kann es rasch passieren, dass ein Text im falschen Namensraum abgespeichert wird." Viel mehr als die bloße Behauptung würden mich hier wirklich mal Daten interessieren, wie viele namensraumfehlgeleitete Beiträge es in beiden Szenarien jeweils tatsächlich gibt. Selbst wenn geeignete Daten irgendwann mal beigebracht werden, stellt sich aber immer noch die Frage, weshalb ausgerechnet nur der Artikelnamensraum von allen anderen unterschieden werden soll. Nach meiner persönlichen (natürlich auch nicht biasfreien) Beobachtung kommt es wesentlich häufiger vor, dass Benutzer- und Benutzerdiskussionsnamensraum verwechselt werden. (Diskussionsbeiträge im Artikelnamensraum kommen natürlich auch vor, aber selten, und sie kamen trotz abweichender Hintergrundfarben schon immer vor.)
• Fast vergessen: In der Umfrage mögen zwar 85% gegen die einheitliche Farbe gewesen sein, aber niemand weiß so genau, wofür die 85% eigentlich sind. Es gibt viele Möglichkeiten, die Farbe uneinheitlich zu machen: Man kann wie in Monobook alles außer dem Artikelnamensraum einfärben, ebensogut könnte man aber auch nur alle Diskussionsnamensräume einfärben oder ganz andere Dinge tun. Dass die 85% es in Vector genau wie in Monobook (also die Artikel weiß und alles andere graublau) haben möchten, ist vielleicht eine naheliegende Vermutung, aber keineswegs sicher. Davon abgesehen vermisse ich in der Umfrage auch eine Aufklärung, dass standardmäßig alle Skins – auch Monobook – eine einheitliche Hintergrundfarbe haben und ein Konzept, wer sich eigentlich um die durch die Umfärbung verursachten Bugs (Tabellenhintergründe!) kümmern soll.

Gruß --Entlinkt 18:16, 9. Sep. 2010 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: hgzh 13:14, 19. Apr. 2022 (CEST)

Formatierung von Einzelnachweisen

Die Einzelnachweise sollten sich vom üblichen Text unterscheiden, daher schlage ich vor, die Schriftgröße auf 90% zu verkleinern, wie es auch bereits in der englischen Wikipedia praktiziert wird. Dazu muss einfach folgendes aus Monobook.css übernommen werden:

 /* Einzelnachweise */
 ol.references {
	 font-size: 90%;
 }

Grüße --Carport ^{(Disk. • ± • MP)} 12:32, 13. Jun. 2010 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: hgzh 13:14, 19. Apr. 2022 (CEST)

Schriftgröße von absolut positionierten Elementen

Absolut positionierte Elemente wie Koordinaten können als Schriftgröße (font-size) keine relativen Längen wie em oder % enthalten, da sie Schriftgröße sonst von der Schriftgröße des Elternelemtents abhängen würden, die in einer Infobox kleiner sein kann, als außerhalb. Bei CSS3 gibt es mit rem eine relative Länge, die von der Schriftgröße des Wurzelelements abhängt. Der Firefox unterstützt das ab Version 3.6. Die derzeitige ungünstige pixelbasierte Schriftgrößenangabe für Koordinaten

#coordinates {
	line-height: 11px;
	font-size: 10px;
}

kann damit durch eine relative Schriftgrößenangabe ersetzt werden, die dann die Schriftgrößeneinstellung des Browsers beachtet.

Mit folgender CSS-Definition müssten Browser, die rem nicht verstehen, weiterhin die Pixelangaben bekommen, während Browser, die rem verstehen die besseren relativen Schriftgrößen anzeigen.

#coordinates {
	line-height: 1;
	font-size: 10px; /* Für Browser ohne rem */
	font-size: 0.625rem;
}

Der genaue rem-Wert sollte so gewählt werden, dass bei den üblichen Standardeinstellungen die Schriftgröße gleich ist wie bisher. --Fomafix 15:41, 28. Jul. 2010 (CEST)

Notiz: Die Längeneinheit rem funktioniert in Gecko >= 1.9.2 (Firefox >= 3.6), WebKit seit Juli 2009 und Internet Explorer >= 9. Opera 10.60 habe ich negativ getestet. Gruß --Entlinkt 03:54, 29. Jul. 2010 (CEST)

Opera unterstützt rem seit 11.60. --Fomafix (Diskussion) 14:16, 30. Dez. 2012 (CET)

Bei einer Standardschriftgröße der Browser von 16px und einer gewünschten Schriftgröße von 10px ergibt sich ein Faktor von 0.625rem. line-height: 1 bewirkt die Übernahme der Schriftgröße und reicht somit. --Fomafix 17:18, 29. Jul. 2010 (CEST)

Schrifttest:

• font-size: 0.625em; small big
• font-size: 0.625rem; small big
• font-size: 10px; small big
• font-size: 10px; font-size: 0.625rem; small big

--Fomafix 17:18, 29. Jul. 2010 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: hgzh 13:14, 19. Apr. 2022 (CEST)

Koordinaten stehen auf der Trennlinie

Von Wikipedia:Usability-Initiative/Softwarefehler hierher kopiert.

Hallo,
ich verwende Opera (genauere Daten folgen). Bei den Koordinaten in WP-Artikeln ist mir folgendes aufgefallen:

Browser-Information:

• Version: 10.63
• Build: 3516
• Plattform: Win32
• Betriebssystem: Windows XP
• XHTML+Sprache: IBM Multimodal Runtime Environment, Version: 4.1.3, Build: 20050506.01.1
• Browser-Identifikation: Opera/9.80 (Windows NT 5.1; U; de) Presto/2.6.30 Version/10.63

Ist etwas unschön… --Z1 23:02, 20. Nov. 2010 (CET)

Nachtrag: Ist der Artikel gesichtet, tritt dieser Fehler nicht auf. --Z1 23:07, 20. Nov. 2010 (CET)

Ende Kopie

Da es bei mir in FF und IE ordentlich aussieht, scheint es also ein Problem von Opera + absolut positioniertes Zeug oben rechts + Sichtungskram zu sein, in Benutzer:Z1/vector.css steht zwar viel, aber ich sehe nichts, was ich dafür verantwortlich machen könnte. --Schnark 09:27, 23. Nov. 2010 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: hgzh 13:14, 19. Apr. 2022 (CEST)

z-index: 0

Mit MediaWiki 1.25wmf12 ist nun gerrit:178086 mit

.mw-body-content {
	z-index: 0;
}

aktiv. Das hier lokal definierte

#content {
	z-index: 0; /* Schutz vor Spielchen mit "position: fixed", vgl. [[bugzilla:24667]] */
}

betrifft zwar das übergeordnete Element, aber das gewünschte Ziel müsste damit auch erreicht sein. Die lokale Definition kann daher meiner Meinung nach entfallen. --Fomafix (Diskussion) 10:02, 18. Dez. 2014 (CET)

Nach allem, was ich weiß, kann es leider nicht entfallen, weil

.mw-body-content {
	position: static;
}

implizit auch den z-index abschaltet.

Mein Testfall war seinerzeit die Seite Benutzer:Asthma. Die Links zur Beobachtungsliste etc. müssen auch dann klickbar bleiben, wenn man der positionierten Box einen hohen z-index gibt. --Entlinkt (Diskussion) 11:21, 6. Mär. 2016 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: hgzh 13:14, 19. Apr. 2022 (CEST)

Position der Benachrichtigungen

Wie ja auch auf der Vorderseite dokumentiert, führt unser CSS dazu, dass die Benachrichtigungen zu tief angezeigt wird. Hätte denn ein

body .mw-notification-area {
    top: 0;
}

irgendwelche negativen Nebeneffekte? –Schnark 10:48, 6. Apr. 2017 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: hgzh 13:14, 19. Apr. 2022 (CEST)