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