Re: Why is the `touch-action` CSS property needed?

Thanks, Rick. Perusing through your links explained the situation well.

Has there been any thought given to making `touch-action` an HTML element
attribute rather than a CSS property? As I'm sure you're familiar, the CSS
approach is very troublesome for polyfilling as browsers remove
unrecognized CSS properties, and re-reading the stylesheets and
implementing a CSS parser in JS is definitely suboptimal (though the
"hand.js" polyfill makes a valiant effort in that regard). The other
polyfills (Polymer, Points.js) already use an HTML element attribute
instead because of this limitation.

Having a DOM-based control for DOM events feels like a better separation of
concerns to me than a CSS-based control for DOM events. Perhaps there is
another problem with that approach that I'm unaware of, though, so please
forgive my ignorance if that's the case.

Sincerely,
   James Greene
On Jun 21, 2013 9:26 AM, "Rick Byers" <rbyers@google.com> wrote:

> Hi James,
> The main motivation for a CSS property is for performance on browsers that
> use a separate thread to implement scrolling.  I agree the spec doesn't
> make this very explicit, but it does mention it, eg:
>
> "An additional key goal is to enable multi-threaded user agents to handle
> default touch actions, such as scrolling, without blocking on script
> execution."
> "Touch manipulations are intentionally not a default action of pointer
> events. Removing this dependency on the cancellation of events facilitates
> performance optimizations by the user agent."
>
> This is a really big problem in touch browsers today.  For scrolling to
> feel really good (which we know increases user engagement) we must be able
> to do it at a smooth 60fps, but it can be very hard to ensure parsing /
> javascript / layout / painting etc. never takes >16ms - especially on
> mobile devices.  To address this we must be able to scroll without blocking
> on the main thread, but that's not possible if we must wait to dispatch the
> pointer event to the DOM and see if it is cancelled.
>
> I discuss this problem in more detail here:
> https://plus.sandbox.google.com/115788095648461403871/posts/cmzrtyBYPQc
>
> https://docs.google.com/a/chromium.org/document/d/12-HPlSIF7-ISY8TQHtuQ3IqDi-isZVI0Yzv5zwl90VU/edit#heading=h.qsp769rzbdvl
> https://developers.google.com/events/io/sessions/361772634
>
> Rick
>
>
> On Thu, Jun 20, 2013 at 1:38 PM, James Greene <james.m.greene@gmail.com>wrote:
>
>> Perhaps I've overlooked something but I haven't found anything in the
>> Pointer Events spec nor mailing list archives that explains why the
>> `touch-action` CSS property is needed.
>>
>> From the outside perspective of someone who is *relatively* new to
>> Pointer Events, it seems to me that the JS/DOM should always receive
>> Pointer events and that any user agents' special touch actions should be
>> triggered as the default actions for a given Pointer event.  This would
>> mean that you could prevent the user agents' special touch actions simply
>> by calling `e.preventDefault();` from the JS side.
>>
>> However, what I've read so far about this `touch-action` CSS property
>> would suggest that the user agents may trigger their special touch actions
>> *BEFORE *the Pointer event is passed to JS/DOM.
>>
>> I'm also confused why we would want to *require* a CSS property in order
>> to *enable* a DOM event (though I do understand the nicety of using CSS
>> properties to *disable* DOM events, e.g. "user-select:none").
>>
>> Could someone please enlighten me?  Thank you in advance!
>>
>> Sincerely,
>>     James M. Greene
>>     http://jamesgreene.net/
>>
>>
>