[Bug 15140] The video element's poster attribute requires clarification in relation to precedence

https://www.w3.org/Bugs/Public/show_bug.cgi?id=15140

--- Comment #6 from Philip J <philipj@opera.com> 2011-12-14 09:42:57 UTC ---
(In reply to comment #5)
> > "The intrinsic width of a video element's playback area is the intrinsic width
> > of the video resource, if that is available; otherwise it is the intrinsic
> > width of the poster frame, if that is available; otherwise it is 300 CSS
> > pixels."
> > 
> > This isn't accurate, the intrinsic size should be the size of the poster if the
> > poster is showing and the size of the video otherwise. The above definition
> > would cause a video with a poster showing to take the size of the video as soon
> > as the video as reach HAVE_CURRENT_DATA. Both Opera and Firefox use the size of
> > the poster until the video is shown.
> 
> In the interest of not suddenly changing size when you hit the play button, it
> would be nicer to have the poster rescaled to fit within the video's size
> (pillarboxed or letterboxed as necessary) when the video's size is available.
> In both cases you will, however, have to deal with a size jump: one at the time
> when the video reaches HAVE_CURRENT_DATA and the other when the user initiates
> play.

Well, I disagree and was quite deliberate when implementing it the way I did in
Opera. It just seems to make good sense to use the intrinsic size of the frame
that is actually shown, regardless of where it comes from -- a video that
changes resolution mid-stream would also change the intrinsic size. Also, using
the poster's size means that we have consistency with the preload=none case
where the video size is not known.

> The safest approach for different video and poster sizes is explicit CSS
> settings, so it's not a big problem. But it would indeed be nice if all
> browsers showed the same behaviour.

With this I don't disagree!

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 14 December 2011 09:43:19 UTC