- From: Guohui Deng <notifications@github.com>
- Date: Wed, 05 Aug 2026 09:31:42 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/1224/5194496069@github.com>
guohuideng2024 left a comment (w3ctag/design-reviews#1224) cc: @noamr 1) "long task" is monitored/reported by `LoAF`. A single long task is sufficient to emit a `LoAF`. Therefore, after this feature is implemented the conditional user timing can analyze long tasks. 2) Our intention is that "conditional user timing" is not only tied to `LoAF`(Long animation frame), but a collection of Performance reporting API. "LoAF" is the very first Performance reporting API that monitors and includes these user timing points. Thus, we use a very general word "conditional". And we do intend to expand this to other user cases, like "EventTiming" or even `ElementTiming` in the near future. 3) We use a new name/API like `markConditional` instead of expanding the existing `performance.mark`, based on a number of considerations. a) They behavior very different from regular `performance.mark/measure`: There is **no overlap** between where regular `mark/measure` can appear and where these conditional user timing can appear; The conditional user points (after the future expansion) operates in parallel in a number of different timelines. Even the implementation of `conditional user timing` has very little overlap of that for `user timing` b) We want the app developers to be able to deploy more such user timing points, so the user timing points must be lightweight, with minimal performance overhead. Unfortunately, the existing `performance.mark/measure` has a so large collection of functionalities built in, that operations on them cost too much CPU and memory. Therefore, we explicitly want to exclude these `Option`s in the existing `Performance.mark/measure`. By using a new API/name it's clear that the interface is different. -- Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/1224#issuecomment-5194496069 You are receiving this because you are subscribed to this thread. Message ID: <w3ctag/design-reviews/issues/1224/5194496069@github.com>
Received on Wednesday, 5 August 2026 16:31:47 UTC