- From: Andy Lyttle <whatwg@phroggy.com>
- Date: Tue, 14 Oct 2008 14:17:03 -0700
<aol>Me too.</aol> As I understand it, the intention was that because some players can't support it, all players should be forbidden to do it because web developers might somehow come to rely on it not working. I'm having trouble imagining how that could be a significant problem, and mandating that behavior in the spec seems very weird. A note in the spec explaining that you should mute it if you really want it to not play sounds like a much better way to go. Is there any situation where muting it like that won't elegantly solve this problem? -- Andy Lyttle whatwg at phroggy.com On Oct 14, 2008, at 11:28 AM, Peter Kasting wrote: > On Tue, Oct 14, 2008 at 8:00 AM, Eric Carlson > <eric.carlson at apple.com> wrote: > Some media formats and/or engines may not support reverse > playback, but I think it is a mistake for the spec to mandate this > behavior. Why is reverse playback different from other situations > described in the spec where different UAs/ media formats will > result in different behavior, eg. pitch adjusted audio, negotiation > with a server to achieve the appropriate playback rate, etc? > > I think the current sentence that talks about audio playback rate: > > When the playbackRate is so low or so high that the user agent > cannot play audio usefully, the corresponding audio must not play. > > could be modified to include reverse playback as well: > > When the playbackRate is such that the user agent cannot play > audio usefully (eg. too low, too high, negative when the format or > engine does not support reverse playback), the corresponding audio > must not play. > > Agree wholeheartedly. > > Mandating silence during reverse playback seems bizarre in the > abstract, unnecessary if authors have a way to mute, and > potentially detrimental to future applications which may _want_ to > be able to do this in a controlled fashion (e.g. a virtual > turntable application). > > PK
Received on Tuesday, 14 October 2008 14:17:03 UTC