No, it shouldn't. In particular because all browsers have implemented this part of the spec.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: Not showing fallback content in browsers that support <video> is an explicit design choice motivated by the eventual agreement on a single codec, at which point this situation won't arise. It is unfortunate that we have not yet been able to find a common codec, but in practice the market will almost certainly resolve that long before this specification is done.

Even if every single tool agreed to support the XYZ codec, there would still be tools that also supported experimental codec XYZA -- and so there would be times when a browser did not support the codec that happened to be used in practice.

What fallback would you use in such a case? Why not just provide a fallback video file in a supported format?

The fallback would depend on the particular video (or audio) and context.

As to why not just provide a fallback in the standard codec ...

Why not just require valid XML?  Because it won't happen in practice, and it won't always be an accident when it doesn't happen.

Or if you're asking what the spec should recommend, then just treat it like an object, and use the internal text or elements.

In other words, replace:

"""
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.
"""

with something like:

"""
Content may be provided inside the video element. User agents should not show this content to the user unless they are unable to play the video.  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 or an alternate representation.
"""

And replace:
"""
Note: In particular, this content is not intended to address accessibility concerns. ...
"""

with:

"""
Note: This content is not the preferred method to address accessibility concerns. ...
"""

> The fallback would depend on the particular video (or audio) and context.

Do you have a concrete example of when someone would use a codec that not every browser supports? What fallback would you use for that specific concrete case?

Concrete use cases:

(a)  Transition period, before the One True Codec is fully established.  This also includes legacy pages that are undergoing only minimal maintenance.

(b)  Experimental codecs.  These may be there for political reasons.

(c)  Limited devices, such as low-end cell-phones -- particularly those that tried to use hardware for video, but were finalized before the One True Codec was.

(d)  Personal or low-budget sites, where something is uploaded in the format it was captured in, and not transformed.  (There may also be historical or legal reasons to show something only in the original format.)

What fallback would you use for those specific concrete cases? I don't understand how you imagine this working.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Did Not Understand Request
Change Description: no spec change
Rationale: I don't understand what fallback would be used in these cases.

mass-moved component to LC1

Hi, I am coming across this problem now in development work for a real system so I can give you the concrete example that you are asking for. Some of it is related to the 'temporary problem' (will that really be resolved by 2014?) that major manufacturers refuse to use .webm format, but not all.

Reopening as instructed, you can always close it again.

The reason why this is a problem:

1) We allow ordinary users, such as schoolteachers, to add video files. They almost certainly won't understand anything about video formats; we let them upload a range of formats (including crappy ones like .avi, as well as .mp4 for instance).

2) Because this is an open-source system that can be installed on a range of servers and is frequently used on cheap hosting (and also just because it would be some work), we don't really want to implement automated format conversion relying on a server-side tool such as ffmpeg - at least not yet - this might be a good option in future but there are challenges there.

When we don't use HTML5, then for all file formats we can offer a fallback via the object tag. The system allows for multiple fallbacks and the last fallback is very simple: we give users a link where they can download the file. In most cases, their operating system probably has a player for the file format.

The problem comes when using HTML5 audio or video tags. Here is the solution I am currently planning to adopt for .mp4 files:

1) At the outer layer, use an object tag (which QuickTime will handle if available).
2) Inside that, put the HTML5 video tag - conditional on a browser-detect depending on the format(s) available.
3) Inside that, put the download link.

The browser-detect is needed because we'd like them to see the link not a broken video (if they see the broken video, some people will call helpdesk whereas there is nothing obviously wrong with our web page when you get a download link).

So this is not impossible to make work if we ladle on enough server-side browser detection and hard-code in knowledge about which browsers support which formats in which versions. It just seems like the sort of problem that HTML5 was supposed to make easier, whereas this particular task is harder to achieve than using the HTML4 object tag.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: 

I would recommend the following approaches:

* Don't allow people to upload content that isn't in the well-supported format(s).

* If you really must, then first, realise that this is not what the feature was designed for. But then, use script to detect the error condition (using the onerror handler on <video> or <source> depending on what you're doing) and then in that handler, replace the <video> element with the plugin.

* Alternatively, use <video> as the fallback to the plugin, instead of the plugin as the fallback to the <video>.

Also, always provide the download link, don't hide it in the fallback.