Let me get this straight:
is intended to obfuscate Flash for web video, right?
Then, why on earth would one implement it in a way that does not handle codec mismatches gracefully???
If — for what ever ideological reasons — Mozilla chooses not to support MPEG 4 in the first place and goes for Ogg/Theora (what virtually no-one uses, but hey it’s open) instead, then why not at least handle MPEG 4 content gracefully?
Like — for example — ask the (plug-in) system if anything handles that type and if not, pass on to the fallback?

I strongly doubt, that it would have been much of an effort, to implement it that way…

I’m serious guys:
Battles for codec-superiority* are nothing you should fight on your users backs!

(* then again, from the technical point of view Theora _isn’t_ superior to H.264 — if I’m not mistaken; the only advantage it offers is being open)

Plus:
Add me to the list of “Don’t encourage the use of JavaScript for this!”-people.

Thanks

2) Apparently the file extension .ogv makes an ogg video unplayable in Firefox. That’s weird, because when using ffmpeg2theora to convert files to ogg video (I’m on a Mac, ffmpeg2theora is the recommended converter), it automatically makes them *.ogv* files. And since this information is virtually non-existent (that .ogv files are unplayable in the main browser that requires ogg files for HTML 5 video) it takes a great deal of digging to understand what the f*** is going on. If you’re going to allow only one file format, make sure that the information is abundantly clear about this, and readily available. If for nothing else, to save me from having a(nother) bleeding ulcer… (I’ll put this to the ffmpeg2 people, but you (Mozilla) and Opera need to start making this info visible.)

Thanks

I’m using PHP otherwise to generate the HTML code, so it would be great for me if that could cover what CSS can’t do; but I assume that’s not possible here since only the Javascript or HTML read by the browser can apply in a client-side issue like this. Is this correct?

The spec says:

The controls attribute is a boolean attribute. If present, it indicates that the author has not provided a scripted controller and would like the user agent to provide its own set of controls.

If the attribute is present, or if scripting is disabled for the media element, then the user agent should expose a user interface to the user. This user interface should include features to begin playback, pause playback, seek to an arbitrary position in the content (if the content supports arbitrary seeking), change the volume, and show the media content in manners more suitable to the user (e.g. full-screen video or in an independent resizable window). Other controls may also be made available.

This also lists all the “basic stuff”: play/pause/seek/volume

My need, which I believe will be shared by others for a variety of reasons and uses-cases, is this: can the standard audio (and video) tag controllers that appear on-screen, without Javascript, be modified by CSS for color, transparency, size, and control features?

I’m doing a site, for example, that has an individual web page for each of >100 poems. Each poem is unique, has a unique image background, and the page containing it is meant to be experienced as a whole: including, if an audio controller is added, different needs for the controller color, transparency, and sizes and types of controls available. Current Windows Media, QuickTime, and Linux-based controllers lack some or all of the basic color, size, transparency and controls configurability, and what remains is also different on different OS’s and browsers. WM and QT controllers appear so intrusive and out-of-place in many of the poems that I gave up attempting to use them, waiting instead for HTML5 audio/video tags, where I intend another attempt — one where I hope to be able to set a consistent controller across browsers and OSs.

So, my question is: will this sort of configuration of the controller now be possible — and without Javascript?

@Kroc: RSS Readers is a different topic, because
- they have shorter upgrade cycles than browsers, so they can soon implement html5 video natively
- web-based feed readers use Javascript anyway, they could even use html5flash to implement html5 video now
- there is MediaRSS, which is similar to a video element with multiple source elements

From my point of view, the real concern is getting having the video element in the markup, so that user agents know what’s going on and to have a fallback for the non-FF/non-Chrome/non-Safari population. People with Javascript disabled are less common in my usecase, and disabling Javascript often correlates with disabling Flash and Plugins, which would make most fallbacks unworkable.

What of RSS readers that don’t execute JavaScript?

A common API is definitely what’s needed Lars, I think everybody would benefit if we could combine Video for Everybody with HTML5Flash so that JavaScript isn’t required to see the video (including Flash users), but a JavaScript API allows people to do more advanced stuff and interact with the page.

There is a blog post describing my approach here: http://gettingsoftware.posterous.com/html5flash-using-html5-video-and-audio-right and the source code is available from Github.

The only users who wouldn’t see embedded video although they technically could are the ones that have Flash enabled, but Javascript disabled. And that’s a negligibly small part of most audiences.

A big “Thank You” to Kroc for posting the correct way to embed video using HTML5. For those interested in doing it the right way (instead of the FUBAR way, Kroc’s page is here: http://camendesign.com/code/video_for_everybody

-Mike

So users in such environments will not be very happy with this proposed implementation – which to me also looks like moving your car on a truck instead on its own tires. But you god-like developers might know this much better than me, being only a simple minded user of the web

So again: For all of us corporate users, please do not propagate JavaScript where it is not absolutely necessary.

Thank you very much from a humble Firefox evangelist in a IE dominated large company.

The test videos, will be changed later, with a newer updated OGGTV.