W3C home > Mailing lists > Public > public-device-apis@w3.org > December 2009

Re: Comparing capture* API vs <input type="file" accept="...">

From: Frederick Hirsch <frederick.hirsch@nokia.com>
Date: Fri, 4 Dec 2009 09:37:25 -0500
Cc: Frederick Hirsch <frederick.hirsch@nokia.com>, Arve Bersvendsen <arveb@opera.com>, public-device-apis <public-device-apis@w3.org>
Message-Id: <A50F2C22-B70D-40A1-9CC6-91F68BD5C3A5@nokia.com>
To: ext Dominique Hazael-Massieux <dom@w3.org>
+1, it seems we should avoid unnecessary manipulations, as Bryan also  
noted earlier as well

regards, Frederick (not as chair)

Frederick Hirsch

On Dec 3, 2009, at 5:24 AM, ext Dominique Hazael-Massieux wrote:

> Le jeudi 03 décembre 2009 à 11:00 +0100, Arve Bersvendsen a écrit :
>> <input type="file" accept="…">, In widgets:
>> This is currently marked as "awkward to use", not really, an example:
>> <input id="someForm" type="file" accept="image/*" data- 
>> foo="bar"><!-- foo
>> and bar is something that to provide a hint to the UA to not launch  
>> a file
>> chooser, but rather the camera app)
> But that’s already two very unintuitive things to do:
> • adding an element in the markup (and so cognitively a control in the
> user interface) when what you want is starting programmatically the
> capture without a specific interaction from the user,
> • adding a possibly platform-specific data- attribute whose semantic
> would remain to be seen;
> I clearly wouldn’t find myself comfortable using this in a widget, and
> even less so telling the world how great a solution it is :) I could
> explain it, but I would hardly call that a great programmatic API for
> widgets.
> I can see that it has some value in keeping compatibilities between
> closed and open environments, but that’s really the only thing
> not-awkward about it, in my opinion.
> Dom
Received on Friday, 4 December 2009 14:38:22 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:41 UTC