I think if you want that effect, you flip what's visible in an area of the page between a playing video, and an image. Relying on the poster is not effective, IMHO.
On Dec 8, 2010, at 23:11 , Kevin Marks wrote: > Apologies for top posting; I'm on my phone. > > One case where posters come back after playback is complete is when there > are multiple videos on the page, and only one has playback focus at a time, > such as a page of preview movies for longer ones to purchase. > > In that case, showing the poster again on blur makes sense conceptually. > > It seems that getting back into the pre-playback state, showing the poster > again would make sense in this context. > > That would imply adding an unload() method that reverted to that state, and > could be used to make any cached media data purgeable in favour of another > video that is subsequently loaded. > > >> On Dec 8, 2010 6:56 PM, "Ian Hickson" <i...@hixie.ch> wrote: >> On Sun, 19 Sep 2010, Shiv Kumar wrote: >> > >> > I'd like to see the implementation of the poster attribut... >> >> This is an implementation choice; the spec allows either the poster to be >> used or the first frame. This is to allow the browser to use the poster >> frame until playback begins, but to then use the first frame if the user >> seeks back to the start of the video. >> >> >> > The poster should not show while the player is seeking (some browser >> > implementation do show t... >> >> That's an implementation bug. The spec doesn't allow that. >> >> >> > The poster should show again after the video has ended. >> >> Why? >> >> >> > The visibility of the poster should be scriptable and/or controllable >> > using an attribute. Mea... >> >> What's the use case for this? >> >> >> On Mon, 20 Sep 2010, Silvia Pfeiffer wrote: >> > >> > | When a video element is paused and the current p... >> >> That would be annoying in a different way -- it would mean you couldn't >> seek back to the start of the video and see the first frame. >> >> >> We could make the spec more precise and require that a particular >> behaviour occur before playback has ever happened and another after >> playback has ever happened, but in practice I think that there is only one >> behaviour that is useful and desireable enough that all browsers will >> implement it, and we don't gain much by making the other more esotecir >> behaviours non-conforming for those few people who would prefer it the >> other way. (In general it is considered bad form to require particular UI >> unless there is a strong reason to do so.) >> >> >> On Sun, 19 Sep 2010, Monty Montgomery wrote: >> > >> > If the default action is to redisplay the poster... >> >> The default behaviour without script should be the most useful behaviour, >> not the behaviour that can most easily be turned into another behaviour >> with script. >> >> >> On Mon, 20 Sep 2010, Zachary Ozer wrote: >> > >> > I'd like to weight in quickly on this based on feedba... >> >> > * Webkit's original implementation (show the first frame once it's >> > available) is requested by a lot of people. What they don't realize is >> > that the first frame is ... >> >> > (you have to start loading the video, then call play() and pause() on >> > the first frame), but I'd say it's still a good idea to display the >> > first frame if there's no p... >> >> This seems consistent with the spec's requirements. >> >> >> > * Don't show the poster when the video buffers - just pause the video >> > and give some visual i... >> >> This also. >> >> >> > * We've never had anyone request different poster images for begin / >> > pause / end. People gen... >> >> > and end, and they want the same image. If someone wants to change it, >> > allow them to set the poster attribute via JavaScript. >> >> I'm not aware of people wanting to have it appear at the end -- this never >> came up in the study of use cases. Can you elaborate on this? Are there >> examples of sites that do this today? It seems like you could just put the >> "end poster frame" in the last frame of view instead. >> >> >> > * Don't clear the poster on load(). A lot of people get confused by >> > this. It might make sens... >> >> Not sure what this is referencing. >> >> >> > * I'm not sure how reset() would work. Would you reset the list of >> > <source> too? >> >> What is reset()? >> >> >> On Sun, 19 Sep 2010, Shiv Kumar wrote: >> > >> > First I do want to make clear that it's not about being... >> >> The goal isn't to make HTML declarative to the extent possible, but to >> make it declarative for the most common 80% of use cases. >> >> >> > As regards having control over the poster's visibility using >> > attributes/script, the use case ... >> >> > producers frequently want us to show the poster after the video has >> > ended. >> >> It seems clear that they can play it again if they want to... why would >> they not be able to? Do you have an example of a site I can use that does >> this? I'm curious to study this kind of UI. >> >> >> > Seeing that there is no way to show it again (after it has disappeared) >> > I think that there sh... >> >> > any use for the poster attribute if one wants to turn on the poster. >> >> I don't really see why one would want to turn on the poster. What's the >> use case? >> >> >> > Yes, I know one can assign/un-assign the poster attribute. But really is >> > that how we see func... >> >> > even this solution will not make the poster visible when required (or >> > when desired). >> >> If you want to change the poster, changing the poster="" attribute seems >> like a perfectly reasonable way to do it. >> >> >> >> On Sun, 19 Sep 2010, Robert O'Callahan wrote: >> > >> > We do need a spec change to allow the poster t... >> >> Agreed, but is it? I don't think I've ever seen it! >> >> >> On Mon, 20 Sep 2010, Roger Hågensen wrote: >> > >> > The proper behavior should be that... >> > if there i... >> >> I agree that this is a description of good UI, but not that we should >> mandate it to the point of making other implementation non-conforming. >> >> >> > I'd also like to add that... >> >> > 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, >> > if there is a "paused poster" then it must be toggleable between "paused >> > poster" and frame by th... >> >> Agreed, to the extent that there doesn't seem to be a good use case for a >> "pause poster" in the first place. >> >> >> > And I'd also like to add that... >> >> > If there is a "end poster" then it must be displayed when the user stop the >> > video, or if the last frame of the video is reached then the "end poster" >> > but >> > be shown. >> >> If we supported this feature that's how it should work, sure. >> >> >> > Finally I'd like to add that... >> > There may be one or more posters, the start/pause/end posters ... >> >> I really don't see much evidence that this is a use case that needs >> supporting. >> >> >> > Does posters support hotzones at all? To allow clickable >> > items/links/symbols (urls?). Just cu... >> >> Not currently. >> >> >> On Sun, 19 Sep 2010, Shiv Kumar wrote: >> > >> > As regards having more control of the poster’s visibili... >> >> What's the use case? Is this really something that happens enough to >> matter? >> >> >> On Mon, 20 Sep 2010, Silvia Pfeiffer wrote: >> > >> > Could a call to video.load() reset this state? >> >> It could, yes, according to the spec today, but it also causes the whole >> video to reload from the network (modulo caching). >> >> >> On Sun, 19 Sep 2010, Shiv Kumar wrote: >> > >> > Currently is doesn't affect the poster. But would that... >> >> Currently the spec does allow the poster to be shown after load(), since >> the poster can get shown at any time where the current position is zero, >> and load() resets that. >> >> >> > Ideally poster should be an object (a property of the video element) >> > that has a source proper... >> >> It's not clear to me that the use cases we've seen justify such complexity. >> >> >> On Mon, 20 Sep 2010, Chris Pearce wrote: >> > >> > Showing the poster at the end of playback is a matte... >> >> I think this would make sense if we see evidence that authors actually >> want this behaviour (e.g. they go out of their way to implement it). Do we >> see such evidence in Flash players, for instance? >> >> >> On Mon, 20 Sep 2010, Shiv Kumar wrote: >> > >> > I’ve explained earlier that that’s not a solution. In ... >> >> > Of course we wouldn’t want the user to see the poster during the time >> > it takes to switch so we ... >> >> That seems reasonable. You can also just use another <video> element and >> fade it in over the top and then remove the old one. >> >> >> > In my mind, “load()” does not imply that the poster should also >> > show. The video stream and po... >> >> They're not independent. They're part of the same element. >> >> load() just tells the <video> element to restart. load() is implicitly >> called when you create the <video> element, it's what makes the video >> load in the first place. It makes sense that it would reset the playback >> position, poster, etc. >> >> >> > The other aspect is that the url to the video changes frequently (in >> > order to prevent bandwid... >> >> Using a changing URL to avoid someone referencing your video doesn't seem >> like an especially good design. I don't think we should optimise the spec >> to support such a design. >> >> >> > I fail to see why we can’t simply have a way to turn on the poster >> > without impacting anything... >> >> I'm not sure I agree with this premise. >> >> >> [I've snipped a number of e-mails repeating the same arguments with no new >> information -- please note that repeating arguments doesn't help!] >> >> >> On Tue, 21 Sep 2010, Silvia Pfeiffer wrote: >> > >> > I don't think you understand what load() does. It certainly does not >> > replace >> > a currently playing resource with a new one without glitches. When you load >> > a new resource, you ... >> >> The latter sounds like a bug. load() should set /paused/ to true per spec. >> >> >> On Tue, 21 Sep 2010, Shiv Kumar wrote: >> > >> > Can you give me a good reason/case for not having a si... >> >> That's not how standardisation works. We don't add all the features for >> which we can't find compelling arguments _against_, we only add features >> for which we can find compelling arguments _for_. Compelling arguments >> usually come in the form of use cases (e.g. large numbers of sites that >> are working around the lack of a feature), or compatibility (e.g. lots >> of browsers doing something). >> >> -- >> Ian Hickson U+1047E )\._.,--....,'``. fL >> http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. >> Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > David Singer Multimedia and Software Standards, Apple Inc.
