W3C home > Mailing lists > Public > public-device-apis@w3.org > July 2010

Re: Media Capture API restructured

From: Andrei Popescu <andreip@google.com>
Date: Thu, 8 Jul 2010 13:49:54 +0100
Message-ID: <AANLkTil2Ah8fabrtFjLBybtmajXpynKPKXr6gjg1v04x@mail.gmail.com>
To: Ilkka Oksanen <Ilkka.Oksanen@nokia.com>
Cc: Rich Tibbett <rich.tibbett@gmail.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>

On Wed, Jul 7, 2010 at 4:28 PM, Ilkka Oksanen <Ilkka.Oksanen@nokia.com> wrote:
> On 07.07.10 17:13, ext Andrei Popescu wrote:
>>    Also, could MediaArray be renamed to MediaList in line with the
>>    File API spec?
>> Sounds fine.
> I can change this.
>>    Regarding the 'capture' attribute perhaps a better approach would
>>    be <input type="file" accept="video/*;source=capture">? I'm not
>>    sure that the capture attribute adds anything important to the
>>    file upload element.
>> As mentioned before, that's the approach we took in Android (except that
>> the source can be camcorder / camera / microphone, rather than capture).
>> It's easy to use and easy to implement.
> Introducing new attribute is a little bit cleaner solution as long as input
> based capturing is a separate document I think.

Why is cleaner?

> Andrei and others, can you describe how you plan the source parameter to
> work in practice in your implementation? Is it still possible to select
> normal files if it exists? And vice versa, what if "video/*" or
> "source=camera" is missing, is it then possible for the user to capture
> video or audio?

For a device that has a camera onboard, this is how it works in our

<input type="file">

This triggers a file picker with all options available: gallery,
camera, camcorder, microphone.

<input type="file" accept="image/*">

This triggers a file picker with only two choices: gallery, camera.

<input type="file" accept="image/*;source="camera">

This triggers the camera viewfinder directly. On Android, the
viewfinder is fullscreen and doesn't have a button to switch to the

> My thinking has been that both selecting files and capturing content should
> be possible in every case. Source parameter or attribute just hints in what
> mode the file picker should be initially be.

Are you thinking that this affects the choice of "capture attribute"
vs "source param"? I am not sure I see how...It sounds more like an
implementation issue to me.

Received on Thursday, 8 July 2010 12:50:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:22 UTC