- From: Anders Höckersten <andersh@opera.com>
- Date: Tue, 05 Apr 2011 08:39:10 +0200
- To: "public-webevents@w3.org" <public-webevents@w3.org>, "Arthur Barstow" <art.barstow@nokia.com>
Yes, Matt's proposal sounds ok to me. /Anders On Mon, 04 Apr 2011 20:09:03 +0200, Arthur Barstow <art.barstow@nokia.com> wrote: > Ooops - I meant Anders (not Sangwhan). > > On Apr/4/2011 2:00 PM, ext Arthur Barstow wrote: >> Hi All, >> >> Below, Matt proposes a solution. If anyone disagrees, please speak up; >> otherwise, I think we should consider Matt's proposal as agreed (and he >> can implement his proposal in the spec). >> >> Sangwhan - I also copied your response to this thread below. It appears >> Matt's proposal is consistent with what you said. Please clarify. >> >> -Thanks, ArtB >> >> On Apr/2/2011 10:09 AM, ext Matt Brubeck wrote: >>> On 03/28/2011 01:22 PM, Benjamin Poulain wrote: >>>> From my experience on the issue with Qt on Windows 7, this mixing of >>>> mouse event and touch event make it impossible to do anything useful >>>> with the page. >>>> >>>> The best solution I had was to discard the mouse event generated by >>>> the >>>> platform for the touch event. This way the touch and mouse on the same >>>> computer work as expected. >>> >>> I agree. In order to support this technique, I think the Touch Events >>> spec should at least specify: >>> >>> "If the user agent dispatches both touch events and mouse events in >>> response to the same user action, then the 'touchstart' event must be >>> dispatched before any mouse events for that action." >>> >>> This allows content to support both mouse and touch events, and switch >>> between them dynamically in a clean way. (For example, this would >>> allow our own test suite to detect non-touch-aware browsers.) It is >>> also compatible with existing implementations. Any objections? >> >> On Mar/29/2011 4:39 AM, ext Anders Höckersten wrote: >> > On Mon, 28 Mar 2011 18:44:07 +0200, Matt Brubeck >> <mbrubeck@mozilla.com> wrote: >> > >> >> There is a related issue on browsers that support both touch and >> mouse input - for example, Firefox 4 on Windows 7 tablets. >> >> >> >> On platforms like Windows, the operating system may translate touch >> input into mouse movements. This means that, instead of one >> "mousemove" event happening after the "touchend" event, mousemove >> events and touchmove events are interleaved. (Maybe these mouse events >> should be suppressed if preventDefault() is called on one or more of >> the touch events?) >> >> >> >> [removed text Matt left in by mistake] >> >> >> >> I'm not yet clear enough about this problem to enter any issues in >> Track, but I'd like to hear other thoughts. >> > >> > I can add that QT also has this behavior of sending both mouse events >> and touch events, at least on some systems[1]. >> > >> > I'm leaning towards wanting to ignore system mouse events that are >> generated for touch events, and let the browser handle emulation of >> mouse events by itself. The reason is that I don't see why website >> makers should have to worry about the specific touch/mouse behavior of >> different OSes (beyond having to cater to both touch and mouse >> separately, of course), but perhaps I'm missing something here? >> > >> > /Anders >> > >> > [1] >> http://doc.trolltech.com/latest/qtouchevent.html#mouse-events-and-the-primary-touch-point >>
Received on Tuesday, 5 April 2011 06:39:44 UTC