09:40
<Noam Rosenthal>
If anyone is interested, I've created a little AI skill for tracking the history, rationale and discussion behind existing standard wording, e.g. why a certain algorithm or concept is there in a current standard (WHATWG, w3c, IETF, etc). I found it especially useful for the HTML standard as sometimes it needs to perform complex git queries or lookup old W3C mailing lists and a single git blame/github issue doesn't tell the whole story. See https://github.com/noamr/web-archeologist
09:59
<sideshowbarker>
You have a snippet of example input, and the output you got from Gemini for that?
10:14
<Noam Rosenthal>
(generating a new one just in case I broke something)
10:25
<Noam Rosenthal>

can you give me the history behind https://html.spec.whatwg.org/#spin-the-event-loop?

✦ The history of the "spin the event loop" algorithm is a journey from an informal "blocking" requirement to a rigorous, formalized "specification macro."

  1. The Origin: Parser/Script Synchronization (October 2009)
    The algorithm was introduced by Ian Hickson on October 11, 2009, in commit 35847fe79f33b502a0e9271c9ee523e49e2e93da (https://github.com/whatwg/html/commit/35847fe79f33b502a0e9271c9ee523e49e2e93da) (SVN revision 4103).
  • The Problem: The HTML5 specification needed a way to explain how the parser should stop executing a <script> while waiting for CSS (specifically @import) to finish loading, without "locking up" the entire browser.
  • The Initial Solution: Hickson defined "spin the event loop" as a series of steps: stop the current task, allow the event loop to run, wait for a condition, and then queue a new task to resume the original algorithm. This
    effectively turned a synchronous script execution into an asynchronous "pause and resume" operation.
  1. The Formalization: The "Spec Macro" (May 2019)
    For nearly a decade, the algorithm remained somewhat hand-wavy in its execution. It was significantly "rigorized" and refactored in May 2019 by Anne van Kesteren and Domenic Denicola in commit
    38c50c4ea111bd8f3ff60d2a49110a62a293c7ac (https://github.com/whatwg/html/commit/38c50c4ea111bd8f3ff60d2a49110a62a293c7ac).
  • The Change: This commit added the formal definition of the algorithm as a "macro." It clarified that unlike a standard function call, "spin the event loop" expands into a series of steps that save the state (the execution
    context stack), run microtasks, and then "re-queue" the rest of the algorithm's steps as a new task.
  • The Rationale: This cleanup was part of a larger effort to define "tasks" and "task queuing" as proper data structures in the spec, ensuring that browsers had a interoperable model for how asynchronous resumption should work.
  1. Current Role
    Today, "spin the event loop" is the standard tool for spec authors whenever they need an algorithm to wait for something in a way that appears synchronous to the calling logic but must be asynchronous to the browser (like waiting
    for a stylesheet to load before running a script). It remains one of the most complex and critical "meta-algorithms" in the HTML specification.
10:26
<Noam Rosenthal>
(Note that it's work in progress, happy for PRs/reports for the skill)
10:27
<jjaschke>
Noam Rosenthal: Maybe this might be interesting for you as well, even though currently it's aiming/mostly used for implementing specs.
10:28
<Noam Rosenthal>
Thanks! I'll tell the skill to refer to that for indices
10:43
<sideshowbarker>
jjaschke: my cargo doesn’t seem to have a binstall
10:43
<jjaschke>
sideshowbarker: You should be able to just cargo install webspec-index and compile it
12:55
<zcorpan>
jmdyck: Thank you, I'll fix
13:22
<zcorpan>
Very nice! Maybe IRC logs and Matrix logs could be added somehow? I check those for clues when other sources are lacking, checking dates at or right before a relevant change was authored
13:23
<sideshowbarker>
Ah yeah, including (or especially) the original IRC logs
13:25
<Noam Rosenthal>
nice idea, let me see if I can incorporate that
13:26
<zcorpan>
https://krijnhoetmer.nl/irc-logs/
13:27
<zcorpan>
(Do we have backups of these logs?)
13:27
<sideshowbarker>
https://matrixlogs.bakkot.com/irc-whatwg/ also has those
13:28
<sideshowbarker>
well, only the whatwg channel — not any of the others
13:45
<Noam Rosenthal>
ok, added both to the skill
15:21
<zcorpan>

annevk: ping https://github.com/WebKit/standards-positions/issues/586

I think the spec PR is ready to land

15:44
<zcorpan>
Do we need agenda+ to merge a PR that uses stages?
15:50
<annevk>
zcorpan: since it's stage 3, I don't think so
15:54
<zcorpan>
Lettuce merge
21:53
<jmdyck>
The new item in https://html.spec.whatwg.org/#eligible-for-autoplay (the 4th item) puzzles me in several ways.
21:55
<jmdyck>
First, the structure is if X and Y, or Z; and it isn't obvious to me that I should be grouping (X and Y) vs (Y, or Z)
21:56
<zcorpan>
jmdyck: "is an audio or video element " isn't needed actually
22:01
<jmdyck>
In that case, the "if" isn't necessary either?
22:01
<zcorpan>
Right
22:01
<jmdyck>
so then the item would reduce to Y, or Z;?
22:03
<zcorpan>
(its lazy loading attribute is in the Eager state) or (it has started loading while in the Lazy state) or (scripting is disabled for the element)
22:05
<zcorpan>
"while in the Lazy state" is also technically redundant
23:08
<jmdyck>
so in "it has started loading", the "it" is the media element, right? Because in the status quo, it seems to be saying that the lazy loading attribute has started loading.
23:08
<jmdyck>
(which was another thing that puzzled me)
23:10
<zcorpan>
Yes, the element. "started loading" isn't linked, which isn't ideal. Not sure if there's a hook we can use
23:10
<zcorpan>
jmdyck: can you file an issue?
23:11
<jmdyck>
about all of this, or just the last?
23:11
<zcorpan>
All
23:11
<jmdyck>
ok