This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 12465 - Can it be added that the poster image (if defined) should continue to show until video is played for the first time? Safari currently shows the first frame of the video as soon as it's available (when preloading) while other browsers continue to show the
Summary: Can it be added that the poster image (if defined) should continue to show un...
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-04-09 22:18 UTC by contributor
Modified: 2011-08-15 04:16 UTC (History)
8 users (show)

See Also:


Attachments

Description contributor 2011-04-09 22:18:56 UTC
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#poster-frame
Section: http://www.whatwg.org/specs/web-apps/current-work/#video

Comment:
Can it be added that the poster image (if defined) should continue to show
until video is played for the first time? Safari currently shows the first
frame of the video as soon as it's available (when preloading) while other
browsers continue to show the poster image. The latter would seem to be the
correct behavior, because if I deliberately set a poster image, I want that
image to show for as long as the video has not been played yet. If I
deliberately burn a poster frame into the first frame of the video itself, I
just won't set the poster image.

Posted from: 68.101.124.197
User agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_6; en-us) AppleWebKit/533.19.4 (KHTML, like Gecko) Version/5.0.3 Safari/533.19.4
Comment 1 Steve Heffernan 2011-04-09 22:23:54 UTC
This is my comment. (steve at videojs)
Comment 2 Philip J├Ągenstedt 2011-04-10 19:35:08 UTC
I'd like to see this standardized too. In Opera, the poster is shown if and only if (poster_attr && !poster_failed && !(played_or_seeked && frame_decoded), where the states mean:

poster_attr: poster attribute is set
poster_failed: decoding the poster as an image failed
played_or_seeked: a play or seek has been requested
frame_decoded: a frame has been decoded (any frame)

(Obviously, it's also necessary to have decoded the poster image, but whenever the conditions are above are met we're "trying" to show the poster image, so it either eventually shows or the state switches to poster_failed.

All state is reset at the beginning of the resource selection algorithm.

In addition, whever the poster image is showing, the intrinsic size of the element is the size of the poster. In other words, the element is never resized to the size of the video while the poster image is still showing.

Needless to say, I'd be happy to standardize exactly what we already do :)
Comment 3 Ian 'Hixie' Hickson 2011-07-14 23:27:18 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: 

This is a UI issue, no? Surely it should be left up to the browsers. What's the difference between the user quickly starting and pausing the video and the browser doing it automatically?
Comment 4 Aryeh Gregor 2011-07-15 19:18:00 UTC
If the poster frame is displayed in some browsers but not others once the video starts loading, they'll be forced to hack around it by superimposing an <img> or burning a poster into the first frame of the video.  This defeats the entire point of the feature.  If something is visually part of the page contents, authors absolutely need to be able to control it reliably.  Authors are not going to accept "the poster frame I've carefully selected displays in some browsers until the user hits play, and in others it disappears almost immediately and is replaced by the first frame".

This isn't UI at all.  UI differences are where the same basic thing is displayed to the user, but in a UA-specific manner.  Here we're talking about two totally different things being displayed to the user: the poster and the first frame.  There's no reason not to demand interop here.

I don't get your last sentence at all.  We're talking about a case where no one has started playing the video at all.  What does starting and immediately stopping it have to do with anything?  Once the video has started playing, the poster shouldn't display anymore, as the spec says: "the poster frame should not be shown again after a frame of video has been shown."
Comment 5 Philip J├Ągenstedt 2011-07-18 09:38:02 UTC
(In reply to comment #3)

> This is a UI issue, no? Surely it should be left up to the browsers. What's the
> difference between the user quickly starting and pausing the video and the
> browser doing it automatically?

Why would a browser ever play and pause automatically? That would fire spurious events...
Comment 6 Michael[tm] Smith 2011-08-04 05:17:04 UTC
mass-move component to LC1
Comment 7 Ian 'Hixie' Hickson 2011-08-15 04:15:58 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: see diff given below
Rationale: Fair enough.
Comment 8 contributor 2011-08-15 04:16:56 UTC
Checked in as WHATWG revision r6454.
Check-in comment: Be less flexible about what UAs are allowed to do with <video>.
http://html5.org/tools/web-apps-tracker?from=6453&to=6454