Re: <device> proposal (for video conferencing, etc)

On Wed, Dec 16, 2009 at 4:36 PM, Ian Hickson <> wrote:
> On Wed, 16 Dec 2009, Anne van Kesteren wrote:
>> On Wed, 16 Dec 2009 14:22:32 +0100, Andrei Popescu <> wrote:
>> > One reason for this separation is that we want to leave the <input>
>> > tag for form submission. This is all fine but, at the same time, there
>> > are use cases where an application may want a static image from the
>> > camera but may not want to submit any form. So, in such a case, we are
>> > after all misusing the <input> tag?
>> I do not think we should view it that way. Nowadays there are many
>> applications that use <input> without the associated submission semantics it
>> gets when embedded in <form>.
>> The difference with <device> here is that you cannot meaningfully integrate it
>> with the <form> submission model so it makes sense to completely separate it.
> Right.

Ok, I see.

>> > If I understand the example correctly, the video element will show the
>> > output of the user's camera (i.e. act as an embedded camera viewport).
>> > To be able to implement video chat, we also need a way to see the
>> > remote party, so we need a way to send the Stream over to some server.
>> >  I think we should specify the mechanism for doing that (e.g.
>> > WebSockets::send(Stream stream)).
>> I believe this is the plan yes, if the general proposal can be made to work.
> Indeed. The problem is that this requires a chosen codec, and we don't
> have one. That's why I stopped where I did.

Perhaps I am missing something, but this requirement isn't entirely
obvious to me :) Why do we need to agree on a codec any more than we
needed for the <video> tag? I agree that it would be ideal if we did
but, based on previous experience, that seems unlikely to happen.


Received on Wednesday, 16 December 2009 17:42:47 UTC