Re: [whatwg] video element not ready for prime time
On Thu, 07 Jun 2012 04:06:10 +0200, Kit Grose k...@iqmultimedia.com.au wrote: On 06/06/2012, at 7:44 AM, Ian Hickson wrote: On Fri, 13 Jan 2012, Kit Grose wrote: I'd argue that while we did receive in WebM a common codec it does not enjoy the sort of universal adoption required to be able to mandate its support in the spec, so on that logic, I think establishing a declarative fallback mechanism is probably required to prevent a situation where you cannot write a robust HTML5 page with video and without resorting to JS. I don't think it's time to give up yet, but maybe I'm overly optimistic... Is there any reason why it wouldn't be prudent to render the content of the video element as HTML if the video cannot be played, given that fallback content in the video element is already supported for legacy browsers in the spec: Content may be provided inside the video element. User agents should not show this content to the user; it is intended for older Web browsers which do not support video, so that legacy video plugins can be tried, or to show text to the users of these older browsers informing them of how to access the video contents. How are legacy UAs without video support appreciably different from a UA with restrictive or limited video support? Surely the author's intent in either case is delivering the content in a different way or delivering appropriate alternate content. Even if we eventually get a common codec (which I—perhaps overly pessimistically—feel is unlikely), authors are already using the video element without supplying whatever that eventual codec will be, and users are suffering without reasonable fallbacks. As it stands, it's almost better (and certainly easier) for authors to default to Flash video and use the existing, declarative fallback behaviour of the object element to use a video element instead. That can't be in the best interest of the open web. This was discussed in the thread HTML 5 video tag questions in 2009: http://lists.w3.org/Archives/Public/public-whatwg-archive/2009Jul/thread.html#msg278 The resource selection algorithm never fails - it simply waits for another source to be inserted - so the the hard part is when to show the fallback content. At the time I was very skeptical of switching back and forth between fallback and trying to load a video as more source elements are added, and I still am. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] video element not ready for prime time
On 06/06/2012, at 7:44 AM, Ian Hickson wrote: On Fri, 13 Jan 2012, Kit Grose wrote: I'd argue that while we did receive in WebM a common codec it does not enjoy the sort of universal adoption required to be able to mandate its support in the spec, so on that logic, I think establishing a declarative fallback mechanism is probably required to prevent a situation where you cannot write a robust HTML5 page with video and without resorting to JS. I don't think it's time to give up yet, but maybe I'm overly optimistic... Is there any reason why it wouldn't be prudent to render the content of the video element as HTML if the video cannot be played, given that fallback content in the video element is already supported for legacy browsers in the spec: Content may be provided inside the video element. User agents should not show this content to the user; it is intended for older Web browsers which do not support video, so that legacy video plugins can be tried, or to show text to the users of these older browsers informing them of how to access the video contents. How are legacy UAs without video support appreciably different from a UA with restrictive or limited video support? Surely the author's intent in either case is delivering the content in a different way or delivering appropriate alternate content. Even if we eventually get a common codec (which I—perhaps overly pessimistically—feel is unlikely), authors are already using the video element without supplying whatever that eventual codec will be, and users are suffering without reasonable fallbacks. As it stands, it's almost better (and certainly easier) for authors to default to Flash video and use the existing, declarative fallback behaviour of the object element to use a video element instead. That can't be in the best interest of the open web. —Kit Grose
Re: [whatwg] video element not ready for prime time
On Fri, Jan 13, 2012 at 6:46 AM, Francis Boumphrey boumphre...@gmail.com wrote: Firstly if I use a video with the src attribute e.g. video src='myvideo.mp4' controls and my user agent does not support the format, all I get (in my versions of Opera and Firefox) is a blank screen. Recent versions of Firefox display a message for the user if the mime type of the video is not supported instead of a blank screen. -- http://www.bluishcoder.co.nz
Re: [whatwg] video element not ready for prime time
On Thu, 12 Jan 2012, Francis Boumphrey wrote: A few comments about the video element from the point of view of an HTML author. Currently it is not particularly useful, and there is nothing to encourage me to use it rather than embed Firstly if I use a video with the src attribute e.g. video src='myvideo.mp4' controls and my user agent does not support the format, all I get (in my versions of Opera and Firefox) is a blank screen. No message (as I would get with embed) and as far as I can see there is no way for me as an author to know that the video is not being played so I cannot code a 'write around'. Right, the spec is written with the assumption that we will eventually have a single standard codec. The option is to make several formats of the same video, e.g. myvideo.mp3, myvideo.mp4, myvideo.ogg etc. and place them in child source elements in the hope that one of the formats will be displayed. Even here I have a problem. In which order does the user-agent check the source files (in Chrome it seems to be in the order in which they are written, but there is no guidance here in the spec. The exact algorithm is described in detail. Essentially it's source order, yes. Also will my user agent down-load the file that it cannot play, thus using up band-width? Enough of it to determine it cannot play it, yes, unless you provide attributes on source for it to determine that it doesn't know the format. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] video element not ready for prime time
On Fri, 13 Jan 2012, Kit Grose wrote: On 13/01/2012, at 4:46 AM, Francis Boumphrey wrote: Firstly if I use a video with the src attribute e.g. video src='myvideo.mp4' controls and my user agent does not support the format, all I get (in my versions of Opera and Firefox) is a blank screen. No message (as I would get with embed) and as far as I can see there is no way for me as an author to know that the video is not being played so I cannot code a 'write around'. I brought up this same concern in Dec 2009 and Hixie seemed to concur: On 9/02/2010, Ian Hickson wrote: Indeed, if we can't get a common codec, the spec as written today is not a particularly good design. If we really can't solve this problem, then we'll have to introduce a declarative way of saying if you can't play any of the videos, here's what I want you to do instead -- but hopefully we won't have to go there. (see http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-February/025028.html) I'd argue that while we did receive in WebM a common codec it does not enjoy the sort of universal adoption required to be able to mandate its support in the spec, so on that logic, I think establishing a declarative fallback mechanism is probably required to prevent a situation where you cannot write a robust HTML5 page with video and without resorting to JS. I don't think it's time to give up yet, but maybe I'm overly optimistic... -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] video element not ready for prime time
On Fri, 13 Jan 2012 01:53:23 +0100, Aryeh Gregor a...@aryeh.name wrote: On Thu, Jan 12, 2012 at 12:46 PM, Francis Boumphrey boumphre...@gmail.com wrote: e.g. video src='myvideo.mp4' controls and my user agent does not support the format, all I get (in my versions of Opera and Firefox) is a blank screen. No message (as I would get with embed) and as far as I can see there is no way for me as an author to know that the video is not being played so I cannot code a 'write around'. Boris answered the rest of your questions, but here's a way to detect errors: data:text/html,!doctype html video src='nonexistent.mp4' controls onerror='alert(error)'/video If you use source, the error event is fired at the source element instead and doesn't bubble (why not?), so you have to put onerror on the source element instead. Or use a capturing event listener. I don't know why UAs don't provide their own error messages, though. They provide error icons for failed image loads. I agree that we should do something, but it would be limited to video controls as audio doesn't have a rendering area at all and for video without controls it could interfere with the scripted interface. For audio controls you could always make the controls look dead of course, to make it more clear that there was a problem. -- Philip Jägenstedt Core Developer Opera Software
[whatwg] video element not ready for prime time
A few comments about the video element from the point of view of an HTML author. Currently it is not particularly useful, and there is nothing to encourage me to use it rather than embed Firstly if I use a video with the src attribute e.g. video src='myvideo.mp4' controls and my user agent does not support the format, all I get (in my versions of Opera and Firefox) is a blank screen. No message (as I would get with embed) and as far as I can see there is no way for me as an author to know that the video is not being played so I cannot code a 'write around'. The option is to make several formats of the same video, e.g. myvideo.mp3, myvideo.mp4, myvideo.ogg etc. and place them in child source elements in the hope that one of the formats will be displayed. Even here I have a problem. In which order does the user-agent check the source files (in Chrome it seems to be in the order in which they are written, but there is no guidance here in the spec. Also will my user agent down-load the file that it cannot play, thus using up band-width? I think these questions need to be resolved before authors will start using video for regular pages. The same comments go for the audio element. Frank Boumphrey
Re: [whatwg] video element not ready for prime time
On 1/12/12 12:46 PM, Francis Boumphrey wrote: and as far as I can see there is no way for me as an author to know that the video is not being played If true, this should be simple to fix. But I would think that there was a way to detect this via the readyState or error properties. In particular, if the error.code is MEDIA_ERR_SRC_NOT_SUPPORTED that would seem to be a strong indication that the format could not be played, right? Even here I have a problem. In which order does the user-agent check the source files (in Chrome it seems to be in the order in which they are written, but there is no guidance here in the spec. http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#concept-media-load-algorithm step 3 says: Otherwise, if the media element does not have a src attribute but has a source element child, then let mode be children and let candidate be the first such source element child in tree order. and same section starting at Otherwise, the source elements will be used; run these substeps: explicitly talks about trying the source elements in document order. So what Chrome is doing is exactly what the spec requires. Also will my user agent down-load the file that it cannot play, thus using up band-width? That's up to the to some extent UA, but I'd think that if you list a type=whatever and the UA doesn't support the type, any sane UA would skip the download. Specifically, see substep 5 of the run these substeps section mentioned above: 5. If candidate has a type attribute whose value, when parsed as a MIME type (including any codecs described by the codecs parameter, for types that define that parameter), represents a type that the user agent knows it cannot render, then end the synchronous section, and jump down to the failed step below. So the only way for a UA to not skip the source is if it doesn't know it can't render the type. -Boris
Re: [whatwg] video element not ready for prime time
On Thu, Jan 12, 2012 at 9:46 AM, Francis Boumphrey boumphre...@gmail.comwrote: In which order does the user-agent check the source files (in Chrome it seems to be in the order in which they are written, but there is no guidance here in the spec. The spec does specify this, and chrome fails to follow the spec. See http://webk.it/75154 for details. Cheers, -a
Re: [whatwg] video element not ready for prime time
On 13/01/2012, at 4:46 AM, Francis Boumphrey wrote: Firstly if I use a video with the src attribute e.g. video src='myvideo.mp4' controls and my user agent does not support the format, all I get (in my versions of Opera and Firefox) is a blank screen. No message (as I would get with embed) and as far as I can see there is no way for me as an author to know that the video is not being played so I cannot code a 'write around'. I brought up this same concern in Dec 2009 and Hixie seemed to concur: On 9/02/2010, Ian Hickson wrote: Indeed, if we can't get a common codec, the spec as written today is not a particularly good design. If we really can't solve this problem, then we'll have to introduce a declarative way of saying if you can't play any of the videos, here's what I want you to do instead -- but hopefully we won't have to go there. (see http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-February/025028.html) I'd argue that while we did receive in WebM a common codec it does not enjoy the sort of universal adoption required to be able to mandate its support in the spec, so on that logic, I think establishing a declarative fallback mechanism is probably required to prevent a situation where you cannot write a robust HTML5 page with video and without resorting to JS. —Kit Grose
Re: [whatwg] video element not ready for prime time
On Thu, Jan 12, 2012 at 12:46 PM, Francis Boumphrey boumphre...@gmail.com wrote: e.g. video src='myvideo.mp4' controls and my user agent does not support the format, all I get (in my versions of Opera and Firefox) is a blank screen. No message (as I would get with embed) and as far as I can see there is no way for me as an author to know that the video is not being played so I cannot code a 'write around'. Boris answered the rest of your questions, but here's a way to detect errors: data:text/html,!doctype html video src='nonexistent.mp4' controls onerror='alert(error)'/video If you use source, the error event is fired at the source element instead and doesn't bubble (why not?), so you have to put onerror on the source element instead. I don't know why UAs don't provide their own error messages, though. They provide error icons for failed image loads.
