Re: [whatwg] Do we really need a device element?
On 6/14/10, James Salsman jsals...@gmail.com wrote: On Sun, Jun 13, 2010 at 6:36 PM, James Salsman jsals...@gmail.com wrote: ... I [was] persuaded that the device element is unnecessary, given recent announcements for the accept=...;source=... type specification proposed by Android and Firefox developers. Does anyone have any reasons to the contrary? A device element with a type parameter would be useful when the HTML author is unaware of the target browsers' choice of specific elements such as embed, object, video, microphone, camera, camcorder etc. to control placement of, for example, audio volume and recording level controls, microphone visual feedback, video display viewports, camera and camcorder viewfinders, etc. for real-time device access, which does seem to be very reasonable to do in HTML instead of Flash. Use cases include teleconferencing, screen grabs (device type=image;source=desktop?), maybe shared whiteboards (device type=pointer;source=canvas-id producing coordinate streams and up/down codes?) Real-time camcorder upload has as compelling use case as buffered form-based input type=file accept=video;source=webcam does under lower bandwidth situations. People will want both, so I am not ready to write off the device element yet. Are file inputs defined to be more buffered than devices? Where? IMO a streaming capability should rather be added to form than adding a brand-new device element. The only thing the device element does is hinting that the input should come from alternative sources and provide a new scripting interface. What if you want to use the new scripting interface but not hint that the input should be from alternative sources? Really the reasoning given for the device element, quoting the draft: The device element represents a device selector, to allow the user to give the page access to a device, for example a video camera. So, it's an UI-widget an UA can show to human users to authorize script access to a device. Where's the definition of a device (couldn't find it in the draft, may be my ignorance). If this becomes a standard, shouldn't there also be a standard for an element for pop-up authorizing UI-widgets? If privacy is the reason for this element, as the draft says, why is/would it not be enough to allow requests for devices to fail and allow users not to upload (live) recordings of themselves? It was discussed on the W3C list that users should have to go out of their way to allow scripts to access their devices. Input accept enforces that. Implementations of the Media Capture API can implement similiar measures to protect human users' privacy as device implementations can. A semi-related note: Forms need some way to hint that UAs should stream submits (even before the form is filled in). -- kv, - Bjartur
Re: [whatwg] Do we really need a device element?
On Wed, Jun 16, 2010 at 10:43 AM, Bjartur Thorlacius svartma...@gmail.com wrote: On 6/14/10, James Salsman jsals...@gmail.com wrote: ... I [had been earlier] persuaded that the device element is unnecessary, given recent announcements for the input type=file accept=...;source=... type specification proposed by Android and Firefox developers. Does anyone have any reasons to the contrary? A device element with a type parameter would be useful when the HTML author is unaware of the target browsers' choice of specific elements such as embed, object, video, microphone, camera, camcorder etc. to control placement of, for example, audio volume and recording level controls, microphone visual feedback, video display viewports, camera and camcorder viewfinders, etc. for real-time device access, which does seem to be very reasonable to do in HTML instead of Flash. Use cases include teleconferencing, screen grabs (device type=image;source=desktop?), maybe shared whiteboards (device type=pointer;source=canvas-id producing coordinate streams and up/down codes?) Real-time camcorder upload has as compelling use case as buffered form-based input type=file accept=video;source=webcam does under lower bandwidth situations. People will want both, so I am not ready to write off the device element yet. Are file inputs defined to be more buffered than devices? Yes. Where? At this point, it's either DAP or WebApps, and I am trying to figure out which. The input type=file element has been buffered, asynchronous (per POST, not per javascript callback), multipart/form-encoded since HTML 3, with the accept=... MIME type list attribute appearing in HTML 3.2. IMO a streaming capability should rather be added to form than adding a brand-new device element. Streaming forms? There is input onChange=Form.submit() ..., but that is not really appropriate for file uploads and I haven't seen any proposals along those lines. (Someone please correct me if there are any!) To the extent that we are supposed to obtain interoperability before promoting standards, we need to follow current practice, which is closer to the sockets API as far as emulating the behavior of Adobe Flash goes (if it were up to me, the sockets and the file interface would be merged into a backward-compatible, coherent, and less namespace-cluttering whole, but I think that ship has probably sailed.) The only thing the device element does is hinting that the input should come from alternative sources and provide a new scripting interface. It's also supposed to cause a permissions request (which may typically be a non-blocking (modeless), one-at-a-time prompt for things like microphones or contacts, or a shutter button press for things like cameras. What if you want to use the new scripting interface but not hint that the input should be from alternative sources? Presumably there will be reasonable defaults, or a selection dialog if there is more than one possibility and a default has not been established. The device element represents a device selector, to allow the user to give the page access to a device, for example a video camera. So, it's an UI-widget an UA can show to human users to authorize script access to a device. Where's the definition of a device (couldn't find it in the draft, may be my ignorance). If this becomes a standard, shouldn't there also be a standard for an element for pop-up authorizing UI-widgets? Yes, the same interface is being contemplated for file system, contacts database, calendar item, and photo gallery access at present. If privacy is the reason for this element, as the draft says, why is/would it not be enough to allow requests for devices to fail and allow users not to upload (live) recordings of themselves? I don't understand that question, sorry.
Re: [whatwg] Do we really need a device element?
On Sun, Jun 13, 2010 at 6:36 PM, James Salsman jsals...@gmail.com wrote: ... I [was] persuaded that the device element is unnecessary, given recent announcements for the accept=...;source=... type specification proposed by Android and Firefox developers. Does anyone have any reasons to the contrary? A device element with a type parameter would be useful when the HTML author is unaware of the target browsers' choice of specific elements such as embed, object, video, microphone, camera, camcorder etc. to control placement of, for example, audio volume and recording level controls, microphone visual feedback, video display viewports, camera and camcorder viewfinders, etc. for real-time device access, which does seem to be very reasonable to do in HTML instead of Flash. Use cases include teleconferencing, screen grabs (device type=image;source=desktop?), maybe shared whiteboards (device type=pointer;source=canvas-id producing coordinate streams and up/down codes?) Real-time camcorder upload has as compelling use case as buffered form-based input type=file accept=video;source=webcam does under lower bandwidth situations. People will want both, so I am not ready to write off the device element yet.
Re: [whatwg] Do we really need a device element?
On 6/12/10, James Salsman jsals...@gmail.com wrote: Bjartur, real-time streaming audio uploads enable pronunciation assessment for language instruction during multiplayer online roleplaying games such as those by http://www.8dworld.com input type=file accept=audio/x-speex;quality=(0-10);bitrate=... is more important, and accept=audio/ogg video/x-webm, video/ogg are all fairly important, too. On Jun 12, 2010 11:15 AM, Bjartur Thorlacius svartma...@gmail.com wrote: What is the use case for device? I´ve searched the archives, read a thread, Googled around and read a document on the subject, but still I haven´t found a use case for it other than it is going to magically increase user privacy. input type=file accept=audio/* is a standard and compatible way to request audio stream(s). I can´t see any drawbacks to using input for audiovisual streams at least. -- kv, - Bjartur -- kv, - Bjartur
Re: [whatwg] Do we really need a device element?
On 6/12/10, James Salsman jsals...@gmail.com wrote: Bjartur, real-time streaming audio uploads enable pronunciation assessment for language instruction during multiplayer online roleplaying games such as those by http://www.8dworld.com Yes, applications may need audio/visual input, hence W3C's WG DAP has created an API for accessing audiovisual devices. As there's already a standard for accessing such devices, what value does device add? And why should this even be a HTML element in the first place, rather than an (JS) API? input type=file accept=audio/x-speex;quality=(0-10);bitrate=... is more important, and accept=audio/ogg video/x-webm, video/ogg are all fairly important, too. One non-native English writer to another: I peg your pardon? P.S. sry for prev. post; gmail fkd up.
Re: [whatwg] Do we really need a device element?
Summary: I have been persuaded that the device element is unnecessary, given recent announcements for the accept=...;source=... type specification proposed by Android and Firefox developers. Does anyone have any reasons to the contrary? On Sun, Jun 13, 2010 at 7:33 AM, Bjartur Thorlacius svartma...@gmail.com wrote: On 6/12/10, James Salsman jsals...@gmail.com wrote: Bjartur, real-time streaming audio uploads enable pronunciation assessment for language instruction during multiplayer online roleplaying games such as those by http://www.8dworld.com Yes, applications may need audio/visual input, hence W3C's WG DAP has created an API for accessing audiovisual devices. Created is as yet too past tense for something that's supposed to be documenting practice, of which the only so far is to use Adobe Flash instead of HTML. As there's already a standard for accessing such devices, what value does device add? Per http://dev.w3.org/html5/html-device/ the device element is a way for a page to request permission for its scripts to access a device. Note that it, as a proposal, isn't finalized. I can certainly see the argument for implicit behavior when either input type=... accept=... form elements or real-time javascript streaming interfaces attempt to access a particular device: The same permission request should occur in either case, so why have a separate element for it? And why should this even be a HTML element in the first place, rather than an (JS) API? I don't have a good answer to that. What do others think? input type=file accept=audio/x-speex;quality=(0-10);bitrate=... is more important, and accept=audio/ogg video/x-webm, video/ogg are all fairly important, too. One non-native English writer to another: I beg your pardon? I mean that Speex, Ogg Vorbis, Google VP8/webm, and possibly Ogg Theora if the W3C patent examination staff finds anything wrong with VP8, should be included in form-based device input and upload, ideally, as well as the real-time streaming javascript interface which seems more ephemeral at this point. On the other hand, audio/wav should not be (it is currently referenced in at least one DAP draft document), because it's a minefield union type, and its subtypes are either too high-bandwidth (such as PCM like audio/L16), too low quality (like a-law or mu-law), have such poor compression artifacts, or are of too poor or uncertain encumbrance status to use. I should have written input type=file accept='audio/x-speex;quality=(0-10);bitrate=...;source=microphone' to reflect the newly-announced Android/Firefox placement of the source= parameter. I would like to see something like that for device type=audio per http://dev.w3.org/html5/html-device/#stream-api (This will be pinned down to a specific codec.) But again, I think the issues raised here are good ones and if anyone knows why there is an actual need for a separate device element, please tell me.
[whatwg] Do we really need a device element?
What is the use case for device? I´ve searched the archives, read a thread, Googled around and read a document on the subject, but still I haven´t found a use case for it other than it is going to magically increase user privacy. input type=file accept=audio/* is a standard and compatible way to request audio stream(s). I can´t see any drawbacks to using input for audiovisual streams at least. -- kv, - Bjartur
Re: [whatwg] Do we really need a device element?
Bjartur, real-time streaming audio uploads enable pronunciation assessment for language instruction during multiplayer online roleplaying games such as those by http://www.8dworld.com input type=file accept=audio/x-speex;quality=(0-10);bitrate=... is more important, and accept=audio/ogg video/x-webm, video/ogg are all fairly important, too. On Jun 12, 2010 11:15 AM, Bjartur Thorlacius svartma...@gmail.com wrote: What is the use case for device? I´ve searched the archives, read a thread, Googled around and read a document on the subject, but still I haven´t found a use case for it other than it is going to magically increase user privacy. input type=file accept=audio/* is a standard and compatible way to request audio stream(s). I can´t see any drawbacks to using input for audiovisual streams at least. -- kv, - Bjartur
Re: [whatwg] Do we really need a device element?
On Sat, Jun 12, 2010 at 11:44 PM, Bjartur Thorlacius svartma...@gmail.comwrote: What is the use case for device? I´ve searched the archives, read a thread, Googled around and read a document on the subject, but still I haven´t found a use case for it other than it is going to magically increase user privacy. input type=file accept=audio/* is a standard and compatible way to request audio stream(s). I can´t see any drawbacks to using input for audiovisual streams at least. I would love to see this implementations, This will be helpfull in webbased Screencastings Or SlideCastings Or audio/video telephony
