From ae181b30a270c22dcae31dd7b62486d74a9d94f8 Mon Sep 17 00:00:00 2001 From: Jeffrey Yasskin Date: Tue, 17 Dec 2024 14:16:19 -0800 Subject: [PATCH] Apply changes resulting from Jan-Ivar's code review Co-authored-by: Jan-Ivar Bruaroey --- index.bs | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/index.bs b/index.bs index ae30e02f..bdfafc1e 100644 --- a/index.bs +++ b/index.bs @@ -1458,12 +1458,13 @@ including between [=microtasks=].
During synchronous execution (such as a `while` loop), and after `await`ing an already-resolved `Promise`, -you *shouldn't* expect things like: +developers are *unlikely* to expect things like: * The DOM to update as a result of the HTML parser loading new content from the network * {{HTMLImageElement/width|img.width}} to change as a result of loading image data from the network * Buttons of a {{Gamepad}} to change state * {{Element/scrollTop}} to change, even if scrolling can visually occur +* A synchronous method to act differently depending on asynchronous state changes. For example, if {{LockManager}} had synchronous methods, their behavior would depend on concurrent calls in other windows. These things aren't updated by the currently running script, so they shouldn't change during the current task. @@ -1484,7 +1485,7 @@ A few kinds of situations justify violating this rule: although note that it's also useful to present a consistent task-wide time as in {{AnimationTimeline/currentTime|document.timeline.currentTime}}. * Functions meant to help developers interrupt synchronous work, - as in the case of the proposed {{isInputPending()}}. + as in the case of {{IdleDeadline/timeRemaining()|IdleDeadline.timeRemaining()}}. * States meant to protect users from surprising UI changes, like [=transient activation=]. Note that {{UserActivation/isActive|navigator.userActivation.isActive}}