[whatwg] HTML 5 : The Youtube response

> On Wed, 2010-06-30 at 18:11 -0700, David Singer wrote:
> > I think it's interesting to look at these and ask to what extent they are in scope.
> >
> > > 1. Standard video format
> > > 2. Robust video streaming
> > > 3. Content Protection
> > > 4. Encapsulation + embedding
> > > 5. Fullscreen video
> > > 6. Camera and Microphone access
> >

> > #4 is soluble 'on top of' HTML5 and the media formats, if needed.  Web Archives, Web Apps, and so on.  I think.
> >
Yes, <iframe>s, <objec>s and <audio>/<video>s should solve the problem of
embedding, and (if I understand the meaning of "Encapsulation" correctly)
<html> wrappers should solve encapsulation as well.

> > #5 is a problem only if you care about phishing attacks...or indeed apps that have the gall to believe that you should be able to see nothing else when they are running.
> >
> 
> We talked about this a week or two ago and the idea was to have a "allow
> full screen" element in the video tag that makes a control that can be
> used by the user to go full screen. The problem here is abuse but I
> think the browser vendors should make some safeguards if this is the
> route they take.
> 
> > #6 is well, rather different from the problem of delivering a/v to a user.  I'm not enthusiastic about web pages that can listen to me or watch me, myself...
> >
Agreed, such access for web pages should be limited to <input
type=file>. That would require the user to "go out of his way" to grossly
violate his privacy rather than "just clicking OK" or being click-jacked
into approving of recording of himself (such as with interactive
JavaScripts and CSS'd images of hot women labeled "Click here for more").

> Camera and mic access could be done in the spec IMO and it would be
> useful. How its implemented would be interesting. For sites like
> hotmail, gmail, youtube(for their webcam capture)..etc that have
> integrated chat it would be very useful. Obviously in terms of
> implementation they would have to safe guard by asking. Id look for
> something as simple as <webcam /> or <mic /> or something and dont have
> any parameters and allow the browser to work out what to do would be ok
> to put in the spec. Its a little bit out there but I think it would be
> beneficial if its a blocker for some sites.
Will <webcam> and <mic> be <form> elements, interactive content that can
go anywhere in a web page? If the latter, what whould HTML renderers
do with it? But you're probably thinking about <device>, save the no
@attrs suggestion.

I for one don't understand why this would be any better than (in the
case of <form> elements) <input type=file accept="video/*"|"audio/*">
and for more complex and esoteric use cases (i.e. "webapps"), the device
APIs from the DAP WG of W3C.

Received on Friday, 2 July 2010 07:57:45 UTC