Re: [whatwg] HTML 5 video tag questions
On Tue, 14 Jul 2009, Robert O'Callahan wrote: There's actually a fairly major related problem here. We hide the fallback content by treating it as display:none. Currently Gecko has a huge bug where a display:none plugin does not load/run. This works out well for the video fallback case. If we fix that bug, then unless we do some special magic, plugin-based video fallback will run and play audio while the video element plays --- very bad. Fixed. Note: iframes as video descendants still load, and if those pages contain embed, object, or applets, they will load. Also, nested videos or audios will load, including when in the fallback content of object. All I stopped is object, embed, and applet, when descendants of video, audio, or active objects. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML 5 video tag questions
On Tue, 14 Jul 2009, Philip Jägenstedt wrote: Ian: can you make nested video elements non-conforming so that validators will flag it? This would be helpful regardless of the fallback discussion. Done. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML 5 video tag questions
There were some proposals to change video's fallback model to allow markup to be used as an alternative to a video stream, so that once the various alternative videos had been tried, the user agent would make video act as a regular display:block element and no longer act as a video viewport. I haven't changed video to do this, for the following reasons: * We tried this with object and we had years of pain. I'm not at all convinced that we wouldn't have the same problems here again. * We won't need fallback as soon as we resolve the common codec issue, which is still being worked on. I don't think we should redesign the model to address a transient problem in the platform. * This model would either have to make video not dynamic -- once you fail to load a video, you can no longer use it, because it's showing fallback -- or would require us to introduce yet more state to keep track of whether we should be displaying fallback or not. * If it's not dynamic, we'd have to define what happens when you use the API when the fallback is being shown. Especially for cases like off- page audio, this would lead to a quite confusing authoring experience. * We'd need to have an explicit way of triggering the behaviour for source, given the way the media loading algorithm works. * It's a change, and I really would like to put the brakes on the number of non-critical changes we make. When the element was designed, we explicitly didn't do this -- that's why we have source, and is why the fallback is explicitly intended for legacy user agents, and not user agents that don't support the given videos. Which is to say, we didn't accidentally stumble into this design. All in all, I'm very skeptical that this is a good idea. What's more, any solution would almost certainly involve scripting anyway, and once you're doing things with script, it's really trivial to do the fallback manually, especially with all the hooks video provides, so the use cases don't seem that compelling. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML 5 video tag questions
On Wed, Jul 15, 2009 at 8:58 PM, Maciej Stachowiakm...@apple.com wrote: On Jul 14, 2009, at 3:43 AM, Robert O'Callahan wrote: On Tue, Jul 14, 2009 at 10:42 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Jul 14, 2009 at 10:34 PM, Jonas Sicking jo...@sicking.cc wrote: We can do what's described above for videos and audios too (i.e. walk parent chain etc). We can hack something in, but what about dynamic DOM changes? IFRAME loads? etc More importantly for this list, what should the spec say? Clearly the desirable end result is that a video or audio element with fallback to an object or embed should not load or play the fallback content. I'm not sure how to spec this in a rigorous and consistent way. - Maciej Is there some halfway-decent way to treat it like a comment? That's the other instance that I know of that content is completely ignored. How does that work internally? ~TJ
Re: [whatwg] HTML 5 video tag questions
On Mon, 13 Jul 2009 23:32:44 +0200, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Jul 13, 2009 at 4:01 PM, Philip Jägenstedtphil...@opera.com wrote: I thought you meant video source fallback fallback content here /source /video I would prefer if fallback content and source elements weren't mixed on the same level, but maybe that's just me. Eh, fallback content for non-video browsers is already there, so it's nothing new. (You could also just put @fallback on the second source and drop the third source entirely for the same effect.) Once the source element is iterated by the resource selection algorithm and starts loading, the fallback attribute or the whole source element might be removed. You would have to set a flag at some point to remember the fallback state and unset it... when? What is the effect of video source fallback source src=cant.play.ogg fallback here /video ? It would hit the first source, note that there's no @src, see that there is @fallback, and immediately drop to showing fallback content. Is fallback irrevocable or could the same video element go back to showing video under some circumstances? It should be revocable in the exact same circumstances that a video element might start playing from one source, and then switch to another. From my reading of the algorithm I don't think this is possible, so fallback would be irrevocable. Right, anything but irrevocable fallback would make this even stranger than object fallback. Let's not go there. Does audio also have fallback content? It uses source and the same source-selection algorithm (and the same fallback situation in the case of non-audio browsers), so yes. This is why I suggested videosource src=cant.play.oggnew-fallback-elementOoops!/new-fallback-element/video I still think the use of this is questionable though. I'm not sure why you think the usecase is questionable. It seems pretty clear - it'd be nice to have a non-script way of showing content (specifically, alternate video players) when the browser supports video but can't play any of the provided sources. Yes, handling the (minor) use case video support + no supported source + no script would be nice, but only if it doesn't make an even bigger mess of the resource selection algorithm and doesn't allow switching back and forth between video and fallback. From what I can tell of the resource selection algorithm, fallback should be irrevocable, just like a successful source load is. The resource selection algorithm appears to need fairly trivial changes to accommodate this. Step 4, when parsing @src from video, insert a new substep between substeps 2 and 3. Pull the first sentence from the current substep 3 into this new substep, and say something like If the element has a fallback attribute, abort this algorithm immediately and display the fallback content. When parsing See below for why we can't put the fallback attribute on the video element. source elements, change step 3 so that whenever any of those conditions are met, if the source has @fallback the algorithm aborts immediately and shows the fallback content, otherwise it fires the error event and jumps to the search loop step as normal. This would only cause fallback to be used when the source element is rejected up front, not if it is a candidate for the resource fetch algorithm that fails to fetch/play. So you also need to check @fallback before step 6. However, by then the source element may very well be removed from the DOM, so I you'd have to assign @fallback to a variable earlier in the algorithm and check that. This approach is implementable in my guesstimation, but I'd really want to know more about the history of object fallback issues. Should fallback content be treated as if it were display:none, or are there nastier hacks involved? Alternately, we could just put @fallback always on the video element directly, rather than on source. That would preserve the first part of what I said, but now we have a step between substeps 9 and 10 that checks for @fallback on the video. If it finds it, it immediately aborts and shows the fallback content, otherwise substep 10 proceeds normally (waiting forever). That would cause the fallback to be triggered unconditionally during parsing: video fallback source src=foo type=video/x-unsupported !-- steps 8-10 run here -- source src=bar type=video/x-supported /video There's nothing in the resource selection algorithm that's special-cased for static markup by hooking into the parser, which would be required to make it work (but then only for static markup). Putting @fallback on the video element just won't work. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] HTML 5 video tag questions
On Mon, 13 Jul 2009 17:23:47 -0400, Michael A. Puls II
shadow2...@gmail.com wrote:
On Mon, 13 Jul 2009 17:01:26 -0400, Philip Jägenstedt
phil...@opera.com wrote:
Does audio also have fallback content?
With audio, you can set its display to 'none' and the audio will still
play. However, if its display is set to 'none' and the element were to
fall back to a child object element that loads a plug-in, things
wouldn't work because plug-ins don't work with a display of 'none'.
You would then have to detect that audio fell back so you could set
its display to inline-block for example so the fallback plug-in would
actually load. Or, there'd have to be a new css selector to handle this
like audio::fallback_state { display: inline-block} or a parent selector
on the child object element that was only applied when audio fell back
to it. Or, the browser would have to make plug-in objects that are
descendants of an audio element work with a display of 'none'.
The same applies to video if you want to set its display to 'none' and
just hear the audio.
I realize that this is also a problem for fallback in browsers that don't
support video and audio. So, it's not specific to falling back in
browser that *do* support them.
--
Michael
Re: [whatwg] HTML 5 video tag questions
On Mon, 13 Jul 2009 23:28:41 +0200, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Jul 13, 2009 at 5:01 AM, Philip Jägenstedtphil...@opera.com
wrote:
The design you describe is what object tried to do, and it proved
to be
extremely problematic in practice -- and that was without another
built-in
fallback mechanism to complicate matters.
While object has had a very poor implementation story, I don't think
this was a big reason for that.
Robert O'Callahan, Boris Zbarsky and other gecko layout folks can
answer this better, but at least in gecko I don't think this part of
object was particularly hard to implement correctly once we actually
tried.
Has any browser vendor argued against displaying the fallback due to
high implementation burden?
Implementation probably isn't the biggest burden here, specifying sane
behavior is. For example:
If fallback content is displayed after the last source element has
failed,
what should happen when a new source element is inserted? Switching
back to
video mode would make it even more special than object fallback and
if you
don't you'll just get stuck with fallback and have effectively broken
the
possibility of inserting source elements via scripts.
Something like videosource
src=cant.play.oggnew-fallback-elementOoops!/new-fallback-element/video
is what you'd need to make the resource selection algorithm deal with
fallback in a sane way when scripts are disabled, but this is too much
of a
corner case to justify the complexity in my opinion.
I think fallback contents is simply defined as the contents of the
video, minus any source elements (which wouldn't render anyway).
No need for new-fallback-element.
If I may nit-pick, the spec explicitly says this content is not fallback
content. But your suggestion is to change is, so very well...
The simplest solution would be to display the fallback when there
aren't any source (or @src) elements being either displayed or
waiting to load. I think spec-wise the simplest thing would be to
display fallback when
The networkState of the element is NETWORK_NO_SOURCE.
This way even incremental rendering of the fallback contents would
work fine. The only case that's weird is markup like:
video
lots and lots of fallback here
source src=...
/video
There is a risk that content would be displayed, and then switch to
displaying video. This doesn't seem like a big problem as it seems
more likely that people will put the source first. And if someone
doesn't the effects aren't very bad.
Alternatively we could use the following rules:
1. The networkState of the element is NETWORK_NO_SOURCE.
*and*
2. The video element is fully parsed. I.e. it has been removed from
the stack of open elements.
This would mean that incremental rendering doesn't work. This doesn't
seem any worse than what we have now when fallback is never displayed.
Though I think it'd work fine always display fallback whenever the
networkState is NETWORK_NO_SOURCE.
/ Jonas
Anything that can cause the element to switch back and forth between
displaying fallback and video is a no-go, that would cause a race
condition for if plugins/images in the fallback content. If they have
event handlers the results will get ugly fast:
video
!-- network lag --
source
!-- network lag --
source
!-- network lag --
img src=foo onload=alert('how many times will you see this message?')
/video
--
Philip Jägenstedt
Core Developer
Opera Software
Re: [whatwg] HTML 5 video tag questions
Philip Jägenstedt wrote:
Anything that can cause the element to switch back and forth between
displaying fallback and video is a no-go, that would cause a race
condition for if plugins/images in the fallback content. If they have
event handlers the results will get ugly fast:
video
!-- network lag --
source
!-- network lag --
source
!-- network lag --
img src=foo onload=alert('how many times will you see this message?')
/video
The answer to the question in the alert is once. This is true in the
current fallback model, and would presumably be true in the new fallback
model.
For the current model, note that all the text says is should not show
this content to the user. While this is not defined anywhere, it
doesn't seem to indicate that the content's DOM should not exist, for
example. In Gecko, at least, the image in your example will be loaded
and hence its onload will fire.
-Boris
Re: [whatwg] HTML 5 video tag questions
On Tue, Jul 14, 2009 at 9:46 PM, Boris Zbarsky bzbar...@mit.edu wrote: For the current model, note that all the text says is should not show this content to the user. While this is not defined anywhere, it doesn't seem to indicate that the content's DOM should not exist, for example. In Gecko, at least, the image in your example will be loaded and hence its onload will fire. There's actually a fairly major related problem here. We hide the fallback content by treating it as display:none. Currently Gecko has a huge bug where a display:none plugin does not load/run. This works out well for the video fallback case. If we fix that bug, then unless we do some special magic, plugin-based video fallback will run and play audio while the video element plays --- very bad. People have already discovered that video src=hellokitty.ogvobject data=hellokitty.ogv/object/video plays the audio track twice in Firefox, and aren't happy about it, although it's what the spec seems to suggest. I'm not sure how to modify the spec in a sane way to fix this case, though. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] HTML 5 video tag questions
On Tue, Jul 14, 2009 at 3:05 AM, Robert O'Callahanrob...@ocallahan.org wrote: On Tue, Jul 14, 2009 at 9:46 PM, Boris Zbarsky bzbar...@mit.edu wrote: For the current model, note that all the text says is should not show this content to the user. While this is not defined anywhere, it doesn't seem to indicate that the content's DOM should not exist, for example. In Gecko, at least, the image in your example will be loaded and hence its onload will fire. There's actually a fairly major related problem here. We hide the fallback content by treating it as display:none. Currently Gecko has a huge bug where a display:none plugin does not load/run. This works out well for the video fallback case. If we fix that bug, then unless we do some special magic, plugin-based video fallback will run and play audio while the video element plays --- very bad. It shouldn't be that hard to for plugins walk the parent chain to see if there are any active video elements before starting the plugin. People have already discovered that video src=hellokitty.ogvobject data=hellokitty.ogv/object/video plays the audio track twice in Firefox, and aren't happy about it, although it's what the spec seems to suggest. I'm not sure how to modify the spec in a sane way to fix this case, though. We can do what's described above for videos and audios too (i.e. walk parent chain etc). / Jonas
Re: [whatwg] HTML 5 video tag questions
On Tue, Jul 14, 2009 at 10:34 PM, Jonas Sicking jo...@sicking.cc wrote: We can do what's described above for videos and audios too (i.e. walk parent chain etc). We can hack something in, but what about dynamic DOM changes? IFRAME loads? etc Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] HTML 5 video tag questions
On Tue, Jul 14, 2009 at 10:42 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Tue, Jul 14, 2009 at 10:34 PM, Jonas Sicking jo...@sicking.cc wrote: We can do what's described above for videos and audios too (i.e. walk parent chain etc). We can hack something in, but what about dynamic DOM changes? IFRAME loads? etc More importantly for this list, what should the spec say? Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] HTML 5 video tag questions
On Tue, 14 Jul 2009 11:46:08 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
Philip Jägenstedt wrote:
Anything that can cause the element to switch back and forth between
displaying fallback and video is a no-go, that would cause a race
condition for if plugins/images in the fallback content. If they have
event handlers the results will get ugly fast:
video
!-- network lag --
source
!-- network lag --
source
!-- network lag --
img src=foo onload=alert('how many times will you see this
message?')
/video
The answer to the question in the alert is once. This is true in the
current fallback model, and would presumably be true in the new fallback
model.
For the current model, note that all the text says is should not show
this content to the user. While this is not defined anywhere, it
doesn't seem to indicate that the content's DOM should not exist, for
example. In Gecko, at least, the image in your example will be loaded
and hence its onload will fire.
True, but you could easily have other things in the fallback content (like
mouse listeners) that are suddenly being triggered even though the
fallback content isn't going to be used. No switching back and forth,
please.
I've discussed the object fallback a bit with a knowledgeable colleague
who confirmed that we've had lots of problems with it. Uncertain state of
the fallback content from a scripts point of view is one issue. What to do
with nested objects (when to load/unload them) is another.
If we allow fallback people will certainly begin using nested video,
unless we want to another hack to prevent that.
Ian: can you make nested video elements non-conforming so that
validators will flag it? This would be helpful regardless of the fallback
discussion.
--
Philip Jägenstedt
Core Developer
Opera Software
Re: [whatwg] HTML 5 video tag questions
On Tue, Jul 14, 2009 at 5:05 AM, Robert O'Callahanrob...@ocallahan.org wrote: On Tue, Jul 14, 2009 at 9:46 PM, Boris Zbarsky bzbar...@mit.edu wrote: For the current model, note that all the text says is should not show this content to the user. While this is not defined anywhere, it doesn't seem to indicate that the content's DOM should not exist, for example. In Gecko, at least, the image in your example will be loaded and hence its onload will fire. There's actually a fairly major related problem here. We hide the fallback content by treating it as display:none. Currently Gecko has a huge bug where a display:none plugin does not load/run. This works out well for the video fallback case. If we fix that bug, then unless we do some special magic, plugin-based video fallback will run and play audio while the video element plays --- very bad. People have already discovered that video src=hellokitty.ogvobject data=hellokitty.ogv/object/video plays the audio track twice in Firefox, and aren't happy about it, although it's what the spec seems to suggest. I'm not sure how to modify the spec in a sane way to fix this case, though. How do y'all currently handle noscript content in a context that allows scripts? What if there was a video or object in the noscript? ~TJ
Re: [whatwg] HTML 5 video tag questions
On Tue, Jul 14, 2009 at 3:29 AM, Philip Jägenstedtphil...@opera.com wrote: On Mon, 13 Jul 2009 23:32:44 +0200, Tab Atkins Jr. jackalm...@gmail.com wrote: source elements, change step 3 so that whenever any of those conditions are met, if the source has @fallback the algorithm aborts immediately and shows the fallback content, otherwise it fires the error event and jumps to the search loop step as normal. This would only cause fallback to be used when the source element is rejected up front, not if it is a candidate for the resource fetch algorithm that fails to fetch/play. So you also need to check @fallback before step 6. However, by then the source element may very well be removed from the DOM, so I you'd have to assign @fallback to a variable earlier in the algorithm and check that. Ah, yes, you're right. You'd have to check for @fallback at the end of substep 2 (those subsubsteps are guaranteed atomic, so no race condition) and set a flag, then actually activate fallback if the algorithm fails at step 3 or 6. This approach is implementable in my guesstimation, but I'd really want to know more about the history of object fallback issues. Should fallback content be treated as if it were display:none, or are there nastier hacks involved? As others note in emails following yours, there are already issues with the existing defined fallback content. Once those are successfully resolved, I believe it should work fine for here as well. Successfully resolving them, though, will almost certainly require nastier hacks. Alternately, we could just put @fallback always on the video element directly, rather than on source. That would preserve the first part of what I said, but now we have a step between substeps 9 and 10 that checks for @fallback on the video. If it finds it, it immediately aborts and shows the fallback content, otherwise substep 10 proceeds normally (waiting forever). That would cause the fallback to be triggered unconditionally during parsing: video fallback source src=foo type=video/x-unsupported !-- steps 8-10 run here -- source src=bar type=video/x-supported /video There's nothing in the resource selection algorithm that's special-cased for static markup by hooking into the parser, which would be required to make it work (but then only for static markup). Putting @fallback on the video element just won't work. Sorry, I assumed that checking it at step 10 *did* effectively special-case static markup. I assume that I'm wrong because the delay could just be due to the network/parser being slow at receiving and adding the source elements that are supposed to be in the the static document? If so, then yeah, you're right. @fallback can only be placed on video @src, but not when source elements are involved. ~TJ
Re: [whatwg] HTML 5 video tag questions
On Tue, Jul 14, 2009 at 9:02 AM, Simon Pieterssim...@opera.com wrote: On Tue, 14 Jul 2009 14:51:42 +0200, Tab Atkins Jr. jackalm...@gmail.com wrote: How do y'all currently handle noscript content in a context that allows scripts? What if there was a video or object in the noscript? noscript is parsed as a CDATA element in the HTML parser when scripting is enabled. Any tags would be interpreted as text. This is not the case for object or video because it's ugly and doesn't work in XHTML. You'll notice that noscript is not allowed in XHTML5. Hrm, that's no good then. *Something* has to be done about it, though, because just display:none'ing the fallback content doesn't allow legacy video clients to be tried, which the spec explicitly mentions (and just plain makes sense anyway - without it, video adoption will be substantially slower). We need *some* way to indicate that particular elements aren't to be activated at all in certain circumstances. On a side note, does the old objectembed/ trick work only because the browsers that support that use of object don't support that use of embed, and vice versa? So even though the embed is parsed in an object-supporting browser, it doesn't activate? If so, then it seems like our problem is *too much* interop now. ^_^ ~TJ
Re: [whatwg] HTML 5 video tag questions
On Mon, 15 Jun 2009 jjcogliati-wha...@yahoo.com wrote: Maybe to make this more clear section 4.8.7.1 should add a sentence somewhere like: | Authors may provide multiple source elements to provide different | codecs for different user agents. That section no longer exists. On Tue, 16 Jun 2009, Sam Dutton wrote: Could multiple source elements also be used to provide different bit-rate sources (or even alternative versions, e.g. different languages) as well as different codecs, something like the HTTP streaming playlist idea? On Tue, 16 Jun 2009, Benjamin M. Schwartz wrote: If the browser decides that a video is too high resolution and cannot be played on this system, then why can't it fall through to a lower-resolution copy if one exists? The user agent is allowed to skip past a video file it deems unsuitable, but as currently written, the algorithm precludes the user agent skipping past a resource based on the presence or absence of a further resource that it deems superior. On Tue, 16 Jun 2009, David Singer wrote: [...] there are media queries, and I have posted a couple of times that we should considering allowing source selection based on accessibility needs. we should probably also make it possible to select on language, it's a common need. Localisation in general of HTML isn't supported at the moment; it's assumed that this will be done server-side. (I don't see why we'd support localisation of video and audio media when we don't support localisation of text or images yet). On Fri, 10 Jul 2009, Jonas Sicking wrote: Hmm.. is that good? What if you want to use an object (to use flash or java) or a img as fallback? Then you do it with script. The design is based around the assumption that we will eventually find a common codec so that fallback won't ever be needed in supporting UAs. I agree that the current design makes sense once there is a common codec supported across all browsers. However currently it seems like we might not reach that point until after all major browsers support video. What would be the downside of displaying the fallback contents if none of the videos can be displayed due to unsupported codecs? When would you fall back? For example, while parsing, would you fall back in between the video element being parsed and the first source element being parsed? The design you describe is what object tried to do, and it proved to be extremely problematic in practice -- and that was without another built-in fallback mechanism to complicate matters. On Fri, 10 Jul 2009, Jeff Walden wrote: The design is based around the assumption that we will eventually find a common codec so that fallback won't ever be needed in supporting UAs. So has anyone ever actually pointed out the elephant in the room here, that we might never do so? I can't remember if so. Maybe HTML5: Galaxy Quest (cf. Captain Taggart's line) just isn't going to happen in the foreseeable future. In practice, as people keep pointing out to me, it's only Apple that supports video but doesn't support Theora. If people really want to push Apple into supporting Theora, the best way to do it would be to just keep using it as if it was the common codec, and _not_ provide another fallback for video-supporting UAs -- then things would work fine it non-video- supporting UAs like IE (through fallback flash support inside video), and would work fine in Theora-supporting UAs, but Safari would be left in the cold. On Fri, 10 Jul 2009, Jeff Walden wrote: (I'm also not convinced that we substantially hurt ourselves by making fallback content the final source.) I also think that would make more sense. Right now if a site wants to publish Ogg-only with Cortado as the fallback, they have to use scripting to make it work in Safari. Not supporting Safari would be an effective way of pressuring Apple. And if a site wants to publish H.264-only with Flash or QuickTime as the fallback, they have to use scripting to make it work in Firefox. We presumably don't want to make the use of uncumbered codecs easier. Sites might want to do this even if there were an agreed-upon common codec that simply didn't meet their needs. So a common codec won't completely eliminate this issue. I can't see any advantage to the current design. Sanity and simplicity in implementation is the main advantage. With object, fallback proved to be a huge source of bugs for years. On Sat, 11 Jul 2009, Maciej Stachowiak wrote: There is likely an upper bound set by the maximum possible expiration date of any patents applying to any of the viable candidates. It's just that we'd like to reach agreement well before then. On Sat, 11 Jul 2009, Gregory Maxwell wrote: Not really, at some point well before then the argument will shift to a newer clearly superior to H.264 encumbered format. I would expect that H.264 would spend a
Re: [whatwg] HTML 5 video tag questions
On Jul 12, 2009, at 11:20 PM, Ian Hickson wrote: The design of video from the ground up is based on the idea that in browsers that support the element, the API will be used. If we change this assumption, then the entire design of the element would have to be reconsidered -- in particular, I think we would need to find a way to avoid people having to implement the script side twice, in such a scenario. We don't get a consistent design if we change the assumptions at the slightest provocation. In practice I don't think that the assumption is wrong on the long term, though it may be tested on the short term. video supports fallback to content that almost certainly has a very different API, in browsers that don't support video at all. I'm not sure why it would require major changes in the design to do such fallback in browsers that support video, but not the requested codec. It's true that it may be necessary to have multiple paths in your script if you use video that way. But you have to do that anyway, if you want to support browsers that don't have video at all. And in the case where you just want to embed a video using the best mechanism available, without scripting, the current design makes things harder. I think this argument holds up even if there is an agreed baseline - not everyone may want to use it, especially as the state of the art in video compression improves and higher resolution videos become more popular. I don't think this is an urgent issue, because we probably still have time to change. But I think the spec took the wrong path here and your argument above is not very persuasive. Regards, Maciej
Re: [whatwg] HTML 5 video tag questions
On 12.7.09 23:20, Ian Hickson wrote: If people really want to push Apple into supporting Theora, the best way to do it would be to just keep using it as if it was the common codec, and _not_ provide another fallback forvideo-supporting UAs -- then things would work fine it non-video- supporting UAs like IE (through fallback flash support insidevideo), and would work fine in Theora-supporting UAs, but Safari would be left in the cold. I'm fine doing this for myself: partly because it's pressure on Apple; perhaps mostly because I choose to make embedding videos that I can watch in-browser easy for myself, and because I don't particularly care if some portions of my audience are unable to see such videos and also choose not to download a browser that will display them (fallback content provides a download link -- I haven't made the effort to handle Safari4-sans-XiphQT yet, see supra). That said, my position will be uncommon, and I'm not particularly interested in making use of video right now harder for those who don't share it -- even if it comes at the expense of added pressure on Apple. Jeff
Re: [whatwg] HTML 5 video tag questions
On Sun, Jul 12, 2009 at 11:20 PM, Ian Hicksoni...@hixie.ch wrote: On Fri, 10 Jul 2009, Jonas Sicking wrote: Hmm.. is that good? What if you want to use an object (to use flash or java) or a img as fallback? Then you do it with script. The design is based around the assumption that we will eventually find a common codec so that fallback won't ever be needed in supporting UAs. I agree that the current design makes sense once there is a common codec supported across all browsers. However currently it seems like we might not reach that point until after all major browsers support video. What would be the downside of displaying the fallback contents if none of the videos can be displayed due to unsupported codecs? When would you fall back? For example, while parsing, would you fall back in between the video element being parsed and the first source element being parsed? You could display the fallback once you've reached the /video and not found an acceptable source. Technically it'd be when you pop the video element off the stack of open elements. I don't even think it'd be hard to pull down all sources and check that none of them are supported before displaying the fallback if types aren't specified on the source element. The design you describe is what object tried to do, and it proved to be extremely problematic in practice -- and that was without another built-in fallback mechanism to complicate matters. While object has had a very poor implementation story, I don't think this was a big reason for that. Robert O'Callahan, Boris Zbarsky and other gecko layout folks can answer this better, but at least in gecko I don't think this part of object was particularly hard to implement correctly once we actually tried. Has any browser vendor argued against displaying the fallback due to high implementation burden? / Jonas
Re: [whatwg] HTML 5 video tag questions
On Mon, 13 Jul 2009 11:14:21 +0200, Jonas Sicking jo...@sicking.cc wrote: On Sun, Jul 12, 2009 at 11:20 PM, Ian Hicksoni...@hixie.ch wrote: On Fri, 10 Jul 2009, Jonas Sicking wrote: Hmm.. is that good? What if you want to use an object (to use flash or java) or a img as fallback? Then you do it with script. The design is based around the assumption that we will eventually find a common codec so that fallback won't ever be needed in supporting UAs. I agree that the current design makes sense once there is a common codec supported across all browsers. However currently it seems like we might not reach that point until after all major browsers support video. What would be the downside of displaying the fallback contents if none of the videos can be displayed due to unsupported codecs? When would you fall back? For example, while parsing, would you fall back in between the video element being parsed and the first source element being parsed? You could display the fallback once you've reached the /video and not found an acceptable source. Technically it'd be when you pop the video element off the stack of open elements. I don't even think it'd be hard to pull down all sources and check that none of them are supported before displaying the fallback if types aren't specified on the source element. It would have to be part of the resource selection algorithm. Since that waits for new source elements indefinitely, when exactly would you decide to switch to fallback content? Bad solutions include special-casing static markup and/or (falsely) assuming that scripts will not insert more source elements at some point. If fallback content is defined simply as the content of the video element I also can't figure out any other solutions. The design you describe is what object tried to do, and it proved to be extremely problematic in practice -- and that was without another built-in fallback mechanism to complicate matters. While object has had a very poor implementation story, I don't think this was a big reason for that. Robert O'Callahan, Boris Zbarsky and other gecko layout folks can answer this better, but at least in gecko I don't think this part of object was particularly hard to implement correctly once we actually tried. Has any browser vendor argued against displaying the fallback due to high implementation burden? Implementation probably isn't the biggest burden here, specifying sane behavior is. For example: If fallback content is displayed after the last source element has failed, what should happen when a new source element is inserted? Switching back to video mode would make it even more special than object fallback and if you don't you'll just get stuck with fallback and have effectively broken the possibility of inserting source elements via scripts. Something like videosource src=cant.play.oggnew-fallback-elementOoops!/new-fallback-element/video is what you'd need to make the resource selection algorithm deal with fallback in a sane way when scripts are disabled, but this is too much of a corner case to justify the complexity in my opinion. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] HTML 5 video tag questions
2009/7/13 Ian Hickson i...@hixie.ch: On Fri, 10 Jul 2009, Jeff Walden wrote: And if a site wants to publish H.264-only with Flash or QuickTime as the fallback, they have to use scripting to make it work in Firefox. We presumably don't want to make the use of uncumbered codecs easier. I agree. Moreover there are already two stable and widely used browsers that implement the current spec and websites are starting to use it. Since this fallback would be an incompatible change, please don't do it unless there's a *really* good reason for it. -- Lino Mastrodomenico
Re: [whatwg] HTML 5 video tag questions
2009/7/13 Jeff Walden jwalden+wha...@mit.edu: On 12.7.09 23:20, Ian Hickson wrote: If people really want to push Apple into supporting Theora, the best way to do it would be to just keep using it as if it was the common codec, and _not_ provide another fallback forvideo-supporting UAs -- then things would work fine it non-video- supporting UAs like IE (through fallback flash support insidevideo), and would work fine in Theora-supporting UAs, but Safari would be left in the cold. I'm fine doing this for myself: partly because it's pressure on Apple; perhaps mostly because I choose to make embedding videos that I can watch in-browser easy for myself, and because I don't particularly care if some portions of my audience are unable to see such videos and also choose not to download a browser that will display them (fallback content provides a download link -- I haven't made the effort to handle Safari4-sans-XiphQT yet, see supra). That said, my position will be uncommon, and I'm not particularly interested in making use of video right now harder for those who don't share it -- even if it comes at the expense of added pressure on Apple. In Wikimedia's case, we do care about the user experience, *but* will only be using Theora for the foreseeable future - H.264 is not an option. So browsers with Theora in video should Just Work, browsers without video will get the Java player or an in-browser plugin (and a note suggesting a browser that does Theora in video) and Safari is a nuisance because it's the exception and it *might* work but it *might* not and we have to reliably detect whether it does. (Presumably Apple would be happier with us suggesting XiphQT rather than suggesting Firefox!) iPhone Safari users (does iPhone Safari support video yet?) are, unfortunately, out in the cold until someone writes a Wikimedia client app that does Theora for them. That won't be us unless a volunteer steps up. Other phone users are likely out in the cold too (I don't know of any phones that support arbitrary Java applets in the browser). - d.
Re: [whatwg] HTML 5 video tag questions
Philip Jägenstedt wrote: It would have to be part of the resource selection algorithm. Since that waits for new source elements indefinitely, when exactly would you decide to switch to fallback content? Bad solutions include special-casing static markup and/or (falsely) assuming that scripts will not insert more source elements at some point. If fallback content is defined simply as the content of the video element I also can't figure out any other solutions. A source that says use the content? -Boris
Re: [whatwg] HTML 5 video tag questions
On Mon, Jul 13, 2009 at 1:33 PM, Boris Zbarskybzbar...@mit.edu wrote: Philip Jägenstedt wrote: It would have to be part of the resource selection algorithm. Since that waits for new source elements indefinitely, when exactly would you decide to switch to fallback content? Bad solutions include special-casing static markup and/or (falsely) assuming that scripts will not insert more source elements at some point. If fallback content is defined simply as the content of the video element I also can't figure out any other solutions. A source that says use the content? -Boris Ie inserting source fallback or source contents. If both @src and @fallback are specified on a source, it is treated like a source srcsource fallback; that is, it first tries the @src attribute, and if that doesn't work, then it goes to the fallback content. ~TJ
Re: [whatwg] HTML 5 video tag questions
On Mon, 13 Jul 2009 20:38:11 +0200, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Jul 13, 2009 at 1:33 PM, Boris Zbarskybzbar...@mit.edu wrote: Philip Jägenstedt wrote: It would have to be part of the resource selection algorithm. Since that waits for new source elements indefinitely, when exactly would you decide to switch to fallback content? Bad solutions include special-casing static markup and/or (falsely) assuming that scripts will not insert more source elements at some point. If fallback content is defined simply as the content of the video element I also can't figure out any other solutions. A source that says use the content? -Boris Ie inserting source fallback or source contents. If both @src and @fallback are specified on a source, it is treated like a source srcsource fallback; that is, it first tries the @src attribute, and if that doesn't work, then it goes to the fallback content. That would require the parser to inspect an attribute to determine if the element is a void element (one that does not have a closing tag) or not, which I've been told is not very nice. Are there any other such cases? This is why I suggested videosource src=cant.play.oggnew-fallback-elementOoops!/new-fallback-element/video I still think the use of this is questionable though. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] HTML 5 video tag questions
On Mon, Jul 13, 2009 at 2:15 PM, Philip Jägenstedtphil...@opera.com wrote: On Mon, 13 Jul 2009 20:38:11 +0200, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Jul 13, 2009 at 1:33 PM, Boris Zbarskybzbar...@mit.edu wrote: Philip Jägenstedt wrote: It would have to be part of the resource selection algorithm. Since that waits for new source elements indefinitely, when exactly would you decide to switch to fallback content? Bad solutions include special-casing static markup and/or (falsely) assuming that scripts will not insert more source elements at some point. If fallback content is defined simply as the content of the video element I also can't figure out any other solutions. A source that says use the content? -Boris Ie inserting source fallback or source contents. If both @src and @fallback are specified on a source, it is treated like a source srcsource fallback; that is, it first tries the @src attribute, and if that doesn't work, then it goes to the fallback content. That would require the parser to inspect an attribute to determine if the element is a void element (one that does not have a closing tag) or not, which I've been told is not very nice. Are there any other such cases? Hm? I'm not sure what you mean here. It would work like this: video source src=foo source src=bar source fallback pI'm some fallback content!/p /video You'll see the p if the browser doesn't support video, or if the resource selection algorithm hits that third source and hasn't found anything it can play yet. It wouldn't change whether the source is a void element or not. (You could also just put @fallback on the second source and drop the third source entirely for the same effect.) This is why I suggested videosource src=cant.play.oggnew-fallback-elementOoops!/new-fallback-element/video I still think the use of this is questionable though. I'm not sure why you think the usecase is questionable. It seems pretty clear - it'd be nice to have a non-script way of showing content (specifically, alternate video players) when the browser supports video but can't play any of the provided sources. ~TJ
Re: [whatwg] HTML 5 video tag questions
On Mon, 13 Jul 2009 21:28:45 +0200, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Jul 13, 2009 at 2:15 PM, Philip Jägenstedtphil...@opera.com wrote: On Mon, 13 Jul 2009 20:38:11 +0200, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Jul 13, 2009 at 1:33 PM, Boris Zbarskybzbar...@mit.edu wrote: Philip Jägenstedt wrote: It would have to be part of the resource selection algorithm. Since that waits for new source elements indefinitely, when exactly would you decide to switch to fallback content? Bad solutions include special-casing static markup and/or (falsely) assuming that scripts will not insert more source elements at some point. If fallback content is defined simply as the content of the video element I also can't figure out any other solutions. A source that says use the content? -Boris Ie inserting source fallback or source contents. If both @src and @fallback are specified on a source, it is treated like a source srcsource fallback; that is, it first tries the @src attribute, and if that doesn't work, then it goes to the fallback content. That would require the parser to inspect an attribute to determine if the element is a void element (one that does not have a closing tag) or not, which I've been told is not very nice. Are there any other such cases? Hm? I'm not sure what you mean here. It would work like this: video source src=foo source src=bar source fallback pI'm some fallback content!/p /video You'll see the p if the browser doesn't support video, or if the resource selection algorithm hits that third source and hasn't found anything it can play yet. It wouldn't change whether the source is a void element or not. I thought you meant video source fallback fallback content here /source /video I would prefer if fallback content and source elements weren't mixed on the same level, but maybe that's just me. (You could also just put @fallback on the second source and drop the third source entirely for the same effect.) Once the source element is iterated by the resource selection algorithm and starts loading, the fallback attribute or the whole source element might be removed. You would have to set a flag at some point to remember the fallback state and unset it... when? What is the effect of video source fallback source src=cant.play.ogg fallback here /video ? Is fallback irrevocable or could the same video element go back to showing video under some circumstances? Does audio also have fallback content? This is why I suggested videosource src=cant.play.oggnew-fallback-elementOoops!/new-fallback-element/video I still think the use of this is questionable though. I'm not sure why you think the usecase is questionable. It seems pretty clear - it'd be nice to have a non-script way of showing content (specifically, alternate video players) when the browser supports video but can't play any of the provided sources. Yes, handling the (minor) use case video support + no supported source + no script would be nice, but only if it doesn't make an even bigger mess of the resource selection algorithm and doesn't allow switching back and forth between video and fallback. The browsers that have already shipped with video don't support fallback but they are the ones that are the most likely to need it (assuming that format support will get better over time). It would be nice to hear what they think about all of this. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] HTML 5 video tag questions
On Mon, 13 Jul 2009 17:01:26 -0400, Philip Jägenstedt phil...@opera.com
wrote:
Does audio also have fallback content?
With audio, you can set its display to 'none' and the audio will still
play. However, if its display is set to 'none' and the element were to
fall back to a child object element that loads a plug-in, things wouldn't
work because plug-ins don't work with a display of 'none'.
You would then have to detect that audio fell back so you could set its
display to inline-block for example so the fallback plug-in would
actually load. Or, there'd have to be a new css selector to handle this
like audio::fallback_state { display: inline-block} or a parent selector
on the child object element that was only applied when audio fell back
to it. Or, the browser would have to make plug-in objects that are
descendants of an audio element work with a display of 'none'.
The same applies to video if you want to set its display to 'none' and
just hear the audio.
--
Michael
Re: [whatwg] HTML 5 video tag questions
On Mon, Jul 13, 2009 at 5:01 AM, Philip Jägenstedtphil...@opera.com wrote: The design you describe is what object tried to do, and it proved to be extremely problematic in practice -- and that was without another built-in fallback mechanism to complicate matters. While object has had a very poor implementation story, I don't think this was a big reason for that. Robert O'Callahan, Boris Zbarsky and other gecko layout folks can answer this better, but at least in gecko I don't think this part of object was particularly hard to implement correctly once we actually tried. Has any browser vendor argued against displaying the fallback due to high implementation burden? Implementation probably isn't the biggest burden here, specifying sane behavior is. For example: If fallback content is displayed after the last source element has failed, what should happen when a new source element is inserted? Switching back to video mode would make it even more special than object fallback and if you don't you'll just get stuck with fallback and have effectively broken the possibility of inserting source elements via scripts. Something like videosource src=cant.play.oggnew-fallback-elementOoops!/new-fallback-element/video is what you'd need to make the resource selection algorithm deal with fallback in a sane way when scripts are disabled, but this is too much of a corner case to justify the complexity in my opinion. I think fallback contents is simply defined as the contents of the video, minus any source elements (which wouldn't render anyway). No need for new-fallback-element. The simplest solution would be to display the fallback when there aren't any source (or @src) elements being either displayed or waiting to load. I think spec-wise the simplest thing would be to display fallback when The networkState of the element is NETWORK_NO_SOURCE. This way even incremental rendering of the fallback contents would work fine. The only case that's weird is markup like: video lots and lots of fallback here source src=... /video There is a risk that content would be displayed, and then switch to displaying video. This doesn't seem like a big problem as it seems more likely that people will put the source first. And if someone doesn't the effects aren't very bad. Alternatively we could use the following rules: 1. The networkState of the element is NETWORK_NO_SOURCE. *and* 2. The video element is fully parsed. I.e. it has been removed from the stack of open elements. This would mean that incremental rendering doesn't work. This doesn't seem any worse than what we have now when fallback is never displayed. Though I think it'd work fine always display fallback whenever the networkState is NETWORK_NO_SOURCE. / Jonas
Re: [whatwg] HTML 5 video tag questions
On Mon, Jul 13, 2009 at 4:01 PM, Philip Jägenstedtphil...@opera.com wrote: I thought you meant video source fallback fallback content here /source /video I would prefer if fallback content and source elements weren't mixed on the same level, but maybe that's just me. Eh, fallback content for non-video browsers is already there, so it's nothing new. (You could also just put @fallback on the second source and drop the third source entirely for the same effect.) Once the source element is iterated by the resource selection algorithm and starts loading, the fallback attribute or the whole source element might be removed. You would have to set a flag at some point to remember the fallback state and unset it... when? What is the effect of video source fallback source src=cant.play.ogg fallback here /video ? It would hit the first source, note that there's no @src, see that there is @fallback, and immediately drop to showing fallback content. Is fallback irrevocable or could the same video element go back to showing video under some circumstances? It should be revocable in the exact same circumstances that a video element might start playing from one source, and then switch to another. From my reading of the algorithm I don't think this is possible, so fallback would be irrevocable. Does audio also have fallback content? It uses source and the same source-selection algorithm (and the same fallback situation in the case of non-audio browsers), so yes. This is why I suggested videosource src=cant.play.oggnew-fallback-elementOoops!/new-fallback-element/video I still think the use of this is questionable though. I'm not sure why you think the usecase is questionable. It seems pretty clear - it'd be nice to have a non-script way of showing content (specifically, alternate video players) when the browser supports video but can't play any of the provided sources. Yes, handling the (minor) use case video support + no supported source + no script would be nice, but only if it doesn't make an even bigger mess of the resource selection algorithm and doesn't allow switching back and forth between video and fallback. From what I can tell of the resource selection algorithm, fallback should be irrevocable, just like a successful source load is. The resource selection algorithm appears to need fairly trivial changes to accommodate this. Step 4, when parsing @src from video, insert a new substep between substeps 2 and 3. Pull the first sentence from the current substep 3 into this new substep, and say something like If the element has a fallback attribute, abort this algorithm immediately and display the fallback content. When parsing source elements, change step 3 so that whenever any of those conditions are met, if the source has @fallback the algorithm aborts immediately and shows the fallback content, otherwise it fires the error event and jumps to the search loop step as normal. Alternately, we could just put @fallback always on the video element directly, rather than on source. That would preserve the first part of what I said, but now we have a step between substeps 9 and 10 that checks for @fallback on the video. If it finds it, it immediately aborts and shows the fallback content, otherwise substep 10 proceeds normally (waiting forever). ~TJ
Re: [whatwg] HTML 5 video tag questions
On Mon, Jul 13, 2009 at 4:28 PM, Jonas Sickingjo...@sicking.cc wrote: This way even incremental rendering of the fallback contents would work fine. The only case that's weird is markup like: video lots and lots of fallback here source src=... /video There is a risk that content would be displayed, and then switch to displaying video. This doesn't seem like a big problem as it seems more likely that people will put the source first. And if someone doesn't the effects aren't very bad. That's against spec anyway (source elements, if present, should be the first children of video, and are then followed by fallback content if present), so it's not a big deal if it displays badly.
Re: [whatwg] HTML 5 video tag questions
On Jul 10, 2009, at 6:11 PM, Jeff Walden wrote: On 10.7.09 17:44, Ian Hickson wrote: The design is based around the assumption that we will eventually find a common codec so that fallback won't ever be needed in supporting UAs. So has anyone ever actually pointed out the elephant in the room here, that we might never do so? I can't remember if so. Maybe HTML5: Galaxy Quest (cf. Captain Taggart's line) just isn't going to happen in the foreseeable future. There is likely an upper bound set by the maximum possible expiration date of any patents applying to any of the viable candidates. It's just that we'd like to reach agreement well before then. (I'm also not convinced that we substantially hurt ourselves by making fallback content the final source.) I also think that would make more sense. Right now if a site wants to publish Ogg-only with Cortado as the fallback, they have to use scripting to make it work in Safari. And if a site wants to publish H. 264-only with Flash or QuickTime as the fallback, they have to use scripting to make it work in Firefox. Sites might want to do this even if there were an agreed-upon common codec that simply didn't meet their needs. So a common codec won't completely eliminate this issue. I can't see any advantage to the current design. Regards, Maciej
Re: [whatwg] HTML 5 video tag questions
On Sat, Jul 11, 2009 at 3:24 PM, Maciej Stachowiakm...@apple.com wrote: On Jul 10, 2009, at 6:11 PM, Jeff Walden wrote: On 10.7.09 17:44, Ian Hickson wrote: The design is based around the assumption that we will eventually find a common codec so that fallback won't ever be needed in supporting UAs. So has anyone ever actually pointed out the elephant in the room here, that we might never do so? I can't remember if so. Maybe HTML5: Galaxy Quest (cf. Captain Taggart's line) just isn't going to happen in the foreseeable future. There is likely an upper bound set by the maximum possible expiration date of any patents applying to any of the viable candidates. It's just that we'd like to reach agreement well before then. Not really, at some point well before then the argument will shift to a newer clearly superior to H.264 encumbered format. I would expect that H.264 would spend a period of time as a non-consideration by almost everyone since it would be inferior to something newer and yet would still require fees. You could counter that H.264 and AAC have reached some magic threshold of adoption or usability that they will not fail to the great hamster-wheel of encumbered codec upgrades, but since I've never seen anyone state what those requirements are I'm doubtful. Regardless— It's far from clear that simply waiting 15ish years would resolve the problem, even if anyone found that to be desirable.
Re: [whatwg] HTML 5 video tag questions
On 11.7.09 12:54, Gregory Maxwell wrote: ...snip... Precisely. Jeff
Re: [whatwg] HTML 5 video tag questions
On Jul 11, 2009, at 12:54 PM, Gregory Maxwell wrote: Not really, at some point well before then the argument will shift to a newer clearly superior to H.264 encumbered format. I would expect that H.264 would spend a period of time as a non-consideration by almost everyone since it would be inferior to something newer and yet would still require fees. You may be right. On the other hand, Theora and it's immediate precursor have been around for about a decade, and Theora is still considered to be contender quality-wise. This was a minor side point to what I think is the main point: video should use the fallback content as a last resort if none of the provided sources are suitable. If you are right that in a decade current codecs may all be obsolete, that is supporting evidence for this position. A final source fallback to a baseline codec may someday not be a suitable solution, if the baseline is considered obsolete by then and no one wants to use it. Regards, Maciej
Re: [whatwg] HTML 5 video tag questions
On Sun, 14 Jun 2009 jjcogliati-wha...@yahoo.com wrote: I read section 4.8.7 The video element and I have some questions: 1. What happens if the user agent supports the video tag but does not support the particular video codec that the video file has? Should it display the fallback content in that case, and if so, can a video tag be put inside another video tag? You can use the source element for fallback. If none of the available videos are supported, the video element just sits there doing nothing, and an 'error' event fires in the script. The fallback contents are not shown if the element is supported; they are only intended for other browsers that don't support video at all. 2. What is the recommended way for website authors to determine what video and audio codecs and containers are supported by a user agent? The canPlayType() method. On Sun, 14 Jun 2009, Jonas Sicking wrote: Hmm.. is that good? What if you want to use an object (to use flash or java) or a img as fallback? Then you do it with script. The design is based around the assumption that we will eventually find a common codec so that fallback won't ever be needed in supporting UAs. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML 5 video tag questions
On Fri, Jul 10, 2009 at 5:44 PM, Ian Hicksoni...@hixie.ch wrote: On Sun, 14 Jun 2009, Jonas Sicking wrote: Hmm.. is that good? What if you want to use an object (to use flash or java) or a img as fallback? Then you do it with script. The design is based around the assumption that we will eventually find a common codec so that fallback won't ever be needed in supporting UAs. I agree that the current design makes sense once there is a common codec supported across all browsers. However currently it seems like we might not reach that point until after all major browsers support video. What would be the downside of displaying the fallback contents if none of the videos can be displayed due to unsupported codecs? / Jonas
Re: [whatwg] HTML 5 video tag questions
On 10.7.09 17:44, Ian Hickson wrote: The design is based around the assumption that we will eventually find a common codec so that fallback won't ever be needed in supporting UAs. So has anyone ever actually pointed out the elephant in the room here, that we might never do so? I can't remember if so. Maybe HTML5: Galaxy Quest (cf. Captain Taggart's line) just isn't going to happen in the foreseeable future. (I'm also not convinced that we substantially hurt ourselves by making fallback content the final source.) Jeff
Re: [whatwg] HTML 5 video tag questions
Maybe to make this more clear section 4.8.7.1 should add a sentence somewhere like: Authors may provide multiple source elements to provide different codecs for different user agents. Could multiple source elements also be used to provide different bit-rate sources (or even alternative versions, e.g. different languages) as well as different codecs, something like the HTTP streaming playlist idea? Sam Dutton http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. winmail.dat
Re: [whatwg] HTML 5 video tag questions
The first video source that can be played wins. You cannot provide alternative versions for different languages or resolutions in one VIDEO element. Chris
Re: [whatwg] HTML 5 video tag questions
Kristof Zelechovski wrote: The first video source that can be played wins. You cannot provide alternative versions for different languages or resolutions in one VIDEO element. If the browser decides that a video is too high resolution and cannot be played on this system, then why can't it fall through to a lower-resolution copy if one exists? --Ben signature.asc Description: OpenPGP digital signature
Re: [whatwg] HTML 5 video tag questions
At 18:12 +0200 16/06/09, Kristof Zelechovski wrote: The first video source that can be played wins. You cannot provide alternative versions for different languages or resolutions in one VIDEO element. Chris but there are media queries, and I have posted a couple of times that we should considering allowing source selection based on accessibility needs. we should probably also make it possible to select on language, it's a common need. -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg] HTML 5 video tag questions
Media queries can be done the same way as for images. Similarly, the server can choose to serve a localized version of any resource whatsoever. These customizations should not be put into VIDEO because their scope is wider. IMHO, Chris
Re: [whatwg] HTML 5 video tag questions
On Mon, 15 Jun 2009 07:27:18 +0200, Tab Atkins Jr. jackalm...@gmail.com wrote: On Sun, Jun 14, 2009 at 8:46 PM, jjcogliati-wha...@yahoo.com wrote: I read section 4.8.7 The video element and I have some questions: 1. What happens if the user agent supports the video tag but does not support the particular video codec that the video file has? Should it display the fallback content in that case, and if so, can a video tag be put inside another video tag? If the particular codec is not supported, it displays the fallback content instead. No. If the particular codec is not supported then you get a blank box. If you want to offer multiple formats to cater to disparate UAs, give video some source children rather than @src. It will try each source in turn until it finds one it can play. Yep. -- Simon Pieters Opera Software
Re: [whatwg] HTML 5 video tag questions
On Sun, Jun 14, 2009 at 11:08 PM, Simon Pieterssim...@opera.com wrote: On Mon, 15 Jun 2009 07:27:18 +0200, Tab Atkins Jr. jackalm...@gmail.com wrote: On Sun, Jun 14, 2009 at 8:46 PM, jjcogliati-wha...@yahoo.com wrote: I read section 4.8.7 The video element and I have some questions: 1. What happens if the user agent supports the video tag but does not support the particular video codec that the video file has? Should it display the fallback content in that case, and if so, can a video tag be put inside another video tag? If the particular codec is not supported, it displays the fallback content instead. No. If the particular codec is not supported then you get a blank box. Hmm.. is that good? What if you want to use an object (to use flash or java) or a img as fallback? / Jonas
Re: [whatwg] HTML 5 video tag questions
On Mon, Jun 15, 2009 at 1:46 PM, jjcogliati-wha...@yahoo.com wrote: 1. What happens if the user agent supports the video tag but does not support the particular video codec that the video file has? Should it display the fallback content in that case, and if so, can a video tag be put inside another video tag? It does not display the fallback if the codec/format is not supported. The fallback is only displayed in a browser if the video element is not supported at all. 2. What is the recommended way for website authors to determine what video and audio codecs and containers are supported by a user agent? Ideally all user agents will have one codec that is supported across all implementations. Failing that there's a JavaScript API for querying codec support. Look for 'canPlayType'. Chris -- http://www.bluishcoder.co.nz
Re: [whatwg] HTML 5 video tag questions
On Mon, Jun 15, 2009 at 5:27 PM, Tab Atkins Jr.jackalm...@gmail.com wrote: (That said, I don't think there's anything wrong with nesting videos, it's just unnecessary.) This won't work since fallback content is not displayed unless video is not supported. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] HTML 5 video tag questions
On Mon, Jun 15, 2009 at 4:49 AM, Chris Doublechris.dou...@double.co.nz wrote: On Mon, Jun 15, 2009 at 5:27 PM, Tab Atkins Jr.jackalm...@gmail.com wrote: (That said, I don't think there's anything wrong with nesting videos, it's just unnecessary.) This won't work since fallback content is not displayed unless video is not supported. Dang, I was wrong. I know I remembered some conversations about nested video, but I guess I was just remembering people *asking* about it. Regardless, as noted by others, my source suggestion was correct. Provide multiple sources if you're not sure about what format your users can view. ~TJ
Re: [whatwg] HTML 5 video tag questions
Okay. Thanks. Maybe to make this more clear section 4.8.7.1 should add a sentence somewhere like: Authors may provide multiple source elements to provide different codecs for different user agents. Thank you. --- On Mon, 6/15/09, Tab Atkins Jr. jackalm...@gmail.com wrote: From: Tab Atkins Jr. jackalm...@gmail.com Subject: Re: [whatwg] HTML 5 video tag questions To: Chris Double chris.dou...@double.co.nz Cc: whatwg@lists.whatwg.org, jjcogliati-wha...@yahoo.com Date: Monday, June 15, 2009, 6:55 AM On Mon, Jun 15, 2009 at 4:49 AM, Chris Doublechris.dou...@double.co.nz wrote: On Mon, Jun 15, 2009 at 5:27 PM, Tab Atkins Jr.jackalm...@gmail.com wrote: (That said, I don't think there's anything wrong with nesting videos, it's just unnecessary.) This won't work since fallback content is not displayed unless video is not supported. Dang, I was wrong. I know I remembered some conversations about nested video, but I guess I was just remembering people *asking* about it. Regardless, as noted by others, my source suggestion was correct. Provide multiple sources if you're not sure about what format your users can view. ~TJ
Re: [whatwg] HTML 5 video tag questions
jjcogliati-wha...@yahoo.com wrote: Okay. Thanks. Maybe to make this more clear section 4.8.7.1 should add a sentence somewhere like: Authors may provide multiple source elements to provide different codecs for different user agents. Not just different codecs. Different bitrates, frame rates, or (coded) resolutions are also obvious axes along which browsers would logically want to choose if that's how source is really meant to work. The browser can inspect and decide. --Ben signature.asc Description: OpenPGP digital signature
[whatwg] HTML 5 video tag questions
I read section 4.8.7 The video element and I have some questions: 1. What happens if the user agent supports the video tag but does not support the particular video codec that the video file has? Should it display the fallback content in that case, and if so, can a video tag be put inside another video tag? 2. What is the recommended way for website authors to determine what video and audio codecs and containers are supported by a user agent? Joshua Cogliati http://jjc.freeshell.org/
Re: [whatwg] HTML 5 video tag questions
On Sun, Jun 14, 2009 at 8:46 PM, jjcogliati-wha...@yahoo.com wrote: I read section 4.8.7 The video element and I have some questions: 1. What happens if the user agent supports the video tag but does not support the particular video codec that the video file has? Should it display the fallback content in that case, and if so, can a video tag be put inside another video tag? If the particular codec is not supported, it displays the fallback content instead. If you want to offer multiple formats to cater to disparate UAs, give video some source children rather than @src. It will try each source in turn until it finds one it can play. (That said, I don't think there's anything wrong with nesting videos, it's just unnecessary.) ~TJ
