Re: [whatwg] Html 5 video element's poster attribute
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 i...@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
Re: [whatwg] Html 5 video element's poster attribute
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 sin...@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 i...@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
Re: [whatwg] Html 5 video element's poster attribute
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
Re: [whatwg] Html 5 video element's poster attribute
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 i...@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
Re: [whatwg] Html 5 video element's poster attribute
We should also tighten up the language so that the poster must be shown up until playback begins Yes, please or a seek completes, rather than can be shown though. No, this won't work. I don't want the poster to be shown during a seek so the question of showing it until seek completes is moot. I agree, you don't want all those side effects just to show the poster. If you want to change when the poster appears, you're better off creating your own poster as an image element. So really, what you're saying is simply forget about using the poster attribute altogether. Which is exactly what a few others have done including us, so this whole dialog has been futile. In that case you don't need to tihghten up the spec either. You can implement media switching in mid play by loading the new resource in a new video element, seeking to the switch over point, and then swapping the new video element in place of the old one. When you call load(), the poster will be shown, but when the seek completes, the poster image will be replaced by the frame at the seek target location. This would be quicker than stopping playback of the existing resource, starting a new load in the existing media element, waiting for the new load to initialize, waiting for the seek to the change over point to complete, and then resuming playback. Unlike your proposed method, it can be done without needing to stop playback. Given that this better alternative method exists to achieve what you want, I don't think your case 3 is a strong argument against displaying the poster every time we call load(). Chris, this is awesome dude! Why didn't I think of this. This is a far better solution for a very typical use case. So now I need to sync events across multiple payers, keep playing player 1 and leave the user wondering why her choice hasn't taken effect while I silently load the other video in the background and then ..hmm I get now. That's a much better solution to my need for turning a poster on/off. Ok, serious now.. Chris, it seems to me that you agree that the load() method is not the right method to turn on the poster. Is that correct? Shiv http://exposureroom.com/ http://exposureroom.com From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Chris Pearce Sent: Wednesday, September 22, 2010 1:23 AM To: whatwg@lists.whatwg.org Subject: Re: [whatwg] Html 5 video element's poster attribute On 22/09/2010 4:26 p.m., Shiv Kumar wrote: What I suggested was to use a call to the load() So in your mind calling load() implies showing the poster? I think we should change to this. Then every call to load() would have the same effect. We should also tighten up the language so that the poster must be shown up until playback begins or a seek completes, rather than can be shown though. That would (hopefully!) ensure cross browser consistency. The other reason (that I've mentioned repeatedly) for not wanting to use the load method is this: The load method has way too many side effects including events no less, oh and did I mention have the player now go to pause and have the readyState switch to HAVE_NOTHING, when there is meta data and to Network state go to empty when it's really idle? Gosh, I could take almost every other step in the media element load algorithm stated procedure. These side (I've only listed small number above) effects are not desireable when all we want to do is turn on/off the poster. I agree, you don't want all those side effects just to show the poster. If you want to change when the poster appears, you're better off creating your own poster as an image element. The just show the poster until I play or seek case is the common case. If you want to customize your player, you can still do that. Alter the load alogorithm to now fiddle with the poster will impact the other use case I've mentioned and that is, the ability to be able to switch media in mid play. We call the load() method to be able to do this (because of the things it does do listed above). So now we'll have the poster become visible while we're trying to switch video streams? You can implement media switching in mid play by loading the new resource in a new video element, seeking to the switch over point, and then swapping the new video element in place of the old one. When you call load(), the poster will be shown, but when the seek completes, the poster image will be replaced by the frame at the seek target location. This would be quicker than stopping playback of the existing resource, starting a new load in the existing media element, waiting for the new load to initialize, waiting for the seek to the change over point to complete, and then resuming playback. Unlike your proposed method, it can be done without needing to stop playback. Given that this better alternative method exists to achieve what you want, I don't think your case 3 is a strong
Re: [whatwg] Html 5 video element's poster attribute
On Wed, Sep 22, 2010 at 6:00 PM, Shiv Kumar sku...@exposureroom.com wrote: No, this won’t work. I don’t want the poster to be shown during a seek so the question of showing it until seek completes is moot. I think Chris meant that the poster should remain shown if the user chose to seek instead of play when the video first loads. Showing the poster during any other seek wouldn't make sense. So really, what you’re saying is simply forget about using the poster attribute altogether. Which is exactly what a few others have done including us, so this whole dialog has been futile. In that case you don’t need to tihghten up the spec either. Unfortunately, as has been pointed out by others, the 'using an image' approach becomes problematic when you are using the built in browser controls. I like the idea of being able to manually turn on and off the poster display. Removing the poster attribute is an option to turn the poster off but there is no way to turn it back on again. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] Html 5 video element's poster attribute
On Wed, Sep 22, 2010 at 12:14 AM, Shiv Kumar sku...@exposureroom.com wrote: Now as far as how to fix this is concerned, I've repeatedly provided use cases for why the load() may not work (won't satisfy one of the use cases I've cited) as well as why the load() method shouldn't be used (because of all the side effects it produces). Totally agree - calling load() has a *ton* of side effects besides just showing the poster and it doesn't seem appropriate, except for (perhaps) the case of playback complete / stopped. While I have your attention, what are your thoughts and what you call The Golden Rule and Html 5 video players? Different discussion (content protection). More than happy to take it up in another thread. -- Zachary Ozer Developer, LongTail Video w: longtailvideo.com • e: z...@longtailvideo.com • p: 212.244.0140 • f: 212.656.1335 JW Player | Bits on the Run | AdSolution
Re: [whatwg] Html 5 video element's poster attribute
On Wed, Sep 22, 2010 at 4:47 PM, Chris Double chris.dou...@double.co.nzwrote: On Wed, Sep 22, 2010 at 6:00 PM, Shiv Kumar sku...@exposureroom.com wrote: No, this won’t work. I don’t want the poster to be shown during a seek so the question of showing it until seek completes is moot. I think Chris meant that the poster should remain shown if the user chose to seek instead of play when the video first loads. Showing the poster during any other seek wouldn't make sense. So really, what you’re saying is simply forget about using the poster attribute altogether. Which is exactly what a few others have done including us, so this whole dialog has been futile. In that case you don’t need to tihghten up the spec either. Unfortunately, as has been pointed out by others, the 'using an image' approach becomes problematic when you are using the built in browser controls. I like the idea of being able to manually turn on and off the poster display. Removing the poster attribute is an option to turn the poster off but there is no way to turn it back on again. You just need to remember the value of the poster element before you remove it - then you can set it back later. Silvia.
Re: [whatwg] Html 5 video element's poster attribute
On Wed, Sep 22, 2010 at 9:54 PM, Chris Double chris.dou...@double.co.nzwrote: On Wed, Sep 22, 2010 at 11:50 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: Removing the poster attribute is an option to turn the poster off but there is no way to turn it back on again. You just need to remember the value of the poster element before you remove it - then you can set it back later. I might be misunderstanding what was requested but I don't think this would work. Setting it back won't make the poster appear. The original request was to have a way to make the poster appear or disappear at will. I don't think there is a way at all of re-displaying the poster without creating a new video element is there? Ah I see that's what you meant. Yes, there isn't right now. My suggestion was to adapt the functionality of load() to provide for this need at the end of the video playback. For displaying the poster at any other time, you would still need to run you own javascript code, but I see that as a minor use case, so that should be ok. Cheers, Silvia.
Re: [whatwg] Html 5 video element's poster attribute
On Wed, 22 Sep 2010 14:14:34 +0200, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: On Wed, Sep 22, 2010 at 9:54 PM, Chris Double chris.dou...@double.co.nzwrote: On Wed, Sep 22, 2010 at 11:50 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: Removing the poster attribute is an option to turn the poster off but there is no way to turn it back on again. You just need to remember the value of the poster element before you remove it - then you can set it back later. I might be misunderstanding what was requested but I don't think this would work. Setting it back won't make the poster appear. The original request was to have a way to make the poster appear or disappear at will. I don't think there is a way at all of re-displaying the poster without creating a new video element is there? Ah I see that's what you meant. Yes, there isn't right now. My suggestion was to adapt the functionality of load() to provide for this need at the end of the video playback. For displaying the poster at any other time, you would still need to run you own javascript code, but I see that as a minor use case, so that should be ok. Calling load() would cause the video decoding pipeline to be destroyed and recreated, jumping to the beginning of the video. load() is basically only for manually triggering resource selection after modifying source elements, I think we should use it as little as possible. Resetting the poster state in load() might be a good idea, but it doesn't really solve the problem at hand. I don't have a strong opinion on whether or not the problem is worth solving, but if we do solve it a read-write posterVisible IDL attribute would be OK by me. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] Html 5 video element's poster attribute
You just need to remember the value of the poster element before you remove it - then you can set it back later. Silvia, have you tried this? Remember that at this time the poster never comes back on after the video has ended even if the poster attribute is set. Shiv http://exposureroom.com/ http://exposureroom.com
Re: [whatwg] Html 5 video element's poster attribute
On Tue, Sep 21, 2010 at 3:03 PM, Shiv Kumar sku...@exposureroom.com wrote: For the pause state you will have to use the onpause event to make any changes. But to be honest, I doubt anyone would want to show the poster in pause state. I have not seen that anywhere yet and I have come across a sizeable number of video sites. Can you point to a single one that currently loads a poster image when you press pause? Someone here mentioned Voddler. I’ve seen a few, but I can’t recall. Some of our content producers have requested this too but we’ve not provided them with this feature. Hmm... voddler is not available in my country. :( Any other examples? I'm really trying to understand the use case here. Can you give me a good reason/case for not having a simple method (with no side effects) to make a poster visible/invisible? I can see the use case for when the video is finished and rewinds to the start, and I can see a means to address that without having more attributes. But I cannot see the need for having it mid-video on pause. In fact, I would regard that as pretty poor user interface design actually because you would be seeing the representative poster rather than the current video frame, giving you no indication whatsoever where in the video you currently are. Often when people pause a video they do that to check out what is going on in these frames, e.g. to read some text that is in the frame. Replacing that context frame with a poster makes no sense to me and actually reduces usability. It's particularly bad for people who may need longer to grasp some visual content in the scene than your average user, so it also negatively influences accessibility. I haven't seen a case yet that speaks for having this feature, but I can already come up with two good reasons for not having that feature. Regards, Silvia.
Re: [whatwg] Html 5 video element's poster attribute
On 21 Sep 2010, at 06:03, 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? Just a reminder, we need solid reasons to *add* a feature, not solid reasons *not to add* a feature. http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F -- Benjamin Hawkes-Lewis
Re: [whatwg] Html 5 video element's poster attribute
Silvia, I don't believe you've given is a good reason and use case for not having a single method the allows turning on and off the poster without any side effects. I haven't seen a case yet that speaks for having this feature, but I can already come up with two good reasons for not having that feature. The feature you're talking about is not the feature I'm asking for. I'm asking for a simple method that allows turning on/off the poster without any side effects. I can already come up with two good reasons for not having that feature. That's like saying people will use the Html 5 video player for porn so lets not givem them that ability. Besides, they can do it (showing an image during pause) wheter you like it or not in a hundred other ways. Shiv http://exposureroom.com/ http://exposureroom.com
Re: [whatwg] Html 5 video element's poster attribute
Bejamin, I believe I have provided reasons. It seem in principle people agree. What's we're stuck on is how to go about it. I don't believe providing an indirect method that has a side effect of turning on a poster is the right way to go about it while still leaving the poster as a stepchild of the video element without any direct control over it. Shiv http://exposureroom.com
Re: [whatwg] Html 5 video element's poster attribute
Benjamin, To add to my earlier reply... I proposed that there be a method such as setPostervisibility(bool) to implement this feature while Silvia is proposing this feature be implemented via the load() method. So it then makes sense that she give good reason for and against, just as I have. Shiv http://exposureroom.com
Re: [whatwg] Html 5 video element's poster attribute
Shiv - Why is simply removing the poster attribute unacceptable? -- Zachary Ozer Developer, LongTail Video w: longtailvideo.com • e: z...@longtailvideo.com • p: 212.244.0140 • f: 212.656.1335 JW Player | Bits on the Run | AdSolution On Tue, Sep 21, 2010 at 10:45 AM, Shiv Kumar sku...@exposureroom.com wrote: Benjamin, To add to my earlier reply... I proposed that there be a method such as setPostervisibility(bool) to implement this feature while Silvia is proposing this feature be implemented via the load() method. So it then makes sense that she give good reason for and against, just as I have. Shiv http://exposureroom.com
Re: [whatwg] Html 5 video element's poster attribute
On 21 Sep 2010, at 15:45, Shiv Kumar wrote: I proposed that there be a method such as setPostervisibility(bool) to implement this feature while Silvia is proposing this feature be implemented via the load() method. So it then makes sense that she give good reason for and against, just as I have. As I understand it, Silvia is suggesting you use an existing feature in the spec to do what you want to do, whereas you are proposing to add a *new* feature to the spec to do what you want to do. As per the FAQ, adding new features requires justification; not adding new features does not require justification. I'm not saying your new feature is without any justification. -- Benjamin Hawkes-Lewis
Re: [whatwg] Html 5 video element's poster attribute
Zachary, Why is simply removing the poster attribute unacceptable? Gosh, that's pretty radical isn't it? I've thought about it and if the poster is not usable then yes, I'd rather not have it at all and resort to the implementations (by websites) currently in place. On second thought are you asking about assigning a null/empty string to the poster attribute? If so, then that only hides the poster. But I'm asking for a way to make the poster visible when desired. Shiv http://exposureroom.com -Original Message- From: Zachary Ozer [mailto:z...@longtailvideo.com] Sent: Tuesday, September 21, 2010 1:21 PM To: Shiv Kumar Cc: Benjamin Hawkes-Lewis; Silvia Pfeiffer; WHATWG Subject: Re: [whatwg] Html 5 video element's poster attribute Shiv - Why is simply removing the poster attribute unacceptable? -- Zachary Ozer Developer, LongTail Video w: longtailvideo.com • e: z...@longtailvideo.com • p: 212.244.0140 • f: 212.656.1335 JW Player | Bits on the Run | AdSolution On Tue, Sep 21, 2010 at 10:45 AM, Shiv Kumar sku...@exposureroom.com wrote: Benjamin, To add to my earlier reply... I proposed that there be a method such as setPostervisibility(bool) to implement this feature while Silvia is proposing this feature be implemented via the load() method. So it then makes sense that she give good reason for and against, just as I have. Shiv http://exposureroom.com
Re: [whatwg] Html 5 video element's poster attribute
Benjamin, Ok, I see your point. So yes, I'm asking for a better implementation of an existing feature. So far I've made two proposals as regards the video element's poster. 1. The poster should stay visible until the video is played, rather than disappear as soon as the first frame is loaded. In addition, the poster should not show during buffering or any operation during video playback or switching video streams in mid step. 2. We need direct control over the poster. In principal, both seem to have been accepted. The ongoing debate is about how to implement, #2 above. So far there have been two proposals 1. Enhance the existing load() method to do this. 2. provide a spate method (for example setPostervisibility(bool)) to do this. My reasoning (mind you I've provided many use cases to support this) is that: 1. Currently, the poster is treated as a stepchild of the video element in that there is *no direct control* over the poster. 2. I also see the poster separate from the video in that it's only functionality is show/hide (or fade in/out). Attaching it to logic/processing sequences associated to loading and initializing the video stream (which has many side effects) is not appropriate. 3. Being able to turn on/off a poster *without side effects* is very important. Shiv http://exposureroom.com
Re: [whatwg] Html 5 video element's poster attribute
On Sep 21, 2010, at 11:17 AM, Shiv Kumar wrote: 1. The poster should stay visible until the video is played, rather than disappear as soon as the first frame is loaded. In addition, the poster should not show during buffering or any operation during video playback or switching video streams in mid step. This is a description of how the poster should behave in all browsers. Have you filed bugs against any browsers that do not behave this way? eric
Re: [whatwg] Html 5 video element's poster attribute
On Tue, Sep 21, 2010 at 1:53 PM, Shiv Kumar sku...@exposureroom.com wrote:
Zachary,
Why is simply removing the poster attribute unacceptable?
Gosh, that's pretty radical isn't it? I've thought about it and if the poster
is not usable then yes, I'd rather not have it at all and resort to the
implementations (by websites) currently in place.
Sorry to be unclear - I should have specified that I meant removing
the poster attribute for a specific video tag, vis-a-vis
'videoElement.removeAttribute(''poster)'.
On Tue, Sep 21, 2010 at 2:17 PM, Shiv Kumar sku...@exposureroom.com wrote:
Benjamin,
Ok, I see your point. So yes, I'm asking for a better implementation of an
existing feature.
So far I've made two proposals as regards the video element's poster.
1. The poster should stay visible until the video is played, rather than
disappear as soon as the first frame is loaded. In addition, the poster
should not show during buffering or any operation during video playback or
switching video streams in mid step.
2. We need direct control over the poster.
In principal, both seem to have been accepted. The ongoing debate is about
how to implement, #2 above. So far there have been two proposals
1. Enhance the existing load() method to do this.
2. provide a spate method (for example setPostervisibility(bool)) to do
this.
My reasoning (mind you I've provided many use cases to support this) is
that:
1. Currently, the poster is treated as a stepchild of the video element in
that there is *no direct control* over the poster.
2. I also see the poster separate from the video in that it's only
functionality is show/hide (or fade in/out). Attaching it to
logic/processing sequences associated to loading and initializing the video
stream (which has many side effects) is not appropriate.
3. Being able to turn on/off a poster *without side effects* is very
important.
Using the current API, we've implemented the alternative you've
described, namely removing the poster attribute, placing another image
above video (of the same size), and swapping z-indexes as needed.
The other benefit to this is that it allows to to appropriately
stretch / size the poster image.
As you point out, the video and poster are stepchildren - related in
that it's clear that certain properties should change in lockstep, but
necessarily clear *how* they should change. Assume for a moment that
browsers allowed separate CSS configurations for the video and poster.
What happens when I change the size of the video? Would it update
both? Just the active one? Additionally - size is the obvious case.
What about opacity? Stretching (which should be fixed in CSS at some
point - http://dev.w3.org/csswg/css3-images/#object-fit0)?
My point is that it gets very complicated very quickly, and it's not
clear what to do. So we go to use cases: concrete examples that
demonstrate why a certain functionality is needed / useful and cannot
be replicated otherwise.
As an analogy, consider the audio track for a video. We also allow
audio levels to be controlled separately from the video via volume.
This is because there is no other way to adjust the volume without
changing the audio file itself.
However, it's possible to show / hide the poster either by hiding the
video tag (and adding an image) or by removing the poster attribute
from the tag itself. You could even dial back the opacity of the video
tag (analogous to lowering the volume of the video).
For example, your issue got me thinking that there should be an API
for telling the browser to render whatever's inside of a video tag
while the video isn't play (with the controls on top) since my gut
tells me that there are use cases for this. However, I'm really
ambivalent, since there are many other ways to achieve the same effect
(mostly), so why not just use those? Until I have a really compelling
use case, I can't really justify proposing that it go into the spec.
As other people have said, it would be really useful if you could
provide a *compelling* use case, one where the other proposed
solutions wouldn't do.
Best,
Zach
--
Zachary Ozer
Developer, LongTail Video
w: longtailvideo.com • e: z...@longtailvideo.com • p: 212.244.0140 •
f: 212.656.1335
JW Player | Bits on the Run | AdSolution
Re: [whatwg] Html 5 video element's poster attribute
Hi Zach,
Sure pretty much anything is possible. In fact everything in the Html 5 spec is
already doable is it not? If it's not JavaScript that comes to the rescue it's
Flash player or a combination of the two.
I understand completely your point of view on the other stuff you described and
believe me I don't think for a moment that defining a spec is easy or the job
of implementers is easy.
But I do believe the purpose of this spec (Html 5) is to make what people have
been doing over the years using JavaScript and Flash player) easier and more
approachable.
Who was it that said, If it's worth doing, then it's worth doing right? Since
there *is* a poster feature to the video element then I'd like to see it
implemented such that it if useful. Or as I stated earlier, I'd rather see it
no there. And honestly, what is compelling to some, is not compelling enough
for others. People are using this so there is a use case.
Would you support taking the poster attribute out of the spec?
Or are you saying just leave it broken because fixing it a really complicated.
I'm not sure where you stand on the issue of providing a method to turn on/off
the poster or modify the spec on the load() method to include verbiage about
how the implementations should treat the poster attribute.
Shiv
http://exposureroom.com
-Original Message-
From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org]
On Behalf Of Zachary Ozer
Sent: Tuesday, September 21, 2010 3:15 PM
To: Shiv Kumar
Cc: Silvia Pfeiffer; WHATWG; Benjamin Hawkes-Lewis
Subject: Re: [whatwg] Html 5 video element's poster attribute
On Tue, Sep 21, 2010 at 1:53 PM, Shiv Kumar sku...@exposureroom.com wrote:
Zachary,
Why is simply removing the poster attribute unacceptable?
Gosh, that's pretty radical isn't it? I've thought about it and if the poster
is not usable then yes, I'd rather not have it at all and resort to the
implementations (by websites) currently in place.
Sorry to be unclear - I should have specified that I meant removing
the poster attribute for a specific video tag, vis-a-vis
'videoElement.removeAttribute(''poster)'.
On Tue, Sep 21, 2010 at 2:17 PM, Shiv Kumar sku...@exposureroom.com wrote:
Benjamin,
Ok, I see your point. So yes, I'm asking for a better implementation of an
existing feature.
So far I've made two proposals as regards the video element's poster.
1. The poster should stay visible until the video is played, rather than
disappear as soon as the first frame is loaded. In addition, the poster
should not show during buffering or any operation during video playback or
switching video streams in mid step.
2. We need direct control over the poster.
In principal, both seem to have been accepted. The ongoing debate is about
how to implement, #2 above. So far there have been two proposals
1. Enhance the existing load() method to do this.
2. provide a spate method (for example setPostervisibility(bool)) to do
this.
My reasoning (mind you I've provided many use cases to support this) is
that:
1. Currently, the poster is treated as a stepchild of the video element in
that there is *no direct control* over the poster.
2. I also see the poster separate from the video in that it's only
functionality is show/hide (or fade in/out). Attaching it to
logic/processing sequences associated to loading and initializing the video
stream (which has many side effects) is not appropriate.
3. Being able to turn on/off a poster *without side effects* is very
important.
Using the current API, we've implemented the alternative you've
described, namely removing the poster attribute, placing another image
above video (of the same size), and swapping z-indexes as needed.
The other benefit to this is that it allows to to appropriately
stretch / size the poster image.
As you point out, the video and poster are stepchildren - related in
that it's clear that certain properties should change in lockstep, but
necessarily clear *how* they should change. Assume for a moment that
browsers allowed separate CSS configurations for the video and poster.
What happens when I change the size of the video? Would it update
both? Just the active one? Additionally - size is the obvious case.
What about opacity? Stretching (which should be fixed in CSS at some
point - http://dev.w3.org/csswg/css3-images/#object-fit0)?
My point is that it gets very complicated very quickly, and it's not
clear what to do. So we go to use cases: concrete examples that
demonstrate why a certain functionality is needed / useful and cannot
be replicated otherwise.
As an analogy, consider the audio track for a video. We also allow
audio levels to be controlled separately from the video via volume.
This is because there is no other way to adjust the volume without
changing the audio file itself.
However, it's possible to show / hide the poster either by hiding the
video tag (and adding an image) or by removing the poster attribute
from
Re: [whatwg] Html 5 video element's poster attribute
Part of the issue is that I'm not sure.
Now that the poster (rather than the first frame) should appear for
Webkit browsers, and stretching should be handled by CSS (for both the
video and poster), I'm rather satisfied.
While I can think of times when one *might* want it to also appear (on
buffer, on pause, etc), I'm not sure it's used in practice. Is there a
different instance where it would be usable?
And for this, I refer you to Einstein, who said (approximately), Make
things as simple as possible, but not simpler. [1]
Best,
Zach
[1] : http://en.wikiquote.org/wiki/Albert_Einstein
--
Zachary Ozer
Developer, LongTail Video
w: longtailvideo.com • e: z...@longtailvideo.com • p: 212.244.0140 •
f: 212.656.1335
JW Player | Bits on the Run | AdSolution
On Tue, Sep 21, 2010 at 3:45 PM, Shiv Kumar sku...@exposureroom.com wrote:
Hi Zach,
Sure pretty much anything is possible. In fact everything in the Html 5 spec
is already doable is it not? If it's not JavaScript that comes to the rescue
it's Flash player or a combination of the two.
I understand completely your point of view on the other stuff you described
and believe me I don't think for a moment that defining a spec is easy or the
job of implementers is easy.
But I do believe the purpose of this spec (Html 5) is to make what people
have been doing over the years using JavaScript and Flash player) easier and
more approachable.
Who was it that said, If it's worth doing, then it's worth doing right?
Since there *is* a poster feature to the video element then I'd like to see
it implemented such that it if useful. Or as I stated earlier, I'd rather see
it no there. And honestly, what is compelling to some, is not compelling
enough for others. People are using this so there is a use case.
Would you support taking the poster attribute out of the spec?
Or are you saying just leave it broken because fixing it a really complicated.
I'm not sure where you stand on the issue of providing a method to turn
on/off the poster or modify the spec on the load() method to include verbiage
about how the implementations should treat the poster attribute.
Shiv
http://exposureroom.com
-Original Message-
From: whatwg-boun...@lists.whatwg.org
[mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Zachary Ozer
Sent: Tuesday, September 21, 2010 3:15 PM
To: Shiv Kumar
Cc: Silvia Pfeiffer; WHATWG; Benjamin Hawkes-Lewis
Subject: Re: [whatwg] Html 5 video element's poster attribute
On Tue, Sep 21, 2010 at 1:53 PM, Shiv Kumar sku...@exposureroom.com wrote:
Zachary,
Why is simply removing the poster attribute unacceptable?
Gosh, that's pretty radical isn't it? I've thought about it and if the
poster is not usable then yes, I'd rather not have it at all and resort to
the implementations (by websites) currently in place.
Sorry to be unclear - I should have specified that I meant removing
the poster attribute for a specific video tag, vis-a-vis
'videoElement.removeAttribute(''poster)'.
On Tue, Sep 21, 2010 at 2:17 PM, Shiv Kumar sku...@exposureroom.com wrote:
Benjamin,
Ok, I see your point. So yes, I'm asking for a better implementation of an
existing feature.
So far I've made two proposals as regards the video element's poster.
1. The poster should stay visible until the video is played, rather than
disappear as soon as the first frame is loaded. In addition, the poster
should not show during buffering or any operation during video playback or
switching video streams in mid step.
2. We need direct control over the poster.
In principal, both seem to have been accepted. The ongoing debate is about
how to implement, #2 above. So far there have been two proposals
1. Enhance the existing load() method to do this.
2. provide a spate method (for example setPostervisibility(bool)) to do
this.
My reasoning (mind you I've provided many use cases to support this) is
that:
1. Currently, the poster is treated as a stepchild of the video element in
that there is *no direct control* over the poster.
2. I also see the poster separate from the video in that it's only
functionality is show/hide (or fade in/out). Attaching it to
logic/processing sequences associated to loading and initializing the video
stream (which has many side effects) is not appropriate.
3. Being able to turn on/off a poster *without side effects* is very
important.
Using the current API, we've implemented the alternative you've
described, namely removing the poster attribute, placing another image
above video (of the same size), and swapping z-indexes as needed.
The other benefit to this is that it allows to to appropriately
stretch / size the poster image.
As you point out, the video and poster are stepchildren - related in
that it's clear that certain properties should change in lockstep, but
necessarily clear *how* they should change. Assume for a moment that
browsers allowed separate CSS configurations
Re: [whatwg] Html 5 video element's poster attribute
On Wed, Sep 22, 2010 at 12:13 AM, Shiv Kumar sku...@exposureroom.comwrote: Silvia, I don’t believe you’ve given is a good reason and use case for not having a single method the allows turning on and off the poster without any side effects. I haven't seen a case yet that speaks for having this feature, but I can already come up with two good reasons for not having that feature. The “feature” you’re talking about is not the feature I’m asking for. I’m asking for a simple method that allows turning on/off the poster without any side effects. I can already come up with two good reasons for not having that feature. That’s like saying people will use the Html 5 video player for porn so lets not givem them that ability. Besides, they can do it (showing an image during pause) wheter you like it or not in a hundred other ways. Indeed. The question is not whether it should be disallowed - I have no problem with people rolling their own functionality for overlay images. The question is whether it should be a standard feature and therefore something that people are encouraged to use. I've listed some reasons for why the functionality of automatically switching to a poster image upon pause isn't desirable. I've also stated that I believe that the poster should indeed be displayed when the video element is just loaded and not on autoplay. And I have agreed that there should be a possibility to have that state return after the video has played through. The functionality that you are talking about, namely that of replacing the video display with the poster image at any time is not what I understand a poster image should be. That is a different kind of image and the only reason for introducting such an image type would be to continue running the default controls over the top of an overlay image. I do not believe that is the aim of a poster image. This functionality may actually be possible with the introduction of subtitle tracks, if subtitle tracks are to be allowed to have images in them. That to me seems the more logical way of introducing and satisfying such a need. Cheers, Silvia.
Re: [whatwg] Html 5 video element's poster attribute
I've also stated that I believe that the poster should indeed be displayed when the video element is just loaded and not on autoplay. And I have agreed that there should be a possibility to have that state return after the video has played through Yes, you have and so we're (thankfully) on the same page and so are some others. Whew! Just to clarify, I'm not saying that there is a dire need to show the poster anytime during plaback. But it is a use case that is currently in use by a well known website and there may be others as well. I (ExposureRoom, really) have a need to show the poster at the end of the video and we allow content producers to control that, meaning they can choose not to). You and I and a couple of other don't see eye to eye on how this fix needs to be brought to fore. I'm specitcal about the load() method and stated why in previous posts. What if someone does not want to show the poster at the end. YouTube and Vimeo are examples of that user case. How do you propose they have the option to not show the poster? So in order to provide this flexibility and make the video element useable insofar as the features it does provide, I still feel providing a method to turn it on/off satisfies the current use cases, including those we may not agree with. Yes, using the removeAttribute is a hack when the needs have been clearly demonstrated (I believe). Shiv http://exposureroom.com/ http://exposureroom.com
Re: [whatwg] Html 5 video element's poster attribute
On Wed, Sep 22, 2010 at 12:52 PM, Shiv Kumar sku...@exposureroom.comwrote: I've also stated that I believe that the poster should indeed be displayed when the video element is just loaded and not on autoplay. And I have agreed that there should be a possibility to have that state return after the video has played through Yes, you have and so we’re (thankfully) on the same page and so are some others. Whew! Just to clarify, I’m not saying that there is a dire need to show the poster anytime during plaback. But it is a use case that is currently in use by a well known website and there may be others as well. I (ExposureRoom, really) have a need to show the poster at the end of the video and we allow content producers to control that, meaning they can choose not to). You and I and a couple of other don’t see eye to eye on how this “fix” needs to be brought to fore. I’m specitcal about the load() method and stated why in previous posts. What if someone does not want to show the poster at the end. YouTube and Vimeo are examples of that user case. How do you propose they have the option to not show the poster? That's how it works by default. What I suggested was to use a call to the load() method after it has played through to reset to the beginning state if you really need that. Thus, it covers both use cases. So in order to provide this flexibility and make the video element useable insofar as the features it does provide, I still feel providing a method to turn it on/off satisfies the current use cases, including those we may not agree with. Yes, using the removeAttribute is a hack when the needs have been clearly demonstrated (I believe). It's how you remove the poster. It's a single function call and thus not a hack. Regards, Silvia.
Re: [whatwg] Html 5 video element's poster attribute
Zach,
Just to set the record straight. The question of the feature or fix is not
the debate but rather how this fix is to be implemented.
Now as far as how to fix this is concerned, I've repeatedly provided use cases
for why the load() may not work (won't satisfy one of the use cases I've cited)
as well as why the load() method shouldn't be used (because of all the side
effects it produces).
I realizse that people are free to write off everything I've said as not
compelling enough. It a free world after all.
Thanks for your other thoughts though (on implementing your own poster), it
just goes to show how inadequate this feature is, as is (we don't have the
issue of needing to size the thumbnails because we enforce same aspect rules.
While I have your attention, what are your thoughts and what you call The
Golden Rule and Html 5 video players?
Shiv
http://exposureroom.com
-Original Message-
From: Zachary Ozer [mailto:z...@longtailvideo.com]
Sent: Tuesday, September 21, 2010 3:15 PM
To: Shiv Kumar
Cc: Benjamin Hawkes-Lewis; Silvia Pfeiffer; WHATWG
Subject: Re: [whatwg] Html 5 video element's poster attribute
On Tue, Sep 21, 2010 at 1:53 PM, Shiv Kumar sku...@exposureroom.com wrote:
Zachary,
Why is simply removing the poster attribute unacceptable?
Gosh, that's pretty radical isn't it? I've thought about it and if the poster
is not usable then yes, I'd rather not have it at all and resort to the
implementations (by websites) currently in place.
Sorry to be unclear - I should have specified that I meant removing
the poster attribute for a specific video tag, vis-a-vis
'videoElement.removeAttribute(''poster)'.
On Tue, Sep 21, 2010 at 2:17 PM, Shiv Kumar sku...@exposureroom.com wrote:
Benjamin,
Ok, I see your point. So yes, I'm asking for a better implementation of an
existing feature.
So far I've made two proposals as regards the video element's poster.
1. The poster should stay visible until the video is played, rather than
disappear as soon as the first frame is loaded. In addition, the poster
should not show during buffering or any operation during video playback or
switching video streams in mid step.
2. We need direct control over the poster.
In principal, both seem to have been accepted. The ongoing debate is about
how to implement, #2 above. So far there have been two proposals
1. Enhance the existing load() method to do this.
2. provide a spate method (for example setPostervisibility(bool)) to do
this.
My reasoning (mind you I've provided many use cases to support this) is
that:
1. Currently, the poster is treated as a stepchild of the video element in
that there is *no direct control* over the poster.
2. I also see the poster separate from the video in that it's only
functionality is show/hide (or fade in/out). Attaching it to
logic/processing sequences associated to loading and initializing the video
stream (which has many side effects) is not appropriate.
3. Being able to turn on/off a poster *without side effects* is very
important.
Using the current API, we've implemented the alternative you've
described, namely removing the poster attribute, placing another image
above video (of the same size), and swapping z-indexes as needed.
The other benefit to this is that it allows to to appropriately
stretch / size the poster image.
As you point out, the video and poster are stepchildren - related in
that it's clear that certain properties should change in lockstep, but
necessarily clear *how* they should change. Assume for a moment that
browsers allowed separate CSS configurations for the video and poster.
What happens when I change the size of the video? Would it update
both? Just the active one? Additionally - size is the obvious case.
What about opacity? Stretching (which should be fixed in CSS at some
point - http://dev.w3.org/csswg/css3-images/#object-fit0)?
My point is that it gets very complicated very quickly, and it's not
clear what to do. So we go to use cases: concrete examples that
demonstrate why a certain functionality is needed / useful and cannot
be replicated otherwise.
As an analogy, consider the audio track for a video. We also allow
audio levels to be controlled separately from the video via volume.
This is because there is no other way to adjust the volume without
changing the audio file itself.
However, it's possible to show / hide the poster either by hiding the
video tag (and adding an image) or by removing the poster attribute
from the tag itself. You could even dial back the opacity of the video
tag (analogous to lowering the volume of the video).
For example, your issue got me thinking that there should be an API
for telling the browser to render whatever's inside of a video tag
while the video isn't play (with the controls on top) since my gut
tells me that there are use cases for this. However, I'm really
ambivalent, since there are many other ways to achieve the same effect
(mostly), so why not just use
Re: [whatwg] Html 5 video element's poster attribute
Thus, it covers both use cases. I'd say it covers two use cases. Both implies that's all the use cases there are and I've cited 3 that I know of. So if they want to reset the player they'll have to live with the poster showing when the video ends? What I suggested was to use a call to the load() So in your mind calling load() implies showing the poster? The other reason (that I've mentioned repeatedly) for not wanting to use the load method is this: 1. The load method has way too many side effects including events no less, oh and did I mention have the player now go to pause and have the readyState switch to HAVE_NOTHING, when there is meta data and to Network state go to empty when it's really idle? Gosh, I could take almost every other step in the media element load algorithm stated procedure. 2. These side (I've only listed small number above) effects are not desireable when all we want to do is turn on/off the poster. 3. Alter the load alogorithm to now fiddle with the poster will impact the other use case I've mentioned and that is, the ability to be able to switch media in mid play. We call the load() method to be able to do this (because of the things it does do listed above). So now we'll have the poster become visible while we're trying to switch video streams? Shiv http://exposureroom.com http://exposureroom.com/
Re: [whatwg] Html 5 video element's poster attribute
On 22/09/2010 4:26 p.m., Shiv Kumar wrote: What I suggested was to use a call to the load() So in your mind calling load() implies showing the poster? I think we should change to this. Then every call to load() would have the same effect. We should also tighten up the language so that the poster /must/ be shown up until playback begins or a seek completes, rather than /can/ be shown though. That would (hopefully!) ensure cross browser consistency. The other reason (that I've mentioned repeatedly) for not wanting to use the load method is this: 1. The load method has way too many side effects including events no less, oh and did I mention have the player now go to pause and have the readyState switch to HAVE_NOTHING, when there is meta data and to Network state go to empty when it's really idle? Gosh, I could take almost every other step in the media element load algorithm stated procedure... 2. These side (I've only listed small number above) effects are not desireable when all we want to do is turn on/off the poster. I agree, you don't want all those side effects just to show the poster. If you want to change when the poster appears, you're better off creating your own poster as an image element. The just show the poster until I play or seek case is the common case. If you want to customize your player, you can still do that. 3. Alter the load alogorithm to now fiddle with the poster will impact the other use case I've mentioned and that is, the ability to be able to switch media in mid play. We call the load() method to be able to do this (because of the things it does do listed above). So now we'll have the poster become visible while we're trying to switch video streams? You can implement media switching in mid play by loading the new resource in a new video element, seeking to the switch over point, and then swapping the new video element in place of the old one. When you call load(), the poster will be shown, but when the seek completes, the poster image will be replaced by the frame at the seek target location. This would be quicker than stopping playback of the existing resource, starting a new load in the existing media element, waiting for the new load to initialize, waiting for the seek to the change over point to complete, and then resuming playback. Unlike your proposed method, it can be done without needing to stop playback. Given that this better alternative method exists to achieve what you want, I don't think your case 3 is a strong argument against displaying the poster every time we call load(). Regards, Chris P.
Re: [whatwg] Html 5 video element's poster attribute
On 2010-09-20 05:09, Robert O'Callahan wrote: On Sun, Sep 19, 2010 at 10:57 PM, Shiv Kumar sku...@exposureroom.com mailto:sku...@exposureroom.com wrote: I'm glad to see that people do see the need to change (or specify in more detail) the behavior of the poster at least insofar as it disappearing before the video is played. As far as I know, every major browser (IE 9 beta, Firefox, Safari, Chrome and Opera) do this. As Monty discovered, Firefox does not make the poster disappear until the video is played. Feel free to file bugs against any browsers that behave differently; just because the spec allows something doesn't mean it's a good idea! Tightening up the spec to require the poster to remain until the video is played does sound like a good idea. 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. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11] 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'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. 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. 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. Does this sound like something that would satisfy both developers and users, without annoying either? Personally I do not see much point in a paused poster but I guess if it's scriptable it could act as a info card or maybe repeat the chapter title or something like that! Does posters support hotzones at all? To allow clickable items/links/symbols (urls?). Just curious! -- Roger Rescator Hågensen. Freelancer - http://EmSai.net/
Re: [whatwg] Html 5 video element's poster attribute
On 2010-09-20 05:27, Chris Pearce wrote: Right, so you want to be able to toggle the poster back on (when the media is paused or ended) but after playback has started. I wonder if these are separate use cases, e.g. whether users would want to display a different image from the poster image in these cases. i.e. I wonder if we need to provide an attribute to specify an image to display when paused and another new attribute for an image to display when playback has ended. I wonder if that's overkill through. No no no! Read my previous post why a paused poster is bad idea unless done exactly as I suggested there. A paused poster should under no circumstance steal the paused frame, the user may actually want to look closer at the pause frame, if a paused poster force itself to be displayed the user will be pretty pissed. (I certainly would be) The video streaming service Voddler is an annoying example of this, pause the movie in their player and an ad is shown, although I understand why they wish to show an ad, it does makes it impossible to pause and look at the still frame of the video. -- Roger Rescator Hågensen. Freelancer - http://EmSai.net/
Re: [whatwg] Html 5 video element's poster attribute
On 20 September 2010 16:17, Roger Hågensen resca...@emsai.net wrote: On 2010-09-20 05:27, Chris Pearce wrote: Right, so you want to be able to toggle the poster back on (when the media is paused or ended) but after playback has started. I wonder if these are separate use cases, e.g. whether users would want to display a different image from the poster image in these cases. i.e. I wonder if we need to provide an attribute to specify an image to display when paused and another new attribute for an image to display when playback has ended. I wonder if that's overkill through. No no no! Read my previous post why a paused poster is bad idea unless done exactly as I suggested there. A paused poster should under no circumstance steal the paused frame, the user may actually want to look closer at the pause frame, if a paused poster force itself to be displayed the user will be pretty pissed. (I certainly would be) The video streaming service Voddler is an annoying example of this, pause the movie in their player and an ad is shown, although I understand why they wish to show an ad, it does makes it impossible to pause and look at the still frame of the video. -- Roger Rescator Hågensen. Freelancer - http://EmSai.net/ If it's done in markup it's easier to override... Forcing authors to use script for simple things like this just makes life harder for everyone.
Re: [whatwg] Html 5 video element's poster attribute
On Mon, Sep 20, 2010 at 1:38 PM, Shiv Kumar sku...@exposureroom.com wrote: Could a call to video.load() reset this state? 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? 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. Shiv http://exposureroom.com I regard the load() function as a kind of reset() function. But possibly we need an actual reset() function to return to the original state where the poster image is displayed? Silvia.
Re: [whatwg] Html 5 video element's poster attribute
On 20/09/2010 6:11 p.m., Roger Hågensen wrote: 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 This is a good argument against having a paused-poster. The question then is whether the end-poster needs to be different from the start-poster. If the main use case is re-display the poster image so the user knows that they can play again, then the end-poster and start-poster don't need to be different. 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. On 20/09/2010 7:57 p.m., Silvia Pfeiffer wrote: On Mon, Sep 20, 2010 at 1:38 PM, Shiv Kumar sku...@exposureroom.com mailto:sku...@exposureroom.com wrote: Could a call to video.load() reset this state? 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? I regard the load() function as a kind of reset() function. But possibly we need an actual reset() function to return to the original state where the poster image is displayed? It seems reasonable to me that subsequent calls to load() should behave the same was the first call to load(), so the poster should be redisplayed whenever load() is called. We should change the load() algorithm to require the poster frame to be repainted, if it's present. Chris P.
Re: [whatwg] Html 5 video element's poster attribute
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, I agree except for the start, end and both part. We just need one poster and the ability to show it via script. If people want to change posters (I dont know of any site that has support for multiple posters which would mean that the need is not there) they can do it in script. At the moment the poster disappearing and not having the ability to turn it back on renders the poster attribute useless. But let us not complicate it by adding more posters J. Shiv http://exposureroom.com/ http://exposureroom.com From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Chris Pearce Sent: Monday, September 20, 2010 5:27 AM To: whatwg@lists.whatwg.org Subject: Re: [whatwg] Html 5 video element's poster attribute On 20/09/2010 6:11 p.m., Roger Hågensen wrote: 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 This is a good argument against having a paused-poster. The question then is whether the end-poster needs to be different from the start-poster. If the main use case is re-display the poster image so the user knows that they can play again, then the end-poster and start-poster don't need to be different. 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. On 20/09/2010 7:57 p.m., Silvia Pfeiffer wrote: On Mon, Sep 20, 2010 at 1:38 PM, Shiv Kumar sku...@exposureroom.com wrote: Could a call to video.load() reset this state? Currently is doesnt affect the poster. But would that be intuitive? Im getting the video element to load its source and so the poster will show? I regard the load() function as a kind of reset() function. But possibly we need an actual reset() function to return to the original state where the poster image is displayed? It seems reasonable to me that subsequent calls to load() should behave the same was the first call to load(), so the poster should be redisplayed whenever load() is called. We should change the load() algorithm to require the poster frame to be repainted, if it's present. Chris P.
Re: [whatwg] Html 5 video element's poster attribute
On Mon, Sep 20, 2010 at 7:26 PM, Chris Pearce ch...@pearce.org.nz wrote: On 20/09/2010 6:11 p.m., Roger Hågensen wrote: 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 This is a good argument against having a paused-poster. The question then is whether the end-poster needs to be different from the start-poster. If the main use case is re-display the poster image so the user knows that they can play again, then the end-poster and start-poster don't need to be different. 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. On 20/09/2010 7:57 p.m., Silvia Pfeiffer wrote: On Mon, Sep 20, 2010 at 1:38 PM, Shiv Kumar sku...@exposureroom.comwrote: Could a call to video.load() reset this state? 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? I regard the load() function as a kind of reset() function. But possibly we need an actual reset() function to return to the original state where the poster image is displayed? It seems reasonable to me that subsequent calls to load() should behave the same was the first call to load(), so the poster should be redisplayed whenever load() is called. We should change the load() algorithm to require the poster frame to be repainted, if it's present. I think that would be the easiest way to satisfy this requirement. We don't throw away the cached data if load() reloads the same resource and the resource hasn't changed, I assume? Silvia.
Re: [whatwg] Html 5 video element's poster attribute
On Sep 19, 2010, at 3:17 PM, Silvia Pfeiffer wrote: Not quite: this is an implementation decision that Webkit-based browsers made. Neither Opera nor Firefox work that way (haven't checked IE yet). I agree that this implementation of poster frames is practically useless and it really annoys me as a user. I've been considering registering a bug on Webkit. On Sep 19, 2010, at 5:50 PM, Aryeh Gregor wrote: On Sun, Sep 19, 2010 at 4:53 PM, Shiv Kumar sku...@exposureroom.com wrote: The poster frame should remain visible until the video is played. I agree with Silvia, this should be required by the spec. The alternative is clearly wrong. Someone should also file a bug with WebKit to ask them to change. Someone might want to try a WebKit nightly build before filing a bug. This was changed in r64884. A poster is displayed until there is a movie frame to display and playback begins or the current time is changed. eric
Re: [whatwg] Html 5 video element's poster attribute
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). * Don't show the poster when the video buffers - just pause the video and give some visual indication that you're buffering. * 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. * 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. * I'm not sure how reset() would work. Would you reset the list of source too? Best, Zach -- Zachary Ozer Developer, LongTail Video w: longtailvideo.com • e: z...@longtailvideo.com • p: 212.244.0140 • f: 212.656.1335 JW Player | Bits on the Run | AdSolution On Mon, Sep 20, 2010 at 10:04 AM, Eric Carlson eric.carl...@apple.com wrote: On Sep 19, 2010, at 3:17 PM, Silvia Pfeiffer wrote: Not quite: this is an implementation decision that Webkit-based browsers made. Neither Opera nor Firefox work that way (haven't checked IE yet). I agree that this implementation of poster frames is practically useless and it really annoys me as a user. I've been considering registering a bug on Webkit. On Sep 19, 2010, at 5:50 PM, Aryeh Gregor wrote: On Sun, Sep 19, 2010 at 4:53 PM, Shiv Kumar sku...@exposureroom.com wrote: The poster frame should remain visible until the video is played. I agree with Silvia, this should be required by the spec. The alternative is clearly wrong. Someone should also file a bug with WebKit to ask them to change. Someone might want to try a WebKit nightly build before filing a bug. This was changed in r64884. A poster is displayed until there is a movie frame to display and playback begins or the current time is changed. eric
Re: [whatwg] Html 5 video element's poster attribute
Rob, 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. 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. 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. 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. Shiv http://exposureroom.com/ http://exposureroom.com From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Robert O'Callahan Sent: Monday, September 20, 2010 4:11 PM To: Silvia Pfeiffer Cc: whatwg@lists.whatwg.org; Chris Pearce Subject: Re: [whatwg] Html 5 video element's poster attribute On Mon, Sep 20, 2010 at 7:58 AM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: I think that would be the easiest way to satisfy this requirement. We don't throw away the cached data if load() reloads the same resource and the resource hasn't changed, I assume? Gecko currently does, actually. We should probably fix that. Assuming we fix that, I think calling load() to reset the resource and get back to the show poster state is a fine solution to the show poster at end of video problem. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Html 5 video element's poster attribute
On Mon, Sep 20, 2010 at 5:03 PM, Shiv Kumar sku...@exposureroom.com wrote: 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. I don't see why providing a scriptable API to hide the poster image is better than just having authors use existing APIs to clear the poster attribute. 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 are not designed to be independent. If you want them to be independent, use a real independent image placed over the video. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Html 5 video element's poster attribute
Rob, I don't see why providing a scriptable API to hide the poster image is better than just having authors use existing APIs to clear the poster attribute. What is the existing API to clear and show the poster? They are not designed to be independent. If you want them to be independent, use a real independent image placed over the video. Rob, with all due respect, you seem to have not read the earlier parts of this conversation. I may be wrong and I don’t mean to rub anyone the wrong way here. As it stands today, the poster is not usable (probably because as you state it has not been designed to be independent). Every website that has implemented their own Html 5 video player have had to hack their way to get things to work the way they’d expect. I explained this part in my first post. Basically ,what they do is assign the poster and not the source. Then when the user clicks play, they assign the source. Then each time the user skips ahead, they need to null out the poster attribute (otherwise in some browsers the poster flashes during buffering periods) and then set the currentTime to skip ahead. Now if you want to change the source of the video in mid play to a better or lower quality version of the same video then you have to go through a few more hoops (and the load() method is used at this time – but you don’t want the poster to show either). I think we have a consensus on the need to change the way the poster behaves. 1. The poster should remain visible till the video is played. 2. Once the video has been played, the poster should not show during buffering or skipping ahead or any other action. The only thing that remains then is if web developers would like control over the poster, such as to show the poster after the video has ended, then there should be a way to do that. For this we need a method to show the poster once again. Current there is no way to get the poster to show again and the load() method is not the answer, nor is resetting. A simple method that does not impact anything else will do the trick. Shiv http://exposureroom.com/ http://exposureroom.com From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Robert O'Callahan Sent: Monday, September 20, 2010 9:47 PM To: Shiv Kumar Cc: Silvia Pfeiffer; whatwg@lists.whatwg.org; Chris Pearce Subject: Re: [whatwg] Html 5 video element's poster attribute On Mon, Sep 20, 2010 at 5:03 PM, Shiv Kumar sku...@exposureroom.com wrote: 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. I don't see why providing a scriptable API to hide the poster image is better than just having authors use existing APIs to clear the poster attribute. 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 are not designed to be independent. If you want them to be independent, use a real independent image placed over the video. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Html 5 video element's poster attribute
They are not designed to be independent. If you want them to be independent, use a real independent image placed over the video. Is there a way to do this without also obscuring the controls [making them inacessible]? Monty
Re: [whatwg] Html 5 video element's poster attribute
On Mon, Sep 20, 2010 at 10:31 PM, Shiv Kumar sku...@exposureroom.comwrote: Rob, I don't see why providing a scriptable API to hide the poster image is better than just having authors use existing APIs to clear the poster attribute. What is the existing API to clear and show the poster? element.removeAttribute(poster)? As it stands today, the poster is not usable (probably because as you state it has not been designed to be independent). Every website that has implemented their own Html 5 video player have had to hack their way to get things to work the way they’d expect. I explained this part in my first post. Basically ,what they do is assign the poster and not the source. Then when the user clicks play, they assign the source. Then each time the user skips ahead, they need to null out the poster attribute (otherwise in some browsers the poster flashes during buffering periods) and then set the currentTime to skip ahead. Now if you want to change the source of the video in mid play to a better or lower quality version of the same video then you have to go through a few more hoops (and the load() method is used at this time – but you don’t want the poster to show either). I think we have a consensus on the need to change the way the poster behaves. 1. The poster should remain visible till the video is played. 2. Once the video has been played, the poster should not show during buffering or skipping ahead or any other action. I agree with all that. Firefox already does what you want there. The only thing that remains then is if web developers would like control over the poster, such as to show the poster after the video has ended, then there should be a way to do that. For this we need a method to show the poster once again. Current there is no way to get the poster to show again and the load() method is not the answer, nor is resetting. A simple method that does not impact anything else will do the trick. I am trying to understand why load() is not an adequate answer. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Html 5 video element's poster attribute
No there is not. It's an all or nothing kind of thing. There is no way to get in between (in terns of z-index) the controls and the video. Shiv http://exposureroom.com -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Monty Montgomery Sent: Monday, September 20, 2010 10:32 PM To: rob...@ocallahan.org Cc: Silvia Pfeiffer; whatwg@lists.whatwg.org; Shiv Kumar; Chris Pearce Subject: Re: [whatwg] Html 5 video element's poster attribute They are not designed to be independent. If you want them to be independent, use a real independent image placed over the video. Is there a way to do this without also obscuring the controls [making them inacessible]? Monty
Re: [whatwg] Html 5 video element's poster attribute
Rob, Do you have use-cases where calling load() after the video stream ends would not be a reasonable solution? As you can imagine, getting an Html 5 video player to work as expected is a delicate balance, especially when having to deal with nuances between browser implementations. I don’t have a specific use case per-se, but I don know that calling load() is not a solution here because one has to use load to be able to switch the video from say a medium quality version to an HD version without glitches such that the user experience is seamless (that is the new version plays exactly where the low quality version left off. Of course during this switch I wouldn’t want the poster to re-appear. I feel, to keep things clean (clean from a browser implementation stand point and from an understanding standpoint) we need a method that allows specific control over the poster. At the moment, the poster is a stepchild of the video element. But if you look at popular video websites, the poster is an extremely important aspect of the player. Albeit, a simple aspect. At ExposureRoom we provide content producers a lot of options to do with the poster and they use it. Here are some contradictory cases that may serve as use cases to justify the need to have a spate method: 1. Some websites, don’t bother showing the poster after the video ends while providing the content producer to override. 2. Some websites (and mobile devices) default to showing the poster after the video ends and allowing the content producer to override 3. Some websites show the poster whenever the video is paused. Given the above cases, having a method the specifically controls the visibility of the poster (alone) will allow all of the above cases to be implemented. Shiv http://exposureroom.com/ http://exposureroom.com
Re: [whatwg] Html 5 video element's poster attribute
On Mon, Sep 20, 2010 at 11:36 PM, Shiv Kumar sku...@exposureroom.comwrote: Here are some contradictory cases that may serve as use cases to justify the need to have a spate method: 1. Some websites, don’t bother showing the poster after the video ends while providing the content producer to override. 2. Some websites (and mobile devices) default to showing the poster after the video ends and allowing the content producer to override 3. Some websites show the poster whenever the video is paused. Given the above cases, having a method the specifically controls the visibility of the poster (alone) will allow all of the above cases to be implemented. A side question: do any of these sites want a poster that has dynamic/interactive content in it? Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Html 5 video element's poster attribute
A side question: do any of these sites want a poster that has dynamic/interactive content in it? They have video pre-roll ads but then that’s just another video. Honestly, I can’t speak for other websites (besides seeing what I see and know). At ExposureRoom we don’t have any distractions from the video. No ads in the video and one text ad to the right hand side of the page. No animated ads anywhere on any page on the site. There is more money is pre-roll video ads then there is for animations and more money in animated ads than for static image ads. So video sites may just go down the route of video ads. I know there are large businesses that cater to all your needs for pre-roll ads. Shiv http://exposureroom.com/ http://exposureroom.com From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Robert O'Callahan Sent: Monday, September 20, 2010 11:46 PM To: Shiv Kumar Cc: WHATWG Subject: Re: [whatwg] Html 5 video element's poster attribute On Mon, Sep 20, 2010 at 11:36 PM, Shiv Kumar sku...@exposureroom.com wrote: Here are some contradictory cases that may serve as use cases to justify the need to have a spate method: 1. Some websites, don’t bother showing the poster after the video ends while providing the content producer to override. 2. Some websites (and mobile devices) default to showing the poster after the video ends and allowing the content producer to override 3. Some websites show the poster whenever the video is paused. Given the above cases, having a method the specifically controls the visibility of the poster (alone) will allow all of the above cases to be implemented. A side question: do any of these sites want a poster that has dynamic/interactive content in it? Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Html 5 video element's poster attribute
Rob, YouTube does not show a poster at the end of the video by default, they show other related videos in that space. The content producer can change that but by default YouTube shows (using Flash player) other related videos and the whole thing is animated and interactive. Shiv http://exposureroom.com/ http://exposureroom.com From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Robert O'Callahan Sent: Monday, September 20, 2010 11:46 PM To: Shiv Kumar Cc: WHATWG Subject: Re: [whatwg] Html 5 video element's poster attribute On Mon, Sep 20, 2010 at 11:36 PM, Shiv Kumar sku...@exposureroom.com wrote: Here are some contradictory cases that may serve as use cases to justify the need to have a spate method: 1. Some websites, don’t bother showing the poster after the video ends while providing the content producer to override. 2. Some websites (and mobile devices) default to showing the poster after the video ends and allowing the content producer to override 3. Some websites show the poster whenever the video is paused. Given the above cases, having a method the specifically controls the visibility of the poster (alone) will allow all of the above cases to be implemented. A side question: do any of these sites want a poster that has dynamic/interactive content in it? Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Html 5 video element's poster attribute
On Tue, Sep 21, 2010 at 1:36 PM, Shiv Kumar sku...@exposureroom.com wrote: Rob, Do you have use-cases where calling load() after the video stream ends would not be a reasonable solution? As you can imagine, getting an Html 5 video player to work as expected is a delicate balance, especially when having to deal with nuances between browser implementations. I don’t have a specific use case per-se, but I don know that calling load() is not a solution here because one has to use load to be able to switch the video from say a medium quality version to an HD version without glitches such that the user experience is seamless (that is the new version plays exactly where the low quality version left off. Of course during this switch I wouldn’t want the poster to re-appear. 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). So, all we would need is to also reset the player to pause if it was paused before or it had reached the end before and also reload the poster. All you would need to do then for your player is to register a callback that calls load() when the ended event is raised. Cheers, Silvia.
Re: [whatwg] Html 5 video element's poster attribute
On 21/09/2010 2:37 p.m., Robert O'Callahan wrote: On Mon, Sep 20, 2010 at 10:31 PM, Shiv Kumar sku...@exposureroom.com mailto:sku...@exposureroom.com wrote: The only thing that remains then is if web developers would like control over the poster, such as to show the poster after the video has ended, then there should be a way to do that. For this we need a method to show the poster once again. Current there is no way to get the poster to show again and the load() method is not the answer, nor is resetting. A simple method that does not impact anything else will do the trick. I am trying to understand why load() is not an adequate answer. One caveat: if you use load() to reset the poster image, you'll trigger all the events and state changes, and reset the volume, currentTime, playbackRate and so on. On 21/09/2010 2:31 p.m., Shiv Kumar wrote: Now if you want to change the source of the video in mid play to a better or lower quality version of the same video then you have to go through a few more hoops (and the load() method is used at this time – but you don’t want the poster to show either). Wouldn't it be better to load() the new resource in a separate video element, and then swap it into the DOM when it's completed loading and seeked to your change over point? Wouldn't that be more seemless? On 21/09/2010 3:36 p.m., Shiv Kumar wrote: Here are some contradictory cases that may serve as use cases to justify the need to have a spate method: 1. Some websites, don’t bother showing the poster after the video ends while providing the content producer to override. 2. Some websites (and mobile devices) default to showing the poster after the video ends and allowing the content producer to override 3. Some websites show the poster whenever the video is paused. Given the above cases, having a method the specifically controls the visibility of the poster (alone) will allow all of the above cases to be implemented. If we wanted to go down this path, I think a settable attribute 'postervisible' would be the way to go. Setting to true would show the poster, and the browser would automatically hide the poster the next time it updates the video frame (the next time playback starts and after a seek completes). The attribute would also be readable from script. We'd probably want to dispatch a 'posterhidden' event when the poster is hidden as well, and maybe a 'postershown' event as well. But wouldn't anyone who wanted this level of control have their own custom video controls anyway, so that they could ensure they looked the same across all browsers? In which case they'd have their own custom poster image implementation anyway? Chris P.
Re: [whatwg] Html 5 video element's poster attribute
Silvia, How do you supposed the case I mentioned earlier (where when the video is paused the poster is shown) will work with load()? With all due respect, I do know how load works. Shiv http://exposureroom.com/ http://exposureroom.com
Re: [whatwg] Html 5 video element's poster attribute
On Tue, Sep 21, 2010 at 2:14 PM, Chris Pearce ch...@pearce.org.nz wrote: On 21/09/2010 2:37 p.m., Robert O'Callahan wrote: On Mon, Sep 20, 2010 at 10:31 PM, Shiv Kumar sku...@exposureroom.comwrote: The only thing that remains then is if web developers would like control over the poster, such as to show the poster after the video has ended, then there should be a way to do that. For this we need a method to show the poster once again. Current there is no way to get the poster to show again and the load() method is not the answer, nor is resetting. A simple method that does not impact anything else will do the trick. I am trying to understand why load() is not an adequate answer. One caveat: if you use load() to reset the poster image, you'll trigger all the events and state changes, and reset the volume, currentTime, playbackRate and so on. As it currently stands, load() also resets the pause state and reloads the media resource, making it a bit useless for this need. This is why I considered a reset() function, which would essentially allow you to reset the current resource to the initial playback state, i.e. including being in pause state (if the element has a pause attribute) and resetting the currentTime to 0 and showing the poster. We should probably not reset the playbackRate and the volume though, or any of the selected TimedTracks, and of course we should avoid re-downloading the resource. Cheers, Silvia.
Re: [whatwg] Html 5 video element's poster attribute
On Tue, Sep 21, 2010 at 2:14 PM, Shiv Kumar sku...@exposureroom.com wrote: Silvia, How do you supposed the case I mentioned earlier (where when the video is paused the poster is shown) will work with load()? For the pause state you will have to use the onpause event to make any changes. But to be honest, I doubt anyone would want to show the poster in pause state. I have not seen that anywhere yet and I have come across a sizeable number of video sites. Can you point to a single one that currently loads a poster image when you press pause? Regards, Silvia.
Re: [whatwg] Html 5 video element's poster attribute
For the pause state you will have to use the onpause event to make any changes. But to be honest, I doubt anyone would want to show the poster in pause state. I have not seen that anywhere yet and I have come across a sizeable number of video sites. Can you point to a single one that currently loads a poster image when you press pause? Someone here mentioned Voddler. I've seen a few, but I can't recall. Some of our content producers have requested this too but we've not provided them with this feature. Can you give me a good reason/case for not having a simple method (with no side effects) to make a poster visible/invisible? Shiv http://exposureroom.com/ http://exposureroom.com From: Silvia Pfeiffer [mailto:silviapfeiff...@gmail.com] Sent: Tuesday, September 21, 2010 12:54 AM To: Shiv Kumar Cc: WHATWG Subject: Re: [whatwg] Html 5 video element's poster attribute On Tue, Sep 21, 2010 at 2:14 PM, Shiv Kumar sku...@exposureroom.com wrote: Silvia, How do you supposed the case I mentioned earlier (where when the video is paused the poster is shown) will work with load()? For the pause state you will have to use the onpause event to make any changes. But to be honest, I doubt anyone would want to show the poster in pause state. I have not seen that anywhere yet and I have come across a sizeable number of video sites. Can you point to a single one that currently loads a poster image when you press pause? Regards, Silvia.
[whatwg] Html 5 video element's poster attribute
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. The player then shows this first frame, but 99% of the time the first frame is black. So what you see is a black box. The poster frame of a video is probably the most important not only for the viewer but also for the content producer. It's the one shot the content producer gets at enticing the viewer to watch her video. Most video websites therefore provide multiple ways in which the content producer can define a poster frame for her video. As a result of the current behavior you'll see that most html video player implementation don't set the source attribute on the video element, so as to prevent the poster from disappearing or some will overlay an image over the video element. Ideally, one should be able to simply use the video tag to get the expected behavior without having to go through hoops. The solution would be the following: The poster frame should remain visible until the video is played. The poster should not show while the player is seeking (some browser implementation do show the poster while seeking, resulting a flashes) The poster should show again after the video has ended. 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) Regards, Shiv http://exposureroom.com http://exposureroom.com/
Re: [whatwg] Html 5 video element's poster attribute
On Mon, Sep 20, 2010 at 6:53 AM, Shiv Kumar sku...@exposureroom.com 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. The player then shows this first frame, but 99% of the time the first frame is black. So what you see is a black box. Not quite: this is an implementation decision that Webkit-based browsers made. Neither Opera nor Firefox work that way (haven't checked IE yet). I agree that this implementation of poster frames is practically useless and it really annoys me as a user. I've been considering registering a bug on Webkit. However, there is a loophole in the spec that allows for this behaviour - the video element section states: When a videohttp://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#videoelement is pausedhttp://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-media-pausedand the current playback positionhttp://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#current-playback-positionis the first frame of video, the element representshttp://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#representseither the frame of video corresponding to the current playback positionhttp://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#current-playback-positionor the poster framehttp://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#poster-frame, at the discretion of the user agent. The first half of the either...or... statement is really annoying and should be removed. The poster frame of a video is probably the most important not only for the viewer but also for the content producer. It’s the one shot the content producer gets at enticing the viewer to watch her video. Most video websites therefore provide multiple ways in which the content producer can define a poster frame for her video. As a result of the current behavior you’ll see that most html video player implementation don’t set the source attribute on the video element, so as to prevent the poster from disappearing or some will overlay an image over the video element. Ideally, one should be able to simply use the video tag to get the expected behavior without having to go through hoops. The solution would be the following: The poster frame should remain visible until the video is played. The poster should not show while the player is seeking (some browser implementation do show the poster while seeking, resulting a flashes) I agree with changing the spec to require this behaviour. The poster should show again after the video has ended. I think this would be confusing and would prefer it it just stays at displaying the last played frame. That gives users the visual queue that the playback has finished. 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) Is this really necessary? What would be the use case? Either you want to poster - then you provide the attribute - or you don't want it - then you don't provide it. Also, per script you can remove the attribute and reset it, if you really need it. I don't see what an extra attribute would add? Cheers, Silvia.
Re: [whatwg] Html 5 video element's poster attribute
Ah, interesting, I just wasted most of last night trying to figure out why I couldn't get poster to do anything sane or useful in Chrome or Firefox (actually-- FF4 betas change behavior completely and the poster.. sort of... behaves as expected). Currently the poster disappears as soon as the first frame has been downloaded, which typically takes a second. The player then shows this first frame, but 99% of the time the first frame is black. So what you see is a black box. Not quite: this is an implementation decision that Webkit-based browsers made. Neither Opera nor Firefox work that way (haven't checked IE yet). Firefox 3.x practically never shows the poster. As soon as it has a frame, boom, poster is gone and I've got a big blank square. This is almost instant. I'm in the process of scripting my own controls from scratch so I can force-overlay the video element with an absolute div to show the poster until the user hits play (I have to reimplement controls, as overlaying a div hides the native controls; they don't pop and they wouldn't get events if they did, or even if I forwarded them as the native FF controls ignore synthesized events). FF4 beta shows the poster until the first frame is played (yay). Chrome is the polar opposite from FF3 and shows the poster anytime it doesn't have a frame ready right now, meaning it shows up constantly during seeking, layout changes and stutters. [But Chrome's video playback is darned near unusable anyway. Why is the first minute of every video just missing?] The poster frame of a video is probably the most important not only for the viewer but also for the content producer. It’s the one shot the content producer gets at enticing the viewer to watch her video. Most video websites therefore provide multiple ways in which the content producer can define a poster frame for her video. Now that I'm doing production to force myself to see this from the viewpoint of the content producer, I couldn't agree more. The solution would be the following: The poster frame should remain visible until the video is played. The poster should not show while the player is seeking (some browser implementation do show the poster while seeking, resulting a flashes) Yes, at a minimum Chrome does this. With my producer hat on, it makes no sense. The poster should show again after the video has ended. I think this would be confusing and would prefer it it just stays at displaying the last played frame. That gives users the visual queue that the playback has finished. 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. FTR, if there is a way to overlay without muffling the controls under an impenetrable [transparent/translucent/opaque] layer, do let me know. 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) Is this really necessary? What would be the use case? Either you want to poster - then you provide the attribute - or you don't want it - then you don't provide it. Also, per script you can remove the attribute and reset it, if you really need it. I don't see what an extra attribute would add? Yes, I think this suggestion is one bridge too far and agree with Silvia. I don't want exactly what I want with no scripting-- I want what I want without a thousand lines of scripting to undo and subtly reimplement a similar amount of C. Monty Xiph.Org
Re: [whatwg] Html 5 video element's poster attribute
On Mon, Sep 20, 2010 at 1:15 PM, Monty Montgomery xiphm...@gmail.com wrote: Firefox 3.x practically never shows the poster. Firefox 3.5 didn't have poster implemented so it definitely won't show there. Firefox 3.6 does implement poster and it works for me. If you look at the following page the bottom 3 videos have a poster set: http://tinyvid.tv You should see the poster - press play and it goes away and the video plays. This seems to work fine in FF 3.6 and 4.0 beta for me. If it doesn't work for you, please report a bug. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] Html 5 video element's poster attribute
Actually, the browser behavior is all more complicated than this the preload attribute is influencing it strongly eg, FF4 doesn't show the poster if 'preload' is not set to 'none' And I was wrong now that I recheck chrome... it too replaces poster with first frame, but the poster shows up constantly in flickers (eg, during seeking). You should see the poster - press play and it goes away and the video plays. This seems to work fine in FF 3.6 and 4.0 beta for me. If it doesn't work for you, please report a bug. You have preload set to none in these; if you set to metadata or auto, no poster :-( Monty
Re: [whatwg] Html 5 video element's poster attribute
[apologies, FF4 is working properly... tracked it down to setting 'video.currentTime=0' kicks off dropping the poster and actively preloading] ...but not losing sight of the original post, I agree with the suggestions, and am happy to find FF4 is already following them. Monty
Re: [whatwg] Html 5 video element's poster attribute
I'll try and respond to everyone that's replied... 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.). I'm glad to see that people do see the need to change (or specify in more detail) the behavior of the poster at least insofar as it disappearing before the video is played. As far as I know, every major browser (IE 9 beta, Firefox, Safari, Chrome and Opera) do this. So I wouldn't categorize this as a bug but rather that the spec needs to be specific about this case. 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. 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. 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). Shiv http://exposureroom.com -Original Message- From: simetri...@gmail.com [mailto:simetri...@gmail.com] On Behalf Of Aryeh Gregor Sent: Sunday, September 19, 2010 8:50 PM To: Shiv Kumar Cc: WHATWg Subject: Re: [whatwg] Html 5 video element's poster attribute On Sun, Sep 19, 2010 at 4:53 PM, Shiv Kumar sku...@exposureroom.com wrote: The poster frame should remain visible until the video is played. I agree with Silvia, this should be required by the spec. The alternative is clearly wrong. Someone should also file a bug with WebKit to ask them to change. If WebKit agrees to change, then I don't think that changing the spec should be controversial. The poster should not show while the player is seeking (some browser implementation do show the poster while seeking, resulting a flashes) This sounds like a browser bug. You should report it to the implementer. The poster should show again after the video has ended. I'm ambivalent about this. I could go either way. It should be standardized one way or the other, though, and currently it's standardized as not showing (everyone does that, right?), so I'm okay with keeping it there. 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) I don't see why this is necessary. You can just do video.dataset.poster = video.poster; video.removeAttribute(poster); to remove it, and video.poster = video.dataset.poster; to restore, if you like. (In browsers that implement dataset, which is apparently only WebKit so far. But you can easily store the original value someplace else, although not quite as elegantly.)
Re: [whatwg] Html 5 video element's poster attribute
Monty, All the more reason for the spec to be more explicit I think. Shiv http://exposureroom.com -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Monty Montgomery Sent: Sunday, September 19, 2010 9:58 PM To: Chris Double Cc: Silvia Pfeiffer; WHATWg; Shiv Kumar Subject: Re: [whatwg] Html 5 video element's poster attribute Actually, the browser behavior is all more complicated than this the preload attribute is influencing it strongly eg, FF4 doesn't show the poster if 'preload' is not set to 'none' And I was wrong now that I recheck chrome... it too replaces poster with first frame, but the poster shows up constantly in flickers (eg, during seeking). You should see the poster - press play and it goes away and the video plays. This seems to work fine in FF 3.6 and 4.0 beta for me. If it doesn't work for you, please report a bug. You have preload set to none in these; if you set to metadata or auto, no poster :-( Monty
Re: [whatwg] Html 5 video element's poster attribute
On Sun, Sep 19, 2010 at 10:57 PM, Shiv Kumar sku...@exposureroom.comwrote: I'm glad to see that people do see the need to change (or specify in more detail) the behavior of the poster at least insofar as it disappearing before the video is played. As far as I know, every major browser (IE 9 beta, Firefox, Safari, Chrome and Opera) do this. As Monty discovered, Firefox does not make the poster disappear until the video is played. Feel free to file bugs against any browsers that behave differently; just because the spec allows something doesn't mean it's a good idea! Tightening up the spec to require the poster to remain until the video is played does sound like a good idea. 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. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Html 5 video element's poster attribute
On 20/09/2010 12:50 p.m., Aryeh Gregor wrote: On Sun, Sep 19, 2010 at 4:53 PM, Shiv Kumarsku...@exposureroom.com wrote: The poster frame should remain visible until the video is played. I agree with Silvia, this should be required by the spec. This makes sense, we should spec this so that the poster /must/ be visible until its played, otherwise the poster attribute can't be relied upon by authors. The poster should show again after the video has ended. I'm ambivalent about this. I could go either way. Aesthetically, I feel we shouldn't show the poster once the video has finished. Authors could script this behaviour if they wanted it. The spec as it's written forbids showing the poster after a video frame has been shown. 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) I don't see why this is necessary. I also don't see why this is necessary. The poster attribute is only useful if it's enabled, it's not useful if it isn't. Having an attribute to denote whether the poster attribute is enabled seems like duplication of state to me. You can just do video.dataset.poster = video.poster; video.removeAttribute(poster); to remove it, and video.poster = video.dataset.poster; to restore, if you like. (In browsers that implement dataset, which is apparently only WebKit so far. But you can easily store the original value someplace else, although not quite as elegantly.) The specification for poster [1] implies that we should handle dynamic changes to the poster attribute. I can imagine authors may want to cycle through a chain of poster images for a given video, and this can (theoretically) be easily implemented by changing the poster attribute in a timer. Chris P. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#attr-video-poster
Re: [whatwg] Html 5 video element's poster attribute
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? I hope that makes sense? Shiv http://exposureroom.com/ http://exposureroom.com From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Chris Pearce Sent: Sunday, September 19, 2010 11:10 PM To: whatwg@lists.whatwg.org Subject: Re: [whatwg] Html 5 video element's poster attribute On 20/09/2010 12:50 p.m., Aryeh Gregor wrote: On Sun, Sep 19, 2010 at 4:53 PM, Shiv Kumar mailto:sku...@exposureroom.com sku...@exposureroom.com wrote: The poster frame should remain visible until the video is played. I agree with Silvia, this should be required by the spec. This makes sense, we should spec this so that the poster must be visible until its played, otherwise the poster attribute can't be relied upon by authors. The poster should show again after the video has ended. I'm ambivalent about this. I could go either way. Aesthetically, I feel we shouldn't show the poster once the video has finished. Authors could script this behaviour if they wanted it. The spec as it's written forbids showing the poster after a video frame has been shown. 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) I don't see why this is necessary. I also don't see why this is necessary. The poster attribute is only useful if it's enabled, it's not useful if it isn't. Having an attribute to denote whether the poster attribute is enabled seems like duplication of state to me. You can just do video.dataset.poster = video.poster; video.removeAttribute(poster); to remove it, and video.poster = video.dataset.poster; to restore, if you like. (In browsers that implement dataset, which is apparently only WebKit so far. But you can easily store the original value someplace else, although not quite as elegantly.) The specification for poster [1] implies that we should handle dynamic changes to the poster attribute. I can imagine authors may want to cycle through a chain of poster images for a given video, and this can (theoretically) be easily implemented by changing the poster attribute in a timer. Chris P. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#attr-video-poster
Re: [whatwg] Html 5 video element's poster attribute
Could a call to video.load() reset this state? Silvia. On Mon, Sep 20, 2010 at 1:16 PM, Shiv Kumar sku...@exposureroom.com 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? I hope that makes sense? Shiv http://exposureroom.com *From:* whatwg-boun...@lists.whatwg.org [mailto: whatwg-boun...@lists.whatwg.org] *On Behalf Of *Chris Pearce *Sent:* Sunday, September 19, 2010 11:10 PM *To:* whatwg@lists.whatwg.org *Subject:* Re: [whatwg] Html 5 video element's poster attribute On 20/09/2010 12:50 p.m., Aryeh Gregor wrote: On Sun, Sep 19, 2010 at 4:53 PM, Shiv Kumar sku...@exposureroom.com sku...@exposureroom.com wrote: The poster frame should remain visible until the video is played. I agree with Silvia, this should be required by the spec. This makes sense, we should spec this so that the poster *must* be visible until its played, otherwise the poster attribute can't be relied upon by authors. The poster should show again after the video has ended. I'm ambivalent about this. I could go either way. Aesthetically, I feel we shouldn't show the poster once the video has finished. Authors could script this behaviour if they wanted it. The spec as it's written forbids showing the poster after a video frame has been shown. 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) I don't see why this is necessary. I also don't see why this is necessary. The poster attribute is only useful if it's enabled, it's not useful if it isn't. Having an attribute to denote whether the poster attribute is enabled seems like duplication of state to me. You can just do video.dataset.poster = video.poster; video.removeAttribute(poster); to remove it, and video.poster = video.dataset.poster; to restore, if you like. (In browsers that implement dataset, which is apparently only WebKit so far. But you can easily store the original value someplace else, although not quite as elegantly.) The specification for poster [1] implies that we should handle dynamic changes to the poster attribute. I can imagine authors may want to cycle through a chain of poster images for a given video, and this can (theoretically) be easily implemented by changing the poster attribute in a timer. Chris P. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#attr-video-poster
Re: [whatwg] Html 5 video element's poster attribute
Right, so you want to be able to toggle the poster back on (when the media is paused or ended) but after playback has started. I wonder if these are separate use cases, e.g. whether users would want to display a different image from the poster image in these cases. i.e. I wonder if we need to provide an attribute to specify an image to display when paused and another new attribute for an image to display when playback has ended. I wonder if that's overkill through. Chris P. On 20/09/2010 3:16 p.m., 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? I hope that makes sense? Shiv http://exposureroom.com http://exposureroom.com/ *From:* whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] *On Behalf Of *Chris Pearce *Sent:* Sunday, September 19, 2010 11:10 PM *To:* whatwg@lists.whatwg.org *Subject:* Re: [whatwg] Html 5 video element's poster attribute On 20/09/2010 12:50 p.m., Aryeh Gregor wrote: On Sun, Sep 19, 2010 at 4:53 PM, Shiv Kumarsku...@exposureroom.com mailto:sku...@exposureroom.com wrote: The poster frame should remain visible until the video is played. I agree with Silvia, this should be required by the spec. This makes sense, we should spec this so that the poster /must/ be visible until its played, otherwise the poster attribute can't be relied upon by authors. The poster should show again after the video has ended. I'm ambivalent about this. I could go either way. Aesthetically, I feel we shouldn't show the poster once the video has finished. Authors could script this behaviour if they wanted it. The spec as it's written forbids showing the poster after a video frame has been shown. 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) I don't see why this is necessary. I also don't see why this is necessary. The poster attribute is only useful if it's enabled, it's not useful if it isn't. Having an attribute to denote whether the poster attribute is enabled seems like duplication of state to me. You can just do video.dataset.poster = video.poster; video.removeAttribute(poster); to remove it, and video.poster = video.dataset.poster; to restore, if you like. (In browsers that implement dataset, which is apparently only WebKit so far. But you can easily store the original value someplace else, although not quite as elegantly.) The specification for poster [1] implies that we should handle dynamic changes to the poster attribute. I can imagine authors may want to cycle through a chain of poster images for a given video, and this can (theoretically) be easily implemented by changing the poster attribute in a timer. Chris P. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#attr-video-poster
Re: [whatwg] Html 5 video element's poster attribute
I wonder if these are separate use cases, e.g. whether users would want to display a different image from the poster image in these cases. i.e. I wonder if we need to provide an attribute to specify an image to display when paused and another new attribute for an image to display when playback has ended. I wonder if that's overkill through. Oh gosh no! J Shiv http://exposureroom.com/ http://exposureroom.com From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Chris Pearce Sent: Sunday, September 19, 2010 11:27 PM To: whatwg@lists.whatwg.org Subject: Re: [whatwg] Html 5 video element's poster attribute Right, so you want to be able to toggle the poster back on (when the media is paused or ended) but after playback has started. I wonder if these are separate use cases, e.g. whether users would want to display a different image from the poster image in these cases. i.e. I wonder if we need to provide an attribute to specify an image to display when paused and another new attribute for an image to display when playback has ended. I wonder if that's overkill through. Chris P. On 20/09/2010 3:16 p.m., 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? I hope that makes sense? Shiv http://exposureroom.com http://exposureroom.com/ From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Chris Pearce Sent: Sunday, September 19, 2010 11:10 PM To: whatwg@lists.whatwg.org Subject: Re: [whatwg] Html 5 video element's poster attribute On 20/09/2010 12:50 p.m., Aryeh Gregor wrote: On Sun, Sep 19, 2010 at 4:53 PM, Shiv Kumar mailto:sku...@exposureroom.com sku...@exposureroom.com wrote: The poster frame should remain visible until the video is played. I agree with Silvia, this should be required by the spec. This makes sense, we should spec this so that the poster must be visible until its played, otherwise the poster attribute can't be relied upon by authors. The poster should show again after the video has ended. I'm ambivalent about this. I could go either way. Aesthetically, I feel we shouldn't show the poster once the video has finished. Authors could script this behaviour if they wanted it. The spec as it's written forbids showing the poster after a video frame has been shown. 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) I don't see why this is necessary. I also don't see why this is necessary. The poster attribute is only useful if it's enabled, it's not useful if it isn't. Having an attribute to denote whether the poster attribute is enabled seems like duplication of state to me. You can just do video.dataset.poster = video.poster; video.removeAttribute(poster); to remove it, and video.poster = video.dataset.poster; to restore, if you like. (In browsers that implement dataset, which is apparently only WebKit so far. But you can easily store the original value someplace else, although not quite as elegantly.) The specification for poster [1] implies that we should handle dynamic changes to the poster attribute. I can imagine authors may want to cycle through a chain of poster images for a given video, and this can (theoretically) be easily implemented by changing the poster attribute in a timer. Chris P. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#attr-video-poster
Re: [whatwg] Html 5 video element's poster attribute
Could a call to video.load() reset this state? 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? 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. Shiv http://exposureroom.com/ http://exposureroom.com From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Silvia Pfeiffer Sent: Sunday, September 19, 2010 11:19 PM To: Shiv Kumar Cc: whatwg@lists.whatwg.org; Chris Pearce Subject: Re: [whatwg] Html 5 video element's poster attribute Could a call to video.load() reset this state? Silvia. On Mon, Sep 20, 2010 at 1:16 PM, Shiv Kumar sku...@exposureroom.com 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? I hope that makes sense? Shiv http://exposureroom.com http://exposureroom.com/ From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Chris Pearce Sent: Sunday, September 19, 2010 11:10 PM To: whatwg@lists.whatwg.org Subject: Re: [whatwg] Html 5 video element's poster attribute On 20/09/2010 12:50 p.m., Aryeh Gregor wrote: On Sun, Sep 19, 2010 at 4:53 PM, Shiv Kumar mailto:sku...@exposureroom.com sku...@exposureroom.com wrote: The poster frame should remain visible until the video is played. I agree with Silvia, this should be required by the spec. This makes sense, we should spec this so that the poster must be visible until its played, otherwise the poster attribute can't be relied upon by authors. The poster should show again after the video has ended. I'm ambivalent about this. I could go either way. Aesthetically, I feel we shouldn't show the poster once the video has finished. Authors could script this behaviour if they wanted it. The spec as it's written forbids showing the poster after a video frame has been shown. 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) I don't see why this is necessary. I also don't see why this is necessary. The poster attribute is only useful if it's enabled, it's not useful if it isn't. Having an attribute to denote whether the poster attribute is enabled seems like duplication of state to me. You can just do video.dataset.poster = video.poster; video.removeAttribute(poster); to remove it, and video.poster = video.dataset.poster; to restore, if you like. (In browsers that implement dataset, which is apparently only WebKit so far. But you can easily store the original value someplace else, although not quite as elegantly.) The specification for poster [1] implies that we should handle dynamic changes to the poster attribute. I can imagine authors may want to cycle through a chain of poster images for a given video, and this can (theoretically) be easily implemented by changing the poster attribute in a timer. Chris P. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#attr- video-poster
