U en uw gebruikers willen mobiele webapps die soepel op aanraking reageren en scrollen. Het ontwikkelen ervan zou eenvoudig moeten zijn, maar helaas wordt de manier waarop mobiele webbrowsers reageren op aanraakgebeurtenissen tijdens het scrollen als implementatiedetail overgelaten in de TouchEvent- specificatie. Hierdoor kunnen de benaderingen grofweg in vier categorieën worden onderverdeeld. Deze situatie legt een fundamentele spanning bloot tussen het leveren van vloeiende scrollen en het behouden van controle door de ontwikkelaar.
Vier verschillende modellen voor de verwerking van aanraakgebeurtenissen?
De gedragsverschillen tussen de browsers zijn onderverdeeld in vier modellen.
Normale synchrone gebeurtenisverwerking
Touchmove-gebeurtenissen worden verzonden tijdens het scrollen en elke scroll-update blokkeert totdat de touchmove-afhandeling is voltooid. Dit is goed omdat het het eenvoudigst te begrijpen is en het krachtigst, maar slecht voor de scrollprestaties, omdat het betekent dat elk frame tijdens het scrollen op de hoofdthread moet blokkeren.
Browsers: Android-browser (Android 4.0.4, 4.3), Mobile Safari (bij scrollen div)
Asynchrone touchmove-verwerking
Touchmove-gebeurtenissen worden verzonden tijdens het scrollen, maar het scrollen kan asynchroon doorgaan (de touchmove-gebeurtenis wordt genegeerd nadat het scrollen is begonnen). Dit kan resulteren in "dubbele afhandeling" van gebeurtenissen, bijvoorbeeld door te blijven scrollen nadat de website iets met de touchmove heeft gedaan en preventieDefault bij de gebeurtenis aanroept, waarbij de browser wordt verteld deze niet af te handelen.
Browsers: Mobile Safari (bij het scrollen door Document), Firefox
Touchmove onderdrukt tijdens het scrollen
Touchmove-gebeurtenissen worden niet verzonden nadat het scrollen is gestart en worden pas hervat na de touchend-gebeurtenis. In dit model is het moeilijk om het verschil te zien tussen een stilstaande aanraking en een scroll.
Browsers: Samsung Browser (muisbewegingsgebeurtenissen verzonden)
Raak Annuleren aan bij het starten van het scrollen
Je kunt het niet beide kanten op hebben - vloeiend scrollen en controle voor de ontwikkelaar - en dit model maakt de wisselwerking tussen soepel scrollen en gebeurtenisafhandeling duidelijk, vergelijkbaar met de semantiek van de Pointer Events- specificatie. Sommige ervaringen waarbij de vinger moet worden gevolgd, zoals pull-to-refresh, zijn niet mogelijk.
Browsers: Chrome Desktop M32+, Chrome Android
Waarom veranderen?
Chrome voor Android gebruikt momenteel het oude model van Chrome: touchcancel bij scrollstart, wat de scrollprestaties verbetert, maar tot verwarring bij ontwikkelaars leidt. In het bijzonder zijn sommige ontwikkelaars niet op de hoogte van de touchcancel-gebeurtenis of hoe hiermee om te gaan, en dit heeft ertoe geleid dat sommige websites kapot zijn gegaan. Wat nog belangrijker is, is dat een hele reeks UI-scrolleffecten en -gedragingen, zoals pull-to-refresh , hidey bars en snappoints , moeilijk of onmogelijk goed te implementeren zijn.
In plaats van specifiek hardgecodeerde functies toe te voegen om deze effecten te ondersteunen, wil Chrome zich concentreren op het toevoegen van platformprimitieven waarmee ontwikkelaars deze effecten rechtstreeks kunnen implementeren. Zie A Rational Web Platform voor een algemene uiteenzetting van deze filosofie.
Het nieuwe model van Chrome: het Throttled Async Touchmove-model
Chrome introduceert een nieuw gedrag dat is ontworpen om de compatibiliteit te verbeteren met code die voor andere browsers is geschreven tijdens het scrollen, en om andere scenario's mogelijk te maken die afhankelijk zijn van het ontvangen van touchmove-gebeurtenissen tijdens het scrollen. Deze functie is standaard ingeschakeld en u kunt deze uitschakelen met de volgende vlag chrome://flags\#touch-scrolling-mode .
Het nieuwe gedrag is:
- De eerste aanraakbeweging wordt synchroon verzonden, zodat het scrollen kan worden geannuleerd
- Tijdens actief scrollen
- touchmove-gebeurtenissen worden asynchroon verzonden
- beperkt tot 1 gebeurtenis per 200 ms , of als een CSS 15px- slop-regio wordt overschreden
- Event.cancelable is onwaar
- Anders worden touchmove-gebeurtenissen zoals normaal synchroon geactiveerd wanneer actief scrollen wordt beëindigd of niet mogelijk is omdat de scrolllimiet is bereikt
- Een touchend-gebeurtenis vindt altijd plaats wanneer de gebruiker zijn vinger optilt
U kunt deze demo proberen in Chrome voor Android en de chrome://flags\#touch-scrolling-mode -vlag aan- of uitzetten om het verschil te zien.
Laat ons weten wat je denkt
Het Async Touchmove-model heeft het potentieel om de compatibiliteit tussen browsers te verbeteren en een nieuwe klasse aanraakbewegingseffecten mogelijk te maken. We zijn geïnteresseerd in wat ontwikkelaars denken, en in de creatieve dingen die je ermee kunt doen.