- From: Sangwhan Moon <smoon@opera.com>
- Date: Sat, 30 Apr 2011 19:39:35 +0800
- To: Web Events Working Group WG <public-webevents@w3.org>
On Feb 16, 2011, at 12:48 AM, Web Events Working Group Issue Tracker wrote: > > WebEvents-ISSUE-3: Click event target after DOM mutation during touchstart [Touch Events spec] > > http://www.w3.org/2010/webevents/track/issues/3 > > Raised by: Matt Brubeck > On product: Touch Events spec > > Andrew Grieve <http://lists.w3.org/Archives/Public/public-webevents/2011JanMar/0043.html>: > [[ > If the user taps the screen, and the page changes the DOM within the context > of the touchstart event, should a click event be fired on the new DOM? > -this is the case for both Android & iPhone > -Mobile Google Docs takes advantage of this by placing a textarea under > your click > -It would also be nice to prevent the click, say with a preventDefault() on > the touchend. > ]] Sounds very related to ISSUE-4. I personally think preventDefault on any touch event should prevent any consequential mouse events that would be fired as a interpreted result of the touch event - and since most implementations fire the mouse events as a result of touchstart-touchend, it should blocking touchend shouldn't fire any mouse events. The initial writing draft for the resolution to ISSUE-4 was this: "If the preventDefault method of any touch event is called, the user agent should not dispatch any mouse event that would be a consequential result of the the prevented touch event. " But after some real-world implementation tests, I ended up aligning it with what is out in the world, so only touchstart and touchmove has been mentioned - but I'd personally like to expand the scope to all touch events if there are no objections. -- Sangwhan Moon, Opera Software ASA XMPP: smoon@opera.com | Mobile: +372-5971-6147
Received on Saturday, 30 April 2011 11:40:16 UTC