Explain situation when you might use touch-action: manipulation

I have seen

touch-action: manipulation;

In the CSS of various websites applied to buttons and links. I am curious what the purpose of this is?

I read the values on the Mozilla Developer Network

The touch-action CSS property specifies whether, and in what ways, a given region can be manipulated by the user (for instance, by panning or zooming).

auto: The user agent may determine any permitted touch behaviors, such as panning and zooming manipulations of the viewport, for touches that begin on the element.

none: Use this value to disable all of the default behaviors and allow your content to handle all touch input (touches that begin on the element must not trigger default touch behaviors).

pan-x: The user agent may consider touches that begin on the element only for the purposes of horizontally scrolling the element’s nearest ancestor with horizontally scrollable content.

pan-y: The user agent may consider touches that begin on the element only for the purposes of vertically scrolling the element’s nearest ancestor with vertically scrollable content.

manipulation: The user agent may consider touches that begin on the element only for the purposes of scrolling and continuous zooming. Any additional behaviors supported by auto are out of scope for this specification.

But I don’t understand what the thinking is behind applying this to most links/buttons. Does this prevent a common issue that normally comes with using the default value of auto?

Answer

According to sitepoint post, touch-action: manipulation helps preventing PointerEvents fire by removing each event detection delay. For example, the double-tap event could fire when screen is double-tapped until 300ms case touch-action: manipulation was not declared.

Short quote:

Most touch-based mobile browsers wait 300ms between your tap on the screen and the browser firing the appropriate handler for that event. It was implemented because you could be double-tapping to zoom the page to full width. Therefore, the browser waits for a third of a second — if you don’t tap again, the “click” is activated.

Microsoft has solved many touch-based issues in the PointerEvents specification. For example, the pointerup event won’t be fired if the user is scrolling the page.

There is also a non-standard CSS touch-action property which allows you to remove the delay on specific elements or the whole document without disabling pinch-zooming:

a, button, .myelements { … }

I’m not sure about situations, it depends if you’re not satisfied with the screen taps, so comparisons would be a good idea.

Leave a Reply

Your email address will not be published. Required fields are marked *