Re: SVG 1.2 12.1.1 The Progress Event

On Fri, 09 May 2003, Jim Ley wrote:

> 
> What would happen in the situation where the referenced URI was a data: URI
> or a backwards local reference to a def'd element previously?

My guess is that if the user agent can get useful information then
it must fire the events.

For data:, then it probably doesn't know the total size, but it may
be able to provide events as data is received. If it can not do this,
oh well!

For backwards local references, you won't get the progress events,
just the start and stop (loaded). Hopefully really close together in
time :)
 
> The attribute must be fully loaded (but not necessarily ready to be
> rendered) at the same time as the event handler is defined (if using the
> onPreLoad="..." syntax) so the MUST requirement to dispatch the event before
> loading starts seems impossible to provide.

I agree. Something to think about.

> I'd like to see the total attribute not be ignored for a postload event,
> since knowing the size of the resource should be available to the UA by this
> time, and it seems reasonable to expose it to the user, especially as there
> may have been no loadprogress type events fired for a resource to get the
> size.

I remember there being a reason for leaving it out, but it escapes me
at the moment. I'll raise the issue in the WG.

> In the situation where the content is gzip-compressed, should the inflated
> or gzipped size be returned?

The main use cases for this feature are:

(a) progress bars for receiving data
(b) starting animations once you know the data has arrived
    (eg. a slideshow of images)

Therefore, for gzip data, I assume it is the compressed size.
I could be wrong.

> If the server lies about the size of the resource, what should be returned
> (consider a situation where the server claims a resource is 5000 bytes but
> in reality it's 10000 bytes, then loaded would get above total.) should
> total change in this situation to -1 after it's obvious the initial size
> reported by the server was wrong?

Either that or update total to be always equal to loaded.
I'm not sure which is best.

> The document talks about a "progress property"
> 
> "the progress property on an 'intermediate progress' event is strictly
> greater than zero and strictly smaller than one."
> 
> but I don't see it in the IDL definition, assuming it does exist, then my
> example above would cause problems with the strict requirement that it does
> not get outside the 0-1 range.

Whoops! That was meant to be the "loaded" property. An earlier draft,
not public, used percentages (and "progress" instead of "total").
 
> Also I believe that a complimentary, onError or something similar needs to
> be provided for the situation where for whatever the reason the referenced
> resource is not returned, (since people will often use the events for hiding
> content until all referenced resources are available, the failure of any 1
> resource to be not available will often result in all content not being
> shown.

Good point.

> Also what should happen if the returned resource is a 404 or other non-200
> status code, should the document that accompanies the 404 be displayed and
> made available with progressLoad events (after all it may well be a document
> of a type renderable by the UA) or should it be a failure and therefore fire
> my proposed ERROR event.

We'll think about it. What do you suggest?

Dean

Received on Tuesday, 3 June 2003 23:23:57 UTC