Posted on by Brendan Eich

Mozilla Developer Day Slides

The slides that shaver and I presented at last Friday’s Mozilla Developer Day are up now.

As presented at dev-day, these slides nicely demonstrated support for Apple’s canvas tag, embedded in Mozilla as <xul:canvas> and implemented using Cairo (a static PNG of the clock and animated stars must stand in for now, in the published slides, but you can view source to see the starbar.js script and related source). Thanks go to vlad and stuart for their heroic efforts hacking up <canvas> support.

As vlad pointed out, you can think of <canvas> as a programmable image tag. In that light, it’s reminiscent of the XBM images generated using <img src="javascript:genxbm()"> tricks developed by Bill Dortch back in the Netscape 2 era. All of which is to say, we really should have implemented this kind of tag in 1995, but both the management and hacker cultures then at Netscape deferred to Java for programmable graphics and other such features. What’s ironic is that this left most web designers reaching for Flash, not for Java, as the browser and Java-in-the-client wars played out.

The WHAT Working Group is considering standardizing <canvas>, with the goal of interoperating implementations based on the standard. My hope is that this is done both well, and quickly, in keeping with the WHATWG charter.

People ask about how SVG in Mozilla and <canvas> relate. The short answer is that they don’t, except that both must work well in all dimensions (complete and fast alpha-blending, e.g.) on top of a common graphics substrate, which looks likely to be Cairo.

A longer answer could compare and contrast <canvas>‘s non-persistent, procedural, PostScript-y rendering API with SVG’s declarative markup and persistent DOM. The upshot is that SVG and <canvas> complement one another, catering to fairly distinct requirements and authoring audiences.

One crucial fact to keep in mind: <canvas> support is tiny compared to the implementation of any known profile of SVG, so it will be easy to justify adding <canvas> support to default builds of Mozilla products. SVG should be supported in the same way as XForms and other, bulkier implementations of standards not yet seen much on the web: as a one-click download-and-install package that extends Gecko. I’ve asked top hackers to look into generalized support for such Gecko extensions, based on XTF, with versioning and update management a la Firefox’s extensions.

I’ll blog separately about the other points of interest raised in these slides.

/be

13 Replies to “Mozilla Developer Day Slides”

  1. > SVG should be supported in the same way as XForms
    > and other, bulkier implementations of standards
    > not yet seen much on the web: as a one-click
    > download-and-install package that extends Gecko.
    Yet, as is demonstrated on https://www.croczilla.com/xtf, XTF+SVG is really the killer combination. It makes it possible to drop in support for other graphically represented MLs. XTF alone isn’t enough. You need a way to graphically render the tag afterall! 😉
    XTF+SVG is not the only answer. can be substituted for SVG in many cases, but when it comes to using XTF to build graphical objects that can support drag-n-drop and other complex UI, SVG with its underlying DOM may be invaluable. So, it may be wise to include SVG (some profile) as part of our base substrate to facilitate a more extensible rendering engine.
    -Darin

  3. Darin: exactly what came to mind after dev-day: with <canvas>, or perhaps better, with Cairo scriptable APIs, plus XTF and XBL or a sane merger of the two, do we need the full weight of SVG? Certainly not of SVG 1.2 — but what about the Tiny profile?
    There’s a trade-off between exposing Cairo to script and binding languages such as XTF and XBL, and making SVG the base. Sometimes one will want the SVG DOM. But there are other cases (I believe Apple has shown some at WWDC) where all you need is a rendering area and point-targeted events.
    /be

  4. To finish the thought, if any hot, new composite markup language needs SVG for its primitives, one-click download/install still wins.
    The reason I favor making SVG, XForms, and similar neo-standards download-on-demand is that most Firefox users will not need these formats, for the next year at least. Sure, some intranet and select-user/volunteer-effect exceptions will crop up — thereby proving the rule.
    If we monitor enough downloads, we will have the best data possible to decide whether to bundle a neo-standard in the default build, to boot!
    /be

  5. One big difference between SVG and is that individual SVG elements can have event handlers, focus, etc, but with only the canvas element itself can. So authors will prefer SVG for interactivity.

  6. how about a Firefox Home Edition & a Firefox Pro Edition ;P
    seriously though, i love the idea of Gecko extensions, but it’d be nice to have a beefy Firefox packaged for corporate users who will be more likely to run into SVG & XForms on their Intranet sites.

  7. I saw one interesting UI : non-rectangle window.
    I always interested in window media player. I can choose many different skins, like radio, space ship. Real and QT have no competion in this feature.

  8. Rob: I agree, authors will certainly prefer SVG for many good reasons, but they may not choose SVG over canvas for all event-handling graphics apps — consider 2D games.
    Also, SVG in a compound document won’t be supported across browsers soon, but whatwg.org willing, <canvas> may. Many authors prefer what works across browsers, without plugins.
    /be

  9. Canvas is very interesting.. I like the light weight/client side nature of it. One thing I seem be to be missing in the samples/doc is if you can style it with CSS. If it’s not possible, then I’d say it’s something to consider adding. If it’s possible, how would it work? Thanks!
    -Andrew

  10. Andrew: the Canvas element can be styled with borders, etc. as with an img element; it can also have an opacity and a compose operator to indicate how it should be rendered onto the underlying surface. Other than that, I’m not sure what else you’d consider styling?

  11. Has anyone looked at Roger Critchlow’s Javascript-Generated PNG images recently? GPL’d… It’s been around for six years.
    I wonder how client-side-generated PNG might relate to a canvas tag.

  12. I’ve been wanting canvas for years, since I first saw a simple demo of it from Joe Hewitt. I think SVG and canvas can live together very easily – with the rise of retro and 2d games on the web, having something like a canvas tag could really vault web-gaming to a new level – especially when plugins and activex controls are growing more unsafe. I’d give alot to have canvas showing up in the regular builds.

Comments are closed.