[whatwg] HTML Device element status

[Bjartur Thorlacius]

--------
James Salsman <jsalsman at talknicer.com> wrote:
> > [...]
> <input type=file> is buffered, which would seem to exclude the
> possibility of onchange=form.submit() in any of its forms' elements,
> but is otherwise parsimonious, while <device> is its unbuffered
> counterpart. [...]
> 
What about <form autosubmit> to request data to be automagically sent as soon as data is input and thus eliminate the buffering problem?
> Is there any reason not to protect both them with the same privacy and
> security authorization dialogs, and render them mostly the same,
> except for audio/* and video/* <input> you might have
> record/pause/play/submit while <device> would have record/pause?  For
> image/* the differences are less clear to me: perhaps <input> would
> have a viewfinder, (expandable on mobiles) shutter button, a
> filesystem browser button, and an (optional?) submit button, but an
> image/* <device> might only have a viewfinder and a shutter button.
> For the case of a camera, it would seem to me that the buffered
> approach is also superior, but the unbuffered <device> approach would
> allow audio and video teleconferencing.
If <device> is basically unbuffered <input> why was sharing email
addresses provided as a use case for <device>? And unbuffered FS access
as an stream-friendly alternative to <input>? WTF? FS access doesn't seem
practically useful sans JavaScript, and JavaScript has it's own interfaces
to things such as filesystems. Putting a placeholder for a JavaScript
interface for a filesystem in a web page doesn't make sense to me.

But for the use case you present, the only info that needs to be
present in the form is what protocol to use (implicit), whether to use
PUT or POST (covered in @method of <form>), the URI (@action of <form>)
accepted MIME types and potentially accepted MIME subtypes (both covered
by @accept). There are two problem with just using <form> and <input>
here: <form> implementations don't support simply uploading a single
unwrapped file and there isn't any way to request "bufferless submits"
that would autosubmit as soon as some minimal amount of data has been
gathered (such as @stream/@autosubmit of <form>).

> Also, someone said it would be a good idea to mute audio input and
> output from any hidden tab.  I think this may be a reasonable user
> option (people who listen to podcasts might not like it), and wonder
> if microphone or other audio input should be muted from any window and
> tab without top-most focus and exposure.  Does anyone have thoughts on
> that question?
I don't think muting other top-level browsing contexts should be made
an requirement. Browsers may of course ask for workstation/terminal wide
mute while recording for user convenience.