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

Re: Media Capture API restructured

From: Ilkka Oksanen <Ilkka.Oksanen@nokia.com>
Date: Wed, 07 Jul 2010 18:28:00 +0300
Message-ID: <4C349D00.3030908@nokia.com>
To: ext Andrei Popescu <andreip@google.com>
CC: Rich Tibbett <rich.tibbett@gmail.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
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. This attribute can 
be changed from boolean attribute to attribute that can contain these 
three values.

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?

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.

              -ilkka
Received on Wednesday, 7 July 2010 15:28:49 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:45 UTC