# Event Timing API

## Draft Community Group Report, 1 January 1970

This version:
  https://wicg.github.io/event-timing
Test Suite:
  https://github.com/web-platform-tests/wpt/tree/master/event-timing
Editors:
  Nicolás Peña Moreno (Google)
  Tim Dresser (Google)

Copyright © 1970 the Contributors to the Event Timing API Specification, published by the Web Platform Incubator Community Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.

## Abstract

This document defines an API that provides web page authors with insights into the latency of certain events triggered by user interactions.

## Status of this document

This specification was published by the Web Platform Incubator Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

## 1. Introduction

This section is non-normative.

When a user engages with a website, they expect their actions to cause changes to the website quickly. In fact, research suggests that any user input that is not handled within 100ms is considered slow. Therefore, it is important to surface input events that could not achieve those guidelines.

A common way to monitor event latency consists of registering an event listener. The timestamp at which the event was created can be obtained via the event’s `timeStamp`. In addition, `performance.now()` could be called both at the beginning and at the end of the event handler logic. By subtracting the hardware timestamp from the timestamp obtained at the beginning of the event handler, the developer can compute the input delay: the time it takes for an input to start being processed. By subtracting the timestamp obtained at the beginning of the event handler from the timestamp obtained at the end of the event handler, the developer can compute the amount of synchronous work performed in the event handler. Finally, when inputs are handled synchronously, the duration from event hardware timestamp to the next paint after the event is handled is a useful user experience metric.

This approach has several fundamental flaws. First, requiring event listeners precludes measuring event latency very early in the page load because listeners will likely not be registered yet at that point in time. Second, developers that are only interested in the input delay might be forced to add new listeners to events that originally did not have one. This adds unnecessary performance overhead to the event latency calculation. And lastly, it would be very hard to measure asynchronous work caused by the event via this approach.

This specification provides an alternative to event latency monitoring that solves some of these problems. Since the user agent computes the timestamps, there is no need for event listeners in order to measure performance. This means that even events that occur very early in the page load can be captured. This also enables visibility into slow events without requiring analytics providers to attempt to patch and subscribe to every conceivable event. In addition to this, the website’s performance will not suffer from the overhead of unneeded event listeners. Finally, this specification allows developers to obtain detailed information about the timing of the rendering that occurs right after the event has been processed. This can be useful to measure the overhead of website modifications that are triggered by events.

The very first user interaction has a disproportionate impact on user experience, and is often disproportionately slow. It’s slow because it’s often blocked on JavaScript execution that is not properly split into chunks during page load. The latency of the website’s response to the first user interaction can be considered a key responsiveness and loading metric. To that effect, this API surfaces all the timing information about this interaction, even when this interaction is not handled slowly. This allows developers to measure percentiles and improvements without having to register event handlers. In particular, this API enables measuring the first input delay (FID), the delay in processing for the first "discrete" input event.

### 1.1. Events exposed

The Event Timing API exposes timing information for certain events. Certain types of events are considered, and timing information is exposed when the time difference between user input and paint operations that follow input processing exceeds a certain threshold.

Given an event, to determine if it should be considered for Event Timing, run the following steps:

1. If event’s `isTrusted` attribute value is set to false, return false.

2. If event’s `type` is one of the following: `auxclick`, `click`, `dblclick`, `mousedown`, `mouseenter`, `mouseleave`, `mouseout`, `mouseover`, `mouseup`, `pointerover`, `pointerenter`, `pointerdown`, `pointerup`, `pointercancel`, `pointerout`, `pointerleave`, `gotpointercapture`, `lostpointercapture` `touchstart`, `touchend`, `touchcancel`, `keydown`, `keyup`, `beforeinput`, `input`, `compositionstart`, `compositionupdate`, `compositionend`, `dragstart`, `dragend`, `dragenter`, `dragexit`, `dragleave`, `dragover`, `drop`, return true.

3. Return false.

Note: `mousemove`, `pointermove`, `touchmove`, `wheel`, and `drag` are excluded because these are "continuous" events. The current API does not have enough guidance on how to count and aggregate these events to obtain meaningful performance metrics based on entries. Therefore, these event types are not exposed.

The Event Timing API also exposes timing information about the first user interaction among the following:

- `keydown`

- `mousedown`

- `pointerdown` which is followed by `pointerup`

- `click`

### 1.2. Usage example

        const observer = new PerformanceObserver(function(list) {
            const perfEntries = list.getEntries().forEach(entry => {
                const inputDelay = entry.processingStart - entry.startTime;
                // Report the input delay when the processing start was provided.
                // Also report the full input duration via entry.duration.
            });
        });
        // Register observer for event.
        observer.observe({entryTypes: ["event"]});
        ...
        // We can also directly query the first input information.
        new PerformanceObserver(function(list, obs) {
            const firstInput = list.getEntries()[0];

            // Measure the delay to begin processing the first input event.
            const firstInputDelay = firstInput.processingStart - firstInput.startTime;
            // Measure the duration of processing the first input event.
            // Only use when the important event handling work is done synchronously in the handlers.
            const firstInputDuration = firstInput.duration;
            // Process the first input delay and perhaps its duration...

            // Disconnect this observer since callback is only triggered once.
            obs.disconnect();
        }).observe({type: 'first-input', buffered: true});

    }

The following are sample use cases that could be achieved by using this API:

- Gather FID data (see `firstInputDelay` on the example above) on a website and track its performance over time.

- Clicking a button changes the sorting order on a table. Measure how long it takes from the click until we display reordered content.

- A user drags a slider to control volume. Measure the latency to drag the slider.

- Hovering a menu item triggers a flyout menu. Measure the latency for the flyout to appear.

- Measure the 75’th percentile of the latency of the first user click (whenever click happens to be the first user interaction).

## 2. Event Timing

Event Timing adds the following interfaces:

### 2.1. `PerformanceEventTiming` interface

    [Exposed=Window]
    interface PerformanceEventTiming : PerformanceEntry {
        readonly attribute DOMHighResTimeStamp processingStart;
        readonly attribute DOMHighResTimeStamp processingEnd;
        readonly attribute boolean cancelable;
        [Default] object toJSON();
    };

Note: A user agent implementing the Event Timing API would need to include "`first-input`" and "`event`" in `supportedEntryTypes` for `Window` contexts. This allows developers to detect support for event timing.

This remainder of this section is non-normative. The values of the attributes of `PerformanceEventTiming` are set in the processing model in § 3 Processing model. This section provides an informative summary of how they will be set.

Each `PerformanceEventTiming` object reports timing information about an associated `Event`.

`PerformanceEventTiming` extends the following attributes of the `PerformanceEntry` interface:

`name`
  The `name` attribute’s getter provides the associated event’s `type`.
`entryType`
  The `entryType` attribute’s getter returns "`event`" (for long events) or "`first-input`" (for the first user interaction).
`startTime`
  The `startTime` attribute’s getter returns the associated event’s `timeStamp`.
`duration`
  The `duration` attribute’s getter returns the difference between the time of the first update the rendering step occurring after associated event has been dispatched and the `startTime`, rounded to the nearest 8ms.

`PerformanceEventTiming` has the following additional attributes:

`processingStart`
  The `processingStart` attribute’s getter returns a timestamp captured at the beginning of the event dispatch algorithm. This is when event handlers are about to be executed.
`processingEnd`
  The `processingEnd` attribute’s getter returns a timestamp captured at the end of the event dispatch algorithm. This is when event handlers have finished executing. It’s equal to `processingStart` when there are no such event handlers.
`cancelable`
  The `cancelable` attribute’s getter returns the associated event’s `cancelable` attribute value.

### 2.2. `EventCounts` interface

    [Exposed=Window]
    interface EventCounts {
        readonly maplike<DOMString, unsigned long long>;
    };

The `EventCounts` object is a map where the keys are event types and the values are the number of events that have been dispatched that are of that `type`. Only events whose `type` is supported by `PerformanceEventTiming` entries (see section § 1.1 Events exposed) are counted via this map.

### 2.3. Extensions to the `Performance` interface

    [Exposed=Window]
    partial interface Performance {
        [SameObject] readonly attribute EventCounts eventCounts;
    };

The `eventCounts` attribute’s getter returns a map with entries of the form type → numEvents. This means that there have been numEvents dispatched such that their `type` attribute value is equal to type.

## 3. Processing model

### 3.1. Modifications to the DOM specification

This section will be removed once the DOM specification has been modified.

We modify the event dispatch algorithm as follows.

Right after step 1, we add the following step:

- Let timingEntry be the result of initializing event timing given event and the current high resolution time.

Right before the returning step of that algorithm, add the following step:

- Finalize event timing passing timingEntry, target, and the current high resolution time as inputs.

Note: If a user agent skips the event dispatch algorithm, it can still choose to include an entry for that `Event`. In this case, it will estimate the value of `processingStart` and set the `processingEnd` to the same value.

### 3.2. Modifications to the HTML specification

This section will be removed once the HTML specification has been modified.

Each `Window` has pending event entries, a list that stores `PerformanceEventTiming` objects, which will initially be empty. Each `Window` also has pending pointer down, a pointer to a `PerformanceEventTiming` entry which is initially null. Finally, each `Window` has has dispatched input event, a boolean which is initially set to false.

In the update the rendering step of the event loop processing model, add a step right after the step that calls mark paint timing:

1. For each fully active `Document` in docs, invoke the algorithm to dispatch pending Event Timing entries for that `Document`.

### 3.3. Initialize event timing

When asked to initialize event timing, with event and processingStart as inputs, run the following steps:

1. If the algorithm to determine if event should be considered for Event Timing returns false, then return null.

2. Let timingEntry be a new `PerformanceEventTiming` object.

3. Set timingEntry’s `name` to event’s `type` attribute value.

4. Set timingEntry’s `entryType` to "`event`".

5. Set timingEntry’s `startTime` to event’s `timeStamp` attribute value.

6. Set timingEntry’s `processingStart` to processingStart.

7. Set timingEntry’s `cancelable` to event’s `cancelable` attribute value.

8. Return timingEntry.

### 3.4. Finalize event timing

When asked to to finalize event timing, with timingEntry, target, and processingEnd as inputs, run the following steps:

1. If timingEntry is null, return.

2. Let relevantGlobal be target’s relevant global object.

3. If relevantGlobal does not implement `Window`, return.

4. Set timingEntry’s `processingEnd` to processingEnd.

5. Append timingEntry to relevantGlobal’s pending event entries.

### 3.5. Dispatch pending Event Timing entries

When asked to dispatch pending Event Timing entries for a `Document` doc, run the following steps:

1. Let window be doc’s relevant global object.

2. Let renderingTimestamp be the current high resolution time.

3. For each timingEntry in window’s pending event entries:

   1. Let start be timingEntry’s `startTime` attribute value.

   2. Set timingEntry’s `duration` by running the following steps:

      1. Let difference be `renderingTimestamp - start`.

      2. Set timingEntry’s `duration` to the result of rounding difference to the nearest multiple of 8.

   3. Let name be timingEntry’s `name` attribute value.

   4. Perform the following steps to update the event counts:

      1. Let performance be window’s `performance` attribute value.

      2. If performance’s `eventCounts` attribute value does not contain a map entry whose key is name, then:

         1. Let mapEntry be a new map entry with key equal to name and value equal to 1.

         2. Add mapEntry to performance’s `eventCounts` attribute value.

      3. Otherwise, increase the map entry’s value by 1.

   5. If timingEntry’s `duration` attribute value is greater than or equal to 104, then queue timingEntry.

   6. If window’s has dispatched input event is false, run the following steps:

      1. If name is "`pointerdown`", run the following steps:

         1. Set window’s pending pointer down to a copy of timingEntry.

         2. Set the `entryType` of window’s pending pointer down to "`first-input`".

      2. Otherwise, run the following steps:

         1. If name is "`pointerup`" AND if window’s pending pointer down is not null, then:

            1. Set window’s has dispatched input event to true.

            2. Queue window’s pending pointer down.

         2. Otherwise, if name is one of "`click`", "`keydown`" or "`mousedown`", then:

            1. Set window’s has dispatched input event to true.

            2. Let newFirstInputDelayEntry be a copy of timingEntry.

            3. Set newFirstInputDelayEntry’s `entryType` to "`first-input`".

            4. Queue the entry newFirstInputDelayEntry.

## 4. Security & privacy considerations

We would not like to introduce more high resolution timers to the web platform due to the security concerns entailed by such timers. Event handler timestamps have the same accuracy as `performance.now()`. Since `processingStart` and `processingEnd` could be computed without using this API, exposing these attributes does not produce new attack surfaces. Thus, `duration` is the only one which requires further consideration.

The `duration` has an 8 millisecond granularity (it is computed as such by performing rounding). Thus, a high resolution timer cannot be produced from this timestamps. However, it does introduce new information that is not readily available to web developers: the time pixels draw after an event has been processed. We do not find security or privacy concerns on exposing the timestamp, especially given its granularity. In an effort to expose the minimal amount of new information that is useful, we decided to pick 8 milliseconds as the granularity. This allows relatively precise timing even for 120Hz displays.

The choice of 104ms as the cutoff value for the `duration` is just the first multiple of 8 greater than 100ms. An event whose rounded duration is greater than or equal to 104ms will have its pre-rounded duration greater than or equal to 100ms. Such events are not handled in accordance with the RAIL performance model, which suggests applications respond within 100ms to user input.

## Conformance

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with `class="example"`, like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with `class="note"`, like this:

Note, this is an informative note.

## Index

### Terms defined by this specification

- associated Event, in §2.1
- cancelable, in §2.1
- considered for Event Timing, in §1.1
- dispatch pending Event Timing entries, in §3.5
- EventCounts, in §2.2
- eventCounts, in §2.3
- finalize event timing, in §3.4
- has dispatched input event, in §3.2
- initialize event timing, in §3.3
- pending event entries, in §3.2
- pending pointer down, in §3.2
- PerformanceEventTiming, in §2.1
- processingEnd, in §2.1
- processingStart, in §2.1
- toJSON(), in §2.1

https://dom.spec.whatwg.org/#document Referenced in:

- 3.2. Modifications to the HTML specification (2)
- 3.5. Dispatch pending Event Timing entries

https://dom.spec.whatwg.org/#event Referenced in:

- 2.1. PerformanceEventTiming interface
- 3.1. Modifications to the DOM specification

https://dom.spec.whatwg.org/#dom-event-cancelable Referenced in:

- 2.1. PerformanceEventTiming interface
- 3.3. Initialize event timing

https://dom.spec.whatwg.org/#concept-event-dispatch Referenced in:

- 2.1. PerformanceEventTiming interface (2)
- 3.1. Modifications to the DOM specification (2)

https://dom.spec.whatwg.org/#dom-event-istrusted Referenced in:

- 1.1. Events exposed

https://dom.spec.whatwg.org/#dom-event-timestamp Referenced in:

- 1. Introduction
- 2.1. PerformanceEventTiming interface
- 3.3. Initialize event timing

https://dom.spec.whatwg.org/#dom-event-type Referenced in:

- 1.1. Events exposed
- 2.1. PerformanceEventTiming interface
- 2.2. EventCounts interface (2)
- 2.3. Extensions to the Performance interface
- 3.3. Initialize event timing

https://w3c.github.io/hr-time/#idl-def-domhighrestimestamp Referenced in:

- 2.1. PerformanceEventTiming interface (2)

https://w3c.github.io/hr-time/#dfn-performance Referenced in:

- 2.3. Extensions to the Performance interface (2)

https://w3c.github.io/hr-time/#dfn-current-high-resolution-time Referenced in:

- 3.1. Modifications to the DOM specification (2)
- 3.5. Dispatch pending Event Timing entries

https://w3c.github.io/hr-time/#dom-performance-now Referenced in:

- 1. Introduction
- 4. Security & privacy considerations

https://w3c.github.io/hr-time/#dom-windoworworkerglobalscope-performance Referenced in:

- 3.5. Dispatch pending Event Timing entries

https://html.spec.whatwg.org/multipage/window-object.html#window Referenced in:

- 2.1. PerformanceEventTiming interface
- 3.2. Modifications to the HTML specification (2) (3)
- 3.4. Finalize event timing

https://html.spec.whatwg.org/multipage/#event-dnd-drag Referenced in:

- 1.1. Events exposed

https://html.spec.whatwg.org/multipage/#event-dnd-dragend Referenced in:

- 1.1. Events exposed

https://html.spec.whatwg.org/multipage/#event-dnd-dragenter Referenced in:

- 1.1. Events exposed

https://html.spec.whatwg.org/multipage/#event-dnd-dragexit Referenced in:

- 1.1. Events exposed

https://html.spec.whatwg.org/multipage/#event-dnd-dragleave Referenced in:

- 1.1. Events exposed

https://html.spec.whatwg.org/multipage/#event-dnd-dragover Referenced in:

- 1.1. Events exposed

https://html.spec.whatwg.org/multipage/#event-dnd-dragstart Referenced in:

- 1.1. Events exposed

https://html.spec.whatwg.org/multipage/#event-dnd-drop Referenced in:

- 1.1. Events exposed

https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model Referenced in:

- 3.2. Modifications to the HTML specification

https://html.spec.whatwg.org/multipage/browsers.html#fully-active Referenced in:

- 3.2. Modifications to the HTML specification

https://html.spec.whatwg.org/multipage/webappapis.html#concept-relevant-global Referenced in:

- 3.4. Finalize event timing
- 3.5. Dispatch pending Event Timing entries

https://html.spec.whatwg.org/multipage/webappapis.html#update-the-rendering Referenced in:

- 2.1. PerformanceEventTiming interface
- 3.2. Modifications to the HTML specification

https://w3c.github.io/paint-timing/#mark-paint-timing Referenced in:

- 3.2. Modifications to the HTML specification

https://w3c.github.io/performance-timeline/#the-performanceentry-interface Referenced in:

- 2.1. PerformanceEventTiming interface (2)

https://w3c.github.io/performance-timeline/#dom-performanceentry-duration Referenced in:

- 2.1. PerformanceEventTiming interface (2)
- 3.5. Dispatch pending Event Timing entries (2) (3)
- 4. Security & privacy considerations (2) (3)

https://w3c.github.io/performance-timeline/#dom-performanceentry-entrytype Referenced in:

- 2.1. PerformanceEventTiming interface (2)
- 3.3. Initialize event timing
- 3.5. Dispatch pending Event Timing entries (2)

https://w3c.github.io/performance-timeline/#dom-performanceentry-name Referenced in:

- 2.1. PerformanceEventTiming interface (2)
- 3.3. Initialize event timing
- 3.5. Dispatch pending Event Timing entries

https://w3c.github.io/performance-timeline/#dfn-queue-a-performanceentry Referenced in:

- 3.5. Dispatch pending Event Timing entries (2) (3)

https://w3c.github.io/performance-timeline/#dom-performanceentry-starttime Referenced in:

- 2.1. PerformanceEventTiming interface (2) (3)
- 3.3. Initialize event timing
- 3.5. Dispatch pending Event Timing entries

https://w3c.github.io/performance-timeline/#supportedentrytypes-attribute Referenced in:

- 2.1. PerformanceEventTiming interface

https://w3c.github.io/pointerevents/#the-gotpointercapture-event Referenced in:

- 1.1. Events exposed

https://w3c.github.io/pointerevents/#the-lostpointercapture-event Referenced in:

- 1.1. Events exposed

https://w3c.github.io/pointerevents/#the-pointercancel-event Referenced in:

- 1.1. Events exposed

https://w3c.github.io/pointerevents/#the-pointerdown-event Referenced in:

- 1.1. Events exposed (2)

https://w3c.github.io/pointerevents/#the-pointerenter-event Referenced in:

- 1.1. Events exposed

https://w3c.github.io/pointerevents/#the-pointerleave-event Referenced in:

- 1.1. Events exposed

https://w3c.github.io/pointerevents/#the-pointermove-event Referenced in:

- 1.1. Events exposed

https://w3c.github.io/pointerevents/#the-pointerout-event Referenced in:

- 1.1. Events exposed

https://w3c.github.io/pointerevents/#the-pointerover-event Referenced in:

- 1.1. Events exposed

https://w3c.github.io/pointerevents/#the-pointerup-event Referenced in:

- 1.1. Events exposed (2)

https://w3c.github.io/touch-events/#the-touchcancel-event Referenced in:

- 1.1. Events exposed

https://w3c.github.io/touch-events/#the-touchend-event Referenced in:

- 1.1. Events exposed

https://w3c.github.io/touch-events/#the-touchmove-event Referenced in:

- 1.1. Events exposed

https://w3c.github.io/touch-events/#the-touchstart-event Referenced in:

- 1.1. Events exposed

https://w3c.github.io/uievents/#event-type-auxclick Referenced in:

- 1.1. Events exposed

https://w3c.github.io/uievents/#event-type-beforeinput Referenced in:

- 1.1. Events exposed

https://w3c.github.io/uievents/#event-type-click Referenced in:

- 1.1. Events exposed (2)

https://w3c.github.io/uievents/#event-type-compositionend Referenced in:

- 1.1. Events exposed

https://w3c.github.io/uievents/#event-type-compositionstart Referenced in:

- 1.1. Events exposed

https://w3c.github.io/uievents/#event-type-compositionupdate Referenced in:

- 1.1. Events exposed

https://w3c.github.io/uievents/#event-type-dblclick Referenced in:

- 1.1. Events exposed

https://w3c.github.io/uievents/#event-type-input Referenced in:

- 1.1. Events exposed

https://w3c.github.io/uievents/#event-type-keydown Referenced in:

- 1.1. Events exposed (2)

https://w3c.github.io/uievents/#event-type-keyup Referenced in:

- 1.1. Events exposed

https://w3c.github.io/uievents/#event-type-mousedown Referenced in:

- 1.1. Events exposed (2)

https://w3c.github.io/uievents/#event-type-mouseenter Referenced in:

- 1.1. Events exposed

https://w3c.github.io/uievents/#event-type-mouseleave Referenced in:

- 1.1. Events exposed

https://w3c.github.io/uievents/#event-type-mousemove Referenced in:

- 1.1. Events exposed

https://w3c.github.io/uievents/#event-type-mouseout Referenced in:

- 1.1. Events exposed

https://w3c.github.io/uievents/#event-type-mouseover Referenced in:

- 1.1. Events exposed

https://w3c.github.io/uievents/#event-type-mouseup Referenced in:

- 1.1. Events exposed

https://w3c.github.io/uievents/#event-type-wheel Referenced in:

- 1.1. Events exposed

https://heycam.github.io/webidl/#idl-DOMString Referenced in:

- 2.2. EventCounts interface

https://heycam.github.io/webidl/#Default Referenced in:

- 2.1. PerformanceEventTiming interface

https://heycam.github.io/webidl/#Exposed Referenced in:

- 2.1. PerformanceEventTiming interface
- 2.2. EventCounts interface
- 2.3. Extensions to the Performance interface

https://heycam.github.io/webidl/#SameObject Referenced in:

- 2.3. Extensions to the Performance interface

https://heycam.github.io/webidl/#idl-boolean Referenced in:

- 2.1. PerformanceEventTiming interface

https://heycam.github.io/webidl/#implements Referenced in:

- 3.4. Finalize event timing

https://heycam.github.io/webidl/#dfn-map-entries Referenced in:

- 3.5. Dispatch pending Event Timing entries (2) (3)

https://heycam.github.io/webidl/#idl-object Referenced in:

- 2.1. PerformanceEventTiming interface

https://heycam.github.io/webidl/#idl-unsigned-long-long Referenced in:

- 2.2. EventCounts interface

### Terms defined by reference

- [DOM] defines the following terms:
  - Document
  - Event
  - cancelable
  - event dispatch algorithm
  - isTrusted
  - timeStamp
  - type
- [hr-time-2] defines the following terms:
  - DOMHighResTimeStamp
  - Performance
  - current high resolution time
  - now()
  - performance
- [HTML] defines the following terms:
  - Window
  - drag
  - dragend
  - dragenter
  - dragexit
  - dragleave
  - dragover
  - dragstart
  - drop
  - event loop processing model
  - fully active
  - relevant global object
  - update the rendering
- [paint-timing] defines the following terms:
  - mark paint timing
- [performance-timeline-2] defines the following terms:
  - PerformanceEntry
  - duration
  - entryType
  - name
  - queue the entry
  - startTime
  - supportedEntryTypes
- [pointerevents] defines the following terms:
  - gotpointercapture
  - lostpointercapture
  - pointercancel
  - pointerdown
  - pointerenter
  - pointerleave
  - pointermove
  - pointerout
  - pointerover
  - pointerup
- [touch-events] defines the following terms:
  - touchcancel
  - touchend
  - touchmove
  - touchstart
- [uievents] defines the following terms:
  - auxclick
  - beforeinput
  - click
  - compositionend
  - compositionstart
  - compositionupdate
  - dblclick
  - input
  - keydown
  - keyup
  - mousedown
  - mouseenter
  - mouseleave
  - mousemove
  - mouseout
  - mouseover
  - mouseup
  - wheel
- [WebIDL] defines the following terms:
  - DOMString
  - Default
  - Exposed
  - SameObject
  - boolean
  - implements
  - map entries
  - object
  - unsigned long long

## References

### Normative References

[DOM]
  Anne van Kesteren. DOM Standard. Living Standard. URL: https://dom.spec.whatwg.org/
[HR-TIME-2]
  Ilya Grigorik; James Simonsen; Jatinder Mann. High Resolution Time Level 2. 1 March 2018. CR. URL: https://www.w3.org/TR/hr-time-2/
[HTML]
  Anne van Kesteren; et al. HTML Standard. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[PAINT-TIMING]
  Shubhie Panicker. Paint Timing 1. 7 September 2017. WD. URL: https://www.w3.org/TR/paint-timing/
[PERFORMANCE-TIMELINE-2]
  Ilya Grigorik. Performance Timeline Level 2. 23 April 2019. WD. URL: https://www.w3.org/TR/performance-timeline-2/
[POINTEREVENTS]
  Jacob Rossi; Matt Brubeck. Pointer Events. 4 April 2019. REC. URL: https://www.w3.org/TR/pointerevents/
[RFC2119]
  S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[TOUCH-EVENTS]
  Doug Schepers; et al. Touch Events. 10 October 2013. REC. URL: https://www.w3.org/TR/touch-events/
[UIEVENTS]
  Gary Kacmarcik; Travis Leithead; Doug Schepers. UI Events. 30 May 2019. WD. URL: https://www.w3.org/TR/uievents/
[WebIDL]
  Boris Zbarsky. Web IDL. 15 December 2016. ED. URL: https://heycam.github.io/webidl/

## IDL Index

    [Exposed=Window]
    interface PerformanceEventTiming : PerformanceEntry {
        readonly attribute DOMHighResTimeStamp processingStart;
        readonly attribute DOMHighResTimeStamp processingEnd;
        readonly attribute boolean cancelable;
        [Default] object toJSON();
    };

    [Exposed=Window]
    interface EventCounts {
        readonly maplike<DOMString, unsigned long long>;
    };

    [Exposed=Window]
    partial interface Performance {
        [SameObject] readonly attribute EventCounts eventCounts;
    };

#considered-for-event-timing Referenced in:

- 3.3. Initialize event timing

#performanceeventtiming Referenced in:

- 2.1. PerformanceEventTiming interface (2) (3) (4) (5)
- 2.2. EventCounts interface
- 3.2. Modifications to the HTML specification (2)
- 3.3. Initialize event timing

#performanceeventtiming-associated-event Referenced in:

- 2.1. PerformanceEventTiming interface (2) (3) (4)

#dom-performanceeventtiming-processingstart Referenced in:

- 2.1. PerformanceEventTiming interface (2) (3)
- 3.1. Modifications to the DOM specification
- 3.3. Initialize event timing
- 4. Security & privacy considerations

#dom-performanceeventtiming-processingend Referenced in:

- 2.1. PerformanceEventTiming interface (2)
- 3.1. Modifications to the DOM specification
- 3.4. Finalize event timing
- 4. Security & privacy considerations

#dom-performanceeventtiming-cancelable Referenced in:

- 2.1. PerformanceEventTiming interface (2)
- 3.3. Initialize event timing

#eventcounts Referenced in:

- 2.2. EventCounts interface (2)
- 2.3. Extensions to the Performance interface

#dom-performance-eventcounts Referenced in:

- 2.3. Extensions to the Performance interface
- 3.5. Dispatch pending Event Timing entries (2)

#pending-event-entries Referenced in:

- 3.4. Finalize event timing
- 3.5. Dispatch pending Event Timing entries

#pending-pointer-down Referenced in:

- 3.5. Dispatch pending Event Timing entries (2) (3) (4)

#has-dispatched-input-event Referenced in:

- 3.5. Dispatch pending Event Timing entries (2) (3)

#initialize-event-timing Referenced in:

- 3.1. Modifications to the DOM specification

#finalize-event-timing Referenced in:

- 3.1. Modifications to the DOM specification

#dispatch-pending-event-timing-entries Referenced in:

- 3.2. Modifications to the HTML specification