Canvas is a very simple API, much like what we’ve proposed to Khronos for 3D support. It’s well-scoped, well understood and integrates very well with other web technologies. And it’s been getting a huge amount of traction on the web. People are writing all kinds of really neat technology on top of it, including useful re-usable libraries for visualization. Have a look through Google’s own promotional site for Chrome - a huge number of them use canvas. It has traction. And we’ve gone through a couple of iterations - we’ve added support for text and a couple of other odds and ends once we understood what people were trying to do with it.
Now compare this to SVG and SMIL. Each of those specs are multi-hundred page documents with very large APIs and descriptions of how to translate their retained-mode graphics into something that’s usable on the web. (SVG 1.1 is a 719 page PDF. SVG 1.2 Tiny is 449 pages. The spec for SMIL is a 2.7MB HTML file.) We’ve seen some implementation of SVG and SMIL in browsers, but it’s been slow in coming and hasn’t seen full interoperability testing nor any real pick up on the web. The model for these specs was wrong, and I think it shows.
Chris doesn’t directly say that Google’s approach is “wrong”, but he wonders if the Google proposal of a bigger and more ambitious API would represent too great a compatibility burden for browser vendors and developers.
In the comments of his post, Henry Bridge of the Google O3D team replied; here’s a lightly edited excerpt:
We agree that to keep a standards process focused, APIs should be as minimal as possible while remaining useful, and so we would likely keep things like that out of any first attempt at a standard and, as you say, let it evolve over time. But the usefulness question brings up an important, and we think, unresolved point. We’d love to build the animation and skinning system in JS, but we just couldn’t get a JS-based animation system fast enough — even on our retained-mode API. Javascript is getting faster all the time and we love that, but until someone builds some apps it’ll be hard to know what’s fast enough.
Standardizing [an Open GL-like] immediate mode API for JS makes total sense. It’s a well defined problem, lots of people know GL, and we think it will be useful. But some of the demos we wrote _already_ don’t run well without a modern JS implementation, and moving to [Open GL] won’t help that (but we’d love to be proven wrong). That’s why we think it makes sense to explore both an immediate and a retained mode 3D, and make sure they work well together.
Cool things are finally happening with SVG these days. It's showing up natively in browsers (including Firefox, Safari, Opera, Chrome and more). It's natively supported on the iPhone, and work is happening in various open source communities to create options for Internet Explorer. Google uses it under the covers in Google Maps (to create vector line drawings showing where to go); Google Docs (for drawing into presentations); and more. Wikipedia, one of the top web sites on the Internet, has a huge repository of SVG images, while many tools such as Inkscape, Illustrator, and Visio can either export to SVG or work with it natively. Vector graphics support through SVG and Canvas is consistently one of the top voted requests by developers.
Since more and more is happening with SVG these days, we thought it would be great to host the SVG Open 2009 conference this fall in Mountain View at the Google campus from October 2-4, 2009. The theme this year is "SVG coming of age".
We are looking for contributors to present papers or teach courses. Presenters are asked to submit an extended abstract in English with an approximate length of 400 to 800 words by May 15 to http://www.svgopen.org/. The abstracts are reviewed by a reviewing committee and presenters will be informed about acceptance on or before June 26. If your abstract is accepted, you will be asked to submit your full paper by August 31, according to instructions that will be sent to you.
On Friday, the SVG and CSS working groups of the W3C published the first working drafts of Apple's proposed graphics and styling extensions:
The CSS and SVG Working Groups delivered today
five new specifications for public review, aimed at enabling more compelling content creation with open Web technologies. The five drafts are: SVG Transforms 1.0, Part 2: Language, CSS 2D Transforms Module Level 3, CSS 3D Transforms Module Level 3, CSS Animations Module Level 3, and CSS Transitions Module Level 3.
SVG Transforms allows two-dimensional objects to be transformed using three-dimensional transformations.
CSS 2D Transforms allows elements rendered by CSS to be transformed in two-dimensional space. CSS 3D Transforms extends CSS Transforms to allow elements rendered by CSS to be transformed in three-dimensional space. CSS Animations allow an author to modify CSS property values over time. CSS Transitions allows property changes in CSS values to occur smoothly over a specified duration.
The groups are working closely together to make implementing and authoring these features easy and consistent across Web languages.
Learn more about the Style Activity and Graphics Activity.
Thanks to Harry Underwood for pointing this out to us!
Probably the most requested CSS feature of designers is being able to use custom fonts on web sites. Right now the only real way of doing that cross-browser is relying on Flash, either by building the whole page in it or by using the "Scalable Inman Flash Replacement" or short SIFR script. This does the job for most people but Simo Kinnunen wanted to avoid having to use proprietary software and go for canvas instead to reach the same goal.
Absolutely no plugins required - Everything needed to display Cufón is already available by default in your visitor’s browser. Rather than requiring flash to make the switch, Cufón relies simply on javascript alone.
Compatibility - Cufón runs on IE6, 7, 8, Firefox and the latest version of Safari. On other unsupported browsers (IE5-, Safari 2) it will fail gracefully.
Ease of use - Little or no configuration required.
Speed - Cufón is quick. It loads almost instantly with no ‘flicker’ that you would normally experience with sIFR.
Technically Cufón is a web interface to fontforge and creates an SVG font on the fly from your source font using a JavaScript renderer.
Visually this is pretty cool, however now we need to give it the same rigorous poking we gave SIFR over the years: what does it do in terms of accessibility, usability (copy and pasting text), scaling of text and most importantly overall page performance?
The other problem of course is copyright of font faces, and this is a much harder issue to tackle. Another solution with the same approach, typeface.js had issues with that in the past and this will not be different.
I was reading a Washington Post article when I saw a cool diagram at the bottom of the page:
I did the standard 'right-click' test to see if it was Flash, and was surprised to find it wasn't. Digging deeper, I found that they are using SVG on the page to render an interactive graph where you can find out more on the subjects mentioned in the article. Here is a screenshot of Firebug going into the content of the diagram, showing that it is SVG:
Clicking one of the subject circles updates some extra content below the diagram with further articles:
Juraj Sukop has created a fun project called Typism that lets you build fonts on the Web:
typism is a web-based font editor. It is a public site where anyone can create a font for others to use and to study, to modify and to copy. You write the description of a typeface, design the outlines of a glyph, track the development history and publish any revision in human-readable format to store locally. All it takes to run it is a browser supporting a few open standards.
Typism uses SVG (We don't JUST love Canvas ;) and runs on Google App Engine. The project is open source too so you can check it all out!
Over in SproutCore land, they have been talking about Peter Bergstrom and his amazing work with Canvas and SVG:
Peter Bergstrom has been doing some amazing work with SVG and canvas tags in his SproutCore-based these project called PaperCube. PaperCube visualizes citations their relationships between authors. Watching the videos of his project, you’d swear he was using Flash or Silverlight, but its not. He’s using only native web technologies powered by SproutCore and JavaScript. It’s a great example of what’s possible using the browser’s capabilities today.
There is something ironic about an SVG editor written in Flash, but this preview by Tiago Cardoso, written using the inEvo SVG engine is fun to check out. It uses SVG natively and has some cool features like gesture recognition and shape recognition.
I got the demo working in Firefox 3, though there were some glitches in Safari 3. As a cool aside, when I was uploading the screencast above YouTube transparently saw that I have Gears installed and used it to give me better upload feedback ("Uploading... 31%") and resumability (Disclosure: I work for Google and with the Gears team):
Screenshot Uploading Blobular Screencast Using YouTube
Next on our round-the-web update is a cool graphing library named Bluff, taglined "Beautiful graphs in JavaScript":
Bluff is a JavaScript port of the Gruff graphing library for Ruby. It is designed to support all the features of Gruff with minimal dependencies; the only third-party scripts you need to run it are a copy of JS.Class (about 2kb gzipped) and a copy of Google’s ExCanvas to support canvas in Internet Explorer. Both these scripts are supplied with the Bluff download. Bluff itself is around 8kb gzipped.
To draw a graph, you create a new Bluff graph object using the id of a canvas element on the page, set some options, add the data and labels, then tell the graph to draw. A basic example:
KDE 4 is the latest release of the KDE software stack. One of the most notable changes in KDE 4 is a pervasive usage of SVG. SVG files are used for themes, icons, storage system and transport. They are at the beating heart of beauty of the KDE 4 interfaces.
Furthermore, the whole graphics stack utilized by KDE has been heavily influenced by the SVG standard. A new Free Software graphics driver model, called Gallium3D, has been written in order to utilize modern graphics hardware for accelerating API's such as OpenVG and OpenGL to assure real time rendering of SVG files using minimum amount of resources. On top of that the Qt library, which KDE is layered upon, has a graphics API fully compatible with the SVG rendering model.
To cope with variety of uses of the SVG technology KDE comes with two SVG rendering engines. Th SVG 1.2 Tiny [SVG12] compliant QtSvg library, which is meant to be a minimal rendering engine, suitable for things like icons, and QtWebKit's SVG which is a full SVG engine.
KDE 4 has just begun its existence and almost every day engineers working on it come up with new and creative ideas, tools and use cases for how to better utilize SVG. Unlike most of the technologies leveraging SVG, KDE's focus is on interactivity and animation. A whole set of tools and utilities has been developed to aid that goal. The best example of such uncommon usage of the SVG standard is the Plasma [Plasma] project, which comes with its own animation framework layered on top of the SVG rendering model.
The openness of the SVG standard aided by the creativity of the Free Software engineers created something truly unique and exceptional.
Finally, here is something that will blow your mind (I'm still trying to wrap my mind around this one); someone has been working on getting Microsoft's XAML/WPF technologies to render in the browser without Silverlight using.... SVG:
This post is basically a pre-announcement...in my spare time, I’ve also been working on another system based around the same ideas, except this time based on the SVG implementations supplied by browsers, along with JavaScript.
It’s called Firelight, and the github wiki is here.
Think of it as a Silverlight-like implementation with some WPF thrown in, with no plugin. Just a JS file and a little initialization code. It loads almost instantly (it’s smaller than jquery for the time being, although it’s unlikely to stay that way) and immediately goes to work. And it will directly benefit from performance work being done in browser SVG, DOM, and Javascript implementations.
Since I don’t expect any of you to go grovel around that stream of consciousness wiki page, here’s a tiny demo of some of the core infrastructure in firelight: http://squeedlyspooch.com/firelight/xaml.xhtml. The xaml file which is loaded by that page is here. Note the event triggers on the smaller gradient filled canvas. Try mousing over it and clicking it.
That demo (as the wiki states) works in Firefox version 3.x, Safari (windows, at least) 3.1.2, and on the iPhone (that part I get a real kick out of). Opera has some issues with some of my code, and so I have some issues with Opera. But I’ll get it working there too soon (makes sense, since last I checked it had the most compliant version of SVG available.)
Dylan Schiemann wrote about how disappointing it was that the iPhone didn't support SVG:
Safari on the iPhone does not currently have support for SVG. Safari 3 beta on Mac and Windows is currently the best browser on the planet for SVG performance, so this is a somewhat disappointing omission. We are hopeful that by the end of the year, the iPhone will receive the Safari 3 upgrade, and along with that native support for SVG. For now, we’ll have to wait on dynamic charting and drawing tools due to no SVG and the lack of mousemove event handlers.
It appears that if you point your iPhone 2.1 browser to SVG content and tests it now works!
This work landed on trunk last week. I’ve also submitted my proposal to the SVG WG for standardization. I hope that they’ll like it; there aren’t many degrees of freedom here, for example there’s no new syntax to decide on, so there’s not much to fight over :-). And it’s good for SVG to be able to use its effects more broadly. We’ll change our implementation to match whatever the WG decides.
Unfortunately we don’t yet support external document references, so the elements describing SVG effects have to live in the same document as the elements to which they’re applied. This limits the usefulness of these effects in regular (non-XHTML) HTML for now. But we’ll fix that so that the effects can live in an external SVG file.
Tom Trenka has a fantastic post on custom fonts with dojo.gfx that shows the SVG font definition implementation.
Part one of the article deals with painful, practical issues around the licensing of fonts. Tom discusses the various technical options out there, and then gets to the solution:
In general, the issues surrounding font usage have to do with the ability for someone to visit a web site, grab a specific file, and be able to reuse it without paying for a legitimate copy within any of the most commonly used programs (such as Office). Because of this concern, both the EOT and sIFR techniques work–because the fonts are embedded in a form that is not reusable in a common way.
One approach: the SVG Font Specification
Similarly, the SVG Font specification allows for the same concept—by working with a specific font definition, especially one that can be customized for the specific usage, the spec avoids most of the prickly issues surrounding licensing.
SVG fonts are relatively simple in concept; within the <defs> element, you define the main specifications of a font, and then you include specific glyph definitions. Optionally, you can include character-specific kerning information (the space between letters); some fonts include this type of hinting, and the SVG specification supports it.
I recently ran across Inkscape, an open source very high-quality graphics editor that can output SVG that I'm blown away by. Even better, it runs on Linux, Windows, and Mac OS X. From the Inkscape website:
[Inkscape is] an Open Source vector graphics editor, with capabilities similar to Illustrator, CorelDraw, or Xara X, using the W3C standard Scalable Vector Graphics (SVG) file format.
Inkscape supports many advanced SVG features (markers, clones, alpha blending, etc.) and great care is taken in designing a streamlined interface. It is very easy to edit nodes, perform complex path operations, trace bitmaps and much more. We also aim to maintain a thriving user and developer community by using open, community-oriented development.
Here's a screenshot looking at one of the samples, a vector image of a car; there are a huge number of great tools in this beastie:
Screenshot of Inkscape showing vector image of car
One of the coolest features of Inkscape is it can take a bitmap image, and do tracing of the edges to create a vector representation! Vector images are inherently more "impressionistic"; they are for more illustration type purposes. I decided to take this feature for a spin and took a photograph I have of myself and do edge detection. Here is the photograph before, loaded into Inkscape ready to process:
Inkscape with bitmap, non-vector photograph
Here are the results after playing around with the various options; on the right-hand side of the screen is the options dialog that you can use to fiddle around with the various settings for edge detection:
Screenshot of Inkscape with traced, vector representation
Now, I can save this into an SVG file suitable for the web. I could then edit the markup, or bring it onto a web-page. More on embedding SVG in a future post.
One of the strengths of SVG is that it is a file format suitable for exporting such things; while the Canvas tag is great for having a canvas that JavaScript can draw onto, you can't easily export illustrations into calls to a Canvas as you can with SVG.
As part of the Open Web Advocacy work I've started with Dion and others at Google, one of my goals right now is to help increase awareness and support around doing 2-D/vector graphics on the open web. This includes tools such as the Canvas tag, SVG (Scalable Vector Graphics, an XML markup language for vector graphics), and open source cross-browser drawing toolkits such as Dojo GFX, ExplorerCanvas, and Raphael.
One of the big reasons for this is that 2-D drawing/vector graphics is the top requested feature by double the amount of other feature requests in the recent Open Ajax Alliance Browser Feature Wish List vote-off. As part of this effort I'm doing a bootcamp right now to come up to speed on the latest developments in both Canvas and SVG. I've been using Shelley Powers excellent Painting the Web book to find out the state of vector graphics on the web in 2008. During this education I've run across two interesting things.
First, I wanted to know what the status of SVG support is across the different browsers. I found Jeff Schiller's very complete SVG Test Suite results that are actively kept up to date:
SVG 1.1 became a W3C recommendation on January 13, 2003. Five years later, this page records my results of running various SVG implementations (web browsers and browser plugins) through the official SVG Test Suite. Last updated 2008-06-18.
A screenshot with some of the results:
SVG Test Results Against Browsers for SVG 1.1
Things are pretty good with Firefox 3, Safari 3, and the winner, Opera. There is a strong subset of SVG that can be used cross-browser with these. Of course, Internet Explorer is the limiting factor here, with a grand score of 0% for all tests:
Internet Explorer SVG Support
This means that for open web vector graphics to be realistic we need some kind of shim for Internet Explorer (Adobe used to have a browser plugin for IE that had very high quality, but its quite large and was end of lifed in 2007). Internet Explorer actually has an earlier vector graphics standard named VML (Vector Markup Language) that can be used to 'trick' it into having 2-D graphics support that is used by a number of open source toolkits. However, VML can run into some performance issues when you start to get into a large number of nodes and animation with the available open source drawing toolkits.
One natural avenue is to emulate SVG or other 2-D graphics on Internet Explorer using Flash. I had always heard about this possibility but recently found a small company actually doing it to good effect. They have not finished yet, but their demo is impressive:
SVG Render Using Flash
Here we are viewing the source of the SVG being rendered by this Flash:
SVG Renderer in Flash (View Source)
I emailed the developers to get some more information on this Flash-based renderer and they responded:
Our SVG viewer and editor is not open source. It will be part of the new InputDraw version and with some more features - like draw recognition - will be part of the new Comics Sketch site, so users can create advanced comics strips.
We are part of a small company in Lisbon, Portugal named inEvo that works with a lot of web development, rich interfaces and other areas like computer graphics and artificial intelligence.
While I respect the hard work it took inEvo to create this and their need to charge for it, it looks like using Flash to emulate SVG is a valid approach for Internet Explorer and it would be great to have something similar available open source. Just the basic viewer being available would make sense as open source and would probably even drive more business to them for their higher level tools; it looks like inEvo has created lots of cool things above this that make sense as being commercial-only, such as an SVG editor, drawing recognition, social comics creation and sharing site, etc.
Dmitry Baranovskiy of Atlassian has created Raphaël "a small JavaScript library that should simplify your work with vector graphics on the web. In case you want to create your own specific chart or image crop-n-rotate widget, you can simply achieve it with this library."
Raphaël uses SVG and VML as a base for graphics creation. Because of that every created object is a DOM object so you can attach JavScript event handlers or modify objects later. Raphaël’s goal is to provide an adapter that will make drawing cross-browser and easy. Currently library supports Firefox 3.0+, Safari 3.0+, Opera 9.5+ and Internet Explorer 6.0+.
