[whatwg] Some <video> questions

[Ian Hickson]

On Sun, 27 Jan 2008, Charles wrote:
> 
> The <video> element supports width and height.  Does this include the 
> additional area needed (if necessary) by the controls?  It strikes me 
> that it shouldn't, since it would be odd for the video width and height 
> to change when non-video "decorators" are shown/hidden.
> 
> I don't see a "standard" controls height and width, which is fine, but 
> will there be read-only attributes for the width, height and position 
> for controls?

The spec currently doesn't say. I've added an issue marker regarding this, 
but basically the rendering section will define this, based on 
implementation experience.


On Mon, 28 Jan 2008, Charles wrote:
> 
> If users do show the <video> element's controls, are the plug-in's 
> native controls shown?

No, the user agent is expected to provide its own controls, and not expose 
the embedding framework's controls.


> If that's the case, is the expectation that authors will need to 
> temporarily hide controls (or make sure they're already hidden) before 
> getting its height?

The videoHeight attribute can be used to determine the actual native 
height of the video content.


I have omitted a great deal of the remainder of this specification as it 
did not contain actionable feedback on the specification as far as I could 
tell. Please let me know if I missed something.


On Tue, 29 Jan 2008, Charles wrote:
>
> For example:  YouTube embeds SWF files.  Shouldn't that be a <video> 
> element from a semantic POV?  If so, that seems to imply a requirement 
> for the <video> element to be extendable with plug-ins.

<video> would be appropriate for embedding the FLV files used by Flash 
players, but to embed the SWF files, the <embed> element is better suited.


On Tue, 29 Jan 2008, Charles wrote:
> 
> So, my questions remain.  What I'm hearing is that (1) <video> will only 
> be a cross-browser, cross-platform solution for exactly one format -- 
> that freely implementable and royalty free combination of container and 
> compressed video and audio formats -- and that (2) from a design 
> perspective <video> transport controls may be any size (or no size at 
> all if the browser vendor prefers overlays), requiring designers to roll 
> their own if they need controls to be a predictable size.

Correct, except that it's "at least one format", not "exactly one format".


On Tue, 29 Jan 2008, Charles wrote:
> James wrote:
> > Are you looking for a way for plugins, rather than the browser itself, 
> > to handle <video>?
> 
> Yes, with the brower handling handles precendence and event routing, 
> etc.
> 
> Really not terribly different than plug-ins today, but semantically 
> meaningful, straightforward, simple and consistent.

I don't really understand what that would look like. It isn't what <video> 
is currently intended to be, though.


On Tue, 29 Jan 2008, Charles wrote:
> 
> Are Adobe/Microsoft going to be update their Flash/Silverlight browser 
> plug-ins in order to be first-class <video> handlers in Safari on Mac 
> and Windows?

On Tue, 29 Jan 2008, Charles wrote:
> 
> The question is not about what Adobe or Microsoft may or may not do.
> 
> The question is about whether Safari (not to single out one browser) is 
> going to (a) allow 3rd-party browser plug-ins to create support for more 
> formats (b) using the <video> element (c) on the Safari platform.

Yes, the WebKit implementation (Safari implementation) of <video> will 
allow people to provide new codecs to handle new formats.


> Here's a precise scenario:  A user creates an HTML5 page, and of course 
> uses the <video> element to embed their Windows Media content.  They're 
> rude, and could care less about Mac or Linux support.
> 
> Will Safari provide an API that allows Microsoft to support this 
> scenario [...]

Yes, the Windows Safari browser would just use DirectShow to render the 
videos, and DirectShow allows Microsoft to register a new codec to handle 
the Windows Media content.


On Thu, 31 Jan 2008, Christoph Päper wrote:
> 
> Ian, |object| currently has special handling for images, shouldn't videos be
> dealt with similarily (i.e. not create a nested browsing context)?

Since we're introducing <video>, I don't see much reason to go out of our 
way and support video in <object> as well. It would just make things even 
more complicated.


> Also |type="image"| (or 'video') should be enough, without slash and 
> subtype, but I've raised that before.

I imagine I'll get to that feedback when I process the <object> element 
feedback then. :-)


On Thu, 31 Jan 2008, Charles wrote:
> 
> Imagine the QuickTime plug-in being able to register itself with IE's 
> brower as a handler for <video> types that IE otherwise wouldn't handle.  
> That seems like a very desirable thing, but the more we talk the more it 
> seems outside the scope of what HTML5 can solve.

The QuickTime framework can register itself as a codec in DirectShow, 
which would then work in IE.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'