A Richer Web: SVG And Canvas In Mozilla
Robert O'Callahan
Lizard Engineer
Today's Web Graphics
- CSS: text, rectangular boxes, border effects, opacity
- Images: JPG, translucent PNGs, animated GIFs
- Flash
- Creatively scripted combinations of the above
The Problem
You can't do this with just HTML/CSS!
(And Flash isn't really what you want here)
More Problems
And SVG alone is not a complete solution...
Overview
Introducing SVG for Web developers
Introducing Canvas for Web developers
Web graphics implementation in Mozilla: past, present and future
Comparing approaches
History lesson
SVG
- W3C standard XML vocabulary for vector graphics
- Elements rect, circle etc
- Mix with other XML (e.g. XHTML) in the same document, via namespaces
- Styleable with CSS
- Becomes part of page DOM
- Scriptable on equal terms with non-SVG content
- CSS rules apply equally to SVG and non-SVG content
- Standalone SVG documents also supported
SVG Demo Walkthrough
- All content and scripting in one file
- CSS and script manage both SVG and non-SVG content
- SVG snippet spices up a "plain old" HTML form
- Degrades gracefully in legacy browsers
- All the W3C goodness: accessible, indexable, standard
SVG Status
- Support in Firefox 1.1 and Opera
- Supported in FF 1.1 at SVG 1.1 level:
- Shapes, paths, transforms, clipping
- Gradients and images
- Basic text
- markers and use
- Scripting and CSS styling
- Still to come: declarative animation, foreignobject, patterns, filters, advanced text
Canvas
- Sometimes the simplest representation of a graphic is a program to draw it
- e.g. fractals, function plotting
- Building a huge DOM can be infeasible
- HTML canvas element: an RGBA pixel buffer with a modern 2D graphics
API for script to draw into
- Bezier paths, affine transforms, translucency, gradients
Canvas Demo Walkthrough
- Too many translucent images for SVG rendering
- canvas more convenient in some cases
- canvas much simpler to implement than SVG
- Specification proceeding via WHATWG
- Support in Firefox 1.1 and Safari
- Gracefully degrades via alternate content <canvas>...</canvas>
Mozilla Graphics Story
The Story So Far
- 99% of the Web: solid rectangles, tiled/translucent/scaled images, antialiased text
- ~= mid-90's Windows/Mac/X11 graphics API
- No problem: wrap platform APIs and away we go
- Except for CSS 'opacity'; gross hack
- Performance with tiled/scaled/translucent always a problem
- Printing always weak; e.g. with translucency
Challenges
- SVG/canvas require far more functionality
- Beziers, rotations, scaling, gradients, translucency, pixel-processing effects and more
- Powerful graphics processors in most machines, but focused on 3D API
- Competitors bringing it all together
- How to provide rich hardware accelerated graphics without rewriting the universe?
- Needs to be open source, cross platform, and great
A Solution

cairographics.org
- Open source graphics library providing most necessary functionality
- Compatible open source license
- Community backing (e.g. GTK+)
- Cross-platform
- Offers OpenGL backend ("Glitz")
cairo In Gecko 1.8/Firefox 1.1
- canvas and SVG implementations based on cairo
- No acceleration; software-only render-to-bitmap
- Non-cairo SVG renderers (e.g. GDI+) also implemented
- Watching progress of cairo on Windows before making decision
- Non-canvas, non-SVG rendering uses existing wrapped platform APIs
Implementing SVG foreignobject
- foreignobject allows non-SVG content (e.g. XHTML) to appear inside SVG
- SVG effects should apply to the content
- Rotating, zooming, translucent, drop-shadowed HTML pages, anyone?
- Offers truly "first class" rich graphics: not confined to DOM leaves
- Requires a unified rendering stack
cairo In Gecko 1.9
- Stop using platform 2D APIs, start using cairo to
render all content
- Solves the foreignobject problem
- Benefits for regular Web browsing:
- Hardware acceleration applies to regular HTML
- Higher quality (e.g. bilinear image scaling)
- Work well under way!
Alternatives
- Web developers have other options...
Alternative: Carry On As Usual
- Who needs eye-candy anyway? "Just the content, ma'am."
- Then the Web will be replaced by something else
- Perhaps you will be replaced by someone else
- Maybe not a good idea
Alternative: Flash
- A great product
- Flash content is not part of the page DOM
- Requires separate file packaging, tools, techniques
- Hard to script directly from page
- Flash is leaf only; can't contain HTML
- Lacks standards goodness
Alternative/History Lesson: VML
- Microsoft SVG-ish vector XML vocabulary ca. 1998
- Never took off beyond Office interchange format
- Can SVG do better? Yes!
- Broader tool support (e.g. Illustrator)
- Stronger mixed-document model (VML tied to nonstandard XMLNS)
- Timing! Rich Web apps appear relatively recently;
world wasn't ready in 1998 (consider XMLHttpRequest)
- Hardware accelerated implementations
Conclusion
- Rich graphics coming to the Web now
- SVG and canvas offer complementary functionality
- Graceful degradation supports incremental rollout
- Web sites can be modernized incrementally
- Now it's up to Web developers to show us what the future looks like