[whatwg] Html 5 video element's poster attribute

[Shiv Kumar]

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:zach at 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 <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