Support SVG elements in XAML
The high-level ask is to support using SVG within a XAML tree. The SVG data may be inline or loaded from a source (local file or remote from the web)
There are few current tools for converting SVG to WPF/Silverlight-based XAML but they fall short when dealing with more complex SVG data.
Here are a few scenarios:
- Apps loading svg content from a remote web server. This should work just like any other kind of image data. Remote xaml isn’t likely allowed, and even if it were, there’d be resistance to providing vector art in two formats when SVG is a standard.
o Some SVG files may be dynamically generated by a remote server
- SVG data loaded in a XAML view may have internal named elements.
o I would imagine that there’d be a way to access the internal elements from code to manipulate them and attach event handlers (hover/touch, etc), change properties (color, opacity, etc).
- There’s a lot of free source SVG files that usable under creative commons on Wikipedia for things like US maps, electoral districts and many other rich features.
o It’s a huge time saver to piggyback on those assets. For example, suppose you wanted to color a US map by probability of each electoral district voting a certain way. This is easily done with some reference data & SVG from Wikipedia. Problem is there’s no way to easily manipulate this within a XAML app
- I would hope that an SVG-renderer element would use similar hardware acceleration that the HTML5 renderers use
- Manual conversion to XAML is an extra step in the workflow and leads to duplication of assets. A designer may keep tweaking the source image and must keep generating that XAML. That xaml would then need to be copied into a resource dictionary and can’t be a separate file resource (can it?)
This is done and now is in Windows 10 Creators Update
need full support
Martin Suchan commented
The support for SVG files is very limited - cannot open some basic svg files, not possible to scale them in a lossless manner, not possible to use svg files in BitmapIcon.UriSource .Right now it's just easier for us to keep using .png in 5 sizes.
@dan. Can you provide a repro? Ai file, project that fails to work, what exact format, ...
I need a lot more to go on to file a bug
Dan Guthrie commented
Love the new SVG support but it seems like the feature is not fully baked. Images do not appear in the designer, the size is not read from the file, export format from AI has to be very specific, etc. Are there plans to flush SVG support out more fully?
Is there, or will there be, an equivalent mechanism to the SvgImageSource class for use in stand-alone WPF applications (i.e. not using the desktop bridge to access the Universal API)?
@T.P. -- on your use of SVG for button icons, have you looked at using PathIcon within the AppBarButton? It supports the changing of colors using foreground/background already.
Thanks for the continued feedback. The SVG support we have in Creator's Update is equivalent to the secure static mode from SVG spec: https://svgwg.org/specs/integration/#secure-static-mode.
T. P. commented
I agree with Shawn. I use many SVGs (via Path) to supplement the font icons (Segoe MDL2 Assets) and use them in UIElements. Currently the color of those icons is static and does not respond to changes of the Visual State of the UIElement (such as Disabled on a Button or IsChecked on a AppBarToggleButton). So what I do right now is to edit the UIElement's Template and accordingly adjust the Fill Property of the Path. However, this is a workaround that could break when Templates change over different Windows versions. Also, the workaround doesn't work on PivotItem Headers right now. Also, to use the workaround with the new method (displaying SVGs in Images) there must be a way to change the SVGs color in the VisualState Storyboards.
Not sure how I communicated using it in AU?
Yes to both and more. As Oren mentioned "I would imagine that there’d be a way to access the internal elements from code to manipulate them and attach event handlers (hover/touch, etc), change properties (color, opacity, etc)". With the current approach of setting the source of an Image it doesn't seem that any of this is going to be possible. SVG support is more than just display an image, it's complete manipulation of the elements.
@Shawn, you can't do what he showed today in Windows 10 Anniversary Update. What he showed requires Creators Update.
For manipulating the SVG, are you talking like animate it or update the paths in the SVG during runtime? I don't have that info handy right now. I would open a new UV item to accommodate that.
Clint, will we be able to manipulate the SVG? Is the DeveloperDay demo, it looked like an image would be created from the SVG. This is something I can already do today. True SVG support is the ability to manipulate the elements
I thought I could use the power of a converted svg with animations and now it turns out that the whole bunch of DrawingGroup, DrawingImage, GeometryDrawing doesn't exist....
Mike Marynowski commented
There are troves of icon and vector resources available in SVG and essentially none available in XAML...in an age where we are expected to develop DPI independent apps I'm astounded that the industry standard vector format isn't supported yet on either WPF or UWP.
Thanks for taking this feature under review. SVG is now the "de facto" standard for vector graphics elements and icons.
For example popular apps like Viber uses SVG files for their animated stickers:
As developers we need to be able to drop an SVG animated icon like that in XAML, resize/scale, and start/stop the animation programmatically via methods.
Tim Heuer commented
To clarify a few comments here. Windows and the browser *do* support SVG. The comments of other platforms natively supporting SVG in their native stacks should be clarified as not all of them actually do. There are a few 3rd party/OSS libraries that encapsulate capabilities on other platforms but a lot of them use the underlying web platform as well. This isn't an excuse for us not to consider this work, but just wanted to clarify the ecosystem here.
Why is this still not an option? I just spend hours trying to convert an svg icon to work in a Windows UWP. This should not be hard.... Come on. No wonder noone builds apps for your platform.
agree with Shawn Kendrot, all platform support svg except uwp.
support svg will bring more android/ios developer to uwp platform.
Please support SMIL animations in XAML. SMIL is the best declarative language for animations in the world, there is nothing like it. It's so powerful and still human readable. And offers advanced timing and perfect synchronization between animations and sound effects, something very rare even in closed and proprietary software animation formats. SMIL is the THE standard format for animations, used both for the Web as part of SVG:
… and as the official OpenDocument format for animations and graphic effects:
Currently you cannot include SMIL and SVG animated images in XAML, and in IE you need to use a polyfill based on the web animation standard to run SMIL animations. Eric Willigers from Google has created the official SMIL polyfill implemented entirely on the Web Animations API. You can find it here:
But the web animation standard is NOT a declarative language for animations, you still need SMIL to describe animations in browsers.
Many professional animation packages can import, edit and save directly in SMIL. With SMIL support you can do in minutes things that would require days to do otherwise. It also provides an universal interchange format for animations. SMIL is the "lingua franca" of vector animation. Please support it if you want to make XAML capable of amazing animations.
SVG is standard for all browsers, all OS systems. Only Windows has to work around by creating XAML paths. SVG needs to be supported if we want to bring people over to Windows
Domagoj Pavlešić commented
We all get asset files from designers, and the easiest way is just to include those files in the project, and replace when the change is needed. Unfortunately, most of designers don't care about XAML, and SVG is pretty common on the web these days so it makes a perfect sense.
SVG support would make our lives much easier, designers would be happier (no need to prepare images in different scales) and users would get crisper UI. Triple win :-)