De engine achter Safari is WebKit, een project dat in 2001 bij Apple werd opgestart en sinds 2007 een open source project is en op 7 maart dit jaar werd Apple een trademark voor WebKit toegekend. Het succes van WebKit is enorm, op dit moment is het de engine met het grootste marktaandeel ter wereld, want de WebKit engine wordt gebruikt door browsers als Safari en Chrome.

Maar het rommelt in browser-land, want er komen twee engines bij.

De eerste is Blink, een aftakking (fork) van WebKit, van Google en gekozen omdat Chromium een andere multi-proces architectuur heeft dan de andere browsers die WebKit gebruiken.

Bijna tegelijkertijd komt het nieuws naar buiten dat Mozilla en Samsung ook aan een nieuwe engine werken en deze gaat Servo heten.

Kortom, na een aantal jaren waarin steeds meer browsers dezelfde engine gingen gebruiken zien we nu aftakkingen ontstaan en we zijn dan ook benieuwd wat dit in de toekomst zal betekenen. En wat Apple in die toekomst zal besluiten, want op het moment staat Cupertino op iOS alleen browsers in iOS toe die WebKit gebruiken, dat zou nog wel eens lastig kunnen worden als iedereen zijn eigen engine heeft.

Groeiden we net toe naar makkelijker bouwen en minder hoeven te testen, krijgen we nu dit weer. Dat is balen voor de (website-)bouwers!

Misschien wel Ruud. Maar bij IE5 c.s. vonden we het ook niet zo leuk dat er maar één browser was waar men rekening mee wilde houden...

.

Die standaarden zijn er al jaren, daar zit het probleem dan ook niet. Wel in het je houden aan die standaarden. Er is geen politie die dat handhaaft.

Ik juich de komst van nieuwe engines van harte toe. Misschien gaan we dan weer nieuwe dingen, mogelijkheden, toepassingen zien. Ook op dat gebied lijkt het de laatste paar jaar immers vrijwel stil te staan.

En straks voor iedere browser een ander iDevice?  Waar id KIS naartoe?

Prettig dit!
Straks krijgen we weer hetzelfde gezeur als bij Win.Explorer, waardoor sommige websites weer niet goed werken op browser x, y en w.
Handig bij het bankieren en voor de Belasting.
Enfin, we wachten maar af.
Het voorspelt volgens mij ook niet veel goeds dat Mozilla met Samsung samen gaat.

Ik zie het probleem niet zo, de nieuwere versies reageren ook gewoon op de normale prefixen dus vaak hoef je niet eens meer -webkit-border-radius  te typen maar kun je gewoon al border-radius gebruiken. En mocht je daar echt problemen mee hebben dan is er nog altijd LESS of een JS waardoor je dit niet meer hoeft te doen.
http://leaverou.github.com/prefixfree/

Ik heb er geen problemen mee, het is niet zo dat de verschillen zo enorm groot zijn als dat ze vroeger waren. Wie ontwerpt er nog voor IE5, IE6 of IE7 bijna niemand toch. Of je moet al een doelgroep hebben die zo'n browser gebruikt - denk aan Azie.

@Kaasprikker,

Ik deel je mening niet dat we stilstaan maar ontwikkelingen kunnen natuurlijk altijd sneller, webstandaarden regelen zich zelf wel daar heb je geen politie voor nodig op vandaag. We hebben ook geen slechte browsers meer. De term moderne browser bestaat niet meer zoals je dat vroeger wel had wanneer je Firefox, Safari of Opera gebruikte tegenover IE.

Shmoo. ik ben het wel met je eens, al zie ik vaak 'standaarden' als een rem op nieuwe ontwikkelingen. Ik kijk graag naar wegmisbruikers en naar blik op de weg. Wanneer iedereen zich aan de verkeersregels gaat houden ben ik een pleziertje kwijt.

Ik begrijp dat je de REM als een oude eenheid ziet die heel wat jaren weg is geweest maar juist in deze tijd is de REM en de EM een perfecte eenheid om weer te gebruiken.

De fout ligt bij ons de developers zelf, soms ligt het antwoord op een probleem gewoon bij de basis. Het web is al vanaf het begin responsive geweest alleen hebben wij dat zelf verkracht door in fixed widht's te gaan werken. Het beste voorbeeld daarvan is miss. wel het 960 Grid.

Nu zijn we daar zo aangewend dat wanneer de schermen kleiner worden (iPads en iPhones) ipv groter zoals in de afgelopen jaren het geval was dat we ineens niet meer weten hoe we daar vroeger mee omgingen en verwachten we oplossingen in HTML5 en web standaarden om ons te helpen.

De oplossing is heel simpel, relatieve eenheden gebruiken, % , EM en REM  zijn relatieve eenheden terwijl PX, Inch, CM enz. allen vaste eenheden zijn waar we op vandaag niet zo veel meer aan hebben.
Nu we websites moeten laten schalen kun je bijna niet meer met pixels werken - de term pixel precies ontwerpen die vele designers wel eens gebruiken kan dus eigenlijk door het toilet gespoeld worden omdat het niet meer op die manier bestaat.

Gebruik je op vandaag nog in een 960px grid voor je website en het scherm wordt ineens 600px breed omdat iemand met een Tablet op bezoek komt  dan heb je last van de irritanten horizontale scrollers waar we jaren geleden om gevochten hebben om ze te verbannen van het web.
Maar als je grid 96% van de breedte van het scherm is dan heb je nergens last van want dan is je content gedeelte gewoon 96% van die 600px breedte ipv 960px op een 600px breedte.

Dat moeten we weer gaan leren want zo bouwde we vroeger ook onze websites op, in tabellen en dan waren de celle-/kolommen in percentages 35% of 80% enz. enz. De 960px. Grid heeft ons die manier van werken laten vergeten want als je 960px als vaste breedte had dan kon iedereen tellen een kolom van 640px voor de content daar past een 320px sidebar kolom naast om 960 te maken.

Dames, heren, het gaat om "engines" en deze zullen zich allemaal maar al te graag aan de webstandaarden willen en ook moeten houden. Engines en browsers kunnen niet meer zo vrijblijvend een eigen koers aanhouden, n tegelijk vrolijk melden HTML5 (dus HTML, CSS3 en JavaScript-compliant) te zijn. Dat kon vroeger, maar nu niet meer. Een browser/engine kan hooguit een functie nog niet doorvoeren (kwestie van ontwikkelingstijd), maar niet anders gaan implementeren.

Jammer, ik  hoopte juist zo op NIEUWE functies. Maar dat is dus niet meer mogelijk?

Natuurlijk wel, alleen zul je meer specifiek dit nieuws moeten volgen om ze te ontdekken.

Verhaal in het kort:


Die ontwikkelingen gaan overal op het internet gewoon door, het is alleen de vraag wie stopt ze als eerste als extra functie in een browser voordat ze nog in de webstandaarden worden opgenomen.

Zelfs Adobe is met dit soort dingen bezig.
http://html.adobe.com/webplatform/layout/regions/


Dit is een hele slimme zet van Google en nu gaat Chrome pas echt gas geven en afstand nemen van Safari als browser  omdat ze weten dat hun aanpassingen-/toevoegingen  niet meer bij Apple terecht komen via de WebKit engine.

Wat heeft multi-processor met pixels en iOS te maken?