Re: Justification for the touch-action processing model

On Tue, Jun 4, 2013 at 2:58 PM, Jacob Rossi <Jacob.Rossi@microsoft.com>wrote:

> On Mon, Jun 3, 2013 at 6:12 PM, Rick Byers <rbyers@google.com> wrote:
> >
> > On Sat, Jun 1, 2013 at 2:48 PM, Jacob Rossi <Jacob.Rossi@microsoft.com>
> wrote:
> >>
> >> Addressing your first question:
> >>
> >> The processing model is designed so that you can incorporate
> scrollable/zoomable elements as "ceilings" for the inheritance. Your map
> example illustrates this. Put a different way, we want it such that when
> you touch in a scrollable/zoomable element then you only need to consider
> the elements inside the scrollable/zoomable element to determine the
> touch-action.  Happy to add a note if that helps.
> >
> >
> > Thanks.  And is having a ceiling beneficial for any reason other than
> particular implementation details in IE?  I'm not quite done the Chrome
> implementation yet, but I don't think it makes anything easier for us.
> >
> > As a web developer I'm definitely glad I don't have to remember to
> explicitly specify touch-action: auto on scrollable elements that might
> occur inside of touch-action: none regions.
>
> Not an implementation detail. It's precisely your last comment that
> justifies the design. Generally speaking, we want to avoid scenarios where
> developers have to think to add touch-action:auto for a scroller inside of
> a touch-action:none region.  One way to think about this model is
> effectively "event bubbling."  When you touch, the even "bubbles" up the
> ancestor tree looking for the first "handler." It stops when it reaches the
> scroller because the scroller can "handle" the event. Likewise, it also
> stops at the first element that says explicitly "touch-action: none."
>

Perfect, thanks.  This is what I expected, but I wanted to confirm there
wasn't something else motivating this I hadn't thought of.

 -Jacob
>
>

Received on Tuesday, 4 June 2013 19:31:09 UTC