[whatwg] Interpretation of video poster attribute

On Thu, 2008-06-12 at 07:15 +0000, Ian Hickson wrote:
> So, to summarise, an <img> represents its src="", and a <video> represents 
> its poster="". So use the same mechanism (stretching the image to fit the 
> box dimensions) for both.

Fair enough.

> 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.

> 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. That the element may be resized twice is not a problem, at
least not implementation-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. 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".

> Should aspect ratio correction be done for poster images? What if 
> different videos have different aspect ratios? It would be bad for
> the 
> poster frame to be rendered at different ratios as the UA tries each
> video 
> in turn.

Good point, assuming 1:1 pixel ratio for poster images makes more sense,
even if it means tools for automatically generating poster images will
have to perform aspect ratio correction.

> > 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.

> 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.

-- 
Philip J?genstedt
Opera Software

Received on Thursday, 12 June 2008 00:58:14 UTC