- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 9 Dec 2010 02:55:10 +0000 (UTC)
On Sun, 19 Sep 2010, Shiv Kumar wrote: > > I'd like to see the implementation of the poster attribute change to > something that is more useful. By useful I mean something that wroks > without the need for javascript and works the way most people would > expect. > > Currently the poster disappears as soon as the first frame has been > downloaded, which typically takes a second. 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 the poster while seeking, resulting a flashes) 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. Meaning that one should be able to turn on/off the > poster (without changing the poster attrbute's value) What's the use case for this? On Mon, 20 Sep 2010, Silvia Pfeiffer wrote: > > | When a video element is paused and the current playback position is > | the first frame of video, the element represents either the frame of > | video corresponding to the current playback position or the poster > | frame, at the discretion of the user agent. > > The first half of the either...or... statement is really annoying and > should be removed. 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 other > possibilities are available via trivial scripting (remove it or even > replace it with a different poster after we start playing). If the > poster does not redisplay and the content presenter wants it to, we're > back into scripting an entire control system from scratch, as overlaying > a div/image [to get the poster back] hides the native controls and makes > them inaccessable again. 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 feedback from our users > on this (they have a lot). > > * 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 black for 99% of videos, so they end up using > the poster anyway. We've resisted this because of limitations in Flash > (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 poster set and preload is set to auto (or add > another preload level for poster). 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 indication that you're buffering. This also. > * We've never had anyone request different poster images for begin / > pause / end. People generally just want it to appear at the beginning > 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 sense to clear it in the setter for <video> src, but > I could see this confusing people as well. 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 able to do > things via script, but rather declaratively via attributes to the extent > possible. At least that's the way I feel Html should be. That is, to the > extent possible, Html should be self sufficient, without requiring > JavaScript to get the job done. I mean that is the direction we're > trying to take Html 5 in isn't it? All of the things people have been > doing over the years using JavaScript are finding their way into the > Html spec (such as date, validations, required etc.). 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 I can think of is, that currently there > is no way to make it visible if one wanted to. Typically, we show the > poster after the video has ended because it implies to our users that > they can play the video again if they want to. And the poster *is* the > identifier of the video and not a usually black frame and content > 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 should be a way to make it visible. Website > developers are then free to make the choice for themselves. As it stands > now, one is forced to overlay an image over the video tag and not have > 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 functionality of a new spec is to be implemented? And > 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 to be shown when the video > has ended, if that is the most commonly desired behavior. 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 is a "start poster" then it must be displayed while any pre-loading > takes place, if there is no pre-loading or auto-play then it must remain > displayed until the user press play/pause/stop. > if there is a "start poster" then it must be removed if the user press > play/pause/stop or pre-loading has progressed far enough for autoplay to > start. 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 the user as they please, a small symbol or control may be > shown during the paused frame to indicate there is a "paused poster" > available. 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 may be the exact > same poster or different posters. > The 3 different types of posters must be scriptable to allow rotation between > multiple different 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 curious! Not currently. On Sun, 19 Sep 2010, Shiv Kumar wrote: > > As regards having more control of the poster?s visibility, what I?m > saying is that one should have the ability to turn on/off a poster. > Currently once the poster has been made invisible by the UA, there is no > way to turn it back on. So if I wanted to turn it back on after the > video has ended, I can?t and I think people should have that choice? 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 be intuitive? I'm > getting the video element to load it's source and so the poster will > show? 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 property and a visible property. Or to not break > current implementations. The video element could have a method called > showPoster(bool) or a bool property called postervisible. 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 matter of taste. How > about we remain with a single 'poster' attribute, and add a 'showposter' > attibute, with values 'start', 'end', and 'both', which denote when the > poster is shown? Or the values could be enumerated similar to how > readyState and networkState are enumerated. 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 case where we > allow users to switch versions of video in mid step that is while the > viewer is watch a video of say medium quality and wants to switch to the > HD version, today they can seamlessly switch (without having to start > from the beginning). We use the load method to do what it does today to > do that. > > Of course we wouldn?t want the user to see the poster during the time > it takes to switch so we clear value of the poster before doing this, > which is one of the issues cited in my very first post on this subject. 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 poster are quite frankly independent of each > other. One is a video stream and the other is an image. 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 bandwidth stealing and such). Using load could impact > this delicate balance as well. 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 else, especially as it pertains to the video > stream. The poster and the video are separate and should remain so. 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 set the currentSrc to a new resource URL, then call > load() and it will reset the player controls to start at the beginning, it > will reset the currentTime to 0 and basically do a whole reset. In fact, it > will even start playing back the element, even if it was set to pause before > (this happens in all browsers and I find that kinda strange actually). 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 simple method (with > no side effects) to make a poster visible/invisible? 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. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 8 December 2010 18:55:10 UTC