Re: Justification for the touch-action processing model

I hope I'm wrong but I'm worried about how the current design applies to a component, encapsulated approach where no components should have to know how it is used, where or inside which other component it may be. Has that been scrutinized?

Benoit

On Jun 4, 2013, at 11:58, 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."
> 
> -Jacob
> 
>

Received on Tuesday, 4 June 2013 19:39:26 UTC