Opera wordt Chromium-browser met Webkit-engine
Browserbouwer Opera ruilt zijn eigen render-engine Presto in voor Webkit, de engine die onder meer Apple en Google gebruiken voor hun browsers. Toekomstige versies van Opera zullen bovendien gebaseerd zijn op Chromium.
De overgang waarbij Opera op Chromium wordt gebaseerd, vindt dit jaar geleidelijk plaats, zegt Opera. Vermoedelijk zullen mobiele browsers als eerste gebruikmaken van de Webkit-engine. Enige tijd geleden kwam er informatie naar buiten over Ice, een Opera-browser voor iOS en Android, die gebruikmaakt van de Webkit-engine.
Chromium is de opensourcebrowser waarop Googles Chrome gebaseerd is. Opera zal later deze maand, op telecombeurs Mobile World Congress, zijn eerste Webkit-browser tonen. Die browser zal draaien op Android. Wanneer de desktopversie van Opera precies zal overgaan en of er versies blijven met Opera's eigen render engine Presto is onduidelijk. Opera zal actief bijdragen aan Webkit en Chromium met patches.
Dankzij de overstap hoopt Opera meer tijd en mankracht te hebben voor de implementatie van nieuwe features. Het ontwikkelen van een eigen render-engine kost veel tijd. Door de overgang van Opera naar Webkit blijven er drie 'grote' render-engines over: Webkit van Chrome, Chromium, Safari en Opera, Gecko van Firefox, en Trident van Internet Explorer. Veel mobiele browsers, van onder meer iOS, Android en BlackBerry 10, zijn ook gebaseerd op Webkit.
Opera heeft op de markt voor desktopbrowsers een marktaandeel van rond 1 procent volgens Statcounter. Op Tweakers ligt dat percentage iets hoger; in de afgelopen maand gebruikte 1,76 procent van de bezoekers een browser van Opera.
Reacties (223)
En hoe groter de kans op een nieuw IE-debacle. Je ziet nu al dat er steeds meer developers webkit-only optimalisaties doorvoeren.
Webkit is niet door apple gestart. Het is een fork van KHTML, de render engine van de KDE browser Konqueror.Het is door Apple gestart, maar het lijkt me dat ook Google eraan werkt.
Jammer dat dit door mensen, alsook in dit artikel, volledig word genegeerd!
[Reactie gewijzigd door Emielvenlo op woensdag 13 februari 2013 21:29]
Waarom zouden ze dan bugs snel fixen? Het is een leuk idee dat ze dan allemaal gezellig samenwerken en het daardoor sneller gefixed wordt, maar zo werkt het meestal toch niet.
Het probleen van IE6 was dan ook niet dat ze het niet konden fixen, dat is duidelijk dat het kon, maar dat ze bijzonder weinig reden hadden om het te fixen en standaarden te volgen. Je zal exact hetzelfde probleem hebben als webkit zwaar dominant wordt. Waarom zouden ze moeilijk doen met standaarden, ze zijn dan de standaard.
Ik zie dan ook geen enkele reden om aan te nemen dat er meer geld in webkit gestoken zal worden als die dominant is dan dat er in IE6 werd gestoken. Dat is juist des te meer het geval als meerdere bedrijven eraan werken, leuke illusie dat ze dan allemaal hard eraan werken, veel geld erin steken en snel bugs fixen, maar nogmaals, waarom zouden ze dat doen? Het is voor je bedrijf veel handiger als je zo min mogelijk eraan doet. Al je concurenten hebben ook last van diezelfde bug, dus dat maakt jou niks uit, en beter nog, uiteindelijk lost een concurent het ook wel op, laat die dus maar lekker ervoor betalen.
Nee meerdere render engines die allemaal wel redelijk netjes standaarden volgen en elkaar beconcureren is een veel beter idee.
Het probleen van IE6 was dan ook niet dat ze het niet konden fixen, dat is duidelijk dat het kon, maar dat ze bijzonder weinig reden hadden om het te fixen en standaarden te volgen. Je zal exact hetzelfde probleem hebben als webkit zwaar dominant wordt. Waarom zouden ze moeilijk doen met standaarden, ze zijn dan de standaard.
Ik zie dan ook geen enkele reden om aan te nemen dat er meer geld in webkit gestoken zal worden als die dominant is dan dat er in IE6 werd gestoken. Dat is juist des te meer het geval als meerdere bedrijven eraan werken, leuke illusie dat ze dan allemaal hard eraan werken, veel geld erin steken en snel bugs fixen, maar nogmaals, waarom zouden ze dat doen? Het is voor je bedrijf veel handiger als je zo min mogelijk eraan doet. Al je concurenten hebben ook last van diezelfde bug, dus dat maakt jou niks uit, en beter nog, uiteindelijk lost een concurent het ook wel op, laat die dus maar lekker ervoor betalen.
Nee meerdere render engines die allemaal wel redelijk netjes standaarden volgen en elkaar beconcureren is een veel beter idee.
Dat vind ik nogal een gedurfde uitspraak om het zo neer te zetten alsof het de enige juiste mogelijkheid is
Het ligt puur aan de bedrijven zelf of dit goed of slecht zal zijn
Als je kijkt naar Google en Opera hebben zei enorm veel belang bij een goed functionerende render engine. Vooral Google omdat die toch veel meer in de browser willen doen dan nu het geval is
Die zullen dus wel hoge prioriteit geven aan bugs ed aangezien dit 1 van de belangrijke producten is van Google
Het ligt puur aan de bedrijven zelf of dit goed of slecht zal zijn
Als je kijkt naar Google en Opera hebben zei enorm veel belang bij een goed functionerende render engine. Vooral Google omdat die toch veel meer in de browser willen doen dan nu het geval is
Die zullen dus wel hoge prioriteit geven aan bugs ed aangezien dit 1 van de belangrijke producten is van Google
[Reactie gewijzigd door Mellow Jack op woensdag 13 februari 2013 13:01]
Dit probleem is er momenteel al wel op het mobiele gebied. Daar is de overgrote meerderheid webkit, op enkele nokia's en mensen die zelf opera installeren na.
Hier gebeurt het al regelmatig dat alleen voor webkit gebouwd wordt, gebruikers van andere platformen kunnen dan in de feces zakken. Inderdaad praktijken uit het IE6 tijdperk.
Hier gebeurt het al regelmatig dat alleen voor webkit gebouwd wordt, gebruikers van andere platformen kunnen dan in de feces zakken. Inderdaad praktijken uit het IE6 tijdperk.
Voorbeelden?Het gaat nu al niet meer goed, als het even kan, volgt Webkit de standaard niet.
Of heb je het nu over de experimentele (prefixed) features, die nodig te zijn om webontwikkelaars de mogelijkheid te geven nieuwe standaarden die nog in ontwikkeling zijn zelf te kunnen testen en feedback aan de W3C te kunnen leveren? Want dat laatste lijkt me niet echt een slechte zaak, en zelfs nodig als je wilt dat we straks niet met allemaal slecht uitgedachte standaarden komen te zitten.
Ik vind het ook geen goede zaak dat veel ontwikkelaars doen alsof prefixed standaarden gewoon zonder fallback gebruikt kunnen worden, maar dat is toch echt een probleem wat door die ontwikkelaars zelf veroorzaakt wordt - veel dingen die nu in ontwikkeling zijn moeten gewoon daadwerkelijk gebruikt kunnen worden door ontwikkelaars om te kijken of sommige APIs handig werken en niet makkelijker gemaakt kunnen worden etc. Het gebeurt toch zo nu en dan dat een experimentele HTML5 standaard geschrapt/aangepast word omdat het in de praktijk niet lekker bleek te werken
Dat is juist een afspraak tussen de W3C en de browserbouwers....en daarbij meteen de -webkit- prefix gebruiken om ervoor te zorgen...
Van elke standaard met een 'Release candidate' status wordt de implementatie in de browser gestimuleerd door de W3C om het in de praktijk te testen op tekortkomingen.
Door per engine een prefix te gebruiken kan je als ontwikkelaar zorgen dat de verschillende implementaties elkaar niet bijten.
En als de definitieve standaard vast komt te liggen dan kan je de definitieve standaard met een 'zoek en vervang' implementeren.
Je klaagt dus eigenlijk dat Webkit voorop loopt met de implementatie van release candidate standaarden.
Het is meer dat webkit uiteindeliijk ondersteuning laat bestaan voor die prefixed features ook als ze eenmaal de officiele standaard ondersteunen die dan vaak anders werkt.
Ze zouden of de ondersteuning voor de prefixed versies moeten laten vallen als ze de officiele versie van een feature ondersteunen ofwel de prefixed versie ook conform die standaard moeten laten werken.
Doordat de webkit code dat niet doet en de afwijkende werking voor prefixed code laat bestaan krijg je een soort eeuwige beta code die blijft hangen waardoor er steeds meer afwijkende pagina's onstaan.
Je krijgt een soort nieuwe quirksmode.
Ze zouden of de ondersteuning voor de prefixed versies moeten laten vallen als ze de officiele versie van een feature ondersteunen ofwel de prefixed versie ook conform die standaard moeten laten werken.
Doordat de webkit code dat niet doet en de afwijkende werking voor prefixed code laat bestaan krijg je een soort eeuwige beta code die blijft hangen waardoor er steeds meer afwijkende pagina's onstaan.
Je krijgt een soort nieuwe quirksmode.
Er is nu eenmaal een verschil tussen wat HTML ooit had moeten zijn en wat het is geworden. Het was een meer beschrijvende taal: dit is een kop, dit een alinea, dit is een link en hier ergens komt een plaatje: zie maar hoe je het weergeeft. Het voordeel daaraan is dat je niet om een bepaalde schermresolutie of zelfs scherm hoeft te vragen. Ook voor blinden kan een site dan heel toegankelijk worden gemaakt.
Geheel tegen alle verwachtingen in wilden mensen niet alleen functionele websites maar ook mooie websites. Developers gebruikten frames en tables en andere elementen die bedoeld zijn om data gestructureerd weer te geven, om een website er op een gewenste manier uit te laten zien. Uiteindelijk is daar met HTML5 rekening mee gehouden, maar de oorspronkelijke keuzevrijheid van een HTML-engine is hiermee verdwenen: webdevelopers willen een website pixelperfect kunnen maken. Dat betekent dat ofwel iedere render-engine precies hetzelfde moet doen (waarom dan niet maar 1 engine hebben), of iedere website moet voor alle gebruikte render-engines worden aangepast.
Geheel tegen alle verwachtingen in wilden mensen niet alleen functionele websites maar ook mooie websites. Developers gebruikten frames en tables en andere elementen die bedoeld zijn om data gestructureerd weer te geven, om een website er op een gewenste manier uit te laten zien. Uiteindelijk is daar met HTML5 rekening mee gehouden, maar de oorspronkelijke keuzevrijheid van een HTML-engine is hiermee verdwenen: webdevelopers willen een website pixelperfect kunnen maken. Dat betekent dat ofwel iedere render-engine precies hetzelfde moet doen (waarom dan niet maar 1 engine hebben), of iedere website moet voor alle gebruikte render-engines worden aangepast.
edit:
@latka: Webdevelopers willen misschien helemaal geen website hebben, dat willen hun klanten.
@mcDavid: Als de specificaties zo strikt moeten zijn dat websites pixel voor pixel hetzelfde zijn in elke browser die de specificatie volgt, dan hebben we mijn eerste optie: iedere render-engine doet exact hetzelfde. De manier waarop, de snelheid waarmee en het platform waar onder kan dan natuurlijk wel verschillen.
@latka: Webdevelopers willen misschien helemaal geen website hebben, dat willen hun klanten.
@mcDavid: Als de specificaties zo strikt moeten zijn dat websites pixel voor pixel hetzelfde zijn in elke browser die de specificatie volgt, dan hebben we mijn eerste optie: iedere render-engine doet exact hetzelfde. De manier waarop, de snelheid waarmee en het platform waar onder kan dan natuurlijk wel verschillen.
[Reactie gewijzigd door 84hannes op woensdag 13 februari 2013 15:20]
Kun je mij uitleggen waarom verschillende renderengines bijdragen aan gezonde concurrentie tussen browsers?
Dat een gebruiker de features van Firefox boven Chrome prefereert kan ik goed begrijpen. Maar een voorkeur voor Gecko boven Webkit of andersom begrijp ik niet (als gebruiker, niet als developer). Niemand - niet gebruikers, webdevelopers of browserontwikkelaars - heeft er *echt* belang bij dat er verschillende renderengines zijn: dat is historisch alleen zo gegroeid.
Mozilla heeft al zijn technologie rond XUL en daarmee Gecko gebouwd, en Microsoft heeft Internet Explorer verwoven met Windows. Als dit niet het geval was geweest waren ook zij waarschijnlijk overgestapt naar Webkit of hadden dat in ieder geval overwogen.
Dat een gebruiker de features van Firefox boven Chrome prefereert kan ik goed begrijpen. Maar een voorkeur voor Gecko boven Webkit of andersom begrijp ik niet (als gebruiker, niet als developer). Niemand - niet gebruikers, webdevelopers of browserontwikkelaars - heeft er *echt* belang bij dat er verschillende renderengines zijn: dat is historisch alleen zo gegroeid.
Mozilla heeft al zijn technologie rond XUL en daarmee Gecko gebouwd, en Microsoft heeft Internet Explorer verwoven met Windows. Als dit niet het geval was geweest waren ook zij waarschijnlijk overgestapt naar Webkit of hadden dat in ieder geval overwogen.
Omdat als er maar één render engine is, er geen enkele drive meer is om bugs eruit te halen en te innoveren, gezien dat dat geen enkel voordeel voor een bedrijf oplevert.
Nu als bijvoorbeeld alle engines behalve webkit bewegende gifjes kunnen laten zien, enkel webkit niet, dan kan ik je verzekeren dat dat bijzonder snel erin gegooid wordt, anders hebben immers de browsers die webkit gebruiken een flink probleem. Zonder concurentie hebben ze geen reden om dat te implementeren, het is niet alsof de consument kan overstappen naar een browser die het wel aankan. En als er een bug in zit dan maakt het je niks uit als browsermaker als er nog maar één renderengine is, immers de concurentie heeft er net zoveel last van, laat het hun maar lekker oplossen.
Nu als bijvoorbeeld alle engines behalve webkit bewegende gifjes kunnen laten zien, enkel webkit niet, dan kan ik je verzekeren dat dat bijzonder snel erin gegooid wordt, anders hebben immers de browsers die webkit gebruiken een flink probleem. Zonder concurentie hebben ze geen reden om dat te implementeren, het is niet alsof de consument kan overstappen naar een browser die het wel aankan. En als er een bug in zit dan maakt het je niks uit als browsermaker als er nog maar één renderengine is, immers de concurentie heeft er net zoveel last van, laat het hun maar lekker oplossen.
De drive om een renderengine te verbeteren zou moeten zijn om een beter web te maken. Dit is de primaire motivatie van Google om aan Webkit te werken (en het uberhaupt in eerste instantie te kiezen) en die van Mozilla. Het gaat hen niet primair om de prestige van de beste renderingengine maar om het maken van een sneller en featurerijker web. In het geval van Mozilla gaat het om idealen die ze nastreven, en Google om meer geld te verdienen met een betere ervaring in webapplicaties.
Hoewel Microsoft en Apple de concurrentiestrijd misschien wat sterker voelen, is het niet alsof het verbeteren van een renderengine primair wordt gemotiveerd door concurrentiespelletjes. Met die redenatie zou ook niemand gemotiveerd moeten zijn om aan de Linux-kernel te werken. Die heeft, genomen over het gehele toepassingsgebied van de Linux-kernel, ook geen significante concurrentie. Het is hierbij van belang dat het product open source is, en dat zijn Webkit en Gecko.
Als Webkit (of Gecko, of een open source Trident of Presto) gekozen zou worden als dé referentie-implementatie van het W3C, zouden de verbeteringen erin aangebracht met dezelfde motivatie als het W3C nog bezig is een nieuwe HTML-standaard te ontwikkelen: het verbeteren van het web.
Dat gaat niet gebeuren. Maar als het wel zou gebeuren, zou het veel minder moeite kosten om standaarden te definiëren, zouden browserontwikkelaars geen dubbel werk meer hoeven doen, zouden webdevelopers veel tijdwinst kunnen hebben, en zouden gebruikers beter gedragende webapps hebben. Los van de legacy-perikelen die dit op zou leveren voor met name Microsoft is dat een absolute win-win-situatie mijns inziens.
Hoewel Microsoft en Apple de concurrentiestrijd misschien wat sterker voelen, is het niet alsof het verbeteren van een renderengine primair wordt gemotiveerd door concurrentiespelletjes. Met die redenatie zou ook niemand gemotiveerd moeten zijn om aan de Linux-kernel te werken. Die heeft, genomen over het gehele toepassingsgebied van de Linux-kernel, ook geen significante concurrentie. Het is hierbij van belang dat het product open source is, en dat zijn Webkit en Gecko.
Als Webkit (of Gecko, of een open source Trident of Presto) gekozen zou worden als dé referentie-implementatie van het W3C, zouden de verbeteringen erin aangebracht met dezelfde motivatie als het W3C nog bezig is een nieuwe HTML-standaard te ontwikkelen: het verbeteren van het web.
Dat gaat niet gebeuren. Maar als het wel zou gebeuren, zou het veel minder moeite kosten om standaarden te definiëren, zouden browserontwikkelaars geen dubbel werk meer hoeven doen, zouden webdevelopers veel tijdwinst kunnen hebben, en zouden gebruikers beter gedragende webapps hebben. Los van de legacy-perikelen die dit op zou leveren voor met name Microsoft is dat een absolute win-win-situatie mijns inziens.
[Reactie gewijzigd door DCK op woensdag 13 februari 2013 15:10]
Het probleem speelt zich vooral in de CSS implementatie. Het gaat dus niet om features of platform-verwevenheid.Kun je mij uitleggen waarom verschillende renderengines bijdragen aan gezonde concurrentie tussen browsers?
Maar de vice voorzitter van het W3C kan het misschien beter voor je uitleggen waarom de dominantie van Webkit de open standaarden van het web bedreigt:
http://www.glazman.org/we...HE-OPEN-WEB-NEEDS-YOU-NOW
Ik ben goed op de hoogte van wat wel en niet kan. En er is een reden voor het bestaan van projecten als Wine of Darwine: platform onafhankelijke software is dan wel zwaar inefficient (scripting-talen, Java), dan wel ontzettend beperkt in wat het kan.
Je kunt platform dependence verminderen met dingen als Python of Java, maar je blijft er rekening mee moeten houden.
Shared Objects, ja heel leuk. Dan moet je dus binnen de rendering-engine-loze browser een library / shared object manager gaan bouwen om te trachten om dat in goede banen te leiden en dependency hells te voorkomen. Bovendien krijg je ongetwijfeld websites die niet zo actief bijgehouden worden en een 'oude' versie van 'webkit' serveren, waar weer bugs in zitten die de de PC van de gebruiker investeren met allerhande puinzooi. Zo eenvoudig is dat dus niet.
Dan heb je nog security. Met deze aanpak zou je een willekeurige website toestaan om code op jouw PC uit te voeren, die een rendering-engine zou moeten implementeren. Maar misschien doet die rendering engine nog weer hele andere dingen, waar de gebruiker helemaal niet op zit te wachten. Java op internet is niet voor niets aardig in diskrediet geraakt op websites: feitelijk zou je daarmee kunnen doen wat jij omschrijft. Echter, er kan veel meer gebeuren, er kunnen bugs zitten in de Java VM en weet ik wat allemaal niet. Je opent een gigantische mogelijkheid om de gebruikers aan te vallen, en al die willekeurige code zal op de een of andere manier gecontroleerd moeten worden op veiligheid. Bouwers van virusscanners zullen je dankbaar zijn mocht dit doorgang vinden.
En dan nog een knelpunt: smartphones / tablets. Met hun beperkte resources, opslagruimte en rekenkracht zullen die het een stuk zwaarder krijgen om custom code uit te moeten voeren om elke website te renderen. Bovendien zal het datagebruik ook hier flink moeten stijgen, zelfs met efficiente caching van de rendering code.
Ook voor krachtigere PC's is dit rampzalig: elke website die een slightly different rendering engine heeft zal apart geladen moeten worden, waardoor het geheugengebruik flink zal stijgen, terwijl ze grofweg hetzelfde doen.
Je kunt platform dependence verminderen met dingen als Python of Java, maar je blijft er rekening mee moeten houden.
Shared Objects, ja heel leuk. Dan moet je dus binnen de rendering-engine-loze browser een library / shared object manager gaan bouwen om te trachten om dat in goede banen te leiden en dependency hells te voorkomen. Bovendien krijg je ongetwijfeld websites die niet zo actief bijgehouden worden en een 'oude' versie van 'webkit' serveren, waar weer bugs in zitten die de de PC van de gebruiker investeren met allerhande puinzooi. Zo eenvoudig is dat dus niet.
Dan heb je nog security. Met deze aanpak zou je een willekeurige website toestaan om code op jouw PC uit te voeren, die een rendering-engine zou moeten implementeren. Maar misschien doet die rendering engine nog weer hele andere dingen, waar de gebruiker helemaal niet op zit te wachten. Java op internet is niet voor niets aardig in diskrediet geraakt op websites: feitelijk zou je daarmee kunnen doen wat jij omschrijft. Echter, er kan veel meer gebeuren, er kunnen bugs zitten in de Java VM en weet ik wat allemaal niet. Je opent een gigantische mogelijkheid om de gebruikers aan te vallen, en al die willekeurige code zal op de een of andere manier gecontroleerd moeten worden op veiligheid. Bouwers van virusscanners zullen je dankbaar zijn mocht dit doorgang vinden.
En dan nog een knelpunt: smartphones / tablets. Met hun beperkte resources, opslagruimte en rekenkracht zullen die het een stuk zwaarder krijgen om custom code uit te moeten voeren om elke website te renderen. Bovendien zal het datagebruik ook hier flink moeten stijgen, zelfs met efficiente caching van de rendering code.
Ook voor krachtigere PC's is dit rampzalig: elke website die een slightly different rendering engine heeft zal apart geladen moeten worden, waardoor het geheugengebruik flink zal stijgen, terwijl ze grofweg hetzelfde doen.
Opera was is weldegelijk groot. Opera Mini is in Azië, delen van Oost-Europa en India erg populair. Dit omdat het draait op elk toestel, ook de waar normaal gesproken geen volledige render engine op zal draaien. Bijvoorbeeld een Nokia 6230.
http://gs.statcounter.com...-as-monthly-201201-201301
(okee, ze worden wereldwijd ingehaald door (budget-)android-toestellen, maar dan nog. 24% voor een heel continent is best veel)
http://gs.statcounter.com...-as-monthly-201201-201301
(okee, ze worden wereldwijd ingehaald door (budget-)android-toestellen, maar dan nog. 24% voor een heel continent is best veel)
Die -webkit (en -o, en -ie, en -firefox, en watdanook) prefixes zijn voor extensies die nog niet standaard zijn, maar wat een standaard in wording is. Je ageert tegen iets wat juist heel duidelijk is afgesproken.
Wat jij feitelijk zegt is dat browsers zich niet aan de standaarden houden.Zou prettig zijn.... maar zolang de W3C standaarden achter lopen bij de browser, is daar weinig hoop op...
Hoe kunnen standaarden nu achter lopen? Op wat? Op eigen wensen en verzinsels van de browsermakers? IE-praktijken van weleer dus.
Een standaard is een afspraak die NU geldt. Per definitie kan die dus niet achterlopen.
IE6 is niet te vergelijken. Webkit wordt door meerdere bedrijven actief ontwikkeld, waaronder bedrijven die belang hebben in een snelle evolutie van het web. Tevens auto-updaten bijna alle web browsers.
Microsoft had in die tijd een belang om juist het web tegen te houden, en liet de browser versloffen. Ook deed het geen enkele moeite om oude versies op te ruimen. Twee heel belangrijke verschillen.
We hebben nog steeds 3 verschillende main engines, en dat is meer dan genoeg. Het probleem is helemaal niet webkit, het probleem is incompetente developers die webkit-only features bakken, in gevallen waar dit niet gepast is.
Microsoft had in die tijd een belang om juist het web tegen te houden, en liet de browser versloffen. Ook deed het geen enkele moeite om oude versies op te ruimen. Twee heel belangrijke verschillen.
We hebben nog steeds 3 verschillende main engines, en dat is meer dan genoeg. Het probleem is helemaal niet webkit, het probleem is incompetente developers die webkit-only features bakken, in gevallen waar dit niet gepast is.
Dat is juist het probleem, webkit volgt de standaarden niet zo nauw, ze willen OF te ver voorlopen en voeren webkit-specifieke dingen in (CSS3 is vrij goed uitgezet, maar toch zijn er dingen als:
webkit-border-radius
en
border-radius
Border Radius is iets wat niet eens zo lang geleden tot standaard gebombardeerd wordt. Je geeft het een paar nummertjes mee, en voila, je objectje heeft een mooi afgeronde border. Het punt is dat webkit iets te snel was met het invoeren van een draft-standaard (in plaats van afwachten tot de echte standaard), en hun eigen implementatie maakte wat EXACT hetzelfde doet, maar dan twee nummertjes heeft omgedraait... en een webkit-tag er voor.
Het resultaat? Tsja... veel "techies" die zeuren dat een browser niet webkit-compatible is, als hij 100% HTML5 & CSS3 volgt... en een hoop webdevvers die, zoals eerder omschreven, pietje precies webkit ontwikkelen.
Webkit is hard op weg om een nieuw IE6 te worden: de tijd vooruit, engine-specifieke rendertags, en een groot marktaandeel... het is eigenlijk een gevaar. Gecko is overigens niet zo handig bezig als je het mij vraagt door SOMS wel en SOMS niet webkit-tags te renderen... zo krijg je nog meer webkit-specifiek ontwikkelwerk (met de motivatie: het werkt toch wel onder firefox), en nog meer onverwachte eigenaardigheden, zoals op dit moment met fileapi en notifications...
Ik zou haast hierdoor de switch maken naar IE10. Eigenlijk... ik denk dat ik dat ga doen.
webkit-border-radius
en
border-radius
Border Radius is iets wat niet eens zo lang geleden tot standaard gebombardeerd wordt. Je geeft het een paar nummertjes mee, en voila, je objectje heeft een mooi afgeronde border. Het punt is dat webkit iets te snel was met het invoeren van een draft-standaard (in plaats van afwachten tot de echte standaard), en hun eigen implementatie maakte wat EXACT hetzelfde doet, maar dan twee nummertjes heeft omgedraait... en een webkit-tag er voor.
Het resultaat? Tsja... veel "techies" die zeuren dat een browser niet webkit-compatible is, als hij 100% HTML5 & CSS3 volgt... en een hoop webdevvers die, zoals eerder omschreven, pietje precies webkit ontwikkelen.
Webkit is hard op weg om een nieuw IE6 te worden: de tijd vooruit, engine-specifieke rendertags, en een groot marktaandeel... het is eigenlijk een gevaar. Gecko is overigens niet zo handig bezig als je het mij vraagt door SOMS wel en SOMS niet webkit-tags te renderen... zo krijg je nog meer webkit-specifiek ontwikkelwerk (met de motivatie: het werkt toch wel onder firefox), en nog meer onverwachte eigenaardigheden, zoals op dit moment met fileapi en notifications...
Ik zou haast hierdoor de switch maken naar IE10. Eigenlijk... ik denk dat ik dat ga doen.
Dat is expres, en precies met die reden: daarmee kun je dus als browserbouwer alvast die standaarden implementeren voordat ze standaard zijn en als dan later de standaard toch aangepast wordt tov de draft (zoals hier blijkbaar gebeurd is) heb je geen sites die kapot gaan. En Firefox kan dan juist geimplementeerd hebben wat later wel tot standaard gebombardeerd wordt (dus met die nummertjes omgedraaid, wat men blijkbaar logischer vindt), en dan heb je terwijl de standaard nog geen standaard is geen sites die op webkit 't een doen en op firefox het ander. In plaats daarvan zeg je als webbouwer dus tegen webkit X-Y en tegen firefox Y-X, tegelijk. Eenmaal de standaard geaccepteerd voeg je de standaard (Y-X) toe.Border Radius is iets wat niet eens zo lang geleden tot standaard gebombardeerd wordt. Je geeft het een paar nummertjes mee, en voila, je objectje heeft een mooi afgeronde border. Het punt is dat webkit iets te snel was met het invoeren van een draft-standaard (in plaats van afwachten tot de echte standaard), en hun eigen implementatie maakte wat EXACT hetzelfde doet, maar dan twee nummertjes heeft omgedraait... en een webkit-tag er voor.
Je zou het eigenlijk helemaal niet moeten hoeven testen in 3 browsers als de standaarden al gewoon prima in elkaar zitten. Omdat HTML5 nog niet zo heel lang definitief is geworden (ok, het hele proces is nog niet klaar, maar er zit nu al wat schot in) lopen nog niet alle browsers bij. Doordat webkit echter een heleboel features al had toegevoegd, zitten we nu op het punt waarop vele websites weer aanpassingen moeten doen om browsers compatibel te maken aan de originele standaard.
Voordat HTML5 kwam, had ik geen problemen om een site die ik in chrome heb opgebouwd in firefox te laten werken. Maar omdat men bij webkit op een gegeven moment concept webstandaarden is gaan gebruiken, werkte die manier opeens niet meer.
Voordat HTML5 kwam, had ik geen problemen om een site die ik in chrome heb opgebouwd in firefox te laten werken. Maar omdat men bij webkit op een gegeven moment concept webstandaarden is gaan gebruiken, werkte die manier opeens niet meer.
Ik ben benieuwd wat voor opera-specifieke truukjes jij moest uitvoeren dan. Als je firefox en chrome goed had, was er in mijn beleving weinig wat er nog aan opera moest gebeuren.
Overigens gaat Opera zich nog wel druk maken over de renderer:
"Our first patch to WebKit (so for all WK browsers) is to bring CSS multi-col to Presto levels."
Overigens gaat Opera zich nog wel druk maken over de renderer:
"Our first patch to WebKit (so for all WK browsers) is to bring CSS multi-col to Presto levels."
Op dit item kan niet meer gereageerd worden.
Populair: Samsung Websites en communities Mobiele telefoons Laptops Sony Games Microsoft Politiek en recht Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
