Google schrapt de ondersteuning voor de Pointer Events-standaard van Microsoft in Chrome-browsers vanwege zwakke redenen
3 minuut. lezen
Uitgegeven op
deel dit artikel
Verbeter deze handleiding
Lees onze openbaarmakingspagina om erachter te komen hoe u MSPoweruser kunt helpen het redactieteam te ondersteunen Lees meer
Aanwijzergebeurtenissen is een nieuwe standaard die Microsoft eerst heeft geïnitieerd en later door het W3C is ontwikkeld om een uniform apparaatinvoermodel - pen, muis en aanraking - in meerdere browsers te definiëren. Pointer Events maakt het gemakkelijker om verschillende browsers en apparaten te ondersteunen door webontwikkelaars te behoeden voor het schrijven van unieke code voor elk invoertype. Om cross-browser-interoperabiliteit voor Pointer Events te demonstreren, heeft Microsoft patches voor Blink- en Mozilla-browserengines bijgedragen en interoperabiliteitsprototypes ontwikkeld, waaronder een Pointer Events-prototype voor WebKit. Ook Pointer Events werd goed ontvangen door de webgemeenschap.
Vorige week heeft het Chrome-team gepost dat ze van plan zijn om Pointer Events-ondersteuning in Chrome te laten vallen met de volgende redenen.
Kort gezegd, pointergebeurtenissen hebben drie belangrijke nadelen ten opzichte van het alternatief: 3) Mobile-first web: Pointergebeurtenissen zouden waarschijnlijk nooit de touch-gebeurtenissen op het web verdringen (vooral zonder ondersteuning van Safari). Aangezien touch-evenementen blijvend zijn, heeft het ondersteunen van een ander grotendeels redundant invoermodel hoge complexiteitskosten op de lange termijn op het webplatform. 1) Prestaties: het hittestmodel dat vereist is voor aanwijzergebeurtenissen legt een niet-triviale prestatiestraf op (hittest bij elke bewegingsgebeurtenis) die noch Android-, iOS- of aanraakgebeurtenissen hebben. We zijn niet bereid om een functie toe te voegen die het prestatienadeel van het web vergroot ten opzichte van native mobiele platforms. 2) Rijkdom: aanwijzergebeurtenissen vereisen dat scrollen en gebeurtenisafhandeling elkaar uitsluiten. Dit sluit een aantal UI-effecten uit die veel voorkomen op mobiele platforms (bijv. pull to refresh). Recente sterke feedback van ontwikkelaars heeft ons ertoe gebracht Chrome hier in de tegenovergestelde richting te veranderen - waardoor gebeurtenisafhandeling tijdens het scrollen mogelijk wordt (zie uitgave 3). We zijn toegewijd aan het werken in de webstandaardengemeenschap om de input op het web te verbeteren, en we waarderen vooral de relatie die we recentelijk hebben opgebouwd met het IE-team hier. Ondanks dit verschil in technische mening over wat het beste is voor het web, ben ik optimistisch dat we samen nog steeds goede vooruitgang zullen boeken.
Hoewel je over het tweede en het derde punt kunt discussiëren, denk ik dat de eerste reden onaanvaardbaar is. Omdat Safari van Apple de standaard nu niet ondersteunde, willen ze geen ander redundant invoermodel ontwikkelen. Ik kan een aantal functies in Chrome opsommen die nog niet beschikbaar zijn in andere browsers en het is nu overbodig. Zal Google die functies uit de browsers verwijderen? Ook zijn Android en Chrome van Google veel populairder dan Safari, en in combinatie met IE en Firefox wordt bijna het grootste deel van de internetbrowser gedekt. Ik weet niet waarom Google in dit geval niet bereid is tegen Apple in te gaan.
Er zijn een paar berichten van experts over deze kwestie die hun mening hebben gegeven over de actie van Google op aanwijzergebeurtenissen, lees ze via de onderstaande link.
