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

On Thu, 3 Dec 2009, 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.

Indeed.

The reverse is true on the Web side of things -- "starting 
programmatically the capture without a specific interaction from the user" 
is something we'd never want to allow on the Web (consider how porn sites 
would be a very different experience if they took video of you while you 
visited the site...).

This is probably an example of a set of requirements where we actually 
want two specs, one for widgets and one for the Web.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'