W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2009

[whatwg] <video>/<audio> feedback

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 14 May 2009 11:53:37 -0700
Message-ID: <63df84f0905141153r1d1942cauc555fa19562acc4@mail.gmail.com>
On Tue, May 12, 2009 at 9:29 PM, David Singer <singer at apple.com> wrote:
> At 12:09 ?+1000 13/05/09, Silvia Pfeiffer wrote:
>> On Wed, May 13, 2009 at 5:01 AM, Jonas Sicking <jonas at sicking.cc> wrote:
>>> ?On Sun, May 10, 2009 at 6:56 PM, David Singer <singer at apple.com> wrote:
>>>> ?At 14:09 ?+1000 9/05/09, Silvia Pfeiffer wrote:
>>>>> ?Of course none of the
>>>>> ?discussion will inherently disallow seeking - scripts will always be
>>>>> ?able to do the seeking. But the user may not find it easy to do
>>>>> ?seeking to a section that is not accessible through the displayed
>>>>> ?timeline, which can be both a good and a bad thing.
>>>> ?How easy a particular user interface is to use for various tasks is (I
>>>> hope)
>>>> ?not our worry...
>>> ?I'm not sure I agree. If the spec provides a feature set that no one
>>> ?is able to create a useful UI for, then there definitely might be a
>>> ?problem with the spec.
>>> ?I still have not received any comments on my previous assertion that
>>> ?there are essentially two separate use cases here. One for bringing
>>> ?attention to a specific point in a larger context, one for showing
>>> ?only a smaller range of a video.
>> Just to confirm: yes, there are two separate use cases. (I was under
>> the impression that the discussion had brought that out).
> Yes, that's fine. ?I think it's clear that we could have a 'verb' in the
> fragment "focus-on", "select" etc. to indicate that. ?I think it's also
> clear that no matter what verb is used, the entire resource is 'available'
> to the UA, that scripts can (if they wish) navigate anywhere in the entire
> resource, and that UAs can optimize the interface for the given verb, but
> the interface can still permit access to the entire resource.

Personally I'm pretty un-opinionated on these details.

If setting a range in the fragment results in the .currentTime
spanning from 0 to length-of-range or from start-of-range to
end-or-range seems only like a question of which API is the most
author friendly. Script can always remove the range-fragment if it
wants to use a .currentTime outside of the range.

The only argument that I can think of either way is that it might be
hard to create a decent UI for the situation when a range is
specified, but .currentTime is set to outside that range using script.

But again, I don't have much of an opinion.

/ Jonas
Received on Thursday, 14 May 2009 11:53:37 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:49 UTC