On Tue, Jul 30, 2024 at 7:05 PM 'Adam Ettenberger' via blink-dev < blink-dev@chromium.org> wrote:
> cc+: fla...@chromium.org, pec...@chromium.org, mahesh...@samsung.com > > Was wondering if you could share some background / motivation into why > `touch-action` was selected for allowing/disallowing handwriting for > Android Stylus Writing. > touch-action <https://w3c.github.io/pointerevents/#the-touch-action-css-property> is used by authors to define for direct manipulation devices whether direct manipulation input devices (touch and pen) should execute their direct manipulation behavior. When the spec was written this only included panning and zooming. 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 treat stylus handwriting as a "direct manipulation" action, which is similarly prevented by touch-action. This attribute aims for a similar effect, providing developers a mechanism > to allowing/disallowing handwriting, and could replace `touch-action` as a > qualifier. > It's unclear to me whether implementing this would mean we don't need to honor touch-action: none. I would not expect someone authoring a drawing application to not have to set handwriting to false, unless perhaps handwriting also is preventable by their event handlers. However, today even the demo from the pointer-events spec doesn't actually call preventDefault on the events. Thanks! > > On Tuesday, July 30, 2024 at 11:42:01 AM UTC-7 Adam Ettenberger wrote: > >> Chose DOMString for a few reasons, primarily some technical differences >> between Boolean and Enumerated attributes. >> >> The intent is for this attribute to be opt-out, i.e., true by default and >> developers may specify when handwriting should not be available. >> Additionally this attribute will be inherited, so developers could >> specify handwriting="false" on the lowest common ancestor to affect a >> subtree of content. >> > It seems to me to be quite similar to the spellcheck attribute which presents its IDL value as a boolean, even though the html attribute effectively supports three values (true, false, unset / invalid). This behavior mirrors recent work regarding the "writingSuggestions >> <https://html.spec.whatwg.org/#dom-writingsuggestions>" attribute. >> >> --- >> >> Boolean attribute <https://html.spec.whatwg.org/#boolean-attributes>: >> Specifying the attribute always evaluates to *true*. It's only possible >> to have a value of *false* by omitting the attribute. >> >> This makes it impossible to implement an inheritance-like behavior, and >> would require the attribute to either be an opt-in (developers need to >> specify handwriting on all inputs), or to rename it so it reads as an >> opt-out attribute (e.g., disableHandwriting) and specify on all inputs that >> shouldn't have handwriting. >> >> Keywords "true", "false", "on", "off" are not valid for boolean >> attributes. >> >> Enumerated attribute >> <https://html.spec.whatwg.org/#keywords-and-enumerated-attributes>: >> Is much more flexible than Boolean attributes, may specify "true" / >> "false" keywords, and may specify behavior for "missing value default" and >> "invalid value default". >> This makes it possible to implement both "true by default" and >> inheritance in the attribute specification. >> >> On Tuesday, July 30, 2024 at 10:28:00 AM UTC-7 Gregg Tavares wrote: >> >>> I'm just curious. Why is it a DOMString and not a boolean? I didn't see >>> that in the explainer >>> >>> >>> >>> On Mon, Jul 29, 2024 at 12:00 PM Chromestatus < >>> ad...@cr-status.appspotmail.com> wrote: >>> >>>> Contact emails adam.ett...@microsoft.com >>>> >>>> Explainer >>>> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Handwriting/explainer.md >>>> >>>> Specification None >>>> >>>> Summary >>>> >>>> This feature provides a standard mechanism to indicate whether an >>>> element or its subtree should allow user agent handwriting input. User >>>> agents that support handwriting recognition as a means to input text using >>>> a pen/stylus will behave differently than a user agent that doesn't support >>>> handwriting. However, this handwriting may not be desirable for all >>>> supported input fields. By specifying the HTML handwriting attribute, >>>> authors can indicate when the user agent should not allow handwriting. >>>> >>>> >>>> Blink component UI>Input>Text >>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:UI%3EInput%3EText> >>>> >>>> Motivation >>>> >>>> To disable handwriting input without this feature, developers would >>>> need to use preventDefault() on pen touch events, assuming that was an >>>> option for the user agent implementation of handwriting input. Android uses >>>> a non-standard `touch-action` configuration to disable handwriting input, >>>> this proposal will provide a standardized mechanism. >>>> >>>> >>>> Initial public proposal None >>>> >>>> TAG review None >>>> >>>> TAG review status Pending >>>> >>>> Risks >>>> >>>> >>>> Interoperability and Compatibility >>>> >>>> None >>>> >>>> >>>> *Gecko*: No signal >>>> >>>> *WebKit*: No signal >>>> >>>> *Web developers*: No signals >>>> >>>> *Other signals*: >>>> >>>> WebView application risks >>>> >>>> Does this intent deprecate or change behavior of existing APIs, such >>>> that it has potentially high risk for Android WebView-based applications? >>>> >>>> None >>>> >>>> >>>> Debuggability >>>> >>>> None >>>> >>>> >>>> Is this feature fully tested by web-platform-tests >>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>> ? No >>>> >>>> Flag name on chrome://flags None >>>> >>>> Finch feature name None >>>> >>>> Non-finch justification None >>>> >>>> Requires code in //chrome? False >>>> >>>> Estimated milestones >>>> >>>> No milestones specified >>>> >>>> >>>> Link to entry on the Chrome Platform Status >>>> https://chromestatus.com/feature/5186620366782464?gate=5076052179943424 >>>> >>>> This intent message was generated by Chrome Platform Status >>>> <https://chromestatus.com>. >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "blink-dev" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to blink-dev+...@chromium.org. >>>> To view this discussion on the web visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/000000000000faa1ae061e677989%40google.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/000000000000faa1ae061e677989%40google.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to blink-dev+unsubscr...@chromium.org. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9521a161-75c9-4740-b936-b9e0b7655c97n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9521a161-75c9-4740-b936-b9e0b7655c97n%40chromium.org?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJh39TPwqL0d4UGohYvgqvxN6POSWWcbmXvc_FD4_idtuSaW2w%40mail.gmail.com.
