On Thu, 09 Jul 2009 19:10:08 -0400, Maciej Stachowiak <m...@apple.com>
wrote:
On Jul 9, 2009, at 3:34 PM, Peter Kasting wrote:
On Thu, Jul 9, 2009 at 3:30 PM, Aryeh Gregor <Simetrical
+...@gmail.com> wrote:
On Thu, Jul 9, 2009 at 10:04 PM, David Gerard<dger...@gmail.com>
wrote:
> Really? I thought that was next Chrome, not this Chrome.
It works in the developer version:
http://dev.chromium.org/getting-involved/dev-channel
For any site author needing a UA sniffing route to determine whether
a visitor's Chrome version supports <video>, just look for version
3.x or higher.
I'd recommend using feature testing or fallback instead though, if you
can make that work for your site.
Just to add:
For detecting video support via JS, I suggest feature testing for
window.HTMLVideoElement (and optionally window.HTMLAudioElement and
window.HTMLMediaElement).
You indeed can't really go by UA string sniffing as what if I use UserJS
to make HTMLVideoElement and HTMLAudioElement aliases to
HTMLUnknownElement, HTMLMediaElement equal to {} and use Getters/Setters
and prototypes to provide an HTMLMediaElement API proxy to a child
<object> that loads the VideoLan plug-in (for example, which is scriptable
and can play Theora and others)?
In that case, I wouldn't want to have to also spoof the UA (via HTTP
User-Agent and JS's navigator.userAgent etc.) just to get the right code
on the page.
I already see that <http://openvideo.dailymotion.com/> and
<http://youtube.com/html5> are using lousy UA string detection. There is
some use of fallback for <video>, but for the JS code that calls stuff
like video.play() etc., UA string detection is used, which makes things
too brittle and makes it so any new browser that supports <video> has to
wait for the UA detection to get updated.
I think I saw a recent Jquery <video>/<audio> plug-in though that doesn't
use any UA string detection, which is good.
--
Michael
