[whatwg] Html 5 video element's poster attribute

Thu Dec 9 09:29:07 PST 2010

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" <ian at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20101209/4c828d89/attachment-0002.htm>