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

On Wed, Jun 16, 2010 at 10:43 AM, Bjartur Thorlacius
<svartman95@gmail.com> wrote:
> On 6/14/10, James Salsman <jsalsman@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 <device>s?

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.

Received on Wednesday, 16 June 2010 20:57:37 UTC