This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Problem: what is a browser expected to display in @controls when a <video> or <audio> element loads a media resource with a media fragment Proposal: The browser will play the resource from the fragment start time to the fragment end time and pauses at the end time. It further displays the time segment on the timeline of the @controls in a suitable manner as part of the full video's timeline. If the user hits "play" at the end of the fragment playback, playback will continue past the end of the playback until it reaches the end of the resource or another user interaction occurs. The change should be made to http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#user-interface where it should be added to recommendations of what browsers should expose when a @controls attribute is present. Note: Browsers should do the same thing when users navigate directly to a audio or video resource that includes a temporal media fragment specification. Even though this is a browser issue and therefore out of scope of this bug, it is still important to understand that this is a consistency issue and should be handled by user agents the same way everywhere.
What should happen if the user seeks outside the fragment, then seeks back and plays normally until the fragment end time? Does the video pause? There are three options that I can see: 1. always pause at the fragment end time during normal playback 2. never pause at the fragment end time 3. pause depending on whether the user has seeked outside the fragment range or not. Option 3 is a bit risky, because a user trying to seek close to the beginning or end of a range will easily miss and end up outside of the range, irrevocably changing the behavior of the video. I think such a UI might be a bit too magical. I don't (yet) have a strong opinion between option 1 and 2.
(In reply to comment #1) > What should happen if the user seeks outside the fragment, then seeks back and > plays normally until the fragment end time? Does the video pause? > > There are three options that I can see: > > 1. always pause at the fragment end time during normal playback > 2. never pause at the fragment end time > 3. pause depending on whether the user has seeked outside the fragment range or > not. > > Option 3 is a bit risky, because a user trying to seek close to the beginning > or end of a range will easily miss and end up outside of the range, irrevocably > changing the behavior of the video. I think such a UI might be a bit too > magical. > > I don't (yet) have a strong opinion between option 1 and 2. I have a fourth option: remove the fragment restriction as soon as the user interacts with the resource's timeline, i.e. pauses, seeks. If the user doesn't interact, then pause at the fragment end time.
(In reply to comment #2) > I have a fourth option: remove the fragment restriction as soon as the user > interacts with the resource's timeline, i.e. pauses, seeks. If the user doesn't > interact, then pause at the fragment end time. That would work, but I see it as a workaround rather than a solution that would actually be good for users. Wouldn't it be confusing to have the UI mark the start and end of a range on the seek bar, but then ignore the range depending on if one has played/paused/seeked or not? Removing the range from the UI as well wouldn't be much better, someone trying to seek to close to the beginning of the range would just end up with the range disappearing.
Any UI expectations for media fragments that apply to <video>/<audio> should also apply to viewing the media file in its own tab, or indeed retrieving a media file from a URL using a non-browser UA -- right? Why is the HTML spec the right place to put this sort of thing? I just opened the default movie player on Ubuntu and immediately found an "Open Location..." option that would let me view media from a URL. The authors of that application presumably would have no reason to care about HTML or <video>, only about the semantics of media fragments. Why should they have to look in the HTML spec to find out how they're expected to display URLs with media fragments? This should be in the media fragment spec.
(In reply to comment #4) > Any UI expectations for media fragments that apply to <video>/<audio> should > also apply to viewing the media file in its own tab, or indeed retrieving a > media file from a URL using a non-browser UA -- right? Why is the HTML spec > the right place to put this sort of thing? > > I just opened the default movie player on Ubuntu and immediately found an "Open > Location..." option that would let me view media from a URL. The authors of > that application presumably would have no reason to care about HTML or <video>, > only about the semantics of media fragments. Why should they have to look in > the HTML spec to find out how they're expected to display URLs with media > fragments? This should be in the media fragment spec. There are recommendations specified in the media fragment spec and that's all that such a spec can do, since players may have different approaches to dealing with the fragments. We do want browsers to be compatible with each other, though. So we need to add the specific means in which fragments are exposed when a @controls attribute is given for audio or video. A browser isn't a random stand-alone media player, but exhibits a behaviour that needs to be compatible across browsers.
(In reply to comment #4) > Any UI expectations for media fragments that apply to <video>/<audio> should > also apply to viewing the media file in its own tab, or indeed retrieving a > media file from a URL using a non-browser UA -- right? Why is the HTML spec > the right place to put this sort of thing? > > I just opened the default movie player on Ubuntu and immediately found an "Open > Location..." option that would let me view media from a URL. The authors of > that application presumably would have no reason to care about HTML or <video>, > only about the semantics of media fragments. Why should they have to look in > the HTML spec to find out how they're expected to display URLs with media > fragments? This should be in the media fragment spec. Aryeh, your use case is dealt with at http://www.w3.org/TR/media-frags/#media-fragment-display (in the Media Fragment spec). Don't you have the answer of your question there?
(In reply to comment #5) > We do want browsers to be compatible with each other, though. So we need to add > the specific means in which fragments are exposed when a @controls attribute is > given for audio or video. A browser isn't a random stand-alone media player, > but exhibits a behaviour that needs to be compatible across browsers. Why isn't there a need for compatibility between browsers and (at least some) non-browsers? Clearly some implementations might have entirely different needs, but that's why there's such a thing as a "SHOULD" requirement <http://tools.ietf.org/html/rfc2119>. Alternatively, the media fragment spec could explain how it's expected to work in browsers and browser-like implementations, without requiring that behavior of other implementations. HTML5 does this in its Rendering section. In particular, I'd expect the same URL to be interpreted in essentially the same way if I open it in a dedicated movie player (that supports opening URLs) and if I open it in a browser tab. If the browser starts at the fragment start time and the movie player doesn't, for instance, I'd regard the movie player as broken. (In reply to comment #6) > Aryeh, your use case is dealt with at > http://www.w3.org/TR/media-frags/#media-fragment-display (in the Media Fragment > spec). Don't you have the answer of your question there? What HTML-specific requirements are needed in addition to those requirements?
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. The UI is entirely up to the UAs. So long as it is done in terms of the API, they could have their UI be completely incomprehensible and it would still be conforming.
The Media Fragments WG agrees with this rationale, see http://www.w3.org/2011/06/22-mediafrag-minutes.html
mass-move component to LC1