- From: Jeffrey Yasskin <notifications@github.com>
- Date: Tue, 13 Oct 2026 19:51:15 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Wednesday, 14 October 2026 02:51:20 UTC
jyasskin left a comment (w3ctag/design-reviews#1224) Thanks @guohuideng2024. Your reasoning for adding new functions makes sense to me. I'm still not sure whether this is the right name, and whether it will be quite the right design once you add a second Performance reporting API that monitors these user timing points. 1. Ideally function names describe what they apply to. "Conditional" doesn't indicate what the condition is. Something like "markForPerformanceIncident" might explain itself better, but you and the working group can probably come up with a more explanatory name than I can. 2. Is it possible that developers will want to say that a mark applies to `LoAF` but not `EventTiming` or vice versa? If so, you're going to need to add an options dictionary to the parameters. Once you've done that for `measureConditional`, you'll want to move `startMark` and `endMark` inside it. https://w3ctag.github.io/design-principles/#prefer-dictionaries also suggests that your optional parameters should be inside an options dictionary even without the extra field to select the kind of performance incident. -- Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/1224#issuecomment-6159786561 You are receiving this because you are subscribed to this thread. Message ID: <w3ctag/design-reviews/issues/1224/6159786561@github.com>
Received on Wednesday, 14 October 2026 02:51:20 UTC