'ready' event may be premature; inconsistent functioning of SoundciteJS

As of August, 2020 , TimelineJS was changed to support using SoundciteJS audio players. The intention was for any TimelineJS configuration component which permits HTML to permit Soundcite clips.

User reports and rough tests suggest that soundcite clips only function in the text and headline fields, but not in the media caption and media credit fields.

This change (3e200ab40ec288ba91ffb5414205e90f1a9fd4bc) included adding and firing a ready event which would trigger loading Soundcite JS and CSS. When SoundciteJS loads, it immediately scans the page for elements with the soundcite class, and attempts to convert them into playable elements.

Experimenting with a debugger shows that those .soundcite elements in captoin/credit are not yet in the DOM when SoundciteJS initializes. One can fiddle about in the browser inspector later and get SoundciteJS to make those elements into players.

While issues with SoundciteJS flushed out this problem, to me the bigger flaw here is that the timeline isn't really ready when the ready event fires.

Given the primitive approach to async programming throughout early TimelineJS code, it's hard to know how we'd establish a clear signal that all of the media elements were truly ready without pretty big changes. (Ideally, we'd just use Promise.all(...) but that may not be so straightforward with all of the complex legacy code.)

So, for now, this is to document the issue.

Start by reviewing change 3e200ab40ec288ba91ffb5414205e90f1a9fd4bc and the code surrounding the ready event. Compare when SoundciteJS scans the text, headline, media caption, and media credit elements; the issue is complete only when the readiness signal reliably follows creation of all relevant DOM elements, or the scope is clarified.