- From: Kevin Marks <kevinmarks@gmail.com>
- Date: Thu, 9 Dec 2010 10:36:45 -0800
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-0001.htm>
Received on Thursday, 9 December 2010 10:36:45 UTC