- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Mon, 20 Sep 2010 21:58:27 +1000
On Mon, Sep 20, 2010 at 7:26 PM, Chris Pearce <chris at pearce.org.nz> wrote: > On 20/09/2010 6:11 p.m., Roger H?gensen wrote: > > If the user pauses the video during play then a "paused poster" must not be > shown as the user most likely intends to study the paused frame of the video > > > This is a good argument against having a paused-poster. > > The question then is whether the end-poster needs to be different from the > start-poster. If the main use case is "re-display the poster image so the > user knows that they can play again", then the end-poster and start-poster > don't need to be different. > > Showing the poster at the end of playback is a matter of taste. How about > we remain with a single 'poster' attribute, and add a 'showposter' attibute, > with values 'start', 'end', and 'both', which denote when the poster is > shown? Or the values could be enumerated similar to how readyState and > networkState are enumerated. > > > On 20/09/2010 7:57 p.m., Silvia Pfeiffer wrote: > > On Mon, Sep 20, 2010 at 1:38 PM, Shiv Kumar <skumar at exposureroom.com>wrote: > >> >Could a call to video.load() reset this state? >> >> Currently is doesn?t affect the poster. But would that be intuitive? I?m >> getting the video element to load it?s source and so the poster will show? >> >> > I regard the load() function as a kind of reset() function. But possibly we > need an actual reset() function to return to the original state where the > poster image is displayed? > > > It seems reasonable to me that subsequent calls to load() should behave the > same was the first call to load(), so the poster should be redisplayed > whenever load() is called. We should change the load() algorithm to require > the poster frame to be repainted, if it's present. > I think that would be the easiest way to satisfy this requirement. We don't throw away the cached data if load() reloads the same resource and the resource hasn't changed, I assume? Silvia. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100920/2e143f91/attachment-0001.htm>
Received on Monday, 20 September 2010 04:58:27 UTC