Re: Change Proposal for ISSUE-147

On Fri, 18 Mar 2011, Philip Jägenstedt wrote:
> > 
> > What might make sense is to do something like what Silvia proposed, 
> > but instead of changing the existing API, just adding an API that 
> > returns current playback metrics. That is, have playbackRate and 
> > defaultPlaybackRate work as specced now, but add a .metrics object 
> > that includes amongst other things an .actualPlaybackRate attribute 
> > that gives the actual result. It would make a lot of sense to have 
> > this if we add to it the other metrics that browsers are exposing in 
> > vendor extensions.
> 
> In principle, this seems OK, if a bit unnecessary. We already have the 
> raw snapshot metric for determining playback speed: currentTime. Would 
> actualPlaybackRate be the derivate of that over a defined period of 
> time?

currentTime is somewhat limited in accuracy for this since it's affected 
by pausing, media stalls, stopping for user interaction, etc.


> Anyway, it's not at all clear to me what scripts would actually do with 
> this information. Tell the users that their browsers sucks?

That's a good point. What's the use case for this? Is it better for 
interoperability to just have the browsers approximate the playback speed 
as best as possible (which might not be good at all in some cases), and 
return the same value for playbackRate as any other browser? I could see 
an argument that actually setting playbackRate only when it is a supported 
rate (notwithstanding that you might not know what a supported rate is in 
the first place when it's set) would lead to pages breaking in different 
UAs due to pages relying on the specific characteristics of browsers to 
which they were written.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'