[whatwg] Html 5 video element's poster attribute

[Shiv Kumar]

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