- From: Thomas Roessler <tlr@w3.org>
- Date: Wed, 16 Jun 2010 12:06:04 +0200
- To: Robin Berjon <robin@robineko.com>
- Cc: Thomas Roessler <tlr@w3.org>, Andrei Popescu <andreip@google.com>, Dominique Hazael-Massieux <dom@w3.org>, public-device-apis@w3.org
On 16 Jun 2010, at 11:50, Robin Berjon wrote: > Hi Andrei, > > On Jun 11, 2010, at 19:45 , Andrei Popescu wrote: >> On Fri, Jun 11, 2010 at 3:51 PM, Robin Berjon <robin@robineko.com> wrote: >>> - image/*;source=camera >>> - video/*;source=camera >>> - audio/*;source=microphone >> >> Yep, except video should maybe use "source=camcorder". >> >>> Would it make sense to make it source=device for all three? >> >> Maybe, but I am not sure this saves us much typing while potentially >> losing some clarity for Web authors. > > I'm not concerned with saving keyboard strokes, but more with silly bugs. The "source" parameter isn't a device selector, i.e. if there are two cameras on the terminal you can't go source=camera1 or source=camera2 (I presume that's the case, because otherwise you need a discovery mechanism to make it useful). > So essentially all that you want to flag is the fact that the author indicated a preference for capturing from a device rather than from file. Syntactically, you only need one keyword for that, not three. Another consideration: accept is currently specified in terms of a comma-separated list of MIME types without parameters. You now reuse the MIME parameter syntax to say something about the form behavior, but not really about the data that the form deals with. That seems strange. Any reason in particular for not simply using a parameter called, e.g., "capture", which would leave it to the user agent to determine the specific capture device? Benefits: - gracious fall-back even if an implementation isn't prepared to deal with MIME parameters - capture form elements are easily identifiable within the DOM
Received on Wednesday, 16 June 2010 10:06:12 UTC