Webkit slaagt volledig voor Acid3-test

De ontwikkelaars van browserengine Webkit hebben bekendgemaakt dat hun software volledig is geslaagd voor de Acid3-test. Door verbeteringen in de verwerking van Javascript wordt de test nu namelijk ook vlot gerenderd.

Tot op heden voldeed Webkit aan de eerste twee voorwaarden, maar nog niet aan de derde. De Acid3-test kent drie slaagvoorwaarden. De eerste is dat de browser gebruik moet maken van zijn standaard instellingen, de tweede is dat het eindresultaat op de pixel precies gelijk moet zijn aan de referentie-afbeelding en de laatste voorwaarde is dat de test vlot gerenderd wordt.

De afgelopen maanden hebben de ontwikkelaars verschillende performance­verbeteringen doorgevoerd in de verwerking van Javascript, het werken met de DOM en in het renderen, waardoor nu ook aan de derde voorwaarde voldaan is. De prestatieverbeteringen zijn vooralsnog alleen in een zogenoemde nightly terug te vinden.

Webkit is de eerste die volledig slaagt voor de Acid3-test. Oudere versies van deze engine worden door onder meer Apple's Safari en Googles Chrome gebruikt. Opera's Presto kan de test weliswaar correct renderen, maar geeft deze niet vlot weer. Gecko, de engine in onder andere Firefox, behaalt met de meest recente nightly op het moment van schrijven 87 van de 100 tests. De browserengine van Internet Explorer 8.0 Beta 2 heeft slechts succes bij 21 van de 100 tests.

Reacties (99)

[roelandb]

Nu nog wachten op een nieuwe firefox die deze acid3 test 100% scoort!

[Verwijderd]

Ik wacht liever op een zinvolle testsuite. Deze is volkomen kansloos omdat het niets zegt over real-life praktijksituaties. Bovendien snapt nog geen 5% van de developers hoe ze webpagina's moeten opbouwen, dus wat je exact aan deze test hebt is nog maar de vraag.

Intussen is het natuurlijk wel een mooie marketingtruc. Net alsof we er al bijna zijn...

[tuXzero]

Ik wacht liever op een zinvolle testsuite. Deze is volkomen kansloos omdat het niets zegt over real-life praktijksituaties.

Wat is voor jou dan een zinvolle testsuite? Volgens mij voldoet deze prima. De test gaan dan ook over hoe gegevens gerenderered en geïnterpreteerd moeten worden. Met name het object model en de interpretatie van JavaScript. Hierbij pakken ze best fundamentele dingen, geen uiterst onbekende features die maar enkele websites gebruiken.

Bovendien snapt nog geen 5% van de developers hoe ze webpagina's moeten opbouwen, dus wat je exact aan deze test hebt is nog maar de vraag.

De test is niet voor mensen die websites bouwen. De test is voor mensen die browsers bouwen. Als de browser bouwers zich allen 100% aan de standaard hielden dan dan hoefde je maar 1 website te bouwen die zich ook 100% aan de standaard hield en werkt de pagina wel op een miljoen verschillende browsers.

En dat is waar we, als mensen die het wel snappen, naartoe willen. Simpelweg omdat in de code nergens de naam van een browser zou hoeven staan!

[Verwijderd]

Zoals ik in een andere reactie al zei: een goede testsuite bestaat uit honderden of duizenden unit tests. Met een goede testsuite kun je overigens ook meteen laten zien hoe het wél en hoe het niet hoort te werken. Met één enkele test bestaande uit een hoop crap die je in praktijksituaties nooit tegenkomt, kun je eigenlijk niets aantonen.

Als deze test bedoeld is voor mensen die browsers bouwen, blijkt maar weer dat veel van die mensen ver weg staan van het uiteindelijke doel: dat mensen die browsers fatsoenlijk kunnen gebruiken. Dat gebruik bestaat uit real-life websites, niet aan semi-academische theorie.

Als elk van de afzonderlijke voorschriften juist wordt geïmplementeerd, slaagt een browser ook in zeer complexe situaties. Dat wil niet zeggen dat je met één complexe test kunt aantonen dat een browser de standaarden juist implementeert.

Het is eerder andersom. Als er na deze test nog één flaw wordt ontdekt in een browser, kun je alleen maar concluderen dat de test flawed is. Ik durf met veel vertrouwen in mijn oordeel nu al te zeggen dat dat het geval is.

[johnbetonschaar]

De Acid3 test bestaat ook uit honderden losse tests, het is niet zomaar een leuk css brouwsel dat heel moeilijk te renderen valt, maar heel zorgvuldig in elkaar gezet om een zo groot mogelijke subset van zowel geldige als ongeldige html, css en javascript te testen.

Nu zal het inderdaad zo zijn dat het voor een gewone gebruiker vrij oninteressant is wat deze test doet, en dat 90% van de test zo gekunsteld is dat je het nooit tegen gaat komen, maar dat maakt de test nog niet minder waardevol. Je hebt het over semi-academische theorie en dat een browser 'gewoon fatsoenlijk te gebruiken moet zijn', en dat je een browser gewoon via afzonderlijke unit tests moet testen, maar je vergeet volgens mij even hoe complex het geheel van de html, css en javascript/dom standaarden wel niet is, daar zijn gewoon geen allesdekkende test suites van te maken. En het is al helemaal niet met unit tests alleen te testen, de layout van 1 pagina hangt van veel te veel dingen af om die op functieniveau volledig te kunnen testen. Als je wilt garanderen dat browsers 'fatsoenlijk te gebruiken zijn' dan hoort daar ook bij dat ze zo goed mogelijk renderen wat de designer had bedoelt, en om dat te beoordelen zal je toch een benchmark nodig hebben. En dan is de Acid3 test beter dan helemaal geen test, en waarschijnlijk een van de uitgebreidste test suites die er beschikbaar is.

Dus ik snap je kritiek op deze test niet helemaal. Of alles in die test even belangrijk is daar kan je best van mening over verschillen, maar dat een hogere correctheidsscore op deze test altijd een goede zaak is lijkt me buiten twijfel...

[Reactie gewijzigd door johnbetonschaar op 23 juli 2024 22:38]

[Verwijderd]

De Acid3 test bestaat ook uit honderden losse tests, het is niet zomaar een leuk css brouwsel dat heel moeilijk te renderen valt, maar heel zorgvuldig in elkaar gezet om een zo groot mogelijke subset van zowel geldige als ongeldige html, css en javascript te testen.

Waarmee het meteen heel lastig te herleiden wat er precies fout is gegaan als iets niet helemaal klopt, en dus is het een test waaruit je niet heel eenvoudig de exacte fout kunt herleiden. Een fout document is fout. Nu kun je beweren dat een browser daar alsnog iets goeds van moet zien te brouwen, maar ik zie liever dus al die tests los, zodat je concrete, meetbare, losstaande tests hebt, waarin je elke gewenste functionaliteit los van context, met minimale context of met volledige context kunt testen.

Nu zal het inderdaad zo zijn dat het voor een gewone gebruiker vrij oninteressant is wat deze test doet, en dat 90% van de test zo gekunsteld is dat je het nooit tegen gaat komen, maar dat maakt de test nog niet minder waardevol.

Dat maakt de test waardeloos. Het is net zo'n zinvolle tests als kijken of een vliegtuig zou kunnen blijven vliegen als er een olifant door een motor geschoten zou worden. Wat het resultaat ook is, je hebt er weinig aan. Als je veel waarde hecht aan het resultaat, dan heb je gewoon niets begrepen van die standaarden.

Je hebt het over semi-academische theorie en dat een browser 'gewoon fatsoenlijk te gebruiken moet zijn', en dat je een browser gewoon via afzonderlijke unit tests moet testen, maar je vergeet volgens mij even hoe complex het geheel van de html, css en javascript/dom standaarden wel niet is, daar zijn gewoon geen allesdekkende test suites van te maken.

Waarom wordt het dan geprobeerd? En wat dan als blijkt dat er iets door de mazen van het net glipt? Moet de acid3 test dan worden aangepast? Alle voorgaande resultaten zijn daarmee in één klap ongeldig.

En het is al helemaal niet met unit tests alleen te testen, de layout van 1 pagina hangt van veel te veel dingen af om die op functieniveau volledig te kunnen testen. Als je wilt garanderen dat browsers 'fatsoenlijk te gebruiken zijn' dan hoort daar ook bij dat ze zo goed mogelijk renderen wat de designer had bedoelt, en om dat te beoordelen zal je toch een benchmark nodig hebben.

Daarom zou een testsuite dus moeten bestaan uit losse tests zodat gecontroleerd kan worden of alles goed werkt met geldige, ongeldige en rommeldocumenten.

En dan is de Acid3 test beter dan helemaal geen test, en waarschijnlijk een van de uitgebreidste test suites die er beschikbaar is.

Stroman. Uiteraard is elke test beter dan geen test. Een set van vele losse tests is echter alweer beter dan één test die niet alles omvat wat goed moet gaan en fout zou moeten gaan.

Dus ik snap je kritiek op deze test niet helemaal. Of alles in die test even belangrijk is daar kan je best van mening over verschillen, maar dat een hogere correctheidsscore op deze test altijd een goede zaak is lijkt me buiten twijfel...

Dan denk je aan totaal verkeerde dingen. Ik kan uit deze test niet afleiden of een browser alles goed doet wat belangrijk is. Het belangrijkst is om gestructureerde informatie op een acceptabele manier te presenteren. Het enige wat ik zie is een onzinnige set HTML code, CSS en Javascript, waaruit zou moeten blijken dat een browser aan alle standaarden voldoet. Leuk voor marketing, leuk om bij een presentatie te laten zien, onbruikbaar in de echte wereld.

[johnbetonschaar]

Waarmee het meteen heel lastig te herleiden wat er precies fout is gegaan als iets niet helemaal klopt, en dus is het een test waaruit je niet heel eenvoudig de exacte fout kunt herleiden. Een fout document is fout. Nu kun je beweren dat een browser daar alsnog iets goeds van moet zien te brouwen, maar ik zie liever dus al die tests los, zodat je concrete, meetbare, losstaande tests hebt, waarin je elke gewenste functionaliteit los van context, met minimale context of met volledige context kunt testen.

Alle onderdelen van Acid3 zijn gedocumenteerd, je kan zelfs na de test op het resultaat klikken en dan krijg je al een vrij precieze specificatie van wat er is fout gegaan. Volgens mij moet je je eens wat dieper in de test verdiepen, want het werkt niet zoals jij volgens mij denkt.

Dat maakt de test waardeloos. Het is net zo'n zinvolle tests als kijken of een vliegtuig zou kunnen blijven vliegen als er een olifant door een motor geschoten zou worden. Wat het resultaat ook is, je hebt er weinig aan. Als je veel waarde hecht aan het resultaat, dan heb je gewoon niets begrepen van die standaarden.

Sorry, maar ik vind die vergelijking waardeloos. In de css/html/dom/javascript specs ligt een enorme berg aan functionaliteit vast die een browser zou kunnen ondersteunen. Dat je nu misschien 90% van de meer exotische functionaliteit (of manier om die te gebruiken) niet dagelijks op sites tegenkomt wil nog niet zeggen dat het daarom totaal oninteressant is om te supporten en te testen. Is het niet voor die sites die er expres of bij toeval wél van gebruik maken, dan wel voor mogelijk gebruik in de toekomst. In die zin is Acid3 *juist* zinvol, bugs in veelgebruikte functionaliteit kan je met user testing ook al snel vinden.

Waarom wordt het dan geprobeerd? En wat dan als blijkt dat er iets door de mazen van het net glipt? Moet de acid3 test dan worden aangepast? Alle voorgaande resultaten zijn daarmee in één klap ongeldig.

Acid3 is geen officiele test of standaard, het is slechts wat het is: een test suite. Ik begrijp uit jouw redenering dat jij een test suite alleen maar zinvol vindt als de test de volledige specificatie dekt en 100% gegarandeerd correct is, maar in de praktijk werkt dat nou eenmaal niet zo.

Daarom zou een testsuite dus moeten bestaan uit losse tests zodat gecontroleerd kan worden of alles goed werkt met geldige, ongeldige en rommeldocumenten.

[...]

Dan denk je aan totaal verkeerde dingen. Ik kan uit deze test niet afleiden of een browser alles goed doet wat belangrijk is. Het belangrijkst is om gestructureerde informatie op een acceptabele manier te presenteren. Het enige wat ik zie is een onzinnige set HTML code, CSS en Javascript, waaruit zou moeten blijken dat een browser aan alle standaarden voldoet. Leuk voor marketing, leuk om bij een presentatie te laten zien, onbruikbaar in de echte wereld.

Het een sluit het ander niet uit, ik snap nog steeds niet wat je probleem is. Je kan uit _geen enkele_ test ter wereld afleiden of een browser alles doet wat belangrijk is. Unit tests op functieniveau vangen alleen lokale fouten, user tests alleen overduidelijke fouten en usability fouten, en integratie test suites kunnen onmogelijk compleet dekkend zijn. Als dat het argument tegen Acid3 is, dan kan je net zo goed alle test suites afschaffen en de specificaties allemaal weer ruim gaan interpreteren.

Jij noemt het zinloze functionaliteit die de Acid3 test dekt, ik noem het exotische functionaliteit die blijkbaar niet triviaal of voor de hand liggend is om in 1x goed te implementeren, gezien de moeite die browsers er mee hebben. Hoe groter ze Acid3 maken hoe beter, elke functionaliteit of soort gebruik dat eenvoudig testbaar in alle browsers werkend te maken is, is een verbetering van browsers in zijn algemeenheid.

[Reactie gewijzigd door johnbetonschaar op 23 juli 2024 22:38]

[Verwijderd]

Alle onderdelen van Acid3 zijn gedocumenteerd, je kan zelfs na de test op het resultaat klikken en dan krijg je al een vrij precieze specificatie van wat er is fout gegaan. Volgens mij moet je je eens wat dieper in de test verdiepen, want het werkt niet zoals jij volgens mij denkt.

Ik begrijp heel goed hoe de tests werken, maar ik ben het totaal niet eens met de denkwijze die erachter zit. Wat er exact wél en níét getest wordt lijkt een beetje willekeurig, en de uitgangssituatie vind ik onzinnig. Dit is gewoon niet hoe je in mijn ogen tests moet uitvoeren. Het resultaat van een test moet concreet zijn. Je moet er iets mee kunnen zeggen. Met het resultaat van deze test kun je alleen zeggen dat een browser voor de Acid3 test slaagt of niet. Whooptyfuckingdoo! Marketingkolder.

Sorry, maar ik vind die vergelijking waardeloos. In de css/html/dom/javascript specs ligt een enorme berg aan functionaliteit vast die een browser zou kunnen ondersteunen. Dat je nu misschien 90% van de meer exotische functionaliteit (of manier om die te gebruiken) niet dagelijks op sites tegenkomt wil nog niet zeggen dat het daarom totaal oninteressant is om te supporten en te testen.

Inderdaad. Er moet absoluut getest worden. Maar dan alsjeblieft met heel concrete losstaande tests, zodat je daadwerkelijk een oordeel aan het resultaat van een test kunt hangen.

Is het niet voor die sites die er expres of bij toeval wél van gebruik maken, dan wel voor mogelijk gebruik in de toekomst. In die zin is Acid3 *juist* zinvol, bugs in veelgebruikte functionaliteit kan je met user testing ook al snel vinden.

Browsermakers zullen sowieso zelf de boel goed moeten testen. Als de makers van Acid3 nou voor een bruikbare set tests hadden gezorgd, had dat ook heel wat kunnen schelen. Ze kozen er echter voor om een of ander vaag kunstwerk te maken waarmee een heel zichtbaar resultaat behaald kan worden, maar eigenlijk kun je niet veel met het resultaat. Ja je kunt zeggen dat Internet Explorer een kutbrowser is, maar ondertussen is het internet met Internet Explorer goed te besurfen. Ik denk toch dat de browserbouwers meer hebben aan een vrachtwagenlading losstaande concrete voorbeelden van hoe iets geïmplementeerd moet zijn, en unit tests om te controleren of dat ook zo is. Dat ziet er alleen niet zo spannend uit als Acid3. Het doet me een beetje denken aan "The Great Global Warming Swindle".

Acid3 is geen officiele test of standaard, het is slechts wat het is: een test suite. Ik begrijp uit jouw redenering dat jij een test suite alleen maar zinvol vindt als de test de volledige specificatie dekt en 100% gegarandeerd correct is, maar in de praktijk werkt dat nou eenmaal niet zo.

In de praktijk moet het zo zijn dat elk afzonderlijk voorgeschreven kenmerk van een standaard afzonderlijk getest wordt. Daarbovenop kun je een set tests doen van combinaties van die kenmerken en te verwachten problemen. In de praktijk zou software aan de hand van zulke tests ontwikkeld zou moeten worden.

Het een sluit het ander niet uit, ik snap nog steeds niet wat je probleem is. Je kan uit _geen enkele_ test ter wereld afleiden of een browser alles doet wat belangrijk is. Unit tests op functieniveau vangen alleen lokale fouten, user tests alleen overduidelijke fouten en usability fouten, en integratie test suites kunnen onmogelijk compleet dekkend zijn. Als dat het argument tegen Acid3 is, dan kan je net zo goed alle test suites afschaffen en de specificaties allemaal weer ruim gaan interpreteren.

Nee hoor. Je hoeft alleen maar de Acid3 test te negeren en een betere set tests te maken om je browser goed te laten functioneren. Overigens zou die de Acid3 test dan wel met vlag en wimpel moeten slagen natuurlijk, en anders is je eigen set met tests niet goed.

Het exacte doel van de Acid3 test is mij compleet onduidelijk. Ik zou daar weleens een duidelijke definitie van willen zien.

Jij noemt het zinloze functionaliteit die de Acid3 test dekt, ik noem het exotische functionaliteit die blijkbaar niet triviaal of voor de hand liggend is om in 1x goed te implementeren, gezien de moeite die browsers er mee hebben. Hoe groter ze Acid3 maken hoe beter, elke functionaliteit of soort gebruik dat eenvoudig testbaar in alle browsers werkend te maken is, is een verbetering van browsers in zijn algemeenheid.

Hoe groter de test, hoe minder concreet het resultaat wordt. Het is dan overigens niet veel anders. Je kunt op basis van het resultaat aangeven dat een browser wel of niet slaagt voor de Acid3 test, maar je kunt niet aangeven of een browser zich aan de standaarden houdt of niet.

[arendjr]

Kom op zeg, hoe moeilijk is het nou te bevatten? Een browser die slaagt voor Acid3 heeft in elk geval alle functionaliteit goed geimplementeerd die nodig is voor die specifieke test. En dat is beter dan een browser die daar niet voor slaagt.
Natuurlijk zegt dat in absolute termen niet zo veel, want een browser die niet slaagt kan in andere dingen weer goed zijn. Het enige dat je dus kunt zeggen is dat een browser die niet slaagt in elk geval duidelijke aanwijsbare problemen heeft in de ondersteuning van de functionaliteit die door Acid3 getest wordt, hetgeen als motivatie dient voor de makers van die browsers om hun implementatie te verbeteren. Dat is het hele doel van deze test.
Unit tests op klein niveau hebben alle browsers zelf al wel en zoals je kan zien hebben die ook geen volledige coverage. Vandaar dat tests zoals Acid dus waardevol zijn.

[thegve]

Unit tests op rendering gebied zijn wat anders die op applicatie niveau. Wat betreft rendering van een bekende html contructie of bepaalde HTML elementen ken ik geen gestandaardiseerde referentie-rendering of unit-test.

[ronny]

Ze kozen er echter voor om een of ander vaag kunstwerk te maken waarmee een heel zichtbaar resultaat behaald kan worden, maar eigenlijk kun je niet veel met het resultaat. Ja je kunt zeggen dat Internet Explorer een kutbrowser is, maar ondertussen is het internet met Internet Explorer goed te besurfen.

Maar hier draait het juist om!
IE is ook een kut browser, echter omdat hij zoveel wordt gebruikt worden vrijwel alle pagina's zo aangepast dat ze ondanks alle nukken van IE goed worden weer gegeven.

Dus als je een reallife test wil doen dan is dat prima, je moet dan wel een pagina hebben die geen aanpassingen heeft die specifiek werken voor aparte browsers.

Verder is er het nooit mogelijk om een test te ontwerpen die 100% de realiteit berijkt. Er zijn altijd wel omstandigheden die afwijken.
Een crashtest met auto's zijn ook niet realistisch omdat er altijd wel dingen afwijken. De snelheid, de hoek, de balading, de profiel op de banden, het weer of andere zaken.
Het geeft echter wel een beeld hoe bepaalde zaken worden afgehandeld.
Zowel zaken die wel goed geprogrameerd zijn, maar ook zaken die niet goed gaan.

[Little Penguin]

Ik ben slechts ten dele met je eens dat deze test ook weer niet alles zegt, hoewel ik het dan weer wel belangrijk vind dat de standaarden die getest worden wel gevolgt worden door alle browsers. Denk aan het feit dat IE nog steeds niet het W3C-event model volgt en dat is best wel vervelend voor de ontwikkelaar!

De Aicd-testen zijn dus weer wel handig om browser-ontwikkelaars te sturen bij de keuze welke standaarden met gaat implementeren, ik denk namelijk niet dat IE8 CSS2.1 volledig geimplementeerd zou hebben zonder de Acid2-test. Nu kunnen we vanaf 2009/2010 eindelijk zonder compromisen gebruik maken van de CSS2.1 features en dat werd toch echt wel eens tijd...

[Tjeemp]

Maar aan de andere kant is het dus wel zo dat als alle browsers 100/100 scoren er geen afwijkingen zijn tussen de verschillende versies... of zie ik dat verkeerd?

[Verwijderd]

Wat betekent dat precies voor praktijksituaties? Het zal mij de rozen interesseren of een browser slaagt in het renderen van één achterlijke brei van CSS en HTML.

Zo zijn zowel HTML als CSS niet bedoeld, en dus mág je geen enkele waarde hechten aan het resultaat.

Voorbeeldje uit de HTML 4.01 specificatie:

We discourage authors from using empty P elements. User agents should ignore empty P elements.

Wat zie je in de Acid3 test? 6 keer een leeg P element. Ongeacht of een browser het met wat CSS goed rendert of niet: de HTML code is dus niet iets wat je in de praktijk zou moeten tegenkomen. Wat moet je dan eigenlijk nog met het resultaat van de test?

Ik heb er niet eens zin in de rest van de test te analyseren. De test is gewoon onzin.

Een goede test is het stuk voor stuk bekijken van bijvoorbeeld de behandeling van bepaalde CSS properties (of eenvoudige combinaties hiervan), om te zien of de user agent zich houdt aan de voorgeschreven standaarden. Dat betekent waarschijnlijk honderden zo niet duizenden kleine testcases, ik zou het haast unit-tests noemen.

Daar kun je wél iets mee, onder de voorwaarde dat het een zinvol voorbeeld van HTML code gaat die je in een goed gemarkeerde HTML pagina kunt tegenkomen.

[Little Penguin]

Niet dat ik weet hoe de Acid3 test precies opgezet is, maar op de Acid2-test was vergelijkbare kritiek. De test zelf voldeed niet aan de standaarden (HTML e.d.) en dat was een fout van de test, tenminste dat werd beweert.

De fouten waren echter expres ingbouwd om de browsers te dwingen om foute code (op een zelfde manier) af te keuren en het zo mogelijk te maken om bijvoorbeeld CSS in de toekomst uit te breiden.

Het zal me niet verbazen dat dit soort constructies ook aanwezig zijn in de Acid3-test. Juist door dit soort constructies op te nemen en te verwachten dat ze genegeerd worden, kun je testen of men dit ook doet.

Ik heb er niet eens zin in de rest van de test te analyseren. De test is gewoon onzin.

Als deze test tot gevolg heeft dat alle browsers het W3C DOM event model ondersteunen en dat ze JavaScript op dezelfde manier behandelen (etc, etc, etc) dan vind ik deze test toch zeer zinnig.

Een goede test is het stuk voor stuk bekijken van bijvoorbeeld de behandeling van bepaalde CSS properties (of eenvoudige combinaties hiervan), om te zien of de user agent zich houdt aan de voorgeschreven standaarden.

Dat soort testen zijn er al (Official W3C CSS Test Suites), maar die zijn lang niet zo hip als een Acid-test. Verder testen die zaken alleen positief en testen dus niet wat een browser doet als er foute invoer gegeven wordt.

[Isnowiz]

Je zegt het zelf al: de test is niet wat je in de praktijk tegen zou moeten komen.
De realiteit is echter dat je zulke dingen wel tegen komt, en ook daar komen de standaarden weer in beeld. De standaarden leggen namelijk ook vast hoe fouten afgehandeld moeten worden.

Het is ook bijzonder wenselijk dat alle browsers die fouten hetzelfde afhandelen, anders krijg je gevallen waarbij een hobbyist een website in elkaar knutselt die werkt in IE, maar niet in andere browsers. Als IE zich nou aan die standaard zou houden, dan gaat die hobbyist net zo lang lopen kloten tot het goed werkt, en dan werkt het dus ook in alle andere browsers. Het creëren van uniformiteit is hier het doel.

Een test voor het goed renderen van goede code vind ik persoonlijk minder nuttig. Als een browser namelijk niet goed werkt, dan komt dat in de praktijk snel genoeg aan het licht als mensen de browser gaan gebruiken.

[Lennie]

Als IE zich nou aan die standaard zou houden

Ik denk dat het hele probleem is, dat is neit zo en Microsoft wil dat zo veel mogelijk zou houden.

In de tussen tijd moeten makers van websites wel allemaal omwegen gebruiken om het werkend te maken met IE, vanwege het marktaandeel. Tevens wordt er niet veel nieuws geimplementeerd door Microsoft.

Als we daar nou mee zouden ophouden, zouden de gebruikers die nu IE gebruiken daar mee ophouden en zouden we verder kunnen.

Maar ja, dat zal niet zo snel gebeuren natuurlijk.

[intGod]

Het is een beetje als het groene boekje, Niemand kent het helemaal van buiten en het interesseert maar weinig mensen wat er in staat en iemand die het van buiten kent krijgt geen grote waardering.

Maar het weerhoudt ons er wel van fouten te maken zoals het verwarren van "brei" en "brij". Het maakt niet uit dat er veel mensen zijn die er geen belang aan hechten. Het houdt onze taal bij elkaar.

Het geeft aan hoe dicht een browser bij de standaarden aansluit - niet alleen wat er WEL moet gebeuren maar ook wat er NIET mag gebeuren.

De ACID3 test is slechts een snapshot met voornamelijk testen die op dat ogenblik door weinig brwosers goed weergegeven worden. "Het groot Nederlands dictee" voor browsers, dus.

Verder biedt jouw vorm van unit-testing geen enkele garantie dat complexe combinaties correct behandeld worden - dat geef je zelf toe. ACID3 is een uitdaging - 5k wedstrijden hebben ook geen nut en toch maakt het mensen weer bewust van alternatieve methodes van coderen.

[BarôZZa]

Voorbeeldje uit de HTML 4.01 specificatie:

We discourage authors from using empty P elements. User agents should ignore empty P elements.

Wat zie je in de Acid3 test? 6 keer een leeg P element. Ongeacht of een browser het met wat CSS goed rendert of niet: de HTML code is dus niet iets wat je in de praktijk zou moeten tegenkomen. Wat moet je dan eigenlijk nog met het resultaat van de test?

Ik heb er niet eens zin in de rest van de test te analyseren. De test is gewoon onzin.

Dat is juist de bedoeling van de test. Het punt is dat het overgrote deel van de webdesigners zich niet 100% aan alle HTML/CSS voorschriften houdt. Het is dus de bedoeling dat de browsers op dezelfde manier vooral de fouten behandelen zodat de pagina toch op dezelfde manier gerenderd wordt. Je wilt niet weten hoeveel mensen niet weten dat de <p> dient voor paragraaf en het simpelweg gebruiken om een witregel te creëren.

Voor de rest is dit ook geen vervanging voor unittests etc, het is simpelweg een benchmark voor browsers. Dat een videokaart een hogere score haalt in 3dmark betekent ook niet dat de kaart beter scoort in alle games dan een andere kaart. Wel is het een goede indicatie.

[Reactie gewijzigd door BarôZZa op 23 juli 2024 22:38]

[Depress]

Misschien is de test van Acid 3 wel zo dat deze elementen ook echt worden genegeerd?

[Little Penguin]

Op het gebied van de getests compliancy kun je inderdaad aannemen dat de browsers hetzelfde werken. Grote kans echter dat je wel je site in standards-mode moet laten renderen omdat de browser anders toch kiest voor de "eigen" legacy keuze in plaats van het volgen van de standaarden...

[LordPan]

Dit is juist tegen de eerste vereiste van de ACID3 test.

De eerste is dat de browser gebruik moet maken van zijn standaard instellingen

Hiermee wordt dus bedoeld dat de de ACID3 test in je zogenoemde "legacy"-mode moet draaien en niet (de "oplossing" van IE8), in een speciale modus die je toch enkel voor deze test zou gebruiken.

btw.: ik vind die laatste vereiste anders wel een zeer goed pluspunt. Een browser die 50% haalt, daar programmeren ze de sites wel rond (sommige vinden dit spijtig, maar het is de realiteit), maar dat ze dit dan ook nog eens snel doen, dat is iets waar een gebruiker WEL iets aan heeft.

[Verwijderd]

IE8 draait default in standaards mode en en niet in een legacy compatibility modus.

[A Lurker]

Dat zie je verkeerd. Acid3 test maar een deel van de javascript functionaliteit die een browser zou moeten kunnen. Slagen voor de test betekent niet automatisch dat de browser alles goed doet.

Wat je wel zeker weet is dat als de browser niet slaagt voor de test, de browser zich niet (geheel) aan de standaard houdt. Verder vind ik dat de test een redelijke indicatie geeft van hoe goed javascript geimplementeerd is. Ik was er al van overtuigd dat IE6 zich een stuk minder goed aan standaarden houdt qua javascript dan firefox, opera etc en met de Acid3 test wordt dit alleen maar bevestigd.

Een nadeel van dit soort momentopnamen is dat bedrijven nu juist gaan focussen op het slagen van de Acid3 test, en minder of geen aandacht schenken aan de overige functionaliteit, hetgeen een vertekend beeld zal geven in de resultaten. Het kan dus ook best zo zijn dat webkit toch nog veel fouten bevat in de overige functionaliteit, maar iets zegt me dat het wel redelijk goed zit ermee.

[kozue]

Deze test test ook veel foutafhandeling van web browsers, dus is het wel degelijk een test tegen al die wannabe developers die foute code produceren. Als alle browsers fouten volgens de standaard afhandelen heb je geen last meer van "werkt niet in browser X" omdat sommige developers niet verder hebben gekeken dan hun eigen browsertje.

[thegve]

Ik vind dat sowieso de tijd dat elke vorm van op html lijkende rotzooi maar weer gerendered moet worden wel eens een keertje voorbij moet zijn. Websites/applicaties bouwen is gewoon een vak wat je eerst maar eens moet leren. Zolang er nog zoiets bestaat als een quirksmode zullen veel bouwers niet de moeite nemen om het goed te doen. Gelukkig doen de laatste browser-versies het in standards-compliance mode het over het algemeen al een stuk voorspelbaarder.

[Little Penguin]

Met Firefox 3.1 maakt men al wel vorderingen, maar net als bij de Acid2 test is het niet zo dat de Mozilla-ontwikkelaars zich voor hun planning laten leiden door de Acid3-test. Het is ten slotte slechts een test van een beperkt aantal features - waarbij sommigen erg handig zijn en andere meer nice-to-have.

(Bedenk daarbij dat Safari van sommige standaarden slechts een deel geïmplementeerd heeft en dan net dat deel erbij pakken dat nodig is voor het slagen van de Acid3-test...)

Ik denk dat pas met Firefox 4 (gepland ergens in 2010?) er een volledig Acid3-compliant Firefox uit zal komen, maar ik kan er natuurlijk naast zitten - men is namelijk wel druk doende om zo veel mogelijk testen ook daadwerkelijk te gaan halen. Met een score van 87 heeft men in Fx 3.1 toch al een mooie slag gemaakt t.o.v. Fx 3.0.

[stappel_]

er is al een firefox 3.1 build die 97/100 haalt. deze heeft iemand zelf gemaakt met alle patches die er in bugzilla staan. de maintainers zijn iets voorzichtiger.

[Isnowiz]

Die nieuwe javascript-engine waar ze aan werken zou er nog wel voor een paar puntjes bij kunnen zorgen...

[Parlor_Inventor]

Leuk en aardig dit nieuws, maar als webontwikkelaar zit je toch nog vast aan het legio mensen die nog IE6 gebruiken (het werkt toch?) en partijen die het niet zo hebben op het naleven van regeltjes. Daardoor zit je vast aan de subset van technologieën die alle gebruikte browsers ondersteunen, kortom, alle ontwikkelingen van na 2001 zijn maar van zeer beperkte waarde.

[Little Penguin]

Leuk en aardig dit nieuws, maar als webontwikkelaar zit je toch nog vast aan het legio mensen die nog IE6 gebruiken (het werkt toch?)

Het aantal mensen dat nog op IE6 zit, dat neemt rap af - ik denk dat het aandeel van IE6 volgend jaar september nog maar 1/3 zal zijn van wat het nu is. Over 2-3 jaar heeft IE6 dezelfde status als de andere browser die in die tijd uitgebracht is (Netscape 4.7) en wordt er geen rekening meer mee gehouden.

partijen die het niet zo hebben op het naleven van regeltjes.

Als de markt er om vraagt, dan zal men wel moeten - zeker als men zich wilt handhaven in landen als Duitsland (waar standards-compliant browsers meer dan 50% van de markt hebben...)

Daardoor zit je vast aan de subset van technologieën die alle gebruikte browsers ondersteunen, kortom, alle ontwikkelingen van na 2001 zijn maar van zeer beperkte waarde.

Zie boven, op termijn is dat dus niet het geval - verder kun je altijd nog gebruik maken van scripts als Dean Edwards IE7 die IE6 en IE7 voorzien van ondersteuning van veel CSS2 features...

[catfish]

mooi niet, er zijn nog steeds heel veel bedrijven die met IE6 moeten werken door hun inhouse webapps (meestal kan IE7 ze niet eens goed draaien)
de omzetting gebeurd gewoon niet of nauwelijks heb ik de indruk, dus zolang XP veel gebruikt wordt in bedrijven zal het zo blijven vrees ik

[Little Penguin]

Natuurlijk zijn er grote bedrijven die nog steeds met IE6 werken en dat ook nog wel even blijven doen, maar vroeger of later zullen ook zij over moeten - ik kan me niet voorstellen dat Microsoft tot in lengte van jaren IE6 zal blijven ondersteunen namelijk.

Maar dan hebben we het over grote bedrijven, het MBK zal echter wel over gaan - zij hebben slechts een paar systemen en laten de Windows-updates gewoon lopen. Ze gaan dus ook mee met de update-cycle naar IE8 etc.

Verder zullen ook grote bedrijven een overgang naar IE7 vroeger of later initieren, uiteraard nadat ze de makers van de inhouse webapps de opdracht gegeven hebben om ze IE7 (en misschien wel gelijk IE8) compatible te maken...

[edwingr]

Leuk en aardig dit nieuws, maar als webontwikkelaar zit je toch nog vast aan het legio mensen die nog IE6 gebruiken

Dat is nog geen reden om initiatieven als Acid tests te stoppen, want het zal wellicht helpen om meer eenheid in de diverse engines te bewerkstelligen tegen de tijd dat IE6 wél van het toneel verdwenen is.

[Reactie gewijzigd door edwingr op 23 juli 2024 22:38]

[sewer]

Ik krijg een deja vu van maart: nieuws: Nieuwe builds Safari en Opera slagen voor Acid3-test

Was die toen toch niet goed ofzo?

[Verwijderd]

Het is zo dat elk van de honderd subtests niet langer dan 33 milliseconden mag duren. Afgelopen maanden zaten ze de hele tijd rond de 34/35, maar nu lijkt het erop dat ze onder de 33 zijn gedoken . Vooral test 26 (performance test) en test 69 (ook performance test) waren heikele punten voor webkit. Het ziet er trouwens ook naar uit dat er geen performance test in de Acid4 test komt, n.a.v. Hixie's blog

[Reactie gewijzigd door Verwijderd op 23 juli 2024 22:38]

[Soultaker]

Dat was toen dus alleen de grafische component. Blijkbaar is er nu ook een snelheidseis. 't Is me niet helemaal duidelijk of die er toen ook was, of dat die er later bij verzonnen is.

Safari (Webkit) en Opera renderden de test dus al correct, maar nu ook binnen de tijd.

[geert1]

Toentertijd haalden ze wel 100 punten op de test, maar werd niet voldaan aan de eis dat de test vlot gerenderd moest worden. Dat is nu pas gelukt.

[unglaublich]

Waarop was dat gerucht dat IE 8.0 de test met 100/100 had gehaald dan op gebaseerd?

Hoe dan ook, de Acid 3 test gebruikt ook allemaal exotische css en javascript technieken die in real-life toch nooit gebruikt worden. Neem de score van Firefox, 87/100. Maar toch worden bijna alle pagina's precies zo weergegeven als bedoeld.

[Little Penguin]

Waarop was dat gerucht dat IE 8.0 de test met 100/100 had gehaald dan op gebaseerd?

Het is voor het eerst dat ik hoor dat er een gerucht is dat IE8 100/100 scoort in de Acid3-test. Heb je enige referentie naar dit gerucht?

Hoe dan ook, de Acid 3 test gebruikt ook allemaal exotische css en javascript technieken die in real-life toch nooit gebruikt worden.

Ze worden nog niet gebruikt, omdat een aantal van deze zaken nog niet geïmplementeerd waren (of foutief geïmplementeerd waren). Nu zullen niet alle features door iedereen gebruikt gaan worden, maar als we er zeker van zjn dat dit sort features op het merendeel van de browsers werken dan kan daar wel eens verandering in komen.

[Verwijderd]

Dat IE8 de acid3 test zou kunnen halen is natuurlijk onmogelijk.
IE8 ondersteunt geen SVG ,matig de DOM level 2 en 3 en maar heel beperkt CSS3 drafts en terwijl de ACID3 test daar al wel gebruik van maakt.
Bovendien heeft Micrsoft in IE IE8 zelfs in overeenstemming met de W3C standaarden gekozen om datgene wat ze aan CSS3 drafts gaan ondersteunen keurig met een -ms- prefix te gaan ondersteunen. Heel poitiek w3c standaards correct maar daarmee kan nooit iets in de ACID3 test worden gescoord die dergelijke elementen eigenlijk al als definiteve recommendations beschouwt.

[Little Penguin]

Heel poitiek w3c standaards correct maar daarmee kan nooit iets in de ACID3 test worden gescoord die dergelijke elementen eigenlijk al als definiteve recommendations beschouwt.

Waarmee je impliceert dat Acid3 test op compliancy t.o.v. een work in progress als CSS3 en op die manier probeer je de test zelf onderuit te halen.

Feit is echter dat alleen zaken getest worden die al 3(!) jaar in CR zijn en al veeel langer in ontwikkeling. Er is dus voldoende tijd geweest om de geteste features ook te implementeren zou ik zo denken.

Dat men de standaarden een tijd niet gevolgt heeft qua implementatie, dat kun je de schrijver van de Acid(3) test moeilijk aanrekenen vind ik zo...

[sohus]

Waarom bouwt Microsoft ook gewoon deze engine niet in?

Dan zijn we in 1x van al dat gezeur af.

[Little Penguin]

Omdat Microsoft het probleem heeft dat ze een enorme legacy moeten ondersteunen (waar ze zelf wel voor gezorgt hebben, maar dat is wat anders).

Omdat het een paar jaar er op leek dat alleen de Microsoft browser er nog toe deed zijn ontwikkelaars van (intra)net applicaties tot de, erg domme, beslissing gekomen om proprietaire mogelijkheden van IE te gaan gebruiken. Het gevolg is nu dat MS verplicht is om die legacy zooi ook te blijven ondersteunen, ondanks de roep (vanuit de markt) voor een standards-compliant browser.

Men zal dus altijd een duale browser moeten blijven maken, een deel volgt dan netjes de standaarden en een legacy deel is nodig voor de legacy-zooi vanuit het verleden...

[Darude1234]

Ze zijn nergens toe verplicht als ze een standard-compliant browser zouden maken en bepaalde website werken niet meer omdat die specifieke IE-functies gebruiken dan hebben die website bouwers snel genoeg weer een wel werkende website gemaakt.
Het is een product van Microsoft dus Microsoft mag er mee doen wat hij wil lijkt mij. Als ze morgen besluiten de normale w3c-standaarden aan te houden en al het andere te schrappen teken ik daar voor.
Momenteel zet ik gewoon een linkje op m'n website: "Ziet u deze website niet goed? Gebruik dan Firefox!"

[mor0n]

Momenteel zet ik gewoon een linkje op m'n website: "Ziet u deze website niet goed? Gebruik dan Firefox!"

Dat vind ik wel erg sneu. Alsof Firefox de king onder de browsers is. Tegenwoordig is het al niet zo moeilijk meer om een _website_ crossbrowser compatible te maken. Bij applicaties is dit een ander verhaal.

[Reactie gewijzigd door mor0n op 23 juli 2024 22:38]

[thegve]

Ik heb bij onze klanten(web-applicaties) het gevoel dat IE6 nog een marktaandeel van 90% heeft. Ik weet niet hoe het precies zit maar het zou me niets verbazen of dit aandeel is gewoon nog enorm hoog. En ik denk dat ongeveer alle ontwikkelaars het er wel over eens zijn dat de combinatie IE6 aan de ene kant en IE7/FF aan de andere kant (Safari word als "nice to have" meegetest) niet altijd even makkelijk is.

[Sgreehder]

Goh, dat zou inderdaad handig zijn. In de praktijk betekent dat wel dat heel wat websites in de fout gaat lopen. Waaronder een groot deel gemaakt met software van Microsoft. Ik denk bovendien niet dat Microsoft de kwaliteit in huis heeft om met dat soort overgangen om te kunnen gaan (volgens mij moet heel Windows dan ook weer op de schop).

[Verwijderd]

Dat zal wat zijn zeg! Microsoft die een engine gebruikt van iemand anders die beter is dan hun eigen. Zo ver gaat microsoft niet zakken.

[Parlor_Inventor]

Vooral niet als die 'iemand anders' de open source community én Apple is

[haploc]

Dat doen ze toch al constant. Ze kopen voortduren bedrijven over (zie ook met hun semantic search engine, recent) om mee te kunnen met de concurrentie.
Hun eigen engines voldoen gewoon niet.

Mvg

[mashell]

Hun eigen engines voldoen gewoon niet.

En daarom lopen hun klanten massaal over naar andere browser. Of toch niet? Er zijn 2 gewoon webstandaarden, die van het w3c en die van Microsoft.

[Wim-Bart]

Quick & Dirty?????

Eventjes je geschiedenis ophalen.... En de interface van Apple/Xerox is ook niet de oorsprong... Jamer dat Dat Digital Equipment niet meer bestaat :-)

[DoubleDot]

ik zou zeggen eindelijk, maar ik hoop dat dit zich ook in de werkelijkheid ( m.a.w een echte browser ) kan omzetten

[hugoy]

Webkit, de engine van onder meer Apple's Safari en Google Chrome, is de eerste die volledig slaagt voor de Acid3-test.

Safari en Google Chrome beta's zouden het dus al moeten hebben.

[Little Penguin]

De eerdere beta's van Google Chrome scoorden op het gebied van de Acid3 test lager dan Safari (en de bijbehorende nightly builds), de kans dat Chrome dus nu direct Acid3-compliant is, die is niet zo heel erg groot.

Nu verwacht ik wel dat binnen nu en 3-6 maanden er een Acid3-compliant Google Chrome is en natuurlijk zal er een Chromium zijn die in de tussen tijd als nightly wel Acid3-compliant zal zijn.

Aan de andere kant heeft WebKit op het gebied van sommige standaarden slechts datgene geimplementeerd, wat nodig is voor de Acid tests - het ging hierbij om SVG/SMIL gerelateerde zaken dacht ik. Op dat gebied lopen Mozilla's Gecko en Opera's Presto voor op WebKit...

[Verwijderd]

Chrome zit ook nog in Beta...

[Verwijderd]

Ik heb safari eens geprobeert maar de standaard instelling heeft cleartype en dit kon ik nergens uitschakelen, kan dus nooit pixel voor pixel identiek zijn.
Kijk maar naar het plaatje bij het artikel, de tekst er onder hoort niet in cleartype te zijn.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 22:38]

[Little Penguin]

Je moet ook niet dit screenshot als referentie nemen, maar klikken op de link - deze leid je naar een HTML-pagina die de tekst vanuit HTML ook rendert.

Op dit manier is het dus mogelijk om pixel-precies te zijn, omdat de fonts op dezelfde manier gerenderd worden. Dat er dan wel kleine verschillen zijn tussen browsers en besturingssystemen, dat moet je voor lief nemen. Ik vind dat ook helemaal geen probleem, ik ben juist tevreden met de anti-aliassed rendering van Mac OS X

Volgens mij staat dit ook ergens in de/een begeleidende tekst. Er staat ook niet voor niets een link naar de reference-rendering, de test is geslaagd als hij overeenkomt met de reference-rendering die jij oproept...

[kozue]

Het lijkt me sterk dat de test er overal 100% hetzelfde uit zou zien. Als je dat font niet hebt, wat ze daar gebruikt hebben, gaat het er toch altijd anders uit zien. Neem nou dit bijvoorbeeld, uit de code:

font: 20px Arial

Arial is een windows font. Hoe kun je nou stellen dat de test er overal hetzelfde uit moet zien als je platform-specifieke dingen nodig hebt

[Verwijderd]

Dat is toch de essentie van een standaard?

[thegve]

Dat is het punt van kozue dus. Als ik wil dan een pagina er op Linux, Mac en Windows er hetzelfde uitziet, dan helpt het niet als ik font: 20px Comic Sans; ga gebruiken, want dat kent Linux (en ik neem aan) Mac niet.

[MSalters]

Acid3 is een stupide idee. Opera Mini kan op deze nooit Acid3 compliant zijn. Mijn beelscherm is simpelweg te klein om de testimage 100% pixel-identiek te renderen. Het originele idee achter HTML is dat de auteur zijn informatie zo goed mogelijk beschrijft, zonder de exacte browser details te weten. De browser moet die HTML dan zo goed mogelijk omzetten naar iets lokaals. Dat is inherent niet pixel identiek. Acid3 valt in dezelfde categorie als de 800x600 pixel websites. Dat was ook een "standaard".

[Verwijderd]

chrome gebruikt een erg oude versie.

[NitroX infinity]

Gecko, de engine in onder andere Firefox, behaalt op het moment van schrijven 87 van de 100 tests.

Ik haal met Firefox (3.0.2 en 3.0.3) maar 71 van de 100

[user109731]

Klopt, 87/100 word in de nightlies van Firefox 3.1 gehaald

[Verwijderd]

89/100 in de laatste nightly van vandaag

De kans is groot aanwezig dat Firefox 3.1 slaagt voor de Acid3 test of in ieder geval er heel dicht tegen aan zit bij de officiële release.

/edit: experimentele builds van Fx 3.1 halen 97/100

[Reactie gewijzigd door Verwijderd op 23 juli 2024 22:38]

[Dorus]

Nee, heb hier een vraag over gesteld op het mozillaZine forum, experimentele builds halen idd. 97/100, maar daar zitten enkele patches bij die het waarschijnlijk niet zullen halen voor FF3.1. 95/100 is waarschijnlijker voor FF3.1.

Bij Mozilla gaan ze nog altijd van de filosofie uit dat je het beter of goed kan doen en anders niet. Het is natuurlijk mogelijk dat ze er wel in slagen het voor FF3.1 af te hebben, maar voor alsnog niet geheel waarschijnlijk.

Het voordeel is natuurlijk dat je bij firefox geen constructies zult aantreffen als "IF (acid3 test) {do this} else {do that}" die een tijd terug in een andere browser zat. Durft echter geen namen te noemen omdat ik mijn bron kwijt ben, en niet weet of dat er ondertussen al uit is. Wel is het duidelijk dat de browsers die voor de acid 3 test slagen daar specifiek naar toegewerkt hebben, en aangrenzende functies die niet in de acid 3 test zaten niet ondersteunen.

Ook interesant nog altijd was de opmerking van een FF3 ontwikkelaar, dat FF op het moment dat de acid 3 test uitkwam het beste scoorde. Idem voor de acid 2 test. Dus eigenlijk ondersteunde firefox de standaarden gemiddeld het beste, echter niet diegene die specifiek getest worden in de acid test's
Het staat nog steeds op mij TODO list om oude versies van Firefox/IE/Opera/Webkit te testen op de ACID test's, en te zien hoe ze op deze test's presteerde VOORDAT de acid test's uit kwamen

[TheJVH]

Misschien heb je niet alle standaard instellingen .

[Parlor_Inventor]

De stabiele versies van Firefox gebruiken altijd een stabiele (en dus oudere) versie van Gecko.

[Verwijderd]

Ik haal ook maar 71/100, maar als je op de link 'this reference rendering' klikt krijg je de kleuren versie(?) en is het wel 100/100.

[Tralapo]

Dat is een voorbeeld... Zo zou het er uit moeten zien als de browser inderdaad helemaal geslaagd is.

[Little Penguin]

Net zoals de laatste release-versie van Safari (dat is versie 3.1.2) ook slechts uitkomt op 75/100 en ook absoluut niet uitkomt op de reference-rendering. Zoals diverse anderen al aangegeven hebben gaat die 87/100 score om de nightly-builds en niet om de release versie.

Dit bericht zelf gaat ook slechts om de nightly build van WebKit en niet om Safari of Google Chrome...

[Verwijderd]

Ik haal met chrome maar 79/100...

[user109731]

Chrome gebruikt een oudere versie van Webkit. Momenteel zijn ze wel bezig met het mergen van de laatste Webkit versie, even geduld nog

[Intrique]

Komt omdat de nieuwe versie van webkit nog niet in google chrome zit.

[b19a]

Super, de engines zullen de komende maanden hun weg wel gaan vinden naar final versies!

[sandr]

Met google chorme krijg ik hier anders maar 76/100 dus die voldoet al niet aan de eerste 2 voorwaardes

[Blaise]

Daar zit ook nog niet de nieuwste versie van webkit in.