CaptureVsInput

This table proposes to compare the pros and cons of designing the capture API using a brand new Capture interface (possibly implemented on navigator.device) vs re-using the <input> mechanism with a derivation of the FileReader API. See the related discussion thread.

	.capture*	<input type="file" accept="…">	<input type="photo"> (resp audio, video)
UI	new non-modal prompt	form control derived from input file, part of the page	new form control, part of the page
scope of new API	several new interfaces	limited (derive from FileReader)	limited (derive from FileReader)
In widgets	can grant access to API without prompt	awkward to use	awkward to use
Integration with Media gallery	left to the developer	possibly transparent (but down to the UA)	possibly transparent (but down to the UA)
viewfinder compat	new API calls needed	possibly transparent?	possibly transparent?
control on number and duration of captures	available in API	number controled by number of fields — awkward user exp; not clear how to control duration	could be controled with attributes on the input field?
detection for support of capture capabilities	possible with boolean flags added to Capture interface	not clear; might need flags addition	not clear either
evolution for more control of the capture devices	need new API calls added to Capture	no clear path; probably would need API of its own, but not clear how to plug in <input>	no clear path; probably would need API of its own, but not clear how to plug in <input>
impact/dependence on markup spec (html5?)	None	Limited	Not trivial