There has been a ton of speculation on SVG and its relationship (or lack thereof) to Avalon. Here is some thoughts on that, collected from various responses I've made or others have made.
- Our rendering model is very much like that of SVG. We support a hierarchical compositing model with transforms that affect items in the hiearchy.
- Our markup isn't the same mostly because XAML is a direct reflection of the programming model. There is a very solid relationship between the markup and the objects and methods.
- Our OM doesn't match the SVG DOM because we choose to go with an object model that more closely matches what we think our users expect. Specifically, we tried hard to make sure that our object model provided a certain amount of consistency with WinForms (and VB and MFC before it) and ASP.Net. Beyond this, our object model is strongly typed where much of the SVG DOM is based around strings.
-
WVG is a term that we are no longer using and isn't, in my opinion, very useful.
We were supposed to have scrubbed this from our documentation, but apparently we missed
some stuff. There is no strick subset of Avalon objects and XAML markup that
stands on its own with respect to vector graphics.
- Whereas when using SVG inside of XHTML there is a very bright line, when using a vector graphic element in a UI authored in XAML, there is no sharp line. You can put a Rectangle element, for example, in flow with a document without a Canvas element. To do a similar thing with XHTML/SVG, you would need to wrap all SVG content in an SVG element.
- For Avalon, the set of properties and property types is the same between vector graphics elements and other elements. In this way the background property for a Button is of type Brush -- the same as the fill property for a Rectangle.
- There are elements that can very easily be seen to belong to both a control subset and a vector graphics subset. For example, Image makes sense in a UI sense but also in a VG sense. XHTML and SVG both have image elements. We avoid this duplicity. Text is another area where we avoid a large amount of duplication.
- While we share a rendering model with SVG to a large extent, our support and features don't match up completely. Some of it is stuff that we haven't implemented yet and others are due to choices that we've made because of programming model concerns. I'll try to put together a guide on this stuff at some point in the future.
I'm sure there are questions around SVG and XAML/Avalon that I haven't answered here. Post in the comments and I'll update this post with the latest and greatest.