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).
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.)
WHEN CREATING A NEW ISSUE DO SO ABOVE THIS PARAGRAPH, REPLACING THE PROMPTS, BUT LEAVE THIS PARAGRAPH INTACT AS WELL AS THE TEXT BELOW IT When this issue is raised in the github/bugzilla/mail of the WG that owns the spec, use the text above this para as the basis for that comment. Then edit this issue to remove this paragraph and ALL THE TEXT ABOVE IT. Replace the text 'link_to_issue_raised' below with a link to the place you raised the issue, but leave the remaining text below this para unaltered.
This is a tracker issue. Only discuss things here if they are i18n WG internal meta-discussions about the issue. Contribute to the actual discussion at the following link:
aphillips
commented
3 weeks ago
8.1 The touch-action CSS property https://www.w3.org/TR/2024/WD-pointerevents3-20240326/#the-touch-action-css-property
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.)
WHEN CREATING A NEW ISSUE DO SO ABOVE THIS PARAGRAPH, REPLACING THE PROMPTS, BUT LEAVE THIS PARAGRAPH INTACT AS WELL AS THE TEXT BELOW IT When this issue is raised in the github/bugzilla/mail of the WG that owns the spec, use the text above this para as the basis for that comment. Then edit this issue to remove this paragraph and ALL THE TEXT ABOVE IT. Replace the text 'link_to_issue_raised' below with a link to the place you raised the issue, but leave the remaining text below this para unaltered.
This is a tracker issue. Only discuss things here if they are i18n WG internal meta-discussions about the issue. Contribute to the actual discussion at the following link:
§ link_to_issue_raised