CaptureVsInput

From DAP WG Wiki
Revision as of 11:33, 3 December 2009 by Rberjon2 (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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