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

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
Een goede ontwikkelaar heeft natuurlijk altijd een prefix gebruikt en de versie zonder prefix van een CSS statement. Een goede ontwikkelaar... ;)
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.
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 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]

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

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.
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)
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/
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Ť? ;)
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. ;)
Waarom beginnen de eventnamen dan met MS?
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.
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.
Omdat net als bij CSS je een prefix gebruikt tot het een standaard is.
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)

Op dit item kan niet meer gereageerd worden.



Populair: Tablets Nokia Websites en communities Lumia Smartphones Laptops Sony Apple Games Politiek en recht

© 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