From the inimitable Chris Double of Mozilla’s New Zealand brain trust: moving, rotating, scaling <video> in SVG (so who needs yet another non-standard plugin?). If you make a build from Chris’s code, don’t forget to view-source the demo.
/be
8 Replies to “Video Tag Progress”
Comments are closed.
A bit off-topic, but as to who needs yet another non-standard plugin? Those of us, who’d like to not be limited to only doing client side dev in javascript. For me the primary reason why I want that non-standard plugin is a byte-code addressable VM. Make the javascript VM in Mozilla byte-code addressable so that people can write compilers for other languages and the non-standard plugin becomes less appealing.
sdether: do you mean Flash, or SL? That is, which are you actually using, or is this all future tense?
Also, to what end do you want a bytecode-addressable VM? If it’s only so you can program in other languages than JS, which languages? If it’s for some other reason, it would help to hear it. Thanks,
/be
I should have included Java in the possible plugins in the last comment. Really, there are choices, but they may not integrate as well as JS does with the page or browser.
However, these plugins are all means to ends, and I’m interested in the ends. With the video tag and other new content types, the need for plugins to do advanced rendering is reduced. With Tamarin and the monkeys, the need for plugins to support other programming languages goes down.
If after all these new things come to pass, there’s still a need for “bytecode-addressable VMs”, I’d like to know why. We’re working hard on the graphics and optimizing multi-lingual VM fronts, so you won’t need a plugin unless you have a requirement or strong preference that we are missing.
/be
Brendan, sorry for being cryptic.. I was just following the lead of your post 🙂
I was referring to Silverlight and at that the 1.1 alpha which includes the CLR. 1.0, I couldn’t have cared less for, but 1.1 changed my interest level completely. I have two problems with Javascript being the only official web client language:
1) I don’t particularly like its language syntax and I’m generally a strongly typed language fan.
2) It forces me to write client and server portions of the app in different languages, even though they generally are complementary pieces of enforcing the same business logic.
If you look at a history of platforms (and stipulating that the browser is a platform), then language mono-cultures have never thrived. Now, previous platforms have had the benefit (disadvantage?) of coding to the metal, so you could write a compiler for anything. But Virtual Machines have the promise of being language agnostic, and both the JVM (no thanks to Sun) and the CLR have both shown that a single runtime can handle a wide variety of languages.
So, if that’s the case, shouldn’t the browser platform follow that example and just allow the execution of byte-code instead of wrapping its VM with a single-language JIT compiler (I may have the details wrong, but that’s what the platform looks like from the outside).
I know this isn’t a problem that’s easily solved. Even if Mozilla allowed people to write compilers in other languages and have the script tag reference byte-code generated by those compilers, that doesn’t make it a standard. Now you’ve got to get Opera, Safari, Konqueror, etc. on board, and of course IE, while MS would likely just point to Silverlight and say “yeah, no thanks”. But it’s something that sure would be nice to see as part of the W3C specs
So the end that I’m personally after is the web platform with a language agnostic runtime. That way, as languages fall in and out of favor, they can be dealt with on this platform without trying to push a new standard on people. In the meantime I’ll use javascript for simple stuff and hope that Moonlight makes Silverlight content more palatable to those who’ll dismiss a plug-in from Redmond for non-technical reasons.
sdether, See Brendan’s post just prior to this for info on other languages. And you can do ECMAScript 4 statically typed, too. (Assuming it doesn’t take as long as Perl 6 to come out.) From my perspective, it seems more and more like you can make abstractions of underlying features and use them where available. If 99.9% of people either have Firefox 4 (or whenever we get the goodies) or Flash or Silverlight or Java, then you can address any of their feature sets abstractly. And you can then just assume that video or high-performance VM or vector graphics or whatever is available. And as the abstractions and the standards coalesce, software providers (Mozilla, Microsoft, Adobe, Sun, Google) will want to make their systems support the de facto standards. We just might get a nice, powerful open platform in another 5-10 years by sheer market forces.
Tom,
Somehow i managed to miss the previous post. IronMonkey does sound like what I’m looking for, although the details I can google are fairly vague right now. Is it meant to run only the dynamic languages of the CLR (mention of IronRuby and IronPython only)? If it’s an IL translator, it should work for any CLR language, right? And does that mean we can feed IL to IronMonkey for it to translate to ABC? More info would be appreciated.
I don’t quite understand why creating these adaptations to Tamarin is simpler than adopting the mono CLR or the jvm and getting an ECMAScript 4 compiler on top of those more mature VMs. But that’s another topic.
By the way, I should also have said, “Great news on the video!”. I’m looking forward to that being bundled. Are we getting plain audio, too? (And this all likely to hit at Firefox 4 or when?) Thanks for the news, in any case.
sdether wrote: “I don’t quite understand why creating these adaptations to Tamarin is simpler than adopting the mono CLR or the jvm and getting an ECMAScript 4 compiler on top of those more mature VMs. But that’s another topic.”
Tamarin already does ES3 (even eval now with the birth of the self-hosted compiler) and much of what is in ES4. Better to start with that than start over. Plus it’s a lot smaller and faster to start than other VMs that might claim to sort of “do JS” already, but really: the first reason is enough. As I keep saying, browsers must “do JS” first and fast, and other languages are gravy.
Check out https://ejohn.org/ and read through jresig’s “the choice of tamarin” blog entry for more.
/be