[whatwg] File inputs, @accept, and expected behavior
Tab Atkins Jr.
jackalmage at gmail.com
Tue Feb 8 09:28:32 PST 2011
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 .
> 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
> It's entirely a interface option for UAs to provide (e.g. ) 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
More information about the whatwg