W3C waarschuwt voor dominantie WebKit
De toegenomen populariteit van de WebKit-render-engine op mobiele browsers brengt gevaren met zich mee. Dat stelt de CSS Working Group van de W3C. Steeds meer mobiele websites werken enkel in browsers met de WebKit-Engine.
De waarschuwing staat in een oproep van mede-voorzitter Daniel Glazman van de CSS Working Group. Hij waarschuwt voor het gevaar van de marktdominantie van WebKit: er dreigt eenzelfde situatie te ontstaan als voorheen met Internet Explorer op de desktopbrowsermarkt.
Toen Internet Explorer 6 nog de populairste webbrowser was, wemelde het van de websites die alleen in die browser werkten, schrijft Glazman. Dat kwam doordat Internet Explorer de html- en css-standaarden vaker negeerde dan volgde. Dat is nu voorbij, maar: "Internet Explorer 6 is weg, maar het probleem is terug", schrijft Glazman.
Volgens de css-voorman zijn er namelijk steeds meer mobiele websites die alleen in een browser met WebKit werken. Dat komt doordat zowel de standaard-Android als -iOS-browser WebKit als render-engine gebruiken. Gebruikers van een andere browser, zoals een mobiele Firefox-versie of Internet Explorer op Windows Phone, stuiten volgens Glazman steeds vaker op meldingen dat een website 'niet geschikt' voor hun browser is.
WebKit, dat door Apple is ontwikkeld en onder een opensource-licentie beschikbaar is gesteld, biedt websitebouwers een aantal specifieke css-instellingen die op mobiele websites van pas komen, zoals gradients, afgeronde hoeken en animaties. Door dat via css te doen in plaats van via respectievelijk afbeeldingen of javascript, wordt bandbreedte bespaard. De speciale WebKit-css-opties kunnen worden gebruikt met de '-webkit-*'-prefix.
Firefox, Internet Explorer en Opera bieden vergelijkbare, browserspecifieke css-opties, maar die worden volgens Glazman op mobiele sites zelden gebruikt: het overgrote deel van de gebruikers heeft WebKit, dus negeren webbouwers andere browsers. Dat is in strijd met het open web, vindt hij.
Alle webbrowsermakers hebben de W3C laten weten de WebKit-css-opties over te nemen. "Laat ik het duidelijk zeggen: dit is geen hypothetisch geval en ik beschrijf hier niet iets wat kan gebeuren. Alle browsermakers hebben ons laten weten dat het zal gebeuren, en liever vroeg dan later." De browsermakers zeggen 'geen andere keuze' te hebben.
Als alle browsermakers de css-opties van WebKit overnemen, is er voor webbouwers ook geen reden meer om de officiële css-richtlijn te volgen. "Dit brengt de doodslag toe aan ons standaardisatieproces", waarschuwt Glazman. Hij roept webbouwers op om ook rekening te houden met gebruikers van andere browsers. Het ondersteunen van andere browsers kost volgens hem relatief weinig werk.
Beter nog is volgens Glazman om alle browserspecifieke css-opties in de css-standaard te verwerken. "Wij, en daarmee vertegenwoordigen we de web-industrie, kunnen de architectuur van het web niet onveilig en onbetrouwbaar laten worden", betoogt hij. Dat dreigt wel te gebeuren als de ontwikkeling van het web afhangt van één render-engine.
Een meerderheid van de CSS Working Group deelt de bezorgdheid van Glazman. Onder meer de browsermakers zitten in de CSS Working Group, evenals Adobe, HP en een vertegenwoordiger van het W3C zelf. Het is echter onduidelijk welke partijen de bezorgdheid delen.
Reacties (137)
Zorg er dan voor dat alle browsers dezelfde CSS functies hebben!
Is het echt nodig om:
mozilla gradient
webkit gradient
opera gradient
IE gradient
als verschillende functies te hebben?
Hoe moeilijk kan het zijn om dat gewoon te vervangen door 'gradient'?
Is het echt nodig om:
mozilla gradient
webkit gradient
opera gradient
IE gradient
als verschillende functies te hebben?
Hoe moeilijk kan het zijn om dat gewoon te vervangen door 'gradient'?
Omdat gradient officieel niet bestaat/bestond in de huidige css standaarden. browser makers zagen dat hier wel behoefte aan was en begonnen het alvast naar eigen inzicht in te bakken in hun browsers. Met andere woorden, het heet wel gradient maar de werking kan per browser wel degelijk verschillen.
Dus kan je eigenlijk concluderen dat het standaardisatie proces te lang duurt, en de schuld bij W3C ligt. De browsers lopen ver voorop de standaarden. Dat hoort, lijkt me, andersom te zijn.
Het lijkt me eigenlijk beter om eerst een goede standaard te maken dan om te haasten. Aan het begin van het gradienttijdperk had elke browser een eigen implementatie. Uiteindelijk heeft de W3C gekozen om Mozilla's implementatie te kiezen en dit wordt nu langzaam verwerkt in de standaarden.
Je kan niet zeggen "Ik wil gradients" en dan gewoon snel eventjes een standaard daarop bakken. Stel dat je iets vergeten bent waardoor de hele standaard weer opnieuw moet? Stel dat de andere implementatie 10x makkelijker is waardoor websitebouwers in de problemen komen?
Ik sluit me overigens volledig bij het W3C aan met deze uitspraak. Ik ben zelf een Firefoxgebruiker en zie heel vaak meldingen dat ik beter Chrome kan gebruiken om sites te bezoeken. Dit geldt niet alleen voor mobiel, maar ook desktop. Mij herinnert dat aan hoe IE de markt domineerde enkele jaren geleden. Helaas is iedereen dat echter alweer vergeten waardoor we nu op een Chrome-dominatie af gaan.
Laten we namelijk niet vergeten dat Chrome, net als IE in het verleden, met allerlei nieuwe ideeën komt die alleen in hùn implementatie werken. Hiermee trekken ze steeds meer mensen naar hun platform, en zodra ze 90% van de markt hebben kunnen ze zonder enig probleem zeggen dat ze stoppen met luisteren naar het W3C.
Je kan niet zeggen "Ik wil gradients" en dan gewoon snel eventjes een standaard daarop bakken. Stel dat je iets vergeten bent waardoor de hele standaard weer opnieuw moet? Stel dat de andere implementatie 10x makkelijker is waardoor websitebouwers in de problemen komen?
Ik sluit me overigens volledig bij het W3C aan met deze uitspraak. Ik ben zelf een Firefoxgebruiker en zie heel vaak meldingen dat ik beter Chrome kan gebruiken om sites te bezoeken. Dit geldt niet alleen voor mobiel, maar ook desktop. Mij herinnert dat aan hoe IE de markt domineerde enkele jaren geleden. Helaas is iedereen dat echter alweer vergeten waardoor we nu op een Chrome-dominatie af gaan.
Laten we namelijk niet vergeten dat Chrome, net als IE in het verleden, met allerlei nieuwe ideeën komt die alleen in hùn implementatie werken. Hiermee trekken ze steeds meer mensen naar hun platform, en zodra ze 90% van de markt hebben kunnen ze zonder enig probleem zeggen dat ze stoppen met luisteren naar het W3C.
[Reactie gewijzigd door TvdW op donderdag 9 februari 2012 12:33]
Die gradient functie bestaat al sinds 2009 meen ik., we zitten nu in 1012. Hoe lang moet een organisatie er over doen om er een standaard van te maken als de organisatie wil dat wij, de web devvers, daar gebruik van kunnen maken?Uiteindelijk heeft de W3C gekozen om Mozilla's implementatie te kiezen en dit wordt nu langzaam verwerkt in de standaarden.
Ook de W3C implementatie van programmeurs die de webbrowser engines maken kloppen niet altijd. Ik vind dat het W3C eerst daar maar eens de nadruk op moet gaan leggen. Een goeie standaard voor het web is leuk, maar een goeie standaard voor de webbrowser engines is net zo belangrijk!
Je reactie is begrijpelijk maar is eigenlijk ook fout. Het is namelijk niet haasten wat ze doen. Hoelang is de gemiddelde doorlooptijd voor een standaard?
CSS3 de werkgroep begon in 2007, 2 December 2010 working draft.. 12 Mei 2011 final draft. M.a.w. het duurde meer dan 4 jaar voordat de standaard compleet is.
Nu weet ik niet hoe anderen hier over denken maar in de ICT is dit een eeuwigheid. dit is nog van voor de eerste Android ooit het levenslicht zag. De iPhone 2G werdt geintroduceerd.
M.a.w., het W3C werkt gewoon te traag. En daar zitten browsermakers niet op te wachten.. zoals het nu altijd gaat is de browsermakers verzinnen functionaliteit en na een aantal jaar is het in een standaard verwerkt.
Opzich doet het W3C goed werk, maar gewoon te traag. Als alle browsers voldeden aan de W3C standaarden dan hadden we al die mooie functionaliteit niet die er nu is.
Relevante links:
2007: http://www.w3.org/TR/css-beijing/
2011: http://www.w3.org/TR/CSS/
CSS3 de werkgroep begon in 2007, 2 December 2010 working draft.. 12 Mei 2011 final draft. M.a.w. het duurde meer dan 4 jaar voordat de standaard compleet is.
Nu weet ik niet hoe anderen hier over denken maar in de ICT is dit een eeuwigheid. dit is nog van voor de eerste Android ooit het levenslicht zag. De iPhone 2G werdt geintroduceerd.
M.a.w., het W3C werkt gewoon te traag. En daar zitten browsermakers niet op te wachten.. zoals het nu altijd gaat is de browsermakers verzinnen functionaliteit en na een aantal jaar is het in een standaard verwerkt.
Opzich doet het W3C goed werk, maar gewoon te traag. Als alle browsers voldeden aan de W3C standaarden dan hadden we al die mooie functionaliteit niet die er nu is.
Relevante links:
2007: http://www.w3.org/TR/css-beijing/
2011: http://www.w3.org/TR/CSS/
[Reactie gewijzigd door ronaldmathies op donderdag 9 februari 2012 12:58]
Nee. WebKit ondersteunt de "standaard syntax" pas vanaf versie 534.16 - ik heb geen precieze data maar dat is ongeveer een jaar geleden. In mei werd de standaard al uitgegeven? Ik tel slechts 3 à 4 maanden vanaf het punt waarop de makers het eens werden. Dat vind ik toch vrij netjes. Alle voorgaande jaren waren ze aan het ruziemaken over welke optie nou de standaard zou worden.
Volgens mij was het zo dat Webkit 'voor die tijd' alleen de -webkit- variant ondersteunde, maar vlak na de final draft in 2011 ook de 'standaard variant' zonder -webkit- ervoor. Ze hadden dus de functionaliteit allang klaar maar hebben gewacht op de officiele standaard voordat ze de functionaliteit onder/conform de standaard-tags aanboden.
Hoe lang moet je erover doen om een standaard te ontwikkelen? 'We' zijn al jaren aan het rommelen met een HTML5 standaard die maar geen final status bereikt, CSS3 is nog niet officieel rond, etc. Als je met de officiele standaarden werkt, zit je met een site die toch behoorlijk wat features zal moeten ontberen of moet je allerlei rare work-arounds toepassen.
Het W3C is gewoon te traag met het doorvoeren van standaarden, dus dan gaan browserbouwers zelf maar aan de slag. Gesteggel over codecs voor audio/video, gelulhannes over de implementatie van drag/drop-technieken: get the f*** over it en kom eens ergens binnen afzienbare tijd uit. En zo niet, dan haalt de markt je dus wel in ja. Want die markt vraagt er gewoon om. Je kan niet verwachten dat 'het web' wel even 10 jaar wacht op een nieuwe standaard. Letterlijk 10 jaar.
Dus W3C: steek je hand in eigen boezem en ga agile standaarden ontwikkelen ofzo.
Verder doen ze overigens puik werk hoor.
Het W3C is gewoon te traag met het doorvoeren van standaarden, dus dan gaan browserbouwers zelf maar aan de slag. Gesteggel over codecs voor audio/video, gelulhannes over de implementatie van drag/drop-technieken: get the f*** over it en kom eens ergens binnen afzienbare tijd uit. En zo niet, dan haalt de markt je dus wel in ja. Want die markt vraagt er gewoon om. Je kan niet verwachten dat 'het web' wel even 10 jaar wacht op een nieuwe standaard. Letterlijk 10 jaar.
Dus W3C: steek je hand in eigen boezem en ga agile standaarden ontwikkelen ofzo.
Verder doen ze overigens puik werk hoor.
Dus hiermee zijn alle beslissingen van Microsoft betreffende CSS en HTML destijds recht gepraat. Het W3C had beter zijn werk moeten doen?
Niet automatisch goedgepraat maar het is wel zo dat Microsoft (en Netscape) beiden geen andere keuze hadden dan zelf nieuwe technieken te bedenken en maar te hopen dat de W3C het later op dezelfde manier zou aanpakken. Het probleem van Microsoft is niet dat IE6 zaken niet ondersteunde. Het probleem is dat IE6 jarenlang niet is geüpdatet en men dus ook nooit de standaarden die daarna opkwamen heeft geïmplementeerd. Als Microsoft IE6 door ontwikkeld had en zeg 2 jaar later IE7 had uitgebracht had het probleem nooit zo groot kunnen worden.
Ga voor de grap maar eens met Netscape Navigator 4 (de concurrent van IE6) moderne websites bezoeken. Ook dat werkt gewoon niet.
Ga voor de grap maar eens met Netscape Navigator 4 (de concurrent van IE6) moderne websites bezoeken. Ook dat werkt gewoon niet.
Netscape 4 was destijds de concurrent van IE4. Toen IE6 uitkwam in 2002 was Netscape 4 allang dood en begraven, die strijd woedde in 1998/1999.
voor alle W3C-"haters": je beseft dat de leden van de working groups meestal werkzaam zijn voor de verschillende browser makers?
Het proces is hier niet het probleem: de innovatie ligt bij browsermakers, zij krijgen vanuit de markt (front-end developers) vragen waarom feature X (bijv. gradients) niet via CSS geregeld kunnen worden. Ze gaan een beetje experimenteren en bieden dit aan met een prefix. Ander browser makers doen of tegelijkertijd hetzelfde, of zien dezelfde feature requests en gaan daarmee ook aan de slag. Uiteindelijk geeft de markt aan welke variant ze het fijnste vinden werken en de "verliezende" browsers nemen die variant over.
Ondertussen gaat het W3C aan de slag met het schrijven van de standaard. Dat gaat verder dan even noteren dat een gradient van kleur X naar kleur Y moet verlopen, maar ook hoe dat dan verder geïmplementeerd moet worden.
Volgens mij werkt het proces vergelijkbaar met andere normeringsinstituten, zoals het NEN of ISO. Het bedrijfsleven ontwikkelt de standaard, het instituut legt de standaard vas.
Het probleem ligt juist bij de ontwikkelaars, die kort door de bocht willen omdat ze een site "voor de iPad" of "voor de iPhone" maken en niet voor het web. Er zijn meerdere oplossingen (bijv. het prefix-free script of via CSS preprocessors, zoals SASS/LESS) waarmee je je code kunt schrijven zonder rekening te houden met al die vendor-prefixes.
Het proces is hier niet het probleem: de innovatie ligt bij browsermakers, zij krijgen vanuit de markt (front-end developers) vragen waarom feature X (bijv. gradients) niet via CSS geregeld kunnen worden. Ze gaan een beetje experimenteren en bieden dit aan met een prefix. Ander browser makers doen of tegelijkertijd hetzelfde, of zien dezelfde feature requests en gaan daarmee ook aan de slag. Uiteindelijk geeft de markt aan welke variant ze het fijnste vinden werken en de "verliezende" browsers nemen die variant over.
Ondertussen gaat het W3C aan de slag met het schrijven van de standaard. Dat gaat verder dan even noteren dat een gradient van kleur X naar kleur Y moet verlopen, maar ook hoe dat dan verder geïmplementeerd moet worden.
Volgens mij werkt het proces vergelijkbaar met andere normeringsinstituten, zoals het NEN of ISO. Het bedrijfsleven ontwikkelt de standaard, het instituut legt de standaard vas.
Het probleem ligt juist bij de ontwikkelaars, die kort door de bocht willen omdat ze een site "voor de iPad" of "voor de iPhone" maken en niet voor het web. Er zijn meerdere oplossingen (bijv. het prefix-free script of via CSS preprocessors, zoals SASS/LESS) waarmee je je code kunt schrijven zonder rekening te houden met al die vendor-prefixes.
Dat maakt het falen van W3C alleen maar grotervoor alle W3C-"haters": je beseft dat de leden van de working groups meestal werkzaam zijn voor de verschillende browser makers?
Zelfs met rechtstreekse verbindingen naar de diverse browsermakers blijft W3C jaren achter de feiten aanhobbelen.
Het probleem ligt volgens mij niet volledig bij de ontwikkelaars. Het cross-browser compatible maken van een CSS intensieve website kan heel moeilijk en kostelijk zijn, zeker omdat er nu enorm veel apparaten zijn waarmee je een website kan bezoeken. Daardoor zullen ontwikkelaars vaak enkele bochten moeten afsnijden om binnen het budget te blijven.
Daardoor komt de verantwoordelijkheid echter terug bij het W3C te liggen denk ik. Door zo lang bezig te zijn aan een standaard forceer je immers browserontwikkelaars om de "gradient" regel te ontwijken totdat de standaard af is en een soort van namespace in te bouwen (webkit-gradient bv.). Hierdoor is de ontwikkelaar genoodzaakt om kortere bochten te nemen zoals hierboven vermeld omdat er anders per gebruikte CSS feature een regel voor elk type browser voorzien moet worden.
Ik ben echter van mening dat implementatie details zoveel mogelijk uit de standaard moeten blijven. Deze details hangen te veel af van de gebruikte hardware en onderliggende software waardoor de standaard veel te ingewikkeld zal worden en dus lang op zich zal laten wachten.
Daardoor komt de verantwoordelijkheid echter terug bij het W3C te liggen denk ik. Door zo lang bezig te zijn aan een standaard forceer je immers browserontwikkelaars om de "gradient" regel te ontwijken totdat de standaard af is en een soort van namespace in te bouwen (webkit-gradient bv.). Hierdoor is de ontwikkelaar genoodzaakt om kortere bochten te nemen zoals hierboven vermeld omdat er anders per gebruikte CSS feature een regel voor elk type browser voorzien moet worden.
Ik ben echter van mening dat implementatie details zoveel mogelijk uit de standaard moeten blijven. Deze details hangen te veel af van de gebruikte hardware en onderliggende software waardoor de standaard veel te ingewikkeld zal worden en dus lang op zich zal laten wachten.
Ik denk dat er een groot verschil is tussen het IE6 verhaal en Webkit. Zoals in het artikel vermeldt, negeerde IE6 de standaarde vaker dan dat het zich eraan hield. Webkit echter houdt zich zeer goed aan de standaarden, maar er zijn gewoon een aantal functies waar vraag naar is. Webkit, en firefox etc, implementeren hier hun eigen functies voor. En in principe vindt ik dat niet zo heel raar. Want zeg nou zelf, css is bedoeld voor styling, zodra je javascript nodig hebt om gradients, of ronde hoekjes te maken, dan mist er gewoon iets.
Dat gezegd hebbend, zouden de browsermakers eigenlijk een soort onderling contact moeten hebben, en deze features op elkaar moeten afstemmen, zolang er nog geen w3c standaard is.
W3c kan deze functies dan overnemen na toetsing van deze functies.
Dat gezegd hebbend, zouden de browsermakers eigenlijk een soort onderling contact moeten hebben, en deze features op elkaar moeten afstemmen, zolang er nog geen w3c standaard is.
W3c kan deze functies dan overnemen na toetsing van deze functies.
Nee, je mist het punt van meneer Glazman. Hij waarschuwt vooraf, dat Webkit zo dominant kan worden dat het de standaard kan gaan negeren zonder problemen.
Webkit doet dat eigenlijk al.
Webkit doet dat eigenlijk al.
Ik heb het inderdaad anders opgevat. Zoals jij het stelt, dat Webkit zo dominant kan worden dat het standaarden kan negeren, daar heb je een punt. Puur omdat er een hoop mobiele websites zijn die alleen werken met een webkit browser. Maar naar mijn mening is dat eerder omdat juist de standaarden goed geimplementeerd zijn. Waardoor iedereen Webkit gebruikt, en het dus dominant wordt.
Ik ben het niet met je eens dat het nu al de standaarden negeert, want alles uit css2.0 en de css3.0 prototype zit er gewoon in. Het voegt echter extra functies toe. Dat vindt ik niet negeren, eerder een uitbreiding.
Ik ben het niet met je eens dat het nu al de standaarden negeert, want alles uit css2.0 en de css3.0 prototype zit er gewoon in. Het voegt echter extra functies toe. Dat vindt ik niet negeren, eerder een uitbreiding.
Prima, maar er moet dan wel een goede middenweg gekozen worden waarbij experimenten van browsers en de uitbreiding / aanvulling van standaarden van het W3C niet te ver uit elkaar liggen.
Glazman heeft best een punt dat het gevaarlijk is als browsers te veel gaan voorlopen op de standaarden, maar dat wordt ook wel in de hand gespeeld door de *kuch* snelheid van het W3C.
Neem bijvoorbeeld "border-radius" als prachtig voorbeeld. Een property die volgens mij al meer dan vijf jaar wordt ondersteund door browsers (Firefox, Webkit en daarna zelfs IE) maar nog steeds alleen in een candidate recommendation is opgenomen. Met als resultaat dat deze properties inderdaad bij verschillende browsers anders geïmplementeerd zijn, zoals bijvoorbeeld -webkit-border-top-left-radius v.s. -moz-border-radius-topleft.
Als je over een dergelijk eenvoudig en veel gevraagd én gebruikt item al meer dan 5 jaar moet doen om tot een definitieve aanbeveling te komen, dan is er volgens mij ook iets mis in je eigen besluitvormingstraject en is het wel erg makkelijk om huilie te doen over de browsermakers.
Bovendien, de genoemde browsers houden zich wel netjes aan alle bestaande standaarden. Dat is een groot verschil met IE6, waar de toen al bestaande CSS, HTML en Javascript standaarden verkeerd geïmplementeerd of gewoon totaal genegeerd werden.
Glazman heeft best een punt dat het gevaarlijk is als browsers te veel gaan voorlopen op de standaarden, maar dat wordt ook wel in de hand gespeeld door de *kuch* snelheid van het W3C.
Neem bijvoorbeeld "border-radius" als prachtig voorbeeld. Een property die volgens mij al meer dan vijf jaar wordt ondersteund door browsers (Firefox, Webkit en daarna zelfs IE) maar nog steeds alleen in een candidate recommendation is opgenomen. Met als resultaat dat deze properties inderdaad bij verschillende browsers anders geïmplementeerd zijn, zoals bijvoorbeeld -webkit-border-top-left-radius v.s. -moz-border-radius-topleft.
Als je over een dergelijk eenvoudig en veel gevraagd én gebruikt item al meer dan 5 jaar moet doen om tot een definitieve aanbeveling te komen, dan is er volgens mij ook iets mis in je eigen besluitvormingstraject en is het wel erg makkelijk om huilie te doen over de browsermakers.
Bovendien, de genoemde browsers houden zich wel netjes aan alle bestaande standaarden. Dat is een groot verschil met IE6, waar de toen al bestaande CSS, HTML en Javascript standaarden verkeerd geïmplementeerd of gewoon totaal genegeerd werden.
[Reactie gewijzigd door Zoefff op donderdag 9 februari 2012 13:06]
Er is een analoog in de rest van de software development wereld aan hoe standaardisatie bij het W3C werkt, het waterfall model. Laat dat model nu net geïntroduceerd zijn door Winston Royce als een anti-model, een ontwikkelmodel dat nadrukkelijk niet goed werkt. Desondanks is het overgenomen door grote delen van de software ontwikkelgemeenschap, en ik merkte een tijdje terug dat het W3C standaardisatiegebeuren ook ongeveer zo werkte: eerst standaardiseren (door W3C), daarna implementeren (door engine bouwers).Het lijkt me eigenlijk beter om eerst een goede standaard te maken dan om te haasten. Aan het begin van het gradienttijdperk had elke browser een eigen implementatie. Uiteindelijk heeft de W3C gekozen om Mozilla's implementatie te kiezen en dit wordt nu langzaam verwerkt in de standaarden.
Browser renderingengine bouwers zien ook dat dat niet werkt, en daarom zijn de meest prominente engine bouwers overgestapt op iets dat beter vergelijkbaar is met agile development.
Het gevolg is browser-specifieke prefixes. Als het W3C relatief aan de software wereld nieuwe (in dit geval CSS) standaarden op slakkentempo ontwikkelt hebben webbouwers natuurlijk zoiets van "ok, dan maar met prefixes". Het volgende probleem is nu dat het meestal wel mogelijk, maar niet echt fijn is meerdere van die dingen naast elkaar te gebruiken dus kiezen de devvers er eentje, en dat blijkt nu webkit te zijn.
Als webgebruiker in het algemeen ben ik ook niet echt blij met deze ontwikkelingen, maar de wortel van het hele gebeuren ligt toch echt bij de W3C.
Het enige (wegens behoud van inertia van het huidige platform op dit moment onrealistische) alternatief dat ik kan bedenken is HTML, JS en CSS alle 3 faliekant eruit knallen en vervangen door 1 taal die niet zomaar die gaten opvult, maar ook nog eens flexibel genoeg om nieuwe ontwikkelingen moeiteloos bij te benen (en nee, de huidige talen zijn, gezien de enorme engineering efforts die telkens nodig zijn om nieuwe features de respectievelijke engines in te krijgen, niet voldoende). Er is maar 1 taal die ik kan bedenken die daar écht voor geschikt is, en t is een (helaas) relatief onbekende tegenwoordig: Lisp.
[Reactie gewijzigd door Jeanpaul145 op donderdag 9 februari 2012 13:27]
JavaFX en Silverlight hebben het ook geprobeerd, maar werden door de concurrentie niet geaccepteerd ('not invented here").
Ik gebruik ook firefox maar zo'n melding heb ik nog nooit gezien. Kun je een voorbeeld geven voor desktop?Ik ben zelf een Firefoxgebruiker en zie heel vaak meldingen dat ik beter Chrome kan gebruiken om sites te bezoeken. Dit geldt niet alleen voor mobiel, maar ook desktop.
Ik gok dat hij gewoon ads voor Chrome ziet. 
Ik vind het niet geheel terecht, dat je Chrome als schuldige aanwijst. Op z'n minst moet je Safari er bij betrekken.
En de vinger zou naar geen van beide moeten wijzen, maar naar webkit. De engine achter beide browsers.
IE was overig wel zelf schuldig, omdat zij haar eigen engine had (Trident).
En de vinger zou naar geen van beide moeten wijzen, maar naar webkit. De engine achter beide browsers.
IE was overig wel zelf schuldig, omdat zij haar eigen engine had (Trident).
Het Webkit team bestaat voor 90% uit Apple en Google werknemers.
Kom op wat is er moeilijk aan het definieren van een css functie gradiant(kleur,kleur)?
misschien omdat je wel drie kleuren wilt?
Misschien wil je ook wel andere verlopen zoals 20% zwart, 70% rood en 10% blauw.
Wat dacht je van een gradiënt als een cirkel, ovaal of hoeken...
(Kleur, kleur) is dus zeker niet genoeg, en daarom ben ik blij dat het W3C zich er mee bemoeit en niet een Wouser
Misschien wil je ook wel andere verlopen zoals 20% zwart, 70% rood en 10% blauw.
Wat dacht je van een gradiënt als een cirkel, ovaal of hoeken...
(Kleur, kleur) is dus zeker niet genoeg, en daarom ben ik blij dat het W3C zich er mee bemoeit en niet een Wouser
Nee hoor, zo werkt het al jaren. Browsermakers experimenteren met nieuwe functies en als ze aanslaan worden ze opgenomen in de standaard. Andersom worden er nieuwe standaarden door W3C gepubliceerd waar browsermakers weer een tijdje over doen om ze in te bakken. Het is een dynamisch niet chronologisch proces als dat enigszins logisch klinkt 
En dan zijn het dus geen standaarden, het wordt niet makkelijker voor ontwikkelaars als browser makers doen waar ze zelf zin in hebben en css en html op hun eigen manier gaan interpreteren.
Nu al moet je heel veel dingen afvangen door voor IE/FF/Chrome etc extra CSS toe te voegen zodat het op alle browsers het er ongeveer hetzelfde uitziet.
Het zou verboden moeten zijn dat ze zelf allemaal verschillende property's bedenken en toevoegen. Ze zouden hun tijd moeten steken in het verwijderen van bugs in de huidige w3c standaarden die ze ondersteunen.
Heel veel ontwikkelaar gebruiken veel mogelijkheden gewoon weg niet omdat het op de ene wel werkt en de andere niet. Of ze gaan restricties op sites zetten dat je alleen maar met een bepaalde browser toegang hebt. Dat moeten we niet willen dacht ik zo.
Ik juich w3c standaarden alleen maar toe, jammer dat browser makers energie steken in een opmaak taal die alleen zij zelf maar ondersteunen.
Nu al moet je heel veel dingen afvangen door voor IE/FF/Chrome etc extra CSS toe te voegen zodat het op alle browsers het er ongeveer hetzelfde uitziet.
Het zou verboden moeten zijn dat ze zelf allemaal verschillende property's bedenken en toevoegen. Ze zouden hun tijd moeten steken in het verwijderen van bugs in de huidige w3c standaarden die ze ondersteunen.
Heel veel ontwikkelaar gebruiken veel mogelijkheden gewoon weg niet omdat het op de ene wel werkt en de andere niet. Of ze gaan restricties op sites zetten dat je alleen maar met een bepaalde browser toegang hebt. Dat moeten we niet willen dacht ik zo.
Ik juich w3c standaarden alleen maar toe, jammer dat browser makers energie steken in een opmaak taal die alleen zij zelf maar ondersteunen.
Klinkt alsof je het vooral over Chrome hebt. En ik ben het volledig met je eens, vaak worden bugs niet opgelost en wordt er alleen maar met features gegooid.
Zijn de Webkit bugs met border radius al opgelost?
Test:
http://ieblog.members.win...rder-radius.example1.html
Resultaten van de verschuillende browsers uit 2010 waren (IE9 rechtsonder):
http://ieblog.members.win...ain_rounded_corners_1.png
Ik heb geen iPad/iPhone om uit te proberen of het nu wel goed werkt
Test:
http://ieblog.members.win...rder-radius.example1.html
Resultaten van de verschuillende browsers uit 2010 waren (IE9 rechtsonder):
http://ieblog.members.win...ain_rounded_corners_1.png
Ik heb geen iPad/iPhone om uit te proberen of het nu wel goed werkt
Net even getest (iPhone met iOS 5.0.1) en ik krijg netjes (aannemede dat dat de bedoeling was) een blauw kader met afgeronde hoeken te zien.
Het horen allemaal rondjes te zijn
In dat geval, helaas. Het lijkt meer op een kruising van de twee rechter beelden in de tweede link van hAl, hierboven.
je kan pas van een standaard spreken wanneer je tot een overeenkomst komt. Neem nu HTML5. Dit is tot op de dag van vandaag nog altijd geen standaard hoewel vele gebruikers al roepen dat het geweldig is en vele browsers al claimen compatibel te zijn. Er zijn nog altijd struikelblokken (zoals <video>) die ervoor zorgen dat de standaard niet rond is. En zelfs als iedereen akkoord gaat is de standaars pas echt af wanneer 2 browsers de volledige specificaties hebben geïmplementeerd.
wat wel grappig (of eigenlijk heel erg triest) om te zien is, is dat, men het heel hoog op had met webstandaarden na het hele ie6 verhaal, maaar dat het vervolgens nog bijna 10 jaar duurt en er nog steeds geen nieuwe css specs op tafel liggen...
vind je het dan gek dat apple en google hun eigen plan trekken, dat de rest nu gaat volgen is alleen maar logisch nu webkit de dominante / defacto standaard aan het worden is.
maar om nu de schuld bij een ander te leggen (ook al zijn die webontwikkelaars lui), is in mijn opvatting op z'n minst raar.. dat hele standaardiseren gaat zo onmogelijk traag, en de vraag naar dit soort features is zo groot, dat we misschien moeten denken aan het moderniseren van w3c?
vind je het dan gek dat apple en google hun eigen plan trekken, dat de rest nu gaat volgen is alleen maar logisch nu webkit de dominante / defacto standaard aan het worden is.
maar om nu de schuld bij een ander te leggen (ook al zijn die webontwikkelaars lui), is in mijn opvatting op z'n minst raar.. dat hele standaardiseren gaat zo onmogelijk traag, en de vraag naar dit soort features is zo groot, dat we misschien moeten denken aan het moderniseren van w3c?
Die ligen er wel hoor maar bij Webkit willen ze nieuwe features inbouwen.maaar dat het vervolgens nog bijna 10 jaar duurt en er nog steeds geen nieuwe css specs op tafel liggen...
Niet hun bestaande features volledig in lijn met de standaarden brengen.
Ligt aan de benadering van de browser, iedereen hanteert zijn eigen 'efficiente' methode om dat af te handelen die ze aanroepen met hun eigen css-code. Webkit is overigens opensource. Niets weerhoudt de andere browsermakers ervan om hun syntax te ondersteunen.
Hoewel, het zou beter zijn als er gewoon standaard code is binnen CSS voor basale dingen als gradients.
Hoewel, het zou beter zijn als er gewoon standaard code is binnen CSS voor basale dingen als gradients.
die is er ook:Hoewel, het zou beter zijn als er gewoon standaard code is binnen CSS voor basale dingen als gradients.
http://dev.w3.org/csswg/css3-images/#gradients
Dit is de officiele standaard CSS syntax voor een liniaire gradient:
background: linear-gradient(left top,white, black);
Dit is de webkit syntax:
background: -webkit-gradient(linear, left bottom, right top, from(#fff), to(#000));
Webkit wijkt dus af van de W3C standaarden en heeft een proprietary implementatie.
[Reactie gewijzigd door hAl op donderdag 9 februari 2012 13:10]
WebKit heeft inmiddels al de W3C standaard geïmplementeerd, hoor. Nadeel is alleen dat gebruikers hun browsers niet altijd even snel upgraden, waardoor je toch nog rekening moet houden met de verouderde syntax.
Het gaat er vooral om dat ze ondersteuning voor die oude prefixed syntax verwijderen.WebKit heeft inmiddels al de W3C standaard geïmplementeerd, hoor.
Als Webkit snel de oude prefixed syntax niet meer ondersteund moeten de webdeveloeprs die gekozen hebben voor een experimentele proprietary ondersteuning overgaan naar de correcte standaardsondersteuning
[Reactie gewijzigd door hAl op donderdag 9 februari 2012 17:20]
Dat is zelfs nog niet eens nodig. Als je de relatief nieuwere dingen als gradients goed hebt gebruikt, heb je -webkit-gradient(), -moz-gradient(), -o-gradient(), -ms-gradient(), gradient().
Hoef je zelfs niet eens iets weg te halen, want de laatste die wordt herkend 'wint', en dat is de standaard gradient() van w3c.
Die verschillende vormen kun je zelfs nog automatiseren, zodat je er maar eentje zelf hoeft op te geven. Het probleem is dat veel devs te lui zijn om dit te doen, maar wel alvast de experimentele nieuwigheden willen gebruiken.
Persoonlijk vind ik die voorvoegsels uitermate handig. Bij het invoeren van nieuwe dingen zijn er altijd verschillen, omdat er fouten worden gemaakt of de specs nog onduidelijk zijn. Bij box-shadow bijvoorbeeld was de volgorde van de kleuren foutief bij webkit. Inmiddels niet meer. Niets aan de hand, kon je corrigeren met de prefix. En omdat de standaard als laatste stond, werkt het ook nog nu webkit de standaard herkent.
Hoef je zelfs niet eens iets weg te halen, want de laatste die wordt herkend 'wint', en dat is de standaard gradient() van w3c.
Die verschillende vormen kun je zelfs nog automatiseren, zodat je er maar eentje zelf hoeft op te geven. Het probleem is dat veel devs te lui zijn om dit te doen, maar wel alvast de experimentele nieuwigheden willen gebruiken.
Persoonlijk vind ik die voorvoegsels uitermate handig. Bij het invoeren van nieuwe dingen zijn er altijd verschillen, omdat er fouten worden gemaakt of de specs nog onduidelijk zijn. Bij box-shadow bijvoorbeeld was de volgorde van de kleuren foutief bij webkit. Inmiddels niet meer. Niets aan de hand, kon je corrigeren met de prefix. En omdat de standaard als laatste stond, werkt het ook nog nu webkit de standaard herkent.
Inderdaad… er zijn toch standaarden? Waarom moeten browsers dan allemaal hun eigen manier van functies aanspreken hebben? Nu hebben Firefox, Opera, Safari e.d. allemaal nagenoeg dezelfde omschrijving: o-gradient, moz-gradient, webkit-gradient e.d.… wat op zich prima te onthouden en gebruiken is.
Maar Internet Explorer heeft een compleet andere omschrijving… zélfs nu nog. Die hebben weer een filter waar nauwelijks iets van begrepen kan worden.
Als alle browsers dezelfde engine zouden gebruiken los je dat probleem op. Het enige wat je dan zou moeten doen is er toezicht op houden dat deze engine alles netjes volgens de afgesproken standaarden implementeert, en niet teveel op eigen houtje dingen gaat toevoegen. Anders heb je dalijk weer een engine die bloated en ronduit slecht werkt (kijk maar naar wat de oude engine van IE deed bijvoorbeeld)
Het lijkt mij veel beter om een uniforme open standaard-engine te gebruiken waar iedereen gebruik van maakt, en dáár dan een goed en strict toezicht op te houden, dan een handvol engines waar iedereen z'n eigen intepretaties op na houdt bij 't ontwikkelen ervan.
Maar, zoals 't nu op dit moment is kan ik op zich de waarschuwing van het W3C wel begrijpen. Maar de beredenering vind ik niet helemaal realistisch. Toezicht houden op standaarden waar iedereen, vroeger en nu nog steeds, her en der mee aan de haal gaat… of toezicht houden op 1 geweldige engine en dat toezicht strak genoeg houden zodat het een schone en snelle engine is, wordt en blijft?
Maar Internet Explorer heeft een compleet andere omschrijving… zélfs nu nog. Die hebben weer een filter waar nauwelijks iets van begrepen kan worden.
Als alle browsers dezelfde engine zouden gebruiken los je dat probleem op. Het enige wat je dan zou moeten doen is er toezicht op houden dat deze engine alles netjes volgens de afgesproken standaarden implementeert, en niet teveel op eigen houtje dingen gaat toevoegen. Anders heb je dalijk weer een engine die bloated en ronduit slecht werkt (kijk maar naar wat de oude engine van IE deed bijvoorbeeld)
Het lijkt mij veel beter om een uniforme open standaard-engine te gebruiken waar iedereen gebruik van maakt, en dáár dan een goed en strict toezicht op te houden, dan een handvol engines waar iedereen z'n eigen intepretaties op na houdt bij 't ontwikkelen ervan.
Maar, zoals 't nu op dit moment is kan ik op zich de waarschuwing van het W3C wel begrijpen. Maar de beredenering vind ik niet helemaal realistisch. Toezicht houden op standaarden waar iedereen, vroeger en nu nog steeds, her en der mee aan de haal gaat… of toezicht houden op 1 geweldige engine en dat toezicht strak genoeg houden zodat het een schone en snelle engine is, wordt en blijft?
W3C vindt het kennelijk niet nodig om hun CSS specificatie een beetje relevant en actueel te houden. Dat is hun goed recht. Alleen is het dan merkwaardig om te klagen over een de-facto uitbreiding van de CSS standaard die door een veelgebruikte render engine en door een groot aantal webbouwers wordt ondersteund.
Daarbij is er een groot verschil met IE only en Webkit only. Webkit is open source en kan door iedereen geimpementeerd worden op alle platformen. En doet het gewoon erg goed blijkbaar.
W3C vind het wel nodig om actueel te blijven maar zoals al eerder is aangegeven moet je bij een standaardproces op veel dingen letten en het goed standaardiseren want een standaard die rammelt heeft niemand wat aan en geeft alleen maar een slechte naam aan de standaard..
Het gaat niet om een uitbreiding maar gewoon om afwijkende implementaties in Webkit van de W3C standaarden.
W3C CSS3 pagina's voor de genoemde voorbeelden:
Gradients: http://dev.w3.org/csswg/css3-images/#gradients
Afgeronde hoeken: http://www.w3.org/TR/css3-background/#corners
Animaties: http://www.w3.org/TR/css3-animations/
W3C CSS3 pagina's voor de genoemde voorbeelden:
Gradients: http://dev.w3.org/csswg/css3-images/#gradients
Afgeronde hoeken: http://www.w3.org/TR/css3-background/#corners
Animaties: http://www.w3.org/TR/css3-animations/
[Reactie gewijzigd door hAl op donderdag 9 februari 2012 13:45]
en nu een bron dat w3c deze al heeft uitgerold (final status)... en nu een bron waarin staat sinds wanneer google deze features heeft ingevoerd...
dat er wat buggs in chrome blijven liggen praat nog niet goed dat het blijkbaar zo enorm lang heeft moeten duren eer mij eindelijk tot een voorlopige css3 draft heeft kunnen komen.
zeggen dat die standaarden bestaan is dus behoorlijk voorbarig...
jouw linkjes too little too late
dat er wat buggs in chrome blijven liggen praat nog niet goed dat het blijkbaar zo enorm lang heeft moeten duren eer mij eindelijk tot een voorlopige css3 draft heeft kunnen komen.
zeggen dat die standaarden bestaan is dus behoorlijk voorbarig...
jouw linkjes too little too late
Webkit implementeeert juist al heel veel standaarden voordat de de final status hebben. Vandaar ook dat ze met een -webkit- prefix worden geimplementeerd. Dat zijn features met een exoperimentele status.en nu een bron dat w3c deze al heeft uitgerold (final status)...
Wat ze echter niet doen is die eigen webkit implementaties die het in de W3C standaard dus niet geworden zijn weer snel uit uitfaseren.
Daardoor blijven deze proprietary implementaties steeds maar gebruikt worden door Webdevlopers ook al zijn die al geschrapt door het standaardisatie proces.
Het zou dus wenselijk zijn dat ze bij webkit niet alleen maar probeerden snel te scroren in features maar ook hun niet standaard oplossingen weer snel uit zouden faseren zodra de W3C anders heeft besloten.
En de status van de W3C recommendation heeft daar weinig mee te maken. Webkit wil graag voorlopen, dan moeten ze dus ook terug als ze een enkele keer de verkeerde richting gekozen hebben.
Ik vind dit eng, ik ben het helemaal met je eens
Als webkit dat niet doet, gedraagt het zich precies hetzelfde als Internet Explorer in het verleden.
Als webkit dat niet doet, gedraagt het zich precies hetzelfde als Internet Explorer in het verleden.
De term 'standaard' is zwaar overrated. Officiele standaarden zijn altijd oer traag. De rest van de wereld doet het met defacto standaarden en 'drafts'. HTTP is nog altijd niet helemaal door het RFC-standaardisatie-proces heen, maar dat gebruiken we ook al jaren zonder problemen.
In IE10? en volgens mij voor sommige dingen in IE9 heb je gewoon -ms-border-radius e.d.
Dit is het grote probleem, deze opties bestaan niet in de standaarden en dus als een browser maker denkt dat het wel handig is dan maakt hij of zij een optie die dat doet op de manier die hij vind dat goed is. Een andere maker van een andere browser ziet een zelfde behoefte en implementeert dit weer net even anders en zo voort en zo voort. Uiteindelijk kunnen ze allemaal ongeveer het zelfde maar allemaal op een net even andere manier.
Om dan hier weer een standaard uit te halen is erg lastig omdat je dan moet kiezen wie de beste implementatie heeft gemaakt en raad eens wie er in de keuze commissie zitten? Juist ja de zelfde browser bouwers en dus duurt het veel al redelijk lang voor men echt tot een conclusie komt daar naast is het erg lastig om even snel te beslissen dat A of B nu een standaard is want eerst moet er nog weer een inspraak proces komen moeten er allerlei andere formele stappen worden genomen en moet de rest van de browser makers nog besluiten hier ook aan mee te doen.
Dat een overgrote meerderheid van de mobiele browsers nu op WebKit draait is niet verkeerd dat WebKit nu dat doet dat de gehele opensource gemeenschap zo boos om was toen Microsoft het deed is ironisch.
Laten we eerlijk wezen Mozilla STANDARD COMPLIANT!!!, WebKit STANDARD COMPLIANT!!! en dat was voor een groot deel hun belangrijkste speer punt in de begin jaren van deze browsers. In middels hebben deze browsers dus niets anders gedaan dan Microsoft ooit deed goed ze volgen de standaarden dan wel maar voegen er zelf ook dingen aan toe die niet onderdeel van de standaard zijn. Op die manier kun je dus nooit tot een echte standaard komen omdat er altijd wel iemand is die een speciale tag wil toevoegen omdat ene ding te doen dat de andere niet kunnen doen.
Ik zou persoonlijk als ik een mobiele site zou afnemen van een site ontwikkelaar nooit of ten immer accepteren dat de site alleen in WebKit of alleen in IE of alleen in welke andere browser engine dan ook werkt. Ik zou er hoe dan ook altijd opstaan dat alleen de standaarden gebruikt worden dat dingen die in de standaarden niet mogelijk zijn dan ook maar niet gedaan worden. Dan maar een iets lelijkere site maar wel een site waar iedereen bij kan met welke fatsoenlijke browser dan ook.
Daar naast zou ik zeggen pas de standaard compliance checks aan en laat een browser engine deze nooit of ten immer door komen als er meer dan alleen de standaard tags en attributen ondersteund worden. Op dat moment zijn alle moderne browsers niet meer standaard compliant en zullen ze allemaal of zich aan de regels moeten houden of moeten toegeven dat ze niets anders doen dat IE5 en 6 ooit deden maar dan met een iets betere rendering van de standaard elementen.
Om dan hier weer een standaard uit te halen is erg lastig omdat je dan moet kiezen wie de beste implementatie heeft gemaakt en raad eens wie er in de keuze commissie zitten? Juist ja de zelfde browser bouwers en dus duurt het veel al redelijk lang voor men echt tot een conclusie komt daar naast is het erg lastig om even snel te beslissen dat A of B nu een standaard is want eerst moet er nog weer een inspraak proces komen moeten er allerlei andere formele stappen worden genomen en moet de rest van de browser makers nog besluiten hier ook aan mee te doen.
Dat een overgrote meerderheid van de mobiele browsers nu op WebKit draait is niet verkeerd dat WebKit nu dat doet dat de gehele opensource gemeenschap zo boos om was toen Microsoft het deed is ironisch.
Laten we eerlijk wezen Mozilla STANDARD COMPLIANT!!!, WebKit STANDARD COMPLIANT!!! en dat was voor een groot deel hun belangrijkste speer punt in de begin jaren van deze browsers. In middels hebben deze browsers dus niets anders gedaan dan Microsoft ooit deed goed ze volgen de standaarden dan wel maar voegen er zelf ook dingen aan toe die niet onderdeel van de standaard zijn. Op die manier kun je dus nooit tot een echte standaard komen omdat er altijd wel iemand is die een speciale tag wil toevoegen omdat ene ding te doen dat de andere niet kunnen doen.
Ik zou persoonlijk als ik een mobiele site zou afnemen van een site ontwikkelaar nooit of ten immer accepteren dat de site alleen in WebKit of alleen in IE of alleen in welke andere browser engine dan ook werkt. Ik zou er hoe dan ook altijd opstaan dat alleen de standaarden gebruikt worden dat dingen die in de standaarden niet mogelijk zijn dan ook maar niet gedaan worden. Dan maar een iets lelijkere site maar wel een site waar iedereen bij kan met welke fatsoenlijke browser dan ook.
Daar naast zou ik zeggen pas de standaard compliance checks aan en laat een browser engine deze nooit of ten immer door komen als er meer dan alleen de standaard tags en attributen ondersteund worden. Op dat moment zijn alle moderne browsers niet meer standaard compliant en zullen ze allemaal of zich aan de regels moeten houden of moeten toegeven dat ze niets anders doen dat IE5 en 6 ooit deden maar dan met een iets betere rendering van de standaard elementen.
Deze opties bestaan vrijwerl allemaal wel in de CSS standaarden maar de diverse webkit implementaties wijken daar gewoon van af.Dit is het grote probleem, deze opties bestaan niet in de standaarden
Er is bij webkit meer een haast om veel nieuwe features te ondersteunen dan om features netjes in lijn met de afgesproken standaarden te brengen
[Reactie gewijzigd door hAl op donderdag 9 februari 2012 13:02]
Een render-engine ontwikkelaar moet vrij zijn om engine specifieke tags toe te voegen. En een site mag deze naar eigen goeddunken implementeren. Dit maakt juist dat er verder ontwikkeld word aan de standaard.
We moeten alleen niet vergeten te checken hoe de pagina gerenderd wordt als webkit- tags niet gebruikt worden. En al helemaal geen melding geven aan de gebruiker dat ie maar een andere browser moet kiezen.
Zolang de website door een browser die aan de w3c standaard voldoet er voor de gebruiker goed uitziet is dit prima. En je kan prima verschillende layouts kiezen voor verschillende browsers omdat een browser nu eenmaal niet de css tag ondersteund die je graag zou willen zien.
Als een afnemer wil weten of zijn site er de komende jaren goed uit blijft zien doet hij er verstandig aan na te vragen hoe de site er uitziet als puur de w3c standaard wordt gevolgd. Deze is namelijk veel minder tijdgevoelig en browser gevoelig.
Een mooie optie zou zijn als de browserbouwers een checkbox hadden om browserspecifieke tags uit te schakelen.
Ik kan mij het meeste ergeren aan de website van mijn internet provider welke slechts in een beperkt aantal browsers weer kan geven dat er een storing is. Hoe ingewikkeld kan het zijn om je storingsoverzicht in alle browsers weer te geven. Het zijn 10 tekstregels. Maar ik noem geen namen (Ziggo!)
We moeten alleen niet vergeten te checken hoe de pagina gerenderd wordt als webkit- tags niet gebruikt worden. En al helemaal geen melding geven aan de gebruiker dat ie maar een andere browser moet kiezen.
Zolang de website door een browser die aan de w3c standaard voldoet er voor de gebruiker goed uitziet is dit prima. En je kan prima verschillende layouts kiezen voor verschillende browsers omdat een browser nu eenmaal niet de css tag ondersteund die je graag zou willen zien.
Als een afnemer wil weten of zijn site er de komende jaren goed uit blijft zien doet hij er verstandig aan na te vragen hoe de site er uitziet als puur de w3c standaard wordt gevolgd. Deze is namelijk veel minder tijdgevoelig en browser gevoelig.
Een mooie optie zou zijn als de browserbouwers een checkbox hadden om browserspecifieke tags uit te schakelen.
Ik kan mij het meeste ergeren aan de website van mijn internet provider welke slechts in een beperkt aantal browsers weer kan geven dat er een storing is. Hoe ingewikkeld kan het zijn om je storingsoverzicht in alle browsers weer te geven. Het zijn 10 tekstregels. Maar ik noem geen namen (Ziggo!)
engine-specifieke tags mogen best, wat mij betreft. Maar die werken dan alleen maar in die bepaalde engine. Dit is in feite ook zoals html5 en css3 worden ontwikkeld: er is heel sterk gekeken naar wat bepaalde browsers al hadden. Maar je hebt het hier dan om extra's.
Waar het hier om gaat zijn standaard-eigenschappen, die door webkit veel te lang afwijkend van de standaard worden weergegeven. Daar is terecht bij IE enorm over gekankerd. Er is geen enkele reden dat niet te doen als het om webkit gaat.
Ik mag graag in mijn handleidingen fantasiewoorden verzinnen. Maar dat is iets heel anders dan dat ik bestaande woorden foutief ga spellen. Zo foutief, dat ze door anderen niet meer goed zijn te begrijpen.
Waar het hier om gaat zijn standaard-eigenschappen, die door webkit veel te lang afwijkend van de standaard worden weergegeven. Daar is terecht bij IE enorm over gekankerd. Er is geen enkele reden dat niet te doen als het om webkit gaat.
Ik mag graag in mijn handleidingen fantasiewoorden verzinnen. Maar dat is iets heel anders dan dat ik bestaande woorden foutief ga spellen. Zo foutief, dat ze door anderen niet meer goed zijn te begrijpen.
Er is een belangrijk verschil met IE. Webkit is opensource, evenals Firefox. IE was en is dit niet, dus dat zij afweken van de standaard was een zeer kwalijke zaak.
En daar zit meteen ook het probleem. IE of Opera is niet opensource en kunnen dus niet de code simpelweg copy-n-paste. Anders moeten ze hun engine ook open maken.
Waarom is het een probleem als _alle_ browserbakkers de engine gaan gebruiken? Dan zijn alle websites toch weer voor iedereen te benaderen?
Zal gegarandeerd wel een veiligheidsprobleem met zich meebrengen; als er een lek in webkit zit zijn alle browsers er meteen vatbaar voor.
Zal gegarandeerd wel een veiligheidsprobleem met zich meebrengen; als er een lek in webkit zit zijn alle browsers er meteen vatbaar voor.
Het probleem is dat er webdevelopers zijn die de fouten in WebKit gaan ""benutten"" en te lamlendig zijn om hun sites volgens de standaarden te schrijven. Zoals Glazman al aangaf krijg je dan weer de situatie van "uw browser is niet ondersteund, rot maar lekker op met je firefox|opera|ie|alles_behalve_webkit".
Wat mij betreft mogen zulke developers sowieso het stemrecht (actief en passief) ontnomen worden.
Wat mij betreft mogen zulke developers sowieso het stemrecht (actief en passief) ontnomen worden.
Kapot stampen!Wat mij betreft mogen zulke developers sowieso het stemrecht (actief en passief) ontnomen worden.
Maar dat neemt het hele proces weer uit handen van de W3C en de nieuwe CSS standaard is dan feitelijk door de wc gespoeld.
Het lijkt me dat dat innovatie een beetje tegenwerkt... Daarnaast is webkit nou niet bepaald bugvrij - het enige grote voordeel dat webkit heeft tov gecko is dat het een snellere engine is.
Omdat op die manier alle andere engines geen kans meer krijgen, Daarnaast betekend het dat het web niet meer open is, je wordt dan verplicht om de webkit-engine te gebruiken om het goed te kunnen bekijken.Waarom is het een probleem als _alle_ browserbakkers de engine gaan gebruiken?
Oke, zo had ik er nog niet over nagedacht.
Een monocultuur is nooit goed. Als er ooit iets dramatisch mis gaat met Webkit (kritieke bug, verkocht, gehacked) is de hele wereld de pineut.
Vergelijk het met bananenbomen. Alle bananen die wij in de winkel kopen zijn genetisch identiek. Alle (cavendish)-banenbomen zijn klonen van elkaar. Nu is er een ziekte opgestoken waar die boom niet tegen kan. Als je eenmaal 1 zieke boom in je boomgaard hebt kun je ze allemaal omkappen, want er is geen enkele boom tegen bestendig, want ze zijn allemaal precies hetzelfde.
Je kan het ook met Windows vergelijken. Er zijn zoveel virussen voor Windows omdat alle machines precies hetzelfde zijn. Daardoor zijn er een paar wormen geweest die in een paar dagen tijd het grootste deel van de wereld hebben kunnen aanvallen.
Vergelijk het met bananenbomen. Alle bananen die wij in de winkel kopen zijn genetisch identiek. Alle (cavendish)-banenbomen zijn klonen van elkaar. Nu is er een ziekte opgestoken waar die boom niet tegen kan. Als je eenmaal 1 zieke boom in je boomgaard hebt kun je ze allemaal omkappen, want er is geen enkele boom tegen bestendig, want ze zijn allemaal precies hetzelfde.
Je kan het ook met Windows vergelijken. Er zijn zoveel virussen voor Windows omdat alle machines precies hetzelfde zijn. Daardoor zijn er een paar wormen geweest die in een paar dagen tijd het grootste deel van de wereld hebben kunnen aanvallen.
Dan wordt het toch tijd dat de W3C deze webkit-standaarden adopteert? Beetje raar als de officiele standaard niks te maken zou willen hebben met de 'de facto' standaard. Aangezien WebKit zelf onder GPL wordt gepubliceerd voorzie ik hier ook geen problemen.Als alle browsermakers de css-opties van WebKit overnemen, is er voor webbouwers ook geen reden meer om de officiële css-richtlijn te volgen. "Dit brengt de doodslag toe aan ons standaardisatieproces", waarschuwt Glazman. Hij roept webbouwers op om ook rekening te houden met gebruikers van andere browsers. Het ondersteunen van andere browsers kost volgens hem relatief weinig werk.
Helemaal als alle andere browsermakers aangeven WebKit te gaan volgen!
het is niet van apple 
"WebKit is een fork door Apple van KHTML, een project van KDE, en wordt gebruikt door Safari, een webbrowser meegeleverd met Mac OS X en door Google Chrome, een door Google gemaakte webbrowser, gelanceerd op 2 september 2008."
bron
bron
Idd slecht van tweakers om te zeggen dat het door Apple ontwikkelt is, ipv door KDE.
Nee, WebKit is van Apple. KHTML is van KDE, en Chrome is van Google. Uiteindelijk zijn ze allemaal familie, maar heeft iedereen in deze reeks zijn/haar eigen wijzigingen gemaakt waardoor er grote verschillen zijn. Tussen WebKit en Chrome zitten echter nog weinig verschillen, waardoor je redelijkerwijs kan zeggen dat Apple een groot deel van Chrome heeft gemaakt.
Daarin tegen hebben: Apple, KDE, Nokia, Google, RIM, Palm en Samsung allemaal geholpen bij de ontwikkeling van WebKit dus je kunt niet zomaar zeggen dat Apple het ontwikkelt heeft want dat is niet helemaal waar.
WebKit is wel degelijk door Apple ontwikkeld, dat klopt gewoon. Daarnaast gebruikt KDE nu zelf WebKit voor meerdere dingen.
Staat op http://www.webkit.org/ toch zeker dat het een KDE branch is en niet andersom.
Zou je kunnen onderbouwen wat daar zo grappig aan is?
In het begin zijn ook maar grotendeels de standaarden van Netscape overgenomen (dit zie je nog steeds terug in de "Mozilla" in iedere browser user-agent-string.)
Apple Webkit is zelf weer een een voortbouwsel op KHTML, dat weer op Gecko voortborduurt (zelf de opvolger van Mozilla). Ze hebben dat bij Apple niet in een vacuum verzonnen en het wordt ook niet in een vacuum ontwikkelt. Grote jongens als Nokia, Samsung en Google dragen ook bij.
Op de desktop-markt maakt tegenwoordig zo'n 40% gebruik van Apple Webkit (Safari + Chrome), op de mobiele markt misschien wel meer dan 90% (iOS + Android).
De overige browsermakers hebben zelf al aangekondigd dat ze de Webkit-functies zullen gaan implementeren, wat is er dan zo hilarisch aan het idee om het tot officiele standaard te maken?
In het begin zijn ook maar grotendeels de standaarden van Netscape overgenomen (dit zie je nog steeds terug in de "Mozilla" in iedere browser user-agent-string.)
Apple Webkit is zelf weer een een voortbouwsel op KHTML, dat weer op Gecko voortborduurt (zelf de opvolger van Mozilla). Ze hebben dat bij Apple niet in een vacuum verzonnen en het wordt ook niet in een vacuum ontwikkelt. Grote jongens als Nokia, Samsung en Google dragen ook bij.
Op de desktop-markt maakt tegenwoordig zo'n 40% gebruik van Apple Webkit (Safari + Chrome), op de mobiele markt misschien wel meer dan 90% (iOS + Android).
De overige browsermakers hebben zelf al aangekondigd dat ze de Webkit-functies zullen gaan implementeren, wat is er dan zo hilarisch aan het idee om het tot officiele standaard te maken?
[Reactie gewijzigd door Keypunchie op donderdag 9 februari 2012 12:48]
Een commerciele partij (of dat nou Google of Apple is) moet niet de standaarden gaan domineren. Dat moet je aan een onafhankelijke organisatie overlaten.
dat is alleen maar morgelijk als die onafhankelijke organisatie een beetje op schiet.. ik zit er iig niet op te achten dat tweakers.net er morgen uit ziet zoals 10+ jaar geleden omdat we geen nieuwe technologien meer morgen gebruiken tot dat w3c ze heeft goed gekeurd...
misschien moet tweakers.net eens alle html5 / css3 en browser specifieke functies uitzetten evenals jquery (want dat is ook niet erg netjes)... tot dat deze weer zijn goedgekeurd door w3c (over een jaar of 2 ?)...
misschien moet tweakers.net eens alle html5 / css3 en browser specifieke functies uitzetten evenals jquery (want dat is ook niet erg netjes)... tot dat deze weer zijn goedgekeurd door w3c (over een jaar of 2 ?)...
@Keypunchie en @Pixeltje erboven
menen jullie dit nou echt?
menen jullie dit nou echt?
Wat iser mis als het W3C een goede standaard overneemt? Waarom zou je het niet doen?
Sterker nog, met hun huidige koers verliezen ze alle relevantie. Krijg je hetzelfde gezeik als met HTML5 en de video-tag. Zolang ze niks specificeerden was het mooie gelegenheid voor Adobe en Microsoft om hun Silverlight en Flash-plugins overal tussen te proppen.
Gaat nog best lang duren voor we daar weer eindelijk vanaf zijn.
[edit]
Voor alle duidelijkheid: ik zeg niet dat alle browsermakers de WebKit-engine moeten overnemen. Het gaat erom dat het W3C niet zo moet zeuren en haast moet maken met het kiezen van een standaard voor specifieke functionalteiten zoals gradient. Dan is het kiezen voor de standaard zoals gedefinieerd door WebKit een goede keuze, wat alleen al blijkt door de marktadaptatie.
Sterker nog, met hun huidige koers verliezen ze alle relevantie. Krijg je hetzelfde gezeik als met HTML5 en de video-tag. Zolang ze niks specificeerden was het mooie gelegenheid voor Adobe en Microsoft om hun Silverlight en Flash-plugins overal tussen te proppen.
Gaat nog best lang duren voor we daar weer eindelijk vanaf zijn.
[edit]
Voor alle duidelijkheid: ik zeg niet dat alle browsermakers de WebKit-engine moeten overnemen. Het gaat erom dat het W3C niet zo moet zeuren en haast moet maken met het kiezen van een standaard voor specifieke functionalteiten zoals gradient. Dan is het kiezen voor de standaard zoals gedefinieerd door WebKit een goede keuze, wat alleen al blijkt door de marktadaptatie.
[Reactie gewijzigd door Keypunchie op donderdag 9 februari 2012 12:50]
Nee dat is handig, één browser die het bepaalt voor alle andere browsers... waar hebben we dat ook al weer eerder gezien?Helemaal als alle andere browsermakers aangeven WebKit te gaan volgen!
Gradients en afgeronde hoeken zijn wel opgenomen in CSS3, maar deze standaard is nog niet officieel.
Als render engines eigen features toevoegen moeten deze de prefix van de browser hebben. CSS Validators negeren dan deze properties. Het probleem is dat het W3C al sinds 2004(!) bezig is met deze standaard.
Hoewel CSS inmiddels wel is gepubliceerd als Technical Recommendation, heeft deze nog steeds de 'snapshot' status. Eigenlijk is het stiekum dus gewoon nog een Technical Draft.
Het als in 1996 gaat de besluit vorming van het W3C als dikke stroop. Zowel Netscape en Microsoft hadden haast vanwege de browser oorlog en het W3C deed alles, net zoals nu, op zo'n dooie gemakkie. Het gevolg, de browser developers gingen zelf uitbreidingen schrijven. Zowel Netscape 4 als Internet Explorer 4 hadden vergelijkbare features, maar beide waren anders gespecificeerd.
En door gebrek aan concurrentie voor Internet Explorer is de browser oorlog als een veenbrandje verder gegaan. Maar inmiddels is de browser oorlog weer in alle hevigheid losgebarsten en weer maken de developers de keuze voor een specifieke engine. Dat is heel erg lang Internet Explorer geweest, maar nu blijken veel developers dus de keuze voor webkit te maken.
En over 5 jaar krijgen we weer websites als 'stopwebkit.nl' omdat we dan met een totaal andere render engine werken en iedereen die webkit websites vervloekt.
Markt dominantie is geen probleem als de standaarden vast leggen. Glazman en consorten moeten dus gewoon opschieten met de CSS3 en CSS4 specificaties. Ja CSS4 ja, want de developers van de render engines zijn alweer bezig met de volgende generatie en die zal ook weer nieuwe CSS features hebben, waarschijnlijk om HTML5 nog beter te maken.
Nu zijn webkit en gecko engines wel open source, maar de render engines van Microsoft en Opera zijn dat niet. Als de render engine developers elkaars features proberen over te nemen krijg je op een gegeven moment dat de feature in sommige render engines niet helemaal goed werkt.
Misschien moeten Microsoft, Google, Apple, Mozilla en Opera maar zelf een CSS werkgroep oprichten en daarna de specificatie as-is naar het W3C sturen. Browsers concurreren tegenwoordig al lang niet meer op specifieke features, maar juist op snelheid en correctheid..
Als render engines eigen features toevoegen moeten deze de prefix van de browser hebben. CSS Validators negeren dan deze properties. Het probleem is dat het W3C al sinds 2004(!) bezig is met deze standaard.
Hoewel CSS inmiddels wel is gepubliceerd als Technical Recommendation, heeft deze nog steeds de 'snapshot' status. Eigenlijk is het stiekum dus gewoon nog een Technical Draft.
Het als in 1996 gaat de besluit vorming van het W3C als dikke stroop. Zowel Netscape en Microsoft hadden haast vanwege de browser oorlog en het W3C deed alles, net zoals nu, op zo'n dooie gemakkie. Het gevolg, de browser developers gingen zelf uitbreidingen schrijven. Zowel Netscape 4 als Internet Explorer 4 hadden vergelijkbare features, maar beide waren anders gespecificeerd.
En door gebrek aan concurrentie voor Internet Explorer is de browser oorlog als een veenbrandje verder gegaan. Maar inmiddels is de browser oorlog weer in alle hevigheid losgebarsten en weer maken de developers de keuze voor een specifieke engine. Dat is heel erg lang Internet Explorer geweest, maar nu blijken veel developers dus de keuze voor webkit te maken.
En over 5 jaar krijgen we weer websites als 'stopwebkit.nl' omdat we dan met een totaal andere render engine werken en iedereen die webkit websites vervloekt.
Markt dominantie is geen probleem als de standaarden vast leggen. Glazman en consorten moeten dus gewoon opschieten met de CSS3 en CSS4 specificaties. Ja CSS4 ja, want de developers van de render engines zijn alweer bezig met de volgende generatie en die zal ook weer nieuwe CSS features hebben, waarschijnlijk om HTML5 nog beter te maken.
Nu zijn webkit en gecko engines wel open source, maar de render engines van Microsoft en Opera zijn dat niet. Als de render engine developers elkaars features proberen over te nemen krijg je op een gegeven moment dat de feature in sommige render engines niet helemaal goed werkt.
Misschien moeten Microsoft, Google, Apple, Mozilla en Opera maar zelf een CSS werkgroep oprichten en daarna de specificatie as-is naar het W3C sturen. Browsers concurreren tegenwoordig al lang niet meer op specifieke features, maar juist op snelheid en correctheid..
Een andere mogelijkheid zou zijn om iets minder strikt te parsen. Wanneer hetgeen zonder de -webkit-* (of andere prefix) ondersteund wordt dan kunnen ze de prefix gewoon weg laten. Vaak is er wel een prefix maar is de implementatie bij alle browsers hetzelfde. Nog een optie, voor webdevelopers, is LESS te gebruiken met vendor-prefixes.https://github.com/derekallard/LESSCSS-Vendor-Prefixes
Gradient zal in gebruik worden genomen zodra CSS3 gestandaardiseerd is.
Op dat moment kunnen alle browsers het gaan ondersteunen.
Onderdeel van de CSS-standaard is dat je vendor prefixes mag om zo al wel nieuwe funky dingen te implementeren die er aan zitten te komen, maar nog niet in de officiele standaard zitten. Dit is wat alle browserbakkers doen, zodat ze al even los kunnen gaan met nog niet 100% compliant ondersteuning, maar wel nieuwe dingen te kunnen.
Daarom konden al veel browsers CSS3-trucjes, terwijl CSS3 nog gestandaardiseerd moet worden.
Het probleem nu is dat luie websitebouwers voor het grote publiek aimen en alleen de -webkit-varianten opnemen...
http://nl.wikipedia.org/wiki/Cascading_Style_Sheets
http://reference.sitepoint.com/css/vendorspecific
Op dat moment kunnen alle browsers het gaan ondersteunen.
Onderdeel van de CSS-standaard is dat je vendor prefixes mag om zo al wel nieuwe funky dingen te implementeren die er aan zitten te komen, maar nog niet in de officiele standaard zitten. Dit is wat alle browserbakkers doen, zodat ze al even los kunnen gaan met nog niet 100% compliant ondersteuning, maar wel nieuwe dingen te kunnen.
Daarom konden al veel browsers CSS3-trucjes, terwijl CSS3 nog gestandaardiseerd moet worden.
Het probleem nu is dat luie websitebouwers voor het grote publiek aimen en alleen de -webkit-varianten opnemen...
http://nl.wikipedia.org/wiki/Cascading_Style_Sheets
http://reference.sitepoint.com/css/vendorspecific
[Reactie gewijzigd door _eXistenZ_ op donderdag 9 februari 2012 12:25]
Aangezien de source code van webkit bekend is kunnen de mobiele versies van andere browsers gemakkelijk de standaarden van webkit overnemen, wat op den duur dit probleem kan verhelpen.
Aangezien browsers tegenwoordig steeds sneller worden ontwikkeld, mag het W3C wel even naar zichzelf kijken. Ook standaardisatie kan versneld worden.
zo creëer je problemen die niet eens bestaan; "adapt, beat or die!"
Of ze maken de css3 standaard sneller af. Op het moment is het al niet heel erg nodig meer om -webkit- -moz- te gebruiken maar gewoon de standaard in te voeren. Oftewel waarom niet in css een soort general flag plempen? In plaats van voor alles -moz- / * te zetten bovenaan je document een lijstje met browsers dat gebruik mag maken van je nieuwe features.
Dat de browser dan zelf uitmaakt of de ondersteuning prima is of niet in de gebruikte versie (en dus anders die flags gewoon negeert). Dat brengt vast ook problemen met zich mee, maar totdat css volledig gesupport word zie ik ook geen noodzaak een speciale support in te bouwen in het bouw proces.
Dat de browser dan zelf uitmaakt of de ondersteuning prima is of niet in de gebruikte versie (en dus anders die flags gewoon negeert). Dat brengt vast ook problemen met zich mee, maar totdat css volledig gesupport word zie ik ook geen noodzaak een speciale support in te bouwen in het bouw proces.
Natuurlijk is het geen goede ontwikkeling dat ontwikkelaars zich richten op één platform, maar na jaren frustraties met sites die het alleen deden in Internet Explorer 6 voor Windows is er een geniepigheid in mij die doet denken "weten die Windows (Phone) gebruikers ook eens hoe het is als hun platform niet ondersteund word".
Verder heeft WebKit (en ook Mozilla) alleen maar bijgedragen aan het dragelijker maken van Front End Development, want het heeft er voor gezorgd dat nieuwe versies van Internet Explorer meer CSS3 functies ondersteunen, en WebKit (en Mozilla) browsers maakt het ontwikkelen van geavanceerder interfaces ontzettend veel makkelijker, dus we hebben er veel aan te danken. Nu maar hopen dat Front End developers ook hun paginas er netjes uit laten zien op niet mobile-webkit browsers.
P.S.
box-sizing: border-box; FTW!
css gradients FTW!
box shadow FTW!
css animations FTW!
Verder heeft WebKit (en ook Mozilla) alleen maar bijgedragen aan het dragelijker maken van Front End Development, want het heeft er voor gezorgd dat nieuwe versies van Internet Explorer meer CSS3 functies ondersteunen, en WebKit (en Mozilla) browsers maakt het ontwikkelen van geavanceerder interfaces ontzettend veel makkelijker, dus we hebben er veel aan te danken. Nu maar hopen dat Front End developers ook hun paginas er netjes uit laten zien op niet mobile-webkit browsers.
P.S.
box-sizing: border-box; FTW!
css gradients FTW!
box shadow FTW!
css animations FTW!
Zeer begrijpelijk waarom je dit denkt hoor maar redelijk oneerlijk voor de mensen die windows phone hebben gekocht die hier niks vanaf weten. Veel van hun mobiele websites zouden het in de toekomst dan niet doen en dat is slechte reclame.maar na jaren frustraties met sites die het alleen deden in Internet Explorer 6 voor Windows is er een geniepigheid in mij die doet denken "weten die Windows (Phone) gebruikers ook eens hoe het is als hun platform niet ondersteund word".
Ik zie liever dat W3C eens inziet dat browsermakers ook wel mee kunnen helpen aan het maken van standaards.
Dat is imo iets wat MS aan hun klanten moet uitleggen en niet de verantwoordelijkheid bij de websitebouwer leggen. Is toch gewoon simpeler het meest gebruikte/populaire kit als standaard te gaan nemen. Waarop de rest zich dan kan baseren.
Het W3C is zelf dermate laks in het goedkeuren van standaarden dat veel browsermakers zelf alvast een concept of recommendation in hun rendering engine toevoegen. Ze gebruiken daarvoor vendor-prefixed zodat (vaak véél) later als het W3C het daadwerkelijk accepteert en tot standaard verheft conflicten mbt de werking worden voorkomen. Het W3C zou eens niet vier jaar moeten doen over het omzetten van een recommendation tot een standaard (rounded-corners, gradients, multiple background images, background image scaling, ellipsis etc), dan zou er minder tot geen enkele reden zijn voor browsermakers om met vendor prefixes als -moz-, -o- en -webkit- te werken.
Tot die tijd kunnen ontwikkelaars hulpmiddelen als css3please.com gebruiken om cross-browser css te gebruiken, en moeten browsermakers die géén ondersteuning van concept css dat nog niet door het W3C is doorgevoerd, niet zeuren. Dan heeft een user géén ronde hoeken, boeiend. Een site hoeft er niet in elke browser exact hetzelfde uit te zien.
Tot die tijd kunnen ontwikkelaars hulpmiddelen als css3please.com gebruiken om cross-browser css te gebruiken, en moeten browsermakers die géén ondersteuning van concept css dat nog niet door het W3C is doorgevoerd, niet zeuren. Dan heeft een user géén ronde hoeken, boeiend. Een site hoeft er niet in elke browser exact hetzelfde uit te zien.
[Reactie gewijzigd door Danny op donderdag 9 februari 2012 12:25]
En wie ben jij om te bepalen hoe snel de "echte" gebruikers van ontwikkelingen mogen genieten. Die dominantie van WebKit is echt niet omdat het niet uitmaakt. Het maakt juist heel veel uit en daarom springen webdevelopers er boven op.Voor het overgrote deel van de echte gebruikers van het internet zijn dat soort dingen niet belangrijk zijn, ze willen hun informatie vinden/communiceren etc, en daar zijn geen ronde hoekjes en mooie kleurverloopjes voor nodig.
Als het niet uitmaakte, dan zou de W3C ook niet aan de bel hoeven te trekken, toch?
Sorry hoor maar als jij me een website kunt laten zien die niet te zien is met wat anders dan webkit krijg je van mij een ijsje,
Er is echt geen webontwikkelaar die dat nog doet...
Er is echt geen webontwikkelaar die dat nog doet...
Op dit item kan niet meer gereageerd worden.
Onderwerpen
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
