You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm requesting a TAG review of the normative changes of the Input Events Level 2.
The Input Events spec defines additions to events for text and related input to allow for the monitoring and manipulation of default browser behavior in the context of text editor applications and other applications that deal with text input and text formatting.
Explainer¹: http://w3c.github.io/editing/ (includes explanation for why contenteditable as it exists today is problematic and why additions such as the beforeinput event are needed)
Security and Privacy self-review²:
(1) PII? No
(2) High value data? No
(3) New state that persists across browsing sessions? No
(4) Persistent, cross-origin state? No
(5) Newly expose data to an origin? No
(6) New script exe/loading? No
(7) Access location? No
(8) Access sensors? No
(9) Access local computing environment? No.
(10) Access other devices? No
(11) Control over UA's UI? No
(12) Expose temp IDs? No
(13) 1st party vs. 3rd party contexts? No
(14) What about "incognito"? No changes
(15) Local data persist? No
(16) "Security Considerations" and "Privacy Considerations"? There are
no known security or privacy impacts of this feature beyond
fingerprinting [ fingerprinting-guidance] techniques that already are
available through existing events, such as the keydown and keypress [
UI-EVENTS] events.
(17) Downgrade default security? N
こんにちは TAG-さん!
I'm requesting a TAG review of the normative changes of the Input Events Level 2.
The Input Events spec defines additions to events for text and related input to allow for the monitoring and manipulation of default browser behavior in the context of text editor applications and other applications that deal with text input and text formatting.
Explainer¹: http://w3c.github.io/editing/ (includes explanation for why contenteditable as it exists today is problematic and why additions such as the beforeinput event are needed)
Specification: https://w3c.github.io/input-events/ (Please review the list of normative changes since 2018 at the following link: Horizontal Review of Input events w3c/input-events#166)
WPT Tests: https://github.com/web-platform-tests/wpt/tree/master/input-events
User research:
Security and Privacy self-review²:
(1) PII? No
(2) High value data? No
(3) New state that persists across browsing sessions? No
(4) Persistent, cross-origin state? No
(5) Newly expose data to an origin? No
(6) New script exe/loading? No
(7) Access location? No
(8) Access sensors? No
(9) Access local computing environment? No.
(10) Access other devices? No
(11) Control over UA's UI? No
(12) Expose temp IDs? No
(13) 1st party vs. 3rd party contexts? No
(14) What about "incognito"? No changes
(15) Local data persist? No
(16) "Security Considerations" and "Privacy Considerations"? There are
no known security or privacy impacts of this feature beyond
fingerprinting [ fingerprinting-guidance] techniques that already are
available through existing events, such as the keydown and keypress [
UI-EVENTS] events.
(17) Downgrade default security? N
GitHub repo: https://github.com/w3c/input-events
Primary contacts:
Organization/project driving the specification: the W3C WebEditing WG
Multi-stakeholder support³:
Status/issue trackers for implementations⁴: https://wpt.fyi/results/input-events?label=experimental&label=master&aligned
Further details:
You should also know that...
The text was updated successfully, but these errors were encountered: