[whatwg] <video> element feedback

On Tue, 20 Mar 2007, Gareth Hay wrote:
>
> I do fully understand the points you make below, but I am not sure I fully
> subscribe to the logic.
> 
> > <embed> is in HTML5 specifically for plugins.
> > 
> > However, for <embed>, <object>, <iframe>, and <video>, the spec 
> > doesn't require that UAs implement the features using plugins or using 
> > native code. For example, Mozilla natively supports SVG in <embed> (it 
> > doesn't require a plugin). Similarly, you could see <video> be 
> > implemented as a special-case plugin. That's an implementation detail 
> > and doesn't really affect the spec.
> 
> I think we have then arrived at tags-for-everything.
> (<img><video><audio><embed><iframe> cover everything do they not?)

Oh no, there are many more types of media that exist or can exist. <3d>, 
<smell>, <animation>, <tactile>... some media don't exist in digital form 
yet, but they will in due course; others exist in niche markets but may 
become more popular... some simply haven't been thought of yet.


> However, I think if <object> is so widely derided by everyone, than I 
> think it needs to be depreciated sooner rather than later.

I have seriously considered doing this. Unfortunately I don't think we can 
actually do it given the large amount of legacy content, e.g. tutorials 
for how to embed flash which encourage use of <object>.



On Wed, 21 Mar 2007, Lachlan Hunt wrote:
> > 
> > I only included togglePause() because Flash supports it and some 
> > people asked for it; I'm not convinced we should keep it.
> 
> I'm in favour of dropping it.  It's an unnecessary API for browsers to 
> support.  It adds nothing that can't be done with play()/pause() and an 
> if statement.
> 
> if (video.state == HTMLVideoElement.PAUSED) {
>     video.play();
> } else {
>     video.pause();
> }

On Tue, 20 Mar 2007, Jeff Cutsinger wrote:
> 
> +1.

I've commented it out for now. Let's see how many people complain.



On Tue, 20 Mar 2007, Shadow2531 wrote:
> 
> So, if one used <video src="200x200.ogg" style="width: 800px; height: 
> 800px;"></video> , there'd be no way to make the video display at 200 x 
> 200 because it would always scale?

Currently, correct.


> If so, if one wanted to simulate the look I'm describing, would one have 
> to do the following for example?
> 
> <figure style="width: 800px; height: 800px; background: #000;">
>    <video src="200x200.ogg" style="width: 200px; height: 200px;"></video>
> </figure>
> 
> (Just want to be sure.)

Yeah, you could do that.



> I'm thinking more along the lines of a local HTML page that embeds a 
> local video (one of your favorites for example) where when you load the 
> page (via a bookmark or a panel for example), it automatically starts 
> and is set to loop (because you authored it that way).

Well for local content we don't need to worry about interoperability 
(since the user makes it for himself on his user agent), so user agents 
are free to add vendor extensions to do this, or the user could use JS, or 
the user could do something that doesn't involve HTML at all, that's not 
really our problem.


> So, this is all that is needed to do autostart?
> 
> window.onload = function() {
>    document.getElementsByTagName("video")[0].play();
> };

That will do it, yes, assuming the user agent doesn't block it (the spec 
allows that, under use control).


> > > However, if JS is needed for the video element to function at all, 
> > > then the video element needs to fall back if JS is turned off.
> > 
> > Interesting point.
> 
> Yes, since JS is required, if JS is off, the browser should display the 
> alternate content.
> 
> > You can do this with JS, of course (and that's the preferred way; hide 
> > the fallback when you have JS).
> 
> Are you saying that with JS on, the fallback content will be displayed 
> in addition to the video and you have to use JS to hide the fallback 
> content like the following?
>
> window.onload = function() {
>    var x = document.getElementsByTagName("video")[0];
>    x.play();
>    x.innerHTML = "";
> };

No, I meant something like:

   <section id="video">
     <p>You need JavaScript turned on to do video.</p>
   </section>
   <script>
     // clear the fallback
     var v = document.getElementById('video');
     while (v.hasChildNodes) v.removeChild(v.firstChild);

     // get the data to play
     var src = 'video.ogg';

     // create the UI
     default xml namespace = "http://www.w3.org/1999/xhtml";
     var ui = <div>
                <p><video src={src}></video></p>
                <p>
                 <input type="button" value="Play" onclick="vPlay()"/> 
                 <input type="button" value="Pause" onclick="vPause()"/> 
                </p>
              </div>;
     var video = ui..video.domNode();
     function vPlay() { video.play() }
     function vPause() { video.pause() }
     v.appendChild(ui.domNode());

     // start playback
     video.play();
   </script>

Or, probably better:

   <section id="no-js-warning">
     <p>You need JavaScript turned on to do video.</p>
   </section>
   <section id="video">
     <p><video src="video.ogg"></p>
     <p>
       <input type="button" value="Play" onclick="vPlay()"/> 
       <input type="button" value="Pause" onclick="vPause()"/> 
     </p>
   </section>
   <script>
     // clear the fallback
     var f = document.getElementById('no-js-warning');
     f.parentNode.removeChild(f);

     // UI functions
     function vPlay() { video.play() }
     function vPause() { video.pause() }

     // start playback
     video.play();
   </script>
   


On Tue, 20 Mar 2007, Simon Pieters wrote:
> 
> BTW, this would be a lot simpler to do if the src="" attribute was made
> optional:
> 
>    <video><p>fallback</p></video>
>    <script>
>     document.getElementsByTagName("video")[0].src = "foo.ogg";
>    </script>
> 
> I think this should be allowed. Without the src attribute, the video 
> element could represent a placeholder where a video might have been 
> relevant (e.g. if scripting was enabled).

Currently without a src="" attribute the element represents a black 
square. I think that's better than having the entire rendering change when 
you change the src="", no? We could make src="" optional; it's only 
required for consistency with other things in the spec right now. I don't 
really have strong opinions on the requiredness of attributes.



On Tue, 20 Mar 2007, Matthew Ratzloff wrote:
>
> However, two points:
> 
> a) The current API for Video as specified in the WHAT specification 
> applies just as easily to audio, except for videoWidth and videoHeight 
> properties.  What are the barriers to a single element with a common 
> interface?

Well, there are big differences (like, video has an aspect ratio and 
renders video!), but yes, the API could probabl be reused without many 
differences. I'm not adding <audio> yet -- demand doesn't seem as high as 
for <video>, people were asking for <video> independently, but nobody 
asked for <audio> before <video> was considered -- but if we add it I 
assume we will use a similar API.


> b) The element (whatever it becomes) should handle all video, not just
> native video.

That's an implementation detail. Whether support is native, reuses OS 
features, plugins, DLLs, or whatever, makes no difference to the spec.


> Browsers should see if a video is unsupported and show the fallback 
> message, which would contain a link to download the appropriate 
> software.  For example,
> 
> <video src="example.wmv">
>     This is a Windows Media Video file, but you need to download
> such-and-such to display it in your browser.
> </video>

The fallback isn't done that way in the spec today because that kind of 
fallback has been a source of bugs in browsers when it comes to other 
features (e.g. <object>); however, the spec provides the information to 
the script, though 'error' events, so you can achieve the same effect.



On Wed, 21 Mar 2007, Laurens Holst wrote:
> > 
> > I see the need for a standalone element now.
> 
> Why? There is no overloading going on anywhere.

<object> right now is overloaded to do at least four things:

   * inline images
   * plugins
   * nested browsing contexts (iframes)
   * fallback container

...each of which has very distinct behaviour (e.g. whether it has a 
scripting context, whether it shrinkwraps, whether it is replaced or not; 
whether it invokes an external program, what kind of decoder it uses). 
Adding a fifth (inline video with an API) would increase the complexity 
yet again.

<object> is *very badly* implemented. It has been a decade since <object> 
was first created and browsers STILL don't do it right in all cases (or 
even in most cases, frankly). Adding more complexity to such a disaster 
zone is bad design.


> First of all, if one would just take a practical approach and think in 
> terms of solutions instead of impossibilities, you could simply have a 
> property HTMLObject.objectController, which then gets you an object 
> specific to the ?media group?.

It wouldn't be "simply", though. You'd need to define how to determine 
what the media group is, you'd need to define how to change from one type 
to another, you'd need to have browsers implement all this on top of all 
their existing bugs -- sometimes, it's just better to keep things 
separate, even if they seem like they could be abstracted out into one 
concept. We can't ignore our past experiences in designing HTML5.


(Incidentally, this message and the previous one was BCC'ed to everyone 
who wrote e-mails that I took into account when designing the changes to 
the spec. I didn't necessarily actually reply to each one, because many of 
them said the same thing. Apologies for any confusion if you were BCC'ed 
but didn't know why.)

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

Received on Tuesday, 20 March 2007 14:08:37 UTC