Webtypografie und hochauflösende Bildschirme
Retina-Bildschirme und das Pixel als Maßeinheit
Wie hat sich der marktübliche Schriftgrad im Webdesign im Laufe der Jahre verändert, und wie hängt das mit den immer hochauflösenderen Bildschirmen zusammen? Die modernen Retina-Displays lassen uns ganz neu über Skalierbarkeit und die Sinnhaftigkeit des Pixels als Grundlage allen Screendesigns nachdenken.
Dieser Beitrag ist ein Auszug aus dem #webtypobuch von Gerrit van Aaken, das seit Dezember 2012 online erhältlich ist. Alle Infos zum Buch findet ihr auf webtypobuch.de.
Seit es Computermonitore im freien Handel gibt, ist deren Pixeldichte langsam aber stetig gestiegen. Zu Beginn der Desktop-Publishing-Revolution, Mitte der Achtzigerjahre, waren es noch die berühmten 72 ppi (pixel per inch), die bei professionellen Layoutbildschirmen dafür sorgten, dass ein einzelnes Pixel genauso groß war wie ein Typografischer Punkt, nämlich 0,35 × 0,35 mm. Das hatte den pragmatischen Vorteil, dass man Drucksachen tatsächlich in physischer Originalgröße am Bildschirm entwerfen konnte (Ausdrucken war teuer), und eine 12-Punkt-Helvetica am Bildschirm mit 12 Pixeln dargestellt wurde. So ließ es sich leichter rechnen.
Später kletterten die Bildschirmauflösungen dann locker über die 100er-Grenze, bis hin zu besonders protzigen Geräten mit bis zu 150 ppi. Letztere vor allem bei hochpreisigen Windows-kompatiblen Laptops Mitte der Nullerjahre, zum Beispiel ein Dell Dimension mit 15,4" Bildschirmdiagonale und 1.920 × 1.200 Pixeln. Viel höher jedoch konnte die Pixeldichte dann nicht mehr werden – zumindest nicht ohne Quantensprung. Und zwar weniger aus technischen, sondern aus konzeptionellen Gründen; das Problem an kleineren Pixeln ist nämlich, dass nicht nur die einzelnen Pixel im Vergleich schrumpfen, sondern mit ihnen alles, was aus ihnen gebildet wird. Und das ist zum großen Teil Text, der von menschlichen Augen gelesen werden soll. Eine heikle Angelegenheit, denn die gleiche 11-Pixel-Arial, welche auf dem 112-ppi-Monitor noch einigermaßen gut zu erkennen ist, kann auf einem 147-ppi-Monitor schon zu winzig sein, um sie ohne Lesebrille entziffern zu können; eine deutlich erhöhte ppi-Zahl führt bei sonst gleichbleibenden Parametern zu deutlich kleinerer Schriftdarstellung.
Die Webdesignwelt hat glücklicherweise darauf reagiert und in den letzten sieben bis acht Jahren die früher üblichen 11 oder 12 Pixel großen Fließtexte schrittweise zu den heute eher üblichen 14 bis 16 Pixeln transformiert. Damit einher ging auch die maximal empfohlene Layoutbreite von anfangs 640 Pixeln über später 800 Pixel auf heute 1024 Pixel. (Einige verwegene Webdesignkollegen versuchen es zwar inzwischen auch mit 1280 Pixeln oder experimentieren gar mit absichtlich horizontal scrollenden Inhalten, doch davor rate ich im Allgemeinen ab.)
Diese Anpassung des marktüblichen Leseschriftgrads an die steigenden Auflösungen der Monitore geht natürlich nur dann gut, wenn sich das Ganze über mehrere Jahre hinweg langsam entwickelt. Doch was passiert, wenn ein Hardware-Hersteller auf einmal nach vorne prescht und die Auflösung eines Gerätes auf einen Schlag, sagen wir: verdoppelt? Nun. Apple hat im Jahr 2010 genau das getan und mit dem iPhone 4 einen Bildschirm am Markt platziert, der statt 163 ppi satte 326 ppi darstellen konnte. Also für jeden Pixel des Vorgängerscreens vier Pixel auf dem neuen Screen – denn die Verdoppelung der Auflösung bezieht sich ja auf beide Richtungen, horizontal und vertikal.
Wenn Apple bei diesem Quantensprung das Gleiche getan hätte wie bei der bisher üblichen Evolution, stünden die Dinge in Sachen Lesbarkeit nicht zum Besten. Eine 12-Pixel-Arial wäre dann nämlich so außerordentlich winzig, dass wahrscheinlich selbst kerngesunde Teenager mit 120 % Sehkraft eine Lupe benötigten.
Statt dessen griff Apple zum einzig sinnvollen Trick und verdoppelte nicht nur die Auflösung, sondern auch die dargestellte Pixelanzahl aller angezeigten Elemente. Unsere 12-Pixel-Arial wird automatisch zu einer 24-Pixel-Arial, die dann den gleichen physischen Platz einnimmt wie früher, mit dem Unterschied, dass sie aus mehr Geräte-Pixeln besteht und von daher viel schärfer und detailreicher ist.
Damit wir uns nicht falsch verstehen: Die Entwickler von Apps und Websites müssen nichts an ihren Stylesheets ändern! Statt dessen nimmt man bei diesen hohen Auflösungen eine Trennung zwischen der virtuellen und der physischen Auflösung vor. Etwas vereinfacht gesprochen behauptet das iPhone intern weiterhin, nur 320 × 480 statt der tatsächlichen 640 × 960 Pixel zu besitzen. Man rechnet als Designer auch weiterhin in den kleineren Größen, nennt das Pixel dann aber bisweilen Punkt/Point, oder auch logisches Pixel. Erst sobald es an die konkrete Darstellung geht, verwendet das Betriebssystem die zusätzlichen Hardwarepixel dafür, Schriften und Grafiken schärfer und detailreicher zu machen.
(Über die fachgerechte Bespielung von hochaufgelösten Bildschirmen, auch über typografische Gesichtpunkte hinaus, hat Frontend-Guru Thomas Fuchs mit »Retinafy Me« ein empfehlenswertes E-Book geschrieben: retinafy.me)
Dieses Prinzip hat das Potenzial, einiges auf den Kopf zu stellen – auch und gerade im Webdesign. Denn in Zukunft wird es immer mehr sogenannte High-PPI-Bildschirme geben, bei denen ein 1:1-Verhältnis zwischen Software- und Hardware-Pixel nicht mehr sinnvoll ist. Genau genommen hat es auch in der offiziellen CSS-Spezifikation nie eine zwingende Übereinstimmung zwischen Hardware-Pixel und CSS-Pixel gegeben. Es war nur viele Jahre so, dass ein font-size:14px;
fast immer zu einer in 14 Pixeln dargestellten Schrift geführt hat. Jetzt ist das immer häufiger nicht mehr der Fall.
Entwickler für die Smartphone-Plattform Android kennen diese zusätzliche Abstraktionsebene übrigens schon ein wenig länger. Bereits in recht frühen Versionen von Googles Smartphone-Betriebssystem gab es den Density-Faktor, der von einer Basis-Auflösung 160 ppi ausgeht und für jedes Hardware-Gerät einen ausgleichenden Wert annimmt. Android-Telefone mit 120 ppi erhalten einen Density-Wert von 0.75, während ein 320-ppi-Gerät (analog zum Retina-Display des iPhones) eine Density von 2.0 erzeugen würde. Wenn man diesen Faktor brav beachtet, bleiben die physischen Größenverhältnisse der Bedienelemente ungefähr gleich, was für die Touch-Bedienung mit dem Finger nicht ganz unwichtig ist. Die Darstellungqualität hingegen verbessert oder verschlechtert sich eben je nach Displaydichte.
(Kleine Anmerkung für die nerdigen Leser: Die Sache mit dem Viewport-Zooming auf Smartphone-Browsern lasse ich an dieser Stelle aus, weil es meine Erläuterung unnötig kompliziert machen würde. Aber: Ja, das käme als weitere Abstraktionsschicht potenziell auch noch hinzu.)
Obwohl also das Konzept der Virtuellen Auflösung zum ersten Mal bei den Smartphones in größerem Stil eingesetzt wurde: Die Idee der Auflösungsunabhängigkeit geistert auf Computern mit klassischen Betriebssystemen (Windows/Mac OS) auch schon sehr lange durch den Raum, ohne bisher jemals tatsächlich konsequent umgesetzt und vermarktet worden zu sein. Und irgendwo verspüren viele Webdesigner auch keinen besonderen Drang, es tatsächlich einzufordern, denn eine Unsicherheit bezüglich der virtuellen und physischen Auflösung erschwert natürlich die bequeme pixelbasierte Planung und Umsetzung, wie man sie seit Jahren gewohnt ist. Im Zweifelsfall werden die Pixelkonstrukte beim Endkunden verkleinert oder vergrößert dargestellt, dadurch unscharf oder komisch gekrümelt, je nach Density-Wert. Nicht nur Auftraggeber hätten damit Probleme.
Doch der Trend geht trotzdem ganz klar weg vom klassischen Pixel, dessen Breite man »irgendwo zwischen 0,2 mm und 0,3 mm« ansiedeln konnte. Das Hardwarepixel wird heutzutage immer kleiner, flexibler und unberechenbarer, und damit letztlich auch immer unwichtiger, zumindest als Einheit zum Rechnen und Layouten. Es lohnt sich im Gegenzug mehr denn je, auf Vektorgrafiken und -fonts zu setzen, wo immer es geht, und auf Pixelgrafiken für Layoutelemente möglichst zu verzichten!
Noch sind wir allerdings nicht so weit, das Pixel vollständig vernachlässigen zu können, denn es gibt mehr als genug konventionelle Bildschirme, auf denen man sehr wohl unscharfe Halbpixelkanten erkennen kann, welche bei der Skalierung von Vektorformen oftmals entstehen. Man beachte insbesondere die untere Kante des 40-Pixel-Icons (ganz rechts):
Bei der Produktion von Icon-Sets – ob vektorbasiert oder nicht – verwenden professionelle Screendesigner nach wie vor ein 32er- oder 48er-Raster, um solche Nebeneffekte zu reduzieren. Aber in ein paar Jahren, so glaube ich, wird unseren Kindern der Pixelfetischismus im Webdesign der Nuller- und Zehnerjahre ähnlich lustig erscheinen wie uns die drolligen Pixelklötzchen der 8-Bit-Games aus den Achtzigern.
Kommentare
Tobias Scheible
am 19.12.2012 - 09:19
Sehr interessanter Artikel. Ich hab mich bei meinem neuen Layout für meinen Blog auch mit der Problematik beschäftigt. Und zwar war mein Ziel die echte Auflösung voll zu nutzen, ohne die künstliche Verdoppelung durch das Betriebssystem. Mit dem Viewport-MetTag kann man die Anweisung geben das eben dieser Effekt nicht angewendet wird:
<meta name="viewport" content="width=device-width, target-densitydpi=device-dpi">
Eine sehr spannende Sache ein Layout von einer Breite von 320 (iPhone 3) bis 2560 (Nexus 10) zu erstellen. Für die Geräteerkennung musste ich dann auf die Lösung Mobile-Detect zugreifen, da ich ja über die Auflösung die Geräte nicht mehr identifizieren konnte ;-)
Andy Pillip
am 19.12.2012 - 11:39
Sollten wir dazu übergehen, in tatsächlichen physikalischen Größen (cm, inch) zu designen/stylen?
1. Das W3C hat in CSS3 fast alle absoluten Größen auf physikalische Größen bezogen:
Alles lässt sich also in inch oder cm umrechnen, 1 px ist zum Beispiel 1/96stel von einem inc, also 0,26458 mm (gemäß Standard).
2. Gestalten wir zunehmend Oberflächen zum Anfassen (Touch-Bildschirme), die physikalische Größe ist also extrem wichtig.
Was meint ihr?
Gerrit van Aaken (Autor)
am 19.12.2012 - 11:47
Klappt meines Erachtens nur bei flächendeckender Retina-Auflösung. Auf den niedrig aufgelösten Bildschirmen sind die "Rundungsfehler" bzw. Pixelkanten noch zu hässlich, als dass man den Pixel jetzt schon außer Acht lassen könnte. Und bei der Rechnung in absoluten physischen Längenangaben kommt es unweigerlich zu Pixelunschärfen, wie oben im Beispiel demonstriert.
Lass uns in drei oder vier Jahren darüber nochmal sprechen :-)
Tekl
am 19.12.2012 - 16:42
Ein inhaltlich wie auch sprachlich toller Beitrag über ein Thema, das sich so nebenher einschlich.
Wie schön wäre es, wenn man flächendeckend in mm/pt arbeiten könnte und überall würde es exakt dargestellt.
Ich habe mich aber sehr gewundert, dass Apple die auflösungsunabhängige Oberfläche an den Nagel gehängt hat und auf Pixelverdopplung setzt.
Lilli
am 19.12.2012 - 20:25
Ich habe ein Notebook mit höherer Pixeldichte (166dpi) und dort werden die Pixel nicht in virtuelle Pixel umgerechnet. Das Ende der Geschichte ist, mein System funktioniert super, weil ich dort die Schriftgröße festlegen kann, im Browser habe ich die Grundschriftgröße angehoben, muss mich jetzt aber leider mit Webseiten rumärgern, welche die Schrift in Pixel festzurren. Dort muss ich nämlich manuell per Seitenzoom korrigieren, das nervt und leider sind es viele Seiten. Noch viel trauriger ist, dass selbst viele gute Webworker nicht einsehen warum Pixel für das Web einfach untauglich sind (zumindest was die Schriftgröße angeht).
Gerrit van Aaken (Autor)
am 20.12.2012 - 08:33
Ein wichtiger Aspekt, der leider im Artikel und im Buch nicht ausreichend beleuchtet wird. Ich werde das ändern.
Nicolai Schwarz (Webkraut)
am 20.12.2012 - 08:56
Das ist mal ein gutes Argument gegen Pixel-Angaben. Überzeugt mich mehr als das reine Barrierefreiheits-Argument (bzgl. Desktop-Zoom). Weiß denn jemand, wie häufig das vorkommt? Machen das mehrere Notebooks so – oder »nur« ein paar Außenseiter?
Jens Grochtdreis (Webkraut)
am 20.12.2012 - 09:08
Das scheint mir doch eher ein Problem des Gerätes zu sein. Muss ich jetzt auch noch neben den Fehlern der Browser auf die Fehler einzelner Gerätehersteller eingehen? Und was machen dann die Nutzer von Geräten mit ähnlichen technischen Rahmenbedingungen, bei denen die virtuellen Pixel anders gehandhabt werden? Nee, irgendwann ist Schluss.
Markus Gans
am 20.12.2012 - 10:51
Ich denke nicht, daß es sich hier um ein fehlerhaftes Gerät handelt. Vielmehr scheint es sich hier schlicht um ein PC-Notebook mit Windows oder Linux zu handeln und nicht um einen Rechner mit einem Betriebssystem von Apple oder Google, wo hohe PPI-Auflösungen von Hause aus unterstützt werden.
Jens Grochtdreis (Webkraut)
am 20.12.2012 - 12:02
Ich meinte auch nicht, dass das Gerät fehlerhaft ist. Wir haben nunmal eine grosse Auswahl an Endgeräten und Browsern. Da gibt es am Ende nicht die EINE Lösung. Ich hoffe darauf, dass wir die Eigenarten der einzelnen Geräte möglichst gut identifizieren und per Media-Query bzw. JavaScript darauf reagieren können. Oder wir lassen unsere Designs einfach mal sich selber anpassen :-) Ich weiss, dass dieser Ansatz bei Designern und Kunden nicht beliebt ist, aber er entspricht der Realität.
Paul
am 21.12.2012 - 01:14
Es handelt sich nicht um ein fehlerhaftes Gerät. Allerdings muss man sich vor Augen halten, dass man zusätzliche Zeit benötigt, solche Probleme mit "Sonderfällen" zu beseitigen. Die Frage ist, ob der Kunde bereit ist, dafür mehr zu bezahlen. Ich würde sagen, das hängt stark vom Projekt und der Zielgruppe ab.
Lilli
am 21.12.2012 - 09:29
Was heißt Schluss? Du musst lediglich die richtige Einheit für die Schriftgröße wählen, nämlich em (oder in Zukunft rem, wenn du keine Vererbung haben möchtest). Damit bist du dann komplett unabhängig vom Endgerät und der Nutzer kann sogar seine Vorliebe in Form der Grundschriftgröße im Browser einstellen.
Deinem Beitrag weiter unten entnehme ich, dass du Pixel wählst, weil es für dich einfacher ist, nicht weil es die beste Lösung für den Benutzer ist. Das finde ich sehr schade und hoffe du überdenkst deine Meinung noch einmal.
Jens Grochtdreis (Webkraut)
am 21.12.2012 - 09:59
Ich nutze em im Wesentlichen nicht, weil ich die Multiplikationseffekte fürchte und Rundungsfehler bei Browsern nicht ganz ausschliessen kann. Die Einheit rem ist sicherlich ideal, doch damit ich diese nutze müssen erstmal die alten IE aussterben.
Ich werde demnächst mal schauen, ob ich mit Sass sicher und schnell auch in em auszeichnen kann. Mein aktuelles Projekt ist leider ohne Sass und sowieso schon eine Hölle. Da würde die Verwendung von em das Chaos nur vergrößern und uns zuviel Zeit kosten.
Der Nutzer braucht in meinen Augen em oder Prozent nur, wenn er nicht den Seitenzoom nutzt. Doch das ist eine bewusste Entscheidung über dessen Konsequenzen sich jeder im Klaren sein sollte. Oder?
Übrigens meinte ich mit "irgendwann ist Schluss" schlicht und ergreifend, dass ich als Entwickler nicht alle Fehler und Sonderverhalten abfangen kann. Das macht keinen Sinn. Und es bezahlt niemand. Es ist manchmal auch schlicht unnötig.
Lilli
am 21.12.2012 - 10:36
Der Seitenzoom ist schlicht kein Ersatz für die Anhebung der Grundschriftgröße. Den Seitenzoom muss ich bei jeder besuchten Seite wieder manuell einstellen, die Grundschriftgröße wirkt automatisch bei neu geöffneten Seiten.
Ich denke das mit dem „Schluss“ habe ich schon richtig verstanden, bloß stellt sich das Problem der Sonderverhalten gar nicht erst wenn man mit em arbeitet. Daher verstehe ich nicht was so schlimm daran ist auf die Vererbung zu achten, wenn das Resultat danach Geräteübergreifend funktioniert.
Es freut mich jedenfalls, dass du dir des Problems bewusst und offen für eine Lösung in der Zukunft bist.
Dirk
am 27.12.2012 - 21:46
Nur als Ergänzung: Chrome merkt sich den Zoomfaktor für jede einzelne Seite.
Lilli
am 24.01.2013 - 07:29
Das ist für bereits besuchte Seiten richtig, das tut Firefox auch. Bei neuen Seiten greift das allerdings (logischerweise) nicht, da wird jede Suche zur Nervenprobe.
Paul
am 21.12.2012 - 01:11
Wenn du vielen Websites begegnest, die einen zu geringen Schriftgrad haben und du sowieso schon die Standard-Schriftgröße angepasst hast, warum legst du nicht auch gleich die "minimale Schriftgröße" (Firefox) bzw. die "Mindestschriftgröße" (Chrome) fest? Soweit ich dein Problem verstanden habe, sollte das genau die Lösung dafür sein.
Lilli
am 21.12.2012 - 09:46
Das ist für mich leider keine Option. Wenn ich die minimale Schirfgröße so weit anhebe, dass die Schrift gut lesbar ist, dann habe ich überhaupt keine unterschiedlichen Schriftgrößen mehr. Marginalien, Footer, Fließtext und Überschriften sind dann auf den meisten Seiten alle gleich groß, da wird es extrem schwierig die wesentlichen Inhalte schnell zu erfassen.
Jens Grochtdreis (Webkraut)
am 20.12.2012 - 08:38
Warum sollten wir denn mit mm/pt designen? Das widerspricht doch dem Medium. Anhand der Retina-Displays sehen wir doch gerade, dass solche Längenmasse unpassend sind.
Pixel ist in meinen Augen exakt das richtige Mass. Eventuell benötigen wir noch ein paar Umgebungsvariablen mehr, um mit den Pixeln noch effektiver umgehen zu können. Aber das lässt sich ja lösen. Im iOS-Bereich ist Apple ja auch nicht so träge wie beim Desktop-Safari und kann eventuell noch Verbesserungen nachschieben.
Ich persönlich habe es immer gehasst, wegen des IE6 meine Seiten in em auszeichnen zu müssen und freue mich, Pixel nutzen zu können. Die standardmässige Skalierungsmethode in allen Browsern skaliert schliesslich Seiten komplett. Und ich muss mir den Kopf nicht zermartern, ob ich eventuell Multiplikationseffekte zu bedenken habe.
Ich empfinde Pixel nicht als untauglich. Im Gegenteil, sie sind sehr tauglich. Sie sind zudem eine dem Medium angepasste Masseinheit. Sie sind auch eine relative Masseinheit, denn schliesslich wurden bei Retina-Displays nicht die Display selber vergrössert, sondern nur die Anzahl der darstellbaren Pixel. Pixel ist ergo ein relatives Mass. Und die IE6-Zeiten sind glücklicherweise vorbei.
Tekl
am 20.12.2012 - 13:15
Das mit den unterschiedlichsten Pixeldichten und wie Apple damit umgegangen ist zeigt doch das Problem. Ein Pixel ist überhaupt nicht mehr vorhersehbar. Gerade bei Touch-Oberflächen ist die reale Größe von Schaltflächen ja extrem wichtig, damit es bedienbar bleibt und gerade da wäre doch eine mm-Angabe ideal, um einen Button immer gleich groß und „treffsicher“ zu haben.
Aber bei mm/pt im Allgemeinen muss ich dir recht geben, das ist für's Webdesign nicht optimal. Dennoch wäre es schön, wenn mm und pt funktionieren und ggf. einen benutzerdefinierten Zoom-Faktor berücksichtigen würde.
Marc Haunschild
am 20.12.2012 - 22:08
Entschuldige mal bitte, aber Seitenzoom führt fast immer zu einer Vergrößerung über den viewport hinaus. Es sei denn das Layout ist liquid und responsiv. Und die responsiven Breakpoints werden in em angegeben. Und wenn eh em nötig sind, dann kann man die auch gleich durchgehend anwenden. Probleme mit der Vererbung lassen sich meist dadurch umgehen, dass Schriftgrößen nur Blockelementen zugewiesen werden, die nur inline-Elemente enthalten und selbst wenn das mal nicht der fall sein sollte firebug und Co geben jederzeit zuverlässig Auskunft über die berechneten Schriftgrößen.
Und ja, man muss sich darum kümmern, dass die Besucher von Webseiten lesbare Texte erhalten. Egal auf welchem Gerät und mit welchem Browser.
Klaus
am 20.12.2012 - 18:32
mich verwundert diese Erkenntnis des Artikels: Die Webdesignwelt hat glücklicherweise darauf reagiert und in den letzten sieben bis acht Jahren die früher üblichen 11 oder 12 Pixel großen Fließtexte schrittweise zu den heute eher üblichen 14 bis 16 Pixeln transformiert.
doch in höchstem Maße.
Das mit den 14-16 Pixeln muss ein anderer Planet sein, ist imho doch nach wie vor 12 Pixel die Standardgröße für Schriften.
Noch erstaunlicher finde ich diese Aussage von Jens Grochteis: Ich persönlich habe es immer gehasst, wegen des IE6 meine Seiten in em auszeichnen zu müssen und freue mich, Pixel nutzen zu können.
Ich vestehe diese dauernde Erwähnung des IE6, der schon länger nicht mehr relevant ist, in keinster Weise. Selbst der IE9 kann keinen Textzoom, wenn die Schriftgröße in Pixeln angegeben ist.
Der Seitenzoom ist da nur ein schwacher Trost erhöht er doch ganz schnell die Zeilenlaufweite und erschwert die Lesbarkeit damit.
Beim FF habe ich übrigens deshalb nur Text zoomen standardmäßig eingestellt. Damit ist besonders abends nach einem langen Arbeitstag ein sehr angenehmes lesen im I-net möglich. Bei den allermeisten Websites die ich besuche muss ich den Text um 1-2 Stufen vergrößern, damit das lesen für mich angenehm ist.
Der Artikel sowie einige Kommentare hinterlassen bei mir den Eindruck, als wäre die Pixelgenauigkeit eines Designs wichtiger als der Komfort für den Besucher.
Besucher, ihr wißt schon, dass ist die Spezies die Websites besucht um Infos zu erlangen, Buchungen zu tätigen, etc. pp.. Wenn mal einer vorbeikommt zeige ich ihn euch mal ;) SCNR
Gerrit van Aaken (Autor)
am 20.12.2012 - 22:59
Ich bin schon der Ansicht, dass wir auf einem Großteil der neu gelaunchten Websites der Jahre 2010–2012 inzwischen mindestens einen Schriftgrad von 14px haben (im Fließtext, nicht in den Marginalboxen!), und auch die 16px sind nicht mehr selten. Hängt natürlich auch mit Webfonts zusammen. Eine FF Tisa oder Minion wirkt unter 16px so groß wie eine Arial mit 14px.
Klaus
am 21.12.2012 - 09:06
in Zusammenhang mit Webfonts oder Schriftgraden denke ich nicht in Pixeln sondern in Prozent oder em. Alles andere ist wg. der vielen Ausgabegeräte nicht sinnvoll. ;)
Paul
am 21.12.2012 - 10:41
Gibt es eigentlich irgendeinen Grund, etwas anderes als 100% für seinen Fließtext zu verwenden?
Klaus
am 04.01.2013 - 10:59
nein, keinen rational und logisch erklärbaren! ;)
Immer wieder lesenswert, nicht nur für Anfänger, bis inkl. 1.2: http://little-boxes.de/lb1/1-das-web-ist-nicht-aus-papier.html
Paul
am 06.01.2013 - 20:26
In der Tat. Danke für den Link!
Jens Grochtdreis (Webkraut)
am 21.12.2012 - 09:52
In meiner Praxis hat der IE6 erst dieses Jahr aufgehört, relevant zu sein. Und es ist noch nicht sehr lange her, da habe ich für eine Großbank alles auf dem IE6 skalierbar machen müssen. Da gab es noch keinen Seitenzoom. Der ist mittlerweile überall Standard. Deshalb habe ich ihn noch erwähnt.
Wer den Seitenzoom zu Gunsten des Textzooms abschaltet, kennt die Konsequenzen. Sollte es jedenfalls.
Ich glaube nicht, dass ich allen Eventualitäten, die mir entgegenkommen, in der Umsetzung eines Designs entsprechen kann. Ich designe zudem nicht selber und habe ergo wenige Eingriffsmöglichkeiten. Wenn wir allen Eventualitäten begegnen wollen, müssen wir auf die meisten Designideen verzichten. Das wäre schade und ist auch nicht Sinn der Sache.
Ich gebe zu, dass ich px aus eigener Präferenz, eigener Bequemlichkeit und wegen der Sicherheit der Entwicklung wähle. Meine Projekte sind eher keine simplen Bloglayouts, bei denen em kein Drama ist. Es sind eher komplexe, grosse Seiten, bei denen Designer dann auch schonmal die Schriftgrößen in eigentlich gleichen semantischen Elementen variieren. Das passiert aber einer gewissen Komplexität schonmal. Und die Multiplikationseffekte mag ich nunmal nicht. Auch die Rundungdifferenzen zwischen den Browsern finde ich nicht besonders toll.
Ich wüßte nicht, was an der Auszeichnung mit Pixeln für den Nutzer schlechter sein soll, als mit em. Eine kleine Schriftgröße ist in beiden gleich klein, eine große ist gleich gross. Ich bezweifel, dass die Zahl derer, die Schriftskalierung einstellen, richtig gross ist. Und wenn: s.o.
Eventuell werde ich demnächst mittels Sass mal wieder eine Seite mit em auszeichnen. Das Tool macht den Umgang für mich leichter und das Ergebnis besser.
Die Kommentare sind geschlossen.