Was mich interessierne würde, wäre, nach welchem Schema Mozilla eigentlich bei der Nummerierung vorgehen würde. Es gab ja einen Firefox 1 (und davor ebne noch viele Versionen), 1.5, 2, 3 und jetzt ist die Rede von 3.1. Warum gibt's also zb einen Firefox 1.5 anstatt 1.1, und warum kommt gleich Firefox 3 statt 2?
Kann jemand kurz erklären, warum Firefox 4 auf Firefox 2 beruhen soll und nicht auf 3? Warum macht man sich dann überhaupt die Mühe, die 3er-Version raus zu bringen? Werden wenigstens Teile von 3 auch in 4 weiter verwendet werden?
Von Sierk Bornemann am Di, 20. Mai 2008 um 23:09 #
KHTML wird wohl sterben, weil man auch innerhalb des KDE-Teams so langsam aber sicher auf WebKit migrieren wird bzw. schon fleißig dabei ist. Es gibt Projekte, da fressen die Kinder die Eltern bzw. überholen sie irgendwann. Das hier dürfte so ein Beispiel sein. WebKit ist einfach zu verbreitet und zu populär, und KHTML fristet zu sehr ein Nischendasein. Das haben die KDE-Entwickler auch schon längst eingesehen, und deshalb wird dort wohl auch irgendwann ausschließlich WebKit eingesetzt werden. WebKit ist nicht weniger Open-Source als KHTML, auch wenn Apple einen Großteil der Entwickler stellt.
Also bisher heißt es von den KDElern immer, dass sie KHTML weiterentwickeln wollen. Ok, ob sie das tun werden, ist eine andere Frage Dennoch halte ich KHTML bei weitem nicht für so schlecht, wie es immer gemacht wird.
Von Sierk Bornemann am Mi, 21. Mai 2008 um 18:45 #
Es geht hier überhaupt nicht ums Schlechtmachen. Es geht darum, welcher von beiden Rendering Engines von den Leuten bzw. den verschiedenen Software-Projekten da draußen bzw. von der Industrie bevorzugt wird. Und das ist nun mal eben ganz offensichtlich WebKit und nicht KHTML. WebKit hat einfach eine größere Verbreitung (durch Apples strategische Entscheidung bzgl. Safari schon immer gehabt) als KHTML, und das Ganze befruchtet sich selber, weil immer mehr Interessenten dazukommen, je mehr Interessenten sich bereits für WebKit entscheiden haben. So kann das nun mal auch passieren, wenn man den Leuten die freie Entscheidung überlässt -- WebKit ist für viele Interessenten einfach attraktiver (geworden) als KHTML. Pech für KHTML, Glück für WebKit.
Siehe u.a. auch:
The unforking of KDE's KHTML and Webkit http://tinyurl.com/29vt4f
Ars at WWDC: Interview with Lars Knoll, creator of KHTML http://tinyurl.com/2ffdqb
Video: Lars Knoll and George Staikos on KHTML and WebKit http://tinyurl.com/2k7e8t http://tinyurl.com/ymodq2
George and Lars on KHTML and WebKit http://tinyurl.com/66qxsm
Von Sierk Bornemann am Di, 20. Mai 2008 um 22:01 #
Außer Marketing-Blabla, um dem eigenen Browser ein wenig Aura zu verschaffen und ihn mehr ins Gespräch zu bringen, bringt das Bestehen des ACID3-Tests nicht viel. Er sagt nichts aus, außer dass die Tests, die ACID3 bereitstellt, bestanden werden. Mehr nicht. Der Test sagt nichts darüber aus, ob die zugrundeliegenden Webstandards bzw. Spezifikationen denn tatsächlich umfassend umgesetzt worden sind. Die ACID3-Tests geben nur einen Teil dessen wieder bzw. prüfen nur einen Teil dessen ab, was die Spezifikationen hergeben. Und genau deshalb lassen sich die Firefox-Entwickler von diesem Hype nicht beirren. Weil sie ganz genau wissen, dass Opera und noch viel mehr Safari dafür Umsetzungslücken in ganz anderen Bereichen, teilweise derselben abgeprüften Spezifikationen haben. Bei Safari z.B. ist Einiges ziemlich schnell und teilweise mit heißer Nadel gestrickt umgesetzt worden, nur um nach außen hin bzgl. ACID3 sagen zu können: "Erster". Einer näher Betrachtung hält so manche Umsetzung nicht stand, weil sie im Grunde nochmal überarbeitet werden muss oder müsste. Zumal kommerzielle Browser-Hersteller wie Opera und Safari, wenn sie aus strategischen und marketingtechnischen Gründen bestimmte Features umgesetzt haben wollen, um z.B. mit dem glorreichen Bestehen des ACID3-Tests werben zu können, ganz schnell und flux ihre Entwickler auf genau die Bugs und Features ansetzen können, die gefixt werden müssen, um gerade mal eben ACID3 zu bestehen. Da Mozilla ein vollständiges Open Source Projekt ist und hier die Uhren etwas anders ticken, sollte man den Mozilla Entwicklern die Zeit einräumen, die sie benötigen, um bestimmte Features und Eigenschaften sauber zu implementieren.
du scheinst mir eine etwas verblendete Einstellung zu haben. Mozilla ist wohl ein OpenSource Projekt, aber das hält die deshalb nicht davon ab mal eben ein paar Entwickler suf ACID3 zu schicken. Und das bräuchte es noch nichtmal. Auch die Freizeitentwickler stürzen sich von selber auf die Probleme. Das Argument mit den Entwicklern dürfte wohl nichtig sein. Die Mozilla Foundation hatte 2006 übrigens Einnahmen, die zehn mal so hoch wie Operas Umsatz waren.
Du führst auch noch an, dass aufgrund der Tatsache, dass Mozilla „ein vollständiges Open Source Projekt ist [...] hier die Uhren etwas anders ticken“. Und was ist mit WebKit? Soll das etwa kein OpenSource sein? Auch da wird der Code so geschrieben, dass einigermaßen vernünftige Ergebnisse dabei heraus kommen. Gerade bei OpenSource muss aufgepasst werden, dass schlampige Umsetzung nicht zu Sicherheitslücken führt.
Was sagt also das Wettrennen aus? Es sagt etwas über die Flexibilität des Codes und die Entwicklungsumgebungen aus. Heute lassen sich anscheinend auch komplexe Probleme recht einfach lösen und in gut strukturierten Code einbinden. Dass dabei erstmal auf den Test geschiehlt wird ist verständlich und auch bei Mozilla nicht anderst. Die Spezifikation komplett um zu setzen ist eben immer noch Fleissarbeit, die eben erst dann erledigt wird, wenn Bedarf besteht oder Ressourcen frei sind. Auch das ist bei Mozilla nicht anderst.
Verabschiede dich mal von deinem Wunschdenken. Bei Mozilla findest du im gleichen Rahmen wie bei anderen lückenhafte Umsetzungen von Standards. Mozilla ist auch immer gut dabei die Werbetrommel zu rühren. Und inzwischen ist Mozilla eine Geldmaschine, von der Opera kaum träumen kann. Mozilla ist als Stiftung im Handlungsspielraum natürlich eingeschränkt, und darf mit seinem Millionen nicht machen, was sie wollen.
Von Sierk Bornemann am Mi, 21. Mai 2008 um 00:44 #
> du scheinst mir eine etwas verblendete Einstellung zu haben
Mitnichten. :-)
> Mozilla ist wohl ein OpenSource Projekt, aber das hält die deshalb nicht davon ab mal eben ein paar Entwickler suf ACID3 zu schicken.
Doch. Weil die Entwickler, die das umsetzen können, teilweise auch noch andere Aufgaben haben bzw. ihre konkreten und dringend benötigten Beiträge in der Freizeit machen und ansonsten evtl. auch mal anders eingespannt sind, z.B. durch Beruf oder/und Ausbildung. In kommerziellen Umgebungen, wo ausschließlich bezahlte Entwickler sitzen, ist das Umfeld ein etwas anderes, genau diese Entwickler und geballt mit einem ganz konkreten Problem zu befassen, wenn die Firmenleitung das so wünscht, um ein ganz bestimmtes Feature oder Problem gelöst zu bekommen. Bzgl. dieser möglichen Manpower, die punktuell eingesetzt werden kann, sieht's da bei Mozilla etwas anders aus, weil die hauptamtlich arbeitenden Mozilla-Entwickler eben auch nur in begrenzter Zahl vorhanden sind und alle anderen eben auch noch andere Berufe haben, denen sie nachgehen müssen.
> Verabschiede dich mal von deinem Wunschdenken.
Das ist kein Wunschdenken. Das habe ich u.a. heute von jemandem bestätigt bekommen, der in die internen Prozesse von Mozilla eingeweiht ist und weiß, wie die internen Kapazitäten dort verteilt sind. Um z.B. ein bestimmtes CSS-Feature umzusetzen, welches schon lange auf der Agenda steht und auch z.B. vom ACID3-Test abgefragt wird, stehen bei Mozilla derzeit angeblich z.B. nur ganze 3 Leute zur Verfügung, von denen alle drei im Moment durch andere Aufgaben oder private Pläne ein wenig gehemmt sind, dieses Feature schnell umzusetzen. Deshalb liegt es erstmal da, ein Patch ist auch schon vorhanden, und der/die Betreffende(n) arbeiten Stück für Stück an der Implementierung, und die endgültige fertige Umsetzung wird prognostiziert für die Zeit nach FF3.0. Apple und Opera haben da als Firmen ganz andere personelle Voraussetzungen als Mozilla, da kann einfach gesagt werden: aus dem und dem Grunde hat das Problem dann und dann fertig zu sein, und im Zweifel werden eben Nachtschichten eingelegt. Und das Mozilla-Projekt ist so komplex, dass nur wenige den Code überhaupt verstehen bzw. sich da reinfuddeln können, was die Sache auch nicht gerade leichter macht, wenn man "mal eben schnell" ein paar zusätzliche Leute einarbeiten will, um ein Problem schnell zu lösen. Diejenigen bei Mozilla, die tatsächlich den Code anfassen und verändern, sind welche, die sich ganz genau damit auskennen müssen, und die sind nicht einfach durch irgendwelche zusätzlichen Coder zu ersetzen. Und da hat das Safari-Team und das Opera-Team einen entscheidenden Vorteil, denn der Code der beiden Konkurrenz-Browser scheint deutlich einfacher zu verstehen und zu warten zu sein. Es dürfte wohl mit der ausschlaggebende Punkt gewesen sein, warum Apple damals auf KHTML für seinen Safari gesetzt hat und nicht auf Mozilla Code.
Ich sehe das Problem mitnichten an dem Entwicklermodell, sondern faktisch nur im Veröffentlichzeitpunkt des acid3 Tests. Da dort ein Ian Hixie am Test werkt, hat der wohl ein vitales Interesse gehabt, dass Opera und nicht Mozilla den Test besteht und hat den Test erst im März finalisiert. Eigentlich wäre ja schon im April mit Firefox 3 geplant gewesen und so spät hätte man da nicht mehr an der Rendering Engine geschraubt. Die ist ja über ein Jahr lang in unzähligen Alphas getestet gewesen, die Gecko 1.9. Käme Firefox 3 erst im August oder später, würde der Test wohl bestanden werden...
Von Sierk Bornemann am Mi, 21. Mai 2008 um 10:23 #
Ian Hickson, derzeit für Google arbeitend, vorher für Opera und davor für Mozilla, ist treibende Kraft des ACID3-Tests. Unter diesem Gesichtspunkt frage ich mich, welches angeblich vitale Interesse er haben sollte, *gegen* Mozilla zu sein oder zu arbeiten und *für* Opera. Ich denke, er hat aus seiner Zeit bei Mozilla und Opera in beiden Lagern einige Freunde und Fürsprecher, das Verhältnis dürfte ausgewogen sein. :-) Zudem ist Ian Hickson derjenige welche, der ACID3 zusammengestellt und verwaltet hat, siehe http://ln.hixie.ch/?start=1200301306&count=1 und der URL der bisherigen Draft-Version: http://www.hixie.ch/tests/evil/acid/003/ . Ian Hickson ist zudem Editor und treibende Kraft der WHATG, http//www.whatwg.org/ und der im Frühjahr letzten Jahres neu zusammengestellten W3C HTML Working Group, http://www.w3.org/html/wg/ , welche derzeit an einem Nachfolger für HTML, (X)HTML 5, arbeitet und eine große Anzahl an Mitgliedern und auch die bisherige Arbeit der WHATG übernommen hat und weiterführt. Deswegen ist Ian Hickson auch zugleich Editor der W3C HTML WG und setzt die Spezifikation, die in wesentlichen Punkten auf den bislang geleisteten Arbeiten der WHATG beruht, schriftlich ins Werk. Und hier in dieser HTML WG sitzen u.a., neben vielen anderen Leuten, u.a. auch David Hyatt (Apple) und Maciej Stachowiak (Apple). David ist Co-Editor von HTML5 und Maciej ist für Safari bzw. die Umsetzung dort zuständig. Man kennt sich also und hat regelmäßig miteinander zu tun. Dass das Rennen um den ACID3-Test auf diese Weise so ausgetragen worden ist, wie er ausgetragen worden ist, hat also möglicherweise sehr viel mit diesen persönlichen und beruflichen Verbindungen zu tun, eben weil man sich kennt und auch auf anderen Feldern zusammenarbeitet. Der Acid3-Test war noch keine Woche pressewirksam draußen (es war im Januar 2008, vorher gab's nur in eingeweihten Kreisen den Draft, an dem zu der Zeit noch kräftig herumgeschraubt wurde unter http://www.hixie.ch/tests/evil/acid/003/ zu sehen), da lieferten sich das Safari-Team und das Opera-Team öffentlich und öffentlichkeitswirksm mit viel Tam-Tam und viel Aufmerksamkeit ein Kopf-an-Kopf-Rennen, wer denn nun als Erster "Erster" schreien durfte und diesen frisch gebackenen ACID3-Test, der eigentlich noch zu frisch war und noch Fehler hatte (noch Wochen später musste der eine oder andere Test aus dieser Suite herausgenommen oder umgeschrieben werden), als erster bestehen konnte. Und, davon kann man ausgehen, bei dem Ganzen ging es den beteiligten Teams mit Sicherheit nicht darum, möglichst viel und möglichst gründlich die HTML- und CSS-Spezifikationen des W3C zu erfüllen, sondern es dürfte in erster Linie in diesen Wochen darum gegangen sein, diesen Test zu bestehen und "Erster" rufen zu können, koste es was es wolle. Man hat sich ganz zielgerichtet auf alles das gestürzt, was den jeweiligen Browser irgendwie davon abgehalten hat, ACID3 zu bestehen bzw. hat zielgerichtet alle diejenigen Bugs entfernt, die ein Bestehen von ACID3 verhinderten. Fast täglich konnte man entweder aus der Ecke von Safari oder aus der Ecke von Opera irgendwas hören oder lesen, wieviel man einem "100/100" von ACID3 mal wieder gekommen sei. Am Ende dankt man sich sogar gegenseitig für den sportlichen und amüsanten Wettkampf, siehe http://webkit.org/blog/174/scenes-from-an-acid-test/, Abschnitt "Thanks".
Liegengeblieben sind dabei so manche andere (auch nicht unwichtige) Bugs und Features, welche bei den ACID3-Tests, die ja nur einen vorbestimmten und festgelegten Ausschnitt abprüfen, gar nicht berücksichtigt werden. Teilweise sind das Fehler oder Teile von denselben oder auch anderen Webstandards, wo Mozilla bspw. ziemlich gut dasteht und am Weitesten in der Umsetzung gegenüber allen anderen Browsern ist. Diese grundsätzliche Kritik an ACID3 und diesem Rennen und Hype darum habe nicht ich alleine, sondern ich habe prominente Fürsprecher wie z.B. Eric Meyer, der zu dem Ganzen zum Beispiel Folgendes geschrieben hat bzw. an Meinung vertritt:
Meyers Meinung teile ich zu 100%, was das Rennen ums unbedingte und möglichst schnelle Bestehen der ACID3-Tests angeht (das ganze Rennen hatte ja keine 4 Wochen gedauert, dann war's entschieden). ACID3 ist ein netter Versuch. Der aber leider auf der Hälfte steckengeblieben ist. Weil er nicht umfassend ist und leider nur einen kleinen Ausschnitt abtestet. Einen Ausschnitt, den die Macher willkürlich festgelegt haben. Alles andere ist Hype.
XHR? also XMLHttpRequest kann doch schon der aktuelle FF, oder?
Sind die nativen JSON-DOM-Bindungen standardisiert, so dass die Hoffnung besteht, dass andere Browser das auch einsetzen, damit man es überhaupt benutzen kann?
Mich würde eher interessieren, wann denn nun endelich Firefox 5 fertig ist???
(nicht ernst gemeint)
Mozilla Iceweasel 2.0.0.14, Copyright (c) 1998 - 2008 mozilla.org
> ...dass Firefox 4 auf »Mozilla 2«, der Version 2.0 der Gecko-Engine beruhen soll....
Hier geht es um die Engine. Nicht um die Anwendung.
khtml fänd ich ja in ordnung, aber sich von sowas wie apple abhängig zu machen fänd ich reichlich daneben.
Siehe u.a. auch:
The unforking of KDE's KHTML and Webkit
http://tinyurl.com/29vt4f
Ars at WWDC: Interview with Lars Knoll, creator of KHTML
http://tinyurl.com/2ffdqb
Video: Lars Knoll and George Staikos on KHTML and WebKit
http://tinyurl.com/2k7e8t
http://tinyurl.com/ymodq2
George and Lars on KHTML and WebKit
http://tinyurl.com/66qxsm
was die sogenannte böse Apple Abhängigkeit angeht: Du nutzt nicht zufällig Cups? ;-)
Beste Grüße,
Holger
Er sagt nichts aus, außer dass die Tests, die ACID3 bereitstellt, bestanden werden. Mehr nicht. Der Test sagt nichts darüber aus, ob die zugrundeliegenden Webstandards bzw. Spezifikationen denn tatsächlich umfassend umgesetzt worden sind. Die ACID3-Tests geben nur einen Teil dessen wieder bzw. prüfen nur einen Teil dessen ab, was die Spezifikationen hergeben. Und genau deshalb lassen sich die Firefox-Entwickler von diesem Hype nicht beirren. Weil sie ganz genau wissen, dass Opera und noch viel mehr Safari dafür Umsetzungslücken in ganz anderen Bereichen, teilweise derselben abgeprüften Spezifikationen haben. Bei Safari z.B. ist Einiges ziemlich schnell und teilweise mit heißer Nadel gestrickt umgesetzt worden, nur um nach außen hin bzgl. ACID3 sagen zu können: "Erster". Einer näher Betrachtung hält so manche Umsetzung nicht stand, weil sie im Grunde nochmal überarbeitet werden muss oder müsste. Zumal kommerzielle Browser-Hersteller wie Opera und Safari, wenn sie aus strategischen und marketingtechnischen Gründen bestimmte Features umgesetzt haben wollen, um z.B. mit dem glorreichen Bestehen des ACID3-Tests werben zu können, ganz schnell und flux ihre Entwickler auf genau die Bugs und Features ansetzen können, die gefixt werden müssen, um gerade mal eben ACID3 zu bestehen. Da Mozilla ein vollständiges Open Source Projekt ist und hier die Uhren etwas anders ticken, sollte man den Mozilla Entwicklern die Zeit einräumen, die sie benötigen, um bestimmte Features und Eigenschaften sauber zu implementieren.
du scheinst mir eine etwas verblendete Einstellung zu haben. Mozilla ist wohl ein OpenSource Projekt, aber das hält die deshalb nicht davon ab mal eben ein paar Entwickler suf ACID3 zu schicken. Und das bräuchte es noch nichtmal. Auch die Freizeitentwickler stürzen sich von selber auf die Probleme. Das Argument mit den Entwicklern dürfte wohl nichtig sein. Die Mozilla Foundation hatte 2006 übrigens Einnahmen, die zehn mal so hoch wie Operas Umsatz waren.
Du führst auch noch an, dass aufgrund der Tatsache, dass Mozilla „ein vollständiges Open Source Projekt ist [...] hier die Uhren etwas anders ticken“. Und was ist mit WebKit? Soll das etwa kein OpenSource sein? Auch da wird der Code so geschrieben, dass einigermaßen vernünftige Ergebnisse dabei heraus kommen. Gerade bei OpenSource muss aufgepasst werden, dass schlampige Umsetzung nicht zu Sicherheitslücken führt.
Was sagt also das Wettrennen aus? Es sagt etwas über die Flexibilität des Codes und die Entwicklungsumgebungen aus. Heute lassen sich anscheinend auch komplexe Probleme recht einfach lösen und in gut strukturierten Code einbinden. Dass dabei erstmal auf den Test geschiehlt wird ist verständlich und auch bei Mozilla nicht anderst. Die Spezifikation komplett um zu setzen ist eben immer noch Fleissarbeit, die eben erst dann erledigt wird, wenn Bedarf besteht oder Ressourcen frei sind. Auch das ist bei Mozilla nicht anderst.
Verabschiede dich mal von deinem Wunschdenken. Bei Mozilla findest du im gleichen Rahmen wie bei anderen lückenhafte Umsetzungen von Standards. Mozilla ist auch immer gut dabei die Werbetrommel zu rühren. Und inzwischen ist Mozilla eine Geldmaschine, von der Opera kaum träumen kann. Mozilla ist als Stiftung im Handlungsspielraum natürlich eingeschränkt, und darf mit seinem Millionen nicht machen, was sie wollen.
Mitnichten. :-)
> Mozilla ist wohl ein OpenSource Projekt, aber das hält die deshalb nicht davon ab mal eben ein paar Entwickler suf ACID3 zu schicken.
Doch. Weil die Entwickler, die das umsetzen können, teilweise auch noch andere Aufgaben haben bzw. ihre konkreten und dringend benötigten Beiträge in der Freizeit machen und ansonsten evtl. auch mal anders eingespannt sind, z.B. durch Beruf oder/und Ausbildung. In kommerziellen Umgebungen, wo ausschließlich bezahlte Entwickler sitzen, ist das Umfeld ein etwas anderes, genau diese Entwickler und geballt mit einem ganz konkreten Problem zu befassen, wenn die Firmenleitung das so wünscht, um ein ganz bestimmtes Feature oder Problem gelöst zu bekommen. Bzgl. dieser möglichen Manpower, die punktuell eingesetzt werden kann, sieht's da bei Mozilla etwas anders aus, weil die hauptamtlich arbeitenden Mozilla-Entwickler eben auch nur in begrenzter Zahl vorhanden sind und alle anderen eben auch noch andere Berufe haben, denen sie nachgehen müssen.
> Verabschiede dich mal von deinem Wunschdenken.
Das ist kein Wunschdenken. Das habe ich u.a. heute von jemandem bestätigt bekommen, der in die internen Prozesse von Mozilla eingeweiht ist und weiß, wie die internen Kapazitäten dort verteilt sind. Um z.B. ein bestimmtes CSS-Feature umzusetzen, welches schon lange auf der Agenda steht und auch z.B. vom ACID3-Test abgefragt wird, stehen bei Mozilla derzeit angeblich z.B. nur ganze 3 Leute zur Verfügung, von denen alle drei im Moment durch andere Aufgaben oder private Pläne ein wenig gehemmt sind, dieses Feature schnell umzusetzen. Deshalb liegt es erstmal da, ein Patch ist auch schon vorhanden, und der/die Betreffende(n) arbeiten Stück für Stück an der Implementierung, und die endgültige fertige Umsetzung wird prognostiziert für die Zeit nach FF3.0.
Apple und Opera haben da als Firmen ganz andere personelle Voraussetzungen als Mozilla, da kann einfach gesagt werden: aus dem und dem Grunde hat das Problem dann und dann fertig zu sein, und im Zweifel werden eben Nachtschichten eingelegt. Und das Mozilla-Projekt ist so komplex, dass nur wenige den Code überhaupt verstehen bzw. sich da reinfuddeln können, was die Sache auch nicht gerade leichter macht, wenn man "mal eben schnell" ein paar zusätzliche Leute einarbeiten will, um ein Problem schnell zu lösen.
Diejenigen bei Mozilla, die tatsächlich den Code anfassen und verändern, sind welche, die sich ganz genau damit auskennen müssen, und die sind nicht einfach durch irgendwelche zusätzlichen Coder zu ersetzen. Und da hat das Safari-Team und das Opera-Team einen entscheidenden Vorteil, denn der Code der beiden Konkurrenz-Browser scheint deutlich einfacher zu verstehen und zu warten zu sein. Es dürfte wohl mit der ausschlaggebende Punkt gewesen sein, warum Apple damals auf KHTML für seinen Safari gesetzt hat und nicht auf Mozilla Code.
Zudem ist Ian Hickson derjenige welche, der ACID3 zusammengestellt und verwaltet hat, siehe http://ln.hixie.ch/?start=1200301306&count=1 und der URL der bisherigen Draft-Version: http://www.hixie.ch/tests/evil/acid/003/ .
Ian Hickson ist zudem Editor und treibende Kraft der WHATG, http//www.whatwg.org/ und der im Frühjahr letzten Jahres neu zusammengestellten W3C HTML Working Group, http://www.w3.org/html/wg/ , welche derzeit an einem Nachfolger für HTML, (X)HTML 5, arbeitet und eine große Anzahl an Mitgliedern und auch die bisherige Arbeit der WHATG übernommen hat und weiterführt. Deswegen ist Ian Hickson auch zugleich Editor der W3C HTML WG und setzt die Spezifikation, die in wesentlichen Punkten auf den bislang geleisteten Arbeiten der WHATG beruht, schriftlich ins Werk. Und hier in dieser HTML WG sitzen u.a., neben vielen anderen Leuten, u.a. auch David Hyatt (Apple) und Maciej Stachowiak (Apple). David ist Co-Editor von HTML5 und Maciej ist für Safari bzw. die Umsetzung dort zuständig. Man kennt sich also und hat regelmäßig miteinander zu tun. Dass das Rennen um den ACID3-Test auf diese Weise so ausgetragen worden ist, wie er ausgetragen worden ist, hat also möglicherweise sehr viel mit diesen persönlichen und beruflichen Verbindungen zu tun, eben weil man sich kennt und auch auf anderen Feldern zusammenarbeitet. Der Acid3-Test war noch keine Woche pressewirksam draußen (es war im Januar 2008, vorher gab's nur in eingeweihten Kreisen den Draft, an dem zu der Zeit noch kräftig herumgeschraubt wurde unter http://www.hixie.ch/tests/evil/acid/003/ zu sehen), da lieferten sich das Safari-Team und das Opera-Team öffentlich und öffentlichkeitswirksm mit viel Tam-Tam und viel Aufmerksamkeit ein Kopf-an-Kopf-Rennen, wer denn nun als Erster "Erster" schreien durfte und diesen frisch gebackenen ACID3-Test, der eigentlich noch zu frisch war und noch Fehler hatte (noch Wochen später musste der eine oder andere Test aus dieser Suite herausgenommen oder umgeschrieben werden), als erster bestehen konnte. Und, davon kann man ausgehen, bei dem Ganzen ging es den beteiligten Teams mit Sicherheit nicht darum, möglichst viel und möglichst gründlich die HTML- und CSS-Spezifikationen des W3C zu erfüllen, sondern es dürfte in erster Linie in diesen Wochen darum gegangen sein, diesen Test zu bestehen und "Erster" rufen zu können, koste es was es wolle. Man hat sich ganz zielgerichtet auf alles das gestürzt, was den jeweiligen Browser irgendwie davon abgehalten hat, ACID3 zu bestehen bzw. hat zielgerichtet alle diejenigen Bugs entfernt, die ein Bestehen von ACID3 verhinderten. Fast täglich konnte man entweder aus der Ecke von Safari oder aus der Ecke von Opera irgendwas hören oder lesen, wieviel man einem "100/100" von ACID3 mal wieder gekommen sei. Am Ende dankt man sich sogar gegenseitig für den sportlichen und amüsanten Wettkampf, siehe http://webkit.org/blog/174/scenes-from-an-acid-test/, Abschnitt "Thanks".
Liegengeblieben sind dabei so manche andere (auch nicht unwichtige) Bugs und Features, welche bei den ACID3-Tests, die ja nur einen vorbestimmten und festgelegten Ausschnitt abprüfen, gar nicht berücksichtigt werden. Teilweise sind das Fehler oder Teile von denselben oder auch anderen Webstandards, wo Mozilla bspw. ziemlich gut dasteht und am Weitesten in der Umsetzung gegenüber allen anderen Browsern ist.
Diese grundsätzliche Kritik an ACID3 und diesem Rennen und Hype darum habe nicht ich alleine, sondern ich habe prominente Fürsprecher wie z.B. Eric Meyer, der zu dem Ganzen zum Beispiel Folgendes geschrieben hat bzw. an Meinung vertritt:
Acid Redux
http://meyerweb.com/eric/thoughts/2008/03/27/acid-redux/
Meyers Meinung teile ich zu 100%, was das Rennen ums unbedingte und möglichst schnelle Bestehen der ACID3-Tests angeht (das ganze Rennen hatte ja keine 4 Wochen gedauert, dann war's entschieden). ACID3 ist ein netter Versuch. Der aber leider auf der Hälfte steckengeblieben ist. Weil er nicht umfassend ist und leider nur einen kleinen Ausschnitt abtestet. Einen Ausschnitt, den die Macher willkürlich festgelegt haben. Alles andere ist Hype.
Sind die nativen JSON-DOM-Bindungen standardisiert, so dass die Hoffnung besteht, dass andere Browser das auch einsetzen, damit man es überhaupt benutzen kann?
Und was ist awesomebar++?
;)