[whatwg] Interpretation of video poster attribute

[Ian Hickson]

On Thu, 12 Jun 2008, Philip Jägenstedt wrote:
> >
> > This isn't currently defined (even without a poster, as far as I can 
> > tell), but my intention would be to not make the poster affect the 
> > intrinsic dimensions, and for the default, in the absence of video 
> > data, is 300x150.

This is defined now by the way.


> > The problem with scaling to the poster's size is that it would make 
> > the veo resize twice e (300x150 -> poster -> video) instead of just 
> > once (300x150 blank, then poster -> video).
> 
> If poster is to <video> what src is to <img>, then surely the video 
> element should take the size of the poster image if no width/height is 
> given? This is certainly my preference, as width/height would otherwise 
> effectively be mandatory when poster is used, which would in turn 
> require the poster to be of the same size as the video unless one is to 
> be scaled.

Why? The posted would be displayed in the default 300x150 box.


> That the element may be resized twice is not a problem, at 
> least not implementation-wise.

That it's resized at all is a terrible problem; that it woul resize twice 
would be a disaster, UI-wise.


> As some container formats allow changing the video frame size mid-stream 
> (notably chained Ogg streams, so called sequential multiplexing) the UA 
> could possibly resize the video element an unlimited number of times, so 
> handling that is necessary anyway.

That's not the common case, though; a poster is.


> On that note, perhaps an event to notify JavaScript UIs of such changes 
> would be useful/necessary. Perhaps reusing "resize" event would be the 
> best, other names could be "videochange" or "sizechange".

I've noted this for a v3 feature.


> > > HTTP 4xx and 5xx errors (and equivalents in other protocols) must 
> > > (may?) cause the user agent to ignore the poster attribute.
> > 
> > Well what else are they going to do? HTTP already requires this as far 
> > as I can tell.
> 
> It appears that Safari shows a little X symbol instead, but perhaps 
> specifying this behavior is not necessary. We will likely ignore the 
> poster attribute entirely instead.

Showing a red X seems contrary to the spec (which says that the <video> 
element represents the poster, the video, or nothing), but really 
rendering things are out of scope of the spec. In any case, in a few years 
we'll probably look at what implementations do and specify what the 
implementations have converged on.


> > I'm not sure a fake button (which wouldn't actually work anyway) is a 
> > natural interpretation of "poster frame". :-)
> 
> As long as it's mentioned somewhere there can be no misunderstanding.

Ok, added a note.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'