- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Wed, 06 Apr 2011 11:57:43 +0200
- To: public-device-apis@w3.org
Hi, As discussed during the F2F (and per my ACTION-367), I've updated HTML Media Capture to use a separate attribute instead of a media type parameter on the accept attribute: http://dev.w3.org/2009/dap/camera/#captureparam While writing it down, it appeared that we need to put some thought on the interactions between the capture attribute and the accept attribute. We need to address the combination of incompatible accept and capture attributes (e.g. "image/*" and "microphone", "image/svg" and "camera"), of capture attributes matching input devices not present on the device (e.g. there is no camcorder), and invalid values of capture attributes. My rough idea would be: * if there is no input device of the type specified in the capture attribute that allows to get the type of media specified in the accept attribute, then default to a type of input device that allows it - if the accept attribute specifies a full media type (e.g. image/svg) and there is no input device that allows to get that type, then do as if capture was set to "filesystem" - if the accept attribute specifies a range media type (e.g. image/*), do as if capture was set to an input device that allows for that range of media type; if there is no such input device, fallback to filesystem * if there is no accept attribute, and there is an input device matching the type described in the capture attribute, present the user with the option of recording files of all the types allowed by the said device * if there is no accept attribute, and there is no input device matching the type described in the capture attribute, fallback to filesystem Thoughts? Some suggestions on how to present this in a clearer way would be welcome too. Dom
Received on Wednesday, 6 April 2011 09:57:59 UTC