[whatwg] Html 5 video element's poster attribute

[Zachary Ozer]

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: zach at 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 <skumar at 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-bounces at lists.whatwg.org [mailto:whatwg-bounces at 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 <skumar at 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 <skumar at 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: zach at longtailvideo.com • p: 212.244.0140 •
> f: 212.656.1335
> JW Player  |  Bits on the Run  |  AdSolution
>
>