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: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 21 Jul 2010 11:18:18 -0700
Message-ID: <AANLkTin73vbb5jWTJSMhcVdpy44Y0gnmvs3fUI3JtNCU@mail.gmail.com>
To: Henri Sivonen <hsivonen@iki.fi>
Cc: "public-html@w3.org WG" <public-html@w3.org>, public-device-apis@w3.org
On Wed, Jul 21, 2010 at 5:22 AM, Henri Sivonen <hsivonen@iki.fi> wrote:
> 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?

A few comments:

The MediaList interface is unnecessary. The Files returned from the
FileList interface can implement the MediaFile. Compare to how
NodeList interface always returns Node objects, but that those Node
objects often also implement Element or TextNode.

It's good that the 'capture' mime parameter is defined to be a hint
and isn't required to affect behavior in any way. It's still unclear
that it is really needed. A good browser UI should likely *always*
display buttons for attaching a file or capturing a new image or video
using a camera. That is what we are long term hoping to do for firefox
since the vast majority of pages don't have an @accept attribute at
all. If an implementation want to be conservative and not always
display a button for capture, triggering off of @accept containing a
"image/..." mimetype seems reasonable.

Why is MediaFile defined to only be implemented on Files captured
using a device? Why not also allow it to be implemented by files that
reside on the users file system?

It's probably a good idea to make the FormatData accessor
asynchronous. Otherwise implementations are required to read all such
data into memory every time a MediaFile is instantiated.

/ Jonas
Received on Wednesday, 21 July 2010 18:19:24 UTC

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