[pointerevents] ‘Logical’ values for the ‘touch-action’ property (#505)

aphillips has just created a new issue for https://github.com/w3c/pointerevents:

== ‘Logical’ values for the ‘touch-action’ property ==
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: https://github.com/w3c/pointerevents/pull/496 which is a followup of another issue: https://github.com/w3c/pointerevents/issues/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)

Please view or discuss this issue at https://github.com/w3c/pointerevents/issues/505 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 6 June 2024 16:39:28 UTC