W3C home > Mailing lists > Public > public-device-apis@w3.org > June 2011

Re: Question about HTML Media Capture specification

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Mon, 27 Jun 2011 11:56:58 +0200
To: js45.yang@samsung.com
Cc: "Ilkka.Oksanen@nokia.com" <Ilkka.Oksanen@nokia.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>, 정상욱 <sangwook@samsung.com>, 이원석 <wonsuk11.lee@samsung.com>, 김규영 <gyuyoung.kim@samsung.com>
Message-ID: <1309168630.2542.203.camel@altostratustier>
Le jeudi 23 juin 2011 à 12:12 +0000, 양종석 a écrit :
> The "capture" attribute is just optional. Even if there is no
> "capture" attribute in the File Upload state, the user agenet should
> invoke some interface that allow to take a picture, record a sound
> file, recorder video, or select a file from file system.

Ideally, indeed. Your 4 first examples match the intent of the spec
without any doubt.

> Ex5)  <input type="file" accept="image/*" capture="microphone">
>     => It's to allow to take picture, select a file from file system.
>     => The capture attirbute is ignored because the value is
> "microphone" but it is not allowed to record a sound 
>     => It's the file picker present the interface for camera by
> default. The user can select the interface for camera within the file
> picker

That's indeed what the current specification suggest (although not very
explicitly); but this might open for discussion. The question really is
which of the two attributes (accept vs capture) should have prevalence
when they contradict each other.

> I think that the same file picker should be launched in all cases and
> the file picker includes all intefaces.
> I think that it's not easy to implement the file picker.
> So, My implementation choice is to launch "Interface selector" instead
> of the file picker.
> "Interface selector" will present the allowed behavior - "take a
> picture" "record a sound file" "recorder video" "file system"
> At that time, the user will select an interface from the "Interface
> selector" and the selected interface will be lauched.

Indeed, customizing file pickers might not always be possible depending
on the platform; an intermediate interface selector is probably a
reasonable way to solve this, although I imagine it has the
inconvenience to require more user interactions when the defaults are

I don't know if this is realistic, but maybe a better algorithm would
* if the capture parameter is not set (or set to an invalid value) but
the accept parameter is set to a image/, video/ or audio/*, use the
intermediate interface selector
* if the capture parameter is set to filesystem, only offer the file
picker and skip the intermediate selector
* if the capture parameter is set to a valid value, offer directly the
recording interface; assuming that recording interface can be more
easily customized, include a way to get the media file from the file
picker as an option 


Received on Monday, 27 June 2011 09:57:19 UTC

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