- From: Jimenez, Ernesto, VF-Group <Ernesto.Jimenez@vodafone.com>
- Date: Mon, 4 Jul 2011 13:36:41 +0200
- To: "Dominique Hazael-Massieux" <dom@w3.org>, <js45.yang@samsung.com>
- Cc: <Ilkka.Oksanen@nokia.com>, <public-device-apis@w3.org>, 정상욱 <sangwook@samsung.com>, 이원석 <wonsuk11.lee@samsung.com>, 김규영 <gyuyoung.kim@samsung.com>
> -----Original Message----- > From: public-device-apis-request@w3.org [mailto:public-device-apis- > request@w3.org] On Behalf Of Dominique Hazael-Massieux > > > 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. According to the spec, the capture *may* be present and just provides *a hint* on what you prefer to use: an existing image/video/audio file from the FS or capture a new one. My interpretation from the spec is that the important attribute is accept, which is what instructs what you want to get, and the fact that we have camera/camcorder/microphone as options for capture is just redundant, it could just be new or filesystem. What is the reason for having camera/camcorder/microphone as capture options when they correlate 1 to 1 with the image/video/audio accept values? I'm probably missing something :) Best, Ernesto
Received on Monday, 4 July 2011 11:37:29 UTC