RalphGL blogt

Was ist anders im Web — als beim Druck?

Die Vor­her­seh­bar­keit des Dar­stel­lungs­er­geb­nis­ses von Web­sei­ten hängt von zahl­rei­chen Fak­to­ren ab und ist lei­der nur bedingt vor­her­seh­bar. Darin unter­schei­den sich Online-Publikationen ganz erheb­lich von Druck­sa­chen. In der Druck­vor­stufe wur­den Stan­dard­for­mate und spe­zi­elle Work­flows ent­wi­ckelt, um keine bösen Über­ra­schun­gen in der Pro­duk­tion zu erle­ben (siehe PDF/X1a, PDF/X3 etc.). Hält sich der Gra­fi­ker bzw. Druck­da­ten­er­stel­ler an den ver­ein­bar­ten Stan­dard, ver­wen­det er nor­mierte, pro­fi­lierte Farban­ga­ben und berück­sich­tigt die Papier­ei­gen­schaf­ten, kann er sich ziem­lich sicher sein, am Ende auch das gewünschte Ergeb­nis auf Papier in Hän­den hal­ten zu kön­nen. Und — ist die Druck­sa­che erst mal pro­du­ziert — wird auch wirk­lich jeder Betrach­ter das glei­che Dru­ck­er­geb­nis in Hän­den hal­ten können.

Im Onlin­ebe­reich ver­hält es sich (lei­der) völ­lig anders.

Ein­fluss­fak­to­ren für die Dar­stel­lung von Webseiten

Lei­der ist es keine Selbst­ver­ständ­lich­keit, dass eine Web­seite beim Betrach­ter X auch nur annä­hernd so aus­sieht, wie beim Betrach­ter Y. Denn nicht jeder Betrach­ter betrach­tet die vom Ser­ver aus­ge­lie­ferte Seite unter glei­chen Bedin­gun­gen. Ein­fluss auf das kon­krete Dar­stel­lungs­er­geb­nis haben:

• Bild­schirm­auf­lö­sung des Betrachters
• Betriebs­sys­tem und instal­lierte Schriften
• Brow­ser, –ver­sion und –einstellungen
• Farb­ma­nage­ment von Betriebs­sys­tem, Brow­ser und nicht zuletzt die Farb­tiefe und Bildschirmeinstellungen

Die Ein­hal­tung von Web­stan­dards wie XHTML 1.0 oder HTML 4.x bie­ten lei­der nur bedingt eine Gewähr für ein vor­her­seh­ba­res Ergeb­nis, denn

• ältere Brow­ser haben mit neue­ren Stan­dards natur­ge­mäß Probleme
• auch einige aktu­elle Brow­ser erfül­len nur teil­weise die Standardanforderungen

Typo­gra­fie im Web — Denkste!

Für pro­fes­sio­nelle Druck­sa­chen­ge­stal­ter ist es eine Selbst­ver­ständ­lich­keit Ele­mente durch Tabu­la­to­ren oder opti­mier­ten Zei­chen­aus­gleich bün­dig aus­zu­rich­ten, den Zei­len­um­bruch durch eine Wort­tren­nung zu opti­mie­ren, „typo­gra­fi­sche Anfüh­rungs­zei­chen“ ein­zu­set­zen, zwi­schen Bin­de­strich und Halb­ge­viert zu unter­schei­den etc. All dies wurde lei­der bis heute im www nicht ein­mal in den aktu­el­len Stan­dards berück­sich­tigt. Es gibt zwar erfreu­li­che Ansätze hierzu, wie z.B. das auf die­ser Web­seite ver­wen­dete Wordpress-Plugin wp-typography wel­ches u.a. eine Sil­ben­tren­nung und zumin­dest unter­schied­li­che Anfüh­rungs– und Schluss­zei­chen ermög­licht. (Nach­trag vom 20.8.09: Toll, dass nach dem heu­ti­gen Update und der Ände­rung der Ein­stel­lung der Anfüh­rungs­zei­chen in „deutsch“ auch „rich­tige deut­sche Anfüh­rungs­zei­chen“ ver­wen­det wer­den. Die­ses emp­feh­lens­werte Modul stellt einen Mei­len­stein für die Web-Typografie dar!). Aber letzt­lich kön­nen sol­che Hilfs­mit­tel nur durch einen zusätz­li­chen Imple­men­ta­ti­ons­auf­wand auf einer Web­seite ver­wen­det werden.

Der Weg aus dem Dilemma

Vor eini­gen Jah­ren mein­ten einige Desi­gner, dass der beste Weg um eine ein­heit­li­che Dar­stel­lung von Web­sei­ten zu gewähr­leis­ten darin bestünde die Sei­ten mög­lichst kom­plett als Bil­der zu spei­chern und aus­zu­lie­fern. Oft wur­den die Web­sei­ten aus meh­re­ren Ein­zel­bil­dern zusam­men­ge­setzt, um so z.B. das Bild für den Inhalt unab­hän­gig von Kopf– oder Fuß­be­reich zu wech­seln — z.B. durch eine ent­spre­chende Inter­ak­tion wie einen Menü­klick des Benut­zers. Diese zer­schnit­te­nen Ein­zel­bil­der wur­den dann in einer Tabelle wie­der zusam­men gesetzt.
Diese „Lösung“ wel­che die Grund­idee von Hyper­text — und dabei han­delt es sich schließ­lich beim www — ad absur­dum führt, erregte die Gemü­ter nicht nur der Pro­gram­mie­rer und der­je­ni­gen, die der Mei­nung waren eine Web­seite würde in ers­ter Linie Inhalt — also Texte und Links trans­por­tie­ren und eine Tabelle wäre zur tabel­la­ri­schen Dar­stel­lung von Inhal­ten da. Auch bei gemä­ßig­te­rer Inter­pre­ta­tion erga­ben sich ernst­hafte Kritikpunkte:

1. Eine Web­seite, die nur aus Bil­dern besteht ist weder für Such­ma­schi­nen, noch für Men­schen mit einem visu­el­len Han­di­cap „sicht„bar
2. Eine Web­seite, die aus Bil­dern auf­ge­baut ist, gibt eine fixe Größe in Pixel vor — unab­hän­gig von der Bild­schirm­auf­lö­sung des Betrach­ters. Ob die Schrift also im Ergeb­nis 4mm groß auf dem Bild­schirm erscheint, oder nur 1mm groß ist eben gerade nicht vor­her­seh­bar, das Ziel der Desi­gner folg­lich verfehlt.

Sol­che Pixel­sei­ten sind erfreu­li­cher­weise mitt­ler­weile kaum noch anzu­tref­fen. Und auch Web­sei­ten, die kom­pe­tente Auto­ren mit Werk­zeu­gen wie Flash erstellt haben sind nicht mehr zwangs­läu­fig „Pixel­sei­ten“ son­dern kön­nen durch­aus kom­pa­ti­bel, bar­rie­re­frei und Such­ma­schi­nen­freund­lich sein.

Statt­des­sen hat sich in den letz­ten Jah­ren die Ein­sicht durch­ge­setzt, dass eine pixel­i­den­ti­sche Dar­stel­lung von Web­sei­ten unter allen Bedin­gun­gen nicht das Ziel sein sollte. Denn — von den oben bezeich­ne­ten Pro­ble­men dies zu errei­chen ein­mal abge­se­hen — ele­mi­niert man die Vor­züge, die man durch die Betei­li­gung zweier Sei­ten (dem Ser­ver der die Sei­ten gene­riert und aus­lie­fert und dem Cli­ent mit Brow­ser an dem sie betrach­tet wer­den) an der Dar­stel­lung einer Web­seite errei­chen könnte.
Schließ­lich ist es doch gut und kein Pro­blem, wenn z.B. ein kurz­sich­ti­ger Benut­zer oder einer an einem sehr hoch auf­lö­sen­den Bild­schirm, bei dem ein Pixel folg­lich sehr klein ist, die Mög­lich­keit haben die Dar­stel­lung der Schrift im Brow­ser zu ver­grö­ßern. Oder wenn ein Mobil­te­le­fon mit einem sehr schma­len Dis­play Inhalte in einer Spalte dar­stellt, die man auf dem PC in meh­re­ren Spal­ten neben­ein­an­der sieht. Das „Pro­blem“ der unter­schied­li­chen Dar­stel­lung ist eigent­lich nicht unbe­dingt eines, son­dern kann zu einem Vor­teil gerei­chen, wenn man die Mög­lich­kei­ten von XHTML 1.0 bzw. HTML4.x zu nut­zen weiß.

Doch der Desi­gner, der natur­ge­mäß alles unter sei­ner Kon­trolle haben möchte, (aber auch der tech­nisch unbe­darfte Kunde) hat damit oft ein Pro­blem, schließ­lich führt z.B. eine Ver­grö­ße­rung der Schrift zu ver­än­der­ten Zei­len­um­brü­chen und einer Ver­klei­ne­rung der Abstände zwi­schen der Schrift. Befin­det sich die Schrift in einer fixen Spalte, oder vor Hin­ter­grund­gra­fi­ken, z.B. im Menü, kann es dazu füh­ren, dass die Schrift über die vor­ge­se­he­nen Berei­che hin­aus­ragt.
Ein Mei­len­stein zur Lösung die­ser Pro­bleme war die Ein­füh­rung der Ska­lie­rung von Bil­dern, die zunächst Opera, dann auch Fire­fox und mitt­ler­weile auch der Inter­net Explo­rer (ab Ver­sion 7) ein­ge­führt hat. Nun ver­grö­ßert und ver­klei­nert der Benut­zer über ent­spre­chende Inter­ak­tion nicht nur den Text, son­dern in glei­chem Maße auch die Grafiken.

Brow­ser­wei­chen und ange­passte Style­s­heets einsetzen

Eine Mög­lich­keit die Dar­stel­lung einer Seite unter einer ganz bestimm­ten Umge­bung zu beein­flus­sen, ist für genau diese Bedin­gung einen spe­zi­ell hier­für kon­zi­pier­ten Inhalt aus­zu­lie­fern. Ein häu­fig ver­wen­de­ter Fall ist z.B. bei der Ver­wen­dung von PNG-Grafiken mit Alpha­ka­nal (für wei­che Trans­pa­ren­zen) eine Spe­zi­al­ver­sion für den Internet-Explorer vor Ver­sion 7 aus­zu­lie­fern, da der IE erst abVer­sion 7 PNG mit Alpha­ka­nal beherrscht.

Das Pro­blem bei sol­chen Wei­chen ist, dass zunächst ganz genau ermit­telt wer­den muss unter wel­chen Bedin­gun­gen eine abwei­chende Ver­sion aus­ge­lie­fert wer­den soll. Diese Bedin­gung muss sau­ber for­mu­liert und ebenso sau­ber umge­setzt wer­den. Hätte man z.B. zu Zei­ten, als es noch kei­nen Inter­net Explo­rer 7 gab eine PNG-Weiche pro­gram­miert, die für den Inter­net Explo­rer eine abwei­chende Ver­sion lie­fert, so wäre diese Umset­zung mit Ein­füh­rung des Inter­net Explo­rers 7 über­holt gewesen.

Man muss sich klar sein, dass jede Brow­ser­wei­che einen zusätz­li­chen Imple­men­ta­ti­ons– und Test­auf­wand bedeu­tet. Folg­lich sollte man die­sen Lösungs­an­satz nur im Aus­nah­me­fall wäh­len und auf jeden Fall aus­gie­big testen.

Feh­ler eliminieren

Mit Feh­lern im html-Code wird von ver­schie­de­nen Brow­sern unter­schied­lich umge­gan­gen. Der eine Brow­ser „rät“, was gemeint sein könnte, der andere igno­riert ein feh­ler­haf­tes Ele­ment ein­fach. Wer eine ein­heit­li­che Dar­stel­lung von Web­sei­ten errei­chen möchte, sollte des­halb auf einen stan­dard­kon­for­men vali­dier­ten Code wert legen, der mög­lichst keine Feh­ler auf­weist. Dass dies in der Pra­xis meist nicht zu 100% erreicht wer­den kann sollte nicht dazu füh­ren, dass man die­ses Ziel aus den Augen verliert.

Moderne Stan­dards nut­zen und Work­a­rounds minimieren

Idea­ler­weise stel­len alle moder­nen Brow­ser eine Web­seite die feh­ler­freien Code ent­hält iden­tisch dar. Von die­sem Ziel ist man gar nicht mehr so weit ent­fernt. Aktu­elle Ver­sio­nen von Opera, Fire­fox und Inter­net Explo­rer beherr­schen weit­ge­hend die aktu­el­len W3C-Standards. Für wel­che Brow­ser sich eine indi­vi­du­elle Anpas­sung und Opti­mie­rung lohnt ist immer indi­vi­du­ell anhand der Ziel­gruppe, der Reich­weite des Pro­jek­tes und des damit ein­her­ge­hen­den Bud­gets sowie der zu erwar­ten­den Quote an Nut­zern zu ent­schei­den. Ob es sich lohnt für einen Brow­ser, den 2% der Web­sei­ten­be­su­cher nut­zen zu opti­mie­ren und evtl. einen work­a­round zu erstel­len, das muss jeder für sich ent­schei­den. Heut­zu­tage (Stand August 2009) nut­zen bedau­er­li­cher­weise immer noch zwi­schen 5 und 10% der Web­sei­ten­be­su­cher (mei­ner Web­sei­ten) den Inter­net Explo­rer in der Ver­sion 6. Diese nicht geringe Anzahl lässt einen Test und eine Anpas­sung für den IE 6 sinn­voll erscheinen.

Doch wie tes­tet man die Dar­stel­lungs­er­geb­nisse mit ver­schie­de­nen Brow­sern. Die gän­gis­ten Brow­ser und Sys­teme sollte man selbst auf einem Live-System tes­ten, also z.B. Win­dows XP, Vista und Win­dows 7 mit Inter­net Explo­rer 7 und 8 sowie Fire­fox 3. Natür­lich sollte man bei der Wahl sei­ner Test­sys­teme auch die Ziel­gruppe im Auge behal­ten. Eine Web­seite, die sich mit OS X-Themen und Druck­vor­stufe beschäf­tigt, sollte auch für Mac-User ver­träg­lich sein, wohin­ge­gen das bei einer Schnäpp­chen­jä­ger­seite für gebrauchte Com­pu­ter­teile evtl. eher keine Rolle spielt. Um nicht einen gan­zen Rech­ner­park in die Ecke stel­len zu müs­sen, emp­fiehlt es sich mit vir­tu­el­len Maschi­nen zu arbei­ten. So kann z.B. eine Basis­in­stal­la­tion von Win­dows XP mit Inter­net Explo­rer in einer vir­tu­el­len Maschine ebenso gute Dienste leis­ten, wie ein Inter­net Explo­rer 5 in einer Win­dows 2000 VM.

So sieht die Seite blog.agentur-lindner.com in 34 ver­schie­de­nen Brow­sern aus

Doch egal wie viele PCs und VMs man in die Ecke stellt, irgend­wann ist Schluss und manch­mal ist es auch ein­fach zu auf­wän­dig für eine schnelle Reva­li­die­rung Tests an meh­re­ren Rech­nern direkt durch­zu­füh­ren. Die Alter­na­tive hierzu heißt www.browsershots.org. Die­ser Web­dienst lie­fert Bild­schirm­ab­bil­dun­gen der gewünsch­ten Web­seite unter fast allen Betriebs­sys­te­men und Brow­sern an. Selbst Exo­ten kön­nen hier­mit getes­tet wer­den. Inter­es­sant ist auch die Mög­lich­keit eine bestimmte Bild­schirm­breite oder Farb­tiefe vor­zu­ge­ben. Brow­ser­shots lei­tet die Anfrage an eine Viel­zahl von Sys­teme mit unter­schied­lichs­ten Brow­sern und Betriebs­sys­te­men wei­ter und erhält von die­sen die jewei­li­gen Bil­der der ange­frag­ten Web­seite wie­der zurück um sie dann an den Anfra­ger aus­zu­lie­fern. Die Bil­der kön­nen als PNG-Grafiken im Brow­ser ange­se­hen oder als ZIP-Archiv her­un­ter­ge­la­den wer­den. Eine geniale Sache! Jede Web­seite sollte vor Abschluss der Arbei­ten mit die­sem Sys­tem über­prüft werden!