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

Re: HTML Media Capture draft from Device APIs and Policy Working Group

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Wed, 21 Jul 2010 16:29:25 +0200
To: Henri Sivonen <hsivonen@iki.fi>
Cc: "public-html@w3.org WG" <public-html@w3.org>, public-device-apis@w3.org
Message-ID: <1279722565.2282.765.camel@localhost>
Le mercredi 21 juillet 2010 à 15:22 +0300, Henri Sivonen a écrit :
> On Jul 20, 2010, at 18:33, Dominique Hazael-Massieux wrote:
> > The Device APIs and Policy Working Group has published a new draft
> > called "HTML Media Capture" on which we think we'll need to coordinate
> > with your group:
> > http://www.w3.org/TR/2010/WD-html-media-capture-20100720/
> > 
> > That document defines a mechanism to bind an <input type=file> with a
> > set of well-defined accept attribute values, completed by a mime type
> > parameter ("capture"), with an extended file picker (that integrates
> > access to on-device microphones, cameras and camcorder) and resulting in
> > a MediaFile object that extends the File object from the FileAPI.
> Why is the capture parameter needed?
> Why wouldn't browsers always allow the use of a capturing device (in
> addition to picking an existing file) when a page has <input type=file
> accept='...'> where '...' is a capturable type and there's a suitable
> capture device available?

The goal is that they always would, but that the capture parameter would
give a hint to the browsers that they should start the file picker
interface using the capture mode rather than the pick-a-file mode.

(that's more or less what the Android browser currently does, based on
what Andrei has described:
http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/0060.html )

Received on Wednesday, 21 July 2010 14:29:34 UTC

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