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

Omdat net als bij CSS je een prefix gebruikt tot het een standaard is.
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?
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]

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]

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).

Op dit item kan niet meer gereageerd worden.



Populair:Apple iPhone 6DestinyAssassin's Creed UnityFIFA 15Nexus 6Call of Duty: Advanced WarfareApple WatchWorld of Warcraft: Warlords of Draenor, PC (Windows)Microsoft Xbox OneApple iOS 8

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

Beste nieuwssite en prijsvergelijker van het jaar 2013