You need an HTML CANVAS addon
A <CANVAS>scrapbook:
Exploring the HTML5 CANVAS element

Collected examples

My examples

Other's examples (locally cached and slightly modified)

Other examples (remote)



non-native support

alternatives and related links

Released: Fri Dec 25 2007; John S. Urban

I've lost my share of time wrapped up in the HTML CANVAS/ SVG / VML / WebCGM /Adobe PDF /FLASH .... battle for the hearts of developers and users who are trying to create web-based (or at least web-friendly) vector-based graphics. I've learned a few things while sorting through these options. What follows is a (currently ongoing) chronical of what I have experienced while exploring the role of the HTML CANVAS element.

First, I created a CANVAS driver for the simple C/Fortran-centric VOGLE graphics library. I have only tested the driver with the opera(1) and firefox(1) browsers at this point. I found that the HTML5 CANVAS element standard lets me produce a static vector-based plot quite satisfactorily with a small amount of intellectual capital and time required to do the development, assuming I have a higher-level library or product generating the file. The lines display nicely anti-aliased in the browsers I tried (although the HTML5 specification does not appear to require that). I'm convinced any product that currently can produce simple vector-based graphics output can quickly be changed to produce CANVAS files.

I use my version of the VOGLE library very heavily. The driver is useful. So far so good. But I'm hoping for more than a high-resolution snapshot of my VOGLE plots. And who can leave well-enough alone? So I added rescaling features. The results of the 1.2 driver are in the sample file vogle4.html . Then I manually edited the file and added a few other things manually (the info+ mode and the monochrome mode and the "points" options).

I am fortunate that my graphics library of choice supports software dash codes and stroked fonts because the CANVAS element is a little too simple. Absolutely no native text support? No dashcode support? no points? No object definition or display list? One polygon fill algorithm? Well, if being simple means CANVAS elements can quickly become a part of the HTML standard and be widely adopted I can live with those limits (look how nice and simple HTML 2.0 was). Someone can muck it up and make it way too complicated later. So at least I can get as far as I could with a pen plotter years ago.

First and foremost -- are CANVAS elements really going to be supported by all graphic browsers? Well, if anything is this will be. It's proposed as part of HTML5 and is so simple you have to be hard-pressed to justify not doing it. You write a browser that supports JavaScript and VML or SVG and CSS style sheets and plug-ins and you can't support this? Universal support is such a key issue that I have no need to go further if I don't think a CANVAS element will become as standard as an HTML IMG element.

What about animation and panning and zooming? Can I make a GUI with a CANVAS that's better than a simple HTML form? Are their GUI-builders for this? Can I make utilities to dynamically draw graphs and plots? How interactive can I make my interfaces? How about interfaces to server-side codes and client-side applications? Any chance any editor or tool is going to let me read a document with CANVAS elements and edit the graphics interactively? How popular is this solution? How long will it be supported? More importantly, can I do it more simply (or maintainably or flexibly or portably) than if I use Java applets or VML or SVG or FLASH or Adobe PDF or whatever comes out next week? It looks like it's easy enough to find out at least a few answers by simply trying them.

Why hold out hope?

You will note a thread of pessisism. I remember when Display PostScript seemed to solve a lot of the needs a CANVAS element appears to address; then IGES and CGM files; Tcl/Tk; VRML; OpenGL; Java/Applets ... As I've mentioned, I've looked at other solutions that do everything a CANVAS element does and then some. The VOGLE library could already write a simple PostScript, CGM, Adobe PDF, SVG or VML file, for example. So what value do I see in a CANVAS element?

As I alluded to, potential "universality" is the primary appeal; the (theoretically) human-readable text-based simplicity has it's uses and attractions; and the easy access from JavaScript and integration with HTML is the other significantly appealing feature. It is nice to have the option to add the graphics right into a single HTML file with the text. If CANVAS elements are destined to be part of HTML5 my hopes are high that CANVAS plots should soon work in any graphical browser. That's a big plus. Everyone will have the display platform. And what about (some) of the missing basic features? I can extend the CANVAS vocabulary with JavaScript routines. I've got routines around that draw dashed lines and vector-based fonts like the classic Hershey fonts. So if something simple is not there I can add it, or maybe find it.

Of course, all roads lead to the non-proprietary browser interface, and that is where we find the CANVAS element. And we've established that the apparent simplicty is misleading because the sum of the parts (other HTML elements, JavaScript, CSS, ...) is greater than the whole and all that. So the ever-expanding great integrator (the extensible open-standards "Internet Browser") is coming through. But some red flags immediately become apparent as you browse for CANVAS resources on the Web. Why isn't there a larger collection of JavaScript "CANVAS" routine links off what appear to be the main CANVAS references (, ) for example? This CANVAS element has been out there for a while.

A few notes on the most unexpected things I found while making the VOGLE driver before I move on...


What's my perspective? The most exciting thing about the HTML CANVAS element is that it complements JavaScript instead of creating yet another complex standard from scratch, that the plots can be placed directly into a single HTML document, and that it is simple and can be edited with a text editor. You can pretty much know everything there is to know about drawing static HTML CANVAS elements in a few hours. The entire specification is a few pages. Figuring out how it integrates with JavaScript and HTML, what you can do with CSS to style borders and positions and such, and whether browser implementations let you get fancy (portability, animation, performance, memory or size limits, ....)? A couple of days of putz`in and browsing Internet examples should suffice to answer your questions.

Something on my list is to see if I can make a large number of components displayed in <IFRAME> elements using different products talk to each other and process files on both the server and client efficiently and securely. That is, I still want Unix in a browser.

FOOTNOTES: When you do not want the plot data integral to the document

While sometimes being in-line is an advantage, occasionally I want something in a separate file like SVG or IMG files; especially if it is something I can reuse. There are at least two straight-forward solutions -- make an HTML file that just shows the CANVAS and then use it in other documents with an IFRAME element, or make everything into a javascript *.js file.and include it with a HTML SCRIPT element. The following clock is completely defined in a separate file and invoked with a simple IFRAME element, for instance.

If the clock and solar system examples are not running as animations and you are using the opera(1) browser try re-loading the page (until I find a solution for this problem).

On the other hand, this demo is based on overlaying images instead of drawing vectors. Click on the graphic and slide it up with the arrow keys to read about some portability issues I encountered ...

And of course there is the obligatory "Conway's Game of ".

I really need to evaluate the GOOGLE excanvas.js interface that uses VML (mostly) to process CANVAS elements.