-
Notifications
You must be signed in to change notification settings - Fork 74
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
Add UI Events as features, update existing events #2285
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think doing this rename makes some sense, but it's a breaking change. I'd rather not do those one at a time, since we have some other features that ought to be renamed. Would you undo this change and file an issue instead?
(The changes to the keys are fine.)
caniuse: focusin-focusout-events | ||
status: | ||
compute_from: api.Element.focus_event |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To align with caniuse, this needs to be pinned to focusin
and focusout
but BCD has a very different take on whether or not to mark them supported or not. Would you mind removing all of this and filing an issue in its place, and linking the issue back to this PR discussion?
caniuse: focusin-focusout-events | |
status: | |
compute_from: api.Element.focus_event |
@@ -0,0 +1,10 @@ | |||
name: Composition events | |||
description: Composition Events are a method of adding text containing characters that might not be commonly available on keyboard, from emoji to logograms in Asian languages to input from speech recognition processors. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would you mind changing the descriptions for all of these to use the convention that we have for other event features?
[one event] The
foo
event fires when…
[multiple events] Thebar
,baz
, andqux
events fire when…
[too many events to name] Mouse events, such asclick
,mousedown
, ormousemove
, fire when…
I'm guessing you've already familiarized yourself with these and it'll move a lot faster if you seed these conventionally first.
description: Keyboard events describe a single interaction between the user and a key (or combination of a key with modifier keys) on the keyboard. | ||
spec: https://w3c.github.io/uievents/#events-keyboardevents | ||
status: | ||
compute_from: api.KeyboardEvent.KeyboardEvent |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should pin to the _event
keys
description: Wheel events occur when the user moves a mouse wheel or similar spatially rotating input device. | ||
spec: https://w3c.github.io/uievents/#events-wheelevents | ||
status: | ||
compute_from: api.WheelEvent |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pin to the _event
keys. If the event doesn't actually fire, there's no sense reporting the status of the interface.
spec: https://w3c.github.io/pointerevents/ | ||
caniuse: pointer | ||
status: | ||
compute_from: api.PointerEvent |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pin to _event
keys only
And some tweaks to input and mouse events features.