Remove the need of a 'touch-action' attribute on DOM nodes to fire pointer events

[axemclion]

The W3C specification does not require a touch-action attribute in a DOM node to fire pointer events.

Is this requirement for performance - and not having to add event listeners to all DOM nodes ?

[dmethvin]

I think the problem is that on current browsers not implementing pointer events there is no reliable cross-browser way to determine whether touch-action has been set in a stylesheet as specified by the standard. Many if not most browsers will remove CSS properties they don't understand, which makes the browser's in-memory document.stylesheets useless to the polyfill. The hand.js shim attempts to retrieve the stylesheet via AJAX but that's a really big performance hit, would require XDR for IE8-9, and still not support IE 6/7. Even then it can't faithfully reproduce the CSS cascade or dynamic changes.

[axemclion]

@dmethvin My question was more about requiring touch-action as an attribute to even start firing pointer events. According to the specification, should not the pointer events be fired even if I do not have the CSS property set?

By default, the value of touch-action is auto.

[RByers]

There is a perf trade off here due to the perf impact on threaded scrollimg
of adding touch event handlers. So you want some way (at least as an
option) to opt into pointer event support in different sub-trees. It
doesn't have to be touch-action though - could be a "enable pointer events"
attribute that is logically inherited by child nodes.

On of the big benefits of implementing touch action natively is that it can
be done without hurting threaded scrolling.
On Jul 21, 2013 8:51 PM, "Parashuram N" notifications@github.com wrote:

@dmethvin https://github.com/dmethvin My question was more about
requiring touch-action as an attribute to even start firing pointer events.
According to the specification, should not the pointer events be fired even
if I do not have the CSS property set?

By default, the value of touch-action is auto.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/92#issuecomment-21320323
.

[dfreedm]

I've been working a lot recently to remove this. With #90, touch-action should no longer be needed for mouse input.

For touch, the simulated mouse events can provide enough information for down and up, but they will have the wrong pointerType.

Like what @RByers said, touch handlers have a very big performance tradeoff that I've been trying to keep minimal.

[axemclion]

How about requiring the attribute to opt-in only for touchmove events ?
Are other events like touchstart or touchend also affected by this ? Can we listen to touchstart and touchend at the document level (like the mouse events),

Apart from having to treat touchmove as a special case, can the need to opt-in for other touch events be removed ?

[RByers]

Touchstart is an issue too - prevents scroll from starting, especially an
issue during page load on mobile.

But yes with native support for touch-action, this restriction can be
lifted. Its why I'm making touch-action in chrome a high priority.
On Jul 24, 2013 10:52 PM, "Parashuram N" notifications@github.com wrote:

How about requiring the attribute to opt-in only for touchmove events ?
Are other events like touchstart or touchend also affected by this ? Can
we listen to touchstart and touchend at the document level (like the mouse
events),

Apart from having to treat touchmove as a special case, can the need to
opt-in be removed ?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/92#issuecomment-21527895
.

[axemclion]

Does touchstart have that bad a performance impact ? If not, we would just need the touch-action DOM attribute only for touchmove and all other pointer events will work without needing the attribute (like in the specification).

I also noticed that in touch.js, there is a check for the support of a touch-action CSS style. The if-else state basically says that if touch-action CSS style is supported by the browser, all touch event listeners are added to the top level document. If the CSS style is not supported, these events are added to sub-trees based on the touch-action attribute on the subtree DOM.
Does this mean that even when the touch-action CSS property is supported, pointer events will still be “opt-in” using the CSS style instead of a DOM attribute?

[dfreedm]

I'll answer your two part question in two parts:

touchstart and touchmove both can stop scrolling with preventDefault, so both of them will disable composited scrolling.
As of now, the synthetic mouse events generated by touches will create pointerdown and pointerup events for any area on the screen, though the pointerType will be mouse instead of touch.
Also, adding touch-action="auto" attribute will enable the full set of expected pointerevents in the spec, at the expense of the composited scrolling performance.
This seems like a reasonable compromise to me as you'll at least get something from touches in the "default" case, and full spec compatibility can be achieved with a possible performance hit.

Yes, if touch-action is supported by the browser, there is no need to set the attribute, and the touch handlers should be safe to add to the whole document.
However, I would recommend using the attribute for backwards compatibility. In touch-action.js, a stylesheet is generated that uses the attribute value to set the css property, which maximum compatibility with all supported browsers.

[touch-action="none"] {
  -ms-touch-action: none;
  touch-action: none;
}

[bergie]

As it is likely related, it seems you cannot listen to PointerEvents from document with this polyfill. This is unfortunate as that appears to be the only way to receive mouse drags that end outside of the current window.

[dfreedm]

@bergie I'm not sure I understand what you mean. All PointerEvents bubble from their target to the window.

From the issue you linked, it seems your problem is actually related to events that target window, which seems like a bug.

I'll file a new bug, as this one is incredibly stale.