Chrome 47 heeft een nieuwe functie waarmee u gemakkelijker kunt begrijpen hoe gebruikers met uw site omgaan: InputDeviceCapabilities ! Laten we even een stap terug doen en kijken waarom dit belangrijk is.
DOM-invoergebeurtenissen zijn een abstractie boven invoergebeurtenissen op laag niveau, losjes gekoppeld aan de invoer van een fysiek apparaat ( click kunnen bijvoorbeeld worden geactiveerd door een muis, touchscreen of toetsenbord). Er is echter een probleem: er is geen eenvoudige methode om de details te verkrijgen van het fysieke apparaat dat verantwoordelijk is voor een gebeurtenis.
Bovendien kunnen bepaalde typen invoer om compatibiliteitsredenen verdere "nep" DOM-invoergebeurtenissen genereren. Een dergelijke nep-DOM-gebeurtenis vindt plaats wanneer een gebruiker op een touchscreen tikt (zoals op een mobiele telefoon); hierbij worden niet alleen aanraakgebeurtenissen geactiveerd, maar, om compatibiliteitsredenen, ook muisgebeurtenissen.
Dit levert problemen op voor ontwikkelaars bij het ondersteunen van zowel muis- als aanraakinvoer. Het is moeilijk te bepalen of een mousedown gebeurtenis daadwerkelijk nieuwe invoer van een muis vertegenwoordigt, of slechts een compatibiliteitsgebeurtenis 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 firesTouchEvents -eigenschap die wordt ingesteld op true of false afhankelijk van hoe de gebeurtenis door de gebruikersactie is gegenereerd.
De vraag is: waar moet dit gebruikt worden?
Naast Pointer Events verwerken veel ontwikkelaars tegenwoordig de logica voor interactie in de aanraaklaag, waardoor Default in de eerste plaats geen 'nep'-muisgebeurtenissen kan creëren. Dit ontwerp werkt goed in veel scenario's en hoeft niet te worden gewijzigd om te profiteren van InputDeviceCapabilities.
Maar in sommige scenario's wilt u de aanraakgebeurtenis echt niet 'preventDefault' gebruiken; 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 de logica voor aanraak- en muisgebaseerde gebeurtenissen consolideren in een model dat vergelijkbaar is met hoe u de logica zou beheren met Pointer Events. Dat wil zeggen dat u slechts één set code nodig hebt die de interactielogica beheert en ontwikkelaars een eenvoudigere 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 Rick Byers dit heeft gepolyfilled , zodat je het op de meeste platforms kunt gebruiken.
Deze API is momenteel minimaal en richt zich op het oplossen van een specifiek probleem met het identificeren van muisgebeurtenissen die zijn afgeleid van aanraakgebeurtenissen . Het is zelfs mogelijk om een instantie van InputDeviceCapabilities te instantiëren; deze bevat echter alleen firesTouchEvents . Naar verwachting zal deze in de toekomst worden uitgebreid , zodat u meer inzicht krijgt in alle invoerapparaten op het systeem van een gebruiker. We horen graag uw feedback over use cases .