[whatwg] Html 5 video element's poster attribute

[Kevin Marks]

I know it's not effective at the moment; it is a common use case.
QuickTime had the 'badge' ux for years that hardly anyone took advantage of:

http://www.mactech.com/articles/mactech/Vol.16/16.02/Feb00QTToolkit/index.html

What we're seeing on the web is a converged implementation of the
YouTube-like overlaid grey play button, but this is effectively
reimplemented independently by each video site that enables embedding.

As we see HTML used declaratively for long-form works like ebooks on lower
performance devices, having embedded video that doesn't cumulatively absorb
all the memory available is going to be like the old CD-ROM use cases the QT
Badge was meant for.

On Thu, Dec 9, 2010 at 9:29 AM, David Singer <singer at apple.com> wrote:

> 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/f04e8a62/attachment-0002.htm>