Gibt es eine Webkit-Monokultur im Netz? Opera-Evangelist Bruce Lawson und einige andere Mitglieder der CSS Working-Group des W3C sehen es so. Die Dominanz des iOS auf mobilen Clients begünstige die Entwicklung hin zu einer rein webkit-fokussierten Auszeichnung der CSS-Dateien aktueller Webapps. Ein große Zahl von Developern würde ihre Apps nur auf iOS-Clients testen und sich nicht einmal dann um die standardkonforme Schreibweise kümmern, wenn es sie gäbe. So würden webkit-exklusive Websites auch dann entstehen, wenn es gar nicht erforderlich wäre.
Andere Meinungen schreiben am Markt verfügbaren Frameworks und Boilerplates die Schuld zu. Opera, Microsoft und Mozilla wollen auf diese vermeintliche Bedrohung, bald gänzlich vom mobilen Markt verschwunden zu sein, reagieren, indem sie Webkit-Prefixes in ihren eigenen Browsern unterstützen. Dass es auch anders gehen kann, zeigt Lea Verou mit ihrem Tool -prefix-free.
-prefix-free setzt erforderliche Prefixes zur Laufzeit selber
-prefix-free ist ein kostenlos verfügbares Javascript, das es erlaubt, CSS stets ohne Prefixing, also immer in der standard-konformen Auszeichnung zu schreiben. -prefix-free setzt etwa erforderliche browserspezifische Prefixes zur Laufzeit selber. Das Tool wird von Lea Verou sorgfältig fortentwickelt und unter MIT-Lizenz bereit gestellt. Selbst CSS-Guru Eric Meyer lobt Verous Script in den höchsten Tönen.
Browserprefixing ist eine zumeist lästige, weil aufwändige, aber unabdingbare Vorgehensweise bei der Erstellung von CSS-Stylesheets. Es ist jedoch immer noch um Längen besser als das in der Vergangenheit übliche CSS-Hacking. Browserprefixes sprechen gezielt Implementierungen der jeweiligen CSS-Elemente des jeweiligen Browsers an. So lässt sich sicherstellen, dass der Benutzerbrowser erkennt, wie eine bestimmte Anweisung mit seinem eigenen Featureset umgesetzt werden kann.
Das Problem ist, dass es viele verschiedene Browser mit vielen verschiedenen Implementierungen gibt, so dass ein CSS-File heutzutage schnell schwer lesbar ob der ganzen Prefixes wird. Dabei ist nicht nur die Lesbarkeit beeinträchtigt, auch die Wartung des Stylesheets wird schwieriger. Entwicklerin Lea Verou wollte sich den ganzen Kraut- und Rüben-Code nicht länger anschauen müssen und entwickelte eine Lösung.
Ihr Script -prefix-free erlaubt es dem Designer, CSS-Files zu schreiben, ohne dabei Browserprefixes zu verwenden. Prinzipiell müsste er sie nicht einmal kennen. Im Kopf der jeweiligen Seite eingebunden, idealerweise direkt nach dem Einbinden der Stylesheets, sorgt -prefix-free zur Laufzeit dafür, dass der Zielbrowser über das korrekte Prefix angesprochen wird. Die Einbindung zur Laufzeit ist das stärkste Argument für die Umsetzung des Scripts als clientseitige Implementation im Gegensatz zu einer serverseitigen Abwicklung dieser Aufgabe.
Wer für bestimmte Fälle sicherstellen will, dass auch tatsächlich das korrekte Prefix gesetzt werden wird, der kann natürlich weiterhin entsprechende Anweisungen manuell einbauen. -prefix-free übergeht bereits mit Prefixes versehene Anweisungen.
-prefix-free steht zur kostenlosen Verwendung unter GitHub zur Verfügung. Es kann auch als jQuery-, sowie als Dynamic DOM Plugin verwendet werden. Unberechtigterweise muss sich Lea Verou aus den Reihen der Standardverfechter Kritik gefallen lassen. Sie begünstige die Webkit-Monokultur noch, wird ihr vorgeworfen. Dabei ist bei verständiger Betrachtungsweise das Gegenteil der Fall. Lea plädiert auf Einhaltung der Standards durch den Webdeveloper. Das Prefixing macht die Maschine…
Offtopic: Es lohnt sich auch, Lea Verous Projekt Animatable, eine Galerie mit CSS Transitions im Auge zu behalten!
0 Antworten
Klasse Tipp! Deswegen schau ich jetzt hier wirklich beinahe jeden Tag wieder vorbei!
Leas Skript macht in meinen Augen Sinn, wenn ich es im Rahmen des Prototypings oder bei einer HTML-Präsentation nutze. Für eine echte Seite empfinde ich die Idee eher als Frechheit, denn als gut.
Warum soll der Endnutzer unter der Faulheit des Entwicklers leiden? Das ist ja das Ergebnis dieser Generierung zur Laufzeit. Sie verlangsamt die korrekte Darstellung, weil ja erstmal die korrekten Prefixes erzeugt werden müssen.
Wer sich Arbeit sparen möchte, sollte Snippets in seinem Editor einrichten oder einen Präprozessor wie Sass oder Less nutzen.
Hmm. Na ja, als Frechheit würde ich die Arbeit Leas nicht bezeichnen wollen. Ich sehe auch nicht, dass es auf Faulheit des Entwicklers schließen lässt, wenn er sich eines Prefixers bedient. Ich bin immer froh, wenn ich meine Arbeit mit Tools beschleunigen kann und ich bin bestimmt nicht faul.
Tatsache ist natürlich, dass der Einsatz von -prefix-free einen – wenn auch minimalen – Effekt auf die Performance hat. Bei großen Stylesheets könnte es allerdings durchaus sein, dass die mit -prefix-free zu parsende Datei aufgrund ihrer weit geringeren Größe den Performancenachteil durch den Downloadvorteil wieder wett macht.
Wer den unbestreitbaren kleinen Performanceeffekt scheut, der muss dennoch nicht alles zu Fuß prefixen, sondern könnte sich beispielsweise des Tools CSS Prefixer von myfreeweb bedienen. Der macht ein Rewrite und parst nicht zur Laufzeit: https://github.com/myfreeweb/cssprefixer
Hier schließe ich mich Jens vollkommen an. Ich sehe da neben der Performance noch einen anderen Punkt: CSS-Prefixes wurden nicht ohne Grund eingeführt. Der Sinn ist schließlich der, dass noch nicht fertige CSS-Features bereits im Draft verwendet werden können. Anhand der Gradients sieht man deutlich, wie sich hier alles innerhalb von kürzester Zeit doch wieder ändern kann.
prefix-free geht nun aber hin und erhebt alle Prefixes für jeden Browser in ein Release-Stadium, da automatisch alle Prefixes gesetzt werden. Das ist aber unlogisch, da es auch vorkommen kann, dass ein CSS-Feature mit Prefix im Browser integriert ist, aber nur fehlerhaft funktioniert.
Man sollte als Webentwickler schon wissen, wann man welchen Prefix verwendet. Dafür gibt es, wie Jens schon erwähnte, auch Präprozessoren (SASS, Compass, LESS, Stylus) oder Code-Snippets im Editor, welche man alle nach seinen Bedürfnissen anpassen kann.
Die Performance wird in den meisten Fällen zwar durchaus marginal in Mitleidenschaft gezogen, aber in Anbetracht der zur Verfügung stehenden Geräte kann man hier durchaus Requests und Performance einsparen. Selbst mein iPhone 4 hat scheinbar nicht genug Power um JavaScript in annähernd gleicher Geschwindigkeit auszuführen wie ein Desktop-Rechner. Es verträgt sich nun einmal nicht, wenn man auf der einen Seite Bytes und Requests sparen will, womöglich über Responsive Images nachdenkt, dann aber wieder ein unnötiges Script drauf packt.
Ich will da keinen Glaubenskrieg vom Zaun brechen, gebe aber noch zweierlei zu bedenken:
1. -prefix-free ermöglicht dem Developer, der W3C-Empfehlung zu folgen, die da lautet “Authors should avoid vendor-specific extensions”.
2. Dadurch das -prefix-free nicht alle Prefixes zwanghaft reinkloppt, sondern vorab ermittelt, was der Browser, der eben die Seite aufruft, kann, unterlässt -prefix-free das Setzen nicht mehr erforderlicher Prefixes. Ob der Developer das auch tut? Hier ist ja zusätzlich zu beachten, dass sich die Fähigkeiten der Browser permanent ändern. Ich habe für meine Stylesheets bei den Kunden keine Patenschaft übernommen.
1. Ok, der Developer hält sich dann daran, aber -prefix-free nicht.
2. Nicht mehr erforderliche Prefixes weg zu lassen ist je nach Browser auch gut, aber ist man sich dann immer sicher, dass -prefix-free das auch korrekt macht? Außerdem findet dann wohl nicht nur ein automatisiertes Setzen von Prefixes statt, sondern ein Feature-Test. Verwendet man gleichzeitig Modernizr, dann werden beim Rendern einer jeden Seite bestimmte Featur-Tests doppelt ausgeführt. Das macht nun überhaupt keinen Sinn.
Des weiteren holt man sich wieder ein unnötiges fremdes Script in die Seite, welches außerdem Bugs enthalten kann (siehe Github Commits und Issues). Ich halte da nichts von. Setze ich die Prefixe in SASS oder per Snippet, dann erzeugt das zumindest keine JavaScript-Bugs 😉
Die Frage ist doch, ob der Vorteil (Prefixe nicht mehr schreiben) den Nachteilen überwiegt. Das trifft nur in meinen Projekten nie zu.
Ich würde das Skript einerseits gerne zur Entlastung einsetzen, andererseits grauts mir dann vor den Usern mit deaktiviertem Javascript (auch wenn der Anteil gering ist), sodass ich die Prefixes zur Sicherheit doch wieder selbst reinkloppen würde…
In diesem Falle wäre wohl der weiter oben verlinkte CSS Prefixer empfehlenswert.