Chrome 47 heeft een nieuwe functie die het gemakkelijker maakt om te begrijpen hoe gebruikers omgaan met uw site: InputDeviceCapabilities ! Laten we een stapje terug doen en leren waarom dit belangrijk is.
DOM-invoergebeurtenissen zijn een abstractie boven invoergebeurtenissen op laag niveau, losjes gekoppeld aan fysieke apparaatinvoer ( click kunnen bijvoorbeeld worden geactiveerd door een muis, touchscreen of toetsenbord). Er is echter een probleem: er bestaat geen eenvoudige methode om de details te verkrijgen van het fysieke apparaat dat verantwoordelijk is voor een gebeurtenis.
Bovendien kunnen bepaalde soorten invoer om compatibiliteitsredenen verdere "nep" DOM-invoergebeurtenissen genereren. Eén zo'n nep-DOM-gebeurtenis vindt plaats wanneer een gebruiker op een aanraakscherm tikt (zoals op een mobiele telefoon); het activeert niet alleen aanraakgebeurtenissen, maar, om compatibiliteitsredenen, ook muisgebeurtenissen.
Dit veroorzaakt problemen voor ontwikkelaars bij het ondersteunen van zowel muis- als aanraakinvoer. Het is moeilijk om te weten of een mousedown gebeurtenis daadwerkelijk nieuwe invoer van een muis vertegenwoordigt, of slechts een compatibiliteitsgebeurtenis is voor een eerder verwerkte touchstart-gebeurtenis.
De nieuwe InputDeviceCapabilities API biedt details over de onderliggende bronnen van invoergebeurtenissen via een sourceCapabilities object op de UIEvent.
Het object heeft een eigenschap firesTouchEvents die is ingesteld op true of false op basis van de manier waarop de gebeurtenis door de gebruikersactie is gegenereerd.
De vraag is: waar moet dit worden gebruikt?
Buiten Pointer Events verzorgen veel ontwikkelaars tegenwoordig de logica voor interactie in de aanraaklaag, waardoor Default wordt voorkomen om te voorkomen dat er überhaupt "nep"-muisgebeurtenissen worden gecreëerd. Dit ontwerp werkt goed in veel scenario's en hoeft niet te worden gewijzigd om voordeel van InputDeviceCapabilities.
Maar in sommige scenario's wilt u de aanraakgebeurtenis echt niet voorkomen; U wilt bijvoorbeeld nog steeds dat tikken 'klik'-gebeurtenissen verzenden en de focus wijzigen. In deze gevallen kunt u met de informatie in de eigenschap MouseEvent.sourceCapabilities.firesTouchEvents beginnen met het consolideren van de logica voor aanraak- en muisgebaseerde gebeurtenissen in een model dat vergelijkbaar is met de manier waarop u de logica zou beheren met Pointer Events. Dat wil zeggen dat u slechts één codeset kunt hebben die de interactielogica beheert en ontwikkelaars een eenvoudiger manier biedt om logica te delen tussen browsers die Pointer Events wel en niet ondersteunen.
function addMouseEventListener(target, type, handler, capture) {
target.addEventListener(type, function(e) {
if (e.sourceCapabilities.firesTouchEvents)
return false;
return handler(e);
}, capture);
}
Het goede nieuws is dat dit door Rick Byers Polyfilled is, zodat je het op de meeste platforms kunt gebruiken.
Tegenwoordig is deze API minimaal en gericht op het oplossen van een specifiek probleem met het identificeren van muisgebeurtenissen die zijn afgeleid van aanraakgebeurtenissen . Het is zelfs mogelijk om een instance van InputDeviceCapabilities te instantiëren; het bevat echter alleen firesTouchEvents . Er wordt verwacht dat dit in de toekomst zal worden uitgebreid , zodat u meer inzicht krijgt in alle invoerapparaten op het systeem van een gebruiker. We ontvangen graag uw feedback over gebruiksscenario's .