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 , , reacties: 71, views: 19.969 •
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
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]

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.
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.
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)
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. ;)
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?
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]

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Ť? ;)
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]

Op dit item kan niet meer gereageerd worden.



Populair: Vliegtuig Luchtvaart Crash Smartphones Laptops Apple Games Politiek en recht Besturingssystemen Rusland

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

Beste nieuwssite en prijsvergelijker van het jaar 2013