> 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/0d62d5b5-5b22-47bd-a1f1-a2fdf7e28909n%40chromium.org.
