[whatwg] Html 5 video element's poster attribute

[Kevin Marks]

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.   `._.-(,_..'--(,_..'`-.;.'
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20101208/fc136fb8/attachment-0002.htm>