W3C home > Mailing lists > Public > public-html@w3.org > July 2008

Re: ProgressEvent and unreachable networkState LOADED in HTMLMediaElement

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 8 Jul 2008 22:44:43 +0000 (UTC)
To: Philip J├Ągenstedt <philipj@opera.com>
Cc: HTML WG <public-html@w3.org>
Message-ID: <Pine.LNX.4.62.0807082243500.11215@hixie.dreamhostps.com>
On Thu, 26 Jun 2008, Philip Jńgenstedt wrote:
> On Wed, 2008-06-25 at 16:51 +0700, Philip J├Ągenstedt wrote:
> > This progress events draft states that exactly one of the events
> > "error", "abort" and "load" must be dispatched. This is easy in most
> > cases, but ´╗┐what about infinite media resources (streaming) or media
> > resources so large that the browser can never cache the entire resource
> > at once (certainly not in memory, and not on disk on devices either).
> 
> Rethinking this, it seems that it's as simple as triggering the abort 
> event when the element is eventually unloaded. Can/should this be 
> specified somewhere?

I think the Progress spec should just say that if the resource is 
infinite, then it might be that none of those is fired.


> Still, it might be useful to note that the LOADED state might never be 
> reached for streaming or very large files. Thus, script authors should 
> never wait for the LOADED state to guarantee that the file can play 
> through, that's a guarantee that can never be given (CAN_PLAY_THROUGH is 
> the best guess we can give).

Well, they know what file they gave their video player. I don't know what 
that a note would be seen by the relevant people. :-)


> > Somewhat related, is the intention to have the "stalled" event added 
> > to the progress events spec?
> 
> I'm taking this to the WebApps WG as well.

Ok.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 8 July 2008 22:45:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:19 GMT