Should setInterval account for execution delays to prevent drift?

If I am reading the 'timer initialisation steps' correctly, a timer set with setInterval should (after the delay) invoke the passed function then schedule another callback with the same delay. However, I'm not aware of any browser that actually does this:

• Firefox appears to schedule the next callback before invoking the function, or at least subtracts the execution time from the next delay.
• Chrome and Edge seem to go one step further, also reducing the delay for the next callback if the start of the current invocation was late. This means some intervals may be lower than the specified delay in order to maintain it as an average. (Look for values <10 here: test.)

(Note: I'm ignoring the behaviour of background tabs and cases where the function takes longer to execute than the delay.)

In my opinion the spec should be updated to describe the behaviour of Chrome and Edge, which is clearly the intuitive behaviour for developers. Whilst the spec already notes that it is wrong to rely on the timers for precision, which will still remain the case, it should be possible to rely on setInterval not to cause application-level drift in the order of minutes when the delay is as low as 1s.

Start with the HTML Standard's timer initialisation steps and compare them with the linked Mozilla test and the browser behavior described. Review the 49-comment thread for unresolved consensus; done means an agreed specification change with corresponding timer wording and tests identified.