Re: WebEvents-ISSUE-3: Click event target after DOM mutation during touchstart [Touch Events spec]

On Sat, Apr 30, 2011 at 7:39 AM, Sangwhan Moon <smoon@opera.com> wrote:

>
> 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
>
>
> +1 To expanding it to all events. The playbook and the latest iOS already
have already expanded this make preventDefault on touchend prevent clicks.

I think this issue is different from issue 4 though. It means to address the
case where preventDefault() is not called, but a touch handler changes the
DOM underneath the touch.