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.
