Designing download progress in a fetch-compatible way

[jakearchibald]

Hey folks! We're looking at adding progress monitoring to fetch over in whatwg/fetch#1843. Let's figure out a consistent model.

I like the name monitor used here.

I think we should move away from ProgressEvent, and leave them to rot in XHR land. Instead, we should use a plain Event type and move state to the target object.

In terms of naming, we were looking at request and response, but download and upload seems ok to me. I also support this being downloadprogress rather than just progress, although we may have a progress event for state changes that cover multiple phases.

[domenic]

I think we should move away from ProgressEvent, and leave them to rot in XHR land. Instead, we should use a plain Event type and move state to the target object.

Can you explain why in more detail? I can understand not creating a new type of event, but since ProgressEvent already exists, it seems nice enough to reuse it.

In terms of naming, we were looking at request and response, but download and upload seems ok to me.

What are you naming with these names?

although we may have a progress event for state changes that cover multiple phases.

+1, webmachinelearning/prompt-api#4 discusses this a bit.

[lukewarlow]

In terms of naming, we were looking at request and response, but download and upload seems ok to me.

What are you naming with these names?

Depends on the exact shape of the API we land on but potentially requestprogress and responseprogress for event names.

I'm torn between request/response and upload/download. The first matches the fetch API nomenclature and I don't think there's any references to upload or download anymore (other than stuff like download links but that's distinct imo).

But upload/download matches XHR and seems to match what developers actually call this (probably because it's what XHR calls it).

[jakearchibald]

@lukewarlow

I'm torn between request/response and upload/download.

One thing that might influence what we do is, is what we expect to happen if the response comes from somewhere other than the network.

[jakearchibald]

@domenic

Can you explain why in more detail? I can understand not creating a new type of event, but since ProgressEvent already exists, it seems nice enough to reuse it.

I mean we created a new type of API for fetch rather than use XHR 😄, so it's an opportunity to adopt more modern styles of API, rather than create an old/new hybrid.

The nice thing about having state on the object is you can receive the object after the first event, or even after the final event, and be able to get the state. The event is purely to know the state changed, rather than providing the data itself.

[Mouvedia]

Before ProgressEvent we had LSProgressEvent; please don't add another one unless the planned extensions are considered incompatible with the current shape.
https://xkcd.com/927

[tomayac]

Before ProgressEvent we had LSProgressEvent

Maybe saving someone else a Web search: LSProgressEvent. Wow, #TIL.

[jakearchibald]

please don't add a another one unless the planned extensions are considered incompatible with the current shape.

That is exactly what's being discussed - a pattern that is instead compatible with modern web platform design. https://w3ctag.github.io/design-principles/#state-and-subclassing

I'm assuming that ProgressEvent isn't used by anything other than the superceded and badly designed XHR.

[Mouvedia]

It's used by the handler SVG element.
e.g.

<handler ev:event="loadstart">[…]</handler>
<handler ev:event="progress">[…]</handler>
<handler ev:event="loadend">[…]</handler>

It's also used by FileReader of File API.
There might be other usages, I am not sure.

[lukewarlow]

Worth noting that FileReader is similar to XHR in some ways, it does provide extra functionality over the alternatives (namely progress events in both cases), but it's also not particularly modern in design. In fact some (w3c/FileAPI#159 (comment), w3c/FileAPI#159 (comment)) even reference that file reader is soft deprecated.

All that is to say just because XHR and FileReader use it doesn't mean it should be used here.

I'm also not sure that it definitely shouldn't be used though.

It should also be noted that there's precedent for progress events that use Event not ProgressEvent:

• MediaElement progress event - https://html.spec.whatwg.org/#event-media-progress
• BackgroundFetchRegistration progress event - https://wicg.github.io/background-fetch/#background-fetch-registration-events - interestingly that also uses a similar design to Jake's idea - should note it also uses upload/download naming.

It's used by the handler SVG element.
e.g.

<handler ev:event="loadstart">[…]</handler>
<handler ev:event="progress">[…]</handler>
<handler ev:event="loadend">[…]</handler>

Is this actually implemented anywhere? I can't find any docs for this SVG element?

[jakearchibald]

• BackgroundFetchRegistration progress event - https://wicg.github.io/background-fetch/#background-fetch-registration-events - interestingly that also uses a similar design to Jake's idea - should note it also uses upload/download naming.

Heh I designed that API so it isn't the maddest coincidence. I had forgotten I'd used that pattern though. I avoided request/response naming there because it may involve multiple responses. I guess the same is true for model downloads.

[Mouvedia]

It's used by the handler SVG element.
e.g.

<handler ev:event="loadstart">[…]</handler>
<handler ev:event="progress">[…]</handler>
<handler ev:event="loadend">[…]</handler>

Is this actually implemented anywhere? I can't find any docs for this SVG element?

https://www.w3.org/TR/SVGTiny12/elementTable.html#element_handler
https://www.w3.org/TR/2008/REC-SVGTiny12-20081222/svgudom.html#events__ProgressEvent

[Mouvedia]

Also the video element used to support the loadend event.

…r4133 removes the "in progress" events (loadstart, loadend, and progress) that used to be fired while the video/audio file was downloading

loadstart and progress remains still though.
Those 3 corresponds to the event types of ProgressEvent.

[lukewarlow]

Svgtiny as far as I know never shipped in any browser? If so it's not really relevant to this conversation. Either way there's examples both for and against using the ProgressEvent class.