Google en Opera stappen over op fork 'Blink' van WebKit-browserengine - update

Google werkt aan zijn eigen browserrenderengine onder de naam Blink. Aanvankelijk is de engine nog gebaseerd op de code van opensourcesoftware WebKit, maar hij zal gaandeweg zijn eigen gang gaan. Ook Opera stapt over op Blink, dat nu de basis voor Googles Chromium-project is.

De reden om WebKit te forken is volgens Google dat de innovatie gehinderd werd door de toegenomen complexiteit van zowel WebKit als Chromium. Chromium is het opensourceproject dat aan de basis staat van de Chrome-browser en Chrome OS. Er zijn echter al een aantal fundamentele verschillen tussen Chromium en andere op WebKit gebaseerde browsers: zo gebruikt het Chromium-project een andere multiprocess-architectuur.

Voor webontwikkelaars zal er de komende tijd weinig veranderen, belooft Google. De eerste stap zal volgens het bedrijf zijn om de code op te schonen. Google verwacht direct zeven buildsystems en meer dan zevenduizend bestanden, goed voor in totaal 4,5 miljoen regels code, te kunnen schrappen. Op de lange termijn zorgt een gezonde codebase voor een stabielere browser met minder bugs, stelt de Chrome-ontwikkelaar.

Desondanks zal de fork op termijn wel van invloed worden op webontwikkeling. WebKit is de basis van niet alleen Chrome, maar ook Apples Safari en Opera en deze bedrijven droegen gezamelijk bij aan de ontwikkeling. Het afsplitsen van Blink zal de opensourcecommunity van WebKit-ontwikkelaars voor een keuze stellen. Ook zal Google eigen functionaliteit aan Blink toevoegen en kan het bedrijf nu zijn eigen keuzes maken wat ondersteuning van nieuwe web-standaarden betreft. Volgens Google zorgt het hebben van meerdere renderengines echter voor meer innovatie en ook zou het in de woorden van het bedrijf bijdragen aan 'de gezondheid van het totale open web-ecosysteem'.

Opera zal Google volgen en ook van Blink gebruik gaan maken, zowel bij de desktop- als de mobiele versies van de Opera-browser. "Toen we aankondigden Presto achter ons te laten, maakten we bekend met Chromium verder te gaan en het forken en de verandering van naam is van weinig invloed op de Opera-browsers", zegt een Opera-woordvoerder tegen The Next Web.

De naam Blink refereert naar het veel bekritiseerde en niet gestandaardiseerde blink-element van html die tekst kon laten knipperen. De ontwikkeling van WebKit zelf werd in 2001 in gang gezet door Apple als fork van khtml en KDE's JavaScript-engine. De W3C waarschuwde een jaar geleden nog voor de dominantie van WebKit, die een browsermarktaandeel van ongeveer 40 procent heeft. Firefox gebruikt de Gecko-engine en Internet Explorer gebruikt Trident.

Update, 12.50: Volgens Google Chrome-ontwikkelaar Alex Russell zal Blink vooral de ontwikkeling van de Google-browser versnellen en werd dit gehinderd door de gezamelijke ontwikkeling van WebKit. Ook stelt hij dat ontwikkelaars met Blink minder bang hoeven te zijn dat aanpassingen onbedoelde gevolgen krijgen. Een medewerker van Chrome-beveiligingsteam, Justin Schuh, zegt dat Blink de mogelijkheid biedt 'heel wat beveiligingsproblemen die zich hebben opgestapeld aan te pakken'. Hij wijst onder andere op de ontwikkeling van Site Isolation.

Reacties (102)

[Rekcor]

Het lijkt wel het kiezen tussen twee kwaden:

1) één zeer dominante browser/engine (bijv. IE6)

Voordelen:

• 1 codebase voor web-devs
• minder testen

Nadelen:

• 1 bedrijf heeft monopolie en kan doen wat 'ie wil (platforms uitsluiten bijv.)
• nauwelijks progressie

2) meerdere engines naast elkaar

Voordelen:

• progressie door concurrentie

Nadelen:

• testen, testen, testen
• uitzonderingen in HTML/CSS/JavaScript

[Reactie gewijzigd door Rekcor op 22 juli 2024 14:20]

[tszcheetah]

Het nadeel "1 bedrijf heeft monopolie" gaat m.i. niet op in het geval van WebKit; er zijn meerdere partijen die eraan kunnen ontwikkelen - en dit daadwerkelijk doen. Ook is het open source en kan bij stagnatie de ontwikkeling altijd weer door een ander opgepakt worden om zo de progressie te waarborgen.

Neemt niet weg dat meerdere engines het voordeel blijft houden dat er gestandaardiseerd wordt op basis van documentatie/een definitie van de functionaliteiten, in plaats van op implementatiedetails van 1 engine.

Het grote probleem wat zich nu voordoet met Webkit is dat in het geval van CSS de items met -webkit- prefix niet uitgefaseerd worden én dat WebKit dominant is op de mobiele markt. Hierdoor gaan webontwikkelaars de fout in door de standaardversie niet te implementeren. Dat is een heel ander probleem dan wat er in het IE6-tijdperk was (verschil van interpretatie qua standaarden).

In principe is het dus goed dat er meerdere engines zijn, mits dit niet resulteert in (wezenlijke) interpretatieverschillen van de W3C-standaarden - pas dan wordt 't echt vervelend voor web-ontwikkelaars.

[Loller1]

Eugh, dat het open source is een non-argument. Er is nog altijd een selecte groep die bepaald wat er in komt en wat niet. En Webkit is daar een geweldig voorbeeld van, want aan de standaarden houd het zich niet echt. En dat heeft de mobiele markt geen goed gedaan (ontzettend veel Webkit-only websites)...

[tszcheetah]

Eugh, dat het open source is een non-argument. Er is nog altijd een selecte groep die bepaald wat er in komt en wat niet.

Dat klopt wat betreft de ontwikkeling op zich; maar wat betreft continuïteit is het wél een argument. Immers, als de ontwikkeling daadwerkelijk stagneert kan er een fork gemaakt worden - zoals ook regelmatig gebeurt (OpenOffice->LibreOffice, X11->Xorg en nu Webkit->Blink). Dat is in het geval van een closed source oplossing (Trident) niet het geval.

Het verschil tussen nu en het IE6-tijdperk is dat er destijds een dominante browser was; nu is het een dominante rendering engine maar een grotere hoeveelheid browsers, waarvan enkele overstappen op een fork. Daarom is de situatie in het verleden (IE6) dus ook niet zomaar te vergelijken met de situatie nu (WebKit).

[Relief2009]

We zijn al 4 versies verder met IE en het grappige is dat IE10 het minst erge is gezien dat hele Webkit compatibiliteit gebeuren. Ik snap dus niet waar je heen wil met je verhaal. En MS heeft totaal geen monopolie meer.

Wel goed nieuws dat Webkit nu minder gepushed wordt. Kunnen devs zich eindelijk eens focussen op correcte code.

[Reactie gewijzigd door Relief2009 op 22 juli 2024 14:20]

[analog_]

Wat belet de rest van ook niet over te stappen. Ik gok dat er toch een groot deel google werk achter webkit zit en als ze die terugtrekken is het maar de vraag of de rest dat kan opvangen (onderhoud == onderhoud). Daarom is het voor de rest wat betreft overlevingskansen nu (denk ik) het verstandigst om bij Google op de boot te blijven -onder moeder vleugels-.

Hetzelfde gevaar is er bij MySQL en zijn 'recente´ dochters (engines, mariadb enzo) welke feitelijk niet zonder Oracle kunnen overleven omdat de community te klein is om MySQL (zelf) bijgewerkt te houden.

Ja tuurlijk kan een MS, Apple of andere groot software bedrijf het oppakken, maar financieel is dat minder gunstig voor ze..

[Reactie gewijzigd door analog_ op 22 juli 2024 14:20]

[curumir]

Je weet toch wel dat Apple een van de grootste contributors van Webkit is? Zoals in het artikel staat hebben zij Webkit geforkt van KDE... Ik zou me dan ook geen zorgen maken over de toekomst van webkit...

[watercoolertje]

Dat is dus NIET zo, over de hele periode van begin webkit tot vandaag heeft Apple 37% bijgedragen net als Google, echter is Google maar minder dan de helft van de tijd actief, ga je dus over nu kijken per dag is Google ruim 2x zo actief in hun bijdrage!

http://photos.appleinsider.com/webkit-2013.png

Er zijn 10-allen bedrijven die mee werken en Googles aandeel is ongeveer 50% van alle bijdrage dus zet er echt veel meer mensen op in (42% van alle auteurs is van Google tegenover 11% bij Apple en de rest is allemaal veel lager))

[Reactie gewijzigd door watercoolertje op 22 juli 2024 14:20]

[Carbon]

Dat is dus NIET zo, over de hele periode van begin webkit tot vandaag heeft Apple 37%

Apple 37,96% Google 37,73%
Apple is niet alleen één van grootste maar de grootste "contributor" (let op de quotes)!

echter is Google maar minder dan de helft van de tijd actief, ga je dus over nu kijken per dag is Google ruim 2x zo actief in hun bijdrage!

Het aantal commits per tijdseenheid zegt helemaal niets over geleverde bijdrage!
De geleverde bijdrage kun je alleen maar bepalen door te kijken naar wat er gecommit is.

[Reactie gewijzigd door Carbon op 22 juli 2024 14:20]

[watercoolertje]

Het is het enige meetbare dus daar moeten we het mee doen. Maar het kan dus nog veel positiever voor Google uitvallen, gezien die 4x zo veel personeel er op hebben gezet zijn hun commits waarschijnlijk groter...

Het is dus wel degelijk aannemelijker dat Google (veel) meer bijdraagt sinds 2008 (toen is Google webkit gaan gebruiken)...

Als je de grootste bent ben je OOK 1 van de grootste

[Reactie gewijzigd door watercoolertje op 22 juli 2024 14:20]

[Carbon]

Als je de grootste bent ben je OOK 1 van de grootste

Grapjas!

Het stukje "Apple is niet alleen één van grootste" refereert aan jouw ontkenning!

[burgt]

dat is dan weer een aanname die nergens op slaat, het kunnen bijvoorbeeld net zo goed bugfixes zijn van een regel (hoewel daar ook ooit veel tijd in kan gaan zitten).

En wie weet zijn de helft van de commits van apple enkel het verhogen van het type nummer (moet ook gebeuren)

Dus ook met het aantal gereviewde commits kun je nog steeds niets zeggen over de bijdrage.

Maar gezien het werk dat Google in chrome verzet verwacht ik inderdaad wel dat zij veel bijdragen aan functionaliteit en bug fixes.

Je zult dus echt moeten kijken nara de commits zelf voordat je er iets echt nuttigs over kan zeggen.

[curumir]

Inderdaad burgt. De diagrammetjes zeggen op detail niveau niet genoeg om overdreven sterke uitspraken over te doen. Het aantal commits zegt niks over de impact en de grootte en aantal auteurs zegt niks over de inhoud van de commits.

Iedereen die neutraal kijkt naar webkit weet dat zowel Apple als Google veel bijdragen. Dat is het enige wat ik zeg in het stukje waar Watercoolertje zo onnodig fel op reageert: Dat Google wegvalt is erg vervelend, maar Apple is nog steeds (en vanaf het begin) een van de grootste contributors van Webkit.
Dat het wordt ontkent met hoofdletters doet niks af aan het letterlijk waar zijn van dat statement.

[Reactie gewijzigd door curumir op 22 juli 2024 14:20]

[curumir]

Waar staan de manuren?

[Martinspire]

Niet alleen naar wat er gecommit is, maar ook wat er behouden is gebleven. Ik kan me voorstellen dat van sommige functionaliteiten deze wel 5x van opzet kan zijn veranderd (juist omdat het niet door de test komt). Dan ziet de commit er wel prima uit, maar kan het gewoon iets ouds overschrijven. Dan zou bv Chrome maar 10% hebben toegevoegd (rustig, het is een voorbeeld).

[MaestroMaus]

Nou, waar ik heen wil met mijn verhaal is dit; we zijn heel lang met MS in IE6 land gebleven. Waarom? Omdat MS over het algmeen zo lang mogelijk doet met zijn software (kosten/baten).

Firefox (en later Chrome) nam puur door kwaliteit een groot deel van de markt af van IE en forceerde MS om nieuwe browsers uit te brengen die beter waren (sneller met javascript, zich beter houden aan standaarden, etc.). Was dit niet gebeurd dan hadden we nu allemaal nog steeds iets in de richting van IE6 gehad. Iets was MS natuurlijk prima gevonden had (jij betalen zij doen er haast niets voor).

Het feit dat MS zich nu beter aan de regels houdt en probeert met een kwalitatief goede browser te komen komt niet omdat MS dat zo leuk vindt. Die hadden veel liever met hun eigen "html standaard" doorgegaan en veel liever niet geinvesteerd in een betere browser.

En IE is de "minst erge"? Alleen als je voor IE10 sites bouwt ja. Maar serieuze website bouwers houden zich toch minimaal nog met IE8 t/m IE10 bezig nu.

Maar nu terug naar mijn opmerking: de enigste manier waarop je de verschillende browsermakers forceerd om hun browsers beter te maken is door concurrentie. Anders treed er stilstand op net als bij MS destijds. Dat is wat ik wilde zeggen met mijn vorige reactie.

[Reactie gewijzigd door MaestroMaus op 22 juli 2024 14:20]

[Loller1]

Hoe weet jij nu of ze liever hun eigen standaard hadden? Dat kunnen we ook zeggen over iedere andere browsermaker, en als we dan toch bezig zijn: het W3C heeft al enkele leren gezegd dat IE de beste implementatie van de standaarden heeft...

Als je problemen hebt met het ontwikkelen voor IE9 en 10, dan doe je iets fout, en ook IE8 geeft lang niet zoveel problemen als laat voordoen...

[arendjr]

Ik heb regelmatig problemen met IE9 (missing WebSockets, anyone?), om over IE8 nog maar te zwijgen. Dat ze vooruit gaan valt niet te ontkennen, en IE10 is in mijn dagelijkse ervaring idd eindelijk op het niveau gekomen dat het praktisch geen extra effort meer kost om te ondersteunen. Maar zo rooskleurig als jij het laat voorkomen is het ook weer niet.

[Pendaco]

Ik voorzie meer verschillen tussen de browsers op iOS en Android. Dan zijn het in de toekomst niet zozeer de verschillen tussen de desktop browsers die irritant doen, maar juist de smartphones en tablets.

[MaestroMaus]

Als webdevs nu zo lui aan het worden zijn dat ze nog maar een codebase wensen dan moeten ze nog maar eens goed over hun beroep nadenken. Firefox heeft in koude jaren vele mensen uit de brand geholpen en ervoor gezorgd dat MS niet te veel kan blijven leunen op hun oude browsers & oude features. Dat had niet gekund zonder diversificatie. Het bewaren en koesteren van open standaarden is niet alleen belangrijk in barre tijden. Het is minstens net zo belangrijk in goede tijden. Er zal geen vooruitgang geboekt worden zonder concurrentie en dus ook niet zonder verschillende codebases.

[Reactie gewijzigd door MaestroMaus op 22 juli 2024 14:20]

[Martinspire]

1 codebase is misschien geen uitkomst, maar het lijkt er nu op dat we al richting de 8 verschillende browsers toegaan. Dat hindert het ontwikkelproces ook enorm.
Eerst had je al IE (6,7,8,9,10), Firefox, Chrome, Opera en Safari waar je voor moest ontwikkelen. Daar kwamen vervolgens nog de tablet en smartphone versies bij en nu hebben we ineens dat ze allemaal nieuwe engines of forks gaan gebruiken.
Alleen Opera is hierbij echt weggevallen, maar die kun je ook nog niet helemaal stoppen want de webkit versie moet nog komen.
Gelukkig verschilt IE10 niet veel van IE11, maar omdat IE10 nog niet overal op zal komen (hij is niet verplicht op Win7), zul je dus ook nog oude browsers moeten ondersteunen.

Al met al dus veel extra werk. Als er nou minder verschil zat tussen de mobile en tablet, was het te overzien, maar inmiddels is dat ook al niet meer en gaat het ook daar zijn eigen weg.
Ik wil best mn site testen, maar ga voor een project van 2 weken niet nog een volle week besteden aan alle mogelijke combinaties, want daar gaan we straks wel naartoe.

[Reactie gewijzigd door Martinspire op 22 juli 2024 14:20]

[mashell]

Ik wil best mn site testen, maar ga voor een project van 2 weken niet nog een volle week besteden aan alle mogelijke combinaties, want daar gaan we straks wel naartoe

Waarom niet? Een project duurt dan gewoon 3 weken. Het mag dan saai en vervelend werk zijn, het is wel werk wat je gewoon kunt factureren. Hoe meer browsers en verschillen hoe meer werk voor webdevers hoe beter zou je toch denken.

[arendjr]

De logica die je nu gebruikt staat ook wel bekend als de "broken window fallacy": http://en.m.wikipedia.org/wiki/Parable_of_the_broken_window

Zoals het repareren van een kapot raam geen winst levert aan de economie door het geld dat besteed moet worden aan de reparatie, zo ook levert nodeloos testen geen winst. In plaats van dat testen had de klant namelijk ook minder geld kwijt kunnen zijn en de developer alweer aan een volgend project bezig kunnen zijn.

Let wel, ik argumenteer niet tegen goed testen door developers, maar het kan ook de spuigaten uitlopen natuurlijk.

[invic]

Dit bevestigt nog meer dat op html , javascript en CSS gebaseerde applicaties een nachtmerrie is om goed te laten werken op alle courante browsers en op verschillende OS'sen. Heel veel tijd ben je kwijt aan testen als je jouw applicatie op alle courante browsers wilt laten werken en kun je alleen gebruikmaken van de de grootste gemene deler van de functionaliteit van een bepaalde browser engine. Daarom zijn plugin zoals flash en silverlight zo slecht nog niet ondanks de hype op html5. HTML5 is niet anders dan een veredelde shell scripting voor het web...

[curumir]

Webkit was noch optie 1 noch optie 2, omdat het door een consortium van bedrijven werd gemaakt die nadeel 1.1 in de weg zat. Nadeel 1.2 heeft denk ik niet zo veel te maken met dominantie danwel met positionering in het businessmodel.
Bij Microsoft was Internet Explorer een manier om Netscape dwars te zitten en marktaandeel te krijgen op webpagina's bekijken. Bij zowel Apple als Google is het web een essentieel onderdeel van hun bedrijfsvoering. Google vanwege apps in de Cloud, Apple vanwege HTML5 en de belangrijke positie hiervan in iOS.

[Cyleo]

Google blijft waarschijnlijk de core van wekit nog wel gebruiken, punt 2 zal dus nog wel mee valk. De reden waarom ze een fork willen gebruiken is eigenlijk heel logisch: webkit bevat teveel functies die chrome niet gebruikt / anders implementeert. Zie ook:http://www.androidpolice.com/2013/04/03/google-no-longer-cares-for-webkit-either-apparently-forking-the-engine-into-new-project-called-blink/

[Reactie gewijzigd door Cyleo op 22 juli 2024 14:20]

[Anoniem: 415197]

Het lijkt wel het kiezen tussen twee kwaden [...]

Oplossing: een simpelere webtaal die altijd werkt en waar iedereen zelf zijn render engine voor kan bouwen (of een open-source library gebruiken, naar keuze van de developer, niet de user).

Met andere woorden, denk fundamenteel.

[Reactie gewijzigd door Anoniem: 415197 op 22 juli 2024 14:20]

[MsG]

http://xkcd.com/927/

[Anoniem: 84766]

Het lijkt erop dat er een aardige discussie is geweest binnen WebKit tussen Google, Apple en waarschijnlijk Samsung. Ook al heeft Google een behoorlijke bijdrage, vermoed ik dat Apple nog steeds bepaald waar WebKit heen gaat en dat Apple natuurlijk doet wat goed is voor Apple en dit strookt niet altijd met de richting van Google.

De eerste grote discussie kwam ten tijde van WebKit2. Apple koos ervoor om een andere process scheidingslijn aan te brengen dan dat Google deed voor Chrome. De boodschap van Apple was, als je de discussie leest, wij hebben heel veel werk in WebKit gestopt, dus wij hebben geen boodschap aan jullie kritiek dat we het niet overlegd hebben.

Google als andere grote contributor kiest nu voor zichzelf, wat Samsung hopeloos achterlaat. Want zonder Google zal Apple alleen nog maar doen wat goed is voor Apple. Dus ook Samsung heeft een nieuwe partner gevonden.

Dit wordt zeer interessant, omdat zowel Google als Samsung / Mozilla gaan werken aan multithreading op het gebied van rendering en Javascript. Beiden zeggen dat dit ondoenlijk was geworden binnen WebKit met alle platformen en bureaucratie. Google gaat flink snijden in de WebKit vork en Mozilla begint opnieuw.

Nu wordt het interessant wat Apple dan binnen WebKit gaat doen om ook deze engine klaar te maken voor de toekomst. Of ze zijn al lang bezig, waar de focus ligt op de Mac en voornamelijk iOS en dat Google en Samsung zich dus niet meer konden vinden in WebKit en dat Apple gezegd heeft, dan ga je toch lekker weg.

[Carbon]

De eerste grote discussie kwam ten tijde van WebKit2. Apple koos ervoor om een andere process scheidingslijn aan te brengen dan dat Google deed voor Chrome.

Google was eerder met het scheiden van het rendering en browser process.
Chrome maakt dus geen gebruik van WebKit2!

Zie ook: Adapt WebKit2 design

Het grote verschil is dus dat de Chrome browser de sandboxing en IPC regelt, terwijl dat bij WebKit2 onderdeel is van de API.

[Anoniem: 84766]

Google was inderdaad eerder, alleen andere partijen waren niet zo gecharmeerd dat Apple in één klap WebKit2 in de trunk dropte zonder dat dit besproken was of dat er gemeenschappelijk een technisch ontwerp was gemaakt.

Het doel van de scheiding zoals binnen Webkit2 en die van Chrome is heel anders, zoals ook valt te lezen in onderstaande mailing.

….
Given what proportion of overall maintenance work on WebKit I done by Apple, I don't think anyone is entitled to veto us adding a new API layer. I also recall that when the chromium API layer was added, no one asked permission, you just let us know that it was coming. Which is fine - API layers are pretty low cost, and I hope no one would argue against a major contributor including theirs.
….

Zie hier voor de mailing list waar de discussie begint:
https://lists.webkit.org/...ev/2010-April/012255.html

Edit: Uiteindelijk wordt de lieve vrede bewaard, maar de toon is gezet denk ik.

[Reactie gewijzigd door Anoniem: 84766 op 22 juli 2024 14:20]

[Rafe]

Interessant stukje info uit de FAQ voor webdevelopers:

Will we see a -chrome- vendor prefix now?
We’ve seen how the proliferation of vendor prefixes have caused pain for developers and we don't want to exacerbate this. As of today, Chrome is adopting a policy on vendor prefixes, one that is similar to Mozilla's recently announced policy.

In short: we won't use vendor prefixes for new features. Instead, we’ll expose a single setting (in about:flags) to enable experimental DOM/CSS features for you to see what's coming, play around, and provide feedback, much as we do today with the “Experimental WebKit Features” flag. Only when we're ready to see these features ship to stable will they be enabled by default in the dev/canary channels.

For legacy vendor prefixed features, we will continue to use the -webkit- prefix because renaming all these prefixes to something else would cause developers unnecessary pain. We've started looking into real world usage of HTML5 and CSS3 features and hope to use data like this to better inform how we can responsibly deprecate prefixed properties and APIs. As for any non-standard features that we inherited (like -webkit-box-reflect), over time we hope to either help standardize or deprecate them on a case-by-case basis.

[ronaldmathies]

Dus lees ik het volgende goed:

In short: we won't use vendor prefixes for new features. Instead, we’ll expose a single setting (in about:flags) to enable experimental DOM/CSS features for you to see what's coming, play around, and provide feedback, much as we do today with the “Experimental WebKit Features” flag. Only when we're ready to see these features ship to stable will they be enabled by default in the dev/canary channels.

Als een feature dus stabiel is dan zal het standaard aangezet worden (met een vendor prefix ervoor). Dus ze gaan eigen vendor prefixes gebruiken. Ik had het volgende willen zien:

Only when we're ready to see these features ship to stable will we start a process with the W3C consortium to have these finalist in the next round.

Maar dat zeggen ze niet dus de zin:

We’ve seen how the proliferation of vendor prefixes have caused pain for developers and we don't want to exacerbate this.

Klopt niet helemaal, ze zeggen dat het alleen een pijn punt is wanneer de feature niet stabiel is. Maar wanneer het stabiel is is het geen probleem om deze te introduceren.

[Rafe]

Als een feature dus stabiel is dan zal het standaard aangezet worden (met een vendor prefix ervoor). Dus ze gaan eigen vendor prefixes gebruiken.

Nee, er staat ondubbelzinnig dat ze van hun vendor-prefixen afwillen. De geërfde webkit-prefixed features zullen op den duur worden gestandaardiseerd of worden verwijderd uit Blink.

Nieuwe experimentele CSS-features zal je dus zonder prefix kunnen gebruiken nadat je in about:flags de optie 'experimental features' hebt aangezet. Iets dat alleen web/browser developers zullen doen. Zodra een feature stabiel is zal deze na een browserupdate ook werken voor de gemiddelde eindgebruiker die eerdergenoemde optie niet aan heeft staan. Als web developer hoef je dus niet meer de prefixed features te gaan vervangen door de gestandaardiseerde features.

[Reactie gewijzigd door Rafe op 22 juli 2024 14:20]

[Niemand_Anders]

Nieuwe experimentele CSS features mogen juist NOOIT zonder prefix gebruikt worden. Is hetzelfde als je eigen HTML tags verzinnen.

We hebben na het Netscape/MSIE debacle afgesproken dat een browser developer GEEN eigen elementen meer mag toevoegen zonder prefix.

Als Google dus de vendor prefix weglaat, voldoet het niet meer aan de W3C standaard.
De prefix mag alleen verdwijnen als het element is opgenomen in de draft specificatie omdat dan ALLE partijen zijn geraadpleegd en input hebben kunnen geven..

Internet Explorer zal altijd een veel gebruikte browser blijven zolang Windows een monopoly heeft en daarnaast zal het marktaandeel van Webkit slinken naar het niveau van Firefox, waardoor je effectief alleen nog blink overhoud.

De kans op een nieuwe browser oorlog tussen Trident (Microsoft) en Blink (Google) wordt dan wel heel erg groot. Want het begint met CSS, maar kan ook overslaan op HTML of javascript..

[Rafe]

Nieuwe experimentele CSS features mogen juist NOOIT zonder prefix gebruikt worden.

Leuk dat de W3C dat roept, maar de ontwikkelingen gaan te snel voor die organisatie (WhatWG anyone? ).

Het vele gebruik van vendor prefixes in het wild is ook niet wenselijk en zelfs zo erg dat Mozilla overwoog om webkit-prefixed features te gaan ondersteunen in Firefox. Dit omdat web developers niet gebruik maakten van de equivalente moz-prefix of niet overstapten naar de later gestandaardiseerde feature.

Het succes van Mozilla/Google's nieuwe oplossing valt of staat met hun definitie van 'stabiel' voordat ze iets aanzetten voor de hele wereld. Als dat "we hebben iets dat werkt in onze browser" is, dan krijgen we jouw doemscenario. Als dat overeenstemming is tussen de grote browserbouwers, zonder het trage W3C, dan lijkt me het een beter systeem omdat de code niet verandert hoeft te worden door web developers.

[Freeaqingme]

Als Google dus de vendor prefix weglaat, voldoet het niet meer aan de W3C standaard.
De prefix mag alleen verdwijnen als het element is opgenomen in de draft specificatie omdat dan ALLE partijen zijn geraadpleegd en input hebben kunnen geven..

Het lastige is dat datzelfde W3C ook erkent dat de enige manier om tot volwassen standaarden te komen is door browsermakers en webdevelopers juist met toekomstige features te laten testen, zodat eventuele problemen al tijdens het standaardisatieproces kunnen worden verholpen (daarna is immers geen optie).

Overigens zijn het geen Chrome-only features, maar zijn het features waarvan nagenoeg iedereen die bij het W3C betrokken is er van overtuigd zijn dat ze one way or another uiteindelijk gestandaardiseerd zullen worden. Juist doordat deze features ook nog eens middels aparte configuratie ingeschakeld moeten worden, kan Chrome dergelijke features ook vrij makkelijk weer uitzetten of aanpassen: in principe worden er geen websites in productie-omgevingen door beinvloed.

Be aware, hetzelfde issue had je met browserprefixes ook al. Toen introduceerde men ook al nieuwe features welke niet gestandaardiseerd waren. Maar juist doordat iedere browser zijn eigen tags (browsernaam-*) gebruikte was de kans op incompabiliteit nog groter.

[Anoniem: 125509]

Als de twee takken verder uit elkaar gaan lopen lijkt me dat geen haalbare kaart. Als twee -webkit- prefixes een andere parameterlijst verwachten loopt de boel sowieso in de soep.

Dus mooi streven, maar ik moet het nog zien gebeuren.

[Anoniem: 405779]

Blij dat Opera zich aansluit. Het gebeurt nogal eens dat websites in opera simpelweg niet werken en ik noodgedwongen 1 van de alternatieven moet opstarten. Super irritant.

Hoe meer partijen zich afsplitsen (en dus kleiner worden) hoe meer ze gedwongen worden rekening te houden met standaarden. Grote partijen zoals we dat vroeger kenden van MS kunnen hun "standaarden" niet langer opdringen.

[Relief2009]

Inderdaad. Het werd een beetje irritant met al die Webkit elements waarbij zaken niet correct werkten op browsers die zich echt aan standaarden hielden (IE10).

[Amito]

Grote partijen zoals we dat vroeger kenden van MS kunnen hun "standaarden" niet langer opdringen.

Ik snap vaak niet zo goed waarom het MS kwalijk wordt genomen. Is het erg om een browser mee te leveren bij je OS (ik ken mensen die het al raar vinden dat Office er niet standaard op zit). Dat is namelijk enige wat je ze kwalijk zou kunnen nemen. In die tijd had je simpelweg geen goed alternatief. Je had netscape, ik heb het geprobeerd, maar ik vond het maar zwaar, log en traag. Toen Firefox uitkwam ben ik meteen over gestapt omdat ze functionaliteiten hadden (bijv. tabs) dat erg handig was/is.

[Carbon]

De aankoniging op de WebKit mailinglist: Thank You

De reactie: Cleaning House

[RoestVrijStaal]

Na alle links in het artikel na te gaan kan ik concluderen dat het nog onduidelijk is onder welke licentie Blink gaat vallen.

Aangezien Webkit onder de BSD valt (op JavaScriptCore & WebCore na, want die vallen onder de LGPL2.1), bestaat in theorie dus de kans dat Google het doodleuk closed source houdt. Zeker als JavaScriptCore en WebCore worden vervangen door onderdelen van Opera's Presto engine.

[Anoniem: 125509]

Gezien hun historie met bijvoorbeeld Webm, Chrome en Android lijkt me dat een wel heel onlogische aanname, maar in theorie zou het kunnen. Een open source browser met een closed source engine. Maar in dat laatste geval verwacht ik weinig succes.

[Exception]

lgens Google zorgt het hebben van meerdere renderengines echter voor meer innovatie en ook zou het in de woorden van het bedrijf bijdragen aan 'de gezondheid van het totale open web-ecosysteem'.

Ik geloof wel dat dit voor meer innovatie gaat zorgen, maar we krijgen nu wel weer verschillen. Internet Explorer gaat zich eindelijk weer aan de 'regeltjes' houden en nu moeten zij het weer anders doen...

[Brummetje]

Een andere engine of meerdere engines zegt niks over het wel of niet aan de standaard houden natuurlijk.

[simplicidad]

Maar ik stel mij toch de vraag hoe het WebM debacle zou zijn afgelopen als Google beschikte over hun eigen browser engine in tegenstelling tot een engine waar ze meer rekening moet houden met anderen.

Het gevaar schuilt dat ze een IE'tje kunnen doen en in tegenstelling tot holle reclameslogans zoals "don't do evil", ben ik toch wat op mijn hoede voor zo'n zaken. Ik wil het echt niet terug meemaken dat tijdperk. Ook heel die CalDAV historie laat toch een vieze smaak na in mijn mond.

Naar wat ik gelezen heb heeft het ook te maken dat men bij webkit nogal strenge eisen stelt inzake het breken van stuff. Veel van die regels code die ze willen verwijderen zijn bvb tests en dergelijke voor andere platformen.

Elke patch & commit moet door een batterij tests (voor elk platform) lopen en vanaf dat ze ergens falen dan worden patches niet toegelaten. Het schijnt dat dit een doorn is in het oog is van Google. Dus compatibiliteit of incompatibiliteit heeft er ergens wel mee te zien.

[Reactie gewijzigd door simplicidad op 22 juli 2024 14:20]

[TheGhostInc]

(voor elk platform)

Multiplatform is soms een voordeel, maar soms ook gewoon een groter nadeel. Het is prachtig dat je programma nog draait op een Sparc of andere zwaar specialistische instructieset, maar als er dan een fout ontstaat moet Google iemand in dienst nemen die fouten kan oplossen in een versie die een paar mensen kunnen gebruiken...

Daarnaast moet je ook goed bedenken wie 'verantwoordelijk' is voor dergelijke builds. Je kunt ook besluiten dat je maar 1 of 2 architecturen ondersteunt en de rest is een port vanaf die codebase. Op die manier heb je een paar mensen die af en toe een versie exporteren en builden en de 'quirks' in de gaten houden in plaats van je hele developmentteam continu op te houden. Daarbij zijn er vaak speciale bibliotheken beschikbaar die dat eenvoudiger maken, daar hebben uiteindelijk meer mensen iets aan dan één heel specifiek programma.

[Martinspire]

Het lijkt me ook niet dat ze een ongebruikelijk OS zullen gebruiken voor het testen, maar de verschillende windows versies (bv tot xp) een paar linux distributies en osx voor de desktop en ios6, android 2.3/4.0 en mogelijk nog een ander os lijkt me toch wel het minimale.

Je moet als browserfabrikant gewoon rekening houden met je doelgroep en die bevindt zich gewoon op verschillende platformen. Minder testen lijkt me in dit tijdperk niet de bedoeling. Soms zie ik het bij de Beta en Dev van Chrome ook helemaal fout gaan. Dan ben ik ergens mee bezig en werkt het niet zoals het hoort terwijl dit in andere browsers geen probleem is. Ja, dat lees je goed, Webkit werkt soms niet goed meer. Al 4x gehad dat ik een dag of 2 aan het zoeken ben geweest waarom chrome de pagina niet goed weergeeft.
Momenteel lijkt ie schijt te hebben aan het toepassen van antialiasing aan fonts (of cleartype) en bij css animaties zie je vaak bij sommige animaties dingen verspringen omdat de hele pagina naar de videokaart gaat ipv een klein deel (firefox en IE10 doen dat wel goed)

[Reactie gewijzigd door Martinspire op 22 juli 2024 14:20]

[dtech]

Wat heeft WebM te maken met de browser engine? Chrome ondersteund WebM, ook als het dezelfde browserengine gebruikt als Safari. De ondersteuning voor een codec heeft bar weinig met de browserengine te maken.

[Exception]

Dat is waar, maar ik ben bang dat het toch altijd net iets anders wordt gerenderd waardoor je, al zijn het minimale, verschillen krijgt.

[arendjr]

Dat probleem bestaat helaas nu al tussen verschillende browsers, zelfs als ze allemaal WebKit gebruiken. Dit komt omdat verschillende browsers nog steeds verschillende rendering backends kunnen gebruiken met bijvoorbeeld verschillende font rendering of verschillende GPU acceleratie.

Ondanks dat je je aan de standaard houdt gaat er simpelweg niets boven ouderwets testen in verschillende browsers

[Brummetje]

Precies, en vergeet ook niet de verschillende besturingssystemen.... Chrome b.v. ziet er (fonts meestal) vaak anders uit op Windows, OSX en Linux.

[Pendaco]

En denk ook aan de verschillende chrome elementen (input types) van een browser, drop-downs, radio buttons, multiselect/checkbox etc.

[mcDavid]

Indirect wel. Zolang er meerdere veelgebruikte engines zijn, hebben zowel browsermakers als webdevelopers geen andere keus dan zich aan een algemene standaard te houden. Zodra er een monopolie ontstaat (zoals vroeger het geval was met Internet Explorer) is het nog maar een kleine stap naar het gebruik proprietary protocollen, waardoor concurrentie een stuk lastiger wordt.

[Freeaqingme]

De naam Blink refereert naar het veel bekritiseerde en niet gestandaardiseerde blink-element van html die tekst kon laten knipperen.

Gelukkig is daar altijd nog CSS:
[code]<span style="text-decoration: blink;">Text to blink here</span>[/code]

offtopic:
Welke admin wil er bij mij een html blink-tag invoegen?

[Exception]

En ook die werkt niet in Chrome hoor ;-)

[RM-rf]

en de BLINK tag zou overigens bedacht zijn door dezelfde persoon die ook de Lynx browser ontwikkelde, Lou Montulli

het was oorspronkelijk een grapje over de ontwikkeling van text-gebaseerde browsers naar visuele weergave van HTML-pagina's..
Montulli had gezegd dat als men een BLINK-tag zou toevoegen, deze ook in tekst-browsers ondersteund kon worden als grafisch effect.

http://www.montulli.org/theoriginofthe%3Cblink%3Etag

Back in 1994 I was a founding engineer at Netscape, prior to that I had written the Lynx browser, which predated all of the other popular browsers at that time. Lynx had been and still is a text only browser and is commonly used in a console window on UNIX machines. At Netscape we were building software that used a graphical user interface and could express vastly more text styles and layouts as well as images and other media. We spent a lot of time thinking about the future of the web and new technologies that would enable new classes of documents, applications and uses. A few examples of those thoughts were, HTML Tables, SSL for secure communications, Plugins for extensions, and JavaScript to enable dynamic HTML.

Sometime in late summer I took a break with some of the other engineers and went to a local bar on Castro street in Mountain View. The bar was the St. James Infirmary and it had a 30 foot wonder woman statue inside among other interesting things. At some point in the evening I mentioned that it was sad that Lynx was not going to be able to display many of the HTML extensions that we were proposing, I also pointed out that the only text style that Lynx could exploit given its environment was blinking text. We had a pretty good laugh at the thought of blinking text, and talked about blinking this and that and how absurd the whole thing would be. The evening progressed pretty normally from there, with a fair amount more drinking and me meeting the girl who would later become my first wife.

Saturday morning rolled around and I headed into the office only to find what else but, blinking text. It was on the screen blinking in all its glory, and in the browser. How could this be, you might ask? It turns out that one of the engineers liked my idea so much that he left the bar sometime past midnight, returned to the office and implemented the blink tag overnight. He was still there in the morning and quite proud of it.

[BramV]

Als iedereen in ieder geval de HTML5 standaard implementeert dan maakt het op zich niet uit welke browser of engine je gebruikt. Daar is HTML ooit voor uitgevonden ?

Html5 is nu zo rijk met mogelijkheden dat het nog jaren duurt voordat er weer iets echt fundamenteel anders nodig is. HTML5 is best wel een kleine stille revolutie (Bijv geen Flash meer nodig, geen Skype meer nodig etc.)

Dat bijv Microsoft altijd is gaan marchanderen met html standaarden maakt uiteindelijk dat zij geen belangrijke speler meer zijn op browser gebied. Soort Netscape 2.0...

[Loller1]

Met meer als 50% van de markt op de desktop vind ik Microsoft toch nog best een belangrijke speler...

Skype niet meer nodig? Je bedoelt die video chat dienst? Wat heeft dat met HTML5 te maken?

[Carbon]

Als iedereen in ieder geval de HTML5 standaard implementeert dan maakt het op zich niet uit welke browser of engine je gebruikt. Daar is HTML ooit voor uitgevonden ?

Dat is de theorie, de praktijk is helaas anders.
Probleem is dat HTML 5 kwa implementatie ongelofelijk complex is, een wereld met meerdere browserengines die allemaal gelijk renderen is een utopie.
Webkit als een soort opensource reference code leek een stap in de goede richting.

Html5 is nu zo rijk met mogelijkheden dat het nog jaren duurt voordat er weer iets echt fundamenteel anders nodig is. HTML5 is best wel een kleine stille revolutie (Bijv geen Flash meer nodig, geen Skype meer nodig etc.)

HTML5 + Javascript is nog lang geen 100% Flash vervanger, en dat hoeft ook niet want Apps hebben die leegte inmiddels opgevuld.

[mashell]

Dat bijv Microsoft altijd is gaan marchanderen met html standaarden maakt uiteindelijk dat zij geen belangrijke speler meer zijn op browser gebied. Soort Netscape 2.0...

Van wie had Microsoft dat "marchanderen" geleerd, inderdaad van Netscape. Toen Microsoft nog met Netscape zelf de standaarden zette ging de innovatie heel veel sneller dan nu waarin iedereen onderaan de ivoren toren staat te wachten tot de heren met witte jurken en grijze baarden van de w3c eindelijk eens naar beneden komen en weer eens wat opleveren.

[90710]

Google probeert zo veel mogelijk Apple er uit te drukken (App Store linkjes uit zoekresultaten verwijderen, etc).

[Luke_msx]

Als je een beetje tussen de regels van de acties van Google doorleest, lijkt dat inderdaad het geval te zijn. Don't be evil is veranderd in try to hide being evil...

Toen Google zelf een browser wilde ontwikkelen, vonden ze het wel prettig dat er al een boel werk voor hun gedaan was en ze Webkit als basis konden nemen. Maar nu Chrome langzamerhand een serieuze speler begint te worden, vinden ze het niet meer zo leuk dat andere partijen profiteren van het werk dat ze in Webkit steken.

Google lijkt een beetje op een paard van Troje.

[Reactie gewijzigd door Luke_msx op 22 juli 2024 14:20]

[watercoolertje]

Toen Google zelf een browser wilde ontwikkelen, vonden ze het wel prettig dat er al een boel werk voor hun gedaan was en ze Webkit als basis konden nemen. Maar nu Chrome langzamerhand een serieuze speler begint te worden, vinden ze het niet meer zo leuk dat andere partijen profiteren van het werk dat ze in Webkit steken.

Is dat gek Google steekt al sinds ze webkit gebruiken bijna meer tijd in webkit dan de rest bij elkaar (met 10-tallen bedrijven die bijdragen is dat best wel veel meer dan de rest doet)

http://photos.appleinsider.com/webkit-2013.png

Je kan ze overal van beschuldigen natuurlijk, moet je lekker zelf weten, maar als ik die statistieken bekijk is het niet meer dan logisch dat ze niet de grootste bijdrager willen zijn aan een project van een ander, voor een evil bedrijf maar ook voor een niet evil bedrijf is dit niet meer dan een logische stap, om dan voor jezelf te gaan, zodat je de grootste bijdrager bent aan je eigen project.

[Reactie gewijzigd door watercoolertje op 22 juli 2024 14:20]

[curumir]

Lies, damn lies and statistics.

Er staan twee indicatoren die een indruk geven van de mate van betrokkenheid. Het aantal commits en het aantal authors.
Apple en Google hebben bij de pie die het aantal commits weergeeft een even groot percentage (bijna 38%), Apple heeft zelfs een net iets hoger percentage.
Google wint het wel op het aantal authors, maar dat zegt veel minder dan het aantal commits. Beter 10 permanente ontwikkelaars dan 100 die 1 keer per maand iets committen.

Dus, jammer maar helaas. Afgaande op deze cijfers is Apple misschien wel de grotere committer. Je betoog dat Google meer dan de rest bijdraagt is dan ook zeer duidelijk niet waar.

[watercoolertje]

Nee jij loopt nu de boel te verdraaien door te rekenen vanaf 2002 terwijl ik het duidelijk heb over sinds Google Webkit gebruikt in Chrome, groot verschil natuurlijk...

Die onderste 2 grafieken gaan namelijk over 2002 tot heden dus - als je zoals ik dus aangeef meet vanaf Chrome- kan je daar helemaal NIKS uit halen...

Kijk nou is naar die bovenste 2 grafieken, reken daar vanaf 2008 toen Google Webkit uitbracht en je ziet dat Google minimaal 2x zo veel bijdraagt...

Dat Apple maar marginaal (nog geen hele %) meer bijdraagt van 2002 tot eind 2012 (8 jaar dus!) dan Google in maar 4 jaar zegt toch wel genoeg wie de afgelopen 4 jaren het meeste heet bijgedragen.

Het kan zijn dat je kleurenblind bent en de kleur groen met blauw verwisseld natuurlijk, maar ga niet zeggen dat ik lieg want dat doe ik niet! Jij loopt mij nu zwart te maken omdat jij kleurenblind bent of niet goed leest wat ik net zei (dat het mij om de laatste 4 jaren ging)...

[Reactie gewijzigd door watercoolertje op 22 juli 2024 14:20]

[curumir]

Lies, damn lies and statistics gaat over het interpreteren van statistieken op zo'n manier dat het jezelf het beste uitkomt. En dat is precies wat je doet.

Je verdedigt Google door te zeggen dat het rechtvaardig is om te forken omdat ze de grootste bijdrages leveren. Maar dan wel pas vanaf dat ze meedoen. Dat is toch precies wat ik bedoel?
Als je het hebt over de rechtvaardiging van een fork omdat ze zoveel gemaakt hebben kijk je natuurlijk naar de gehele livecycle. En daar zijn Apple en Google in evenwicht.

En tussen twee haakje, je hoeft Google helemaal niet te rechtvaardigen. Het is Open Source, ze mogen ook forken als ze 0% hebben bijgedragen.

[watercoolertje]

Ik zeg niet dat het rechtvaardig is om te forken, daar heb ik helemaal niks over te zeggen en/of oordelen. Ik zeg enkel dat ik hun keuze begrijp (om webkit te forken) en DAT verdedig ik

Maargoed succes met de discussie, ik ben er klaar mee...

[Reactie gewijzigd door watercoolertje op 22 juli 2024 14:20]

[Alwinonline]

Volgens mij lees jij de grafieken niet helemaal goed, het klopt inderdaad dat het aantal commits hoger is bij Apple, echter is Apple een jaartje of 3-4 eerder begonnen. Dus effectief gezien heeft google meer authors en commits bijgedragen.

[Amito]

Jalumsx heeft wel degelijk een punt. Google heeft geprofiteerd van jarenlang werk van de andere bedrijven en als ze nu iets terug doen dan vinden ze dat opeens oneerlijk.

Anyway, als het opensource blijft kunnen ze de code denk ik ook overnemen in webkit als het interessant genoeg is.

[watercoolertje]

Google ontneemt inderdaad helemaal niks, dus inderdaad hoe kan je het ze nu kwalijk nemen dat ze de afgelopen 4 jaar 2x zo veel hebben bijgedragen aan Webkit dan de initiator van het hele project

Alles wat Google er in heeft gestoken blijft er ook in, en Webkit blijft gewoon open source want daar heeft Google niks mee te maken...

En hun eigen fork is ook weer open source dus als iemand nog van Google wil blijven profiteren kan dat ook gewoon...