12465 2011-04-09 22:18:56 +0000 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 2011-08-15 04:16:56 +0000 1 1 1 Unclassified HTML WG LC1 HTML5 spec unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#video P3 normal --- 1 contributor ian ayg ian mike philipj public-html-admin public-html-wg-issue-tracking silviapfeiffer1 steve public-html-bugzilla oldest_to_newest 47309 0 contributor 2011-04-09 22:18:56 +0000 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 47310 1 steve 2011-04-09 22:23:54 +0000 This is my comment. (steve at videojs) 47315 2 philipj 2011-04-10 19:35:08 +0000 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 :) 51068 3 ian 2011-07-14 23:27:18 +0000 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? 51135 4 ayg 2011-07-15 19:18:00 +0000 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." 51197 5 philipj 2011-07-18 09:38:02 +0000 (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... 53762 6 mike 2011-08-04 05:17:04 +0000 mass-move component to LC1 55020 7 ian 2011-08-15 04:15:58 +0000 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. 55021 8 contributor 2011-08-15 04:16:56 +0000 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