Re: SVG 1.2 12.1.1 The Progress Event

Dean Jackson wrote:
> 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!

I was under the impression that all/most current SVG implentation used a parser 
implemented by a different team. If so they probably only get get data: URLs 
when the element tag it sits on is done being parsed. This would indicate 
immediate start/stop. Even an implementation that could start reading the data: 
URL before the element is finished being read would in fact have to wait as long 
because it'd have to look for onpreload attributes in that scope.

>>In the situation where the content is gzip-compressed, should the inflated
>>or gzipped size be returned?
> 
> Therefore, for gzip data, I assume it is the compressed size.
> I could be wrong.

I agree, it makes more sense.

>>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?

Well there's no reason this event should just cater for progress bars. We could 
add fields for responseCode and mimeType, or even a complete httpHeaders object.

-- 
Robin Berjon <robin.berjon@expway.fr>
Research Engineer, Expway        http://expway.fr/
7FC0 6F5F D864 EFB8 08CE  8E74 58E6 D5DB 4889 2488

Received on Wednesday, 4 June 2003 05:40:45 UTC