[whatwg] Do we really need a <device> element?

On 6/14/10, James Salsman <jsalsman at gmail.com> wrote:
> On Sun, Jun 13, 2010 at 6:36 PM, James Salsman <jsalsman at 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 <device>s? 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

Received on Wednesday, 16 June 2010 10:43:46 UTC