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 inheri
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.
This attribute aims for a similar effect, providing developers
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
> han
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 becaus
m 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
ter-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 propo
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 availa
