Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Handwriting] Add Handwriting CSS Value #1018

Open
1 task done
gastonrod opened this issue Nov 25, 2024 · 5 comments
Open
1 task done

[Handwriting] Add Handwriting CSS Value #1018

gastonrod opened this issue Nov 25, 2024 · 5 comments

Comments

@gastonrod
Copy link

こんにちは TAG-さん!

I'm requesting an early TAG design review of the handwriting keyword for the touch-action CSS attribute.

This feature introduces a new web standard that simplifies enabling or disabling handwriting input across multiple platforms. By specifying a new keyword in the touch-action CSS property, developers can now easily indicate whether an element or its subtree should allow handwriting input.

  • Explainer: MSEdgeExplainers/Handwriting/HandwritingIntentCSSValue.md
  • User research: Handwriting capabilities are being implemented at the moment and when they are shipped developers will need a way to handle their enablement. Once implemented, these capabilities will be enabled by default and users will need a mechanism to disable it.
  • Security and Privacy self-review: Since the proposed property should not interact with other HTML or IDL attributes, DOM properties, or JavaScript APIs in an interesting way, and the property doesn't reflect whether a user agent supports or has enabled handwriting input, it shouldn't be possible to use this for fingerprinting. As of writing this, we are not aware of any way the proposed property could be used towards nefarious means since it's merely a hint for the browser to allow handwriting input and the handwriting state doesn't expose anything about the user nor their device. There are no known security impacts of the features in this specification.
  • GitHub repo: MicrosoftEdge/MSEdgeExplainers
  • Primary contacts:
  • Organization/project driving the design: Microsoft
  • Multi-stakeholder feedback³:
    • Chromium comments: A new chrome Status will be created as soon as I get the needed permissions. Ongoing discussion can be found in the explainer, here are some links [1] [2] [3]

Further details:

  • I have reviewed the TAG's Web Platform Design Principles
  • The group where the incubation/design work on this is being done (or is intended to be done in the future): W3C Web Incubator Community Group, Pointer Events Working Group
  • The group where standardization of this work is intended to be done ("unknown" if not known): Pointer Events Working Group
  • Existing major pieces of multi-implementer review or discussion of this design: Linked under Multi-stakeholder feedback -> Chromium comments
  • Major unresolved issues with or opposition to this design:
    • touch-action in its current state may not be flexible enough for developers needs.
    • The property name, while clearly communicated in the Spec, isn't specific to touch behaviors as it includes stylus/pen actions as well.
    • Developers may want granular control over input type in addition to "actions".
    • Developers may want granular control to specify "action" precedence (handwriting then scrolling, or vice versa).
    • Concerns with how handwriting and panning can intuitively co-exist, since it's possible a scrollable page with touch-action: handwriting pan-y may be unable to be panned. e.g., when the entire document is editable.
  • This work is being funded by: Microsoft

You should also know that...

Feedback from many working groups will likely be required to achieve consensus on the shipping of this feature, as it may affect pointer events, CSS and HTML.

@jyasskin
Copy link
Contributor

What's the adoption state here? I see enough Chrome interest to justify adopting this into the WICG, so ideally you'd have moved it there before filing this TAG review. But I also see discussion inside the Pointer Events WG: is it far enough along that the WG would support adopting it?

@gastonrod
Copy link
Author

There is currently no code implemented for the feature. We are adding a use counter to try to measure how many webpages would be affected by the shipping of this proposal as-is, and I'm working on a prototype PR for chrome.
The first proposal we created was to add an HTML tag to control the enablement of handwriting on elements, but we received some feedback on why using touch action could be a better way of (dis)abling handwriting. We are currently exploring both options and trying to get consensus on what the best mechanism would be to implement to control this feature, which is why I'm submitting the proposal for an early TAG review and will be shortly posting this issue to the editing and html working groups. A discussion is already ongoing on the pointer events WG.

@jyasskin
Copy link
Contributor

Sorry, I meant the state of adoption by community and working groups. https://www.chromium.org/blink/launching-features/#start-incubating:~:text=incubation%20venue mentions proposing the work to an incubation venue before filing the TAG review.

@gastonrod
Copy link
Author

I see, I know starting a TAG review this early isn’t what is recommended by the docs, but since this proposal will likely need input from multiple groups I was recommended to get TAG involved sooner as it could help steer us toward a better solution and catch any big architectural concerns early. Let me know if there are other considerations I should keep in mind, or if you'd prefer we shelf this until the discussion happens in the WGs.

@slightlyoff
Copy link
Member

hey @jyasskin; I think the intent here is to get this into WICG or similar, but I've never understood our guidance in the Blink launch process to gate requesting TAG feedback on repo location, particularly for early reads.

Happy to work with you and @chrishtr to clarify on the Blink side.

@gastonrod: thanks for filing this. I think it's good advice to request moving to a more formal incubation venue, but hopefully that won't block this thread.

@plinss plinss added this to the 2024-12-16-week milestone Dec 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants