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