W3C is pleased to receive the Device Input submission from Cisco Systems.
The submission describes a proposed extension to HTML forms to allow for input from devices such as microphones, scanners and cameras.
From the abstract:
Currently, HTML forms allow the producer of the form to request information, including files of data, from the operator using the form. However, this capability is limited because HTML forms don't provide a way to ask the operator to submit input from arbitrary sources such as audio devices like microphones. Since input and upload from various devices is a feature that will benefit many applications, this draft proposes an extension to the HTML INPUT type="file" form element. Motivations include language instruction assistance, voice transcription, and high-quality speech transmission under low-bandwidth conditions.
The W3C membership is invited to discuss the disposition of the submission in the w3c-ac-forum mailing list or to advise the Director via the team contact.
The participants of the HTML Activity have reviewed the proposal for possible use in their work on forms.
The following statement is from the chair of the HTML working group:
HTML is intended to be a device-independent markup; this means that any proposal that suggests markup that includes the word "device", especially if there is no fall-back mechanism, should ring alarm bells.
This is the fundamental problem with the device upload submission (without going into detailed criticism).
To take an example from the submission (http://www.w3.org/TR/device-upload):<INPUT name="picture1" type="file" device="camera" value="2">
What should happen if the user doesn't have a camera, but does have a photograph and a scanner? What if there is a camera, but not connected to the computer, so that the user has to take a picture, download it, and then upload it from a file?
These differences shouldn't be visible in the markup, but should be abstracted out into the *intent*, so that a user agent can then offer whatever is available on the client machine in question.
In other words, the markup should state that an *image* (or a movie, or a sound, or whatever) is required, not a camera, and the user agent, seeing that an image needs to be supplied can then offer whatever facilities are available for delivering an image (scanner, camera, filestore, TV card, ...)
In fact this is exactly how the markup works currently in HTML 4 (http://www.w3.org/TR/html4/). For instance, you can write:<INPUT name="picture1" type="file" accept="image/*">
It should then be up to the user agent to offer to let you use the camera or scanner, as available, or the filestore.
Apparently the browser manufacturers have mistaken the attribute value "file" to mean "something from the filestore", rather than "something to be packaged and sent as a file". A possible solution to this could be a submission in the form of a note on recommendations to browser manufacturers on how to implement the user interface to file upload.
There are many messages relating to the proposal in the email archive for the mailing list used for the working group's discussion of forms. W3C members (only) can see for themselves the various threads on the device upload proposal in:
Disclaimer: Placing a Submission on a Working Group agenda does not
imply endorsement by either the W3C Staff or the participants of the Working
Group, nor does it guarantee that the Working Group will agree to take any
specific action on a Submission.