Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?

Firefox 46 gibt sich zwecks Kompatibilität teilweise als WebKit-Browser aus

Die Mozilla Foundation hat mit der Veröffentlichung von Firefox 46 auch einige Änderungen im Umgang mit Webseiten vorgenommen. Neben einer verbesserten Sicherheit im Umgang mit JavaScript durch ein optimiertes JIT betrifft dies auch die Darstellung von Webseiten. Im Fokus steht dabei die Unterstützung modernster Web-Standards in HTML5 und CSS3, die oftmals einen experimentellen Status haben und daher nur in einem bestimmten Browser funktionieren. Diese Standards sind daher mit einem Prefix wie "-ie" (Internet Explorer) oder "-webkit" (WebKit, Safari, Chrome) maskiert.

Das hindert jedoch viele Web-Entwickler nicht daran, die Standards bereits in ihrer Webseite zu unterstützen. Teilweise aus den Augen verloren wird jedoch Firefox und dessen Prefix "-moz". Als Konsequenz unterstützt daher das nun veröffentlichte Firefox 46 auch viele "-webkit"-Standards, womit Firefox-Nutzer wieder alle Funktionen von Webseiten verwenden können. Einen ähnlichen Ansatz verfolgt bereits Microsoft beim neuen Web-Browser Edge, der ebenfalls "-webkit"-Standards unterstützt. Die jetzige Situation wäre vor 10 Jahren noch undenkbar gewesen. Damals galt noch der Internet Explorer als Standard, weswegen Chrome, Firefox und Safari bis heute auch einige Microsoft-spezifischen Web-Funktionen unterstützen.

Abgesehen von dieser Verhaltensänderung bietet die Firefox-Version eine verbesserte Darstellung von Vektorgrafiken im SVG-Format sowie eine verbesserte Unterstützung von Bedienungshilfen bei der Verwendung von Google Docs. Web-Entwickler können sich außerdem über erweiterte Perfomance-Werkzeuge freuen, mit denen sich die korrekte Speicherverwaltung prüfen lässt.

Firefox 46 setzt mindestens OS X 10.6 Snow Leopard voraus und ist als Download mittlerweile 87 MB groß.

Weiterführende Links:

Kommentare

cuco27.04.16 16:56
Die Überschrift ist somit einfach falsch. Er gibt sich als Webkit und nicht als Safari aus.
0
someone27.04.16 17:14
cuco
Die Überschrift ist somit einfach falsch. Er gibt sich als Webkit und nicht als Safari aus.
Stimmt, mit Safari hat das bestimmt mal gar nichts zu tun.
Vermutlich hat es primaer sowieso mit dem Webkit Fork "Blink" welcher von Google fuer Chrome gemacht wurde zu tun...
0
vMief27.04.16 17:15
cuco
Die Überschrift ist somit einfach falsch. Er gibt sich als Webkit und nicht als Safari aus.
Wenn man es schon genau macht, gibt sich Firefox als nichts anderes aus, sondern ahmt nur nach
0
ratti
ratti27.04.16 17:32
Jetzt sind wir wieder da, wo wir vor 10 Jahren waren. Statt validem HTML/CSS geben sich Browser als „der Marktführer“ aus.
0
teorema67
teorema6727.04.16 18:14
Chrome hat mit 49:46 die Nase bei der Versionsnummerninflation immer noch vorn


cuco
... Er gibt sich als Webkit und nicht als Safari aus.
Das erinnert mich an OmniWeb. Der hat ein langes Menü mit großer Browserauswahl, für die er sich ausgeben kann.
Wenn ich groß bin, geh ich auch auf die Büffel-Universität! (Ralph Wiggum)
0
sb27.04.16 18:22
Ich habe die Überschrift korrigiert. Tatsächlich ist Firefox der letzte Browser, der im UserAgent-String noch kein Safari zu stehen hat.
🎐 Sie werden häuslichen Frieden, finanzielle Sicherheit und gute Gesundheit genießen.
0
dom_beta27.04.16 19:39
Diese Standards sind daher mit einem Prefix wie "-ie" (Internet Explorer) oder "-webkit" (WebKit, Safari, Chrome) maskiert.

Für IE nicht

-ms-

?
...
0
vMief27.04.16 20:02
dom_beta
Diese Standards sind daher mit einem Prefix wie "-ie" (Internet Explorer) oder "-webkit" (WebKit, Safari, Chrome) maskiert.
Für IE nicht -ms- ?
Korrekt, IE hat "-ms"
0
sierkb27.04.16 21:48
Eine völlig falsche Überschrift, die etwas völlig falsches suggeriert und auch im Text falsch wiedergibt. Dabei ist das Thema nicht neu, seit Jahren in der Diskussion,und auch hier bei MTN wurde schon drüber gesprochen und hitzig diskutiert.

Richtig ist: Mozilla setzt, wie schon seit einiger Zeit, in seiner Rendering-Engine bzgl. CSS zusätzlich Vendor-spezifische CSS-Aliase mit -webkit ein, welche auf dieselbe im Browser bereits verbaute und funktionierende standardkonforme Funktion und Schreibweise verweisen, wie das deren -moz-Präfixe auch tun und welche schon seit Jahren immer genau dann abgebaut und dezimiert werden, wenn die Implementierung im Browser so stabil ist, dass das -moz-Präfix überflüssig geworden ist, Mozilla kommuniziert das auch regelmäßig in seinen Developer-Dokumenten und Release-Notes für den Browser, wann wo welche -moz-Präfixe verschwunden sind oder verschwinden werden; und Opera machts seit Jahren genauso, Google seit einiger Zeit auch und Miccrosoft auch. Diese Praxis des nur vorübergehenden Einsatzes vendor-spezifischer CSS-Präfixe zu Testzwecken und dann der Abbau derselben zugunsten der generischen Schreibweise ist die auch von der CSS-Spezifikation empfohlene Praxis. Einzig und allein Apple hat es bisher nicht gemacht und die eigenen -webkit-Präfixe immer schön drin behalten, keinen Abbau betrieben und das im Gegensatz zu den anderen Herstellern auch nicht kommuniziert, sodass viele vor allem jüngere nachgewachsene Webautoren in völlig falscher Annahme und auch teilweise Ignoranz bedenkenlos das ganze -webkit-Arsenal eingesetzt haben, das sich ihnen da bot, völlig ignorierend, dass andere Browser damit nichts anfangen können und dass das eigentlich so nicht sein soll.

Jetzt, seit gestern, macht es Apple endlich, endlich anders und steuert gegen, baut diese Präfixe ab bzw. verbirgt sie hinter einem Config-Schalter beim Build, und zwar erst seit der jüngst erst rausgegebenen Safari Technology Preview, aus der stabilen Safari-Version sollen experimentelle -webkit-Präfixe wohl nach und nach verschwinden, wenn ich den betreffenden WebKit-Blog-Eintrag von Edward O'Conno/Apple richtig verstehe:

WebKit Blog (26.04.2016): Updating Our Prefixing Policy

Endlich! Wurde auch höchste Zeit, dass die sich an der Front mal bewegen und überhaupt mal einen Finger krumm machen, durch Apples Nichtstun und Nichtkommunizieren und vor allem der Faulheit und Unwissenheit vieler Inhalteanbieter da draußen ist diese prekäre Situation überhaupt erst entstanden, dass man WebKit wie damals auch dem IE hinterherlaufen muss, weil sich da durch Nichtstun des Herstellers und der Bequemlichkeit und Nichtahnung und mangelnder Sorgfalt der Inhalteanbeiter und Seitenbetreiber eine gefährliche Schieflage und Fehlentwicklung ergeben hat, die kaum mehr einzudämmen und beherrschbar ist.

Diese von langer Hand geplanten und untereinander und innerhalb der CSS-Arbeitsgruppe sehr kontrovers aber schlussendlich abgestimmte und gemeinsam getragene Maßnahme aller Browser-Hersteller gemeinsam zusammen mit dem W3C und den beiden Erfindern und Autoren von CSS (Hakon Wium Lie von Opera und dem Bert Bos vom W3C), ist eine bereits vor 2012 eingeleitete und 2012 gemeinsam beschlossene Notmaßnahme, um es nicht weiter so laufen zu lassen, da das Unheil schon da ist, der Schaden bereits angerichtet ist, Browser, die nichts dafür können, von Seiten ausgeschlossen werden, die sie eigentlich wunderbar darstellen könnten, wenn deren Betreiber nur sauber gearbeitet und sich nicht auf WebKit eingeschossen hätten sondern bedacht hätten, dass diese Präfixe ursprünglich eh nicht für die freie Wildbahn gedacht waren sondern nur zeitlich begrenzt für Testzwecke und dass es browserübergreifend eine präfix-lose Notation gibt, die alle Browser anspricht und dass diese unbedingt zu bevorzugen oder wenigstens als Fallback zu verwenden ist (noch nicht mal Letzteres ist oft passiert, weshalb diese bedauernswerte Situation überhaupt erst entstanden ist).

WebKit Blog (26.04.2016): Updating Our Prefixing Policy

sitepoint.com (13.02.2012): The Impending CSS Vendor Prefix Catastrophe

W3C CSS Arbeitsgruppen-Meeting (07.02.2012): [CSSWG] Minutes and Resolutions Paris F2F Monday Morning 2012-02-06: Administrivia, Vendor Prefixes, Property/Value Alias OM


Eigentlich wäre genanntes gestern erschienener WebKit-Blog-Eintrag eine Meldung hier wert gewesen statt über die Purzelbäume und Klimmzüge, die die Konkurrenz machen muss um sich nicht ausschließen zu lassen durch diese völlig aus den Fugen geratene Schieflage, kommt diese seit gestern veröffentlichte Änderung seitens Apples WebKIt/Safari doch von genau der richtigen Stelle und greift endlich beim eigentlichen Verursacher und Problemkind an und führt da eine signifikante und total überfällige Änderung ein. Endlich!
0
vMief27.04.16 22:00
sierkb Du schreibst immer "Apple": "Apple ist faul", "Apple macht nichts", "Apple...". Allerdings sollte man das nicht so Apple-Global betrachten, sondern vielmehr nur auf das Webkit-Team beziehen. Denn ich gehe stark davon aus, dass Tim Cook keine Ahnung vom Thema Webentwicklung hat er wird zwar wissen, was WebKit ist und wofür es eingesetzt wird, aber irgendwas am Produkt WebKit wird er kaum machen oder ändern, ebenso die anderen Führungsmitglieder.
Natürlich werden die Produkte durch die Führungsetage gelenkt, aber innerhalb dieser Grenzen werden diese Teams vollkommen autonom arbeiten, anders kann man ein solch großes Unternehmen auch gar nicht führen. Das Unternehmen, in dem ich arbeite, ich viel kleiner (Hersteller für Business-Software mit hauptsächlichem Vertrieb in den DACH-Staaten), und selbst da arbeiten die ganzen Software-Teams vollkommen autonom, unser CEO hat davon keine Ahnung. Natürlich gibt es regelmäßige Meetings der Führungskräfte, wo viele wichtige Dinge besprochen werden und die allgemeine Ausrichtung der Software festgelegt wird, aber ansonsten kann der Produkt Manager in unserem "frei" Entscheiden, was wir entwicklen sollen und was nicht.
Sehr viel anders wird das dort auch nicht sein, vor allem bei einer Sache wie WebKit, die bei Apple jetzt wirklich nicht im Fokus steht.
0
sierkb27.04.16 22:09
vMief:

Nimm die unbequemen Fakten bitte zur Kenntnis. Es IST leider so.
Lies Dir das Protokoll des 2012er-Meetings durch, da wurde auch nochmal verschärft auf Apples besondere Rolle und Verantwortung, die sie lange Zeit eben leider nicht wahrgenommen haben, sondern es haben laufenlassen in diesem Spiel hingewiesen.

Und gestern erschienener WebKit Blog-Eintrag beweist es auch, dass man da wohl erst jetzt signifikant was ändernt im Gegensatz zu zuvor.
Sicher auch mit ein Grund, warum Opera 2010 die öffentliche Bitte an Google bereits ventiliert hatte, WebKit zu forken, damit die Entwicklung zum Wohle des gesamten Webs dort weitergehe und nicht weiter auf der Stelle trete wie es lange Zeit der Fall war. Wenn man seitens Opera so zufrieden gewesen wäre, hätte man diesen öffentlichen Aufruf sicher nicht gestartet und wäre nicht der Erste gewesen, der sofort Googles WebKIt-Fork namens Blink dann eingesetzt hätte statt zu Apple WebKit zu greifen. Apple war hier einfach lange Zeit untätig, als Eigentümer, Projekverantwortlicher und führender WebKit-Verwender verantwortungslos untätig.

Alle anderen, die manch anderer da gerne noch als MItverantwortliche genannt hätte, die kommen in ihrer Verantwortung erst in zweiter Linie. Es ist zuvorderst Apples Job als Projektverantwortlicher, dass so eine Situation auf Basis des von ihnen verantworteten und geleiteten Projektes gar nicht erst entsteht, da kann man Maßnahmen ergreifen und vor allem kann man das kommunizieren. Breit, sehr breit kommunizieren. So, dass es auch der Letzte begriffen hat und entsprechend umsteuert und sich dran hält. Grad' Apple ist doch so ein PR-Talent, da erwartet man sicher nichts Unmögliches. Aber grad' im Kommunizieren jenseits der großen glitzernden Bühne ist Apple leider ein Totalausfall. Nicht zum ersten Mal. Und das wissen wir alle auch und da gibt es auch nichts dran zu beschönigen. Sondern höchstens zu verbessern und zu beloben, wenn Apple es dann tatsächlich mal gemacht hat, das Kommunizieren jenseits des Rampenlichts mit den Entwicklern und dem Rest der Welt.
0
vMief27.04.16 22:15
sierkb du hast meinen Beitrag scheinbar nicht wirklich gelesen. Ich habe nie etwas davon geschrieben, dass Apple alles gut gemacht hätte oder WebKit besser sei als andere, das habe ich nie erwähnt. Ich wollte nur klar machen, dass "Apple" und "WebKit" zwei paar Schuhe sind, nur weil WebKit ein Teil von Apple ist, heißt das nicht, dass Apple als Unternehmen das viel was macht. Die zwei/drei Webkitentwickler (wenn es denn überhaupt so viele sind) werden da vieles in Eigenregie machen, natürlich immer in einem vorgegebenen Rahmen, aber halt autonom, wie ich es oben erklärt habe. Und dieses autonome Team hat halt Mist gebaut.
0
sierkb27.04.16 22:28
vMief:

Apple ist Projektleiter von webkit.org. Apple gibt da die Richtung vor und fällt da strategische Entscheidungen, erst recht bestimmen sie, was von webkit.org in ihren Safari-Browser kommt und was nicht (schon allein das unterscheidet sich teilweise signifikant von dem, was andere aus dem Code machen). Und steht damit in der Verantwortung. Der sie unzureichend nachgekommen sind und sie einige Dinge haben schleifen lassen.
Wem diese Richtung nicht passt, kann gehen, kann was Eigenes machen, so funktioniert Open-Source. Apple hat es damals mit KDEs KHTML-Engine des Konqueror-Browsers gemacht, es geforkt und den Fork WebKit genannt. Google hat es Jahre später, als sie mit der Marschrichtung und konkreten Entwicklung von WebKit unter Apples Regie nicht mehr einverstanden waren, genauso gemacht wie damals Apple und hat seinerseits dann WebKit geforkt und den Fork WebKit genannt, Opera hatte nur drauf gewartet und ist Google sofort beigesprungen.

Was Du Dir da grad' gerne wünscht und zugunsten und zum Schutze Apples herauslesen willst, entspricht nicht den Tatsachen und nicht der Historie. webkit.org ist Apples Projekt. Unter Apples Leitung. Zwar unter Beteiligung einer Community, der auch verschiedene Firmen angehören, die für sich daraus was ableiten, aber Apple bestimmt die große Linie, bestimmt sie erst recht für deren Safari, da picken sie sich aus dem WebKit-Repository das raus, was sie brauchen und ihnen opprtun ist und was nicht, lassen sie liegen bzw. bremsen betreffende Bestrebungen aus. Deswegen gibt es den Fork Blink. Weil einige, allen voran Google und Opera nicht mehr einverstanden waren damit und mit Apple und Apples großer Linie immer öfters aneinandergerasselt waren. Das ist legitim und völlig in Ordnung. Trotzdem ist und bleibt webkit.org ein von Apple geführtes und dominiertes Projekt, die Projektverantwortlichen von WebKit.org sind alle bei Apple angestellt, sitzen u.a. in den W3C-Arbeitsgruppen bzw. sind teilweise sogar Mitautoren der Spezifikationen und bzgl. des WebKit einsetzenden Safari Browsers hat eh kein anderer das Sagen als Apple und nur Apple, Apple allein bestimmt, was da reinkommt und was nicht und das lässt sich Apple auch nicht nehmen.
0
vMief28.04.16 05:39
sierkb Wer ist Apple? "Apple Inc." ist nur eine Firma, ein Name, mehr nicht. Du sagst "Apple ist der Projektleiter", aber wer ist den jetzt der Projektleiter? Tim Cook?
0
sierkb28.04.16 11:21
vMief:

Was soll diese rhetorische Frage, Du kennst die Antwort.
Was ist an meiner Aussage "Trotzdem ist und bleibt webkit.org ein von Apple geführtes und dominiertes Projekt, die Projektverantwortlichen und federführenden Leute von WebKit.org sind alle bei Apple angestellt, sitzen u.a. in den W3C-Arbeitsgruppen, sprechen da in erster Linie im Namen von Apple und deren Interessen (machen das teilweise sogar sehr deutlich, wenn es unterschiedliche Interessen gibt), sind teilweise sogar Mitautoren der Spezifikationen" für Dich nicht zu verstehen?

Diese für das Apple'sche WebKit-Projekt verantwortlichen Apple-Mitarbeiter haben diese Position nicht ohne Grund und aus purem Jux und Tollerei inne. Auch der vorgerstrige Blog-Eintrag im WebKit-Blog von Edward O'Connor bzgl. der zukünftigen Präfix-Praxis WebKit bzw. Safari/Safari Dev Preview ist nicht von irgendeinem Dahergelaufenen geschrieben worden, sondern von einem Apple-Mitarbeiter, der diesbzgl. Verantwortung trägt und an den man sich bei Fragen wenden soll: Edward O'Connor, angestellt bei Apple. Maciej Stachowiak, Ex-Eazel, Ex-GNOMEer , eine ganze wichtige Person bei Apple, was WebKit, dessen Fortentwicklung und Integration in Safari angeht, arbeitet seit Jahren bei und für Apple, trägt dort dieses Projekt betreffend und auch Webstandards betreffend bei Apple Führungsverantwortung, ebenso wie Ex-Mozilla-Mann Dave Hyatt .
0
vMief28.04.16 11:31
sierkb Was ist an meiner Aussage für Dich nicht zu verstehen? Hast du die überhaupt gelesen? Die Kernaussage hast du bisher vollständig ignoriert. Und mit so einer Person werde ich nicht mehr diskutieren.
0
sierkb28.04.16 11:32
vMief:

Natürlich habe ich sie gelesen. Aber sie ist, so wie sie gestellt ist irrelevant, weil überhaupt nicht zielführend. Lies meine Antwort darauf. Hast Du die überhaupt verstanden?
Beschäftige Dich mal mit diesen Personen und dem was sie tun und welche Rolle sie bei Apple und in den W3C Arbeitsgruppen und der WHATWG innehaben, dann klärt sich Deine Frage von ganz alleine und dann verstehst Du auch, was und wie ich das meine, was ich geschrieben habe.

Oder/und lies mal das Blog bzw. die entsprechenden Einträge von Ex-Apple-Projektverantwortlichen Don Melton, der damals WebKit überhaupt erst gegründet hatte und Safari aus der Taufe gehoben und verantwortlich betreut hatte: . Auch dann wird Dir Einiges klarer und Du verstehst die Zusammenhänge dann besser.
0
appel_kindje28.04.16 22:23
sierkb
Jetzt, seit gestern, macht es Apple endlich, endlich anders und steuert gegen, baut diese Präfixe ab bzw. verbirgt sie hinter einem Config-Schalter beim Build, und zwar erst seit der jüngst erst rausgegebenen Safari Technology Preview, aus der stabilen Safari-Version sollen experimentelle -webkit-Präfixe wohl nach und nach verschwinden, wenn ich den betreffenden WebKit-Blog-Eintrag von Edward O'Conno/Apple richtig verstehe:

Das stimmt so auch nicht, schon in der aktuellen Safari-Version 9.1 ist -webkit an mindestens einer Stelle weggefallen. Es gibt einen Safari-Bug mit der Schriftdarstellung, den man bisher mit:

-webkit-font-variant-ligatures: no-common-ligatures;

umgehen konnte, seit 9.1 gelingt das jetzt nur noch mit:

font-variant-ligatures: no-common-ligatures;

Eine echte Verbesserung ist das aber nicht, da man nun alle Projekte mit dem Problem erneut anpassen muss. In der Safari TP ist das dahinterliegende Schriftdarstellungsproblem gelöst.
0
sierkb29.04.16 00:22
appel_kindje:

OK. Wann kam Safari 9.1 raus? 22.03.2016, vor gut einem Monat also, ziemlich gleichzeitig zur Safari Technoloy Preview, Beta-Test von 9.1 erstmalig im Januar diesen Jahres.

Wann war dieses von mir obig verlinkte außerplanmäßige Meeting der W3C CSS-Arbeitsgruppe? Am 07.02.2012. Vor 4 Jahren. Und jetzt erst rührt Apple da spürbar und zaghaft einen Finger, 4 Jahre später. Obwohl es schon damals brannte das Thema und man extra deswegen und wegen des so dringlichen Handlungsbedarfs mit möglichst rascher Umsetzung dieses Ad-Hoc-Meeting einberufen hatte. Mozilla hatte da schon gehandelt, Opera auch. Google inzwischen auch, Microsoft auch. Apple fängt jetzt erst an, zu handeln. Ganze 4 Jahre nach dieser Dringlichkeitssitzung und dem allgemeinen Konsens, asap zu handeln, sofort zu handeln. Andere Prioritäten waren Apple offenbar wichtiger trotz dieser Dringlichkeit und auch Konsens darüber ob dieser Dringlichkeit innerhalb der CSS WG und WHATWG und den dort anwesenden Vertretern der Browser-Hersteller. Noch Fragen?

Apples zögerliches und spätes Handeln, erst recht angesichts dieses stattgefundenen Brand-Meetings angesichts einer schon dort desolaten Situation und Entwicklung was das Thema angeht Anfang 2012, spricht seine eigene unrühmliche Sprache, und es gibt keine wirklich nachvollziehbare Entschuldigung dafür.
0

Kommentieren

Sie müssen sich einloggen, um die News kommentieren zu können.