This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html Multipage: http://www.whatwg.org/C#playing-the-media-resource Complete: http://www.whatwg.org/c#playing-the-media-resource Comment: <video> make loop work with reverse playback Posted from: 83.218.67.122 by philipj@opera.com User agent: Opera/9.80 (X11; Linux x86_64; U; Edition Next; en) Presto/2.9.186 Version/12.00
If one has a background music loop and can change the playback rate, it seems arbitrary to make it not work with playbackRate < 0. It doesn't seem like looping would be any harder to achieve in this situation, so the reason for the restriction is not clear.
What's the use case? No audio plays with negative playback rates anyway. The use case for looping is to have background music. The use case for playback rate is to have fast-forward and rewind buttons. The use case for default playback rate is to watch lectures in compressed time. I don't really see why you would need to go backwards and loop. There's lots of logic that only happens forwards and not backwards currently for similar reasons.
Why wouldn't one play audio in reverse playback? If one has looping background music in a game and have an effect where time starts slowing down and then goes backwards, one would want the music to keep playing, backwards and looping.
Audio is explicitly muted when going backwards and in certain other cases, based on implementation feedback (primarily from Microsoft, IIRC? I forget).
Huh, I didn't know that, and don't remember seeing that feedback. Until we actually implement it I won't pretend to know all the intricacies, but this seems to be a QoI issue.
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: Until or unless that changes, looping backwards doesn't seem to have a use case, so I'm marking this WONTFIX for now. The relevant clause was added in 2008-10-15 in r2330, in response to Mozilla and Apple feedback, not Microsoft feedback. Apologies for the earlier misattribution. See these e-mails: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-October/016573.html http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-October/016615.html See also bug 8390.