- 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>
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 clear. I don't know if this is realistic, but maybe a better algorithm would be: * 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 HTH, Dom
Received on Monday, 27 June 2011 09:57:19 UTC