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.
IE werd maar door één bedrijf onderhouden, straks wordt Webkit door meerdere bedrijven onderhouden, ik denk niet dat het een slechte stap is is.
Correctie: straks wordt webkit door nog meer bedrijven onderhouden. Maar idd, als fervent Opera-gebruiker juich ik dit toe.
Webkit word al door meerdere bedrijven onderhouden. Het is door Apple gestart, maar het lijkt me dat ook Google eraan werkt.
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]
Het is inderdaad jammer dat er volledig aan dit feit voorbij wordt gegaan op een website als Tweakers.net. Sowieso is er niets mis met wat meer achtergrond informatie, maar dat geheel terzijde.
[Reactie gewijzigd door kevinv2u op woensdag 13 februari 2013 21:55]
Je kan KHTML zo hard omhoog prijzen als je wil, maar feit blijft dat sinds de 'fork' (zelfs de eerste WebKit was veel meer dan slechts een KHTML fork) WebKit echt heel wat meer is geworden dan wat KHTML was.
Sure, je kan de bron van WebKit wel toeschrijven aan KHTML, maar dat is dan ook dat. Het is Apple die WebKit zo gemaakt heeft als het nu is, waarbij Google sinds WebKit opensource en op zichzelf gegaan is ook aan het bijdragen is.
Maakt dit KDE, Apple of Google de WebKit baas? Nee, maar behalve KDE en Apple is er niemand te bedanken voor de kwaliteit van WebKit. Google heeft geowoon toen WebKit mature genoeg was 'ook even een browser gemaakt'. En nu schrijft iedereen Google Chrome als de grote WebKit baas, terwijl het toch echt Apple was die er wat van gemaakt heeft, met KHTML als bron. Zonder KTHML had Apple wel een andere engine gevonden, of gewoon zelf een gemaakt... maar dat deden ze niet, ze hebben KHTML gepakt, en dat zegt wel wat over de kwaliteit van KHTML.
Stel dat WebKit genoemd wordt, en daarna een browser als voorbeeld genoemd moet worden, dan is Safari toch wel het 1e voorbeeld, dat is gewoon de definitie van WebKit! Daarna zou je Chromium en dan misschien nog Chrome kunnen noemen, maar dat constante gedoe alsof WebKit van Google is.. bah. Het was van Apple, en nu is het van zichzelf. The end.
Sure, je kan de bron van WebKit wel toeschrijven aan KHTML, maar dat is dan ook dat. Het is Apple die WebKit zo gemaakt heeft als het nu is, waarbij Google sinds WebKit opensource en op zichzelf gegaan is ook aan het bijdragen is.
Maakt dit KDE, Apple of Google de WebKit baas? Nee, maar behalve KDE en Apple is er niemand te bedanken voor de kwaliteit van WebKit. Google heeft geowoon toen WebKit mature genoeg was 'ook even een browser gemaakt'. En nu schrijft iedereen Google Chrome als de grote WebKit baas, terwijl het toch echt Apple was die er wat van gemaakt heeft, met KHTML als bron. Zonder KTHML had Apple wel een andere engine gevonden, of gewoon zelf een gemaakt... maar dat deden ze niet, ze hebben KHTML gepakt, en dat zegt wel wat over de kwaliteit van KHTML.
Stel dat WebKit genoemd wordt, en daarna een browser als voorbeeld genoemd moet worden, dan is Safari toch wel het 1e voorbeeld, dat is gewoon de definitie van WebKit! Daarna zou je Chromium en dan misschien nog Chrome kunnen noemen, maar dat constante gedoe alsof WebKit van Google is.. bah. Het was van Apple, en nu is het van zichzelf. The end.
Hopelijk gaat IE ook nog eens over op webkit!
Als ze niet volledig overgaan op webkit hoop ik dat ze een directive introduceren om toch webkit te kunnen gebruiken. Iets in de trant van "<meta renderer=webkit />" ofzo.
Dat zou een ware zegen zijn voor developers.
Als ze niet volledig overgaan op webkit hoop ik dat ze een directive introduceren om toch webkit te kunnen gebruiken. Iets in de trant van "<meta renderer=webkit />" ofzo.
Dat zou een ware zegen zijn voor developers.
Dat zou een zeer slechte ontwikkeling zijn: iedereen dezelfde browser iedereen dezelfde bugs en dus iedereen dezelfde exploits.... Eigenlijk hetzelfde als de IE6 tijd dus. Fijn dat je dat iedereen toewenst.
Nee, dat is gewoon niet waar. Het zou heerlijk zijn; met zoveel bedrijven die er geld in steken zullen bugs en exploits snel worden gefixt. En het is niet zo dat Trident geen exploits en bugs heeft.
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]
Het probleem van IE6 is dat Microsoft een monopolie-positie had. Webkit is nu wel behoorlijk groot, maar IE en FF hebben nog wel een veel groter marktaandeel dan Netscape destijds, en ik hoop en verwacht dat ze dat nog wel houden. En zolang IE en Firefox goede vervangers zijn voor webkit, zullen ze zich niet kunnen veroorloven om achter te blijven.
Het grootste probleem is dat er nu webkit-only wordt ontwikkeld, mede dankzij de -webkit-prefix. Maar dat is vooral een probleem voor developers: 45 tot 75% is nu IE en Firefox (bron: https://en.wikipedia.org/...eb_browsers#Summary_table). Webkit-only websites zijn leuk als proefballonnetjes en testprojectjes, maar geen enkele professionele webdeveloper zal de helft van zijn potentiele bereik uitsluiten.
Het grootste probleem is dat er nu webkit-only wordt ontwikkeld, mede dankzij de -webkit-prefix. Maar dat is vooral een probleem voor developers: 45 tot 75% is nu IE en Firefox (bron: https://en.wikipedia.org/...eb_browsers#Summary_table). Webkit-only websites zijn leuk als proefballonnetjes en testprojectjes, maar geen enkele professionele webdeveloper zal de helft van zijn potentiele bereik uitsluiten.
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.
Nokia gebruikt in S40 ook Webkit.
Je vergeet zomaar even de mobiele markt voor het gemak zeker?
Hangt van af, het kan zijn dat je mee kan doen als je aan bepaalde voorwaarden voldoet. Stel je doet helemaal niks aan bugfixes, dan kunnen ze op een gegeven moment ook besluiten om een feature van jou niet op te nemen, want je helpt ook niet mee met bugfixes.
Kijk maar naar Linux, daar werken ook verschillende grote bedrijven aan mee, maar er zijn afspraken waar je aan dient te houden om het project te beschermen.
Kijk maar naar Linux, daar werken ook verschillende grote bedrijven aan mee, maar er zijn afspraken waar je aan dient te houden om het project te beschermen.
Met als verschil dat er dan dus verschillende bedrijven/instanties zijn die zullen bijdragen aan de ontwikkeling van WebKit. :-) Als dat goed blijft gaan en ze krijgen geen ruzie waarop een fork volgt zal dat alleen maar bijdragen aan de ontwikkeling.
Het gaat nu al niet meer goed, als het even kan, volgt Webkit de standaard niet.
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
Onderandere, want gradients worden nog steeds niet ondersteund zoals het hoord. Ik denk ook aan touch, waar zij ook hun eigen systeem gebruiken terwijl de overgrote meerderheid voorstander is van Microsofts versie. En ga zo maar door...
Als je dat zo graag wil, dan verplicht je toch al je IE gebruikers om Chrome Frame te installeren? 
Mijn inziens net iets gebruiksvriendelijker dan helemaal geen upgrade mogelijkheid aan te bieden aan gebruikers van XP/IE.
Het gebruik van prefixes is juist goed om te zorgen dat de browsers allemaal een kans hebben om een standaard te maken, ipv de eerste die met een idee komt.
De standaardenorganisaties schieten niet op. Kijk maar hoelang HTML5 heeft bedoeld. Daarom innoveert Google Chrome bijvoorbeeld door. Als we zouden wachten totdat de standaard formeel klaar is hadden we nu nog amper functionaliteit.
het grappige is dat MS net hetzelfde deed met IE5 en IE6 (eigen dingen toevoegen) en toen was MS opeens pure evil...
standaarden gaan traag omdat er over nagedacht wordt
niemand (ik toch niet) zit te wachten op allerhande functies die overlappen, nutteloos zijn,... het maakt de engine ook nodeloos trager, logger en moeilijker om te onderhouden
standaarden gaan traag omdat er over nagedacht wordt
niemand (ik toch niet) zit te wachten op allerhande functies die overlappen, nutteloos zijn,... het maakt de engine ook nodeloos trager, logger en moeilijker om te onderhouden
MS deed het niet met prefixes, maar gebruikte de standaard-namen met een eigen implementatie. Doordat ze de grootste partij in de browsermarkt waren, werd daardoor de officiele standaard teniet gedaan. Dat is evil ja.
Browser prefixes zijn er JUIST voor gemaakt om experimentele features te implementeren. Als jij als developer er vanuit gaat dat deze prefixes altijd blijven werken, zit de fout bij jou, niet bij de browsermaker.
Browser prefixes zijn er JUIST voor gemaakt om experimentele features te implementeren. Als jij als developer er vanuit gaat dat deze prefixes altijd blijven werken, zit de fout bij jou, niet bij de browsermaker.
Ja precies, vooruitziend als ik ben gebruik ik nu alvast, naast de bestaande -o, -moz, -webkit, -ms, ook de -tba prefix (to be announced) [/sarcasm]
Aan de ene kant jammer die verschraling van engines, aan de andere kant, als ze toch bijna allemaal van de standaarden afwijken, schiet je er eigenlijk ook niets mee op met al die engines. Ikzelf vond Opera trouwens wel fijn om ertussen te hebben.
Ik heb net weer zo'n responsive html5 (video/touch) project achter de rug, en eerlijk gezegd werd ik er niet vrolijk van. De theorie klinkt leuk, maar de praktijk blijkt telkens weer geknoei, dirty gefix, om uiteindelijk iets meer dan alleen maar iets stricts neer te zetten, maar iets wat gewoonweg wérkt.
Aan de ene kant jammer die verschraling van engines, aan de andere kant, als ze toch bijna allemaal van de standaarden afwijken, schiet je er eigenlijk ook niets mee op met al die engines. Ikzelf vond Opera trouwens wel fijn om ertussen te hebben.
Ik heb net weer zo'n responsive html5 (video/touch) project achter de rug, en eerlijk gezegd werd ik er niet vrolijk van. De theorie klinkt leuk, maar de praktijk blijkt telkens weer geknoei, dirty gefix, om uiteindelijk iets meer dan alleen maar iets stricts neer te zetten, maar iets wat gewoonweg wérkt.
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.
Want backward compatibility is niet nodig? Als sites gebruik maken van "-webkit-"-varianten, zou het lullig zijn als dat na een tijdje opeens niet meer werkt. Dan moeten bedrijven weer kosten maken omdat het in nieuwe versies niet werkt.
Daarnaast weet ik niet of het wel "beta code" blijft, het zal me niets verbazen als het gewoon dezelfde achterliggende code gebruikt als de niet-"-webkit-"-variant.
Daarnaast weet ik niet of het wel "beta code" blijft, het zal me niets verbazen als het gewoon dezelfde achterliggende code gebruikt als de niet-"-webkit-"-variant.
Developers kunnen zich natuurlijk ook gewoon realiseren dat er een reden is dat die prefix gebruikt wordt; de standaard is nog niet af en niet bedoeld voor productiesites. Als je het wel doet moet je niet gaan huilen dat het na een jaar niet meer ondersteund wordt: dat was de afspraak.Want backward compatibility is niet nodig? Als sites gebruik maken van "-webkit-"-varianten, zou het lullig zijn als dat na een tijdje opeens niet meer werkt. Dan moeten bedrijven weer kosten maken omdat het in nieuwe versies niet werkt.
Daarnaast weet ik niet of het wel "beta code" blijft, het zal me niets verbazen als het gewoon dezelfde achterliggende code gebruikt als de niet-"-webkit-"-variant.
[Reactie gewijzigd door gerrymeistah op woensdag 13 februari 2013 13:45]
Klopt helemaal
Wij gebruiken deze features ook, maar beseffen heel goed dat het nog experimenteel is en dat het risico bestaat dat we het moeten aanpassen
Al voegen we wel altijd ook de variant zonder prefix toe
Wij gebruiken deze features ook, maar beseffen heel goed dat het nog experimenteel is en dat het risico bestaat dat we het moeten aanpassen
Al voegen we wel altijd ook de variant zonder prefix toe
Dat nu gebeurt dus ook.
Neem bijvoorbeeld de box-shadow property.
Als jij zowel -webkit-box-shadow als box-shadow declaraties hebt, dan negeert webkit tegenwoordig de eerste ten gunste van de non-prefix declaratie.
Neem bijvoorbeeld de box-shadow property.
Als jij zowel -webkit-box-shadow als box-shadow declaraties hebt, dan negeert webkit tegenwoordig de eerste ten gunste van de non-prefix declaratie.
Webkit is deze prefixes gaan gebruiken omdat ze niet wilden wachten totdat de standaard eindelijk eens definitief was.
Veel van de standaarden zijn aangedragen vanuit webkit, maar omdat daar 5 jaar over gediscussieerd moet worden hebben Apple en Google besloten om door te gaan met ontwikkelen en dit met een prefix te doen.
Het is niet helemaal terecht om de schuld bij WebKit te leggen.
Veel van de standaarden zijn aangedragen vanuit webkit, maar omdat daar 5 jaar over gediscussieerd moet worden hebben Apple en Google besloten om door te gaan met ontwikkelen en dit met een prefix te doen.
Het is niet helemaal terecht om de schuld bij WebKit te leggen.
"Hopelijk gaat IE ook nog eens over op webkit!"
Liefst niet. IE krijgt slechts 1x per jaar een nieuwe versie. Ik kan me nu al voorstellen dat je een jaar lang met een verouderde versie van de webkit zou moeten gaan werken. En dat is ook niet echt waar iedereen op zit te wachten.
Bovendien is concurrentie altijd gezond
Liefst niet. IE krijgt slechts 1x per jaar een nieuwe versie. Ik kan me nu al voorstellen dat je een jaar lang met een verouderde versie van de webkit zou moeten gaan werken. En dat is ook niet echt waar iedereen op zit te wachten.
Bovendien is concurrentie altijd gezond
[Reactie gewijzigd door sirnh1 op woensdag 13 februari 2013 12:37]
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]
Of optie 3: render-engines houden zich aan de geldende specificaties zodat developers makkelijk volgens die specificatie kunnen ontwikkelen, en er toch gezonde concurrentie blijft op de browsermarkt.
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
Inderdaad, verschillende renderengines zijn problematisch als er één standaard wordt nagestreefd. Daarom zou het beter zijn als er maar één renderengine zou zijn waar rekening mee wordt gehouden.
Als eindgebruiker wil ik de best mogelijke ervaring als ik aan het surfen ben.Kun je mij uitleggen waarom verschillende renderengines bijdragen aan gezonde concurrentie tussen browsers?
Idealiter wil ik eigenlijk alle websites binnen de milliseconde op mijn scherm zien staan en 5000 browservensters kunnen openen zonder dat mijn laptop / tablet / smartphone traag wordt.
Browserbouwers kunnen hier met elkaar concurreren door steeds betere renderengines op de markt te brengen. Mensen zullen heus niet verlopen elke keer een nieuwe browser 'de snelste' is. Maar als hun browser ter plaatse blijft trappelen terwijl anderen altijd maar 'sneller' worden, dan zullen ze toch wel overschakelen.
Een 'gezonde concurrentie' hebben we trouwens al gezien de laatste jaren tussen de verschillende JavaScript-engines (wikipedia)
Zullen Google en andere webcrawlers leuk vinden... Je genereert een *enorme* overhead aan verkeer, ook inclusief caching en weet ik wat. Een rendering engine is geen klein / triviaal stukje software. Bovendien loop je dan ook al tegen platform-specifieke beperkingen aan. Je moet dan je website geschikt maken voor Windows, Linux en Mac OS X in plaats van voor IE, Firefox en Chrome, of het daar nou echt beter van wordt...
Verder zal het wel een paar graden warmer worden in de diverse datacentra als elke webpagina vergezeld wordt van een rendering-engine...
Verder zal het wel een paar graden warmer worden in de diverse datacentra als elke webpagina vergezeld wordt van een rendering-engine...
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.
Maar dan is de voorwaarde dus dat een website met HTML5 markup moet worden gemaakt, je kan dat niet verwachten; zeker van oude pagina's niet, die ook goed weergegeven moeten worden.In principe zouden de render-engines pixel moeten werken als ze zich houden aan de specificaties van HTML5.
Inderdaad. Specifieke optimalisaties zijn nooit goed. Ze moeten gewoon zorgen dat ze voor HTML5 programmeren zodat alle websites er optimaal gebruik van maken. De Engines moeten gewoon zorgen dat ze dat goed kunnen doen.
Mwah... Opera was dan niet zo groot, maar minder renderers is niet noodzakelijk beter. Als Chromium erg groot wordt kunnen ze te makkelijk non-standaard elementen/attributen introduceren. En dan krijg je op termijn hetzelfde probleem dat we ook met IE hadden (websites die alleen in browser X werken).
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)
Om nog maar te zwijgen over geintegreerde implementaties zoals de Nintendo Wii en bepaalde TV's.
Oja, da's waar. M'n eigen tv draait Opera, net zoals elke niet-kpn glazvezel-settopbox (van Amino) in nederland.
Ik zie veel liever dat de rendering alleen maar afhangt van de W3C-standaarden dan van browsers ...
Ja ik wil dat er altijd en overal vrede is. Maarja onmogelijke dingen gaan gewoon niet gebeuren, kan je hopen/willen maar is gewoon niet realistisch...
Ik wil gewoon dat mijn sites overal goed werken, welke standaard daar ook voor nodig is
Ik wil gewoon dat mijn sites overal goed werken, welke standaard daar ook voor nodig is
[Reactie gewijzigd door watercoolertje op woensdag 13 februari 2013 10:59]
Zou prettig zijn.... maar zolang de W3C standaarden achter lopen bij de browser, is daar weinig hoop op...
Des te meer reden om het bij HTML5 nu gewoon meteen goed te doen. De standaard staat zo goed als vast, haal in ieder geval die -webkit- prefixes dan weg (of bied er ook ondersteuning voor), dan kan een ontwikkelaar echt vele malen beter ontwikkelen voor websites. Tuurlijk kun je voor elke browser een aparte prefix toevoegen, maar dat werkt niet overzichtelijk en zorgt alleen maar voor een grotere download. En dat wil je ook niet.
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.
Ik vraag me af of je dat echt wil. Er zijn heel veel dingen nog steeds geen officiële standaard, die iedereen al wel gebruikt. Als men zich beperkt tot wat al gestandaardiseerd is komen we nooit verder.
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.
Persoonlijk vind ik dit een hele goede actie.
Opera vind ik een van de betere browsers als het om de gebruiksvriendelijkheid en functies aan komt.
Helaas is het voor mij ook de browser waar ik de meeste fouten tegen kom op webpagina's inclusief mijn eigen website.
Speciaal voor opera heb ik in een frame een scrollbar toegevoegd omdat de autoresize er niet op werkt (Zelfs IE7 heeft hier geen moeite mee).
Als de nieuwe versie uit is zal ik zeker overwegen om over te stappen.
Opera vind ik een van de betere browsers als het om de gebruiksvriendelijkheid en functies aan komt.
Helaas is het voor mij ook de browser waar ik de meeste fouten tegen kom op webpagina's inclusief mijn eigen website.
Speciaal voor opera heb ik in een frame een scrollbar toegevoegd omdat de autoresize er niet op werkt (Zelfs IE7 heeft hier geen moeite mee).
Als de nieuwe versie uit is zal ik zeker overwegen om over te stappen.
Straks is het dus een van de betere skins op WebKit, want veel meer is het dan niet meer. Dus of dit een hele goede actie is weet ik niet.
Safari, Chrome, Opera v.s. Internet Explorer is het dan meer, want tussen de eerste drie zijn nagenoeg geen verschil op het uiterlijk na.
Safari, Chrome, Opera v.s. Internet Explorer is het dan meer, want tussen de eerste drie zijn nagenoeg geen verschil op het uiterlijk na.
oh jawel, verschillen genoeg. webkit is een html rendering engine, maar er zijn nog andere dingen die verwerkt moeten worden. Wat dacht je bijvoorbeeld van javascript? Een techniek die vandaag in moderne webapps toch ook niet onbelangrijk is. Daarnaast heb je ook nog altijd andere keuzes te maken. Welke codecs ga je bijvoorbeeld ondersteunen in de <video> tag? Heb je het geld om h.264 te implementeren of ga je het houden op webm?
Beetje jammer dat webkit zo nog een groter marktaandeel krijgt.
Op zich niks mis mee, maar we gaan nu wel weer naar het tijdperk toe dat sites ontworpen worden voor 1 specifieke engine/browser (denk aan IE vroeger) en dat is niet goed voor de standaarden.
Op zich niks mis mee, maar we gaan nu wel weer naar het tijdperk toe dat sites ontworpen worden voor 1 specifieke engine/browser (denk aan IE vroeger) en dat is niet goed voor de standaarden.
Zolang Webkit de standaarden blijft volgen, is er geen probleem. Het wordt pas een probleem als Webkit plots een eigen leven gaat leiden en van de standaard gaat afwijken. Dan worden de rollen omgekeerd en wordt Webkit wat IE vroeger was.
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.
Ik merk nu al dat Google hun services specifiek voor webkit aan lijkt te passen. De laatste tijd draait Google Maps echt voor geen meter meer op Firefox. Slome laadtijden, haperend inzoomen. Op een chromium browser gaat het dan ineens 3x zo snel.
De wereld op z'n kop.
Google investeert heeft veel tijd en moeite in de optimalisatie van hun Javascript engine voor dit soort complexe applicaties. (De performance van Google earth hangt af van Javascript, niet zozeer Webkit/HTNL).
Je ziet dat andere browsers daar nog in achter lopen, hoewel het verschil minder is dan het was.
Google investeert heeft veel tijd en moeite in de optimalisatie van hun Javascript engine voor dit soort complexe applicaties. (De performance van Google earth hangt af van Javascript, niet zozeer Webkit/HTNL).
Je ziet dat andere browsers daar nog in achter lopen, hoewel het verschil minder is dan het was.
Leek me heel vreemd en dus heb ik het maar even getest. Firefox 18.0.2 en alles werkt reuze soepel.Ik merk nu al dat Google hun services specifiek voor webkit aan lijkt te passen. De laatste tijd draait Google Maps echt voor geen meter meer op Firefox.
De oplossing is simpel:
Je doet EERST je browser specifieke CSS3 (-webkit, -moz e.d) en dan de "prefixloze" CSS3 property zodat dze als laatste word uitgeveord en de browser zich aan de standaard houd.
Je doet EERST je browser specifieke CSS3 (-webkit, -moz e.d) en dan de "prefixloze" CSS3 property zodat dze als laatste word uitgeveord en de browser zich aan de standaard houd.
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.
En dat is nu al het geval. De webkit implementatie voor touch interactie is volledig webkit specifiek. Er zitten zelfs patenten op, waardoor andere browsers het niet kunnen implementeren zonder aan Apple te betalen. Dus ook die ontwikkeling is echt niet goed.
Dat van touch is inderdaad even uitzoeken, maar daar is prima omheen te werken. Gewoon de webkit prefix gebruiken, maar het probleem zit hem meer in de andere tags die bv op animaties of het box-model van toepassing zijn.
Nu IE10 weer wat meer ondersteund is het jammer om te zien dat sommige websites niet werken omdat ze er geen generieke tag onder gehangen hebben (dus -webkit-border-radius blijven gebruiken en er desnoods niet border-radius naast zetten, idem voor achtergronden).
Nu IE10 weer wat meer ondersteund is het jammer om te zien dat sommige websites niet werken omdat ze er geen generieke tag onder gehangen hebben (dus -webkit-border-radius blijven gebruiken en er desnoods niet border-radius naast zetten, idem voor achtergronden).
En -o-, en -ie-, en -firefox- dan? Die tellen niet mee?
-webkit- wordt ook vervangen, alleen halen ze wellicht niet de -prefixversie direct weg. Eenmaal een standaard krijgt webkit ook gewoon de standaard versie.
Zolang Internet explorer/trident nog meer marktaandeel heeft dan gecko/webkit, zal dit probleem waarschijnlijk niet voorkomen, aangezien programmeurs hun site, zeker weten, ook geoptimaliseerd willen hebben voor de meest gebruikte browser.
Wikimedia , veel SVG, rendert niet in explorer. Dus Safari, Chrome, Firefox... Opera
Voor mobiele websites (waar mogelijk een hoop optimalisaties bij komen kijken) is IE/trident vrijwel niet bestaand.
Als ik statcounter mag geloven is IE ook al geen marktleider meer, met een neergaande trend. De demografie die ze nog hebben bestaan vervolgens voor een aanzienlijk deel uit gebruikers van verouderde browsers.
Begrijp me niet verkeerd, ik vind dat een web-developer zoveel mogelijk platformen moet ondersteunen (we moeten niet naar een IE6 tijd). Aan de andere kant kan ik me voorstellen dat IE relevantie verliest bij mobiele sites of web-applicaties die profiteren van moderne browsers.
Bovendien blijft Microsoft de eigen glazen ingooien door zo weinig platformen te ondersteunen. Hun eigen OS Windows XP werd vanaf IE9 al niet meer ondersteund, terwijl dat zelf nu nog 38% marktaandeel heeft. Geen ondersteuning voor Linux, android, OSX, ios...
Ik ontwikkel op een OSX apparaat en om voor IE te testen moet je rommelen met Wine, VirtualBox weet ik het. Als ik de keuze had gehad zou ik een Linux apparaat gebruiken, maar dan heb je hetzelfde gezeur. Developers, developers, developers.
edit:verspreking
Als ik statcounter mag geloven is IE ook al geen marktleider meer, met een neergaande trend. De demografie die ze nog hebben bestaan vervolgens voor een aanzienlijk deel uit gebruikers van verouderde browsers.
Begrijp me niet verkeerd, ik vind dat een web-developer zoveel mogelijk platformen moet ondersteunen (we moeten niet naar een IE6 tijd). Aan de andere kant kan ik me voorstellen dat IE relevantie verliest bij mobiele sites of web-applicaties die profiteren van moderne browsers.
Bovendien blijft Microsoft de eigen glazen ingooien door zo weinig platformen te ondersteunen. Hun eigen OS Windows XP werd vanaf IE9 al niet meer ondersteund, terwijl dat zelf nu nog 38% marktaandeel heeft. Geen ondersteuning voor Linux, android, OSX, ios...
Ik ontwikkel op een OSX apparaat en om voor IE te testen moet je rommelen met Wine, VirtualBox weet ik het. Als ik de keuze had gehad zou ik een Linux apparaat gebruiken, maar dan heb je hetzelfde gezeur. Developers, developers, developers.
edit:verspreking
[Reactie gewijzigd door snirpsnirp op woensdag 13 februari 2013 12:21]
Ook dat is al te laat. Het is nog niet zo zeer slecht voor desktops, maar voor mobiele browsers als Firefox en IE wordt dit een zeer groot probleem vanwege de laksheid van veel ontwikkelaars.
Of juist wel goed voor de ontwikkeling omdat je al je programmeertijd kunt steken in één engine in plaats van te moeten spreiden en telkens weer testen in 3 of meer engines.
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.
Voor Opera werdt toch al praktisch nooit geoptimaliseerd en Webkit wint met Opera-gebruikers gemiddeld waarschijnlijk minder dan een procent op de browsermarkt, dus het loopt wel los denk ik.
[Reactie gewijzigd door Aham brahmasmi op woensdag 13 februari 2013 11:06]
Jammer ik vindt Opera erg prettig en het feit dat het behoorlijk compacte browser is zonder bloatware.
Onder linux zowel als windows gaat het nog steeds als een trein.
Dat het percentage laag ligt betekend niet veel.....
Onder linux zowel als windows gaat het nog steeds als een trein.
Dat het percentage laag ligt betekend niet veel.....
Volgens mij veranderd er verder niks aan de features van de browser, dus waarom zou je dit jammer vinden? Het blijft gewoon de browser die je gewent bent, maar dan met een andere render engine.
Er ligt ook een stukje veiligheid wat er aan te pas komt. Van Opera weet ik zeker dat hun code erg klein is dit laat weinig ruimte over voor backdoors enzovoort. Als dit wordt overgeheveld op een webkit zit je eigenlijk weer in een grotere vijver en wordt het makkelijker voor mensen die kwaad willen.
Sterker nog, Opera wil zelf bijdragen aan Webkit. Een deel van de mensen die de vijver bewaken blijft dus hetzelfde!
Ik las in een andere reactie hier dat een aantal developers zeggen dat het eerste wat ze gaan doen de css-ondersteuning van Webkit op Presto-niveau brengen.
Ik las in een andere reactie hier dat een aantal developers zeggen dat het eerste wat ze gaan doen de css-ondersteuning van Webkit op Presto-niveau brengen.
Ik gebruik Opera op windows en op Android, o.a. vanwege de snelheid en vloeiendheid van de renderengine.
Maar in OSX is Opera vergeleken met Webkit (Chrome) onwijs traag.
Maar in OSX is Opera vergeleken met Webkit (Chrome) onwijs traag.
Ik vind het een begrijpelijke keuze van Opera, maar jammer op de lange termijn.
Gaan wesites zich conformeren aan standaarden of aan Webkit als dit defacto standaard is?
Concurrentie is positief voor innovatie.
Gaan wesites zich conformeren aan standaarden of aan Webkit als dit defacto standaard is?
Concurrentie is positief voor innovatie.
Nu kan je wegkomen met zeer slecht geprogrammeerde websites zoals http://www.ziggo.nl dan heb je met een web-engine het probleem niet meer.
Aan de ene kant jammer, voelt het net wat minder "Speciaal" door. Maar aan de andere kant, ik gebruik Opera omdat ik het een fijne browser vind en omdat het gewoon goeie features heeft en daarin meestal stilletje voorop loopt. Als ze daar nu nog meer op kunnen focussen dan lijkt mij dat alleen maar beter.
Ben ik het niet mee eens. Nu ze op webkit overstappen hebben ze meer tijd om nieuwe features te maken. Dit zou ze juist kunnen helpen om een groter marktaandeel te kunnen veroveren. Maar dat zullen we dan wel zien.
Hoewel ik Opera nooit gebruikt heb, is het op zich wel fijn dat je hiermee geen Opera-specifieke trucjes meer hoeft toe te passen om je pagina's cross-browser werkend te krijgen. En dat scheelt altijd tijd die je liever in andere dingen steekt.
Het lijkt me voor een browser-maker dan ook wel fijner om je over het renderen van pagina's in elk geval niet druk te maken en je inderdaad alleen maar te hoeven richten op de features die jouw browser uniek maken.
Het enige nadeel dat ik me nu kan bedenken, is dat er straks minder keuze is qua render-engines. Keuzes hebben is altijd wel enigszins fijn.
Het lijkt me voor een browser-maker dan ook wel fijner om je over het renderen van pagina's in elk geval niet druk te maken en je inderdaad alleen maar te hoeven richten op de features die jouw browser uniek maken.
Het enige nadeel dat ik me nu kan bedenken, is dat er straks minder keuze is qua render-engines. Keuzes hebben is altijd wel enigszins fijn.
Naar mijn weten zijn er nooit Opera-specifieke trucjes geweest. Als je de standaarden volgde deed de website het altijd prima in Opera.
Die zijn er wel hoor, maar vaak zijn dat dingen die je niet direct nodig hebt op een normale website. Maar ze hebben eens wat gedaan met camera support, wat andere browsers niet deden bijvoorbeeld.Naar mijn weten zijn er nooit Opera-specifieke trucjes geweest. Als je de standaarden volgde deed de website het altijd prima in Opera.
Jawel hoor, er zijn diverse -o- CSS extensies
Wat volgens mij alleen precies dezelfde extensies zijn waarvoor je ook een -moz-, -webkit- of -ms- prefix voor nodig hebt.
Nee, er zijn er die enkel in Opera met een o-prefix werken. Zaken die nog niet in de andere browsers werken. Maar het gaat inderdaad om weinig gebruikte zaken.
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."
Het is alweer even geleden, maar toen webkit zaken als border radius, box shadow en background gradients ging ondersteunen, zag het er in Opera anders heel anders uit.
Welke Opera-specifieke trucjes heb jij het dan over? Voor zover ik weet werken alle pagina's die ik heb gemaakt gewoon in Opera zolang je je maar aan de standaard houd. Opera heeft zich als een van de weinige browsers hier stug aan vast gehouden.
Het ging me hier alleen om CSS. Ik meen in het verleden (bij mijn oude werkgever) een aantal Opera specifieke CSS rules te hebben gezien, ook in externe libraries die we indertijd gebruikten. Het is overigens niet zo dat ik zelf dergelijke trucjes heb hoeven toepassen. Google heeft in elk geval wel wat hits op Opera-specifieke CSS hacks.
Maar inderdaad, met het volgen van de standaarden kom je een heel eind. Het enige probleem zat/zit hem in de implementatie van die standaarden in de browsers.
Maar inderdaad, met het volgen van de standaarden kom je een heel eind. Het enige probleem zat/zit hem in de implementatie van die standaarden in de browsers.
Afwachten of ik hier nu zo blij mee ben.
Ik vond Opera juist zo fijn omdat hij lekker snel is en eigenlijk een van de meest stabiele browsers is waar ik mee gewerkt heb. Ik hoop niet dat het veranderen van de renderengine hier verandering inbrengt. Webkit is prima, maar in mijn ogen haalt geen enkele webkitbrowser het bij Opera. Hopelijk zorgt deze verandering er niet voor dat Opera meer richting de andere webkitbrowsers gaat.
Ik vond Opera juist zo fijn omdat hij lekker snel is en eigenlijk een van de meest stabiele browsers is waar ik mee gewerkt heb. Ik hoop niet dat het veranderen van de renderengine hier verandering inbrengt. Webkit is prima, maar in mijn ogen haalt geen enkele webkitbrowser het bij Opera. Hopelijk zorgt deze verandering er niet voor dat Opera meer richting de andere webkitbrowsers gaat.
Ik sluit me volledig bij je aan! Ik gebruik Opera al sinds versie 4, juist omdat het zo'n lekker kleine en vooral snelle browser was. Het was indertijd de enige die nog een beetje vooruit te branden was onder Linux op mijn overgeclockte Pentium 1 
Maar ook nu vind ik hem nog steeds een stuk vlotter lopen dan elke keer als ik even achter bijvoorbeeld Firefox zit. En deze performance zal toch het meest gebaseerd zijn op de renderengine, dus wat dat betreft ben ik wel huiverig voor de overstap naar Webkit.
Aan de andere kant, zoals veel mensen hierboven ook al zeggen, maar wat Opera zelf ook al aangeeft; de overstap naar Webkit scheelt een boel development effort, en het is juist misschien daardoor beter dat er meer browsers op een lijn zitten. Wat ik me afvraag is hoe Opera dan nog wel zijn eigen toegevoegde waarde gaat behouden boven de andere browsers. Of zou het misschien zo zijn dat het eigenlijk niet zo goed gaat met Opera (als bedrijf)? En dat het stoppen van de ontwikkeling van Presto en overstap naar Webkit in feite een bezuinigingsmaatregel is?
Maar ook nu vind ik hem nog steeds een stuk vlotter lopen dan elke keer als ik even achter bijvoorbeeld Firefox zit. En deze performance zal toch het meest gebaseerd zijn op de renderengine, dus wat dat betreft ben ik wel huiverig voor de overstap naar Webkit.Aan de andere kant, zoals veel mensen hierboven ook al zeggen, maar wat Opera zelf ook al aangeeft; de overstap naar Webkit scheelt een boel development effort, en het is juist misschien daardoor beter dat er meer browsers op een lijn zitten. Wat ik me afvraag is hoe Opera dan nog wel zijn eigen toegevoegde waarde gaat behouden boven de andere browsers. Of zou het misschien zo zijn dat het eigenlijk niet zo goed gaat met Opera (als bedrijf)? En dat het stoppen van de ontwikkeling van Presto en overstap naar Webkit in feite een bezuinigingsmaatregel is?
Je vergeet wel even Chrome te noemen die ook op Webkit draait en de vloer aanveegt met Opera. Firefox draait trouwens op Gecko.
Ik snap wel dat je een Opera-fan bent, maar het heeft weinig met de engine te maken.
Ik snap wel dat je een Opera-fan bent, maar het heeft weinig met de engine te maken.
Chrome voelt hier anders een stuk trager aan dan Opera. Op m'n (snelle) desktop merk ik dat niet erg, maar op m'n notebook (dat een simpele AMD E2-1800 is) scheelt het toch best veel. Opera lijkt alles wat soepeler te doen. Of hij echt sneller is zou ik moeten meten, maar de ervaring is in elk geval zo dat Opera vlotter aanvoelt.Je vergeet wel even Chrome te noemen die ook op Webkit draait en de vloer aanveegt met Opera. Firefox draait trouwens op Gecko.
Ik snap wel dat je een Opera-fan bent, maar het heeft weinig met de engine te maken.
Op dit item kan niet meer gereageerd worden.
Populair: Tablets Samsung Websites en communities Mobiele telefoons Google Sony Microsoft Games 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
