08. August 2008
Wer gelegentlich unter Windows mit dem Safari surft oder aber mit Safari/Firefox auf dem Mac im Internet unterwegs ist, wird das Problem wahrscheinlich kennen. Die Kantenglättung führt bei hohen Kontrastverhältnissen zwischen Vorder- und Hintergrund zu einem ungewöhnlich “fetten” Schriftbild. Verursacher ist wohl die CoreText-Technologie, welche Apple zur Kantenglättung in OSX einsetzt und welche auch beim Windows-Safari zum Einsatz kommt. Folgender Beitrag erklärt die Unterschiede zwischen der den Kantenglättungsverfahren von Apple und Mircosoft (Danke an Herrn Caspers für den Link).
Der linke Teil des Screenshots zeigt, was gemeint ist. Kleine und mittlere Schriftgrößen wirken so, als ob sie generell im Fettdruck gesetzt wurden. Richtig auffällig wird das beispielsweise unter Windows Vista, wenn man die Darstellung im IE7, Firefox oder Opera zum direkten Vergleich heranziehen kann.
Bekannte Bugfixes
Einige schlaue Leute haben zwei mögliche Bugfixes gefunden, die das Problem zuverlässig beseitigen. Auf Jonnotie werden beide Ansätze vorgestellt. Das Ergebnis zeigt der rechte Teil des oben gezeigten Screenshots, der mit dem Safari/Win entstand.
Text-Shadow-Methode
* { text-shadow: #000000 0 0 0px; }Diese Methode funktioniert im Firefox und im Safari 3.
Opacity-Methode
* { opacity: 0.9999999; }Diese Methode funktioniert laut Jonnotie auch in der Entwicklerfassung des Safari 4 und wird daher zur Anwendung empfohlen.
Vorsicht bei der Anwendung
Ich habe beide Bugfixes nochmals getestet und kann die Funktion bestätigen. Dennoch rate ich vom Einsatz in der hier gezeigten Form grundsätzlich ab. Der Grund dafür ist die Wahl des Stern-Selektors, wodurch der Bugfix pauschal auf alle Elemente des Layouts angewendet wird. Sowohl im Firefox als auch im Safari führt dieses Vorgehen zu eklatanten Performance-Einbrüchen im Rendering beider Browser. Spürbar wird das besonders, wenn man die Größe des Browserfensters ändert. Beide Browser beginnen bei Seiten mit viel Text massiv an zu ruckeln, selbst auf schnellen Dual-Core-Prozessoren. Speziell auf Notebooks mit schwachen Grafikkarten sind verstärkt Ruckler zu befürchten.
Wer also mit der Textdarstellung unzufrieden ist, und diese unbedingt korrigieren will, sollte dies mit Bedacht tun. Entscheidend für die Performance ist dabei die Größe (Höhe * Breite) der betroffenen Elemente. Ähnlich wie bei der Alpha-Transparenz von PNG-Grafiken wirken sich kleine Elemente kaum auf die Performace aus. Wird der Fix aber großflächig auf z.B. den Inhalt dieses Weblogs angewendet, wird der Performance-Einbruch sehr schnell spürbar und kann auf langsamen Rechnern/leistungsschwachen Grafikkarten (man denke an Notebooks) störend wirken.
Da es in der Regel aber nur Sinn macht, alle Elemente zu korrigieren, rate ich vom Einsatz dieses Fixes eher ab. Wer mit den betreffenden Browsern surft, dürfte sich mit dem Schriftbild arrangiert haben und die zu befüchtenden Performance-Einbrüche auf einigen Rechnern dürften bei den Besuchern eher einen schlechten Gesamteindruck der Seite hinterlassen als dass Sie die schönere Kantenglättung zu schätzen wissen.
Freitag, 08.08.08 (12:43 Uhr)
Der rechte Screenshot zeigt auch eindrucksvoll, wie kleiner Text ganz schnell absaufen kann („Webdesign und digitale…“)
Freitag, 08.08.08 (12:47 Uhr)
@maxc
Auch das ist ein Nebeneffekt des von Apple verwendeten Verfahrens. Unter Vista sieht auch dieser kleine Text besser aus.
Freitag, 08.08.08 (13:37 Uhr)
Da ist wohl wirklich viel Gewohnheit dabei. Ich kann es nicht mit Vista vergleichen, nur mit Windows XP. Betrachte ich diese Seite mit Safari auf Mac und mit IE7 unter XP mit aktivierter Schriftglättung, so gefällt mir der Gesamteindruck der Seite am Mac besser. Ausserdem bilde ich mir ein, dass ich den Text am Mac in gleicher Schriftgröße besser lesen kann. In der Tat erscheint der Text unter XP schärfer, zugleich aber auch dünner und kontrastschwächer, was bei mir zu Leseproblemen führt. Unter Windows müsste ich den Text vergrößern, um ihn ordentlich lesen zu können, am Mac noch nicht. Das wird um so ausgeprägter, je kleiner der Text wird.
(Ich verwende XP virtualisiert auf dem gleichen Rechner und kann deshalb beide Fenster direkt nebeneinandern öffnen und auf dem gleichen - sehr hochwertigen - Monitor betrachten.)
Wie gesagt, das kann einfach Gewohnheit sein - wahrscheinlich sogar - aber ich empfinde es ganz gewiss nicht als “Manko”.
Freitag, 08.08.08 (14:11 Uhr)
Ich bin eher der Meinung dass man das was man rechts sieht fixen müsste damit es so aussieht wie auf der linken Seite und lesbarer wird.
Freitag, 08.08.08 (14:13 Uhr)
@Peter
Das sehe ich ebenso, deshalb rate ich ja auch davon ab. Ich kenne halt genug, die sich auf jeden Bugfix stürzen und blindlings einbauen, daher die warnenden Worte, da ich die Nebenwirkungen als nachteilig erachte.
Freitag, 08.08.08 (14:45 Uhr)
Nachtrag: Ich werde der besseren Vergleichbarkeit wegen, heute nachmittag noch einen Vista-Screenshot hinzufügen.
Sonntag, 10.08.08 (17:34 Uhr)
Also für mich hat der Screenshot links oben (Safari 3.1 XP Arial) das angenehmste Schriftbild. Dementsprechend bräuchten eher die anderen Varianten einen “Bugfix”
Viele Grüße von Zippo!
Dienstag, 12.08.08 (19:00 Uhr)
Mich hat der Bug zu Firefox-2-Zeiten tierisch genervt. Besondere Konstellationen haben eine regelrechte „Animation“ dessen hervorgerufen. D. h., wenn man den Mauszeiger auf Links hielt, wurde der Bug „aktiviert“, zog man die Maus weg, war es wieder normal.
Besonders auffällig ist es bei The Big Noob unter Firefox 2 – einfach mal probieren: mit der Maus über den Absatz unterm Teaserbild fahren.
Zumindest ist dieser auslösende Effekt im FF 3 weg, da fällt es im ersten Moment nicht auf.
Die Variante mit der Opacity ist mir damals irgendwie schon in den Sinn gekommen (und ich wollt das auch ewig bloggen …).
Man darf die Opazität nicht per Asterisk auf alles anwenden, sondern sollte probieren. Oftmals reichen ein paar kaskadierte p- u. hx-Tags aus. Ich hatte mich auch auf fünf stellen nach dem Punkt beschränkt, da es ab da eigentlich nicht mehr sichtbar war. Bei neun Stellen denke ich mir schon, dass das Rendering rechenintensiver ist, wobei mir hier jetzt das Verständnis für die internen Sachen seitens FF fehlen.
Dienstag, 12.08.08 (19:00 Uhr)
Ähh, ich habe vergessen zu erwähnen, dass ich Firefox 2 auf’m Mac meine!
Mittwoch, 13.08.08 (00:07 Uhr)
@Dirk und Datenkind
reicht es nicht vielleicht aus opacity: 0.9999 nur für das body Element zu setzen?
Ich hatte mal in einem Projekt einen FF2/Mac-Bug, bei dem die Scrift immer blinkte. Bis ein Kollege dann zutreffend bemerkt hat, dass der FF zwischen Kantenglättung und nicht Kantenglättung hin und hersprang, woraufhin das setzen von opacity kleiner 1 nur beim body die “Fettschrift” überall dauerhaft ausschaltete.
Ein “Asterix-Opacity” ist schon deshalb ablehnenswert, weil sich die opacity Wert mit der Verschachtelungstiefe multiplizieren.
Mittwoch, 13.08.08 (07:51 Uhr)
@Alexander
Nur einmal angemerkt: * { ... } ist ungefähr das gleiche wie body { ... }, wenn du die „Verschachtelungstiefe“ im DOM ansprichst.
Mittwoch, 13.08.08 (10:21 Uhr)
@David
Ich glaube ich habe mich nicht richtig ausgedrückt. Bei * opacity: 0.9 hat der body den opacity Wert 0.9. Aber sieht so aus als würde man nur dem body den opacity-Wert 0.9 hoch 2 geben (Den von der Wirkung multiplizieren sich die Opacity-Werte mit jeder Verschachtelung im obigen Beispiel nämlich einmal für html und einmal für body selbst).
Alle Kindelemente von body haben den Wert von 0.9 hoch 3 und so weiter.
Gib einmal bei Firebug (auf diesem Blog) $(’*’).css(‘opacity’ 0.8) und einmal $(‘body’).css(‘opacity’, 0.8). Dürfte komplett unterschiedlich aussehen.
Mittwoch, 13.08.08 (10:27 Uhr)
Nochmal (sry für die Spam-Attacke), aber vielleicht ganz guter Vergleich. Opacity verhält sich hier im Prinzip genauso wie font-size (nur dass dies im berechneten CSS-Stil (computedStyle) - anders als bei font-size - nicht angezeigt wird). Die Wirkung von * {font-size: 90%} und body {font-size: 90%} ähnelt der Wirkung bei opacity und den vorgenannten Selektoren.
Mittwoch, 13.08.08 (13:01 Uhr)
@Alexander
Der “Fix” muss meines Wissens nicht auf das Hintergrundelement sondern auf die betroffenen Textelemente direkt angewendet werden.
Zusätzlich zu meinen Perfomance-Bedenken kommen aber auch die u.U. daraus resultierenden Lesbarkeitsprobleme bei kleinen Schriftgrößen. Daher nochmal mein Fazit: Lebt mit den etwas dickeren Schriften, dieser Bugfix verschlimmbessert so pauschal eingesetzt nur. Gezielt eingesetzt, kann er in Einzelfällen hilfreich sein - allerdings nicht ohne Tests.
Mittwoch, 13.08.08 (22:15 Uhr)
Hi Dirk,
das ist echt schade. Deine Performance Bedenken teile ich absolut, habe das gestern an deinem Blog ausprobiert und Window resizen ging mit meinem kleinen Dual Core gar nicht mehr.
Ganz nebenbei finde ich solche Blogpost auch wichtig. Gerade bei solchen versteckten Problemen. Häufig wendet man so etwas an, merkt das Problem nicht und am Ende des Projekts wird der Bug gefunden und die Ursachensuche gestaltet sich extrem schwierig…
Grüsse
alex
Dienstag, 26.08.08 (18:31 Uhr)
Das Rendering von Mac finde ich grausam. Ich selbst bin zwar kein Macuser, doch ein guter Freund hat einen Mac. Wenn ich bei dem sehe, wie die ganze Schrift, zum Beispiel auch die unter den Desktopsymbolen aussieht, wird mir ganz anders zumute. Die Screenshots oben, zeigen das ja auch. Ich frage mich wirklich wie man so eine verschwommene fette Schrift auf Dauer aushält.
Eventuell ist das ganze aber auch Gewöhnung.
Mittwoch, 27.08.08 (12:16 Uhr)
Der Opacity-Hack ist Unfug, denn
opacity < 1erzeugt einen neuen Stacking Context für das Element (siehe CSS3 Color 3.2), mit dem Universalselektor sogar für jedes Element.
Mittwoch, 27.08.08 (16:08 Uhr)
Was der Grund für die drastischen Performance-Einbrüche sein dürfte.
Donnerstag, 18.09.08 (20:11 Uhr)
vielen Dank, es halt mir bei meinen Problem sehr geholfen!
würde den Beitrag gerne bei mir veröffentlichen ( blog.ingeniumdesign.de )
grüße, Basti
Donnerstag, 18.09.08 (21:53 Uhr)
Muss gerade ein Layout umsetzen, dass ein Graphikdesigner erstellt hat, der viel über Typografie löst. Was mir bei Safari das Genick bricht, weil die Hauptnavigationspunkte fett abgesetzt werden soll.
Schätze wenn ich den Bugfix nur für die div#navi einsetze, müssten sich die Performance-Einbußen in Grenzen halten.
Gibt doch praxisrelevante Anwendungsfälle.
Also vielen Dank für diesen Post.