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
<svartman95@gmail.com> wrote:
> On 6/12/10, James Salsman <jsalsman@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.

Received on Monday, 14 June 2010 01:37:10 UTC