[Handwriting] Add Handwriting CSS Value i2i Explainer #903
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
gastonrod
changed the title
Added links to many keywords, clarified some confusing bits, added sections from the template.
ogerchikov
reviewed
Nov 16, 2024
| } | ||
| </style> | ||
|
|
||
| <textarea class="handwritable"></textarea> <!-- the computed handwriting value is true --> |
There was a problem hiding this comment.
Can you please have the same alignment for all the comments for better readability?
ogerchikov
reviewed
Nov 16, 2024
|
|
||
| <div style="touch-action:pan-x;"> | ||
| <textarea></textarea> <!-- the computed handwriting value is false --> | ||
| <textarea style="touch-action:handwriting;"></textarea> <!-- the computed handwriting value is true --> |
There was a problem hiding this comment.
Based on my understanding of [1] and analogy with [2] I think the computed handwriting value is false here. Similar comment for the paragraph below. @adettenb - what do you think?
[1] https://w3c.github.io/pointerevents/#determining-supported-direct-manipulation-behavior
[2] https://w3c.github.io/pointerevents/#example_10
There was a problem hiding this comment.
You're understanding is correct.
These should be false, they have an ancestor that's more restrictive.
For any particular Node, itself and all ancestors must allow handwriting for it to be allowed.
Thanks for catching this!
ogerchikov
reviewed
Nov 16, 2024
| ### Caveats | ||
|
|
||
| A few pain points have been brought up that are worth discussion: | ||
| * Web pages who currently have the `touch-action` property set for different Elements will lose the handwriting capabilities on this element even if they don't want to disable it. When the new keyword ships, the absence of the value will be interpreted as the author of the webpage intently disabling handwriting. |
There was a problem hiding this comment.
I think 'who' should be replace with 'that' and uppercase Elements changed to lowercase.
ogerchikov
reviewed
Nov 16, 2024
| ### Why not extend a different attribute or property? | ||
| [HTML] [inputmode](https://www.w3.org/TR/2002/WD-xforms-20020821/sliceE.html): | ||
| * Related to but distinct from `<input>` `type`. Is only concerned with virtual keyboard inputs. | ||
| [CSS] [pointer-events](https://w3c.github.io/pointerevents/#pointerevent-interface): |
There was a problem hiding this comment.
I think the formatting here is not as intended.
adettenb
reviewed
Nov 16, 2024
|
|
||
| ## Stakeholder Feedback / Opposition | ||
|
|
||
| None other than the discussion linked in the **References and Acknowledgements** section |
There was a problem hiding this comment.
I think it's worth enumerating a few of these as well as referencing the conversations:
touch-actionin 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-ymay be unable to be panned. e.g., when the entire document is editable.
adettenb
reviewed
Nov 16, 2024
Comment on lines
+99
to
+102
| 1. If the computed value for `touch-action` on `element` does not contain the `handwriting` or `manipulation` keyword, **disable handwriting**. | ||
| 2. If the computed value for `touch-action` on `element` does contain the `handwriting` or `manipulation` keyword, **enable handwriting**. | ||
| 3. If the computed value for `touch-action` on `element` is `auto`, search `element`'s parent chain for an ancestor with a non-`auto` computed value for `touch-action`. Apply steps 1 and 2 to the computed value for `touch-action` on the lowest such ancestor. | ||
| 4. If the computed value for `touch-action` on `element` and all of its ancestors is `auto`, **enable handwriting**. |
There was a problem hiding this comment.
Per Olga's comment, please update this section to something along the lines of:
Suggested change
| 1. If the computed value for `touch-action` on `element` does not contain the `handwriting` or `manipulation` keyword, **disable handwriting**. | |
| 2. If the computed value for `touch-action` on `element` does contain the `handwriting` or `manipulation` keyword, **enable handwriting**. | |
| 3. If the computed value for `touch-action` on `element` is `auto`, search `element`'s parent chain for an ancestor with a non-`auto` computed value for `touch-action`. Apply steps 1 and 2 to the computed value for `touch-action` on the lowest such ancestor. | |
| 4. If the computed value for `touch-action` on `element` and all of its ancestors is `auto`, **enable handwriting**. | |
| 1. If the computed value for `touch-action` on `element` and all of its ancestors include either keyword `auto`, `handwriting`, or `manipulation`, **enable handwriting**. | |
| 2. If the computed value for `touch-action` on `element` or any of its ancestors does not include either keyword `auto`, `handwriting`, or `manipulation`, **disable handwriting**. |
adettenb
reviewed
Nov 16, 2024
| * `touch-action: none + HTML handwriting=false` disables handwriting. | ||
| * `touch-action: pan-x pan-y + HTML handwriting=false` disables handwriting. | ||
| * `touch-action: pan-x pan-y + HTML handwriting=true` enables handwriting. | ||
| * `touch-action: none + handwriting=true` disables handwriting? enables handwriting? |
adettenb
reviewed
Nov 16, 2024
| None other than the discussion linked in the **References and Acknowledgements** section | ||
|
|
||
| ## References | ||
| * [Input Method Editors (IME)]() |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Follow up to #808
After a thorough discussion with upstream reviewers [1][https://github.com/w3c/pointerevents/issues/516], it was determined that the best course of action for this feature is to implement it as a new CSS value for the touch-action property instead of a new HTML attribute.
This PR deprecates the existing explainer with the HTML tag proposal and puts forward a new one that proposes a new keyword for the
touch-actionCSS attribute.