W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > February 2012

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

From: <bugzilla@jessica.w3.org>
Date: Mon, 06 Feb 2012 11:40:13 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1RuMvd-0006P2-3y@jessica.w3.org>

--- Comment #11 from Philip J <philipj@opera.com> 2012-02-06 11:40:11 UTC ---
(In reply to comment #10)
> (In reply to comment #4)

> > 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.
> I disagree. The video playback area should be the size of the video, not the
> poster, so that it doesn't change size when you start playing.
> > Both Opera and Firefox use the size of the poster until the video is shown.
> IMHO those are bugs.

AFAICT there are 2 options, implementation-wise:

A. Use the size of the frame that is being displayed regardless of origin, or

B. Use the (current/initial/maximum/?) size of the video if it is known, the
size of the poster image if it is known, or 300x150.

For page authors, I can think of 4 behaviors one might want:

1. Small thumbnail (probably with preload="none") that expands to video size on

2. A variable size player matching the video size and scaling the poster if

3. A fixed size player when you don't know the size of the videos or poster
images at all.

4. Irrelevant, because the poster (if it exists) and video size match anyway.

With implementation A, behavior 1 is the default and 2 requires setting the
size with CSS (on the server or in the loadeddata event).

With implementation B, behavior 1 requires setting the poster size with CSS (on
the server or client by using an <img> element to get the size of the poster)
and then removing the style in the loadeddata event. Behavior 2 almost works as
the default, except that preload break everything -- with preload="none" you'll
get something closer to behavior 1, but exactly when the video size becomes
known in each preload state is deliberately vague in the spec and could differ
between implementations. In other words, to make it robust work you have to set
the size of the video in CSS in the same way as for implementation A.

Behaviors 3 and 4 are the same in either implementation, and I would be
surprised if they together are not the most common cases.

Hopefully this makes it more clear why I picked the behavior I did, and why I
think using the video size (when known) is not a good option.

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 Monday, 6 February 2012 11:41:09 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:26 UTC