Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×

Implications of the Mozilla/Adobe Partnership 104

Fraggle writes "Recently the Mozilla Foundation and Adobe announced a partnership, working together on the next generation JavaScript/ActionScript JIT Virtual Machine. The Browser Den looks at what this means for the future of scripting in Mozilla, and how this partnership with Adobe may affect Mozilla's support for other technologies such as SVG." From the article: "On the Mozilla side the plan is to integrate to code with SpiderMonkey which is Mozilla's current JavaScript implementation that is written in C. This is needed because Tamarin is not a drop-in replacement for SpiderMonkey as it provides necessary features that are not available in Tamarin. The combined SpiderMonkey with integrated Tamarin should not have any problems with old JavaScript and should show a performance boost for most. However, skilled scripters are sure to find ways of optimising performance to get even more gains."
This discussion has been archived. No new comments can be posted.

Implications of the Mozilla/Adobe Partnership

Comments Filter:
  • First the Novell/Microsoft deal and now this?
    • I was thinking the opposite.
      If big business is trying to muscle in, then we should all run for the hills.
      Is itsatrap relevant here?

      I might be overreacting, and we already have one big benevolent overlord guiding us (the Vorlons ermmmmm I mean IBM), do we need others?
      • Re: (Score:2, Insightful)

        To quote the real Kosh: "The avalanche has already started; it is too late for the pebbles to vote." ;)
      • by baadger ( 764884 )
        It isn't a trap because it's impossible to trap anyone all the time the code is GPL'd. IceWeasel could easily benefit from this code as well (although i'm not saying I support IceWeasel or oppose the Adobe/Mozilla partnership).

        The *worst* that could happen is the Mozilla/Firefox 'brand name' becomes tainted and people move away from it in droves. How this could feasibly happen I don't know, it isn't likely at all. Either way I couldn't give a monkeys butt about the brand, I care about the product. So I real
        • Either way I couldn't give a monkeys butt about the brand, I care about the product.

          True to a degree. But the 'brand' of OSS projects is the center around which developers gather. If the 'brand' is subverted or branches out in a way that dissipates that center, then developers will disperse and/or cease to participate.

          'The Mozilla Project' is a distinctily different 'brand' than 'Adobe (tm) Mozilla.'

          Personally, I try to stay at arms length from anything currently made by Adobe. They've been taken over b
    • Oh boy, I can't wait for the Adobe Acrobat Plug-in toolbars and such....*sigh*
      • I now use Foxit Reader almost exclusively for displaying and printing PDFs at work. But my machine still sometimes locks up and throws up dialogues about AdobeAcrobat plugin junk. I haven't taken the initiative to completely excise Adobe Acrobat from the machine (the IT people might frown on that) but Foxit Reader is a single .exe file that I can stick essentially anywhere on my drive and point PDF files at, and it just works(tm).
  • Amazing (Score:2, Insightful)

    Never in my wildest pre-crash dreams did I ever think that Javascript would become a respectable programming language.

    HTML either, but that preconception was crushed when I saw the money those art school dropouts were making.

    I just hope that they don't embed Flash player into the browser. That would suck royally.
    • Re: (Score:3, Interesting)

      by foniksonik ( 573572 )
      "I just hope that they don't embed Flash player into the browser. That would suck royally."

      Don't disparage something you don't understand. It's like saying you hate all music cause you heard a few Britney Spears songs.

      Take a look at OpenLaszlo. [openlaszlo.org]
      • Don't disparage something you don't understand. It's like saying you hate all music cause you heard a few Britney Spears songs.

        No, it is like saying you don't want a radio without an "off" button.

        Most Net Flash content is crap. It's mainly used for ads. I, for one, surf with FlashBlock and only allow the damn thing to play when absolutely neccessary.

      • Don't disparage something you don't understand.

        I can't speek for the GP, but I understand Flash. Flash is about giving control to the content producers at the expense of the consumers. I am a comsumer who likes control, ergo I don't like like flash.

      • I am using a 64 bit Ubuntu 6.10 operating system with the latest firefox 2.0 browser. I can not get any flash to work or any video player. I tried downloading from Adobe and they state they do not support 64 bit. I tried automatix and downloaded a 32 bit firefox and when I download the plugins I get a error message. If I retry to install them, the programs states that they are already installed but when I tell it to reinstall them I get the same error I got before. I like this 64 bit firefox because I w
    • by Malc ( 1751 )
      I've seen some very slick applications written in JavaScript. It can be quite powerful. One feature I really like and put to good use is the eval method - take any string and treat it as a piece of code and run it. It also does some funky things with enviroment contexts (can't remember the right term) where you can define a function that references a variable in the outer function, then pass function off to somewhere else. Later on when you call it from some unrelated code, the variable in the outer fun
      • One feature I really like and put to good use is the eval method - take any string and treat it as a piece of code and run it

        I know Rexx and VBScript can also do that and I'm sure they're not the only ones. It's very handy but hardly unique.
        • by Malc ( 1751 )
          No, but the point is is that JS is powerful and useful. The OP was surprised by this.
        • by FLEB ( 312391 )
          Any interpreted scripting language worth its salt usually provides a code-string running mechanism. It's one of the primary benefits of being an interpreted, as opposed to compiled, language. If you're already interpreting uncompiled code, what's more uncompiled code in the mix?
      • by binner1 ( 516856 )
        The term you're looking for is closure [wikipedia.org].

        -Ben
    • by MORB ( 793798 )
      I'm toying around with embeddable language interpreters to use in my current hobby project, and I'm very fond of lua.

      I recently discovered javascript, which I didn't give much attention before, and I was surprised to discover that it's actually a pretty good language. It pretty much does all the things I like in Lua (functional programming among other things), and even a few more things that could be useful to me.

      The downside is that lua currently beats the crap out of it when it comes to performance.
      The ne
      • The downside is that lua currently beats the crap out of it when it comes to performance. The new JIT VM from adobe should reverse this tendency (at least regarding speed, maybe not regarding memory footprint).

        Some speed benchmarks of Tamarin vs. Spidermonkey are here [playercore.com].

        Some additional benchmarks of Flash Player 9 (which is essentially identical to Tamarin in this context) vs SpiderMonkey can be found here [oddhammer.com].
    • Never in my wildest pre-crash dreams did I ever think that Javascript would become a respectable programming language.

      From Javascript: The World's Most Misunderstood Programming Language [crockford.com]:

      Despite its popularity, few know that JavaScript is a very nice dynamic object-oriented general-purpose programming language. How can this be a secret? Why is this language so misunderstood? ...

      ...JavaScript's C-like syntax, including curly braces and the clunky for statement, makes it appear to be an ordinary procedura

  • Oh well, what's the next killer open source app that we use to thumb our noses at the man? This one's been assimilated.
  • Say What? (Score:5, Insightful)

    by AKAImBatman ( 238306 ) * <akaimbatman AT gmail DOT com> on Friday November 10, 2006 @11:29AM (#16793954) Homepage Journal
    On the Mozilla side the plan is to integrate to code with SpiderMonkey which is Mozilla's current JavaScript implementation that is written in C.

    I presume the article means to say that the Tamarin engine will be coupled with SpiderMonkey's APIs? Because I don't see how you could "combine" two separate Javascript engines and expect a usable result. That would be like "combining" Windows and Mac OS X to make a better operating system. It doesn't quite work that way.
    • Re:Say What? (Score:5, Informative)

      by BHearsum ( 325814 ) on Friday November 10, 2006 @11:32AM (#16793990) Homepage
      Tamarin has a JIT compiler for faster execution of a lot of Javascript code. I imagine that is a big part of what is going to be intergrated.
      • by niteice ( 793961 )
        Tamarin has a JIT compiler for faster execution of a lot of Javascript code.
        That's one of the reasons there's no 64-bit Flash. Who wants to bet on Mozilla having an amd64 JIT first?
    • by dsginter ( 104154 ) on Friday November 10, 2006 @11:33AM (#16793992)
      That would be like "combining" Windows and Mac OS X to make a better operating system. It doesn't quite work that way.

      That sound you hear is the thousands of Microsoft Windows programmers kicking the dirt and going back to the drawing board.
    • Re: (Score:1, Informative)

      by Anonymous Coward
      They basically mean combine SpiderMonkey's JavaScript compiler with Tamarin's JIT. So SpiderMonkey ends up compiling the JavaScript code down to some kind of intermediate format (which it already does), feeds that to Tamarin, which generates native code from that.

      It's kind of like the LLVM project's C++ compilers - they took GCC, and modified it to produce LLVM bytecode which could be fed into their own JIT.
    • >That would be like "combining" Windows and Mac OS X to make a better
      >operating system. It doesn't quite work that way.
      FX: Head of Vista development team "Doh!"
    • That would be like "combining" Windows and Mac OS X to make a better operating system. It doesn't quite work that way.

      Why not? OS X is a train wreck of OS 9, BSD, Mach, and NeXT code and it works pretty well.
  • Conspiracy Theories for nerds.
  • What I want to know is when will we actually see any benefits from this?

    From TFA:

    Tamarin is expected to make its Mozilla debut with Mozilla 2. Mozilla 2 is not actually a product release but is the version of the underlying framework. Mozilla 2 is not expected to be ready by 2008 at the earliest. Firefox 3 will be based on the Mozilla 1.9 framework, it is not sure at this time which Firefox release will use the Mozilla 2 framework.

    So we have FX 3 being based on Mozilla 1.9 which means it will most li

    • It has to be that long before it can be implemented. The implementation depends on the ECMAScript 4 specification. ActionScript 3 is based off of that spec while Javascript 1.7 is based on the ECMAScript 3 spec. The reason ECMAScript 4 is so important is that it allows for strong typing of variables. That strong typing allows Tamarin to compile the script down to machine level code. If strong typing is not used then the script must be interpreted at runtime.
    • Gecko 1.9 will be shipped in Firefox 3, currently scheduled for the May or November 2007, depending on which part of the Mozilla Wiki to belive*. From what I understand there are plans to release a Firefox 4 off Gecko 1.9, much like Firefox 1.5 and Firefox 2 are built off Gecko 1.8. So that would put these changes in Firefox 5 time frame, yes this is quite some time away.

      * http://wiki.mozilla.org/Firefox3/Schedule [mozilla.org]
      * http://wiki.mozilla.org/ReleaseRoadmap [mozilla.org]
  • Whether the deal is good or bad, or partly good and partly bad, it is a good example for thinking about what patent protections should be in GPLv3 [fsfe.org].

    A good focus for the discussion, IMO.

  • However, skilled scripters are sure to find ways of optimising performance to get even more gains."

    Like having Samy as your hero.
  • First post ! (Score:2, Interesting)

    by Rastignac ( 1014569 )
    With Tamarin, FireFox will be faster... "First post !" for sure. ;)
  • Good news (Score:3, Informative)

    by WickedLogic ( 314155 ) on Friday November 10, 2006 @11:50AM (#16794188) Journal
    At the ajax experience [theajaxexperience.com] Brendan Eich spoke about this and without mentioning company names. The boost in performance in JS will cement web application's future and will bring javascript to the forefront even more as the power language that it is. Combine that with JSON [json.org] and the module tag [json.org] proposal, it should be some very interesting times.
    • That's swell (Score:1, Interesting)

      by Anonymous Coward
      Now all we need is a solution to the security problem caused by sites having the abilty to run arbitrary script to begin with. Javascript is great language and I look forward to my browser extensions running on a VM with a JIT, however AJAX is still going to be an inaccessible toy.
  • by suv4x4 ( 956391 ) on Friday November 10, 2006 @11:50AM (#16794190)
    For those who don't follow the project tightly, there are indeed a slew of implications.

    On the side of Mozilla, it means much faster, JIT JS engine, and since you know that Firefox's XUL depends heavily on JS to run, it may have big impact on the performance of Firefox as a whole and change the perception some have of Firefox as "bloated" and "slow".

    This is just a guess though. Here's what's really fun.

    Adobe is now working on its next generation "web platform", code named Apollo. Apollo's long term goals are to merge Flash, HTML/JS/CSS and PDF in one single "web platform", for internet applications.

    Apollo is not a browser, you can think of it sort of like the .NET or Java runtime. Or well, Adobe wants you to think that.

    The first version of Apollo is not going to merge all three technologies into one, but it'll integrate them to work together. This means, you can have Apollo app that is based on AJAX with flash in it. Or Flash project with HTML in it. Or, I guess, Flash with PDF in it.. All sorts of combinations.

    Adobe announced that they will NOT develop a browser on their own for Apollo, and that they are researching what to use.

    I'll be honest, I thought it's apparent they'll pick Opera. Opera is faster than Firefox, it's portable to mobile platforms (and this is important to Adobe), and both Macromedia and Adobe have rich partnership with Opera already.

    For example, Dreamweaver's WYSIWYG on Mac used to be Opera for a long time, and maybe it still is (on Windows, as far as I know, it's custom built).

    And even now, the entire help system of Adobe uses built-in Opera browser. Even their "Bridge" image browser, is in fast running on Opera.

    But now, as they contribute big chunks of Flash 9 (the script engine) to Mozilla, it means only one thing: Adobe has decided on a browser.

    Apollo will feature a version of Gecko with Tamarin for a script engine.

    Currently Adobe Reader (PDF) uses SpiderMonkey for its script engine, but when Tamarin is good enough to replace SpikerMonkey in Firefox, it'll be good enough to do it in Adobe Reader.

    Hence, one step forward towards Adobe's vision of unified HTML/Flash/PDF platform. Interesting times.

    • by larkost ( 79011 ) on Friday November 10, 2006 @12:00PM (#16794322)
      Actually, it has been anounced [blogs.com] that Apollo will be based on WebKit, the framework that is behind Apple's Safari. They will be using the open source version rather than Apple's internal version, but the differences are minor.
      • by suv4x4 ( 956391 )
        Actually, it has been anounced that Apollo will be based on WebKit, the framework that is behind Apple's Safari. They will be using the open source version rather than Apple's internal version, but the differences are minor.

        Interesting, didn't know that. It's strange that of all browsers on the market, Adobe will pick the least popular one, and one which needs a lot of work before it even runs on Windows (I know work is being done on it, but it's far from done).
        • by mbwjr12 ( 939334 )
          Yes, but that work is minor compared to fixing Gecko's bloated code base. I'm sure Adobe chose KHTML (That is the real name WebKit) for the same reasons Apple did when building Safari: it's clean, it's fast, and it's standards compliant. I believe that KHTML (as Konqueror on KDE, and Safari on Mac) is the only engine currently passing the ACID2 compliance test. The guys on the KDE team have done an excellent job. In addition, Apple has already shown that it's not a big deal to port KHTML.
          • by Tim C ( 15259 )
            Apple has already shown that it's not a big deal to port KHTML

            Not to belittle their work, but they did "only" port it from one Unix-like system to another. Porting it to Windows will be rather more work, I suspect.
            • Well given that it has already been (partially) done, by one or two people working in their spare time, I doubt it's as difficult as you think.
              See here (it seems to be now defunct, but they did have a working release out at one point):
              http://en.wikipedia.org/wiki/Swift_(web_browser)/ [wikipedia.org]
              • by bdash ( 598142 )
                Just to clear things up a little... The initial port of WebKit to Windows was done by developers that were already active in the WebKit community. This involved refactoring the WebCore library to be less tied to Mac OS X, and implementing Windows-specific portions of the code when required. A small browser-like application named Spinneret was developed for use in testing WebCore on Windows, the first version of which made its way into the WebKit source code repository in January this year.

                For the majority o
      • From the way that blog entry is written it seems webkit and Apple's WebKit are similar only in name. Aren't they different things?
        • by bdash ( 598142 )
          No, the blog post is just worded in a somewhat misleading manner. The text used, "WebKit is an open source web browser engine. WebKit is also the name of the Mac OS X system framework version of the engine that's used by Safari, Dashboard, Mail, and many other OS X applications.", is taken from the homepage of the WebKit project over at http://webkit.org/ [webkit.org]. It is most definitely the same thing used in Safari on Mac OS X.
    • When Macromedia started, they made great tools. They looked at what professional web developers wanted, and made neat tools to fulfil their needs. Unfortunately, for a while now they have been operating in an entirely different manner - they have been deciding where they want the technology to go, and then trying to push tools that fulfil their vision onto web developers.

      This has meant that their core products, such as Dreamweaver and the Flash development application, have been rapidly becoming crappier. D
    • Hence, one step forward towards Adobe's vision of unified HTML/Flash/PDF platform. Interesting times.

      I find this idea a bit scary. HTML, Flash, and PDF do two completely different things, and attempting to combine them is not going to end with a super-browser but with a monstrous train-wreck something like Acrobat Viewer, which inserts buttons in my excel toolbar without asking, takes forever to load and is generally a waste of space.

      This announcement alone doesn't mean that Adobe will take this direction,
      • I find this idea a bit scary. HTML, Flash, and PDF do two completely different things, and attempting to combine them is not going to end with a super-browser but with a monstrous train-wreck something like Acrobat Viewer, which inserts buttons in my excel toolbar without asking, takes forever to load and is generally a waste of space.

        There's not a lot of point in integrating tools that do the same thing. The functions of Flash, PDF, and HTML are complementary. Not that it means any given toolset to work

    • They actually announced they're using WebKit for Apollo.

      http://labs.adobe.com/wiki/index.php/Apollo:develo perfaq [adobe.com]
    • The OpenLaszlo [openlaszlo.org] Legals Project [openlaszlo.org] will benefit immensely from this! OpenLaszlo is in a position to take excellent advantage of the now open source AMV2 JavaScript engine, for the benefit of users as well as developers. Not only will AVM2 make OpenLaszlo applications run faster on Firefox, but opening up the AVM2 virtual machine will make it possible to develop much more powerful debuggers and integrated development environments.

      -Don

      What is OpenLaszlo "Legals" [openlaszlo.org]?

      "Legals" is an OpenLaszlo project to prov

    • I wonder if it also means it will get harder to turn off annoying Flash ads when browsing with Firefox.
  • by sreekotay ( 955693 ) on Friday November 10, 2006 @11:52AM (#16794208) Homepage
    Despite all the harping, .NET has been a huge success for Microsoft in Corporate/Server development. On the desktop, just as MS is afraid of Flash and Firefox (not coincidental or surprising they linked up) obviating the need for , I think Adobe, et al have been concerned about the potential impact of WPF, etc. for what they call the RIA [kotay.com] space.

    Some early benchmarks [kotay.com] comparing SpiderMonkey, what would become Tamarin, and JScript.NET. are on my site [kotay.com]... interesting is that neither CLR, nor Tamarin provide a big boost when you use the features of JavaScript that make it more interesting than just plain old C. Wonder how much a real world boost this will be for the integration complexity? (i.e. is this another Netscape 6? Perhaps buckling down and fixing SpiderMonkey might serve better...)
    --
    graphically speaking [kotay.com]
    • Re: (Score:3, Interesting)

      by laffer1 ( 701823 )
      They might be able to improve the new combined code to execute faster. This whole thing sounds a lot like Java to me. It will be slow starting up and after a page is loaded, it can execute very quickly. Based on recent research for ecommerce sites, I suspect this may have a negative impact on Firefox adoption down the road. The point of JavaScript was to make a lightweight interpreted language that could glue together other components such as plugins, later java, flash and active x controls.

      I understand
      • by Malc ( 1751 )
        Linux wasn't unique in being free. Every heard of Andrew Tanembaum (sp?)?
      • It will be slow starting up and after a page is loaded, it can execute very quickly

        Don't rush to judgement on this without looking at the code. One of the design criteria for the JIT was to avoid this problem. Flash Player 9 (which uses this VM) can load and start executing jitted code very quickly. (Is "jitted" a real word?)
    • by killjoe ( 766577 )
      "Despite all the harping, .NET has been a huge success for Microsoft in Corporate/Server development."

      No it hasn't all they have done is to convert their VB programmers to VB.NET or C# programmers and they VC++ developers to C#. It's not like they converted java programmers or anything. The truth is that VB programmers were going to "upgrade" to anything MS put out no matter what it was.
      • On the desktop - sure, non-existent - but on the server side, I see more and more developers building, from large scale application deployments to startups, doing their apps with .NET - productivity out-weighing other factors (in their opinion, which they back up with their work :)).
        ---
        graphically speaking [kotay.com]
  • About SVG (Score:3, Interesting)

    by supabeast! ( 84658 ) on Friday November 10, 2006 @12:40PM (#16794814)
    From TFA
    I've seen some theories on the Internet suggest that part of the deal with Adobe was to remove the native SVG support from Firefox effectively reducing the competition for Flash.


    There's no need for Adobe to make such a deal. Anyone who has tried using SVG on Firefox knows that the code renders so slowly as to be almost unusable, and lacks support for a tremendous number of SVG features. On top of that Adobe's own staff were always the big force behind SVG, now that Adobe has pulled out of SVG development its safe to say that SVG has no future outside of the tiny community of inkscape users.

    The only way I could see them removing SVG support would be if Adobe ever decided to open source the Flash player but even then I could imagine that this would not be a popular move as SVG is an open standard.


    Aside from the video codecs--which are no doubt entangled in far too many patent issues for Adobe to publish the standards--Flash is just as open as SVG, and it's a shame that open standards pundits refuse to stop pretending otherwise. It makes them sound just as stupid as the HD-DVD evangelists who pretend that HD-DVD is any less proprietary than Blu-Ray, and its hard to convince people that standards-based web development is important when this kind of garbage keeps getting spewed out.

    SVG will eventually get yanked from Firefox not because of sleazy deals between Adobe and the Mozilla foundation, but due to the W3C not being behind SVG, SVG not having enough developers, the majority of SVG content on the web being experimental projects, and lack of software support for animated SVG content.
    • > now that Adobe has pulled out of SVG development

      Adobe Labs [adobe.com] still has some stake in SVG.

      > its safe to say that SVG has no future outside of the tiny community of inkscape users.

      All major browser manufacturers have plans for SVG at the moment, even IE has plans to eventually include SVG.

      > the majority of SVG content on the web being experimental projects

      Yeah, those experimental projects like Google Maps [codedread.com] and Microsoft Live Local [codedread.com] and Dojo [kylescholz.com]...

      And for those who cite that SVG is "bloated" because it's XM
      • by BZ ( 40346 )
        > And for those who cite that SVG is "bloated" because it's XML, maybe you haven't heard of > something called "compression"...

        Compression doesn't help with the bloat caused by having to maintain a DOM.

        Even if you take the SVG Tiny route and not have a DOM, you have to _parse_ said XML. There are libraries for this, but efficient it is not.
    • Re: (Score:3, Informative)

      I can open up an .swf in notepad and see the source?

      I can inline flash elements in my (x)html page?

      I'm allowed to write my own viewer for it?

      BTW... Konqueror has good support for non-animated/non-scripted SVG already. Soon, it will fix those flaws as well. Webkit has about the same level of support, and there's a committment to make SVG a first-class image format for pages. Opera's support is stellar, including the animation/scripting parts. And Firefox isn't too shabby either.

      As far as I know, that's all 4
      • I can open up an .swf in notepad and see the source?

        No, but that question is irrelevant for the vast majority of end-users. Anything complex enough to be worth rendering in SVG isn't going to be something that there's any reason to look at the source for, aside from satisfying the personal curiosity of people with nothing better to do.

        I can inline flash elements in my (x)html page?

        No, but again, why does it matter if you can? Again, this might be a cute idea for a hobbyist, but not for someone with somethin

        • I said:
          I can open up an .swf in notepad and see the source?

          You claimed:
          No, but that question is irrelevant for the vast majority of end-users.

          But originally you had said...

          Aside from the video codecs--...--Flash is just as open as SVG

          So, you're wrong on two counts. One is being fallacious in bring up the vast-majority of end-users, who don't care about open source/standards in the first place. The second, is denying that plain-text-readability is unimportant in the context of this conversation, which is whe
  • by sootman ( 158191 ) on Friday November 10, 2006 @12:51PM (#16794970) Homepage Journal
    I'm a huge fan of SVG. Not because it's a replacement for Flash, but because it's just XML, which means you can create data-based SVG images "out of thin air" with PHP or the scripting language of your choice. But now that Adobe has bought Macromedia (and with it, Flash) it looks like they're going to give up on SVG. [adobe.com] I'm sure their apps will let you save as SVG, but they're going to quit supporting the viewer on 1/1/2008. And theirs was the dominant viewer. Mozilla has native support, and Safari is getting it, but that's nowhere near the adoption rate of MSIE or Flash.*

    I was really hoping that they'd go the other way--that with the purchase of Macromedia, they'd roll SVG support into the hugely popular Flash plug-in. I wish I were wrong, but my guess is that Adobe, just like MS or anyone else, would rather back a proprietary solution (that they own) than an open one.

    * and, the funny thing is, the MSIE/Adobe combination--on Mac and Windows--was the best. You could print a page with lots of embedded SVG images, and it worked! Safari with Adobe's plugin, or Mozilla with the plugin or natively, would print each image on a separate page, if at all. (Though I haven't tested FF 2.0 yet.) But MSIE/Adobe printed just as you saw on screen.
    • I am with you on SVG. My take on it is that it is the browser's job to implement SVG well and it will take off from there. I have tried creating SVG-only pages with Inkscape and it turned out pretty well...
    • by curunir ( 98273 ) *

      ...but because it's just XML, which means you can create data-based SVG images "out of thin air" with PHP or the scripting language of your choice.

      This was never the reason why SVG was promising. There have been imagine manipulation libraries available to scripting languages for a long time. I remember using GD in Perl to create GIF images "out of thin air" as you put it. That was in 1996.

      The strength of SVG is that it's vector-based. This allows developers to produce images that can be resized on-the-f

    • by BZ ( 40346 )
      The problem with SVG is that the working group is more interested in giving cell-phone makers a Flash competitor standard than in actually creating a vector graphics standard. This is why SVG is getting things like network socket APIs while fundamental problems with the "vector graphics" part are ignored.
  • What javaScript needs is optional strong typing and name spaces. If it is to move forward for ajax applications.
    • What javaScript needs is optional strong typing and name spaces.

      It's getting that, and a bunch of other cool stuff, in the ECMAScript 4 version that Tamarin will implement.

      To see the current working proposals for ECMA for, go here: http://developer.mozilla.org/es4/ [mozilla.org]
      • Thanks for the link. Yeah that's nice and all but if it's not going to be supported by M$ it's all moot no?
  • just thought i'd state the obvious...

    good points are that if the co-operation meant better compatability, (if i made a site in go-live then it would definately work in firefox, or firefox could be made to adapt to go-live standard content) then i'd be happy!

    bad news could be that firefox becomes closed source, and this could be a precursor to a buy-out. first, adobe are tempting the execs, getting friendly, and showing them what substantial funding culminates to... then deciding that, somehow, a coropor
    • How would firefox ever become closed source? It's already been released under open source licences, one of which being the GPL, so it would be pretty much impossible to close (as anyone could just start their own fork from the already released codebase, see iceweasal for an example).

      And Adobe are open sourceing Tamarin - so again, no closed source. This is not a trap.

HOLY MACRO!

Working...