- From: Jacob Rossi <Jacob.Rossi@microsoft.com>
- Date: Thu, 11 Sep 2014 23:42:44 +0000
- To: Rick Byers <rbyers@google.com>
- CC: "public-touchevents@w3.org" <public-touchevents@w3.org>, Matt Gaunt <mattgaunt@google.com>
On Tue, Sep 9, 2014 at 8:00 PM, Rick Byers <rbyers@google.com> wrote:
>
> By the way, have you looked at all for websites that are similarly "broken" when navigator.maxTouchPoints > 0? We've seen a few of these, most recently http://www.shape5.com/demo/design_control/?view=featured (see http://crbug.com/409383).
When we were disabling Touch Events in our prototype, we were also disabling the touchscreen (so maxTouchPoints == 0). We've not seen these issues, but perhaps that's because sites like shape5 are beyond the top sites that can be reasonably manually tested (#9625 in Alexa). I don't repro the issue on Shape5. Do you have a list of other affected sites?
> Disabling hover menus when maxTouchPoints > 0 is a very similar problem to disabling them for ('ontouchstart' in window), but there's no obvious way to help these sites other than evangelism. I certainly wouldn't consider disabling our support for maxTouchPoints as a result ;-)
>
> Perhaps the underlying issue is the same - they want an alternate UI treatment when tapped than when a mouse is used. Again I think something like MouseEvent.derivedFromTouchEvent would make this much simpler for them (or maybe in this case they really do want MouseEvent.pointerType). I'd love any input you have over on that thread.
I think it's possible this pattern (making mouse/touch handling mutually exclusive) might be promoted by the complexity of handling touch & mouse events together. This is a type of problem we were aiming to solve cleanly with pointer events. I'll provide feedback on the derivedFromTouchEvent proposal (most of which you've already heard in 1:1 conversations).
Received on Thursday, 11 September 2014 23:43:14 UTC