Tess: We like early reviews, but this is very early.

Jeffrey: They've had discussions in Pointer Events, so it's not as early as the location of the explainer would imply.

Peter: Initial thought is "why?"

Jeffrey: Seems like handwriting and panning were getting confused for each other.

Peter: Might be a UA bug. If it takes text, the UA should accept handwriting, and it shouldn't be the author's problem.

Martin: pan-x + handwriting? Is that nonsense?

Jeffrey: Ask them those 2 questions?

Martin: If something is handwriting, is there an expectation that we draw the handwriting? If you want text input, use <input>, and let the OS/browser deal with the input.

Tess: But sites do wacky things with contenteditable, and I'm tired of yelling at clouds. It's easy in all-too-common shenanigans case to need to say that various regions accept scribbling and others don't. Bad that you end up there because of the compounding of other problems.

Peter: Not excited about supporting the above. Also bad that this proposes to monkeypatch CSS.

Martin: I'm less negative than my initial reaction. People shouldn't do this, but it's not MUST NOT. I don't know enough about touch-action to be able to say.

Tess: Default UA behavior should be good. On a boring HTML page with <input type=text> or <textarea>, handwriting should Just Work without confusing the page. But in the case where there's a disconnect between the thing that accepts input and the thing the user's manipulating, it seems like you need an escape hatch like this. Like in a synthesizer that just watches finger position.

Peter: Then you'd want a value that prevents handwriting, not a value that enables handwriting.

Tess: Not sure there's a use case for opting in.

Peter: How do you get everything but handwriting, including future stuff.

Martin: Think that's the intent of the touch-action attribute anyway. Weird stuff in the MDN page. Can enable panning left but not right. Don't know why you'd want that. Weird restrictions. In most cases, this seems like the dumb thing to do. Think what the explainer says is that if handwriting is enabled, that's what happens. General shape of this proposal isn't terrible.

Tess: Not uniquely ugly; consistent with the rest of touch-action's weirdness.

Martin: Needs to be clearer about how touch-action interacts with other things.

Peter: And the UA stylesheet sets touch-action on <input> and <textarea>?

Martin: Lots of mobile UI will open a box that you handwrite into.

Peter: And then you never handwrite into any element.

Martin: I think this is only for pages that really want to capture user input directly.

Peter: Maybe for when the control is big enough to capture handwriting.

Peter: I'd thought Pointer Events was specific to pen-type devices.

Martin: Nope, fingers are included.

Jeffrey: Should we ask them to talk to the CSSWG?

Tess: It's been a point of contention in the past, but yes.

satisfied with:

Thanks for bring it to us.  We've discussed the feature and it seems like -- while this is a niche sort of thing to want to do -- there are cases where this could be useful.

The design appears to be consistent with the design of touch-action.  We do think that it would be better to clarify the interaction of `handwriting` with other actions that are available.  In many cases, pointer devices (like fingers) are unable to distinguish between a writing and panning mode, so having `touch-action: pan-??? handwriting` doesn't make a lot of sense for those common devices.

We also encourage you to consult with the CSS working group on this.