‘Logical’ values for the ‘touch-action’ property

[aphillips]

8.1 The touch-action CSS property
https://www.w3.org/TR/2024/WD-pointerevents3-20240326/#the-touch-action-css-property

Value: auto | none | [ [ pan-x | pan-left | pan-right ] || [ pan-y | pan-up | pan-down ] ] | manipulation

The 'touch-action' property says whether the browser should try to interpret a user's touch gestures on an element as requests to scroll or zoom the document (‘touch-action: auto’), or should send those touch gestures to the document's script in the form of pointer events, to be interpreted there (‘touch-action: none’). The pan-* values do something in between: they instruct the browser to only interpret touch gestures for scrolling along the x or y axis, or only for scrolling in one direction. E.g., ‘pan-down’ means the browser should only handle the user's finger gestures for scrolling down (typically a one-finger drag towards the top), while translating all other finger gestures to pointer events.

The one-directional values are new in level 3.

(The directions are actually subject to CSS transformations. E.g., if the element has been rotated 45 degrees, the y axis is really diagonal; and when it has been rotated 90 degrees the y axis is horizontal and ‘pan-down’ really means right.)

A note in the spec suggests that these new one-directional values are useful when the element has already scrolled as far as it can. E.g., when the element has a scrollbar that is at its very top (its initial position), setting ‘touch-action: pan-down’ means that the user can scroll down, but the user's finger gesture for scrolling up will be sent to the script, which can make it mean something. (The script could, e.g., use the scroll-up gesture to reload the document, or load a different document).

Now, the initial position of a scrolling element depends on its ‘direction’ and ‘writing-mode’ properties. E.g., a horizontal, ‘ltr’ element that overflows in the inline direction starts left-aligned and can scroll right; while a similar ‘rtl’ element starts right-aligned and can scroll left. So it potentially makes sense to have ‘logical’ values as well, e.g., ‘pan-inline’ and ‘pan-block’, which act like ‘pan-right', ‘pan-left’ or ‘pan-down’, as appropriate.

Values for the opposite direction (e.g., ‘pan-inline-reverse’ and ‘pan-block-reverse’) could also be useful, for when the element has scrolled to its other end (even though these values will only ever be set by the script, not by the style sheet).

There is in fact an issue about this: #496 which is a followup of another issue: #272 but both are marked as applying to a future spec.

So the question for us is: Is it important to have logical values? And if so, can it wait for level 4?

The alternative for logical values is to write multiple CSS rules, with suitable selectors, e.g., the ‘:dir()’ selector; or to set the property only through JavaScript. (The property is only useful if the document has a script anyway.)

(Filed on behalf of the I18N WG. Issue was originated by @bert-github)

[patrickhlauke]

@aphillips apologies for the late reply. We've discussed this topic - specifically the question of whether or not we should try and get this into Level 3 or defer for the next version - in our last meetings

• https://www.w3.org/2024/07/17-pointerevents-minutes.html#t01
• https://www.w3.org/2024/07/31-pointerevents-minutes.html#t01

While initially we were going to try and squeeze it into Level 3, the one concern that was raised last time was the fact that introducing such a new feature (that had, up to this point, been only in a very rough draft) at such a late stage would jeopardise going to REC with Level 3 (to make sure we have actual implementations), which has already been delayed more than anticipated due to a similar late-stage addition a few months ago.

In addition, it was noted that authors would likely use the directional touch-action in combination with overflow. It appears that currently, logical values for overflow are only in draft in their respective spec, so the general feeling was that merging #496 into the future/next version (Level 4, or potentially "living standard") is not going to be a critical blocker right now for authors.

However, the plan is to focus on this aspect as soon as Level 3 is in REC, and the hope is that Level 4 won't take as long to come to fruition after that.