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

I think this seems like a reasonable proposal that's trying to address a worthwhile goal.

I know I and others have expressed some concerns in the past about how well the web performance specifications fit together in a way that allows multiple implementations to interoperate.  Analyzing that without implementing (or at least without more background in implementing the set of specs) is hard, so I haven't attempted to analyze whether this specification makes that problem any worse, but I'm hoping it doesn't.

A few specific comments on the spec:

-----

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.

-----

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.

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.

-----

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.

-----

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.  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.

-- 
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-493838495