I don’t think that we need to handle a fallback URL (if the second fails, why not a third one, etc).
However, I find the idea of fallback JS useful.
The immediate use-case I have in mind is to enable image lazy-loading (a la lazysizes ), with a decent fallback that displays the images when the script has failed to load.
timeout attribute that indicates an opt-in to this timeout behavior, as well as the actual time that the user should be left waiting for the script to arrive makes sense to me.
The main question that remains is “what would be the fallback?”.
I think that in order for that to be a robust fallback (that covers more use-cases than the ones we can think of right now), the fallback should be defined as an inline script.
That inline script can be either:
- The content of the
ontimeout based event handler.
That can be polyfilled using a ServiceWorker, or even simply by a timeout based script (if
onerror haven’t happened yet, remove the script and do something else instead).