[CSS] Schriftgröße, em, rem, px

[kuromi]

Hallo

Ich arbeite derzeit an einem Theme und denke darüber nach mein bisheriges Verhalten - Schriften in em, Layoutelemente bevorzugt in px - zu ändern.
Genauer darüber nachgedacht, ergaben sich aber einige Fragen für mich.

Standardschriftgröße ist aktuell 16 px. So lernen wir das ja und so ist es bei den meisten Browsern voreingestellt. Daher schreiben auch viele Seiten zu dem Thema, dass sie, wenn sie mit px arbeiten im body die Schriftgröße mit entweder 100% oder eben 16 pixel festlegen. Auf der Größe basiert dann alles. Nun sollte man ja meinen, wenn die Schriftgröße mit 16 px allgemein definiert wird, dass Fließtexte, etc. dann auch in Schriftgröße 16 erscheinen. Das tut sie aber fast nie - die meisten Blogs und Websites, die ich jetzt gelesen habe und die sich zu dem Thema äußern nutzen ganz offensichtlich eine kleinere Schriftgröße. Ebenso würde ich behaupten, dass viele Websites im Netz mehr mit einer Schriftgröße wie z.B. hier im ngb arbeiten, was auch mein favorisierte Größe wäre.

Auf der anderen Seite gibt es Seiten/Blogs, die beginnen aus Berechnungsgründen mit einer Schriftgröße von 62.5% (was schon eher dem gängigen Erscheinungsbild entspricht. 10px), jedoch nur, um hinterher mittels em die Schriftgröße wieder auf 100% hochzusetzen. Es ging eben einfach nur darum, die em-Werte auf einer 10px-Basis einfacher berechnen zu können.

Und ich verstehe weder das Verhalten (beide Versionen) noch das daraus resultierende (scheinbar widersprüchliche) Ergebnis.

Der Grund, wieso ich mir darüber Gedanken mache teilt sich in zwei Punkte:

a) ich überlege die Einheit rem zu nutzen und bin unsicher auf welcher Basis ich beginnen soll - die einen empfehlen 62.5% (um es hinterher wieder hochzurechnen), die anderen gleich 100%. 100% sieht riesig aus [mein Browser (FF) hat die Standardeinstellung, also 16px] und mir erschließt sich nicht der Sinn, eine Schriftgröße anzugeben, die man hinterher fast nicht nutzt.

b) ich würde es gerne mal mit einem Theme versuchen, das sich an die eingestellte Schriftgröße und Auflösung anpasst. Allerdings bin ich auch unsicher, ob das überhaupt nötig ist bei Zoomfunktionen wie im Firefox, die ja die gesamte Seite zoomt, somit die Verhältnisse alle bestehen bleiben.

An die Webdesigner unter euch - welche Gedanken habt ihr euch dazu gemacht? Wie habt ihr euch entschieden? Habt ihr Empfehlungen?
Ich weiß, es gibt Tausende Diskussionen im Netz zum em vs. px Problem, dennoch würde ich gerne die Meinung der ngb User dazu lesen.

Danke für eure Zeit.

 

[LemonDrops]

Ums kurz zu machen. Die von dir angesprochenen Methoden sind veraltet. Entweder du benutzt Pixel, oder "rem", oder beides.

Ein guter Artikel dazu:

You do not have permission to view link please Anmelden or Registrieren

Ansonsten macht das, was dir am meisten liegt. Produktionsgeschwindigkeit ist das Wichtigste.

 

[accC]

Produktionsgeschwindigkeit ist das Wichtigste.

Würde eher sagen, dass das Wichtigste das Ergebnis ist. 100000 Seiten pro Tag in die Tastatur zu brügeln, die Schrott sind, mag zwar auch ein Geschäftsmodell sein, aber keines, das deine Kunden glücklich macht und letztlich auch keines, das der Webdesigner-Szene einen guten Ruf verschafft und der Ruf dieser Szene ist sowieso irgendwo im Keller anzusiedeln.

Ich arbeite mit px. Würde mich aber nicht als den top Designer des WWW bezeichnen.

Da du aber wohl häufig mit Frameworks arbeiten wirst, wenn du wirklich professionell Seiten umsetzt, empfehle ich dir, dich an deren Maßgaben zu halten, einfach um "das beste Ergebnis" zu erzielen.

 

[LemonDrops]

Ich bin kein Webdesigner, ich bin Entwickler. Designer haben gar nicht zu entscheiden, wie eine technische Umsetzung gemacht wird. Produktionsgeschwindigkeit bedeutet natürlich immer die Geschwindigkeit in der, unter den ausgehandelten Qualitätsstandards, etwas gemacht wird. Wenn man sich überlegt wie man eine Webseite entwickelt wird sind ggf. Dinge wie Barrierefreiheit relevant. Die Schriftgröße spielt dabei z. B. eine große Rolle, das muss aber auch bezahlt werden. Wenn dafür niemand bezahlt, gehe ich den Weg der am einfachsten für mich ist. Das würde ich auch jedem raten. Produkteigenschaften die extra Aufwand bedeuten kosten eben Geld, das ist überall so.

 

[kuromi]

@LemonDrops: Was meinst du mit veraltet? em, rem und px werden doch nach wie vor genutzt.
Und der Inhalt deines Links ist leider identisch mit den Inhalten der Seiten, die ich gelesen habe. Somit hilft der mir leider gar nicht.

Allgemein: Ich schreibe das Theme nicht für einen Kunden, sondern aktuell für mich privat.
Mir geht es tatsächlich um Barrierefreiheit. Bisher habe ich das bei Farbkombinationen berücksichtigt (Farbenblindheit, Kontrastprobleme, etc.), die Seite Screenreadertauglich gestaltet (jeder Abschnitt war benannt, Bilder hatten Beschreibungen und Bezeichnungen, etc.), valider Code, etc.. Bei der Einstellung der Schriftgröße habe ich aber immer nur etwas Spielraum gelassen und ansonsten darauf vertraut, dass die Leute im besten Fall die Zoomfunktionen der Browser nutzen, auch wenn das nicht unbedingt toll für die Grafiken ist. Das möchte ich dieses Mal anders versuchen.

Was ich für Kunden schreibe, hängt von deren Wünschen ab. Wollen die ne Website haben, die erst komplett geschrieben werden muss, biete ich Barrierefreiheit an und empfehle das auch. Für mich ist das meist kein zusätzlicher Aufwand und der Kunde selbst bemerkt die meisten Maßnahmen dazu hinterher ohnehin nicht. Es kann sich aber mit den Farbwünschen des Kunden beißen.
Anders sieht es aus, wenn ich einen Shop einrichten soll und die ein anderes Theme oder so möchten - da wäre angepasster Code hinsichtlich Barrierefreiheit ein ganz anderes Thema, falls diese (noch) nicht besteht.

Inzwischen habe ich mich allerdings entschieden und arbeite zwar weiter mit einer Kombination aus em und px, allerdings bisher 90% em. Also umgedrehtes Verhältnis. Aktuell kann man die Schriftgröße nach oben ändern, wie man möchte, das Layout wächst mit. Das gefällt mir. Es gibt bisher nur zwei Grafiken (Hintergrundgrafiken) - eine im Header (da ist kein Text enthalten) und eine für die Navbar (die habe ich bottom gesetzt und repeat-x). Durch die identische Hintergrundfarbe, muss sie so in keine Richtung gestreckt werden oder ist plötzlich zu klein für den Container. Sie sieht damit immer gleich aus, egal wie groß man die Schrift einstellt. Für die andere Grafik habe ich auch schon eine Idee - da der Container ja keinen Text enthält, würde der sich lediglich nach rechts vergrößern, nicht auch nach oben/unten.

 

[gelöschter Benutzer]

Ich nutze eine Basisgröße von Text in px und beschreibe Änderungen bspw. in

You do not have permission to view link please Anmelden or Registrieren

. Auch nutze ich CSS-Präprozessoren wie SASS oder LESS mit Libraries wie

You do not have permission to view link please Anmelden or Registrieren

, die dann nette Funktionen zum Umrechnen von px in (r)em bieten – da muss man dann manuell gar nichts mehr rechnen.

Anstatt überall ein Design px-genau umzusetzen, sollte man sich lieber Gedanken über die Anzeige auf Endgeräten machen. Hilft nichts, wenn überall die Schrift genau 12px hoch ist, aber dafür die Darstellung auf einem hochauflösenden Handy oder 4k-Monitor unlesbar ist. Außerdem sollte man darauf achten, den kleinen Geräten nicht zu viel Rechenarbeit zuzumuten, was bei einer mehrfachen Umrechnung von em-Werten (die sich ja auf das Elternelement beziehen) durchaus gegeben ist.

 

[kuromi]

@phre4k: Danke, die Antwort ist hilfreich für mich. Was die unterschiedlichen Gerätegrößen betrifft, das steht sowieso auch auf dem Plan. Da würde die Schriftgröße dann automatisch verringert, bei kleinerer Auflösung. Wer das nicht mag, kann sie aber eben genauso wieder vergrößern, das gesamte Layout bliebe dasselbe.

Bzgl. rem ist derzeit wohl der einzige Browser, der es nicht unterstützt

You do not have permission to view link please Anmelden or Registrieren

. Und der ist wiederum immer noch recht beliebt auf Smartphones & Tablets, wenn man

You do not have permission to view link please Anmelden or Registrieren

glauben darf.

 

[gelöschter Benutzer]

Du kannst ja statt REM einfach EM verwenden oder ein Fallback von REM zu EM. Fallback ist zwar etwas unsauber, aber wenn du erst den EM-Wert und dann den REM-Wert definierst, nehmen Browser die das können den REM-Wert und Browser die das nicht können ignorieren den.

 

[LemonDrops]

You do not have permission to view link please Anmelden or Registrieren

Mit veraltet meine ich, dass diese Methoden irrelevant sind und wenn du die Infos aus dem Artikel hast, solltest du selbst entscheiden können was zu tun ist. Die Schlussfolgerung ist, dass es mehr oder weniger egal ist was du tust.

Gerade bei dem was du unter "Barrierefreiheit" verstehst, ist es nicht wirklich wichtig, welche Methode du anwendest. Du schießt eh nur ins Blaue und löst ein paar allgemeine Probleme, die sich auch nicht sehr von einfachen SEO und Markup "Best practice" unterscheiden. Ohne eine Definition der Barrieren, die es nicht geben soll, kannst du keine "Barrierefreiheit" herstellen. Das ist der Grund aus dem richtig umgesetzte Maßnahmen zur Barrierefreiheit teuer sind. Man hat lange Checklisten die man erst definieren, dann abarbeiten und testen muss. Denn tatsächlich gibt es keine "Barrierefreiheit", man entscheidet nur welche Barrieren man aus dem Weg räumen möchte/muss.

In deinem Fall kannst du entscheiden was du willst. Willst du die maximale technische Kompatibilität und somit weniger Barrieren, oder willst du einen praktischen Weg, mit aktuellen Technologien nutzen, mit denen du ggf. Barrieren schaffst.

Hilft nichts, wenn überall die Schrift genau 12px hoch ist, aber dafür die Darstellung auf einem hochauflösenden Handy oder 4k-Monitor unlesbar ist..

Ein CSS-Pixel ist nicht gleich mit einem physikalischem Pixel.