Safari slaagt als eerste voor Acid 2-rendertest

Midden maart werd door het Web Standards Project bekendgemaakt dat versie 2 van de Acid-test online zou komen. Acid 2 bestaat uit een testpagina waarin de mogelijkheden van HTML 4, CSS 1, PNG-afbeeldingen en data-URL's getest worden. Evenals met Acid 1, die in 1997 online kwam, is het ook nu de bedoeling dat browsers de test uiteindelijk probleemloos weergeven. Na de lancering van Acid 2 zijn verschillende browserontwikkelaars aan de gang gegaan om eventuele renderbugs in hun browser op te lossen. Enkele dagen geleden is bekend geworden dat David Hyatt de code van Apples Safari heeft verbeterd zodat Acid 2 goed gerenderd wordt. Hiermee is Safari de eerste browser die Acid 2 goed weergeeft. Wanneer deze wijzigingen voor gewone gebruikers beschikbaar komen, is nog niet bekend.

Safari is gebaseerd op de WebCore-renderengine, die weer gebaseerd is op de KHTML-engine die gebruikt wordt in de Konquerer-browser. Als vanzelfsprekend kwam de vraag op of de aanpassingen in Safari ook teruggeport zullen worden naar KHTML, daar de patches door Hyatt zijn vrijgegeven. Het antwoord daarop is echter negatief, aldus KDE-ontwikkelaar Zack Rusin. Het probleem is namelijk dat de WebCore-code inconsistent is en dat codewijzigingen veelal afhankelijk zijn van andere code of zelfs Mac OS X-API's. Het eenvoudigweg invoegen van de vrijgegeven patches is dus niet mogelijk, wat betekent dat patches 'from scratch' zullen moeten worden opgebouwd en ingevoegd in de KHTML-code. Gezien de ondercapaciteit bij het KHTML-project kan dit nog wel enige tijd duren.

Safari's rendering van Acid 2 voor de grote codewijzigingen. Klik op de afbeelding om te zien hoe Safari Acid 2 nu rendert.

Volgens Rusin is deze manier van werken tekenend voor Apple. Het bedrijf van Steve Jobs heeft in het verleden besloten om in Safari gebruik te maken van de KHTML-renderengine. Hierover is overleg geweest tussen Apple en het KHTML-project en toen is afgesproken dat Apple codeaanpassingen zou teruggeven. Dit is weliswaar weleens gebeurd, maar de laatste tijd is hier weinig meer van gekomen doordat Apple alleen de code levert en geen uitleg en changelog. Het lijkt er daarom sterk op dat Apple wel de voordelen wil hebben van een goede renderengine, maar niet de nadelen van het doneren van code en het steunen van het KHTML-project. Echter, dit is toegestaan volgens de Lesser General Public License, de licentie waaronder de KHTML-code is vrijgegeven, en Apple doet dus niets verkeerd.

Lees meer

IT-banen

Reacties (31)

Dreamvoid

Bedrijfsnieuws

30 april 2005 19:17

Zonder negatief te willen zijn, maar ik vraag me bij dit nieuws af in hoeverre dit een daadwerkelijk bruikbare, volledig geteste fix voor deze ontbrekende PNG/HTML/CSS ondersteuning, en geen eenmalige hack die toevallig alleen deze test pagina goed weet te renderen.

Verwijderd 30 april 2005 16:31

Leuk dat tweakers aan het einde uitlegt hoe de lgpl werkt, jammer dat dit met een zure sneer naar apple moet over het niet terug geven van code. Daar is het toch gvd lgpl voor? Dat is de keuze geweest van het khtml project, als ze dat niet bevalt dan hadden ze voor gpl moeten kiezen.

Carbon @Verwijderd • 30 april 2005 16:48

jammer dat dit met een zure sneer naar apple moet over het niet terug geven van code

Wat nog niet waar is ook!
Apple geeft wel degelijk de sourcecode terug.
Het probleem is alleen dat ze geen changelog vrijgeven.

http://www.kdedevelopers.org/node/view/1001

Verwijderd @Verwijderd • 30 april 2005 18:47

Lgpl = Gpl + het wel toestaan van het linken van closed source applicaties tegen open source bibliotheken.

Je kan dus een closed source (Safari) browser maken op basis van Khtml.

Apple is zeer onsportief. Ze zijn een overeenkomst aangegaan met de ontwikkelaars van Khtml met als inzet dat ze er beide beter van werden. Apple een lichtgewicht html engine en de Khtml ontwikkelaars zouden ondersteuning krijg van Apple ontwikkelaars in de vorm van nieuwe featues en bugfixes. Ondanks dat Apple wel de broncode open maakt (wat ook moet bij de Lgpl) doen ze dit op een manier die het Khtml team weinig voordelen op leverd.

ATS @Verwijderd • 30 april 2005 18:20

GPL of LGPL maakt in deze niets uit. De code is beschikbaar, maar geen changelogs. Bovendien zijn de veranderingen vaak afhankelijk van OS/X specifieke zaken. Dat maakt het mergen van de patches in KHTML vrijwel onmogelijk.

groovyhot 30 april 2005 14:51

Wat zou je nu eigenlijk moeten zien? ik zie een ontzettend blokkerige smiley met hele grappige (en niet blokkerige) ogen...

[edit]
met internet explorer 6...

Xiander @groovyhot • 30 april 2005 15:16

Je moet wel volgende link aanklikken en niet het prentje:
http://webstandards.org/act/acid2/test.html#top

Verwijderd 30 april 2005 14:36

Beetje (?) misleidende titel aangezien er maar één gebruiker is die 'm heeft.

ventje853 @Verwijderd • 30 april 2005 14:44

werk hier sinds gisteren met de nieuwe safari en idd, nog altijd ERROR. ik dacht dat het wel ging lukken, dus titel is misleidend.

XiQ @Verwijderd • 30 april 2005 15:11

Iedere gebruiker die bereid is de patches toe te passen/Safari zelf te compilen kan de test draaiend krijgen. Titel is niet misleiding, want het gaat om de software Safari en niet een bepaald versienummer.

twan1 30 april 2005 15:00

In Firefox rendert de tweede test iig ook verkeerd..

RSpliet @twan1 • 30 april 2005 15:14

Opera maakt er zo te zien helemaal soep van, en ook Konqueror doet niet alles goed. Heb geen IE beschikbaar op t moment...

Countess @RSpliet • 30 april 2005 15:17

IE maakt er ook een flinke bende van.
wit vlak met onder een rode band en wat geel en zwarte vierkanten erin.
FF brengt het er dus helemaal zo slecht nog niet vanaf.

ytsmabeer @Countess • 30 april 2005 16:18

FF en Opera8 zien er bij mij bijna hetzelfde uit.
IE is niet te volgen

egeltje 30 april 2005 15:04

Hoewel er veel verbeteringen uit Tiger ook in Safari van OS X 10.3.9 verwerkt, gaat het in Panther fout...

Verwijderd 30 april 2005 16:05

Gezien de ondercapaciteit bij het KHTML-project kan dit nog wel enige tijd duren.

Ze kunnen ook gewoon vlug gaan beginnen met het ondersteunen van Gecko in Konqueror. Scheelt een hoop dubbel werk en je kan apple ook nog eens terug pakken voor hun onsportieve actie.

Superstoned @Verwijderd • 1 mei 2005 12:06

ja, maar afgezien van het feit dat gecko wat trager is dan khtml hebben de kde dev's geen enkele invloed op de ontwikkeling ervan. ze kunnen geen release datum bepalen etc, dus moeten ze maar wachten wanneer er een stabiele versie is die ze met KDE kunnen leveren. da's niet handig. daarbij is KHTML een uitstekend stukje werk, op veel punten beter dan Gecko (en op andere punten weer minder, ja...). ik heb geen andere browser op mijn pc dan konqueror, en dat bevalt uitstekend. maar konqueror zal wellicht over een tijdje ook gecko ondersteunen. keuze = linux

Verwijderd 30 april 2005 15:26

Kunnen ze nou echt niet anders verzinnen, "Hello World".
Nu lijkt het op een beginers project......

achappey @Verwijderd • 30 april 2005 15:32

Volgens mij heb jij het hele idee van Hello World nooit begrepen....

Verwijderd @achappey • 30 april 2005 16:57

Euh "Hello world" mijn eerste programma??

twan1 @Verwijderd • 30 april 2005 20:01

Die render test is niet zo simpel als je Hello world programma-tje

lord_eissens @Verwijderd • 1 mei 2005 01:51

zolang jij het plaatje nog niet normaal kunt renderen lijkt het me ingewikkeld genoeg

Kevinp 30 april 2005 20:27

Eigenlijk is het wel lollig. Want volgens mij zit de pagina niet helemaal lekker in elkaar. In FF krijg ik nl alleen maar de testpagina te zien zonder dat ik ook de comparrison pagina kan kiezen

burne @Kevinp • 1 mei 2005 02:24

Die pagina is volledig geldige HTML, geheel volgens alle relevante afspraken, standaarden en tests.

kijk anders hier eens?

Alle fouten die je meent te zien zijn fouten in je browser.

Remz-Jay @burne • 1 mei 2005 04:35

Niet alleen de HTML is volledig correct, maar ook de gebruikte CSS is in orde: http://jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Fwebstand ards.org%2Fact%2Facid2%2Ftest.html%23top

De check levert wel fouten op, maar als je goed oplet zie je in het commentaar in de pagina zelf dat deze fouten expres zijn toegevoegd om browsers om de tuin te leiden. De parsers in de browsers zouden de regels met de fouten erin moeten negeren aangezien deze niet voldoen aan de CSS gramatica, of er zelfs helemaal niet in voorkomen.

Dat verklaart ook waarom IE zo'n mooi groot rood vlak neerplant: het parsed een statement dat binnen het gebruikte element geen geldige CSS is.