This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/complete/commands.html Section: http://www.whatwg.org/specs/web-apps/current-work/complete.html#devices Comment: Rather than use the USB/rs232 keywords, I would recommend going with the keyword "peripheral" for any device attached to the computer. This way it would not matter if the device in question is USB, 1394, or something platform exclusive. This will future proof the input as well, since it is the data being fetched is what is important, not the connection method. Data being fetched should be broken down into what it is. For example, audio, video (just a video stream), fs, media (comprised of several media streams, such as audio, video, location, text, etc), text, image, location (GPS device), spacial (anything returning spacial data, rangefinder, radar, lidar, etc). I would also recommend using multiple types when specifying a device. For a webcam, do type="media audio video" to ensure that even if the camera does not support audio, the device chooser will then also let you choose a microphone. For playing a media file such as a music file do type="audio image text", this would allow the device to expect an audio file with cover art and lyrics. That is all I have to ramble about. I hope this is of some help. ~Trevor Downs Posted from: 71.198.1.49
Here, I'll format it better. I didn't know the comment would go into a bug tracker. Rather than use the USB/rs232 keywords, I would recommend going with the keyword "peripheral" for any device attached to the computer. This way it would not matter if the device in question is USB, 1394, or something platform exclusive. This will future proof the input as well, since it is the data being fetched is what is important, not the connection method. Data being fetched should be broken down into what it is. For example, audio, video (just a video stream), fs, media (comprised of several media streams, such as audio, video, location, text, etc), text, image, location (GPS device), spacial (anything returning spacial data, rangefinder, radar, lidar, etc). I would also recommend using multiple types when specifying a device. For a webcam, do type="media audio video" to ensure that even if the camera does not support audio, the device chooser will then also let you choose a microphone. For playing a media file such as a music file do type="audio image text", this would allow the device to expect an audio file with cover art and lyrics. That is all I have to ramble about. I hope this is of some help. ~Trevor Downs
Oh, and the title of this bug should be changed to 'Use "peripheral" as the base generic device class keyword', or something to that effect.
I don't really understand how that would work for RS232 devices. If I have a serial port and I want to have a page send bits down the physical wire, how would a generic "peripheral" API work? I think we might end up dropping things beyond cameras and microphones for now, since it's not clear how to handle them generically and handling them on a case-by-case basis is best done on a case-by-case basis, not wholesale.
(In reply to comment #3) > I don't really understand how that would work for RS232 devices. If I have a > serial port and I want to have a page send bits down the physical wire, how > would a generic "peripheral" API work? > > I think we might end up dropping things beyond cameras and microphones for now, > since it's not clear how to handle them generically and handling them on a > case-by-case basis is best done on a case-by-case basis, not wholesale. I was basically trying to get around the messy business of managing device connections and the connector types. My scan & upload web page should not care if my scanner is attached via USB, FireWire or even RS-232. All it should care about is seeing an object of type scanner and being able to fetch an image from it. As for the peripheral object itself, I meant it to be a starting point. It could either be used as a base class or as some kind of capabilities collection. So let's say we get the capabilities object from the peripheral for an RS-232 collection. If the API support your desire to just send a bunch of bits down the line, you could (in all likelyhood this wouldn't be included for security reasons.)
I ended up moving away from <device> as a generic mechanism, because I couldn't work out how to make it work. If you have any concrete proposals, please don't hesitate to reopen the bug and post them here (or on one of the lists). See also this entry in the FAQ: http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F For scanners in particular, <input type=file accept="image/*"> is probably a better solution.