Wer sich meine Frontend-Projekte der letzten Monate genau anguckt, wird sicher schnell feststellen, dass ich etwas getan habe, was vor gar nicht langer Zeit ein Sakrileg gewesen ist: Ich habe feste Pixelangaben für den Schriftgrad verwendet!

»Steinigt ihn!«

höre ich die Kritiker rufen, denn es gibt immer noch eine weitverbreitete Unwissenheit in diesen Dingen. Ich versuche das mal zu erläutern.

Von ca. 2003 bis 2008 galt das Credo, dass nur em oder Prozente für Schriftgrad-Angaben tauglich sind. Diese Angaben haben die Eigenschaft, dass sie auf Unterelemente vererbt werden. Wenn ich also einer Seitenbox ein font-size: 0.8em; zuweise, dann wird sich ein normaler Textabsatz darin kleiner wiederfinden als ein Textabsatz in der Hauptspalte, obwohl beide Absätze möglicherweise mit font-size: 1em; gestylt wurden. Das Elternelement bestimmt also unter Umständen mit, welchen Schriftgrad das Kindelement haben soll.

So weit, so unpraktisch. In vielen Fällen führt diese Vererbungskiste nämlich zu schwierigen Situationen, insbesondere, wenn man mit »krummen« Basis-Schriftgraden arbeitet. Will man nämlich, dass Fonts in auf 13 oder 15 Pixel herausgerendert werden, kommt man sehr schnell in die Situation, mit vielen Nachkommastellen hantieren zu müssen, damit der Browser nicht mit »berechneten Größen« von 13.666 Pixeln hantieren muss. Das führt zu Rundungsfehlern, und das kann nicht schick sein.

Ich spare mir diese ganze Sache und sage dem Browser direkt, wieviele Pixel er (in der 100%-Zoomstufe) verwenden soll, was mir das Leben als CSS-Entwickler extrem viel einfacher macht. Das Missverständnis vieler Entwickler liegt nämlich darin, dass sie denken, ein CSS-Pixel ist identisch mit einem Hardware-Pixel des Bildschirms. Dem ist nicht so. Nur in der 100%-Ansicht des Browser sind die beiden Pixelwelten identisch. Sobald ich mit STRG + oder STRG – die Zoom-Funktion des Browser betätige, decken sich die beiden Pixelmatrixen nicht mehr und der Browser berechnet und rundet die erforderlichen Hardwarepixelmaße der Schriften für die jeweilige Zoomstufe.

Das ist alle logisch und klar. Doch warum galt der CSS-Pixel lange Zeit als verpönt? Der einzige Grund, der mir einfällt (man möge mich korrigieren *) ist die Unfähigkeit des Internet Explorer 6, Schriften zu vergrößern oder zu verkleinern, die in Pixeln definiert wurden. Denn der IE6 hat den CSS-Pixel 1:1 in den Hardwarepixel umgesetzt. Das führte zur Situation, dass vor allem Liebhaber von größeren Schriften (Sehbehinderte, Ältere und viele andere) keine Chance hatten, dem 10-Pixel-Wahnsinn der Herren Webdesigner zu entkommen.

Der IE 6 ist kein wirklich maßgeblicher Browser mehr, und wer ihn heute noch nutzt, ist selber Schuld. Diejenigen, die im IE 6 die Funktion zur Schriftvergrößerung gefunden haben, sind sicherlich auch in der Lage gewesen, den Update-Button zu finden. Heute arbeiten alle modernen Browser mit Seitenzoom, vergrößern also alle Seitenelemente nach Belieben. Es gibt keinen Grund mehr, auf Schriftgrößenangaben in einer Einheit zu verzichten, die innerhalb des Bezugssystems konstant ist. Und das ist nunmal die Pixelangabe.

(Warnung: Der Zeilenabstand line-height ist ein anderes Tier! Er sollte weder in Pixeln, noch in em, sondern ganz ohne Maßeinheit gesetzt werden, damit er stets abhängig von der Schriftgröße ist, egal, wie sich diese ändern mag. Zu den Rundungsfehlern beim Zeilenabstand mach ich dann nochmal einen eigenen Artikel…)

• Update: Aus den Kommentaren gefischt: Einige User stellen in den Browser-Grundeinstellungen eine Basis-Schriftgröße ein, die vom Standard-Wert 16 abweicht. Diese Einstellung wird bei der Verwendung von CSS-Pixeln tatsächlich übergangen. Davon nicht berührt ist jedoch die (weitaus üblichere) Seiten- oder Textskalierung. Diese funktioniert mit Pixeln und em gleichermaßen. Auf Spiegel Online kann man schön sehen, wie eine Kombination genutzt werden kann: Headlines und Fließtext wird abhängig von der Basis-Schriftgröße gerendert, aber Layout-kritische Dinge wie Navigationstexte in Pixeln gesetzt