webm.html5.org
As support for WebM is ramping up, Web authors can start using it. However, since not everyone has a WebM-enabled browser, yet, using WebM on your site poses the problem of having to explain to the visitors of your site how they can view WebM. It is inefficient for everyone to have to do this from scratch on their sites. Also, chances are that per-site help text will be incomplete and out of date soon.
To address this problem, with hosting and domain name help from Anne van Kesteren, I have made webm.html5.org as a place to pool the effort. When you publish WebM content, instead of explaining which browsers support WebM, you can simply link to webm.html5.org and it will detect if the user’s browser supports WebM. If the browser doesn’t support WebM, the page will suggest upgrading the browser to a new version that supports WebM, installing a WebM decoder if the browser supports 3rd-party decoders and one is available, switching to another browser or using another operating system (as applicable and in that order).
The dull visual appearance of the page is a known problem. Visual design isn’t my strong point. I have also avoided using logos without permission. If you’d like to contribute nicer CSS or a nicer-looking (but still short and on-topic) test clip, please find hsivonen on the #whatwg IRC channel on Freenode. Also, if you can contribute accurate advice for platforms that aren’t already covered (e.g. FreeBSD, AIX or OS/2), please drop a line on IRC or in the comments here. (You can view source on webm.html5.org to see what is already covered.)
Are you planning to add multilingual explanation?
Perhaps you could make a version that web authors can embed on their page, where it says nothing at all if the browser supports WebM, and otherwise displays a short explanation and a link to either a longer explanation or to where you can upgrade to a browser that does support WebM.
Wut. Javascript testing for a HTML feature? Please.
Start from here, and build any JS on top you fancy:
[video poster="vidyepwebmnope.png" src="video.webm"][img src=”nope.gif” alt=”…” /] Your browser blah blah… [/video]
So then does this signal an intent on the part of the standards body to become more involved in the codec debate on the side of WebM? Does this count as an official endorsement? Interesting.
The javascript does not recognize the open source version of Google’s Chrome, Chromium.
You should really be testing the availably features instead of the browser.
@John Drinkwater
That is sadly not how the video element is designed. A browser with video support, but without WebM support will not fall back to the video elements content.
The rationale behind that design is that all browsers support the same video formats … eh, thats not true, but for some reason that argument succeeded anyway.
GTZHJ,
You didn’t read the example correctly, that fallback is for browsers that dont support video.
If you look at current use of [video] in Firefox, if you’re given a h264 file and nothing else, it will just display the poster and a large X.
My sample code should* work exactly the same in non?webm browsers.
But that really gets around the point. If a browser can do video, it doesn’t need js to tell it so, it can *just do it*. If you want to test codecs on top of that, then add in javascript.
@tnn: Multilingualism wasn’t part of the plan originally, but since it is the #1 request I’ve gotten, it is the plan now.
@Behold: Thanks for the suggestion. I’ve noted it as an enhancement request, but I don’t have immediate plans to implement it due to schedule constraints.
@John Drinkwater: Did you View Source on the page? It degrades gracefully to some self-help advice if JavaScript is disabled. However, the script makes more accurate advice possible. Furthermore, the reality is that many sites implement their own video player APIs in JavaScript, so if you use a browser that supports the video element and WebM but doesn’t implement the API properly (e.g. Konqueror 4.5 on Fedora 14), you can’t really view all the WebM content out there.
@Kenneth Pardue: No, this is not an endorsement of any kind. This is a personal project of mine. I made the site, because I wished such a site existed so that I could link my visitors to it when I use WebM video on my personal site. This is a loose community blog and, in general, you shouldn’t assume posts on this blog to reflect the opinions of anyone but the person mentioned as the post author. (See the policy.)
@NZheretic: After checking if the browser is known to be too broken to be subjected to a feature detect (Konqueror 4.4 or 4.5), the page proceeds to a feature test. If the browser tests as supporting WebM, the identity of the browser doesn’t need to be sniffed further and isn’t sniffed further. If the browser tests as not supporting WebM, only then the UA string is sniffed and only for the purpose of providing targeted advice to the user so that the user doesn’t need to know how to ignore irrelevant advice. If the user has an ancient version of Chromium that doesn’t support WebM, the site suggests installing Chrome, because the Chromium project doesn’t seem to provide end user-target auto-updating releases of Chromium itself and even if it did, it wouldn’t make sense to stuff the browser ballot with both Chrome and Chromium. (If I’m wrong, the releases are very well hidden.) As far as I can tell, chromium.org provides nightly build that don’t self-update and aren’t really appropriate for end user consumption.
On the other hand, if the user visits the site using Firefox 3.6 bundled with Ubuntu 10.10, the site informs the user both about the availability of Firefox 4 beta from outside the Ubuntu repositories and about the availability of Chromium in the Ubuntu repos. Similar advice isn’t given to Fedora users, because by the default Fedora 14 software repos don’t seem to include Chromium.
If you still believe the site provides incorrect advice about Chromium, please give more detail about the scenario that triggered the incorrect advice.
@John Drinkwater: Ah, okay. I think your approach is right on the website embedding the video.
But I am very sure most authors will not do like you advise, because they need script anyway to rescue the user experience with flash in XX%. Just because they can’t rely on the elements contents for flash in video supporting browsers.
And users without script are much much much rarer than users without WebM but with video and flash support.
FSF has it’s PlayFreedom campaign:
http://playfreedom.org/
I hope the guys running it are aware of webm.html5.org.
I feel somewhat discriminated…:-(
Accessing that page with a Camino nightly (gecko 1.9.2 based) i’m obviously confused with someone using Firefox. I’d expect to be offered the same choices as if I were accessing that page with, let’s say, a nightly Webkit build.
(yeah, Camino contains ‘like firefox’ in the UA string for the obvious reasons of crappy UA detection, no need to abuse it for this though)
@GTZHJ: “But I am very sure most authors will not do like you advise, because they need script anyway to rescue the user experience with flash in XX%. Just because they can’t rely on the elements contents for flash in video supporting browsers.
And users without script are much much much rarer than users without WebM but with video and flash support.”
Users have nothing to do with it.
Only developers who are required to develop a site in Flash will need it. Then again, no one is required to develop a site in Flash. Only a Developer/Consulting Business whose expertise in Flash will try to convince a client they need to have their site developed in Flash.
@philippe: Fixed. Thanks.
How about not being biased and let operating system play the video? Sigh. I suppose Flash will stay for a while longer.
@romaninsh: Everyone had that option for well over a decade, via plain embed/object. You may notice that it was such a catastrophic failure that nobody even uses it as fallback for Flash.
Henri,
I did view?source. But without JS running, it’s not obvious that the webm text is a video! It has all the appearance of a heading and below it are suggestions for browsers to use.
A side?effect of Firefox using javascript for the control interface, noscript disables it.