[whatwg] File inputs, @accept, and expected behavior

[Tab Atkins Jr.]

On Tue, Feb 8, 2011 at 1:41 AM, Rich Tibbett <richt at opera.com> wrote:
> Tab Atkins Jr. wrote:
>>
>> The file input gained the @accept attribute a little while ago, to
>> indicate what type of file should be accepted.  It has three special
>> values, "image/*", "video/*", and "audio/*".
>>
>> I believe one intent of these special values is that browsers may
>> offer the user the ability to capture an image/video/audio with the
>> webcam/mic and automatically set it as the value of the<input>,
>> without the user having to create an intermediary file themselves.
>>
>> The spec doesn't give any indication of this, though, and I've
>> surprised some people (browser devs, internally) when I tell them
>> about @accept after they ask me about access the webcam/mic.
>
> That is possible, yes. It's about providing a video/image/audio file or
> capturing from the webcam/mic by creating an on-the-fly file to return.
>
> For explicitly requesting a webcam or microphone 'file' from a web page we
> have produced the W3C Media Capture spec [1].
>
> For streaming webcam and/or microphone were working on and around the
> <device> element.

Yes, this all seems good and correct.  <input type=file
accept=video/*> allows the UA to give the option of recording a video,
<input type=file accept=video/*;capture=camcorder> gives a stronger
hint that the author expects the user to record a video, and <device>
gives direct access to the video stream from a camera.


>> Could we get a note added to the File Input section describing this
>> intention?
>
> It's entirely a interface option for UAs to provide (e.g. [2]) but the
> primary intention is on sharing normal video/audio/image files so a note in
> the spec seems a little unnecessary IMO.

Right now it's entirely unobvious that UAs should even *think* about
offering the functionality to record a file, so I think it would be
useful.

~TJ