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.884 •
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
Gelukkig doet iedere normale webdeveloper het volgende:

.boxshadow{
-webkit-box-shadow: 0 1px 3px #9e9e9e;
-khtml-box-shadow: 0 1px 3px #9e9e9e;
-moz-box-shadow: 0 1px 3px #9e9e9e;
-ms-box-shadow: 0 1px 3px #9e9e9e;
-o-box-shadow: 0 1px 3px #9e9e9e;
box-shadow: 0 1px 3px #9e9e9e; /* De officiele standaard altijd als laatste */

[Reactie gewijzigd door sfranken op 19 november 2012 15:24]

Nog beter, in Compass: @include box-shadow(bla), en er vervolgens niet meer naar omkijken. Uiteraard wel de CSS netjes gzippen en agressief cachen.

Edit: ik zie nu pas dat je de boxshadow styles in een class selector propt. Persoonlijk ben ik hier erg op tegen, aangezien dit betekent dat je in feite styles in je HTML stopt. Ik begrijp dat het praktisch kan zijn maar ik ben toch meer een purist.

[Reactie gewijzigd door Fledder2000 op 19 november 2012 16:16]

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

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

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.
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. ;)
Maar zolang het dus nog niet een standaard is zou de non-prefix variant in geen enkele browser moeten werken.
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
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.

Op dit item kan niet meer gereageerd worden.