Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 71 reacties, 20.162 views •
Submitter: hAl

Microsoft heeft in een blogposting een aantal mogelijkheden aan webdevelopers voorgesteld om met name mobiele websites goed met Internet Explorer 10 te laten samenwerken. Momenteel worden veel mobiele sites geoptimaliseerd voor de op mobiele apparaten dominante webkit-engine, waardoor deze niet altijd correct functioneren op andere browsers.

Internet Explorer 10 voldoet volgens Microsoft vrijwel geheel aan de html5-standaard. De browser is niet alleen opgenomen in Windows 8, maar ook in Windows Phone 8. Webontwikkelaars die sites geschikt maken voor mobiele apparaten als smartphones en tablets zijn zich de laatste jaren echter specifiek gaan richten op browsers die gebruik maken van de webkit-engine. Webkit wordt onder andere gebruikt in de stockbrowsers van iOS en Android.

In een poging mobiele websites die voor webkit zijn geoptimaliseerd ook correct te tonen en laten functioneren in IE10, heeft Microsoft op zijn Windows Phone Developer Blog in een posting een aantal tips en trucs vrijgegeven. De voorgestelde IE10-optimalisaties die developers in de html- en css3-broncode zouden kunnen doorvoeren, moeten onder andere een oplossing bieden voor websites die nog geen gebruik maken van reeds goedgekeurde css- en dom-properties. Zo bevatten veel mobiele websites in de broncode nog steeds zogenaamde webkit-specifieke prefixes die niet langer strikt nodig zijn, bijvoorbeeld de css-property '-webkit-box-shadow' in plaats van het gestandaardiseerde 'box-shadow'.

Complexer is de afhandeling van touch-input die verschilt in webkit-browsers en IE10. Terwijl webkit-browsers zogenaamde touch events gebruiken, heeft Microsoft in IE10 het pointer events-mechanisme doorgevoerd. Hoewel de W3C een candidate recommendation-status heeft gegeven aan touch events, wil de organisatie Microsofts pointer events als uiteindelijk standaard gaan ontwikkelen, mede omdat deze ook samenwerkt met muis- en stylusinput. Microsoft schrijft in zijn blogposting dat aanpassingen voor pointer events relatief eenvoudig zijn, alhoewel een zoek- en vervangopdracht in de broncode niet zal volstaan.

De posting van Microsoft laat zien dat het bedrijf de afgelopen jaren met de introductie van Internet Explorer 8, 9 en 10 een ommezwaai heeft gemaakt en gekozen heeft voor het omarmen van open webstandaarden. De softwaregigant kreeg lange tijd forse kritiek van webdevelopers omdat het ontwikkelaars met de dominante positie van Internet Explorer 6 jarenlang dwong om niet-gestandaardiseerde code te schrijven. Inmiddels zijn de laatste IE-browsers compatibel met de belangrijkste W3C-standaarden en werkt Microsoft actief aan het ondersteunen en ontwikkelen van nieuwe webstandaarden.

Reacties (71)

Reactiefilter:-171071+141+213+30
Deja vu? Ik vind het grappig om te zien dat zo'n 10-15 jaar geleden webontwikkelaars speciaal websites voor IE gingen ontwikkelen, omdat dit de dominante browser was maar zich voor geen fluit aan de webstandaarden hield. Anno 2012 vraagt Microsoft wederom aan ontwikkelaars om voor IE te ontwikkelen, maar juist precies omdat de browser zich wél aan de standaarden houdt!

Ik vraag me eerlijk gezegd wel af waarom er juist met Webkit een 'andere manier van werken' is dan met IE. Een standaard is een standaard zou je zeggen.. Of hangt dit samen met het feit dat MS hier nieuwe standaarden mee doorheen probeert te krijgen?

[Reactie gewijzigd door Eagle Creek op 18 november 2012 14:44]

Gelukkig houd IE zich nu juist aan de standaarden.... Webkit browsers willen je altijd helpen. En als je dus ergens een foutje hebt dan regelen ze dat wel voor je.. Niet altijd fijn omdat IE er dan over struikelt
Als Microsoft zich aan de standaarden houd waarom moet iemand dan nog zijn website aanpassen die al aan de standaarden voldoen? iets zegt me dat er iets niet klopt
Omdat die website dan niet aan de standaard voldoet.
(inkoppertje, ik weet het)
Complexer is de afhandeling van touch-input die verschilt in webkit-browsers en IE10. Terwijl webkit-browsers zogenaamde touch events gebruiken, heeft Microsoft in IE10 het pointer events-mechanisme doorgevoerd. Hoewel de W3C een candidate recommendation-status heeft gegeven aan touch events [..]
Oftewel, Microsoft leert het nooit. WebKit's touch events zijn een de facto standaard omdat vrijwel alle mobieltjes een webkit-based browser hebben en het is een W3C Candidate Recommendation (laatste fase voordat het 'recommendation' wordt en hoger gaat het niet bij W3C), maar toch besluit Microsoft deze standaard niet te ondersteunen... Slim? We zullen zien maar op de korte termijn maakt dit het leven er voor web ontwikkelaars weer niet makkelijker op. Ze zullen nu namelijk weer twee implementaties moeten maken voor touch ondersteuning.

Microsoft wordt altijd verweten dat ze zich niet aan standaarden houden, maar in feite klopt dat verwijt niet. Sinds IE6 al houden ze zich heel behoorlijk aan standaarden. Maar wat Microsoft al jaren fout doet (imho) is niet kijken naar wat concurrerence browsers doen en daar rekening mee houden. Als een bepaalde API werkt en breed ondersteund wordt dan moeten ze niet zeuren en die API ondersteunen, anders zit ik als ontwikkelaar weer alles dubbel te doen omdat ik twee API's moet ondersteunen.

Toen ze nog de dominante browser hadden kwamen ze daarmee weg. Je had als ontwikkelaar weinig keuze dan beide methoden te implementeren. Maar nu betreden ze een markt waar ze de underdog zijn. Nu weet ik niet of ze er mee weg komen. Als ontwikkelaar zou ik voor mobile IE10 gewoon negeren totdat er genoeg Surface tablets en Windows Phones verkocht zijn om een investering te verantwoorden. MS moet zorgen dat code die op WebKit werkt (voor zover niet WebKit specifiek, wat met de Touch event API niet het geval is) ook gewoon werkt op IE10 en niet weer aan de web developers vragen om maar weer extra moeite te doen en kosten te maken. Die krijgen daar zo langzamerhand tabak van.
Naja, dit maakt het wel heeel eenzijdig. Even wat nuancering. Ik heb verschillende html5 apps gebouwd die puur voor webkit bedoeld waren en anderhalve week geleden een html5 app ontwikkeld voor in de windows store. Wat ik toch wel het meeste merkte was dat alle technieken die ik altijd heerlijk daar kon gebruiken en niet op normale websites (vanwege ie7 enzo) daar wel gewoon werkte (ie10 only environment, dus dingen zoals queryselectors, css3 flexbox model, shadows, transforms, etc.) en dat ik maar zelden iets wou gebruiken wat ie10 niet supporte.
MS moet zorgen dat code die op WebKit werkt (voor zover niet WebKit specifiek, wat met de Touch event API niet het geval is)
Het probleem zit hem nu juist in het feit vooral dat ze besloten dat volgens de standaard iedere engine op niet afgemaakte features het moet prependen met engine prefixes zoals "-webkit-" for css en "webkit" gewoon voor javascript. Alhoewel de redenatie valide is (dat pas als het klaar is je zeker weet dat alle implementaties hetzelfde zijn) zorgt dit er nu voor dat alle developers die eigenlijk features gebruikte die niet voor productie omgevingen bedoeld waren nu heerlijk niet op IE werken (ik ook, daar niet van). Wat ze volgens mij hadden moeten doen was iedere implementatie een naam geven terwijl het in development was (e.g. --jacob-box-shadow of --google-flexmodel) en iedereen die het opdezelfde manier implementeerde zou dezelfde naam gebruiken totdat het klaar is en de prefix zou worden verwijderd. Maja, is makkelijk praten nu retrospectief natuurlijk, maar toch jammer nu voor microsoft.

Hoe dan ook, het aantal belangrijke API's die IE10 niet ondersteund en de concurrentie wel zijn er serieus maar een paar (stuk of 3 of the top of my head: webgl, touch apis wist ik niet eens, mutation observer, usermedia access) en als je bedenkt dat je het over 10-tallen totaal hebt is dat gewoon zeer netjes. Natuurlijk kan het nog steeds beter, maar het beeld wat OddesE schetst is toch wel heel eenzijdig en het is toch echt wel onze schuld vooral als developers dat het zo slecht werkt als het nu werkt (hadden we bijvoorbeeld er alleen al voor gezorgt dat het zowel in firefox mobile en webkit zou hebben gewerkt dan had het ook veeeel beter in IE10 gewerkt).

Edit: En sowieso is het belangrijk om te begrijpen dat firefox dingen ondersteund die webkit nog niet ondersteund, webkit dingen die firefox en IE niet, enz.

offtopic:
Edit2: Maja, misschien ben ik een beetje biased, want ik heb wel een beetje te doen met microsoft, ze doen zo vreselijk hard hun best de laatste tijd en hebben ook wel bepaalde dingen echt vreselijk knap gedaan en bedacht, maar worden alsnog vreselijk gebashed door sommige mensen. Wel grappig eigenlijk, bij m'n eerste officiele baan werd ik door de directeur toen ik er ging werken gewaarschuwd dat ze heel microsoft minded waren en tegen de tijd dat ik weg ging hebben ze nu hun basis infrastructuur naar linux overgezet en andere open source software overgezet en ben ik ondertussen wat meer pro microsoft geworden, ach ja :P

[Reactie gewijzigd door David Mulder op 19 november 2012 00:45]

WebKit's touch events zijn een de facto standaard omdat vrijwel alle mobieltjes een webkit-based browser hebben en het is een W3C Candidate Recommendation (laatste fase voordat het 'recommendation' wordt en hoger gaat het niet bij W3C), maar toch besluit Microsoft deze standaard niet te ondersteunen
De door Microsoft bij W3C ingediende Pointer events standaard is enigzins compatibel met touch events standaard maar heeft als voordeel dat het eventmodel niet puur voor touch schikt is maar ook voor een muis device. De touch events standaard van Webkit is effectief alleen nuttig voor mobieltjes maar met de Pointer events standaard van Microsoft kan je websites zowel op mobieltjes als op laptops en desktops op een vergelijkbare manier gebruiken.

Zeker als je ook media queries gebruikt om je websites dynamisch aan te passen aan de schermgrootte is dat erg nuttig.

[Reactie gewijzigd door hAl op 19 november 2012 08:10]

Omdat website's geoptimaliseerd voor webkit niet perse aan de standaard voldoen aangezien webkit de standaard ook niet volgens de letter volgt of de syntax wel ondersteund maar zijn eigen draai er aan geeft (iets wat kan in de HTML specs, want zo duidelijk zijn die helemaal niet)
Dus omdat webkit meer gebruikt wordt is het DE standaard. En moet IE maar volgen aan Webkit en niet zijn eigen weg gaan. Immers Webkit is groter..

Dit deed Microsoft vroeger ook toch met IE. Dus hetzelfde gebeurt nu met Webkit. Gelukkig is Webkit opensource tegenover IE. Dus we zijn er alleen maar op vooruit gegaan met Webkit.

Top dus!!

[Reactie gewijzigd door Texamicz op 18 november 2012 20:15]

ah, standaarden hebben we niet nodig, dat mag 1 bedrijf/ render engine bepalen...
dat is iig wat je wilt zeggen..
ik krijg flashbacks van IE6...
opensource of niet maakt in deze helemaal niets uit..
Maakt in deze natuurlijk wel degelijk uit, want iedereen kan de implementatie gratis overnemen. En er is geen mogelijkheid tot vendor lock-in, juist omdat het Open Source is.

Verder is het voorbeeld van -webkit-box-shadow een beetje flauw, omdat WebKit zich hier juist heel goed aan de W3C aanbevelingen houdt; zolang een standaard nog in ontwikkeling is moeten browser makers die de voorgestelde functionaliteit willen implementeren deze vooraf laten gaan door een eigen prefix (-webkit- in dit geval) om te voorkomen dat als de standaard wijzigt dat er dan al meteen afwijkende implementaties zijn. Dat box-shadow vervolgens standaard wordt en mensen hier niet op inspelen kan WebKit niks aan doen.

WebKit is er altijd vroeg bij om standaarden te implementeren en dat kan ik alleen maar toejuichen. MS heeft jaren alleen maar achter alles aangehobbeld en de innovatie op het web jarenlang vertraagd doordat ze zoveel marktaandeel hadden maar niks implementeerden. Nu krijgen ze de rekening van die strategie.

Zowel touch events als box-shadow zijn W3C (candidate) standaarden die werken in WebKit; als ze gewoon ook werken in IE, wat is dan het probleem? Het hele probleem ontstaat volgens mij doordat MS weer dezelfde fout maakt: Nieuwe, spannende standaarden (zoals touch events) laat of helemaal niet implementeren. Vroeger ging de wereld dan wachten op MS, maar op mobile gaat dat feestje niet door.
Als je weet door wie het artikel is aangedragen (hAl) dn weet je ook eigenlijk wel weer genoeg...
Ben benieuwd hoe lang je dat nog zegt, Webkit is de nieuwe IE6...
Omdat Webkit zich niet aan de standaarden houd waardoor IE (en Gecko) worden buitengesloten. Probeer maar eens met background-gradient een gradiënt toe te voegen zonder prefix, in IE werkt het, voor Webkit: neen, daar heb je eerst een prefix nodig.
Webkit houdt zich wel aan de standaarden. Zolang het in ontwikkeling is moet er een prefix voor. De developers sluiten de rest uit door enkel webkit attributes neer te zetten en niet voor firefox en algemene specs. Want over een paar maanden zal de prefix misschien niet meer ondersteund worden omdat ze de officiele implementatie gebruiken.
De webdevelopers doen iets fout :)
Omdat de implementatie in webkit nog in ontwikkeling is/was moest je een -webkit- prefix ervoor zetten. Omdat webkit zo groot was, staat nu overal enkel met de webkit-prefix. Maar MS heeft t klaar en heeft geen prefix meer nodig. He, die is er niet, dus geen opmaak.

Developers hebben destijds dus ook geen rekening gehouden met Firefox Mobile, die heeft ook de -moz-prefix nodig. En omdat ze daar geen rekening mee hebben gehouden gaat het nu mis.

Ik doe altijd het volgende rijtje prefixes overal zodat het altijd werkt:
-webkit- (chrome/safari)
-moz- (firefox)
-khtml- (khtml browsers)
-o- (opera)
-ms- (ie)
[niets] (officieel)
Serieusly? IE houdt zich beter aan standaarden? Welke die van Microsoft? Het is een puinhoop daarzo. Bij iedere nieuwe versie is het maar gissen wat er nu wel of niet ondersteund wordt. IE 8 ondersteunde dingen wel die IE 9 niet ondersteund, en dat herhaalt zich bij IE 10. Microsoft heeft maar één belang bij IE10 en da's zoveel mogelijk ontwikkelaars voor Windows 8 of WP8 laten bouwen.

Check dit ff : http://html5test.com/compare/browser/chrome23/ie10/ff16.html

Wat mij betreft geeft Microsoft het na 17(!!!) jaar op, en omarmt Gecko of WebKit.
Het zegt al veel dat jij denkt dat die site iets zegt over standaardondersteuning.

Als je echt standaardsondersteuning wilt testen dan moet je hier wezen:
http://w3c-test.org/html/tests/approved/
Meer dan 11000 tests in de testsuite van W3C .

En daar scoort IE10 heel hoog.
Je bent bekend met het feit dat een aanzienlijk deel van die testen door MS zelf zijn aangedragen? Natuurlijk scoort MS dan goed. Ze testen de dingen waarvan ze weten dat ze het ondersteunen en testen niet waarvan ze weten dat ze het niet ondersteunen.
Als Internet Ontploffer 10 volgens Microsoft geheel aan de HTML5 standaard voldoet, is er toch niks aan de hand.

Een standaard is ook een standaard, maar die kun je als webdeveloper volledig negeren door voor alle properties webkit te zetten, zoals bijv:

-webkit-box-shadow
I.p.v.:
-box-shadow

Dan kan het advies toch alleen maar luiden: "Maak je website volgens de HTML5 standaard."
Ik gebruik vaak Lea Verou's prefix-free. Nergens meer vendor-specific prefixes, maar de standaard. Prefix-free zorgt ervoor dat, indien nodig, de prefixen er voor worden geplaats.

http://leaverou.github.com/prefixfree/
Zo simpel is het niet. Veel onderdelen van html5 staan nog steeds ter discussie of worden vaak verkeerd toegepast door ontwikkelaars. Denk aan de <nav> elementen of <header>, die zijn niet wat je denkt dat het is.

Daarnaast is er de css3, die zal meer verwarring geven. Het is natuurlijk niet slim om wel webkit-box-shadow te gebruiken en het officiele equivalent er niet onder te zetten, maar het is wel vaak gebeurd.

De browsers wars zijn terug van weggeweest, hopelijk minder destructief dan ooit. Wie zich aan standaarden wil houden moet ook zeer behoudend zijn in nieuwe features gebruiken omdat veel browsers die nog niet (goed) hebben geimplementeerd.

Verschillende partijen pushen hun voorstellen door ze gewoon te implementeren met een -moz of -webkit voorvoegsel. Als het veel wordt toegepast en goed blijkt te werken is het bijna onontkoombaar dat het op een of andere manier wordt geïmplementeerd door anderen. Webstandaarden zijn daarmee continue een soort 'rolling release'.

Over javascript heb ik nog maar gezwegen...
Het probleem op het moment is dat er veel nieuwe standaarden komen (en kwamen). Bv. de CSS3 "borders en background" module, deze schrijft dingen als border-radius en box-shadow voor. Hiervan is in ieder geval border-radius door de Webkit ontwikkelaars voorgesteld als standaard en Webkit had hier ook snel een implementatie van. Omdat border-radius echter nog nieuw was hebben de Webkit ontwikkelaars het niet helemaal volgens de door hun voorgestelde standaard ontwikkeld, maar hebben ze zoals het hoort dit gedaan door overal de -webkit prefixes te gebruiken (-webkti-border-radius in plaats van gewoon border-radius bv.). Dit omdat de standaard nog niet af was en er later ook nog wijzigingen hebben plaatsgevonden (op basis van de feedback van webdevs die -webkit-border-radius gebruikten, dit is AFAIK ook onderdeel van het standaardisatieproces). Nu heeft Webkit al altijd met -webkit-border-radius kunnen werken zoals ze toen de standaard hebben bedacht, en toen de standaard af was border-radius kunnen implementeren en er geen compatibility issues zijn tussen "webkits originele border-radius" en de officiele border-radius standaard (want de webkit versie heeft -webkit- ervoor staan).

Het probleem nu is echter dat veel sites alleen maar -webkit-border-radius gebruiken, en niet de officiële border-radius. Ondanks dat alle browsers, inclusief die met de webkit engine, al lang border-radius ondersteunen. Het probleem ligt dus bij de websites (/devs) die de CSS alleen voor een voorgestelde CSS standaard hebben geschreven (met bijbehorende vendor prefix), en later niet hebben geupdate naar de officiële standaard. Waar MS met IE toendertijd gewoon hun eigen standaard "verzon". En webdevs dus de keuze moesten maken tussen of IE ondersteunen, of de rest ondersteunen, of veel meer tijd steken in beide ondersteunen. Terwijl het nu grotendeels neerkomt op overal -webkit- verwijderen (de kleine verschillen tussen het eerste voorstel van de standaard en de uiteindelijke standaard daargelaten)
Firefox/Mozilla lossen dit op door lange tijd na de standaardisering van een CSS-property de prefix gewoon niet meer te laten werken. Zo werkt -moz-opacity bijvoorbeeld niet meer in nieuwere versies van Firefox (14+ geloof ik)
-moz en -webkit niet meer laten werken is op zich prima, maar 'it breaks the web'. Eigen schuld dikke bult kan je zeggen, maar dat geldt ook voor mensen die 'stuck' zitten/zaten met hun intranetje op IE6. Je kunt van die realiteit niet zomaar weglopen. Wie gaat er überhaupt nog werken met dat soort voorvoegsels wanneer ze plotseling buiten gebruik kunnen raken?
De prefixes worden gebruikt omdat een feature experimenteel is en nog geen CSS-standaard heeft. Het verwijderen van de prefixes stimuleert het gebruik van properties zonder prefix, en dat is wel degelijk beter voor het internet.

Overigens: als je site het niet doet zonder prefixes, dan doe je iets heel erg verkeerd. Hoe denk je bijv. dat je site bekijkt in Opera of andere browsers die niet een -moz- of -webkit--prefix gebruiken?
De prefixes worden gebruikt omdat een feature experimenteel is en nog geen CSS-standaard heeft. Het verwijderen van de prefixes stimuleert het gebruik van properties zonder prefix, en dat is wel degelijk beter voor het internet.
als een feature experimenteel is, waarom wordt er dan uberhaupt mee gerotzooit op productie sites die op internet terecht komen zonder fall back, dan heb je als developer geen enkele reden of excuus om een browser af te zeiken.
Welke developer is een browser maker aan het afzeiken dan?
En waarom zou ik als developer niet gebruik mogen maken van mooie features die een bepaalde browser biedt? Zolang alles nog bereikbaar is en werkt op alle browsers?

Bijvoorbeeld met box-shadow kun je een schaduwtje tonen, bijvoorbeeld onder een popup venstertje, uitklap menuutje of knop. Zonder die schaduw werkt het ook gewoon allemaal het ziet er alleen net wat minder gelikt uit. Dat heet progressive enhancement: Het werkt op alle browsers, maar waar beschikbaar worden ook verbeteringen gebruikt die het allemaal wat mooier of plezieriger werken maken.
Op zich ben ik wel voor het idee dat je gewoon de -webkit-box-shadow oid dropped als browser zijnde op het moment dat je box-shadow implementeerd. De ontwikkelaars worden dan gedwongen om in ieder geval de officiele tag in te voegen.

Voor de andere 'expirimentele' browsers (-moz e.d) kan de developer dan zelf voor kiezen.
Het grootste probleem is -webkit-, de irritantste manier van CSS die ooit is bedacht, browser specifieke prefixen... Bij IE kan je het doen met -ms-, maar maar het werkt even goed zonder prefix, maar dan weigert Webkit dienst.
Onderbouwing graag. Welke code werkt wel goed in WebKit met, maar niet zonder prefix?
Je kunt gewoon box-shadow gebruiken hoor. Werkt prima in WebKit.

Wat juist super irritant is, is browsers die een property 'claimen' door er gewoon al gedrag aan te hangen terwijl de discussie erover (in het standaardisatieproces) nog gaande is. Vervolgens kunnen ze een jaar later zeggen dat het niet meer veranderd kan worden omdat er al sites gebruik van maken en een verandering het web zou breken.

Het hele systeem met prefixen wordt juist door W3C aangeraden en Opera, Firefox, Google / Apple en Microsoft houden zich er allemaal aan, juist omdat het slim en logisch is om het zo te doen. Eerst overeenstemming bereiken over hoe het zich moet gedragen en dan pas de wijde wereld in slingeren.

Iedereen die -webkit- ervoor zet snapt meteen dat dat niet cross-browser is. Of men dan besluit daar schijt aan te hebben omdat men zich toch alleen op iPhone gebruikers wil richten is hun eigen keuze. Nu werkt hun site niet op IE10. Jammer dan. Wat betreft de touch events is het MS die dom bezig is. Als deze standaard al zoveel gebruikt wordt (en gewoon door W3C wordt omarmd) ondersteun hem dan gewoon! Ik kan me niet aan de indruk onttrekken dat het gebrek aan ondersteuning hiervan in IE10 geen technische keus is maar een politieke; als ze die standaard wel ondersteunen dan maakt hun alternatieve pointer API geen schijn van kans. Door de ondersteuning weg te laten dwingen ze web developers om of IE10 niet te ondersteunen wat betreft touch, of toch voor de pointer API code te schrijven. We zullen zien wat ze kiezen. Maar ik vind het een riskante gok van MS.
Een belangrijke css3 vernieuwing is het box-model. Daarbij werken de meeste css3 tags (display:box of box-flex) niet zonder -webkit- voorvoegsel. IE heeft er geen probleem mee, maar het breekt wel je hele website als je het niet invoegt
Een goede ontwikkelaar heeft natuurlijk altijd een prefix gebruikt en de versie zonder prefix van een CSS statement. Een goede ontwikkelaar... ;)
Nee, dat is juist een kenmerk van een slechte ontwikkelaar. Zie bijvoorbeeld de CSS gradients, daar hadden webkit en gecko verschillende notaties. Uiteindelijk is de gecko-notatie gestandaardiseerd, en daardoor hadden veel ontwikkelaars dus verkeerde code in hun CSS staan. Het hele idee van prefixes is dat dat voorkomen wordt. ;)
Het lijkt mij evident dat goede ontwikkelaars er van op de hoogte zijn wanneer webkit en gecko verschillende notaties gebruiken, en dus ook kunnen inschatten wanneer een prefix loze versie niet verstandig is.
Wat ie volgens mij bedoeld (maar verwarrend neerzet) is dat ie gewoon alle prefixes heeft genoteerd. Dus -webkt- -moz- -ms- -o- en de normale regel. Dus dan krijg je 5 regels voor het toepassen van box-shadow op een enkel element
klopt, maar goed dat is de concequentie als je met expirementeel spul werkt.
Hoort er gewoon bij
Maar zolang het dus nog niet een standaard is zou de non-prefix variant in geen enkele browser moeten werken.
Microsoft houd zich dus toch weer niet aan de standaarden, als je kijkt naar touch events. Ms gaat hier zichzelf enorm in de vingers snijden. Het feit dat IE10 beter voldoet aan HTML5 standaarden is fijn, maar toch nog grotendeels marketingpraat, aangezien IE10 nog altijd mijlenver achterloopt op Chrome en Firefox.
Ik weet niet welk artikel jij aan het lezen bent, maar in dit artikel staat dit:
Hoewel de W3C een candidate recommendation-status heeft gegeven aan touch events, wil de organisatie Microsofts pointer events als uiteindelijk standaard gaan ontwikkelen, mede omdat deze ook samenwerkt met muis- en stylusinput.
Of te wel, er is nog geen standaard, maar dat word naar alle waarschijnlijk de gene die Microsoft nu heeft gekozen. Niet omdat Microsoft die heeft gekozen, maar omdat die ook met muis- en stylusinput werkt ... is wel zo gebruiksvriendelijk tenslotte voor de bezoeker van je website die geen touchinput heeft ;)
In dit geval kijkt Microsoft dus gewoon goed vooruit.

[Reactie gewijzigd door TMDevil op 18 november 2012 14:53]

Waarom beginnen de eventnamen dan met MS?
Omdat net als bij CSS je een prefix gebruikt tot het een standaard is.
Maar die eventnamen blijven dus tot de einden der dagen in gebruiken hierdoor. En omdat de eventnamen zonder prefix nog nergens gebruikt worden, had dat best gekund. Zeker als Microsoft (mede) deze standaard bedenkt.
Of te wel, er is nog geen standaard, maar dat word naar alle waarschijnlijk de gene die Microsoft nu heeft gekozen.
Het artikel is niet heel duidelijk hierover, dus ik zal je niet van slecht lezen betichten (vind ik sowieso niet netjes om te doen) maar je conclusie klopt in elk geval niet. Het W3C gaat echt geen standaard 'candidate recommendation' status geven om hem daarna weer af te schieten. Zo werkt dat niet.

De Touch Events API is here to stay. Zeker omdat dit inmiddels de de facto standaard is die al door een miljard devices wordt ondersteund. De Pointer Events api is vooralsnog alleen een voorstel:
This document was published by the Microsoft Corporation as a Member Submission.

By publishing this document, W3C acknowledges that the Submitting Members have made a formal Submission request to W3C for discussion. Publication of this document by W3C indicates no endorsement of its content by W3C, nor that W3C has, is, or will be allocating any resources to the issues addressed by it. This document is not the product of a chartered W3C group, but is published as potential input to the W3C Process.
Oftewel wat gebeurt hier? Er is een bestaande, werkende, breed ondersteund API voor touch events, die in de één na laatse fase van standaardisatie zit. Microsoft kiest ervoor om deze niet te implementeren. In plaats daarvan doen ze een voorstel, de allereerste fase van het standaardisatie proces, en het is maar zeer de vraag of hun voorstel het daadwerkelijk tot (candidate) recommendation zal schoppen. Daarvoor moeten ze eerst nog langs Working Draft, Candidate Recommendation en Proposed Recommendation. Pas bij candidate recommendation is een standaard een beetje stabiel en is de kans dat hij nog afvalt echt klein geworden, maar MS vraagt nu van web developers om in plaats van (of naast) de Touch Events candidate recommendation ook maar support in te bouwen voor een Submission?
Het W3C gaat echt geen standaard 'candidate recommendation' status geven om hem daarna weer af te schieten. Zo werkt dat niet.
En daarom gebruiken ze zeker ook de extreem voorzichtige benaming 'candidate recommendation'. Het is geen standaard, het is een recommendation. Oh nee, wacht, het is niet eens een recommendation. Het is een candidate recommendation. En ik ben kandidaat kanshebber om de loterij te winnen :Y)
Klopt helemaal en het is nu breed toegepast omdat men nou eenmaal een functionaliteit wilde gebruiken, ongeacht of het een standaard was.

[Reactie gewijzigd door Martinspire op 19 november 2012 00:43]

En daarom gebruiken ze zeker ook de extreem voorzichtige benaming 'candidate recommendation'.
Wie W3C kent weet dat dat (voor hun begrippen) geen voorzichtige benaming is. Het betekent: Zolang we geen ernstige fouten meer vinden wordt dit de 'recommendation'. Voor alle spullen van W3C kun je recommendation effectief gewoon vervangen door 'standard'. Dit is de de candidate standard.

Als je zo redeneert als jij zijn zaken zoals TCP, POP, SMTP etc ook geen standaarden maar slechts verzoeken tot commentaar, want RFC staat voor Request For Comment. Alsnog zijn dit wel degelijk standaarden.
De HTML5 onderdelen die Chrome en Firefox wel ondersteunen en IE10 niet zijn nog niet gestandaardiseerd, IE10 is, en dat is een feit leer er mee leven, nu de browser die zich het best aan de standaarden houdt.
Door een versie van een feature te implementeren die nu slechts de status 'Submission' heeft in plaats van de bestaande versie, die 'Candidate Recommendation' status heeft te implementeren?

De Touch Events api is hoe je het ook bekijkt méér standaard dan de implementatie van MS, ook wat marktaandeel betreft. De desktop zal MS hier niet helpen want die hebben geen touch (op wat uitzonderingen na).

EDIT: spelfoutje

[Reactie gewijzigd door OddesE op 18 november 2012 23:01]

Gebruikelijk != standaard. Dat iets veel gebruikt wordt, maakt het nog geen standaard. Als de standaard (of vereiste) voor een toets het cijfer 6 is, maar iedereen haalt een 7 dan is de standaard niet ineens 7.

Het was ook nog geen standaard, want het was een kandidaat voorstel
Waar gebruik ik het woord 'gebruikelijk'?

En het is geen kandidaat voorstel maar een candidate recommendation. Recommendation betekent aanrader of advies. Voor zover het het W3C aangaat zijn 'standaard' en 'recommendation' gewoon uitwisselbaar. Er is geen hogere autoriteit op het web dan het W3C en er is geen hogeer status voor W3C documenten dan 'recommendation'.

Verder is het bij de meeste toetsen wel degelijk zo dat als de meeste mensen een hoog cijfer halen dat de norm dan verschuift. En bij techniek is het zeker zo dat als iets veel gebruikt wordt dat het dan een 'de facto' standaard is.

Hoe je het ook wendt of keert: Beide api's liggen bij W3C. Touch heeft én een hogere status én meer implementaties. Dus is het ook meer standaard.
Er wordt al langer gewaarschuwd dat Webkit de nieuwe IE6 aan het worden is. Deze discussie is interessant en toont duidelijk aan dat het een meer is dan een loze kreet. Lees vooral het stukje over vendor prefixes.

Enkele quotes:
tantek: At this point we're trying to figure out which and how many webkit
prefix properties to actually implement support for in Mozilla
tantek: Currently we have zero. Zero is no longer an option for us.
Florian: I found on the rough analysis of top 1000 websites, several percent
use webkit prefixes without a fallback for others.
Florian: Regardless of how we ended up here, if we don't support webkit
prefixes, we are locking ourselves out of parts of the mobile web.
Tab: Given the discussion is about webkit being a monoculture on Mobile, if
webkit decides to remove a prefix then it's okay for everyone to remove
prefixes also.
Florian: Some prefixes will not be dropped by webkit
glazou: None will be dropped.
Men (Mozilla, Opera en Microsoft) spreekt over het feit dat Webkit zo dominant is geworden, dat zij verplicht zijn om -webkit- prefixes te implementeren. Maar dat op hetzelfde moment het gebruik van prefixes zo ingeburgerd is (vaak zonder fallback), dat het laten vallen van support daarvoor teveel websites zou breken. Dus we zitten gewoon terug waar we ooit zaten met IE6.

Dat is trouwens niet de schuld van browser-makers. We hebben het gewoon aan onszelf te danken. Blijkbaar is er uit het verleden niets geleerd.

[Reactie gewijzigd door Alfredo op 18 november 2012 15:02]

De browsermakers, en dan vooral het Webkit team, zij zijn ermee begonnen, hadden gewoon nooit mogen beginnen aan dat prefix gedoe, of ze hadden het zo moeten doen als Microsoft, zij implementeren het pas als de prefix niet meer nodig is.
En hoe moet de boel dan getest worden?
Die prefixen zijn er juist om de standaarden in real life te testen!

prefix == not stable yet
Gelukkig is WebKit opensource, klein maar essentieel verschil.
Hmmmja postback scripts met javascript werken dus niet in IE10 (zowel desktop als metro). Veel .NET sites zijn nu dood zonder een fix in IE10.
Hier is al tijden een fix voor uit. Hanselman heeft er zelfs nog over geblogged:
http://www.hanselman.com/...FF5ScrollbarPosition.aspx

Wel even bijblijven met updates, hè? ;)
Juist. :)

Ik doe zelf alleen front-end :) ik schrok nogal toen ik een paar sites aan het testen was. De programmeurs mogen het zelf gaan fixen :D

Bedankt voor link.
Door je code goed en toekomstbestendig op te zetten, is de hoeveelheid werk die je moet steken in ondersteuning van nieuwe browsers als IE10 minimaal. Qua CSS houden slimme ontwikkelaars sowieso al rekening met de standaardnotatie + de relevante browserspecifieke notaties. Hiermee blijft de declaratie werken ongeacht welke variant ervan door een specifieke browser wordt gebruikt. Qua css3 en html verwacht ik dus weinig problemen; IE10 is op dat gebied vooral een zegen, geen vloek.

Lastiger wordt het met de javascript touch events en wellicht ook zaken als html5-storage, waarvoor verschillende standaarden bestaan. Daarbij blijft het goed uitkijken en onderzoeken wat werkt voor welke browser, wat je wilt ondersteunen en tot in hoeverre. Dat is een nadeel aan de constant veranderende wereld van webtechnologie.

Als ik dan hierboven lees dat .NET-sites problemen gaan krijgen met IE10, moet ik toch gniffelen. De standaard controls en output die asp.net gebruikt lijken compleet lak te hebben aan semantiek van de html, javascript vind je werkelijk overal terug op vrij ranzige manieren, formulier-afhandeling heeft Microsoft helemaal in Javascript gedaan, enz. Die taal is vooral ontworpen vanuit de gedachte van offline software en vervolgens toegepast in de browser. Dus geen wonder dat toekomstbestendigheid dan een probleem is. Gelukkig zijn er manieren om de output zelf te bepalen, door eigen controls te schrijven of .NET MVC te gebruiken. Ik zou niet graag al die massale bloatware .Net apps moeten aanpassen voor IE10, een Microsoft eigen browser nog wel :)
Steek tijd in een CSS converter (mod-rewrite). Ik maak bijvoorbeeld mijn websites op voor mozilla (dus met -moz ervoor). Zodra het van de server komt gaat het eerst door een klein scriptje dat alle prefixes checkt en indien mogelijk kijkt naar de useragent. Dan worden de rules aangepast of uitgebreid voor de browser die het opvraagt en bovendien het attribute zonder prefix wordt toegevoegd. Bijvoorbeeld ook gradients (dat niet in IE9 wordt ondersteund) wordt automatisch omgezet naar embedded SVG. Daarnaast is er voor gradient voor sommige wat oudere webkit versies een andere syntax nodig en die wordt ook automatisch omgezet.

Voordeel:
1) Hoef je niet al die specifieke prefixen op te geven.
2) Je CSS bestand blijft overzichtelijk
3) Bij twijfel schakelt het script alle prefixen in (-o -ms -moz -webkit) inclusief zonder prefix
3) Het CSS bestand is kleiner (is ook geminified)
4) Als er een fout zit in de conversie hoef je dus niet de CSS bestanden aan te passen alleen het script.

Ik heb mijn script nog enkel probleem meegemaakt, het werkt altijd! Ziet er perfect uit. Zelfs onder Internet Explorer :)

En wat de touch events betreft, daar is ook een oplossing voor. Op stackoverflow staat een oplossing voor het mousedown, mouseup, mousemove probleem dat niet werkt op een mobiel apparaat. Het scriptje vertaald touchevents naar mouseclicks zodat je website altijd werkt, ik heb het zelfs uitgebreid met een doubleclick. Dat betekend dus dat je niet hoeft te rommelen met al die events, ze worden automatisch omgezet. Klein stukje:

// https://developer.mozilla.org/en/DOM/event.initMouseEvent for API
var touch = e.changedTouches[0], newEvent = document.createEvent("MouseEvent");
newEvent.initMouseEvent(o.data.touchTypes[e.type], true, true, window, 1,
touch.screenX, touch.screenY,
touch.clientX, touch.clientY, false,
false, false, false, 0, null);

touch.target.dispatchEvent(newEvent);

NB: Het is natuurlijk wat anders als je de specifieke gestrures wilt gebruiken, dan moet je dit niet doen maar over het algemeen is dat heel prettig. En als MS komt met die nieuwe implementatie kun je dat in de code aanpassen. Klaar!

[Reactie gewijzigd door Erwines op 19 november 2012 06:16]

Bedankt voor de uitgebreide info! Er bestaan inderdaad allerlei css-preprocessors, maar ik wilde even het concept van progressive enhancement en futureproof maken toelichten hierboven. Dat kun je voor css inderdaad automatiseren (server-side, client-side of één keer compilen en dan online plaatsen, zijn allerhande tools voor).
Persoonlijk vind ik dat de vergelijking met IE6 hier helemaal niet opgaat.

Het verschil tussen toen en nu is dat MS zich niet hield aan de standaard, terwijl nu webkit als standaard is verworden. Daarmee had MS ook kunnen zeggen, wij conformeren ons ook aan webkit zodat we gewoon 1:1 werken met Google en Safari.
Alleen is webkit geen standaard. Het is wel veel gebruikt, maar geen standaard.
Boeit me niet, ik ga toch nooit IE ondersteunen zolang het standaarden blijft negeren.
Leuk dat jij altijd zelf mag beslissen wat je ondersteunt. De meeste ontwikkelaars moeten zich echter houden aan de wensen van opdrachtgevers, werkgevers en bovenal eindgebruikers :)
Ik stel voor dat MS gewoon stopt met het ontwikkelen van IE en afschaft.
Dan zijn de problemen over "standaarden" opgelost.

Ze mogen dan wel een ommezwaai gemaakt hebben. Het recht om in de eerste 10 jaar nog iets in dat segment te zeggen of te bepalen hebben, is misplaatst na alle miserie die ze webdevelopers en open standaarden vele jaren berokkend hebben.
Het is zeker waar dat Microsoft het in het verleden flink verpest heeft met IE, en ze de ontwikkeling van het internet als medium zelfs hebben vertraagd en soms ontspoord. Maar MS gaat toch niet opgeven, en zal ook niet overstappen op webkit. Ze zijn nu in elk geval een stuk beter bezig dan 10 jaar terug: Sneller nieuwe releases uitbrengen en meer standaarden ondersteunen. Ik denk dat we met IE10 en 11 eindelijk een redelijk gelijkvloerse browsermarkt krijgen. IE zal nu naar verwachting ook bijblijven en niet opnieuw achter gaan lopen. Op het gebied van hardwareversnelling doen ze het zelfs erg goed, zoals ik heb begrepen.

Kunnen we in 2014 misschien eindelijk eens iets efficienter werken ;)
Het is zeker waar dat Microsoft met iedere nieuwe IE versie beter de webstandaarden ondersteund. Dat is echter het hele issue niet. Het issue is dat Microsoft geen auto-updating browser heeft.

Dat betekent dat ten aller tijde de IE gebruikersgroep verdeeld is over meerdere versies, van IE6 - 10, met de nodige ellende voor developers. Hoe goed IE10 ook is, zolang deze niet automatisch bijgewerkt wordt, is het wederom een versie in isolatie waar developers rekening mee moeten houden. Over 1 jaar loopt IE10 weer achter, maar zullen developers deze versie nog jaren moeten ondersteunen. Die ondersteuning wordt door betere standards support weliswaar steeds makkelijker, maar dit probleemt speelt nauwelijks bij Chrome, FF en Safari, welke (semi) automatisch nieuwe versies uitrollen.

Het denken in baselines van zowel de standaard (HTML4, 5) als in browser versies moet van de baan. De standaard is levend, niet statisch en ditzelfde zou voor browsers moeten gelden.

Sterker nog, HTML5 bestaat helemaal niet. Technisch gezien heet het HTML, en het is een levende standaard die continu bijgewerkt wordt. Stop dus met het wachten tot HTML5 "klaar" is, want dat moment gaat nooit komen.

FF en de webkit boys snappen dit, Microsoft nog niet.

Op dit item kan niet meer gereageerd worden.



Apple iPhone 6Samsung Galaxy Note 4Apple iPad Air 2FIFA 15Motorola Nexus 6Call of Duty: Advanced WarfareApple WatchWorld of Warcraft: Warlords of Draenor, PC (Windows)Microsoft Xbox One 500GBWebsites en communities

© 1998 - 2014 Tweakers.net B.V. Tweakers is onderdeel van De Persgroep en partner van Computable, Autotrack en Carsom.nl Hosting door True