Microsoft wil pointer events-api porten naar Chrome-browser

Microsoft wil zijn pointer events, een api om verschillende manieren van gebruikersinput in een browser te verwerken, porten naar de Blink-engine van Googles Chrome-browser. Tot nu toe is de technologie alleen in Internet Explorer 10 te vinden.

De pointer events-api is momenteel alleen beschikbaar in de IE10-browser die in Windows 8 en Windows Phone 8 is te vinden. Via de technologie kan in een browser gebruikersinput afgehandeld worden die afkomstig is van de muis, een touchscreen of het toetsenbord. Ook zou de api door een hoge mate van abstractie in staat zijn om toekomstige invoermethodes te verwerken.

Microsoft poogt van pointer events een webstandaard te maken. Met behulp van de W3C, de organisatie die verantwoordelijk is voor een groot aantal open webstandaarden, is onlangs een release candidate uitgebracht van de specificatie. Daarnaast heeft Microsoft een ruwe implementatie voor WebKit-browsers ontwikkeld, maar de softwaregigant hoopt de technologie een groter bereik te geven door samenwerking te zoeken met Chrome-developers. Op de Blink-mailinglist was onlangs te lezen dat Microsoft de code wil porten naar Blink, de webengine van de Chrome-browser.

Hoewel de Chrome-developers nog het groene licht moeten geven aan de integratie van pointer events in de Blink-engine, zou de api goed zijn ontvangen. Bovendien lijken tal van partijen de technologie te willen gaan gebruiken, waaronder Adobe, de jQuery Foundation en Mozilla.

Reacties (34)

[Nafets]

Dat is nog eens goed nieuws, erg handige api. Gebeurt toch best vaak dat on mouse over elementen niet lekker werken op telefoon of tablet.

[BLACKfm]

Dat lijkt me meer gerelateerd aan de manier van bediening. Met een touchscreen verplaatst je niet echt de cursor. Ik heb bijvoorbeeld een Note 2 en daar kan je met de stylus een muiscursor nadoen en daar werkt de mouseover functionaliteit anders prima mee.

Met je vinger doen alsof je de cursor verplaatst heeft meestal het effect dat je over de pagina scrolt. Je kunt dat effect dus nagenoeg niet evenaren als je geen fysieke muis of nieuwe features hebt zoals je vinger boven het scherm houden.

[Nafets]

Dat lijkt me meer gerelateerd aan de manier van bediening. Met een touchscreen verplaatst je niet echt de cursor. Ik heb bijvoorbeeld een Note 2 en daar kan je met de stylus een muiscursor nadoen en daar werkt de mouseover functionaliteit anders prima mee.

Met je vinger doen alsof je de cursor verplaatst heeft meestal het effect dat je over de pagina scrolt. Je kunt dat effect dus nagenoeg niet evenaren als je geen fysieke muis of nieuwe features hebt zoals je vinger boven het scherm houden.

Het gaat niet over het na bootsen van de muis, maar over het aanbieden van een alternatief. Dit zonder dat een developer er veel moeite hoeft te doen en voor elk alternatieve input methode nieuwe code hoeft te maken. Dus in het hover voorbeeld zou de api kunnen zorgen dat het menu zichtbaar blijft als je op het menu gedrukt hebt op een telefoon of tablet.

[Toettoetdaan]

Best fijn van MS, nu heb je een JS library nodig om b.v. touch input uniform te kunnen gebruiken.

Hammer.js erg prettig als je het nodig hebt http://eightmedia.github.io/hammer.js/

[Martinspire]

Al lijkt die niet helemaal feilloos (de responsive versie van tweakers gebruikte ook hammer.js maar sloopte daarmee het scrollen op de pagina in de IE10 browser van Windows Phone).

[Verwijderd]

Daar staat een puntje over in de wiki!
https://github.com/EightM...mer.js/wiki/Tips-&-Tricks

[Verwijderd]

Hoe komt dat dan? Handelt IE10 dan niet goede de javascript af ?

[Boborc]

alleen beschikbaar in de IE10-browser die in WIndows 8 en WIndows Phone 8 is te vinden

IE10 komt al via de automatische updates van Windows 7 binnen en wordt standaard geïnstalleerd, even ter info.

[Martinspire]

Mja imo erg fijn. Hoef je alleen pc's met XP of lager maar van alternatief te voorzien (als je daar al ondersteuning voor wilt toevoegen).

Maakt HTML5 wat toegankelijker en beter bruikbaar voor webontwikkelaars.

[DrCake]

Goede zet van Microsoft,
Veel betere reclame dan al die scroogled filmpjes.

[sebasmac]

Een goede zet..!

[Martinspire]

Inderdaad. Vind hem zelf fijner werken dan de huidige implementatie in Chrome. Blijkt maar weer dat die toch te snel zijn geweest met het implementeren van een techniek die het nu lijkt af te leggen tegen een andere techniek. Wel jammer dat een heleboel websites al de Chrome manier zijn gaan implementeren waardoor je weer in de knoop gaat komen met backwards compatibility. Benieuwd wat de reactie is.

[SunnieNL]

Je bedoelt de webkit methode die veel websites al gebruiken omdat ze dachten dat dat de standaard was of zou worden ... ?

[i-chat]

ik neem aan dat je experimentele features, niet zodanig in je website code plaatst dat ze onmisbaar of onontkoombaar zijn... stel je voor dat de standaard (die immers nog in ontwikkeling is) bij een volgende update NET iets anders in elkaar zit ...

onwikkelaars moeten zich gewoon realiseren dat ze hun code dusdanig opzetten dat dit soort features vervangen kunnen worden door andere versies of geheel andere functies...

je kunt wel altijd voorop willen lopen maar dan krijg je ook de volle laag als het eens tegen zit,
je kunt dan moeilijk gaan klagen omdat je zelf te vroeg bent ingesprongen.

[Dreamvoid]

HTML5 is nog niet final, en toch zijn er ladingen websites die het al gebruiken, die kunnen niet zo makkelijk meer terug.

[tuXzero]

Daarom weeg ik elke HTML5 feature apart. Misschien is het handig voor HTML5 om iets soortgelijks als NodeJS zijn stability index te maken. Dan kunnen ontwikkelaars nog makkelijker oordelen of ze een bepaalde feature uit HTML5 willen gebruiken.

[jay03]

Dit bestaat inderdaad ook voor html5. Zie http://caniuse.com/#feat=touch

[R-J_W]

Dat is een de 'andere' implementatie.
http://www.w3.org/TR/touch-events/

Het voorstel vanuit Microsoft zoals genoemd in dit artikel.
http://www.w3.org/TR/pointerevents/

@tuXzero de 'stabiliteitswaardering' wordt door de W3C gegeven met de aanduidingen:
Recommendation
Volgens de W3C af, zeg maar de 'standaard'. Let wel, dit zegt weinig over de daadwerkelijke implementatie bij browsers.
Proposed Recommendation (Touch Events)
Candidate Recommendation (Pointer Events)
Working Draft
Zie ook: http://www.w3.org/2005/10/Process-20051014/tr#q74

Wat caniuse.com hieraan toevoegt is een overzicht van ondersteuning door de verschillende browsers.
Ontwikkelaars zullen vervolgens zelf, op basis van hun doelgroep, moeten besluiten of en hoe ze een feature willen gebruiken.

[tuXzero]

Een handige site. Maar, zover ik zag, wordt er geen waardering voor stabiliteit gegeven.

[Loller1]

Volgens mij bestaat zoiets al voor HTML5 en CSS3 (en alle andere niet voltooide standaarden) op de website van het W3C. Ik kan niet zo direct zeggen waar.

[Martinspire]

Van een heleboel code is echter al wel een hogere status dan deze. Dit is nog redelijk experimenteel en zou daarom ook nog helemaal niet aan een browser toegevoegd moeten worden, laat staan zonder developerbeperking worden geïmplementeerd.

[Blokker_1999]

Tuurlijk wel, Google maps maakt er bijvoorbeeld ook gebruik van, was ook de reden waarom Google een tijd terug zo moeilijk deed over maps op de mobiele IE versie, omdat IE gebruik maakt van pointer events ipv googles eigen standaard. Het is dan ook te hopen dat Google deze standaard zal implementeren in zijn browsers en sites zodat we in de toekomst weer iets hebben dat door iedereen gebruikt kan worden ipv browserafhankelijke oplossingen.

[Verwijderd]

De beste standaard moet gewoon geïmplementeerd worden. Of dat nou die van Google is of die van Microsoft. Niemand kan echt zeggen welke nou beter is.

[arendjr]

De beste standaard is degene die werkt. Apple is degene die touch events gepionieerd heeft, en omdat ze dat in WebKit hebben geimplementeerd heeft Chrome het ook opgepakt. Bovendien is Safari nog altijd de meest gebruikte mobiele browser, dus het is logisch dat deze implementatie de de facto standaard werd.

Waar het eigenlijk pas fout ging was dat Apple niet samen wilde werken met het W3C om hun implementatie echt te standaardiseren omdat ze hun relevante patenten niet vrij wilden geven. Dat, plus het feit dat de Pointer Events API een universeel model biedt voor zowel mouse als touch interfaces, zorgt ervoor dat Pointer Events de meest gewenste weg vooruit is, maar het zal nog wel even duren voordat dat in de praktijk ook betere ondersteuning krijgt dan de Touch Events API.

Apple zal nog wel een tijd dwars blijven liggen, voornamelijk omdat ze het zich kunnen permiteren. Maar als ze te lang achter blijven riskeren ze inderdaad dat Safari steeds meer de reputatie van mobiele IE6 gaat krijgen...

@R-J_W: Logisch dat je geen Apple-namen daar vindt, aangezien Apple niet wilde meewerken met het W3C. Dat neemt niet weg dat Apple de eerste was die het implementeerde en dat de draft van het W3C gebaseerd was op Apple's implementatie. Uiteindelijk is het nooit verder gekomen dan draft status omdat Apple ook de patenten niet wilde vrijgeven. (edit: Zie net in je post hierboven dat ie vorige week toch de status van proposed recommendation heeft gekregen. Dat had ik niet verwacht en vraag me dan ook af wat er met de patentsituatie gebeurd is. Het is sowieso een beetje vreemd aangezien het W3C nu dus beiden tot standaard lijkt te willen verheffen, maar goed, we zulln zien )

De reden om dwars te liggen lijkt mij (slechts speculatie, want daar doet Apple zelf natuurlijk geen uitspraken over) om een hefboom te hebben tegen partijen als Nokia die al heel veel patenten hebben op essentiele zaken zoals 3G en vele andere mobiele technologieen. Apple heeft dat niet als laatkomer in de mobiele markt en moet dus ergens anders aan z'n patenten zien te komen, immers als je geen stapels patenten hebt speel je (helaas) niet mee aan de top. Tevens zou Apple niks winnen door een alternatieve API te implementeren die eigenlijk alleen ten goede komt van hun concurrenten, dus ze zullen zichzelf simpelweg afzijdig houden tot ze er eigenlijk niet meer omheen kunnen.

[Reactie gewijzigd door arendjr op 24 juli 2024 03:22]

[R-J_W]

Geen Apple namen bij het HTML5 Touch Events voorstel.
Alle Editors tot nog toe:
Doug Schepers, W3C
Sangwhan Moon, Opera Software ASA
Matt Brubeck, Mozilla
Arthur Barstow, Nokia

Wanneer Pointer Events in Webkit geïmplementeerd is kan Apple dat zonder moeite één op één overnemen ... niet echt een reden om dwars te liggen.
Ze kunnen er altijd voor kiezen om ook Touch Events te blijven ondersteunen voor backwards compatibility.

[badboyqxy]

en hoe gaat het met de iOs gebruikers? en bijv. de opera gebruikers moeten die zelf maar een oplossing hiervoor verzinnen?

[Loller1]

Deze functionaliteit is al geport naar Webkit (Safari -> iOS) en wordt nu dus geport naar Blink (Chromium -> Alle Chromium klonen).

[Veneficus]

Ik heb geen verstand van browser coding, maar begrijp ik goed dat ik dan eindelijk de mouse-overs van XKCD kan lezen op mijn telefoon (HTC One X, Chrome Mobile)?

[Kompaan]

Geen idee, maar dat is ook altijd een probleem op mijn Androids...

[BramVroy]

Is het niet zo dat Blink pas de toekomstige engine is van Chrome? Vooralsnog gebruikt ie bij mijn weten nog altijd de Webkit engine terwijl het artikel anders doet vermoeden.

[R4gnax]

Vanaf Chrome 27 wordt Blink al gebruikt, vziw.
En die draait op het moment in het beta release channel.

[Reactie gewijzigd door R4gnax op 24 juli 2024 03:22]

[mutley69]

Microsoft wil ook chrome vergiftigen met Intellectual property - da's duidelijk de strategie. Eerst schenken nadien de nek omwringen.

[R4gnax]

Microsoft wil ook chrome vergiftigen met Intellectual property - da's duidelijk de strategie. Eerst schenken nadien de nek omwringen.

Misschien eerst even lezen voor je wat roept.
Jouw doemscenario kunnen ze moeilijk ten uitvoer brengen als ze iedereen een levenslang lopende gratis licentie op de techniek geven.

Misschien moet je even bij Apple aankloppen. Die hebben namelijk precies dit geintje al eens geprobeerd te flikken met hun Touch Events API.

[SchizoDuckie]

awaum. weer een kans om een 'prollyfill' te bouwen. beetje jammer dat de pointer events niet vuren buiten hun eigen element though