- From: James Salsman <jsalsman@talknicer.com>
- Date: Sat, 17 Jul 2010 14:02:40 -0700
- 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 UTC