W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

Re: "HTML Media Capture" prepared for publication

From: James Salsman <jsalsman@talknicer.com>
Date: Sat, 17 Jul 2010 14:02:40 -0700
Message-ID: <AANLkTik-zRvnBnU1ToaV5nZW0frKRD03vI0sDx6d7wVx@mail.gmail.com>
To: dom@w3.org, public-device-apis@w3.org
Cc: Ingmar.Kliche@telekom.de, WHATWG <whatwg@lists.whatwg.org>, Web Applications Working Group WG <public-webapps@w3.org>
At least one of the browser authors who were saying they were
implementing buffered device input and upload from cameras and
microphones with input type=file had indicated they might use the
accept= parameter, but I can certainly see the benefit of being able
to specify the choice of a file from either the filesystem or a
device, and a MIME type parameter is as good a place as any to do
that.

Please forgive the cross posting and top posting, but I also need to
ask:  Has anyone considered how to restrict onchanged=form.submit() in
such forms?  I think that is inappropriate for most
multipart/form-encoded POSTs, but I don't want to suggest anything
that would break existing applications.

Furthermore I hope the security considerations sections will soon
include a summary of the language we've discussed about prompting for
device access with the option for remembered choices for permission
grants, along with a way to override and respond to such prompts with
device buttons like a shutter key and/or a record key. I understand
that the user always has an option to reject buffered and
filesystem-based device input by not submitting the form, but it would
be spectacular for the web application to have a way to know when the
user decided it wouldn't grant access to the device (i.e., if there is
background noise or any of dozens of other reasons.) Finally, I
strongly prefer granted permission review and revocability and I hope
that makes it in to the security considerations section, too.

Sincerely,
James Salsman

On Sat, Jul 17, 2010 at 11:47 AM,  <Ingmar.Kliche@telekom.de> wrote:
> Hi Dom,
>
> I think we also briefly tackled the issue of making the FormatData
> attribute of the MediaFile interface read-only (in File all attributes
> are read-only [1]). Was there a decision against making it read-only?
>
> - Ingmar.
>
> [1] http://www.w3.org/TR/2009/WD-FileAPI-20091117/#file
>
> -----Original Message-----
> From: public-device-apis-request@w3.org
> [mailto:public-device-apis-request@w3.org] On Behalf Of Dominique
> Hazael-Massieux
> Sent: Friday, July 16, 2010 12:15 PM
> To: public-device-apis@w3.org
> Subject: "HTML Media Capture" prepared for publication
>
> Hi,
>
> The Working Group agreed on targeting to publish "HTML Media
> Capture" (which ties <input type="file" accept="image/*;capture=camera">
> to the camera and the MediaFile interface) next week as an updated draft
> of http://www.w3.org/TR/capture-api/ .
>
> I've finished preparing the draft with the changes agreed upon during
> the discussions in the F2F this morning at:
> http://dev.w3.org/2009/dap/camera/
>
> This includes:
> - Changed title to "HTML Media Capture"
> - Change "capture" attribute to "capture" parameter of "accept"
> attribute with values in camera, microphone, camcorder
> - Remove "type" attribute from FormatData (redundant with Blob.type)
> - added note on relation to HTML5 (MediaFile interface, capture
> parameter)
> - added note on possible relationship to Media Ontology API
> - Removed the "trusted environments" example
>
> Please let me know if there any last minute changes that you think would
> be useful to bring to the document before a new public draft.
>
> Dom
>
>
>
>
>
>
Received on Saturday, 17 July 2010 21:03:09 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:39 GMT