Well over four years ago Opera made the first native SVG implementation, with the first useful implementation the following year, and Safari and Mozilla got into the game. By 2007 SVG became a browser business and earlier limited use of SVG faded into the background. Roughly at the same time Safari came up with Canvas. Then as now SVG was commonly seen as the more conscientious but awkward elder brother of Canvas. …

Back then SVG was an almost foreign element in the browser world, and there were strong anti-browser sentiments among many SVG propagandists. Now all browsers support SVG, albeit imperfectly. Well, with the one usual exception, allowing us all to dump on Internet Explorer. SVG has by now moved from the desert into the fold, one of us, but not yet a citizen. SVG is in HTML5, not on the same level as Canvas is, but yet it is there.

The sibling rivalry with Canvas is one thing, integration with HTML another. Canvas and SVG are related, if distantly like arthropods and vertebrates are related. SVG may have a separate identity and a spinal chord, but how well does it work in an HTML body? Three years ago I called for a Web 2.1: Making it whole again. For there to be an SVG 2.1 there would first have to be an SVG 2.0, but from the view of integration there are some questions left to be asked.

• What is the SVG relationship with Canvas?
• What is the SVG relationship with HTML5?
• What is the SVG relationship with CSS3?
• What is the SVG DOM relationship with the full DOM?

What in SVG is working well? What is missing? What is superfluous? What is malformed? While SVG has many slots for metadata, there is preciously little semantic information, when is a collection of elements a tiger, when is it a connected group of boxes? How accessible is SVG? Is it more or less so than Canvas?

In short what have we learned from the six years of SVG 1.1 or six months of SVG 1.2 Tiny? How can we make this better? How can we make this work?