Re: [w3ctag/design-reviews] Event Timing API (#324)

> A few sections say:
> 
> > This section will be removed once the DOM specification has been modified.
> 
> but I'd note it might be desirable to refer to the modified section somehow once the modifications are made, rather than deleting the section.

Thanks for the feedback. We will keep this in mind when we get there, though I'm not sure it is possible to have much text other than maybe a non-normative note pointing to where the concepts are defined.

> The [Queueing other entries](https://wicg.github.io/event-timing/#sec-queue-other) section has some wording (about skipping steps of the event dispatch algorithm when there are no event handlers) that makes me wonder about the choice of "first event". In particular, the first click or the first key might not be the user actually trying to interact with the page functionality; many users do things like select text while they're reading or click in blank areas to control what has focus. If those things count as the first event, the results might be misleading -- especially if those things don't have event handlers. I think Travis raised this before, and I think your reply is a reasonable justification for the current design, although I also think it may be worth calling out in the text of the specification as an issue so that readers are aware of the meaning of firstInput events and how to understand them.

Yep, first input may not be meaningful. I have filed an [issue](https://github.com/WICG/event-timing/issues/50) to add a note about this.

> I'd also note that it's not clear from this section how the [create an event timing entry](https://wicg.github.io/event-timing/#create-an-event-timing-entry) definition is used.

Yep, that section is a little bit confusing. The point is to try to specify what can be done if a user agent wants an event surfaced from outside of the event dispatching logic. There is already an [issue](https://github.com/WICG/event-timing/issues/34) for this, I'm leaning towards simply removing the section if it is deemed too confusing.

> The [Security and Privacy Considerations](https://wicg.github.io/event-timing/#priv-sec) section refers to some things that aren't in the specification. In particular, it refers to a choice of a 104ms cutoff that is not documented anywhere in the spec, but seems like it should be.

The [Events exposed section](https://wicg.github.io/event-timing/#sec-events-exposed) is vague about it, but I can hard-code the threshold (right now it says "a certain threshold") there if that would make it clearer? The [algorithm](https://wicg.github.io/event-timing/#sec-dispatch-pending) does include the number.

> I'd note that I haven't really dug into the "Processing Model" sections in detail. It seems like it would be useful to have some explanatory material about what those sections do. For example, it seems like this section creates two kinds of timing entries, "firstInput" and "event"; perhaps something should explain in a few sentences which parts of these algorithms create those entries (or change one type to the other) and give them the correct times.

Ok, maybe splitting the algorithm to encapsulate the part that creates firstInput would help?

> Another example of something that might be worth pointing out in prose is that it's possible to get two entries representing the same event (one of each entryType) if an event is both the first input and longer than 104ms. There are probably a bunch of other similar things worth pointing out to readers (including, say, those who are likely to document and teach the specification) that you're aware of but that might not be obvious without very careful consideration of the algorithms in the Processing Model section that might only be done by an implementor.

Ok, this sounds like it could go in the introductory section. Anyways, filed an [issue](https://github.com/WICG/event-timing/issues/51)

> This seems like it's tightly tied to the work that's done in the Web Performance Working Group -- to what extent has it been discussed with the other participants of that working group, and is there a plan to move it there?

It has been presented to the group in various occasions and there is general consensus that this is a useful API. The plan is indeed to eventually move it from incubation to that group.

By the way, thank you for providing the feedback!


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/324#issuecomment-494934626