senäh

17senäh und so…

CSS3 Logo Thumbnail

HTML/CSS/JS
08. Feb 2012
Kommentare: 4

Kommentar: wozu brauchen wir Vendor-Prefixes und wann werden sie aussterben?

Kategorien: HTML/CSS/JS | 08. Feb 2012 | Kommentare: 4

Die Umsetzung von Website-Designs aus Photoshop in HTML und CSS hat dank CSS3 in Teilbereichen ein viel bequemeres Level erreicht. Für abgerundete Ecken und Schlagschatten ist ein Webentwickler nicht länger auf das Erstellen pixelgenauer Grafiken angewiesen. Ähnlich wie ein Ebeneneffekt in Photoshop angewendet wird, erhält das HTML-Element einfach eine CSS-Eigenschaft und der Browser rendert beispielsweise den gewünschten Schatten.

Schöne, neue Welt. Jedoch bleibt eines zu beachten: solche Eigenschaften sind nicht standardkonform, genauer: sie tauchen in keiner verabschiedeten Spezifikation auf. Die Browser setzen lediglich die aktuellen Spezifikationsentwürfe um.

Gut für uns Webentwickler, da wir nicht bis zur endgültigen Fertigstellung des Standards (geplant für das Jahr 2022) warten brauchen, um mit den neuen, fancy Features von CSS3 rumzuspielen. Der Preis dafür? Das größte Unding seit dem Internet Explorer 6: Vendor-Prefixes.

Was sind Vendor-Prefixes?

Für die, die es nicht wissen: mit einem Prefix vor der eigentlichen CSS-Eigenschaft spricht man die browserspezifische Implementierung an. Für abgerundete Ecken im Firefox z.B. -moz-border-radius, für Safari/Chrome -webkit-border-radius, etc. Das führt dazu, dass man für eine browserübergreifende Implementierung einer CSS-Eigenschaft bis zu 5 Zeilen Code schreiben muss, hier ein Beispiel für abgerundete Ecken:

1
2
3
4
5
-webkit-border-radius:8px;
-moz-border-radius:8px;
-ms-border-radius:8px;
-o-border-radius:8px;
border-radius:8px;

Warum genau brauchen wir das noch mal?

In der Theorie verhält es sich so: ein Browser kann seine eigene Implementierung einer neuen CSS-Eigenschaft einbauen. Weil es aber möglich ist, dass beispielsweise Safari und Firefox zur selben Zeit zwar die gleiche Eigenschaft jedoch mit unterschiedlicher Syntax implementieren wollen, wurden Vendor-Prefixes eingeführt. So kann über ein vorangestelltes Kürzel jede Browserimplementierung einzeln angesprochen werden um über die aktuell gültige Syntax browserübergreifend zum gewünschten Resultat zu gelangen.

Ich betone: in der Theorie. Ich werde mir mal 3 Szenarien rauspicken und daran hoffentlich aufzeigen können wie unnötig Vendor-Prefixes eigentlich sind.

Szenario 1: Webkit vs. Firefox

Ein eigentlich recht prominentes Beispiel: die Syntax eines linearen Verlaufs:

1
2
background: -webkit-gradient(linear, left top, left bottom, from(#000), to(#fff)); /* für Webkit-Browser wie Chrome */
background: -moz-linear-gradient(top, #000, #fff); /* für Gecko-Browser wie Firefox */

Hier sieht man eine Anwendung par excellance. Ersichtlich, oder? Doch stellen wir uns mal vor, wie es ohne Prefixes wär. Dann würden wir ausnutzen, dass CSS-Statements, die vom Interpreter nicht verstanden werden, schlicht ignoriert werden. In unserem Beispiel bedeutet das: die falsche Syntax wird ignoriert, die richtige angewendet. Würde notiert in etwa so aussehen:

1
2
background: gradient(linear, left top, left bottom, from(#000), to(#fff));
background: linear-gradient(top, #000, #fff);

Vorteil: bissl Bytes gespart, außerdem leserlicher.
Nachteil: ?

Szenario 2: Webkit vs. Webkit

Vendor-Prefixes sehen sich nur für die unterschiedlichen Implementierungen zweier Browserhersteller zuständig. Dass aber bei Differenzen zu Gunsten der Standardisierung zwangsläufig ein Kompromiss erfolgt, bei dem mindestens ein Browserhersteller seine Syntax anpasst… so weit wurde wohl nicht gedacht.

So geschehen bei besagter Syntax für den linearen Verlauf. Die Webkit-Syntax wurde erst Mitte Januar an die Firefox-Syntax angepasst. Dadurch ergibt sich das Problem, dass neuere Webkit-Releases die neue Syntax (und zusätzlich noch die Alte) verstehen, ältere Releases allerdings nur die Alte.

Auch hier nutzt man denselben “Hack”: unerwartete Syntaxformen werden vom jeweiligen Interpreter ignoriert. Mit Vendor-Prefixes:

1
2
background: -webkit-gradient(linear, left top, left bottom, from(#000), to(#fff)); /* Webkit - alte Syntax */
background: -webkit-linear-gradient(top, #000, #fff); /* Webkit - neue Syntax */

Ohne Prefixes:

1
2
background: gradient(linear, left top, left bottom, from(#000), to(#fff));
background: linear-gradient(top, #000, #fff);

Vorteil: bissl Bytes gespart, außerdem leserlicher.
Nachteil: ?

Szenario 3: Webkit vs. Firefox vs. Microsoft

Nehmen wir mal an der zugegebenermaßen recht unwahrscheinliche Fall würde eintreten, dass gleich 3 Browserhersteller konkurrierende Syntaxformen implementieren. Opera würde einer der drei adaptieren, außerdem ist es ja üblich für zukunftssichere Seiten noch die Reinform ohne Prefix zu notieren:

1
2
3
4
5
background: -webkit-gradient(linear, left top, left bottom, from(#000), to(#fff)); /* Webkit: Syntax 1 */
background: -moz-linear-gradient(top, #000, #fff); /* Firefox: Syntax 2 */
background: -ms-linear-gradient(top, from(#000), to(#fff)); /* IE: Syntax 3 */
background: -o-linear-gradient(top, from(#000), to(#fff)); /* Opera: Syntax 3 */
background: linear-gradient(top, from(#000), to(#fff)); /* Prefix-frei: Syntax 3 */

Ohne Prefixes würde man einfach wieder annehmen, dass ein CSS-Interpreter sich die richtige Syntax rauspickt. Dopplungen wie im Opera-Falle würden vermieden:

1
2
3
background: gradient(linear, left top, left bottom, from(#000), to(#fff));
background: linear-gradient(top, #000, #fff);
background: linear-gradient(top, from(#000), to(#fff));

Vorteil: bissl mehr Bytes gespart, außerdem wesentlich leserlicher.
Nachteil: ?

Zusammenfassung

Vendor-Prefixes wurden dazu geschaffen wurden, um eventuelle Inkompatibilitäten abzufangen. Statt dabei jedoch eine universellere Lösung zu suchen, hat man sich auf die Inkompatibilitäten zwischen verschiedenen Browserherstellern beschränkt. Auf den Gedanken, dass auch 2 Versionen eines Browsers eine neue Eigenschaft unterschiedlich implementieren, ist man beim W3C scheinbar nicht gekommen.

Dabei ist das zwangsläufig notwendig. Wenn Firefox eine andere Syntax implementiert als Opera, wird sich langfristig ein Kompromiss ergeben müssen. Einer von beiden wird seine Syntax im nächsten Release ändern und somit inkompatibel zur Vorgängerversion machen. Dieser Vorgang ist notwendig auf dem Weg zur standardkonformen Implementation von CSS3-Eigenschaften. Warum also hat dort niemand weit genug gedacht?

Letztendlich muss so oder so die Abwärtskompatibilität beachtet werden, doch dazu benötigt man absolut keine Vendor-Prefixes.

Wann sterben Vendor-Prefixes aus?

Ich hoffe ich konnte klar machen, warum ich finde, dass Vendor-Prefixes im Prinzip eine gute Idee, jedoch nicht der Weisheit letzter Schluss sind. Doch es gibt Licht am Ende des Tunnels. Schaut man sich aktuelle Implementierungen für box-shadow und border-radius an, wird recht deutlich, was geht, was nicht und worauf man achten sollte.

Cross-Browser-Support von box-shadow und border-radius

Cross-Browser-Support von box-shadow und border-radius

(geklaut bei electrictoolbox, Stand: 05/2011)

Man sieht: der Fortschritt in Richtung prefix-free ist zufriedenstellend. Aus dieser Tabelle kann man meiner Meinung nach auch ein paar Erkenntnisse mitnehmen, die zwar so sicherlich nicht 1:1 auf alle CSS3-Eigenschaften anzuwenden sind, aber durchaus als Faustregeln angesehen werden können:

  • bei Google Chrome brauch durch die Auto-Update-Funktion stets nur die aktuelle Version betrachtet werden
  • bei Safari muss man aufpassen, obwohl ebenfalls Webkit-basiert (dabei hielt Steve Jobs doch die Fahne für HTML5 so hoch…)
  • der IE ist ab der Version 9 meist meist ok, für den 7er und 8er sollte trotzdem stets ein Fallback implementiert werden, den 6er darf (!) man im Optimalfall ignorieren, da auch seine Marktanteile nach und nach (endlich) schwinden (nichtmal Facebook und Google unterstützen mehr den 6er)
  • beim Firefox ist die Version 3.6 sehr verbeitet, da danach lange Zeit nichts kam (man hatte den Browserkrieg Part II gewonnen), daher sollte man diesen im Auge behalten, ab Version 4 kann man aber von halbwegs regelmäßigen Updates beim Benutzer ausgehen, sodass ich für mich auch meist nur die aktuelle Version beachte
Solltet ihr anderer Meinung sein, lasst es mich wissen. Gern lasse ich mich belehren ;)

Wie kann ich die Welt verbessern? Was kann ich für das Aussterben von Vendor-Prefixes tun?

Prinzipiell dazu beitragen, dass möglichst viele Leute mit einem aktuellen Browser unterwegs sind. Im Diagramm oben sieht man, dass ein aktueller Browser die einfachste Lösung gegen den Fortbestand von Vendor-Prefixes ist. Je geringer der Anteil einer bestimmten Version, desto eher lässt sich dessen Relevanz beim Kundengespräch vom Webentwickler herunterspielen, desto eher kann man auf Vendor-Prefixes verzichten, desto mehr Zeit hat der Entwickler für die Verbesserung der User Experience, desto besser wird das Web, etc. pp. Warum ein aktueller Browser außerdem wichtig ist, hatte ich vor einiger Zeit bereits geschrieben. Hier stellvertretend eine schnelle Argumentationshilfe in Kurzform

  1. Sicherheit: Lücken werden geschlossen, allerdings nur bei regelmäßigen Updates
  2. Performance: mehr Geschwindigkeit = kürzere Wartezeiten = mehr Zeit für Facebook und Katzenbilder ;)
  3. Fortschritt: der aktuellster Browser spiegelt den neusten Stand der Technik wieder, warum sich diesne also nicht kostenlos sichern?

Und somit gehe ich auch gleich fließend über zum Abschluss (doch schon :D).

Die Mutter aller Lösungen: Auto-Updates

Welche Probleme haben wir eigentlich? Wir bekommen neue CSS3-Features, das ist gut. Allerdings werden – durch den Zustand des noch lange nicht verabschiedeten Standards – Syntaxformen hin und wieder angepasst. Dadurch hat man verschiedene Implementierungen bei verschiedenen Browsern und (vor allem) Versionen.

Die einfachste Lösung? Auto-Updates aller Browser a la Google Chrome.

Ein Alternativweg? Conditional Comments für alle Browser. Nicht nur

<!--[if lt IE 9]> Anweisungen <![endif]-->

sondern auch

<!--[if gt FF 3.6]> Anweisungen <![endif]-->

Somit würde dem Webentwickler für den Zweck der Abwärtskompatibilität ein mächtiges – wenn auch nicht besonders edles – Werkzeug an die Hand gegeben.

Eine weitere Alternative auf Basis von Feature-Unlocking inklusive Versionierung findet sich hier. Auch ein sehr interessanter und cleverer Ansatz.

Wie seht ihr das?

tl;dr

Vendor-Prefixes haben keine Daseinsberechtigung und schaffen neue Probleme (Stichwort Abwärtskompatibilität). Auto-Updates aller Browser werden immer dringender gebraucht, alternativ wären Conditional Comments auch für Nicht-IEs eine geeignete Übergangslösung.

Autor: Enno

Ich bin Enno. PHP ist mein Ding, aber auch alles Neue rund um die Themen HTML5, CSS3 & Co finde ich interessant. Ich mag es Leuten zu helfen und mein Wissen weiterzugeben. Sollte dir mein Beitrag gefallen haben, lass doch nen Kommentar da oder benutze einen der Social Buttons, um deinen Dank auszudrücken ;)

Kommentare (4)

  1. Zum Glück wagt Microsoft auch langsam erste Schritte in Richtung Auto-Update: http://www.golem.de/1112/88460.html

    • Jep, grundsätzlich cool. Leider mit der Einschränkung, dass Leute, die bisher mind. einmal ein Update aktiv abgelehnt haben, nicht in diesen Genuss kommen werden. Außerdem wird das auch den großen Anteil an IE6ern in Unternehmen nicht aushebeln, weil entsprechende Blocker-Kits vorhanden sind. Für Admins is sone Umstellung nach wie vor ein Risikofaktor.

      Aber ja, an sich ein richtiger Schritt in die richtige Richtung. Vielleicht werde ich ja eines Tages den IE17 benutzen, weil mir Microsoft bis dahin mit ihrer Browserpolitik wieder sympathisch geworden ist. Aber wer weiß, wo wir im Web schon wären, wenn nicht regelmäßig gefühlte 20% der Webentwicklung auf die Sicherstellung der Kompatibilität mit IEs fallen würden =/

  2. Hallo Enno,

    ein sehr gut geschriebener und ausführlicher Beitrag zu diesem Thema. Ich habe gestern angefangen in meinen CSS alle Vendor-Prefixe zu entfernen, heute Abend geht’s weiter.
    Für den IE greife ich auf „Conditional Comments“ zurück.
    Zu empfehlen ist das „prefixfree.js“ von Lea Verou. Ich werde es in meine Seiten einbinden und testen. Es ist ein einfaches zusätzliches Feature, allerdings nur wenn Java eingeschaltet ist.

    Gruß
    Klaus

    • Hey Klaus,

      danke für das Lob :)
      Ich bin kein Fan von unnötigen JavaScript-Bibliotheken. Deswegen mach ich sowas auch lieber händisch.
      Und das Problem mit Conditional-Comments ist, dass der IE seit dem 10er die Interpretation dieser deaktiviert hat =/

      Viele Grüße,
      Enno

Hinterlasse einen Kommentarsenäh

Pflichtfelder sind mit * markiert.