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.
[Reactie gewijzigd door Eagle Creek op zondag 18 november 2012 14:44]
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.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 [..]
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.MS moet zorgen dat code die op WebKit werkt (voor zover niet WebKit specifiek, wat met de Touch event API niet het geval is)
[Reactie gewijzigd door David Mulder op maandag 19 november 2012 00:45]
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.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
[Reactie gewijzigd door hAl op maandag 19 november 2012 08:10]
[Reactie gewijzigd door Texamicz op zondag 18 november 2012 20:15]
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.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.
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 heeftHoewel 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.
[Reactie gewijzigd door TMDevil op zondag 18 november 2012 14:53]
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.Of te wel, er is nog geen standaard, maar dat word naar alle waarschijnlijk de gene die Microsoft nu heeft gekozen.
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?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.
[Reactie gewijzigd door Martinspire op maandag 19 november 2012 00:43]
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.
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.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.
[Reactie gewijzigd door Alfredo op zondag 18 november 2012 15:02]
[Reactie gewijzigd door Erwines op maandag 19 november 2012 06:16]
Op dit item kan niet meer gereageerd worden.
Populair: Tablets Samsung Websites en communities Mobiele telefoons Google Apple Microsoft Sony Games Politiek en recht
© 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