From 670c809e7b238e842f013438222ae6c16401270d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Gast=C3=B3n=20Rodr=C3=ADguez?= Date: Tue, 7 Jan 2025 14:56:08 -0800 Subject: [PATCH 1/3] Update HandwritingIntentCSSValue.md --- Handwriting/HandwritingIntentCSSValue.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/Handwriting/HandwritingIntentCSSValue.md b/Handwriting/HandwritingIntentCSSValue.md index 51df0b19..494b8dd1 100644 --- a/Handwriting/HandwritingIntentCSSValue.md +++ b/Handwriting/HandwritingIntentCSSValue.md @@ -107,7 +107,7 @@ All CSS properties have computed values for all elements. The enablement of hand A few pain points have been brought up that are worth discussion: * Web pages that currently have the `touch-action` property set for different elements will lose the handwriting capabilities on this element even if they don't want to disable it. When the new keyword ships, the absence of the value will be interpreted as the author of the webpage intentionally disabling handwriting. * Authors that specify `touch-action: manipulation` will be enabling `handwriting`, even when they might not want the behavior enabled in their webpage. These authors would then need to update their webpages to explicitly mention which behaviors they want, i.e. : `touch-action: pan-x pan-y pinch-zoom`. -* Using `touch-action` restricts handwriting implementations to touch input devices (such as stylus and touch), even though a platform could support handwriting capabilities for other controls, like mouse pointer events. +* Using `touch-action` restricts handwriting implementations to touch input devices (such as stylus and touch), even though a platform could support handwriting capabilities for other devices, like mouse pointer events. * `touch-action` determines which behaviors are allowed for touch input devices regardless of which device is being used, either touch or stylus. In the future, these input devices might be separated into two different CSS attributes to allow things like, say, enable panning with finger touch events and only enable handwriting with a stylus. ## Privacy and Security Considerations @@ -127,11 +127,15 @@ The proposal is for this to be an CSS property. The [first proposal](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Handwriting/explainer.md) was to add the handwriting functionality as an HTML+IDL attribute which would allow authors to specify whether an element should permit handwriting by adding a new `handwriting(= true|= false|)` (`` implying `= true`) attribute to HTML elements. The main arguments to implement the handwriting HTML attribute **over** a css property are: * [Pro] If users or organizations disable CSS for their browsers there would need to be another mechanism to disable handwriting input. * [Pro] All websites that currently use `touch-action` won't have to update their rules if they want handwriting to be enabled (see **# Caveats / Cons**). +* [Pro] Straightforward to use for the developers. +* [Pro] Does not differentiate between touch and other devices. After some discussion [[1](https://groups.google.com/a/chromium.org/g/blink-dev/c/0r_tV6k0NyA?pli=1)] [[2](https://github.com/w3c/pointerevents/issues/516)], it became apparent that implementing the functionality in the `touch-action` CSS attribute was the better alternative. The main arguments in favor of `touch-action` were: * Authors are used to the [recommended practice of adding touch-action: none](https://w3c.github.io/pointerevents/#example_10) to elements over which they wish to handle all events themselves. In order to allow sites for which authors following this recommended practice to continue working, we should treat stylus handwriting as a "direct manipulation" action, which is similarly prevented by touch-action. -* If implemented as an HTML attribute, `touch-action`'s interaction with the attribute would have to be clearly defined and possibly clash with authors' expectations (see following section). +* If implemented as an HTML attribute, `touch-action`'s interaction with the attribute would have to be clearly defined and possibly clash with authors' expectations (see following section). See the following quote from the [discussion](https://groups.google.com/a/chromium.org/g/blink-dev/c/0r_tV6k0NyA/m/dkpayEBmBAAJ): + +> [...] For use cases where the author wants to handle the pointerevents themselves (e.g. in order to accept free-form drawing) they should be using touchaction or preventDefault on the events to tell the browser they are handling them. They shouldn't have to recognize that if there happens to be an input field underneath or nearby that they need to disable handwriting on it. The developer authoring the drawing widget may not be aware that it may be on top of or near an input element, and it seems bad if they need to find such elements and disable handwriting on them." ### Why not an HTML+IDL attribute that interacts with `touch-action`? From 1600f594112e7da1fa6e1f000366ee848b041cf5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Gast=C3=B3n=20Rodr=C3=ADguez?= Date: Tue, 7 Jan 2025 15:14:55 -0800 Subject: [PATCH 2/3] Update HandwritingIntentCSSValue.md Add *Handwriting interactions* section. --- Handwriting/HandwritingIntentCSSValue.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/Handwriting/HandwritingIntentCSSValue.md b/Handwriting/HandwritingIntentCSSValue.md index 494b8dd1..3567c5d5 100644 --- a/Handwriting/HandwritingIntentCSSValue.md +++ b/Handwriting/HandwritingIntentCSSValue.md @@ -93,7 +93,13 @@ Authors are used to the [recommended practice of adding touch-action: none](http The `handwriting` keyword indicates whether an element and the element's descendants will allow handwriting input when supported by the user agent. Handwriting will only be allowed for an element when its computed `touch-action` includes the `handwriting` keyword. By default, `auto` and `manipulation` will include the `handwriting` keyword. -Note that `touch-action` does not indicate that some actions should take precedence over others, so discerning which interaction the pointer events should trigger will be the responsibility of the User Agent. For example, differentiating between a _pan-*_ gesture and a _handwriting_ gesture if both are avaialable. +Note that `touch-action` does not indicate that some actions should take precedence over others, so discerning which interaction the pointer events should trigger will be the responsibility of the User Agent. For example, differentiating between a _pan-*_ gesture and a _handwriting_ gesture if both are available. + +#### Keyword interactions + +Distinction between gesture intentions is left to the User Agent, and determining whether a user intends to pan, zoom or write is beyond the scope of this keyword which only determines if the feature is available. In scenarios where both `handwriting` and `pan-*` are enabled (such as `auto` or `manipulation`, etc.) the User Agent will be responsible for determining which action takes place. + +User Agents may implement certain capabilities to be exclusive to certain devices, like handwriting only being available for styluses. At the moment, the `touch-action` property does not allow for a granular enablement of feature by discriminating between pointer devices. It will be the responsibility of User Agents to handle these complexities when implementing the `handwriting` keyword. ### Determining enablement From 2035e6d1b5612eeb6d7ab9ae945c831f3439b5f9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Gast=C3=B3n=20Rodr=C3=ADguez?= Date: Tue, 7 Jan 2025 15:15:30 -0800 Subject: [PATCH 3/3] Update HandwritingIntentCSSValue.md Remove redundant paragraph. --- Handwriting/HandwritingIntentCSSValue.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/Handwriting/HandwritingIntentCSSValue.md b/Handwriting/HandwritingIntentCSSValue.md index 3567c5d5..f879f82e 100644 --- a/Handwriting/HandwritingIntentCSSValue.md +++ b/Handwriting/HandwritingIntentCSSValue.md @@ -93,8 +93,6 @@ Authors are used to the [recommended practice of adding touch-action: none](http The `handwriting` keyword indicates whether an element and the element's descendants will allow handwriting input when supported by the user agent. Handwriting will only be allowed for an element when its computed `touch-action` includes the `handwriting` keyword. By default, `auto` and `manipulation` will include the `handwriting` keyword. -Note that `touch-action` does not indicate that some actions should take precedence over others, so discerning which interaction the pointer events should trigger will be the responsibility of the User Agent. For example, differentiating between a _pan-*_ gesture and a _handwriting_ gesture if both are available. - #### Keyword interactions Distinction between gesture intentions is left to the User Agent, and determining whether a user intends to pan, zoom or write is beyond the scope of this keyword which only determines if the feature is available. In scenarios where both `handwriting` and `pan-*` are enabled (such as `auto` or `manipulation`, etc.) the User Agent will be responsible for determining which action takes place.