- From: Arthur Stolyar <nekr.fabula@gmail.com>
- Date: Wed, 16 Apr 2014 17:15:28 +0400
- To: public-pointer-events@w3.org
- Message-ID: <CAPAD5+ATKfuR_rH1JmFkzj_ihptetEocoOSEa8mqi+-EYGEZPQ@mail.gmail.com>
> > I found that in specification is not a lot information about hit test > detection for events, esspecially for pointercancel. In my mind, when > finger moves on surface by some interval should be called hit test which > finds new element for 'move', 'out', 'over' etc. events. Also, when finger > moves, accordingly to touch-action may be fired 'cancel' event, but it's > not clear for which element should be fired 'cancel' event. > Open questions are: > Should or not 'move' event be fired before 'cancel' > If so, should there be hit test for that move and subsequent events e.g > 'out', 'over' > And if new target is determined by that 'possible hit test' on which target > should be fired touch cancel. Currently in my library touchcancel send to > last target, therefor after > touchmove that target may be not the same as original. Should I always > send 'cancel' event to start-target or to current-target? Tested on Windows Emulator 12.0 (Window 8.1) with touch events emulation. It seams that IE has implicit 'pointer capture' for element which may trigger scroll. i.e. if element has 'touch-action: pan-x pan-y' or just 'touch-action: auto' CSS property, when all events between pointerdown and pointercancel 'll be fired on that element. It means that if pointer leaves boudaries of that element, then pointerout and pointerleave 'll be fired, but not pointerover and pointerevent on new target. Also, IE has some strange behavior with 'pointer capture', when IE fires pointerout on element with 'pointer capture' then relatedTarget property of event 'll be null, but when IE triggers pointerleave on element with 'pointer capture' then relatedTarget property of that element 'll be same element as in target property of event. -- @nekrtemplar <https://twitter.com/nekrtemplar>
Received on Wednesday, 16 April 2014 13:15:56 UTC