Immer mehr Websites setzen einen aktuellen Webkit-Browser voraus und stellen damit die ganze Idee von Webstandards auf den Kopf. Das Internet Magazin zeigt, was dieser Trend für Webgestalter bedeutet.

Glücklicherweise sind die Zeiten vorbei, als Websites stolz proklamierten, dass sie am besten mit dem Internet Explorer funktionierten. Doch während sich die Internet-Explorer-Ära rasch dem Ende zuneigt, zeichnet sich die Rückkehr der Browserkriege in leicht abgewandelter Form ab: Nicht nur Websites der Design-Avantgarde, sondern immer öfter auch gewöhnliche Websites setzen einen aktuellen Webkit-Browser voraus. Die verschiedenen Versionen des Internet Explorers hatten eine Zeitlang eine vorherrschende Marktposition und es bedurfte der Herausforderung durch Apple, Google, Mozilla und Opera, um Microsofts Dominanz in einem relevanten Ausmaß zu schmälern.

Die Versuchung durch Webkit

Das hohe Innovationstempo der Webkit-Entwicklung hat auf der einen Seite die Standardisierung neuer CSS-Eigenschaften entscheidend vorangebracht, doch auf der anderen Seite hat es herstellerspezifische Präfixe von einem experimentellen Kuriosum in ein allgemein akzeptiertes Gestaltungswerkzeug verwandelt.

Die größte Auswahl an gestalterischen Werkzeugen bietet zweifelsohne die Webkit Engine. Auf Grund der hohen Verbreitung von Webkit ist für Webdesigner die Versuchung, vor proprietären Webkit-Eigenschaften nicht halt zu machen, offenbar unwiderstehlich. Webdesigner stehen ja unter Druck, immer wieder Neues zu bieten und die gestalterischen Wünsche ihrer Auftraggeber oft auf Biegen und Brechen in die Praxis umzusetzen.

Glücklicherweise ist zwar die IE 6-Ära endlich passé, doch Websites, die nur mit einem bestimmten Browser oder, wie im Falle von Webkit, mit einer einzigen Rendering Engine laufen, erleben leider ein Comeback. Wenn sich Daniel Glazman, Mitvorsitzender der CSS Working Group über die Dominanz der von Apple und Google bevorzugten Webkit-Engine beschweren muss, weil viele Webdesigner nur noch das -Webkit-Präfix verwenden und Browser von Microsoft, Mozilla und Opera außen vor lassen, dann muss die Lage schon gravierend sein.

Das Webkit-Monopol im mobilen Internet

Die Gründe für diese Entwicklung liegen wie so oft in den Marktanteilen. Google nutzt die Webkit Rendering Engine im hauseigenen Chrome-Browser, der sich kurzerhand vom einst exotischen Herausforderer zur mittlerweile unangefochtenen Nummer zwei entwickelt hat und dabei Mozillas Firefox hinter sich ließ. Neuerdings ist der Chrome-Browser auch auf Mobilgeräten wie Tablets und Smartphones unter Android OS 4.0 (Ice Cream Sandwich, kurz ICS) standardmäßig voreingestellt. Doch das ist nicht alles. Apple vertraut auf Webkit in Safari und im mobilen Safari auf iOS-Geräten wie dem iPhone und iPad. Sogar Adobes Laufzeitumgebung AIR und Amazons cloudgestützter Browser Silk (verfügbar nur auf Kindle Fire) nutzen intern Webkit-Code. Somit hat Webkit das mobile Internet praktisch monopolisiert. Nachdem Googles Übernahme von Motorolas Mobility Division die Zustimmung der EU- und US-Regulierungsbehörden gewinnen konnte, steht dem weiteren Wachstum webkitbasierter Browser vorerst nichts mehr im Wege.

Als Nebeneffekt der Kombination aus Leistung und Verbreitung nutzen Webdesigner proprietäre -Webkit-Eigenschaften mit einer Selbstverständlichkeit, als ob sie reines CSS einsetzten, und zwar obwohl diese herstellerspezifischen Anweisungen weder in die offizielle CSS3-Spezifikation aufgenommen wurden noch in einem vorläufigen Entwurf des Bearbeiters (sogenannter „Editor’s draft“) auftauchen.

CSS3-Standards vs Webkit-Eigenschaften

Natürlich gibt es unter den proprietären Programmierkonzepten – unter anderem wären hier XMLHttpRequest, die Drag-and-Drop-API, contentEditable, Webfonts zu nennen – auch solche, die es letztendlich zum W3C-Standard schafften. Dennoch sollte Apple und Google nichts davon abhalten, ihre zum Teil durchaus guten Ideen der jeweils zuständigen W3C Working Group vorzuschlagen, mögliche Schwachpunkte auf der Basis des Feedbacks der weltweiten W3C-Gemeinde auszubügeln um dann zu einem gemeinsamen Vorschlag für einen offiziellen W3C-Standard zu gelangen. Oft werden stattdessen solche neuen -Webkit-Eigenschaften der CSS3-Gemeinde von Apples und Googles CSS3-Evangelists sogar als offizieller Bestandteil von CSS3 angepriesen, obwohl sie nicht einmal vorgeschlagen wurden.

Ausgefallene, aber eben proprietäre Lösungen, führen dazu, dass die Grenzen zwischen der offiziellen CSS3-Spezifikation und herstellerspezifischen Neuerungen verwischen. Wer möchte denn schon auf aktuelle Designtrends verzichten, um standardkonform zu gestalten?

Immer mehr CSS-Stylesheets beinhalten inzwischen nur noch die -Webkit-Version einer Eigenschaft, sogar dann, wenn es eine Entsprechung für andere Browser bereits geben sollte, denn den meisten Designern ist es schlicht zu viel Arbeit, für jeden Browser die Syntax nachzuprüfen.

Experimentierfreudige Webdesigner werfen den CSS3-Puristen, die auf der Reinheit ihrer CSS3-Stylesheets bestehen, Haarspalterei vor. Doch für Apple und Google sind hausgemachte CSS3-Eigenschaften, die nicht Bestandteil des offiziellen CSS3-Standards sind und noch nicht einmal in den vorläufigen CSS3-Entwürfen auftauchen, eine trickreiche Methode, um den Standardisierungsprozess von CSS3 gänzlich zu umgehen und de facto zu sabotieren. Design-Innovationen aus Apples und Googles CSS3-Küche, wie die Experimente mit Bildmasken (-Webkit-mask) oder Spiegeleffekten (-Webkit-box-reflect), mögen noch so interessant sein, sie hindern die Verbreitung von CSS3 und verschaffen Webkit-Browsern unfaire Wettbewerbsvorteile gegenüber den Mitbewerbern, die sich an CSS3-Standards halten.

Microsoft, Mozilla und Opera überlegen inzwischen ernsthaft, ob sie ihre Browser nicht als Webkit maskieren und um die Unterstützung proprietärer -Webkit-Eigenschaften erweitern sollten, um Websites darstellen zu können, die eine Webkit Rendering Engine zwingend voraussetzen. Das Konzept offener Webstandards würde dadurch ad absurdum geführt.

Die Lehren der ersten Browserkriege

Proprietäre Erweiterungen versus offizielle Standards: Auch während der Browserkriege der Neunzigerjahre bis ins 21. Jahrhundert hinein gab es bereits Webstandards. Damals wie heute sog man proprietäre Neuerungen einfach mit blinder Begeisterung auf und programmierte an den offiziellen W3C-Standards vorbei. Viele damalige Webprogrammierer ließen sich zum Einsatz proprietärer Features wie etwa Webfonts (ab IE4), IE-Filter zur Einstellung von Opazität, schattierter Rahmen, Übergänge und anderer Anweisungen an nicht standardkonformen DHTML-Behaviors von Microsoft hinreißen. Die heute trendigen -Webkit-Features sind aber um keinen Deut besser als die ActiveX-Erweiterungen und IE-Filter der Neunzigerjahre. Auch sie führen zur Bindung an herstellerspezifischen Code. Langfristig hätte es für Webdesigner – einmal wieder – gravierende Nachteile.

Webgestalter, welche die einst beeindruckenden IE 6-Features ansprechen wollten, mussten dann auch auf Biegen und Brechen akrobatische Workarounds um die Bugs dieses Browsers herum entwickeln und waren dann später auch entsprechend unwillig, auf den IE 7 und IE 8 umzusteigen. Und so war Microsoft bei der Einführung von IE 7 und dann IE 8 gezwungen, weitgehende Rückwärtskompatibilität zu IE 6 zu gewährleisten. Viele Website-Betreiber verließen sich dann auf Tricks wie bedingte Kommentare oder Browser Sniffing, um den problematischen User Agents eine für sie optimierte Version der Website zu servieren, oder versuchten, die gewünschten Features eines der Kompatibilitätsmodi zu aktivieren. Als es dann darum ging, für IE 6 entworfene und mehrmals umgestrickte Websites plötzlich konform mit W3C-Standards zu halten, war der Aufwand enorm. Eigentlich ist dieser proprietäre Ansatz aus den IE6-Zeiten nicht viel anders als die heutige Nutzung proprietärer, also nicht W3C-standardkonformer, -Webkit-Features, die einmal wieder eine Browsermonokultur erzwingt.

Proprietäre Features, die nicht einen offiziellen W3C-Standardisierungsprozess durchlaufen, leiden meist an einem schwachen Design, auch wenn die generelle Idee oft gut gelungen ist. Im Falle von Webfonts, die ab IE4 unterstützt wurden, war Microsofts unselige Idee auf proprietären .eot-Fontdateien zu beharren, eben ein klarer Designfehler, der nicht aufgetreten wäre, wenn Microsoft mit der Idee für Webfonts den W3C-Prozess durchlaufen hätte. Im Falle von Webfonts mittels @font-face ist das Design nun endlich W3C-konform und stieß entsprechend auch auf eine breite Zustimmung.

Ein aktuelles und ebenfalls prominentes Beispiel für eine misslungene Webkit-Erweiterung war die Eigenschaft -Webkit-gradient(), welche vor Fehlern nur so strotzte und CSS3-Gestaltern eine Menge Probleme verursachte.

Proprietäre -Webkit-Erweiterungen

Zu den berüchtigten -Webkit-Eigenschaften, die eben nicht Bestandteil des W3C-Standards sind und dennoch oft benutzt werden, zählen unter anderem

• -Webkit-box-reflect
• -Webkit-text-stroke
• -Webkit-mask
• -Webkit-background-clip: text;
• -Webkit-text-size-adjust
• -Webkit-tap-highlight-color
• -Webkit-text-fill-color

Doch nicht jede Stylesheet-Eigenschaft, welche mit einem Präfix für Webkit, Mozilla oder Explorer ausgestattet ist, muss unbedingt proprietär sein. Ursprünglich waren die Präfixe dafür da, um experimentelle Implementierungen von CSS3-Features aus W3C-Arbeitsentwürfen umzusetzen. Es stellt sich die Frage, wie man diese auseinander hält.

Proprietäre Features und Webstandards unterscheiden

Um zu ermitteln, ob es sich bei einer Stylesheet-Eigenschaft um ein proprietäres Feature der Rendering Engine oder um eine künftige CSS-Eigenschaft handelt, können Sie danach auf der W3C-Website suchen, zum Beispiel mit Google: „box-shadow“ site:w3.org.

So können Sie meist schnell den aktuellen Status der betreffenden Eigenschaft feststellen. Falls ein benötigtes Feature bisher noch nicht existiert, sind Sie gut beraten, mit einer ähnlichen standardkonformen CSS3-Eigenschaft ein vergleichbares Resultat zu erzielen. Auf den Einsatz proprietärer Stylesheet-Eigenschaften sollten Sie idealerweise ganz verzichten, um nicht in die Falle der Browserabhängigkeit zu tappen. Sollte der Verzicht auf proprietäre Stylesheet-Eigenschaften nicht oder nur sehr umständlich möglich sein, befolgen Sie das Konzept der schrittweisen Anreicherung (im Fachjargon „progressive enhancement“). Beim Rendern in einem Browser, der sich nicht auf die betreffende Stylesheet-Eigenschaft versteht, sollte das nicht unterstützte Feature sauber wegfallen, ohne das übrige Design zu beeinträchtigen oder die Nutzung der Inhalte zu erschweren.

CSS3-Features vorschlagen

Vielleicht klingt es für den einen oder anderen abwegig, ein benötigtes CSS3-Feature vorzuschlagen, aber in der Praxis ist dies zumindest möglich, und zwar unter der folgenden Adresse: www.w3.org/Style/CSS /current-work.de.html#contribute

Wer eine sinnvolle Idee vorschlägt, kann mit etwas Glück durchaus auf eine Implementierung hoffen. Voraussetzung ist hierbei, dass es erstens nicht bereits ein vergleichbares standardkonformes CSS3-Feature gibt und zweitens kein ähnliches CSS3-Feature bereits vorgeschlagen wurde. Letzteres lässt sich beispielsweise hier auf der W3C-Website leicht nachprüfen: www.w3.org/Style/CSS /current-work.de.html

Trifft beides zu, so kann ein vorgeschlagenes CSS3-Feature es durchaus in die offizielle CSS3-Spezifikation schaffen. Eines ist aber gewiss: Solch ein Vorgang ist ein langwieriger und recht zeitintensiver Prozess, der einer Menge Ausdauer bedarf und sicherlich keine schnellen Resultate zu Tage fördert.

Fazit

Führende Browserhersteller wie Google, Microsoft oder Mozilla verfolgen ihr eigenes Interesse. Das W3C-Komitee hingegen bemüht sich, faire Wettbewerbsbedingungen für alle zu schaffen und die Unabhängigkeit des Webs zu gewährleisten. Diesmal liegt das Schicksal der Webgestaltung auch in Ihrer Hand. Jeder einzelne Webentwickler kann die Browserhersteller in ihre Schranken weisen, indem er browserspezifische Präfixe einsetzt und rein proprietären Stylesheet-Eigenschaften aus dem Weg geht.