Wikipedia Diskussion:Technik/Baustellen/Schriftgröße 100%

Neuer Dateiname / Dateiformat

Die Dateien wurden inzwischen verändert und verschoben, so dass nun in der Datei mediawiki/skins/MonoBook/resources/screen-common.less der font-size z. B. so geändert werden sollte, um den beschriebenen Effekt zu erzielen:

/* scale back up to a sane default */
div#globalWrapper {
	font-size: 140%;
	width: 100%;
	margin: 0;
	padding: 0;
	position: relative;
	z-index: 0;

=> Dadurch wird die Schriftgröße insgesamt etwas erhöht. --C rall (Diskussion) 20:58, 28. Dez. 2019 (CET)

Schönen Dank für das Rausfummeln der verschobenen Seite.

VG --PerfektesChaos 13:46, 29. Dez. 2019 (CET)

Aktuelle Diskussion

Es ist dringend notwendig, dass beim Leser / User die von ihm im Browser eingestellte Schrift buchstäblich "buchstabenweise zu 100%" an allen "Standardstellen" auftaucht. Dazu gehört:

• Fließtext
• Text in den Infoboxen
• Textbausteine

Bei angemeldeten Usern bedeutet "ankommen" die "Übergabe" an seine etwaige User-CSS.

• Absolute Einstellungen (Pixelwerte) in der User-CSS müssen auch ohne irgendwelche Tricks auch absolut Vorrang haben.

Es ist durchaus bereits eine Bevormundung, wenn man z.B. nicht angemeldeten Lesern einen verkleinerten Text als Standard serviert. Wir sollten dazu erst einmal den Status Quo zusammentragen und hier alle Schriftverändernden Nicht-Benutzer-Einstellungen auflisten. ÅñŧóñŜûŝî (Ð) 09:17, 17. Jun. 2013 (CEST)

Für eventuelle Mitleser hier die Erklärung, warum die Verkleinerung überhaupt gemacht wird: In den 90er-Jahren haben sich 16px als Browser-Defaulteinstellung herauskristallisiert (damals sah das Internet noch so aus, CSS gab es noch gar nicht), die meisten Benutzer ändern daran niemals etwas. Seitdem mit CSS anspruchsvollere Designs möglich sind, hat sich herausgestellt, dass die 16px als Default viel zu groß sind – siehe etwa Mozilla-Bug 51984.

Die Browserhersteller können jedoch den Default nicht mehr verkleinern, weil fast alle Webseiten die Schrift schon selbst verkleinern und es dann zu klein werden würde. Zudem wollen sie natürlich 100% kompatibel zu anderen Browsern bleiben. Deshalb gilt – wie so oft im Zusammenhang mit historischen gewachsenen Dingen – etwas, das man vielleicht unerwartet findet, aber einfach so ist: Die Einstellung im Browser ist nicht das, was man wirklich sehen wird, sondern wenn ich 16px sehen will, dann muss ich über die Einstellung meines Browsers mehr als 16px anfordern.

Und daran wird sich so schnell auch nichts ändern. Auf eine defaultmäßige Aufhebung der Verkleinerung wird sich niemand einlassen, weil die 16px Browserstandard als Default schlicht zu groß sind.

Was die Skins machen, ist der Versuch, einerseits bei unveränderter Browsereinstellung (das sind wie gesagt 16px und betrifft fast alle Leser) einen vernünftigen Wert (das ist in der Nähe von 13px) zu bekommen und zugleich halbwegs proportional zur Browsereinstellung zu bleiben. Die Alternative dazu wäre der fest verdrahtete Wert 13px, dann würde die Browsereinstellung überhaupt nicht mehr wirken (relativ viele Webseiten machen das übrigens tatsächlich, um zu verhindern, dass ihr Design durch verstellte Browser zerschossen wird). Wenn es eine bessere Möglichkeit gäbe, dann wäre auf die Idee in den letzten 15 Jahren wohl schon jemand gekommen. --Entlinkt (Diskussion) 12:39, 17. Jun. 2013 (CEST)

+1

• Bei den Leuten mit Augenproblemen kann man davon ausgehen, dass sie bereits versuchen, über Browser-Einstellungen die meisten häufig frequentierten Webseiten auf Anhieb ohne Nachregelung mit der Tastatur richtig dargestellt zu bekommen.
• Weiterhin soll die Verkleinerung unterhalb der Artikel-Grundschrift unabhängig von den Skins auf identisch Artikel-Grundschrift gebracht werden: Portal-Rahmen, Bildlegenden, REF-Inhalte. Die SMALL SUB SUP REF zwar kleiner, aber nicht zu klein; H1 H2 H3 H4 +BIG angemessen vergrößert. Das wäre die wesentliche Aktion.
• Die nächste Fragestellung ist es, ob die Artikel-Grundschrift identisch mit der Einstellung im Browser sein soll oder auf vielleicht 90 % reduziert; damit ein Mittelweg zwischen Original-px und den momentanen rund 80 %.
  • Es ist einfach ein Angebot für jemand, der kleinere Schriften nicht lesen kann. Und dem bei Wahl einer größeren Browser-Schrift dann wieder diverse andere Seiten um die Ohren fliegen, weil jetzt nur noch 30 Zeichen in jeder Zeile stehen.
  • Letztlich also ein Angebot für alle, die gemischt Seiten mit alter festverdrahteter Pixelzahl, verkleinerten 16px oder frei geerbten 100 % Browser-Einstellungen lesen und dabei Schwierigkeiten haben.
• Reines CSS wäre optionslos (alternativlos, sagt Mutti). Eine Variante, die per konfigurierbarer JS-Option leicht unterschiedliche Stile lädt, wäre noch wilder.
  • Parameter könnte beispielsweise eine relative Bezugnahme auf die Browser-Grundschrift oder feste Pixelzahl sein, während das Größenmischmasch von Portal-Rahmen, Bildlegenden, REF-Inhalte in jedem Fall auf Artikel-Grundschrift vereinheitlicht wird. JS kann aus mehreren festen Seiten mit konstanten Stilen laden, oder einen built-in CSS-Grundstring mit Platzhaltern on the fly optionsgemäß anpassen. Wir würden sogar Browser-Typ und etwas vom screen kennen und könnten regelbasiert die Unterstützung desselben Benutzers auf unterschiedlichen Endgeräten anbieten.
  • Da es nur noch 4 Skins sind, könnte man sogar einen Common-Builtin-String mit kleinen Skin-abhängigen Details kombinieren. Das lässt sich aber auch mit CSS anhand der BODY.skin-skin auseinandersortieren.
  • Ewiger Nachteil beim JS-Stil: Es kommt zu spät und ruckelt deshalb. Oder wird das Gadget so früh ausgeführt, dass das unbemerkt bliebe? Oder im Gadget schneller wirksames CSS mit nachgearbeiteter JS-Politur kombiniert.

Aber schön, dass sich auf dieser Baustelle etwas tut --PerfektesChaos 10:31, 18. Jun. 2013 (CEST)

Der folgende extrem simple Ansatz würde einfach die skineigene Verkleinerung aufheben und dafür sorgen, dass der Haupttext nach Browserstandard angezeigt wird:

/* Vector: inverse of 0.8em */
body.skin-vector {
	font-size: 1.25em;
}

/* Monobook: inverse of 127% */
body.skin-monobook {
	font-size: 78.74%;
}

/* Modern: inverse of 130% */
body.skin-modern {
	font-size: 76.92%;
}

Geht als Default natürlich gar nicht, als Gadget müsste man sich überlegen, ob es das ist, was man will oder doch etwas anderes. (Antonsusi scheint sowas wie dies zu wünschen.)

Die Proportionen der Elemente untereinander (Überschriften, Einzelnachweise usw.) würden so bleiben, wie sie sind, es wird einfach nur hoch- (bzw. nicht herunter-)skaliert.

Cologneblue ist m. E. nicht mit vertretbarem Aufwand anpassbar, weil die Schriftgrößen an zig verschiedenen Stellen festgelegt sind (und zwar in absoluten Einheiten). --Entlinkt (Diskussion) 18:01, 18. Jun. 2013 (CEST)

Der entscheidende Spagat ist es, für nicht angemeldete Leser/User bzw. User ohne eigene CSS-Seite und ohne Browser-Tuning muss eine in den meisten Fällen (Fließtext, Infobox etc.) passende Schriftgröße herauskommen, Benutzer, welche eine CSS-Seite erstellen, erwarten die exakte Umsetzung der dort eingetragenen Werte, sowohl absolut als auch relativ. Wer 36px reinschreibt, der soll sie auch zu sehen bekommen und wer 200% reinschreibt, der soll auch das doppelte seiner mittl. Browsereinstellung bekommen. Deshalb sind die vielen direktcodierten CSS-Angaben einfach störend. Es sollte mehr über CSS-Klassen laufen. ÅñŧóñŜûŝî (Ð) 19:01, 18. Jun. 2013 (CEST)

ÅñŧóñŜûŝî (Ð) 19:01, 18. Jun. 2013 (CEST)

Komplette Vererbungshierarchie in Vector und Monobook

Für alle, die detailliert verstehen möchten, was abgeht (und dies ist Voraussetzung für zielführende Änderungsvorschläge) hier die komplette Vererbungshierarchie bis zum Artikeltext in den beiden wichtigsten Skins.

Die Zahlen beziehen sich auf unveränderte Browsereinstellungen. Will man die Werte bei veränderten Browsereinstellungen nachrechnen, muss man natürlich bei Vector für medium und bei Monobook für x-small den entsprechenden Wert einsetzen.

/* VECTOR */
initial containing block {
	font-size: medium; /* Browsereinstellung, also in der Regel 16px.
                              "Initial containing block" ist kein Element,
                              sondern ein fiktives CSS-Konzept. */
}
html {
	font-size: 1em; /* 16px */
}
body {
	font-size: 1em; /* 16px */
}
div#content {
	font-size: inherit; /* 16px */
}
div#bodyContent {
	font-size: 0.8em; /* 12.8px */
}
div#mw-content-text {
	font-size: inherit; /* 12.8px */
}
	
/* MONOBOOK */
initial containing block {
	font-size: medium; /* 16px */
}
html {
	font-size: inherit; /* 16px */
}
body {
	font-size: x-small; /* Beachte, dass die Vererbungshierarchie an dieser
                               Stelle faktisch unterbrochen ist, denn "x-small"
                               hängt zwar monoton, aber nicht proportional von
                               der Browsereinstellung ab. Bei unveränderter
                               Browserinstellung werden dies 10px sein. */
}
div#globalWrapper {
	font-size: 127%; /* 12.7px */
}
div#column-content {
	font-size: inherit; /* 12.7px */
}
div#content {
	font-size: inherit; /* 12.7px */
}
div#bodyContent {
	font-size: inherit; /* 12.7px */
}
div#mw-content-text {
	font-size: inherit; /* 12.7px */
}

Besonders überraschend dürfte sein, dass Monobook die Schriftgröße für den Artikeltext nicht von medium, sondern von x-small ableitet. Dass der Zusammenhang zwischen diesen beiden nicht proportional ist, erklärt die merkwürdigen Sprünge beim Skalieren der Browsereinstellung. --Entlinkt (Diskussion) 16:25, 17. Jun. 2013 (CEST)

Letzteres ist m.E. kein guter Zustand. Da wird es Zeit, auf Medium umzustellen. ÅñŧóñŜûŝî (Ð) 15:58, 22. Jun. 2013 (CEST)

Wird lokal auf gar keinen Fall gemacht werden und wurde im MediaWiki-Core bereits abgelehnt – meiner Meinung nach zu Recht, weil es bei den wenigen Benutzern, die ihre Schriftgröße im Browser doch verstellt haben, das Aussehen der Wikipedia, an das sie sich gewöhnt haben, gravierend ändert.

Mit der Einführung eines neuen Skins wurde die Möglichkeit genutzt, diese Erblast aufzugeben (und das hat auch schon genug Beschwerden gegeben von wegen, warum sei die Schriftgröße in Vector anders als in Monobook), für Monobook bleibt es so. --Entlinkt (Diskussion) 16:10, 22. Jun. 2013 (CEST)