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: Tue, 5 Jul 2011 12:58:39 +0200
Message-ID: <09C3F9F1A21FF546B312200CFA69F53B02BC9DA8@VF-MBX20.internal.vodafone.com>
To: "Dominique Hazael-Massieux" <dom@w3.org>
Cc: <js45.yang@samsung.com>, <Ilkka.Oksanen@nokia.com>, <public-device-apis@w3.org>, 정상욱 <sangwook@samsung.com>, 이원석 <wonsuk11.lee@samsung.com>, 김규영 <gyuyoung.kim@samsung.com>
My comments with my developer hat on.

> -----Original Message-----
> From: Dominique Hazael-Massieux [mailto:dom@w3.org]
> 
> Le lundi 04 juillet 2011 à 14:59 +0200, Jimenez, Ernesto, VF-Group a écrit :
> > However, I don't understand why I would want to take a picture from
> > the camcorder. Could you elaborate on that? :)
> 
> I'm afraid I can't :)
> 

Maybe we should review what the use cases are. Given the current options, it seems the different capture options don't provide any new besides whether you want fresh or saved content. The information about the different input methods seems to be redundant and, as you pointed out, might be conflicting with the accept (e.g.: <input type="file" accept="image/*" capture="microphone">).

Depending on the use cases we can check what options would make sense. 

> This originates from the Android implementation of this that takes a named
> parameter to indicate the preferred source of the media content, but it's not
> clear to me indeed how the developer would make a useful guess as to what
> is best used for the given content.
> 

Disregarding the discussion about whether we should have different attribute values for the different input methods (camera/camcorder/microphone). According to the thread you commented, Android implementation it's not even using the source parameter to choose a preferred source, but indicating the mandatory source (at least one year ago, :

> ---- From Andrei Popescu ----
> ---- http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/0060.html  ----
> <input type="file" accept="image/*;source="camera">
> 
> This triggers the camera viewfinder directly. On Android, the
> viewfinder is fullscreen and doesn't have a button to switch to the
> gallery.

As a developer, I would like to have consistency when setting my input with capture="camera". Is it going to show the camera dialog by default still enabling uploading a photo from the gallery? Is it going force the user to take a picture and not allowing him to choose one from the gallery?

I need to know if <input type="file" accept="image/*" capture="camera"> forces the user to take a picture because then I'll need to add an input with capture="filesystem" to enable them upload photos from the gallery.

As an example, if we want the capture element to be a hint on the *preferred* source, I would specify that UA's might use the capture attribute to select a source by default and they must allow the user to select another source.

Then the implementer would decide what's their ideal UX for their browser: showing an special button with different options in the page, adding an intermediate dialog for the user to choose if they want to take a picture or choose an existing one, showing the interface to take the picture but have an option to activate the gallery, etc.

What do you think?

Received on Tuesday, 5 July 2011 10:59:07 UTC

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