Welche Font-Size verwendet eine Media-Query?

[Rolf B]

Hallo alle,

wenn ich im Browser die Default-Schriftgröße von 16px eingestellt und dazu dieses CSS habe:

html {
	font-size: 20px;
}
body {
	font-size: 24px;
}

@media (width > 50em) {
	body {
		background-color: green;
	}
}

und ich ziehe den Viewport langsam in die Breite - ab welcher Breite wird der Viewport grün?

1. ab 800px? (50em*16px)
2. ab 1000px? (50em*20px)
3. ab 1200px? (50em*24px)

Ich war mir nicht sicher, ob es 2. oder 3. ist und habe es ausprobiert.

Überraschung: es ist die 1! Font-Size Einstellungen im CSS haben auf @media-Abfragen überhaupt keinen Einfluss.

Es steht tatsächlich auch in der Spec:

Relative length units in media queries are based on the initial value, which means that units are never based on results of declarations.

Aber wen hat das jetzt außer mir noch überrascht?

Wenn man eine Viewportabfrage basierend auf der tatsächlich eingestellten Fontsize machen will – beispielsweise am body – , braucht man eine @container-Abfrage:

body {
	container: body-container / inline-size;
}

@container body-container (width > 60em) {
  ... 
}

Rolf

[Matthias Scharwies]

Guten Morgen,

Es steht tatsächlich auch in der Spec:

Relative length units in media queries are based on the initial value, which means that units are never based on results of declarations.

Aber wen hat das jetzt außer mir noch überrascht?

Mich!

Das muss ins Wiki!

…

Schneller Blick in die letzten Änderungen: Danke!

Herzliche Grüße

Matthias Scharwies

[MudGuard]

Hi,

Wenn man eine Viewportabfrage basierend auf der tatsächlich eingestellten Fontsize machen will – beispielsweise am body – , braucht man eine @container-Abfrage:

zumindest für die Schriftgröße aus dem HTML-Element müßte das doch auch mit rem gehen.

Und welchen Sinn hätte es, für html eine andere Schriftgröße als für body anzugeben?

head ist im Normalfall unsichtbar, also ist body das einzige Element, das direkt von der Schriftgröße in body beeinflußt wird.

Und wenn man head aus irgendeinem Grund doch sichtbar haben will, kann man die abweichende Schriftgröße auch für head statt für html angeben.

cu,
Andreas a/k/a MudGuard

[Matthias Scharwies]

Servus!

Hi,

Wenn man eine Viewportabfrage basierend auf der tatsächlich eingestellten Fontsize machen will – beispielsweise am body – , braucht man eine @container-Abfrage:

zumindest für die Schriftgröße aus dem HTML-Element müßte das doch auch mit rem gehen.

Und welchen Sinn hätte es, für html eine andere Schriftgröße als für body anzugeben?

Einfach, um zu schauen, wo der Wert der Schriftgröße herkommt.

Für html hätte man auch :root {}hernehmen können. Wie Rolf demonstrierte, ist es aber die vom Benutzer eingestellte Schriftgröße unter

Einstellungen>Allgemein>Schriftarten>Größe

Und das muss im Wiki (und im Forum) eben klar gemacht werden, dass Entwickler keine eigenen Dinger festlegen sollen, sondern ihre Seite so gestalten, dass die (Schriftgrößen)-Wünsche des Nutzers berücksichtigt werden.

Und wenn man head aus irgendeinem Grund doch sichtbar haben will, kann man die abweichende Schriftgröße auch für head statt für html angeben.

Darum geht es nicht.

Herzliche Grüße

Matthias Scharwies

[MudGuard]

Hi,

Und welchen Sinn hätte es, für html eine andere Schriftgröße als für body anzugeben?

Einfach, um zu schauen, wo der Wert der Schriftgröße herkommt.

ich meinte in der Realität, nicht für so einen Test.

cu,
Andreas a/k/a MudGuard

[Rolf B]

Hallo MudGuard,

in der Realität ist das sinnlos, da sind wir uns einig.

Im Wiki-Stylesheet stand allerdings sowas wie

html, body {
   font-size: 110%;
}

was dann - oh Wunder - zu einem um 21% vergrößerten Basisfont führte und was meine Frage auch erst auslöste.

Ich habe das jetzt auf 1.15rem (18.4px bei einer Standardfontsize von 16px) vereinheitlicht und muss zusehen, dass ich im weiteren Verlauf des Makeover den Font-Ringkampf der Stylesheets noch weiter beschwichtigt bekomme. Da sind eine Menge %-Angaben drin, die sich über mehrere Vererbungsstufen rauf- und wieder runterrechnen, das will ich - wo sinnvoll - auf rem standardisieren.

Wobei %-Angaben auch ihre Vorteile haben, weil sie sich automatisch dem Kontext anpassen. Ich bin nur nicht überzeugt, dass das aus heutiger Sicht immer sinnvoll genutzt wurde. Als das Wiki-Stylesheet entstand, war rem noch nicht so en vogue, ein IE10 war damals durchaus noch denkbar und wäre damit schlecht zurecht gekommen.

Rolf

[Gunnar Bittersmann]

@@Rolf B

Ich habe das jetzt auf 1.15rem (18.4px bei einer Standardfontsize von 16px) vereinheitlicht und muss zusehen, dass ich im weiteren Verlauf des Makeover den Font-Ringkampf der Stylesheets noch weiter beschwichtigt bekomme. Da sind eine Menge %-Angaben drin, die sich über mehrere Vererbungsstufen rauf- und wieder runterrechnen, das will ich - wo sinnvoll - auf rem standardisieren.

Wenn du da gerade dran bist, könntest du in Erwägung ziehen, die Typographie responsiv zu machen:

• Die Basisschriftgröße wächst mit der Viewportbreite. Natürlich nicht proportional, sondern bspw.

  html { font-size: calc(1em + 1vw) }
  

  Kleiner als 1em kann die Basisschriftgröße damit nicht werden. Nach oben kann man sie auch noch beschränken:

  html { font-size: min(1em + 1vw, 1.25em) }
  

• Die Zeilenhöhe hängt von der Satzbreite ab. Da man mit calc() (noch) nicht durch Längen dividieren kann, mit Mediaquery:

  html {
    line-height: 1.4;
  
    @media (width >= 40em) {
      line-height: 1.5;
    }
  }
  

• Verwendung einer Skala für Schriftgrößen, d.h. eines Faktors k.
  kleiner Text: Basisschriftgröße/k
  h3: Basisschriftgröße × k
  h2: Basisschriftgröße × k²
  h1: Basisschriftgröße × k³

  Der Faktor k hängt von Viewport ab. Bei kleinen Viewports sollte er nicht allzu groß sein; bei großen Viewports darf (sollte) der Unterschied der Schriftgrößen größer sein. Bspw.

  html {
    --font-scale: 1.2;
  
    @media (width >= 40em) {
      --font-scale: 1.25;
    }
  
    @media (width >= 60em) {
      --font-scale: 1.3;
    }
  }
  

Alles anzusehen in diesem Codepen.

Jolan tru

[Rolf B]

Hallo Gunnar,

es gibt so viele Ecken und Sonderlocken im Style, dazu Einflüsse von Vector (unser Basis-Skin) und auch die Legacy-Skins, die Mediawiki selbst einbindet, dass ich froh bin, wenn ich es überhaupt unter Kontrolle bekomme.

Aber die Idee werde ich im Hinterkopf halten. Es kann nicht schaden, eine Palette von einigen Basis-Fontsizes zu haben, diese alle auf 1rem zu beziehen und sie dann überall, wo eine font-size steht, einzusetzen.

Ob ich es wirklich gut finde, dass der Font bei größerem Viewport wächst, weiß ich nicht. Wenn ich das Fenster größer ziehe, dann will ich auch mehr sehen und will nicht, dass der Inhalt sich vergrößert und ich immer noch nicht mehr auf einmal sehe. Solchen Seiten bin ich schon begegnet, und es hat mich tierisch aufgeregt. Für plakative Dinge mag ein responsiver Font schick sein, für eine Doku eher nicht. Kennst Du eine Webseite mit größeren Textmengen, die so etwas tut und wo das brauchbar daher kommt?

Ich habe die genutzte Viewportbreite limitiert, und erst ab 40em schaltet er in die "Normal" Ansicht um, wo die Navigation links vom Artikel landet. Per Default hat man die "Schmal" Ansicht mit Navi unterm Artikel (was man sicherlich noch in ein Dropdown-Menu umbauen könnte), d.h. der variable Bereich ist gar nicht so groß. Auf schmalen Viewports möchte man auch eigentlich gar keine Fontskalierung, find ich, da ist man froh um jedes Zeichen mehr, das in die Zeile passt.

Das ist auch noch so ein Ding: Der Vector-Skin und damit auch der alte Selfhtml-Skin sind als Desktop-First erstellt, d.h. sie bauen mit max-width Angaben von breit auf schmal um. Ich möchte den Makeover-Skin aber Mobile-First haben. Da ist noch einiges zu richten. Zumindest aus unseren eigenen Styles sollen die max-width Queries raus.

Im Moment scheint mir der sinnvolle Ansatz dieser: wer größere Buchstaben wünscht, soll den Textzoom des Browsers verwenden. Wir verwenden bereits eine etwas größere Schrift als der Defaultfont angibt, so dass der Vergrößerungsbedarf sich in Grenzen halten sollte.

Rolf

[Der Martin]

Hallo,

Ob ich es wirklich gut finde, dass der Font bei größerem Viewport wächst, weiß ich nicht. Wenn ich das Fenster größer ziehe, dann will ich auch mehr sehen und will nicht, dass der Inhalt sich vergrößert und ich immer noch nicht mehr auf einmal sehe.

da habe ich schon sehr gegensätzliche Fälle erlebt. Der häufigere Fall ist bei mir tatsächlich der, dass ich die vom Autor mikroskopisch klein festgelegte Schrift gern in lesbarer Größe hätte, und nicht nur Fliegenschisse.

Das kann ich aber auch nicht über die Basis-Schriftgröße im Browser lösen, denn dann wird die Schrift auf anderen Seiten, wo der Autor ein Einsehen hat, plötzlich riesengroß.

Das Problem verfolgt mich aber nicht nur bei Webseiten, sondern auch bei Desktop-Anwendungen. Vor allem unter Windows sind die Defaulteinstellungen so winzig, dass ich in den Anzeigeeinstellungen erstmal die Basis-Skalierung auf 125% oder je nach Bildschirm sogar auf 150% hochsetze.

In früheren Windows-Versionen konnte man noch die Metriken sämtlicher GUI-Elemente frei einstellen - die Schriftgröße von Icon-Titeln, die Schriftart, Farbe und Größe in Fenster-Titelzeilen, Buttons oder Menüs. Leider alles wegrationalisiert. Man kann die Einstellungen noch in der Registry vornehmen (wenn's der Admin erlaubt), aber es gibt leider kein GUI mehr dafür.

Auf schmalen Viewports möchte man auch eigentlich gar keine Fontskalierung

Möchte man nicht? Auf meinem Handy habe ich auch die Default-Skalierung auf 125% gestellt, um das kleine Gefussel überhaupt einigermaßen lesen zu können. Ich verstehe nicht, wie sehr viele Leute eine etwa 2mm hohe Schrift überhaupt noch entziffern können.

Einen schönen Tag noch
 Martin

[Gunnar Bittersmann]

@@Rolf B

Ob ich es wirklich gut finde, dass der Font bei größerem Viewport wächst, weiß ich nicht. Wenn ich das Fenster größer ziehe, dann will ich auch mehr sehen und will nicht, dass der Inhalt sich vergrößert und ich immer noch nicht mehr auf einmal sehe.

Ich sagte doch: „nicht proportional“. Wenn bei größerem Viewport die Schrift geringfügig größer ist, bekommst du immer noch mehr zu sehen als auf kleinem.

Kennst Du eine Webseite mit größeren Textmengen, die so etwas tut und wo das brauchbar daher kommt?

Ja, klar: Tagesspiegel. Da allerdings nicht stufenlos, sondern mit Mediaquery umgesetzt. Vielleicht ändern wir das noch mal.

Jolan tru

[Rolf B]

Hallo Gunnar,

Tagesspiegel

ja, mit ähnlicher Überlegung wie bei mir.

@media (min-width: 62.5em) {
    .tspA4h4 .tspA4ii {
        font-size: 18px;
    }
}
@media (min-width: 48em) {
    .tspA4h4 .tspA4ii {
        font-size: 16px;
    }
}

.tspA4h4 .tspA4ii {
    font-size: 18px;
}

Merkwürdige Skala.

Unter 48em: Groß, ist das die Unterstellung, dass das ein Mobilgerät ist und auf dem Winzbildschirm eh alles viel zu klein aussieht?

Ab 48em wird verkleinert. Desktop mit „anständigen“ 96dpi, aber zu wenig Platz?

Ab 62.5em 🤣 dann wieder groß. „Ahh – jetzt ist Luft!“

Und warum zum Geier legt ihr die Fontsize in px fest?! Ich habe von einem gewissen G. aus B. gelernt, dass das pöse ist.

Rolf

[Gunnar Bittersmann]

@@Rolf B

Merkwürdige Skala.

Ja, da kucken wir gerade nochmal drüber.

Und warum zum Geier legt ihr die Fontsize in px fest?!

Hm, wir haben ein PostCSS-Plugin, dass px im Quelltext in rem umrechnet. Bei den Schriftgrößen passiert das nicht; muss ich mir mal ansehen.

einem gewissen G. aus B.

Nicht zu verwechseln mit einem gewissen Maik W. aus E.

Hach, nicht mehr lange, und wir sind wieder auf Klassenfahrt am selben Ort.

Jolan tru

[Der Martin]

Hi,

html, body {
   font-size: 110%;
}

was dann - oh Wunder - zu einem um 21% vergrößerten Basisfont führte

das ist aber doch exakt das, was man dann intuitiv^[1] erwarten müsste: Die Schrift für das html-Element ist 10% größer als die Basis-Schrift; die des body-Elements ist nochmal um 10% größer als die des Elternelements. Macht rechnerisch 21%. Reine Multiplikation.

Einen schönen Tag noch
 Martin

---

1. Einer der wenigen Fälle, wo CSS mal zu meiner Intuition passt. Meistens eher nicht. ↩︎

[Gunnar Bittersmann]

@@Der Martin

das ist aber doch exakt das, was man dann intuitiv erwarten müsste: Die Schrift für das html-Element ist 10% größer als die Basis-Schrift; die des body-Elements ist nochmal um 10% größer als die des Elternelements. Macht rechnerisch 21%. Reine Multiplikation.

Ähm, nein. Wenn du mit Vergrößerung um x% rechnest, ist das nicht nur reine Multiplikation, sondern auch noch Addition/Subtraktion. 😜

Jolan tru

[Der Martin]

Hallo,

das ist aber doch exakt das, was man dann intuitiv erwarten müsste: Die Schrift für das html-Element ist 10% größer als die Basis-Schrift; die des body-Elements ist nochmal um 10% größer als die des Elternelements. Macht rechnerisch 21%. Reine Multiplikation.

Ähm, nein. Wenn du mit Vergrößerung um x% rechnest, ist das nicht nur reine Multiplikation, sondern auch noch Addition/Subtraktion. 😜

ds wäre mir neu. Nach meiner Schulbildung ist "10% mehr" eine populärwissenschaftliche Formulierung für "um den Faktor 1.10 mehr".

Das ganze zweimal angewendet, und ich bin bei "um den Faktor 1.21 mehr".

Einen schönen Tag noch
 Martin

[Rolf B]

Hallo Gunnar und Martin,

hört doch auf, euch gegenseitig zu trollen.

Übrigens war mir diese doppelte Skalierung durchaus klar. Bei dem „Oh Wunder“ fehlte wohl das Ironie-Tag…

Rolf

[Gunnar Bittersmann]

@@Der Martin

Ähm, nein. Wenn du mit Vergrößerung um x% rechnest, ist das nicht nur reine Multiplikation, sondern auch noch Addition/Subtraktion. 😜

ds wäre mir neu. Nach meiner Schulbildung ist "10% mehr" eine populärwissenschaftliche Formulierung für "um den Faktor 1.10 mehr".

Nö. Streich da das „mehr“: „um den Faktor 1.1 (skaliert/vergrößert)“.

Und da hast du die Addition: 10% + 100% = 1.1

Das ganze zweimal angewendet, und ich bin bei "um den Faktor 1.21 mehr".

Streich da das „mehr“.

Und da hast du die Subtraktion: 1.21 − 1 = 21%

Jolan tru

[Gunnar Bittersmann]

@@Rolf B

[…] und habe es ausprobiert.

Und hast deinen Versuch nicht publik gemacht‽

Musste ich dann nochmal nachbauen: https://bittersmann.de/test/breakpoint

Wenn man im Browser zoomt, bspw. auf 150%, dann erfolgt die Umschaltung immer noch bei 800px; nur dass ein CSS-Pixel dann anderthalbmal so groß ist.

Wenn man die Basisschriftgröße in seinen Browsereinstellungen ändert, bspw. auf 24px, dann erfolgt die Umschaltung bei 1200px.

Jolan tru

PS. Ich habe schwarz/weiß statt rot/grün gewählt. Wegen Rot/grün-Blindheit.

[Rolf B]

Hallo Gunnar Bittersmann,

Sorry. Wollte ich eigentlich. Ist aber alles andere als schick und eigentlich nicht vorzeigbar...

Beispiel:Media-Query-Und-Font.html

Aufruf

Rolf