- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 28 Jul 2010 22:35:20 +0000 (UTC)
- To: Simon Pieters <simonp@opera.com>
- cc: Philip Jägenstedt <philipj@opera.com>, "public-html@w3.org" <public-html@w3.org>
On Thu, 8 Apr 2010, Simon Pieters wrote: > On Thu, 08 Apr 2010 01:10:45 +0200, Ian Hickson <ian@hixie.ch> wrote: > > > > > > "skip"? Do you mean if there is a detectable delay before the new > > > frame shows up? What's the use case for this? The waiting event for > > > the network serves this purpose if the delay is because of the > > > network. For decoding, however, it's quite difficult to know how > > > long it's going to take before it's done, so we will simply always > > > fire it. Is there any browser that does things differently or plans > > > to? The spec could certainly be clearer on what a UA behavior is > > > allowed here. > > > > The use case is not having flickering UI (blinking the word > > "seeking...") if it's not necessary. If it would be helpful, I can > > make the spec more explicitly queue the task to fire "seeking" and > > then abort the send if by the time the task is ready, the seek is > > complete, or some such. > > You get unwanted flickering UI anyway if the seek takes 1ms instead of > 0ms. I think it's better if sites implement the logic for flickering > avoidance (e.g. with a timeout and transisions) than the UA sometimes > not firing an event. Having the event sometimes not fire seems like a > surprising and hard to debug behavior for authors. Fair enough. Done. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 28 July 2010 22:35:49 UTC