On Thu, Jan 17, 2013 at 5:24 PM, Jacob Rossi <Jacob.Rossi@microsoft.com> wrote: > The property acts as a filter on the behaviors a UA is allowed to perform. It doesn't inherit because it has its own processing model (I'll update the spec to remove "inherit" from the grammar--I didn't know the convention). I hear the feedback that the spec text for this model is unclear. I think, perhaps, a more algorithmic approach might be better: > > Run these steps prior to dispatching the pointerdown event for a touch: > 1. Set ELEMENT to the target of the pointerdown. > 2. If the value of touch-action for ELEMENT is "none" then terminate these steps. > 3. If ELEMENT is capable of a performing a touch behavior (such as panning or zooming), then begin considering this touch for that possible behavior and abort these steps. > 4. If ELEMENT is the root of the document, terminate these steps. > 5. Set ELEMENT to the current ELEMENT's immediate parent and repeat steps 2-5. This is golden, very easy to understand. Now that I know what it's doing, I see that it's pretty easy to write out in prose too: When a user touches an element, the effect of that touch is determined by the 'touch-action' property and the default touch behaviors on the element and its ancestors. To determine the effect of a touch, find the nearest ancestor (starting from the element itself) that either has a default touch behavior or that has "touch-effect: none". If the nearest ancestor has a default touch behavior, execute that. If the nearest ancestor has "touch-effect: none", do nothing. ~TJReceived on Friday, 18 January 2013 01:54:42 UTC
This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:23 UTC