Nieuwe builds Safari en Opera slagen voor Acid3-test

Webkit komt als eerste met een publieke versie van zijn browserengine voor de volle honderd procent door de Acid3-test heen. Eerder claimden de ontwikkelaars van Opera de eerste te zijn, maar hierbij ging het om een interne build.

De ontwikkelaars van Opera zeggen binnen een week een versie van de Acid3-geschikte browser publiekelijk te zullen aanbieden.

Ondanks dat de renderengine van Webkit - onder andere toegepast in Apples Safari-browser - door de lakmoesproef heen wist te komen, zijn er door externe ontwikkelaars de nodige onvolkomenheden ontdekt in het weergeven van svg-animaties. De ontwikkelaars hopen de opensource-engine snel geheel compatibel te maken met de svg-standaard. Tijdens het testen ontdekte het Webkit-team nog een fout in de Acid3-test, die er inmiddels is uitgehaald.

Het heeft na het uitbrengen van de Acid3-methodiek, waarbij browsers uitvoerig getest worden op het correct interpreteren en weergeven van webstandaarden, begin deze maand uiteindelijk drie weken geduurd voordat de eerste browsers geheel succesvol door de test heenkwamen. De strijd om de derde plek lijkt nu te gaan tussen de ontwikkelteams van Firefox en Internet Explorer.

Reacties (95)

[E-jey]

Hopelijk worden IE8 en FF ook snel compatible met ACID3. Dat betekend dat IE namelijk ook SVG moet ondersteunen. Javascript + css + svg + html5 vormt een mooi en open alternatief voor Flash en Silverlight. Protocollen waarbij de wereld niet afhankelijk is van MS of Adobe. Ik denk dat Apple met safari nog wat marktaandeel van IE kan afsnoepen. Bedenk daarbij dat mobiele browsers ook veel gebruik maken van webkit. Ik verwacht dat het marktaandeel van IE verder zal slinken.

[Xirt]

De afhankelijkheid van Flash valt nog wel een discussie over te beginnen. Steeds meer bedrijven kiezen voor een HTML site vanwege zoekmachinevriendelijkheid en minder afhankelijkheid (van een plugin).

Overigens denk ik dat iedereen wel kan raden wie van FireFox en IE de race gaat winnen .

[Dreamvoid]

Afhankelijkheid van Flash wordt minder? Zolang de populairste site ter wereld (YouTube) op Flash draait lijkt me dat vooral wishful thinking...

[RuddyMysterious]

Hij had het over volledige sites, zoals die van bijvoorbeeld dure merken. Zeer flashy en dergelijke meer, maar niet zoekbotvriendelijk zoals al werd aangehaald. YouTube gebruikt flash enkel als mediaplayer, niet om de volledige site mee weer te geven.

[Little Penguin]

Hopelijk worden IE8 en FF ook snel compatible met ACID3

Voor IE8 kan ik niet spreken, maar reken er niet op dat deze Acid3 compatible zal zijn, niet dat dit zeer erg is - we hebben jaren kunnen leven met de non-kwaliteit van IE6 (als webdesigners dan, her en der een hack deed wonderen) en kunnen ook wel leven met een IE8 die alleen Acid2 functionaliteit ondersteund.

Firefox 3 zal op de plm 70/100 blijven hangen, omdat men nu eenmaal bijna bij een release zit. Om nu nog quick-fixes te gaan maken voor een paar Acid3-puntjes zou erg dom zijn.

Firefox zal zelf dus zo rond eind 2009 pas Acid3 compatible zijn, op dat tijdstip zal Fx4 met Gecko/Mozilla 2 uit gaan komen verwacht ik zo...

[Verwijderd]

Leuk verhaaltje van een Webkit ontwikkelaar over de Acid3 test en de positieve 'concurrentie' met Opera:

http://webkit.org/blog/174/scenes-from-an-acid-test/

[Ruuddie]

Ik vind het eigenlijk mooi om te zien dat FireFox er niet als eerste bij is. Dat laat zien dat ze professioneel aan het worden zijn, en geen tijd hebben om deze 'spelletjes' mee te spelen.

Volledige compatibility met rare combinaties is leuk natuurlijk, maar het moet geen tijd gaan wegsnoepen van zaken die er wel toe doen, zoals misschien security en rendersnelheid. Bovendien gaat het erom dat hun finals support hebben hiervoor, tussentijdse betas (nightlies vaak zelfs) gebruikt toch amper iemand.

[DJ Henk]

Het is misschien een spelletje, maar dat wil niet zeggen dat er niets serieus achter zit.

Aan de ene kant is het gewoon een principekwestie. Ook bij mozilla hebben ze jarenlang (terecht) gekankerd op de slechte ondersteuning van standaarden in explorer. Nu ze dan een keer niet meer winnen en niet de stoere jongens van de buurt zijn, gaan ze opeens net doen alsof het allemaal niet zo belangrijk is.

En dat is slecht, want aan de andere kant is het gewoon ook echt belangrijk. Standaarden zijn er om na te leven. Aan een intepretatie van wat jij belangrijk vindt heeft niemand iets. Nu moet er dan weer een defacto-standaard groeien over wat echt de standaard is, terwijl we dat net met zijn allen hebben vastgelegd. Dat is natuurlijk onzin.

Want bij Mozilla hebben ze verder ook de wijsheid niet in pacht. Het web wordt nu gebruikt op manieren die een aantal jaar geleden door maar weinig mensen voorgesteld werd. Misschien worden in de toekomst hele andere onderdelen van de techniek belangrijk. Zou wel fijn zijn als het dan allemaal gewoon werkt als afgesproken.

[fraaije]

Nu ze dan een keer niet meer winnen en niet de stoere jongens van de buurt zijn, gaan ze opeens net doen alsof het allemaal niet zo belangrijk is.

Waaruit maak jij op dat Mozilla het niet belangrijk vind om de Acid test te halen?
Bron? Linkje? Of kun je het niet onderbouwen?

Misschien zijn ze wel met man en macht bezig om hun browser compatible te maken.

[Verwijderd]

Het is misschien een spelletje, maar dat wil niet zeggen dat er niets serieus achter zit.

De laatste paar dagen is er een heuse compititie geweest tussen Opera en Webkit, nipt (verschil van een paar uur gewonnen door Webkit Opera). Wel met een internal build, maar toch... Knappe prestatie.

/edit: I stand corrected. Door een kleine aanpassing van de test haalt Opera 99%.

Ook bij mozilla hebben ze jarenlang (terecht) gekankerd op de slechte ondersteuning van standaarden in explorer. Nu ze dan een keer niet meer winnen en niet de stoere jongens van de buurt zijn, gaan ze opeens net doen alsof het allemaal niet zo belangrijk is.

Dit is compleet onzinnig. Mozilla heeft de standaarden zeer hoog in het vaandel staan, ze scoren nou all 71% op de Acid3 test. Slecht is dat zeker niet te noemen. Ik denk dat het voor 99,9% van devvers en end-users meer dan voldoende is. Acid3 test, zoals hierboven al uitgebreid gezegd, een hele hoop uitzonderingen en theoretische situaties. Dat neemt natuurlijk niet weg dat ik Firefox 3 ook graag zou zien slagen in de voor de Acid 3 test.

Maar.... Firefox 3 zit nou tegen het einde van de ontwikkelcyclus aan (release waarschijnlijk in juni). Het zou onverantwoord zijn om zulke grote core features nou nog te gaan implementeren. Het gevaar op regressies ((render)fouten t.o.v. van Firefox 2) is dan levensgroot, ook de stabiliteit van de nightly's zal dan naar alle waarschijnlijk in gevaar komen. Iets dat onbespreekbaar is tijdens het laatste stadium van de ontwikkeling.

Ironisch genoeg was dit ook het geval toen de Acid 2 test gepubliceerd werd, toen was Mozilla ook al bezig met het laatste stadium van hun release.

En dat is slecht, want aan de andere kant is het gewoon ook echt belangrijk.

Het zou nog veel slechter zijn om Firefox 3 nou nog verder uit te stellen om alleen slechts voor één enkele test te slagen. Firefox 2 is onderhand achterhaald en is hard toe aan vervanging van Firefox 2. Nou zeg je, Firefox 2 achterhaalt? Ja, als je de nightly's of beta's van Firefox 3 een paar dagen probeert, weet je waarom.

Standaarden zijn er om na te leven. Aan een intepretatie van wat jij belangrijk vindt heeft niemand iets. Nu moet er dan weer een defacto-standaard groeien over wat echt de standaard is, terwijl we dat net met zijn allen hebben vastgelegd. Dat is natuurlijk onzin.

De standaarden zijn nou toch wel beter gespecificeerd dan eerst. Er is (gelukkig) minder ruimte voor eigen interpretatie.

Want bij Mozilla hebben ze verder ook de wijsheid niet in pacht.

Uiteraard niet. Een klein recent voorbeeldje. Een tijdje terug is de spec van XHR (cross-site XmlHttpRequest) veranderd door de W3C in een laat stadium. Firefox 3 had al in zeer grote mate ondersteuning voor XHR. Echter, door de verandering van de specificatie is gisteren besloten om het uit Fx 3 te halen. In beta 5 zal dit dus ook niet meer aanwezig zijn. Ze hebben liever geen ondersteuning dan halve (waarschijnlijk onveilige) ondersteuning.

Als laatste wil ik opmerken dat het een zeer knappe prestatie is van zowel Opera als Webkit. Echter, ik heb zeer sterk de indruk dat er gericht gepatched is aan de hand van de Acid 3 test en ik heb zeer grote vraagtekens of dat wel de juiste aanpak is. Overigens, Opera 9.5 zal niet slagen voor de Acid 3 test. De internal build waarvan de screenshot beschikbaar is, is bestemd voor Opera 10. Opera 9.5 is net als Fx 3 bijna klaar. Daarom zullen ze daar ook niet meer de kans op regressies (begrijpelijkerwijs) willen riskeren.

Voor meer informatie over de beweegreden van Fx 3 om niet te slagen, raad ik jullie aan om de blog van Mike Shaver te lezen.

[Reactie gewijzigd door Verwijderd op 26 juli 2024 03:05]

[sjaakaq]

Je gaat er hier vanuit dat Opera en WebKit dit ten koste laten gaan van security en snelheid. Te zien aan de huidige stand van zaken (bijv. qua renderingssnelheid) is dit niet het geval, aangezien Opera en WebKit gebruiker Safari allebei sneller renderen dan Firefox.

Verder: de beta's van nu zijn de finals van morgen hè

[graey]

Ehm, het is geen Microsoft, bij de meeste andere bedrijven zit er nog wel wat verschil tussen de beta's en de finals.

[arjankoole]

in opensouce land kun je met enige regelmaat een alpha nog draaien in productie ( ja, jongens krijg maar een collectieve rolberoerte).

ik heb vaak beta's in productie gedraaid, met name de nodige FreeBSD releases, en daar heb ik nooit nooit spijt van gehad, zo goed werkte dat spul.

[QkE]

Ehm. Over beta's gesproken. Heb je de nieuwste beta of nightly van ff al geprobeerd? Ik geloof dat tests laten zien dat ff sneller is dan Opera en Safari/Webkit.

[ppl]

Over welke tests hebben we het dan?

Als ik het hier op mijn Mac bekijk dan bungelen Opera en Firefox toch aardig achter Safari aan qua snelheid. Op Ubuntu Linux is Firefox sneller (andere Gecko browsers zijn nog rapper) en Opera weer langzamer dan op de Mac; Safari draait er niet op. Op Windows is Opera het snelste, daarna Firefox. Safari heb ik nog niet echt aan de tand kunnen voelen maar die lijkt het even goed te doen als Opera. Punt is echter dat dit allemaal gewoon gebruikstesten zijn en niet daadwerkelijke benchmarks. Ik zou die graag wel eens willen zien, dan zou ik die eventueel ook zelf kunnen doen.

[Dingen]

Volledige compatibility met rare combinaties is leuk natuurlijk

Rare combinaties? We hebben het hier over web standaarden, dat is waar de Acid tests op toetsen. Daar is niks raars aan en zou bovenaan het lijstje van elke browserfabrikant moeten staan.

maar het moet geen tijd gaan wegsnoepen van zaken die er wel toe doen, zoals misschien security en rendersnelheid.

Hehe, de teams van Opera en Safari hebben op die vlakken natuurlijk weinig te winnen, want het zijn al de snelste browsers op de markt.

[Verwijderd]

Jouw opmerking klinkt logisch. Maar toch krijg ik het gevoel dat ik ook altijd krijg bij Apple fanboys, die alles omdraaien om het goed te laten klinken.. sorry hoor.

[Verwijderd]

Omdat? Ze niet voor de Acid3 test slagen (die pas 1 maand uit is)?

[boner]

toch geinich om te zien dat een klein team wel een goede browser kan bouwen terwijl de grote jongens het niet kunnen.

zouden MS en FF toch teveel ingezet hebben op features en de core hebben laten liggen?

[user109731]

zouden MS en FF toch teveel ingezet hebben op features en de core hebben laten liggen?

IE ondersteunt veel standaarden (SVG, etc.) gewoon helemaal niet. Bij Firefox zijn het denk ik vooral fouten/tekortkomingen in de implementatie hiervan. Daarbij komt dat Acid3 kwam op een voor Mozilla ongelukkig moment: aan het eind van de Firefox 3 cycle. Het is niet handig om dan nog je core overhoop te halen

[IStealYourGun]

Staat de render engine niet los van Firfox zelf en is dat niet de zelfde als in mozilla wordt gebruikt?

[Daos]

De renderengine (gecko) is weliswaar los van firefox, maar ze hebben dezelfde planning. In firefox 3 zit de nieuwe gecko 1.9.

Het is niet handig om dan nog je core overhoop te halen

Klopt helemaal. Het is zelfs zo dat een volledige ACID3-ondersteuning binnen 3 weken (wat die andere bedrijven gedaan hebben) niet goed kan zijn voor de software. Even snel veranderingen doorvoeren gaat bijna nooit goed en zorgt juist voor meer fouten in je software. Dit is goed te zien bij de updates van Windows. De meeste updates worden goed getest, maar de snelle updates (hotfixes) maken soms wat stuk.

[smokalot]

De opera engine ken ik niet (die kent alleen opera zelf immers, het is geen vrije software), maar van WebKit weet ik dat het relatief schone code is. Gecko doet veel meer moeite om compatibel te zijn met de quirks van Internet Explorer, WebKit is minder uitgebreid, en er zitten minder uitzonderingen in om quirks op te vatten (dus minder compatibel), maar het is wel een stuk makkelijker om dit soort testcases snel doch goed te implementeren.

Dit is overigens een nightly build van WebKit, er gaat echt nog wel goed getest worden voor deze uberhaupt vrijgegeven gaat worden.

[arjankoole]

[quote[WebKit is minder uitgebreid, en er zitten minder uitzonderingen in om quirks op te vatten (dus minder compatibel)[/quote]

me dunkt dat het ook niet de bedoeling is dat je compatible bent met de waardeloze implementatie van standaarden door Microsoft (uitgezonderd IE8 vooralsnog, die zou wel eens goed kunnen worden), maar dat je compatible bent met de standaarden van W3C.

Je maakt dezelfde klassieke fout die webbouwers vele jaren hebben gemaakt: we maken het alleen voor IE, want MS bepaald de standaard, die rare mensen bij W3C moeten ophouden met zeuren.

Inmiddels lijkt het veld 180 graden omgedraaid te zijn (thank the big router in the sky), naar volledige standaarden acceptatie.

[Huppie]

@arjankoole:
Jij maakt dan ook weer een klassieke fout, jij denkt namenlijk dat deze 'standaarden' er al jaren zijn & waren en dat er al genoeg testcases zijn die testen of de standaard correct is geimplementeerd. Niets is minder waar

- Waarom zou ik een website ontwikkelen die het niet doet in de #1 browser ter wereld?
- Waarom zou ik een browser ontwikkelen die zich 100% strikt aan de standaard houdt terwijl 90% van de websites (en de ontwikkelaars) dat niet doen.

- Hoe kan men verwachten dat ik een browser ontwikkel die de standaard 'goed' implementeerd als er geen (of zeer weinig) test-cases beschikbaar zijn die testen hoe een standaard geimplementeerd is?

Lees het volgende artikeltje eens rustig door en denk maar eens over na
Martian Headsets

[Reactie gewijzigd door Huppie op 26 juli 2024 03:05]

[markg85]

- Waarom zou ik een website ontwikkelen die het niet doet in de #1 browser ter wereld?
- Waarom zou ik een browser ontwikkelen die zich 100% strikt aan de standaard houdt terwijl 90% van de websites (en de ontwikkelaars) dat niet doen.

1. zou ik ook niet doen
2. lomp argument! helaas werkt 90% van de mensen met een browser die de standaarden niet of niet goed ondersteunt en omdat je met een site nou eenmaal voor zoveel mogelijk mensen goed zichtbaar wil zijn maak je maar een brakke site die overal goed uit de renderer komt. Ik zelf maak eigenlijk alleen nog maar sites met FF goed werken. IE kan me niet schelen. Als alle ontwikkelaars dit dedan had je:

Of snel een nieuwe ie die wel normaal naar standaarden luisterd (IE8 misschien)
Of geen IE meer (lijkt me het beste).

[Nickname55]

@Huppy
Als je niet ontwikkeld volgens de standaard maar volgens de manier die de grootste browser op dat moment wilt, zadel je je eigen op met veel extra werk. Immers, in die browser doet je web site het op dat moment wel goed. Maar in alle andere browsers niet of matig. Gevolg: klagende gebruikers. Gebruikers willen niet gedwongen worden om een bepaalde besturingssysteem / browser te gebruiken. Als men een Mac wilt kopen dan wil men een Mac kopen. Daarnaast nog het belangrijkste, je website werkt wel goed in die grootste browser op dat moment, maar wie zegt dat dat de grootste browser blijft en wie weet gaat die grootste browser in de toekomst zijn "eigen standaard" wel iets veranderen. Dan werkt het opeens ook niet meer en zal je hem moeten aanpassen. Dat zie je bij IE 8.

[Reactie gewijzigd door Nickname55 op 26 juli 2024 03:05]

[Huppie]

@Nickname55
Maar hoe maak ik nou een website 'volgens de standaard' als ik vervolgens nergens een test-case heb waarin ik mijn website kan testen?

Ok, er zijn de 'validators' maar deze testen puur op syntax. Hoe weet ik dan of mijn website goed weergegeven wordt door 'alle' browsers? nietniet

Het enige wat je kunt doen is je website testen, in <tig> browsers die de standaard implementeren (allemaal op hun eigen manier, en allemaal maken ze (menserlijkgewijs) fouten, zei het 'bugs', zei het 'meningsverschillen in de implementatie omdat de standaars simpelweg niet duidelijk genoeg is'.

Het web is ooit groot geworden door het idee dat iedereen websites kan maken, en kan onderhouden. Maar je gaat mij niet vertellen dat iedereen die (ooit) een website gemaakt heeft de specificatie volledig heeft gelezen en begrepen.

Neem nu een gemiddelde kennis uit je vriendenkring die *ooit wel iets* met een website gedaan heeft... en bedenk je of hij dit begrijpt:


Het enige wat je kunt doen is je website testen, in <tig> browsers die de standaard implementeren (allemaal op hun eigen manier, en allemaal maken ze (menserlijkgewijs) fouten, zei het 'bugs', zei het 'meningsverschillen in de implementatie omdat de standaars simpelweg niet duidelijk genoeg is'.

Het web is ooit groot geworden door het idee dat iedereen websites kan maken, en kan onderhouden. Maar je gaat mij niet vertellen dat iedereen die (ooit) een website gemaakt heeft de specificatie volledig heeft gelezen en begrepen.

Neem nu een gemiddelde kennis uit je vriendenkring die *ooit wel iets* met een website gedaan heeft... en bedenk je of hij dit begrijpt:

If a sibling block box (that does not float and is not absolutely positioned) follows the run-in box, the run-in box becomes the first inline box of the block box. A run-in cannot run in to a block that already starts with a run-in or that itself is a run-in.
bron

Ik ken nog genoeg (nederlandse) web-ontwikkelaars die dat niet volledig begrijpen, en al helemaal niet weten hoe ze dit nou toe kunnen passen. Oftewel... er is een test-setup nodig die de standaard volledig implementeerd, exact zoals ie bedoeld is (het referentiemodel). Hierin kunnen dan websitemakers hun gemaakte website testen en dan weten ze gelijk hoe het er bij iedereen uit moet zien

Maar zolang dit referentiemodel er nog niet is (waarschijnlijk komt het er nooit) is het terecht dat web-ontwikkelaars rekening houden met de browsers die *het meest* gebruikt worden

Verder... met je voorbeeld van IE8 heb je het precies bij het juiste punt (zie ook het artikel).

[Reactie gewijzigd door Huppie op 26 juli 2024 03:05]

[Verwijderd]

Klopt helemaal. Het is zelfs zo dat een volledige ACID3-ondersteuning binnen 3 weken (wat die andere bedrijven gedaan hebben) niet goed kan zijn voor de software. Even snel veranderingen doorvoeren gaat bijna nooit goed en zorgt juist voor meer fouten in je software.

De standards zelf zijn al ouder dan 3 weken, dus die bedrijven kunnen er wel al langer aan de slag mee zijn. Of ga jij voor het implementeren van een nieuwe standaard wachten tot er een acid-test voor is ? Als je je software trouwens goed hebt opgebouwd had je waarschijnlijk al wat kunnen experimenteren met de eerste drafts van die standards.

[fraaije]

FireFox maakt gebruik van de Gecko engine. Netscape is in 1997 begonnen met het ontwikkelen van deze render engine.
Sinds 2003 is Mozilla de drijfveer achter de ontwikkeling van deze render engine.
De ontwikkelaars van Mozilla moeten dus zowel FF als de Gecko engine ontwikkelen.
Opera maakt overigens ook gebruik van een eigen engine genaamd Presto.

[t-h]

Daarbij komt dat Acid3 kwam op een voor Mozilla ongelukkig moment: aan het eind van de Firefox 3 cycle. Het is niet handig om dan nog je core overhoop te halen

dat lijkt me toch wel mee te vallen. ik heb de laatste WebKit geïnstalleerd, die om zijn engine heen gewoon Safari 3.1 gebruikt. Het zou voor Apple een kleine moeite moeten zijn om die engine met de Safari installer mee te leveren, gezien de moeite die ik niet heb hoeven doen om het werkend te krijgen. Daarop gebaseerd durf ik hetzelfde over Firefox te zeggen. Firefox kan nu de laatste Beta de deur uit is best een beter ontwikkelde Gecko-engine implementeren in een RC of Gold versie van Firefox 3.

[SED]

dus je gaat tussen de betacyclus en de RC cyclus de renderengine aanpassen en denkt dan dat ales goed omt?
Dat was zo ongeveer de netscape methodiek, de uitvinders van publieke betas die uiteindelijk roemloos ten onder zijn gegaan.
Lijkt me dus niet zon sterk plan

[frickY]

Alsof dit enige indicatie is voor het zijn van een mooie browser?

Het gaat uiteindelijk allemaal om marktaandeel, en dus gebruiksgemak, stabiliteit, snelheid, geheugenverbruik, en dat soort dingen waar de consument last van heeft.

Ontwikkelaars hebben er niets aan dat deze browsers door de test komen. Het meerderheid van de gebruikers heeft een browser die er niet doorheen komt, welke je toch echt zult moeten supporten.

[smokalot]

Gebruikers kiezen welke browser ze gebruiken, en mij lijkt dat standaardencompatibiliteit een van de belangrijke eigenschappen is waarop je kiest. Het marktaandeel van deze browsers zal dus groeien. Ontwikkelaars kiezen een subset van de webstandaarden om mee te ontwikkelen, hoe groot die subset is, en hoeveel rekening je moet houden met foutieve interpretaties is afhankelijk van wat mensen gebruiken. Dat Internet Explorer ook zijn best doet om redelijk concurrerend te zijn (ze moeten wel), zorgt ervoor dat je in de toekomst een steeds groter deel van de webstandaarden gewoon kunt gebruiken, en dat je steeds minder rekening hoeft te houden met specifieke browsers.

[Huppie]

Gebruikers kiezen welke browser ze gebruiken, en mij lijkt dat standaardencompatibiliteit een van de belangrijke eigenschappen is waarop je kiest.

Ik denk toch dat gebruikers gewoon gebruiken wat het beste werkt. Of dit nou met standaardencompatibiliteit te maken heeft of niet.

Aangezien IE nogsteeds veruit de meeste websites goed weergeeft denk ik dan ook niet dat IE snel z'n positie als marktleider kwijt is. De 'power-users' stappen misschien massaal over, de 'gewone gebruiker' klikt gewoon op het icoontje 'internet'

[t-h]

Ik denk toch dat gebruikers gewoon gebruiken wat het beste werkt.

eigenlijk zeg je zelf al waarom je daarin geen gelijk hebt:

... de 'gewone gebruiker' klikt gewoon op het icoontje 'internet'

IE werkt niet het beste. Niet qua standaarden, zeker niet qua interface en features. Ach

[SED]

IE wertk erg goed en is zeker een van de snelste.
95% van de websites doen het goed in IE en hoe zou dat komen?
Gebruikers hebben geen weet van standaarden en al helamaal geen behoefte daaraan. Dat tweakers geen normale gebruikers zijn doet daar niets aan af.

[Blokker_1999]

acid zijn mooie testen maar zeggen niet alles. De ontwikkelaars van Opera en webkit hebben veel tijd en moeite gespendeerd om de acid 3 test correct te laten renderen, maar dat betekend nog niet dat zij voldoen aan alle standaarden, enkel op de punten die specifiek getest worden. Vooral webkit is in het verleden al aangehaald als een engine die wel de acid tests goed renderd maar dan toch steken laat vallen op gewone websites.

[stewie]

ze gaan met de acid test systematisch door alle standaarden, dus de bedrijven die hun browser updaten hebben in de toekomst betere ondersteuning voor de standaarden dan andere.

het is gewoon een soort competitie voor standaard aannamen.

[Maurits van Baerle]

Maar niet alles wordt getest. Slagen voor ACID3 betekent niet dat je alle standaarden juist afhandeld, alleen die specifieke delen van die waarop wordt getest, het zijn maar een kleine 110 tests...

Het is heel goed mogelijk om te slagen voor ACID3 en toch basale fouten te hebben in je HTML of CSS afhandeling.

De kritiek van sommigen is dus ook dat de Webkit ontwikkelaars teveel gefocust hebben op het slagen voor ACID3 terwijl een aantal basale fouten waar mensen in real-life tegenaan lopen nog steeds niet zijn gefixt. Tegelijkertijd zegt Ian Hickson, de ontwikkelaar van ACID2 en ACID3, dat hij heel veel moeite heeft moeten doen om testen te ontwikkelen waar Webkit niet voor slaagde. De waarheid zal waarschijnlijk wel ergens in het midden liggen.

[Verwijderd]

Als je slaagt voor ACID3 betekent het dus niet per se dat je voldoet aan alle standaarden. Echter, als je niet slaagt voor ACID3, voldoe je sowieso niet aan alle standaarden. Safari en Opera staan er momenteel dus het gunstigst voor.

[Maurits van Baerle]

Eens. Je kunt echter wel betogen dat het ene onderdeel van de standaard belangrijker is dan het andere. Afhankelijk van wat er nu al veelal in gebruik is. Je kunt heel mooi een gloednieuwe CSS3 selector ondersteunen maar als bepaalde veelgebruikte CSS2 onderdelen in jouw browser nog fouten vertonen dan is dat uiteindelijk veel vervelender.

David Baron, één van de Gecko ontwikkelaars, zegt dus ook dat Ian Hickson simpelweg andere prioriteiten heeft. Ze zijn grotendeels hetzelfde maar op een aantal punten net anders.

[GrooV]

Maar je kan misschien een betere ondersteuning hebben en toch niet door de test komen!

Ze kunnen toch veel beter een volledige CSS test draaien? Kost wat meer tijd maar dan weten ze het ook zeker.

[Parasietje]

ACID test het afhandelen van fouten. De test is in mijn ogen veel te strikt. Als je kan kiezen tussen een render engine die snel en efficient juiste CSS rendert, of een trage render-engine die ook foute css-code op een standaard-manier rendert...

Web developers moeten correcte code schrijven, browsers moeten correcte code ook juist renderen. En al de rest interesseert mij eigenlijk weinig tot niets

[Maurits van Baerle]

Je bent in de war. ACID2 test het afhandelen van foute code. ACID3 test het afhandelen van correcte code.

[SED]

dus de test methodiek past men tussentijds aan en daar moeten de fabrikanten dan maar aan voldoen.
Ik heb ook een test bedacht.. de IE test... voldoe je daaraan dan voldoe je gegarandeerd aan 95% van de websites op de wereld. Voldoe je daar niet aan dan behoor je tot de 5% die het niet goed doet.
Lijkt me een zinloos gebeuren zo..
Dus een test moet niet alleen de standaard testen maar tevens een maatgevende richtlijn zijn waarlangs je de maatlat kunt leggen. Dat lijkt ACID dus NIET te zijn.

edit
helemaal bedenkelijk als je ziet dat zelfs in de äcid test zelf tussentijds zaken aangepast worden: http://ln.hixie.ch/?start=1206578003&count=1 hoe serieus ben je dan te nemen?

[Reactie gewijzigd door SED op 26 juli 2024 03:05]

[Verwijderd]

Ik heb het over belachelijke markup. Dat het valideert zegt niets over de correctheid van het gebruik ervan. Het zegt alleen dat er geen syntactische of technische fouten in zitten. Als je de broncode van de test bekijkt, zie je dat er gewoon onzin staat.

[Verwijderd]

Semantisch klopt het misschien niet, en dat kan je ook nauwelijks automatisch testen, maar dit is dan ook geen tutorial voor webdesigners. Als je deze test als browser goed doorloopt, heb je een bewijs dat je een flink deel van HTML, CSS, Javascript en SVG goed ondersteunt.

Browsermakers weten precies welke tests worden uitgevoerd, en je kan gefaalde tests zien als je op de "A" klikt. Het grote voordeel van het plaatje en de simpele counter, is dat het voor gewone gebruikers makkelijk te zien is hoe goed de standards-mode render-engine is.

Wat natuurlijk wel een nadeel is, is dat je vooral kan zien of, en hoeveel er goed gaat; een kwantitatieve test. Je ziet (als leek) niet zo makkelijk wat er precies fout en goed gaat. Het is dus niet zo'n handige test om te kijken welke features een browser precies wel en niet ondersteunt. Nog even afgezien van het feit dat de test niet uitputtend is (wat onmogelijk is).

Een verbetering voor de Acid-test zou dus zijn om aparte testcases duidelijk visueel te maken, in een lange lijst met tests, zodat je afzonderlijke probleemgevallen in browsers kan zien. De bovenste test zou dan een samenvattend plaatje kunnen zijn zoals we die bij de huidige Acid tests al zien.

[xzaz]

Onzin moet ook op de juiste manier worden gerenderd. Dat is de hele bedoeling, plaatje die worden weergegeven maar later weer verwijderd. Is het dan onzin? neen, de browser moet hier mee om kunnen gaan. Dacht dat in ACID2 zo'n bunny voor kwam. Dat is de hele test.

[xzaz]

Geweldig! Goed nieuws, nu FF en IE nog. 2 weken geleden was IE8 nog blij dat ze ACID2 goed afgerond hadden. Ben benieuwd wat de final van FF3.0 en IE8 bij ACID3 halen. We zullen zien.

[user109731]

IE8 hoef je (denk ik) niet veel van te verwachten, aangezien IE geen CSS3, SVG e.d. ondersteunt. Gaan ze denk ik ook niet snel doen, aangezien dat kan concurreren met hun eigen Silverlight.

FF3 zal vermoed ik rond de 70-75 uitkomen. Men is aan het toewerken naar een final release, dan ga je niet je core nog overhoop halen. Beetje ongelukkig dus voor Mozilla. Maarja toch een vrij nette score imho

[Reactie gewijzigd door user109731 op 26 juli 2024 03:05]

[CrashOne]

Net als met de release van Fx 2, precies na het uitbrengen van de Acid2 test. Vandaar dat Fx 2 Acid3 nooit juist heeft gerenderd en dat dit pas in Fx 3 het geval is.

Toch knap dat een test browser makers een doel geeft, terwijl dit eigenlijk de standaarden alleen al voldoende zou moeten zijn.

[Little Penguin]

Toch knap dat een test browser makers een doel geeft, terwijl dit eigenlijk de standaarden alleen al voldoende zou moeten zijn.

Voor veel browserfabrikanten zijn de standaarden wel degelijk voldoende, maar zo'n test is wel mooi voor de laatste metertjes...

Overigens haalt Firefox 1.5 maar liefst 51/100 punten (net getest, ik type dit ook in Fx 1.5), terwijl de recentere Opera (9.25) blijft steken op 46/100 (volgens Wikipedia). Een score van 50% halen in de test zonder dat dit 't doel was (toen Fx 1.5 uitkwam was er nog geen Acid 2 of Acid 3 test) is toch best wel knap.

Met Fx 3 zal men overigens op 71/100 uit gaan komen, ook hier geldt dat het halen van de Acid3 test niet echt het doel was (misschien dat dit geldt voor 5-10 test maar dan heb je het wel gehad).

* Little Penguin vindt de Acid3 test overigens wel degelijk belangrijk op de lange termijn, simpelweg omdat browsers die de Acid3 test halen wel allen eenzelfde minimum ondersteunen...

[ByronFortescue]

Ik heb de laatste build van Webkit getest, en hij komt hier maar tot 94 procent, beetje raar..

Maar hoe dan ook, grappig dat deze race zo snel wordt gestreden, nu Firefox nog!

[dev10]

Ik heb hier de nightly van webkit gedownload en WebKit.dll naar m'n huidige Safari installatie gekopieerd. De eerste keer haalde ik inderdaad geen 100/100 maar 99/100. Na een refresh deed hij het wel goed.

Ik zie dat Safari hem toch nog niet helemaal vlekkeloos maakt. Als je tussen de A en de C klikt, krijg je een alert. Daar staat bij mij in:

Failed 0 tests.
Test 26 passed, but took 328ms (less than 30fps)
Test 65 passed, but took 156ms (less than 30fps)
Test 69 passed, but took 150 attempts (less than perfect).
Total elapsed time: 7.69s.

Dus eigenlijk maakt Safari hem nog helemaal niet goed, want:

To pass the test, a browser must use its default settings, the animation has to be smooth, the score has to end on 100/100, and the final page has to look exactly, pixel for pixel, like this reference rendering.

Het eindresultaat ziet er uit zoals de reference rendering, maar de animatie is niet smooth.

[Reactie gewijzigd door dev10 op 26 juli 2024 03:05]

[Makkelijk]

Ik zou het heel jammer vinden als firefox 3 zakt voor deze test. De twee meest gebruikte browsers zijn wel browsers die het gebruik van niet-standaarden blijven stimuleren door hun vaak verkeerde interpretatie van CSS3.

Veel webontwikkelaars ontwikkelen met firefox en gaan vervolgens creatief zorgen dat het op safari en opera werkt, terwijl dat toch echt de enige twee browsers zijn die wel goed werken.

[Maurits van Baerle]

Als je met de beta van Firefox 3 de CSS3 Selectors test doet zie je dat FF3 geen verkeerde interpretaties van CSS3 heeft, ze ondersteunen alleen nog niet alles. "From the 43 selectors 36 have passed, 0 are buggy and 7 are unsupported"

Hierdoor is er dus geen risico dat webdevelopers rekening gaan houden met CSS3 bugs in Firefox 3. Precies om deze reden ondersteunt Mozilla bepaalde zaken liever helemaal niet dan met bugs in de interpretatie.

[Reactie gewijzigd door Maurits van Baerle op 26 juli 2024 03:05]

[Verwijderd]

Deze test is zo zinloos. De HTML en gebruikte CSS slaan totaal nergens op, en dragen helemaal niets bij aan het correct laten renderen van wél normaal gemarkupte HTML met een normale stylesheet. Het is jammer dat ze enige waarde hechten aan dit soort tests, want in de praktijk heb je er gewoon geen klap aan.

In laboratoria kunnen wetenschappers onder gecontroleerde omstandigheden fantastische dingen doen. Maar in het dagelijks leven heb je er niets aan wat je in dat ene laboratorium kunt. Ik zie liever gewoon praktijkvoorbeelden met lijstjes, tabellen, weet ik niet allemaal, en dan zo opgemaakt dat je er in een real-life situatie er écht iets aan gaat hebben. Die compatibiliteitstests horen te bestaan uit honderden so niet duizenden losse testcases.

[Maurits van Baerle]

De ACID3 test gebruikt uitsluitend correcte HTML en CSS. Hij valideert bijvoorbeeld probleemloos.
Volgens mij ben je in de war met ACID2, die had inderdaad foutafhandeling als focus en bevatte dus foute markup.

[webmaster777]

Ach wat is foute markup. De tests zijn voornamelijk gebaseerd op html 4 en een hoop javascript dus wat verwacht je dan? De SVG plaatjes zijn leuk, maar in de meest gebruikte browsers nog totaal niet volwassen
(en daarmee kan je SVG dus nog niet echt onder het grote publiek gebruiken) De acid3 is voor de ontwikkelaars een leuke uitdaging maar infeite zegt het nog steeds niet veel. Behalve dan dat de diversiteit onder browsers enorm is. Foute interpretaie zit er vaak snel ingebakken. Het kan ook gewoon slechter (om maar wat te noemen: IE7 doet het slechter in de acid3 dan IE 5.5)

[Little Penguin]

De SVG plaatjes zijn leuk, maar in de meest gebruikte browsers nog totaal niet volwassen (en daarmee kan je SVG dus nog niet echt onder het grote publiek gebruiken)

Hetgeen wel gelijk aangeeft waarom de Acid testen belangrijk zijn, al vanaf de eerste Acid test hebben ze er voor gezorgt dat features goed geïmplementeerd werden (box model), ze eindelijk eens gemaakt werden (bijv. CSS2 position fixed) en gaat de Acid3 test hopenlijk zorgen voor goede SVG ondersteuning - dus ook in IE9 oid.

Zowel WebKit (Safari), als Mozilla Gecko (Firefox, Camino, SeaMonkey, etc) als ook Presto (Opera) ondersteunen allen reeds SVG (de een wat beter dan de ander, dat wel), maar IE ondersteund SVG nog niet - deze Acid3 test kan daar mogelijk verandering in brengen...

[Dreamvoid]

Betekent dit dat Safari ook eindelijk de T.net frontpage correct rendert?

[Reactie gewijzigd door Dreamvoid op 26 juli 2024 03:05]

[lowfi]

Nee want safari gebruikt niet deze build van webkit. Bovendien zoals boven wordt aangehaald zegt zon test niets over normale/echte sites.

[PrisonerOfPain]

De laatste Webkit nightly doet het ook nog steeds fout in het door bbr omschreven scenario.

[stewie]

voldoet de frontpage aan een standaard dan?
stuur anders ff een bug-reportje in safari

[Reactie gewijzigd door stewie op 26 juli 2024 03:05]

[ultimasnake]

w3 validatie html
Validation Output: 3 Errors
Deze 3 errors zijn & tekens in de links, deze dienen eigenlijk & te zijn. oh en een <br> ipv <br />

W3 validatie CSS
Sorry! We vonden de volgende fouten (
5 errors geven aan dat het fout is in CSS2 maar wel goed is in CSS3
2 text-overflows die incorrect zijn
1 lightgray wat lightgrey moet zijn

Geen rare dingen dus (netjes trouwens boys!)

[bbr]

Doet ie al, alleen na een "back", word de column breedte een beetje vaag.
Doe je refresh is het weer ok.

[Frietsaus]

Het leuke is dat de WebKit website een leuke bugreport functie heeft. Je kan een bug beter melden dan het hier vragen want anders wordt het mogelijk nooit opgelost.

[Reactie gewijzigd door Frietsaus op 26 juli 2024 03:05]