- From: Rick Byers <rbyers@google.com>
- Date: Thu, 27 Feb 2014 23:16:06 -0500
- To: "Patrick H. Lauke" <redux@splintered.co.uk>
- Cc: "public-touchevents@w3.org" <public-touchevents@w3.org>
- Message-ID: <CAFUtAY_8WTfbbWfwpbuu60S950yqn=8Vjre+2TR4KQjYFa4pHA@mail.gmail.com>
I had intended to talk about some of this in the touch events community wiki. I'm not sure how much value there is in publishing an updated spec and going through the whole w3c process. I'm not opposed to it though if someone else wants to do the work <grin>. But I think there was consensus in the former TouchEvents WG that we considered this spec dead to enable us to focus on pointer events instead (except perhaps in the case of any serious errors). A few comments inline. On Tue, Feb 25, 2014 at 5:05 AM, Patrick H. Lauke <redux@splintered.co.uk>wrote: > Based on a quick conversation with Doug on Twitter the other day > https://twitter.com/patrick_h_lauke/status/437598813004791808 I'm > wondering if there's any desire in this CG to expand on the current W3C > Touch Events spec to define things that have been left quite vague? A few > examples include: > > - the spec talks about preventDefault on touchstart and touchmove to > suppress compatibility mouse events. It does not define what happens when > preventDefault is done on touchend (and from my tests, this is a bit hit > and miss in different browsers) > Yep, the spec was designed to capture the common behavior across the major browsers and so, with that goal in mind, left several things (like this) unspecified. It's great to have references describing the browser behaviors, but links from our wiki to existing sources may be sufficient. - it mentions mousemove, mousedown, mouseup and click for the "interaction > with mouse events" section. no mention of mouseover, mouseenter, mouseout, > mouseleave > I think the idea is that those are always generated in a consistent way as a result of 'mousemove' and so are implicit. As for PE, it doesn't hurt to clarify of course. > - from my testing, it seems that mouse events are only fired in the case > of a single touch tap action. as soon as a second touch point is present, > or the single touch is held on the screen for a certain period of time, or > moves too much, no mouse events are being fired. this is not explicitly > stated. > Again there may be some variability so this wasn't considered directly in scope. But this specific detail is (as far as I know) pretty consistent across browsers. - the spec seems to suggest (in 5.3.2) that changedTouches should only > contain the touches that relate(d) to the "defined touchable element". Does > this mean, more explicitly, that it should only show the change in > targetTouches? from my testing, some browsers also add touches (not in > targetTouches) that changed to the changedTouches touchlist object > That's not how I read it. It's saying that the example code triggers whenever a touch is removed from the defined element, but the answer to your question isn't found in this example. But above in section 5.1 it says pretty clearly "a list of Touches for _every_ point of contact which contributed to the event". - based on the work we're doing in Pointer Events, it would be nice to have > an explicit section that lists the events being fired, and in what order, > for common interactions on a touchscreen (tap on an element), including > compatibility mouse events etc. > > So...is this something that we should/could/want to tackle? Or should I > just file some open issues here http://www.w3.org/2010/ > webevents/track/issues/open ? > > P > -- > Patrick H. Lauke > > www.splintered.co.uk | https://github.com/patrickhlauke > http://flickr.com/photos/redux/ | http://redux.deviantart.com > twitter: @patrick_h_lauke | skype: patrick_h_lauke > >
Received on Friday, 28 February 2014 04:16:54 UTC