Firefox 39+ mit Webkit-Emulation für bestimmte Webseiten
Firefox 39 besitzt ein neues Feature, um CSS-Eigenschaften mit dem -webkit-Präfix zu emulieren und somit korrekt darzustellen. Dies gilt allerdings nicht für jede beliebige Webseite, sondern nur für eine kleine Auswahl an Webseiten, welche fix in Firefox hinterlegt ist und auch nicht verändert werden kann. Webentwickler müssen also auch weiterhin darauf achten, nicht nur für Webkit-Browser Code zu schreiben.
Sogenannte CSS Vendor-Präfixe sind, auch wenn die Idee dahinter gut sein mag, oftmals ein Problem. Nämlich dann, wenn Webentwickler die Browser, welche logischerweise die herstellerspezifischen Präfixe der anderen Browser nicht kennen, vergessen oder gar bewusst ignorieren. Die Folge sind Webseiten, welche in den einen Browsern gut aussehen, in anderen Browser aber nicht, obwohl es überhaupt keinen technischen Grund dafür gibt und diese Browser sehr wohl in der Lage wären, die entsprechende Webseite korrekt darzustellen.
Mozilla hat sich diesem Problem angenommen und so kann Firefox ab Version 39 einige Webkit-Eigenschaften emulieren, als wären sie für das Web geschrieben worden. Allerdings dürfen Webentwickler nun nicht auf die Idee kommen, jetzt erst Recht nur noch für Webkit zu entwickeln, denn nun kommt das Aber: es handelt sich dabei um keine grundsätzliche Fähigkeit von Firefox, was für das Web auch eher schlecht als recht wäre. Stattdessen hat Firefox eine Liste von Webseiten fest implementiert bekommen, welche auch nicht durch den Nutzer verändert werden kann, und diese Liste beinhaltet auch nur wenige Webseiten, vor allem aus China und Japan. Die Idee dahinter dürfte sein, ein paar relevante Webseiten mit großen Darstellungsproblemen für Firefox-Nutzer benutzbar zu machen, wenn es nur an herstellerspezifischem CSS scheitert. In erster Linie geht es dabei um Firefox für Android, weil es besonders auf den mobilen Sektor zutrifft, dass häufig nur für Webkit entwickelt wird. Da dieses Feature allerdings auf Gecko-Ebene implementiert worden ist, ist dies auch uneingeschränkt für die Desktop-Version wirksam, was auch Sinn ergibt, da Gecko auf dem Desktop möglichst das Gleiche darstellen sollte wie Gecko auf dem Smartphone. Das Ziel ist außerdem eine Liste, die so klein, nicht so groß wie möglich ist, denn die beste Lösung für das Web ist ohne jede Frage das Entwickeln von Webseiten, die in jedem Browser funktionieren. Die Emulation für jede beliebige Webseite wäre kontraproduktiv und würde ein vollkommen falsches Signal an die Webentwickler-Community senden. Die Einstellung in about:config, um die Emulation zu deaktivieren, heißt layout.css.unprefixing-service.enabled.
[lightbox style=“modern“ image_path=“https://www.soeren-hentzschel.at/wp-content/uploads/webkit-emulation.png“ popup=“https://www.soeren-hentzschel.at/wp-content/uploads/webkit-emulation.png“ link_to_page=““ target=““ description=““ size=“two_col_small“]
Sören Hentzschel ist Webentwickler aus Salzburg. Auf soeren-hentzschel.at informiert er umfassend über Neuigkeiten zu Mozilla. Außerdem ist er Betreiber von camp-firefox.de, der ersten Anlaufstelle im deutschsprachigen Raum für Firefox-Probleme aller Art. Weitere Projekte sind firefox.agenedia.com, firefoxosdevices.org sowie sozone.de.
Webkit entwikelt sich immer mehr zu pest. 🙂
Stimmt. Was aber in erster Linie an den Webentwicklern liegt, denen es egal ist, dass es noch andere Browser gibt, die nicht Webkit nutzen. 😉
Klingt wie die Behandlung eines Krebsgeschwürs. Ich finde den Ansatz von Mozilla nicht unbedingt sinnvoll. Es trägt dadurch nicht gerade zu einer Problemlösung bei.
Da kann ich dem ersten Kommentar nur zustimmen. Um so mehr bin ich „erfreut“, dass nicht auch Microsoft mit seinem neuen Browser Edge auf WebKit setzt. Dadurch ist Mozilla nicht alleine und hat sogar noch einen mächtigen „Partner“, der auch dafür sorgt, dass in Zukunft nicht nur bzw. bevorzugt auf WebKit gesetzt wird.
Darüber hinaus halte ich diese hier beschriebene WebKit-Emulation aber auch für „gefährlich“. Der Schritt zur generellen WebKit-Emu ist so nicht mehr weit. Ich bin mir nicht sicher, ob Mozilla sich selbst und seinen Nutzern sowie dem uneingeschränkten Zugang zum Internet damit einen gefallen tut.
Nicht grundlos findet diese Emulation nur für eine ganz kleine Auswahl von Webseiten statt. Der Schritt zu einer generellen Webkit-Emulation ist sogar sehr weit, denn genau das hat man ja ganz bewusst nicht gemacht. Die Alternative wäre, dass gewisse Seiten für Firefox-Nutzer nicht oder nur schlecht benutzbar sind. Und wenn beispielsweise ein Baidu in China von Firefox-Nutzern nicht ordentlich benutzt werden kann, dann kann sich ja jeder selbst ausrechnen, was das für Mozilla bedeutet: dass diese Nutzer halt Chrome (mit sehr hoher Wahrscheinlichkeit) verwenden, oder einen anderen Browser, aber eben nicht Firefox. Dass es keine generelle Webkit-Emulation geben wird, das kann man wohl als ziemlich sicher betrachten, aber wenn wichtige Webseiten für Firefox-Nutzer nur wegen sowas nicht funktionieren, ist das auch ein Problem, welches Mozilla addressieren muss, um nicht Nutzer zu verlieren. Firefox hat nicht so viele Nutzer, dass sie es sich leisten könnten, schon gar nicht mobil. Das ist nämlich genau der Punkt: Ginge es nur nach Mozillas Idealen, dann bräuchte es so ein Feature nicht, es ist natürlich die Pflicht der Webenentwickler für Kompatibilität zu sorgen und wer das nicht macht, hat Pech. Mozilla kann aber nur positiven Einfluss ausüben, wenn sie relevant sind, und Relevanz geht über Marktanteile. Je weniger Nutzer Firefox hat, desto weniger Einfluss hat Mozilla. Also geht es immer um ein Abwägen, nicht nur hierbei, grundsätzlich. Das ist nicht anders als mit der Unterstützung von H.264, das geht auch gegen die Ideale, aber man sage mir mal bitte, wie viele Nutzer nicht froh sind, dass sie alle Videos auf YouTube abspielen können, auch ohne Flash Player. Oder Encrypted Media Extensions ab Firefox 38. Das ist DRM für das Web, davon war Mozilla auch noch nie ein Befürworter. Aber Mozilla muss es unterstützen, weil es einfach nicht akzeptabel wäre, wenn Firefox der einzige Browser auf dem Markt wäre, der das nicht unterstützt, da denke ich als allererstes natürlich an Netflix (die Silverlight-Ära geht dem Ende zu).
Okay, da stimme ich dir schon zu, sonderlich erfreut bin ich trotzdem nicht. Das liegt aber vielmehr an den Entwicklern, die es trotzdem nicht lernen. Das Verhalten belohnt Mozilla damit indirekt. Mein Problem an der Sache ist auch, was bedeutet „wichtige Seite“ -> Google Dienste, Bing, Yahoo whatever? Das könnte auch Überhand nehmen. Das Grundübel muss an ganz anderen Stellen angegangen werden. Wir brauchen ein Ende der Vendor-Präfixe und eine einheitliche Umsetzung von CSS-Eigenschaften, sonst wird das nichts.
Die Vendor-Präfixe haben aber schon auch einen Sinn. CSS-Eigenschaften werden ja häufig schon implementiert, bevor die Spezifikation überhaupt abgeschlossen ist, gleiches mit HTML-Elementen, ansonsten würde die Entwicklung des Webs sehr, sehr viel länger dauern, da sind Unterschiede vollkommen natürlich, vor allem auch abhängig davon, welchen Entwurf der Hersteller implementiert hat. Und neue CSS-Eigenschaften müssen dazu ja auch getestet werden, teilweise eben auch, um Schwächen in der Spezifikation im realen Einsatz festzustellen, bevor die Spezifikation finalisiert ist. Denn sobald das Präfix weg ist, gibt es fast keinen Weg zurück mehr. Es ist unheimlich schwierig, die Syntax oder das Verhalten eines Standards zu ändern, wenn etwas erst einmal verwendet wird. Die Folge ist, dass man dann eher etwas schlecht lässt als es zu verbessern, weil die Auswirkungen auf die Kompatibilität viel zu groß wären, im Web ist das leider Realität. Ich hab zum Beispiel im Studium erfahren, dass JavaScript irgendeinen Bug hat (ich weiß leider nicht mehr welchen), der nicht behoben werden kann, weil davon ganz viele Webseiten betroffen wären, würde dieser Bug behoben. Auch werden eigene Implementierungen für Eigenschaften mit Vendor-Präfix für Dinge verwendet, die noch überhaupt nicht auf dem Weg sind, ein Standard zu werden, sondern als solcher erst vorgeschlagen werden sollen. Und es braucht es zwei voneinander unabhänige Implementierungen, damit ein Webfeature zu einem Browserstandard werden kann. Solange das Webfeature nicht standardisiert ist, weichen die Implementierungen unter Umständen voneinander ab, weil die verschiedenen Browserhersteller nicht alles genauso sehen und Dinge jeweils anders machen würden. Wie es dann ohne Präfix gemacht werden soll, legt erst der finale Standard fest.
Teilweise gibt es in Firefox Einstellungen über about:config, um bestimmte CSS-Features vorab zu testen, also das vorher testen geht grundsätzlich schon auch ohne Vendor-Präfix, wobei ich nicht weiß, wie es diesbezüglich in anderen Browsern aussieht. Bei Chrome könnte ich mir vorstellen, dass es da was ähnliches gibt, Chrome hat ja auch sowas wie Flags, aber ich weiß es nicht konkret am Beispiel von CSS-Features, bei anderen Browsern weiß ich es noch weniger. Ich stimme zu, dass Vendor-Präfixes ein Problem schaffen, wofür das Web im mobilen Sektor nun den Preis bezahlt, weil das mobile Web wirklich schrecklich auf Webkit ausgerichtet ist. Ich wollte nur darauf hinaus, dass die Idee der Vendor-Präfixe schon nachvollziehbar ist.
Die einzige nachhaltige Lösung ist das Schaffen des notwendigen Bewusstseins bei den Entwicklern. Aber sowas ist ein schwieriger und langer Prozess, während dieses Feature relativ einfach und schnell umsetzbar ist. Das schließt sich beides auch nicht gegenseitig aus. Mozilla betreibt eh Evangelismus-Arbeit, siehe zum Beispiel:
https://twitter.com/MozWebCompat
Sprich, es wird Kontakt mit Seiten aufgenommen, die Probleme haben. Und ich denke, dass man dies auch mit den Seiten macht, die auf der Whitelist stehen, um sie dann irgendwann wieder herunterzunehmen.
Sowas Ähnliches betreibt Mozilla eh schon ganz lange: es gibt auch ein Liste mit Seiten, denen in Firefox für Android oder Firefox OS ein falscher User-Agent vorgegaukelt wird, damit die Seiten funktionieren. Diese Liste wird regelmäßig aktualisiert, was nicht nur die Aufnahme neuer Seiten bedeutet, sondern eben auch wieder das Runternehmen, sobald die Seite Anpassungen vorgenommen hat. Natürlich kann man nicht davon ausgehen, dass man jede Webseite dazu bekommt, für Firefox Anpassungen vorzunehmen. Es gibt da sehr kooperative Webseiten und Webseiten, da interessiert das niemanden.
Achja, zum Twitter-Account will ich die Webseite noch ergänzen: Quasi ein Bugtracker für das gesamte Web, nicht nur auf Firefox-Probleme beschränkt. Für Mozilla geht es eben um das Web, nicht nur um Firefox:
https://webcompat.com/
Danke Sören für die umfangreiche Ausführung. Bezüglich der Vendor-Präfixe wäre es vielleicht eine Überlegeung wert, den Einsatz auf Dev-Versionen zu beschränken. Das würde dann allerdings in der Praxis viele Webseiten „unbrauchbar“ machen. Andererseits könnte es aber auch dazu führen, dass sich Entwickler an die Standards halten müssen, aber trotzdem mit neuen Features experimentieren können. Grundsätzlich sind Vendor-Präfixe auch nicht schlecht, aber sie führen in der momentanen Situation unweigerlich zu einer Zersplitterung von CSS-Eigenschaften. Sieht man ja wunderbar auf mobilen Endgeräten. Ergo kann dem meiner Meinung nach nur eine wirkungsvolle Standardisierung entgegenwirken. Das müsste aber von der W3C kommen. Die brauchen mir ohnehin viel zu lange, um neue Features zu finalisieren.
Egal wie wir es drehen und wenden es bleibt in jedem Fall ein Teufelskreis. Mozillas Entscheidung finde ich zwar persönlich nicht besonders gut, aber andererseits versteh ich die Position dahinter. Bleibt zu hoffen, dass sich die Lage auf absehbare Zeit etwas entspannt.
Das würde in der Tat sehr viele Webseiten „kaputt machen“ und das betrifft nicht nur -webkit-Präfixe, auch -moz-Präfixe werden noch massenhaft eingesetzt, selbst für Eigenschaften, welche Firefox gar nicht mehr mit Präfix unterstützt. Denn Vendor-Präfixe sind ja eigentlich auch nicht dafür gedacht, dass sie für immer existieren. Wenn der Browser die Eigenschaft ohne Präfix unterstützt, wird die Unterstützung für die Eigenschaft mit Präfix normalerweise irgendwann entfernt. Ich hab ja schon angedeutet, dass Mozilla manche Eigenschaft hinter about:config-Schaltern implementiert und mit denen ist es tatsächlich so, dass diese Schalter zeitweise nur in Nightly und Developer Edition aktiviert sind und in Beta sowie Release nicht. Die Sache ist halt, dass sich Vendor-Präfixe nicht vermeiden lassen, solange etwas implementiert ist, was noch nicht standardisiert ist oder in der Implementierung noch vom Standard abweicht. Denn die Folgen, wenn man auf die Präfixe verzichtet und dann etwas implementiert, was vom finalen Standard (der zu dem Zeitpunkt unter Umständen noch gar nicht existiert) abweicht, sind glaube ich nicht minder fatal.
Die Standardisierung von Webfeatures dauert in der Tat wirklich sehr lange, ich weiß aber nicht, ob sich das beschleunigen lässt, alleine schon, weil Einigkeit unter verschiedenen Browserherstellern wirklich nicht immer ein leichtes Unterfangen ist. 🙂
Ich glaube, dass die Sache mit den Präfixen wunderbar funktionieren würde – in einem ausgeglichenen Markt. Das Problem entsteht meines Erachtens durch die Tatsache, dass mobil nunmal de facto *alles* Webkit ist, Android und iOS addiert ist fast der komplette Markt, das ist wie damals mit dem Internet Explorer auf dem Desktop. Und Menschen lernen bekanntlich nicht aus der Geschichte. 😉 Jetzt gibt es im mobilen Sektor ein Webkit-Monopol und Webentwickler haben kaum einen Grund dazu, sich für andere Engines zu interessieren, die Webkit-Varianten funktonieren ja *überall*. Eine wirksame Lösung wäre es sicherlich, wenn dieses Webkit-Monopol durchbrochen werden könnte, dazu braucht es ein sehr starkes weiteres Betriebssystem. Ich bin kein Freund von Windows Phone, aber für das Web wäre es sicher nicht verkehrt, wenn Windows Phone deutlich mehr Marktanteil hätte, weil es eben Nicht-Webkit ist. Und vor diesem Hintergrund finde ich auch Firefox OS spannend: man muss kein Fan von Firefox OS sein, aber für die Entwicklung des Webs wäre es sehr gut, wenn Firefox OS deutlich mehr Verbreitung hätte, weil es eben auch Nicht-Webkit ist. Wenn Webkit/Nicht-Webkit 50:50 verteilt wäre, dann wäre es einfach nicht genug, nur für Webkit zu entwickeln. Aber bis wir mit dem mobilen Markt wieder in eine ausgeglichene Situation kommen, wenn überhaupt, wird es sicher Jahre dauern. 🙁
Ich denke auch Sören das es Jahre vielleicht ein Jahrzehnt dauern würde bis der Markt ausgeglichen ist mit Webkit und ohne laßt uns überaschen aber Monopol gibts ja überall davon abgesehen, den Entwickler kann man auch verstehen er setzt auf dem Gaul den er kennt und arbeitet lieber in ein Gebiet wo er sich softwareentwicklungstechnisch spezialiert hat alles andere versucht er garnicht wenn das Systen funktioniert was er programmiert in Webkit wenn marktechnisch kein Druck besteht und es kein einfacheres Produkt gibt zum programmieren als Webkit für den Entwickler, da werden viele Entwickler nicht wechseln sei den Webkit wird aufgegeben für ein sicheres stabileres Produkt dann könnte es sein das andere Anbieter den Markt ausgleichen, ich hoffe das es was erfunden das die Webseiten endlich besser darstellt gerade für kleine Display auf den mobilen Androiden, da spielt es keine Rolle ob es Webkit macht oder ein anderer, den Enduser ist es völlig egal mit was die Entwickler die Webseiten schreiben hauptache die bockt nicht, läßt sich öffnen, aber du bist Entwickler hast fürn Sport geschrieben Sören da solltest du es besser kennen wie wie alle hier!