The definition of first input is imprecise & lacking

[rniwa]

The current definition of the first input is that "the first Event whos[e] type is one of the following:" followed by a list of events. It's unclear why touchstart, mouseenter, mouseover, and input aren't listed there. It's also odd that any of accessibility considerations are not enlisted. Furthermore, it's unclear what "first Event" means. The first in what sense? In the current browsing context? In the current window? This needs to be clarified.

[npm1]

I appreciate the feedback, but I don't appreciate the tone of the title, as "imprecise & lacking" is redundant and using negative adjectives twice for no reason. A much better title could be "The definition of first input is imprecise". But yes it's imprecise - apologies, I recently hastily added that for a request (https://github.com/WICG/event-timing/issues/87) but it needs some additional content. It does not affect the processing model at all though, so it could be marked non-normative.

The current definition of the first input is that "the first Event whos[e] type is one of the following:" followed by a list of events. It's unclear why touchstart, mouseenter, mouseover, and input aren't listed there.

This is briefly explained in the last sentence of the introduction: In particular, this API enables measuring the first input delay, the delay in processing for the first "discrete" input event. I can add a note to explain this more clearly, but the idea is to include inputs that would normally trigger new content appearing on the screen, except for scrolling. input would be meaningful but how would it be the first?

It's also odd that any of accessibility considerations are not enlisted.

Yea we should probably add these sections to our performance specifications, even if they are short.

Furthermore, it's unclear what "first Event" means. The first in what sense? In the current browsing context? In the current window? This needs to be clarified.

This should be clear from https://wicg.github.io/event-timing/#finalize-event-timing, but I can add that information here as well.

[rniwa]

The current definition of the first input is that "the first Event whos[e] type is one of the following:" followed by a list of events. It's unclear why touchstart, mouseenter, mouseover, and input aren't listed there.

This is briefly explained in the last sentence of the introduction: In particular, this API enables measuring the first input delay, the delay in processing for the first "discrete" input event. I can add a note to explain this more clearly, but the idea is to include inputs that would normally trigger new content appearing on the screen, except for scrolling. input would be meaningful but how would it be the first?

There are input modalities that do not involve keydown or mousedown. For that matter, events such as focus and paste should probably be considered as well.

It's also odd that any of accessibility considerations are not enlisted.

Yea we should probably add these sections to our performance specifications, even if they are short.

Critically, many AT allow users to move focus, etc... without necessarily triggering keydown or mousedown.

[npm1]

I separated accessibility into a separate issue. I believe I addressed the rest here. Ok to close?

[npm1]

Ping? @rniwa

[rniwa]

That this seems okay to close.