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

RE: Question about HTML Media Capture specification

From: Jimenez, Ernesto, VF-Group <Ernesto.Jimenez@vodafone.com>
Date: Mon, 4 Jul 2011 13:36:41 +0200
Message-ID: <09C3F9F1A21FF546B312200CFA69F53B02BC9ABE@VF-MBX20.internal.vodafone.com>
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 :)

Received on Monday, 4 July 2011 11:37:29 UTC

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