Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 31 reacties
Bron: Heise Online, submitter: A_L

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.

Acid 2 - Eerste rendering van Safari
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.

Moderatie-faq Wijzig weergave

Reacties (31)

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.
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.
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
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.
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.
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...
Je moet wel volgende link aanklikken en niet het prentje:
http://webstandards.org/act/acid2/test.html#top
Beetje (?) misleidende titel aangezien er maar ÚÚn gebruiker is die 'm heeft.
werk hier sinds gisteren met de nieuwe safari en idd, nog altijd ERROR. ik dacht dat het wel ging lukken, dus titel is misleidend.
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.
In Firefox rendert de tweede test iig ook verkeerd..
Opera maakt er zo te zien helemaal soep van, en ook Konqueror doet niet alles goed. Heb geen IE beschikbaar op t moment...
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.
FF en Opera8 zien er bij mij bijna hetzelfde uit.
IE is niet te volgen
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
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.
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.
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.
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 :D
Hoewel er veel verbeteringen uit Tiger ook in Safari van OS X 10.3.9 verwerkt, gaat het in Panther fout...
FireFox 1.0.3 faalt :o Gaan ze hier wat aan doen dit kan natuurlijk niet he :P
IE faalt ook.

Maar ik vraag me af wat het nut is dat Safari dit testje goed afrondt.
IE faalt ook. Maar ik vraag me af wat het nut is dat Safari dit testje goed afrondt.
Zie: http://webstandards.org/act/acid2/guide.html
Dit probleem was al bij Bugzilla gemeld zag ik zojuist. Dus men is er van op de hoogte.
Onder Internet Explorer is het nog veel erger :+
Kunnen ze nou echt niet anders verzinnen, "Hello World".
Nu lijkt het op een beginers project......
Volgens mij heb jij het hele idee van Hello World nooit begrepen....
Euh "Hello world" mijn eerste programma??
Die render test is niet zo simpel als je Hello world programma-tje ;)
zolang jij het plaatje nog niet normaal kunt renderen lijkt het me ingewikkeld genoeg :)

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True