- From: Jacob Rossi <Jacob.Rossi@microsoft.com>
- Date: Thu, 11 Apr 2013 03:47:51 +0000
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- CC: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
> On Fri, Apr 5, 2013 at 9:29 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > > > > On 4/5/13 9:43 AM, Arthur Barstow wrote: > >> > >> <https://dvcs.w3.org/hg/pointerevents/raw-file/default/pointerEvents.html> > > > > > > The IDL looks fine. Thanks for the review. > > > > Two other comments: > > > > 1) If the intent is that the gotpointercapture and lostpointercapture events fire async after set/releasePointerCapture returns, that should be made more clear, I think. Right now an implementation could choose to fire them either sync or async... The table "List of Pointer Event Types" describes these as async. But it should be in the event descriptions too. This is a good fix, thanks. I've updated the spec: https://dvcs.w3.org/hg/pointerevents/rev/91af8c100600 > > 2) It's not clear to me why the 'touch-action' CSS property is restricted to only applying to block-level elements and SVG. Shouldn't I be able to set touch-action on an <img>, say, without making it 'display: block'? Simplifying the API to block-level elements facilitates faster (simpler) hit testing systems and also makes it easier to design multi-threaded scrolling implementations, which is a primary goal of the API. The primary scenarios for touch-action are handling touch actions on scrollable/zoomable elements and in interactive scenarios like canvas games or SVG, all of which are block level. In practice, we haven't seen developers have a need to support inline elements for different touch action handling. I do think extending it to all elements in the future isn't beyond the realm of possibility, but implementations need to first experiment with the ramifications on performance. We don't want to give developers a lever that tanks performance. We actually had the chance to discuss this a bit during this week's WG meeting: http://www.w3.org/2013/04/09-pointerevents-minutes.html#item06 We confirmed that we think this scoping is correct for this spec, but agreed adding a note that explains it and the possibility of it being expanded to all elements in the future seemed appropriate. I would propose: "The touch-action property is restricted to block-level elements to facilitate low latency touch actions. Future specifications may extend this API to all elements." -Jacob
Received on Thursday, 11 April 2013 03:48:30 UTC