Hey Robert, Just checking in, wanted to see what your thoughts are for introducing a `touch-action: handwriting` keyword instead, or if you had a strong preference for one of the other proposals you mentioned? Also, is there another forum that's be better for this discussion?
Thanks, ~Adam On Friday, August 2, 2024 at 5:55:20 PM UTC-7 Adam Ettenberger wrote: > > 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. > > The goal was that developers wouldn't have to specify handwriting for each > element individually unless they had a need to. > I guess they'd likely set this on the same element that would have > `touch-action`, probably the top-level "canvas", "document", or "form" > element then all of the text controls within would inherit the state. > > Among the existing CSS/HTML properties/attribute, I think `touch-action` > is the best candidate for disabling handwriting. > Maybe instead of a `handwriting` attribute, a `handwriting` keyword could > be added to `touch-action` and included in the set of `manipulation` > actions? > > A canvas, document editor, or form input might want granular control based > on which editing tool is selected. For example: > - [🖱️] *pointer-tool:* auto. > - [✋] *panning-tool:* disables handwriting. > - [🖌️] *drawing-tool: *disables both panning and handwriting. > - [🔠] *text-tool:* disables panning. > > I don't think preventDefault will be an option if they want to use the > default touch/stylus scrolling behavior while preventing handwriting when > handwriting is tied to pan-x and pan-y. > If it were possible to distinguish between touch and stylus inputs for > `touch-action`, a developer might want to always allow panning with touch > input but selectively for stylus input for those tools. > > > Applications which have a strict format should have that format listed > as a pattern value and the browser can decide if the handwriting IME is > capable of honoring the pattern. > > There could be a legal form that requires a strict but not standardizable > format. > For example, a field that needs to be an exact character-to-character > match with the same the capitalization, spacing, and punctuation as an > existing legal document. > Handwriting may not provide the best experience for such an input. > > > I'm not sure what the special characters use case you were thinking of, > perhaps you could elaborate on this one? > > I don't remember exactly what I had in mind for this one when I added that > bit 😅. > I can't think of a good example for this now. > > --- > > Is there a better forum for this discussion? > It sounds like introducing an HTML `handwriting` attribute may no be the > right approach, but I also think the current iteration of `touch-action` > may not be sufficient for allowing developers filter default touch/stylus > behaviors granularly. > > On Wednesday, July 31, 2024 at 7:39:58 PM UTC-7 Robert Flack wrote: > >> I'm concerned this may not be the right property. 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. >> IMO this covers these two use cases from your explainer as well as other >> drawing applications: >> >> - Document editor that wants to temporarily disable handwriting input >> while certain tools are selected, to support using a stylus to seamlessly >> draw, place, or size non-text content overtop an editable text region. >> - Application with custom text inputs or editing experiences that >> override default browser behaviors by observing and handling input events >> and editing experiences, doesn't support input method editor (IME) or >> composition{start|end|update} events, or if for any reason the experience >> designed by website authors doesn't behave as they intend when >> handwriting >> input is available. >> >> The declarative pointer-event solution could be better augmented by >> spec'ing and implementing pointer-action >> <https://github.com/w3c/pointerevents/issues/203> and/or something >> similar to the direct-manipulation >> <https://github.com/w3c/pointerevents/issues/203#issuecomment-819693123> >> property >> I proposed on that issue or one that otherwise selects which default action >> a pointing device should take. >> >> For the non-custom pointer-event handling use cases, I think there are >> better alternate mechanisms. E.g. from those use cases you mentioned: >> >> - Application with custom form controls that accept sensitive input >> may also want to avoid using a custom system IME, so they should have a >> hint to be treated like a password field >> - Applications which have a strict format should have that format >> listed as a pattern value and the browser can decide if the handwriting >> IME >> is capable of honoring the pattern. >> - I'm not sure what the special characters use case you were thinking >> of, perhaps you could elaborate on this one? >> >> I'm further concerned that offering a mechanism to disable handwriting >> not because they're replacing it but just to disable handwriting may >> encourage authors to do so even if it reduces the accessibility of users >> visiting their site. E.g. it will prevent users from using their device's >> normal handwriting input capability. >> >> On Wed, Jul 31, 2024 at 3:02 PM Robert Flack <fla...@chromium.org> wrote: >> >>> On Tue, Jul 30, 2024 at 7:05 PM 'Adam Ettenberger' via blink-dev < >>> blin...@chromium.org> wrote: >>> >>>> cc+: fla...@chromium.org, pec...@chromium.org, mahe...@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+...@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/5c768554-b0d0-4b1b-8eb7-f968e275000cn%40chromium.org.