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.

Reply via email to