HTML Media Capture

W3C Working Draft 12 July 2012

This version:
Latest published version:
Latest editor's draft:
Previous version:
Anssi Kostiainen, Nokia
Ilkka Oksanen, Nokia (until May 10, 2012)
Dominique Hazaël-Massieux, W3C (until May 10, 2012)


The HTML Media Capture specification defines HTML form extensions that facilitate users' access to media capture capabilities of the hosting device.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This specification covers a subset of the media capture functionality being worked on by the DAP WG. It is specifically designed to be simple and declarative.

This document was published by the Device APIs Working Group as a Last Call Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to public-device-apis@w3.org (subscribe, archives). The Last Call period ends 09 August 2012. All feedback is welcome.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This is a Last Call Working Draft and thus the Working Group has determined that this document has satisfied the relevant technical requirements and is sufficiently stable to advance through the Technical Recommendation process.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Table of Contents

1. Introduction

This section is non-normative.

This specification extends the HTMLInputElement interface with a new capture attribute. The attribute enables content authors to give hints of preferred means to capture local media such as images, video, and sound, that is to be subsequently uploaded. Conformant user agents provide their users more seamless access to the above-mentioned media capture capabilities of the hosting device.

Access to media streams from the hosting device is out of scope for this specification.

2. Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words must, must not, required, should, should not, recommended, may, and optional in this specification are to be interpreted as described in [RFC2119].

This specification defines conformance criteria that apply to a single product: the user agent that implements the interfaces that it contains.

Implementations that use ECMAScript to implement the APIs defined in this specification must implement them in a manner consistent with the ECMAScript Bindings defined in the Web IDL specification [WEBIDL], as this specification uses that specification and terminology.

3. Terminology

The input element and the HTMLInputElement interface are defined in [HTML5].

The File Upload state is defined in [HTML5].

The enumerated attribute microsyntax, and associated terms and concepts keyword, state, invalid value default, and missing value default, are defined in [HTML5].

In this specification, the term capture control type refers to a specialized type of a file picker control that is optimized, for the user, for capturing media of a specified type.

4. Security and privacy considerations

This specification builds upon the security and privacy protections provided by the <input type="file"> [HTML5] and the [FILE-API] specifications; in particular, it is expected that any offer to start capturing content from the user’s device would require a specific user interaction on an HTML element that is entirely controlled by the user agent.

Implementors should take care of additional leakage of privacy-sensitive data from captured media. For instance, embedding the user’s location in a captured media metadata (e.g. EXIF) might transmit more private data than the user might be expecting.

5. The capture attribute

This section is normative.

When an input element's type attribute is in the File Upload state, the rules in this section apply.

partial interface HTMLInputElement {
    attribute DOMString capture;

5.1 Attributes

capture of type DOMString

When the capture attribute is specified, the user agent should invoke a file picker of the specific capture control type.

The capture attribute controls the capture state (and associated capture control type) of the element. It is an enumerated attribute. The following table lists the keywords, states, and corresponding capture control types for the attribute. The keywords camera, camcorder, microphone, and filesystem map to the corresponding states: Image Capture, Video Capture, Sound Capture, and File Upload respectively.

Keyword State Capture control type
camera Image Capture A camera
camcorder Video Capture A video camera
microphone Sound Capture A sound recorder
filesystem File Upload A generic file picker

The capture attribute's invalid value default and missing value default is the File Upload state.

The HTMLInputElement interface's accept attribute takes precedence over the capture attribute. That is, if the accept attribute's value is set to a MIME type that is not accepted in a defined capture state, the user agent must act as if there was no capture attribute.

This specification complements the following behavior defined in the File Upload state [HTML5]: User agents may use the value of [the accept] attribute to display a more appropriate user interface than a generic file picker. For instance, given the value image/*, a user agent could offer the user the option of using a local camera or selecting a photograph from their photo collection; given the value audio/*, a user agent could offer the user the option of recording a clip using a headset microphone.

A. Examples

This section is non-normative.

The following example gives a hint that it is preferred for the user to take a picture using the device's local camera, and upload the picture taken:

Example 1
<input type="file" accept="image/*" capture="camera">

When an input element's capture attribute is in the Image Capture state, the file picker may render as presented on the right side. When the attribute is in the File Upload state, the generic file picker may render as represented on the left side.

A File picker control in the File Upload (left) and Image
      Capture state (right).

B. References

B.1 Normative references

Arun Ranganathan; Jonas Sicking. File API. 20 October 2011. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2011/WD-FileAPI-20111020/
Ian Hickson; David Hyatt. HTML5. 25 May 2011. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/html5
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Internet RFC 2119. URL: http://www.ietf.org/rfc/rfc2119.txt
Cameron McCormack. Web IDL. 27 September 2011. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2011/WD-WebIDL-20110927/

B.2 Informative references

No informative references.