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

On Fri, Jun 21, 2013 at 7:06 PM, James Greene <james.m.greene@gmail.com>wrote:

> 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.
>
I don't think this WG has seriously discussed switching from CSS html
attributes (although I think several of us agreed it's a reasonable thing
for polyfills to do).  We imagine some scenarios where the power of CSS
will be really helpful - eg. letting you apply touch-action: none to all
elements of a given class.  But probably the main reason we haven't
seriously debated the tradeoffs is for compatibility with the existing IE10
implementation (for the standard to be successful we know we can't change
things so fundamentally that IE is left with a compat problem).  Perhaps *
Jacob* can comment further on why IE10 went with CSS instead of HTML
attributes.

The difficulty of polyfilling is indeed a real problem.  But rather than
avoid CSS because it's harder to polyfill, I think we should have a
cross-browser effort to make CSS extensible through JavaScript.  Many new
web platform features will continue to rely on CSS, and I don't think this
'don't use CSS for feature X because it makes it hard to polyfill' argument
scales to the web at large.

In the interim, mapping CSS properties to HTML attributes for partial
polyfilling seems like a reasonable convention.

> 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.
>
I agree that using CSS for this feels a little strange, as it's not
strictly a presentation issue.  But this isn't really new.  The
(confusingly named) pointer-events property (
http://wiki.csswg.org/spec/css4-ui#pointer-events) which is already widely
supported is similar in this respect.   It's also possible to use CSS
properties like z-index to impact DOM events without otherwise changing
presentation (eg. with transparent overlays).  There are other properties
(eg. 'resize', 'nav-*', etc.) that aren't strictly about presentation.

> 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/
>>>
>>>
>>