"Rather than embracing SVG as an alternative, Microsoft pursued a blatant copy of Flash in their too-late-to-the-table Silverlight effort."
The author seems to have missed, apart from an initial mention, VML out completely. VML was Microsoft's SVG alternative in IE 5 through 8, not Sliverlight. Sliverlight was a Flash alternative.
VML, although badly documented, can/could do much of what SVG can do, in a few cases it does it better. It was also pretty complete with IE 6 in 2001. SVG had the first very basic version in Firefox 1.5 at the end of 2005, and needed Firefox 3.0 in 2008 before you could say it was reasonably complete. MS thought they had a head-start and could win the vector battle.
The key thing, as well, with VML is that it was built into IE natively. Getting Adobe SVG or Sliverlight added onto IE into large corporate environments was near on impossible. We, fortunately, decided we didn't trust Adobe prior to them killing the IE SVG plugin and were running fully on VML at that point.
The last 10 years of my working life have been based around SVG and VML, my co-founder and I would tell you a similar story. Especially, regarding word-wrap in SVG, it's our top pain point as well. It forced us to use HTML as foreign objects in SVG to get word wrap. Of course, IE never supported FOs, Edge has only just added it.
I found a discussion of Microsoft on 2004, why they copied all SVG elements and capitalized them: "SVG has its own set of conventions for element and attribute names that is at odds with the existing .NET Framework class library." https://msdn.microsoft.com/en-us/library/aa480164.aspx#avalo...
A frequently asked question is: Why doesn't Avalon just use SVG? On the face of it, it seems strange to invent a new way of representing vector graphics in markup when a standard already exists. However, the principal advantage of these shape classes is that they have been designed to integrate into the Avalon programming model. The vector drawing elements derive from the same FrameworkElement base class as all other XAML elements, and follow the same naming conventions. SVG has its own set of conventions for element and attribute names that is at odds with the existing .NET Framework class library. Furthermore, SVG elements were not designed to fit into the Avalon object model. By not using SVG, Avalon ensures that vector graphics can be mixed in with any other kind of markup in your XAML, and can take advantage of all of the same layout facilities. (Note that in the version of the Longhorn SDK documentation released at the 2003 PDC, the XAML elements used for vector drawing are sometimes referred to collectively as WVG (Windows Vector Graphics). However, Microsoft is no longer using this name, because it implies, incorrectly, that these elements are somehow distinct from all of the other elements supported by Avalon.)
Which is a lot more than just "SVG has its own set of conventions for element and attribute names that is at odds with the existing .NET Framework class library.".
Silverlight was probably the last major Microsoft attempt at platform lock-in, but it was too late; arguably it was killed by Apple's platform lock-in barrier on iOS just as much as Flash was.
He mentions VML almost right out of the gate, here didn't he? "I have followed the standards for XML-based vector graphics closely. PGML (mainly from Adobe) and VML (mainly from Microsoft),"
Thanks. Yeah I didn't really see VML as relevant after its very inception. True it was sitting there in IE for an extra decade or two but it never had some sort of resurgence or potential that I saw. Silverlight on the other hand had serious people saying "this is the future!" When VML first came out, it had to be taken seriously. Next to PGML, not so much.
He forgot about Microsoft's first attempt at making a Flash/vector competitor, Liquid Motion[1]. It was out around the same time Flash 3/4 started taking off. They later tried again with Silverlight which was a nice effort but horrible timing with mobile about to kill plugins just a couple years later.
Liquid Motion seemed like it could do some damage as DHTML was huge from IE 3/4 and it had the developers on their side because Netscape was wallowing and sucked (document.layers), but they just dropped it. They also did that with tablets and phones so Microsoft usually needs a successful example they can innovate on it seems, otherwise they fumble a bit.
I had the bad judgement to build my VR app on top of Liquid Motion.
Then Microsoft bought Dimension-X (acquihire) and tubed the product, leaving me an orphan. Liquid Motion greatly boosted the mindshare for Java. An OpenGL code base written in Java validated both technologies. So of course it had to die.
For Sun's part, they went the full quixotic with Java 3D, for years refusing to acknowledge anyone would want to use just OpenGL as is. But for its time, Java 3D was the J2EE of scene graph libraries [ducks].
Source: I helped former Liquid Motion employee "Alligator Descartes" design and implement the first public Java OpenGL bindings called "Magician", which was copied by JOGL and others.
I had some visual analytics tools that ran "canvas" on IE6 in 2008 thanks to VML. Never did pure VML but it was a nice crutch to have if you wanted to get very experimental and very cross-browser.
Not to mention performance (or lack thereof). Adobe SVG on a PIII/P4 was like running Photoshop on a 486SX; a small-radius Gaussian blur, like for a drop shadow, would peg the CPU for several minutes even on a simple shape.
since no one's done it yet, i'll mention Raphaël [1] that has served for a long time to provide a single interface to SVG w/VML fallback back to ie6. (supporting only svg features that can be supported/mimicked in vml)
But it is now end of life. The people behind it went on to Snap.svg[1]. Raphaël was great for VML fallback but now that is no longer needed. It is interesting to see just how many people Adobe has hired that worked on SVG (and projects around it like Raphaël). When I was at Teespring, we used Raphaël and some plugins in the web-based design editor before we wrote our own equivalent (without VML support).
The huge pain point in SVG is fonts. Native SVG fonts died. Trying to do exact pixel-perfect layout in SVG for text is now very difficult. See trying to measure the width of a string in a given font.
by "people" you mean Dmitry, who was hired by Adobe and subsequently wrote Snap.svg (perhaps with others, though he seems to be the primary maintainer of both libs)
I didn't name names because I didn't recall who did what. But when we were looking for people with SVG experience, I went down the contributor list to both projects and something like the top 10 were all now at Adobe. This is my recollection from over a year ago so I may have some details slightly wrong.
I think the more interesting aspect is that Adobe hires so many developers with vector graphics experience that it is harder to find them in the SF Bay Area (from the talent pool who is interested/willing to work at a startup). Obviously, this is conjecture.
But definitely a huge thanks to Dmitry for his work and for sharing it.
I was involved early with SVG. I was the Javascript test engineer at Adobe for their plugin, and I sat in on some of the working group meetings. When I left I found the marketing department had been raiding my tests for marketing content, so I contracted back to them and built a couple cool demos for adobe.com/svg.
Years later I was interviewing and my interviewer asked me a lot of questions about one example in particular. It turns out he had run across an example and it was exactly what they wanted for their project, but they didn't understand the math. He had tried to find me with no luck, going so far as to call Adobe and find my coordinator who refused to give out my name.
I opened the sample for him (it was still up), clicked on View Source and pointed to the first line that said "Author: [My fairly unique name]". His response was "DAMN IT! It was that easy?!?!?!"
Animations have also been a pain point for me - part of the problem being the lack of SMIL support in some browsers as well as differing behavior and support with regards to CSS animations.
IE SVG render support was very fast, thanks to their expertise with the older VML format. Chrome, Safari and Firefox were slower in SVG rendering (thousands of nodes), but had faster Canvas rendering.
I have a few projects where allowing users to upload SVG files like other image types would be useful, but SVGs can contain javascript, so allowing straight SVGs is an XSS vulnerability. I don't know what the correct way is to strip javascript out of SVG files. There must be some library which can parse an SVG, keep only whitelisted non-Javascript-containing properties, and write out the file again, but I can't find it. (What does Wikipedia use?)
I think his concern is- since the security program would need to run on the attacker's computer, the attacker may simply opt not to use it, circumvent it. That being said, I don't see why it can't be used to sanitize requests to the server.
Well, if you are worried about xss, that is a case of an attacker's code running on a victim's machine. If they process svgs through the lib before adding them to the dom, that would be one way to prevent the xss attack. This seems to be what DOMPurify are suggesting based on their documentation.
I don't think the idea is that the sanitization happens on the client when they submit content. The client can do the sanitization when they view content. Often it will make sense for the server to do it, but sometimes not. Imagine you're writing an email client web app against someone else's API, and their API gives you the raw html of email messages that people have sent to you. Then it's the client's job to sanitize that HTML for rendering.
Also you can run that library on the server with node.
You're right it's the publishing platform, but it is also my laziness. I don't know if it's the Wordpress theme I'm using or the SVG plugin I tried, but I have yet to get fluent at using SVG in this Wordpress blog: ironically it seemed to work fine on desktop but didn't resize well on mobile. I'll give it another try.
I think a lot of credit for SVG's resurrection goes to Mike Bostock for making it the core of his visualization technology. Obviously D3 is the big SVG thing now, but his 2009 work on Protovis also relied on SVG, as did Polymaps in 2010.
I argued with Mike back then that SVG was a bad choice because it didn't work in MSIE and it was sort of a forgotten technology everywhere else. Fortunately he didn't pay any attention to me. SVG is particularly handy because it lets Javascript create and alter graphics using a DOM representation. That's something you really can't do in Canvas or WebGL without reinventing parts of what DOM does.
I suggest that SVG missed it's true calling - as a modern vector animation platform. D3 is a good example of that kind of use, but I think it had a lot more potential. The ability to debug your graphics as elements can be very useful, and you get a lot of functionality built-in (e.g. DOM events).
As an example, see this unfinished asteroids SVG I wrote in '09 (before <canvas> was generally available):
(seriously, it's not actually a finished game - damage is disabled, there's no levels/etc, but you can move with the arrows, shoot with space, (useless) shield on x)
The problem was the (slow) reflow every time you changed the DOM. I tried a few ideas to batch changes or pre-allocating elements, but browsers just couldn't run it consistently smooth enough at the time. It's somewhat better now - maybe I should actually finish it...
Agreed. I would love to see web apps start moving to SVG. I am not a web developer myself so I could be wrong, but having played with SVG a bit, it seems SO much more suitable for making web apps than the HTML5/CSS morass we are stuck in now.
For SVG to truly rise, it needs better font/text support. It should be easy to programmatically determine the width of a string of text in a given font. Unfortunately, it is not. You can go look how libraries like D3.js do it. But ultimately, pixel-perfect text with SVG is difficult/impossible. I'd really like to know if I'm wrong about that.
On the positive side, ReactJS plays great with SVG. I'm working on some basic line charts that I want ReactJS-managed so I can render them server-side too. My line chart isn't done but I tried the server-side rendering and it's working great.
Have you tried them though? Now check it out with kerning and/or italics. Do you see overhanging when you draw the rectangular box found via the API? Good example is strings that end with a character like f.
Works in theory. In practice, it does not. That is what I found but again, I'd be happy to be wrong.
When working on it a year ago at another employer, we had a list of edge cases. I don't recall them all but some were off by quite a bit. Enough so that the work around was to do everything in SVG except text and use plain DOM position on top for text. That was a bit better. It would be wonderful to do everything in SVG.
Indeed. I just noticed yesterday that the text labels in an svg graph I'd created are changed in size by the Firefox browser. They were too big and overlapping things! Huh? Lowering my "minimum font size" pref fixed the issue.
A great way to "snatch defeat from the jaws of victory," re scalable graphics.
The only thing holding back SVG is laptops. Most phones have enough pixel density that SVGs look great and are the right choice for most non-text, non-photo assets. But pixel density is low enough on most laptops that they look fuzzy. Low-end tablets have the same issue but no one really cares about hi-if experiences on those devices.
I think it often comes down to what's the easiest asset workflow that gets us a good result. From that perspective, 1x raster + 2x raster is less work than 1x raster + SVG
That is strictly true, but the beauty of a bitmap is that you can make it look better by rendering at a larger size and then scaling down. Effectively multisampling by hand. You can also do this as a preprocessing path in your asset pipeline and get better looking results than just using an SVG outright.
This is what we do for the cards at http://greenfelt.net. We lose a lot of detail in the face cards when we render them directly to the correct size as SVGs, especially at small sizes. There's a price to pay, of course, and it's a slightly more blurry look.
Another tangentially related but interesting fact is that every card set we have rendered as a pngcrushed png (except for the absolute largest size) is a smaller than the SVG source code.
It's pretty much the opposite. Too much anti-aliasing. At low resolutions, you need to be aware of the pixel boundaries to really make an image look good. Think 8-bit Nintendo/"pixel" art. You can't simply anti-alias a vector image down to a 8x10 pixel sprite. You just end up with a blurry mess.
Set your coordinates to 0.5 positions instead of whole pixels and look at the differences. Like if you draw a line from 100,100 to 200,200 try 100.5,100.5 to 200.5,200.5
For a quick glance, take a look at this nasty ultra-dense rendering in FF/Chrome and compare it to IE: http://projects.voanews.com/ebola-tracker/ (uses raphaeljs so renders in SVG or VML, whichever is supported.)
Because bitmaps target a specific resolution they can be tweaked so that features are aligned to pixel boundaries resulting in less anti-aliasing.
Truetype fonts are an example of a vector format that can still look sharp at arbitrary resolutions because they can include hinting programs that align the control points to pixel boundaries. This is why fonts tend to look sharper on Windows and Linux than MacOS X. Linux and Windows default to strong hinting, and MacOS X uses only slight hinting, preferring accurate shapes to sharpness.
> Linux and Windows default to strong hinting, and MacOS X uses only slight hinting, preferring accurate shapes to sharpness.
I know you already know these things, but for the sake of discussion (or other people).
Linux allows you configure hinting. It's true that by default (depending on how you define default) you get no hinting, but no reasonable distribution that I know of has shipped with that default for the past 7 years. Quite the opposite in my experience. Linux fonts (thankfully) look more like OS X fonts than Windows fonts.
Unfortunately, this configuration usually happens in some Gnome/Unity/XFCE/KDE configuration format, so if you want to use a better window manager with no DE, you sometimes have to recreate this from scratch, although, as someone who obsesses over font rendering and doesn't like the DEs, this is easier now than in 2000.
And then you have Google Chrome who just ships with its own font rendering. Gah.
I see a big security problem with SVG: browsers allow executing scripts in SVG files in site security context, so you have to check for a lot of script execution vectors in SVG before you allow uploading user files.
If you host SVG file on the same domain as the main site, I can give a direct link to the SVG file and your browser will execute arbitrary JavaScript in that context.
I think in that case setting the CSP sandbox header to "allow-scripts" would have the same effect as the iframe sandbox attribute and allow script execution in the SVG but prevent same-origin access and various other things.
Where is native support for iOS and Android? Why do we bother generating the same assets for different screen densities? Am I the only one who wants SVGs on mobile?
Apple & Xcode support the same concept, but with PDFs. You can add a PDF to an "imageset", and at build time it will be rasterized into different resolutions for different devices.
Because you have to basically implement half a browser for SVG. You need to parse the XML into a DOM and apply CSS that you also need to parse (also javascript in case of animated SVGs that use JS)
SVG specification distinguishes two types of conforming SVG viewers: static and dynamic [1]. The static viewer does not have to support scripting, animations and user interaction.
A good example of a relatively small static SVG viewer/renderer is libRSVG which is used by GNOME project to render icons.
The main size is dealing with libxml, but that's readily handled by smaller xml libraries [http://pugixml.org]. I mean, maybe you don't want to do SVG on an arduino.
Directly comparing SVG and PNG libraries purely based on library size is misleading. PNG's aren't layered, don't contain semantic information, etc. For me librsvg is lightweight since its way better than installing phantomjs as I have been doing to generate embedable PNGs for documents.
One of the things I like about hybrid apps (Cordova, Ionic, etc) is that this is a solved problem since you basically develop on top of Chromium (Android) and WKWebView (iOS). I already do heavy use of SVGs on mobile apps for everything, including animations, and I'm quite happy with the results and the workflow. No more asset-hell, everything's a vector.
Design once in Illustrator (export SVGs) -> Code once -> Run everywhere
Android supports a sub-set of SVG in its VectorDrawable and AnimatedVectorDrawable classes. There is also tooling to convert SVG into VectorDrawables.
It is definitely a partial subset and creating VectorDrawables from any sort of design program is a giant PITA. The best strategy is making an SVG and then going through the XML by hand and turning it into a drawable (ugly I know).
Clearly this is the future direction of Android, but as of today it is still only half implemented.
As for why we didn't have SVG from day 1 on Android, I'm going to guess that is all a performance optimization. It's hard to overstate just how slow & weak early smart phones (iPhone & Android) were relative to today. We've expanded the scope of the apps to fill the available resources (as software engineers always do), but now there is enough head room to handle it all.
This and the android device fragmentation (yes, also for resolutions and pixel density) is what pushed me to start replacing raster images for SVGs in all my web and hybrid mobile apps. I guess being quite good at Illustrator helped me to make the jump.
I don't bother using jpg's, png's of gifs anymore. Whenever I can, I use vector designs exported to SVGs (backgrounds, custom iconfonts, logos, shapes, animations, etc...)
That's a great point. I was talking with Doug Schepers and when I noted the resurgence of SVG that's what he said... "oh, I think the Retina screens brought it back" - it is true, SVG is beautiful on Retina screens, there are SVG Test Suite examples where the raster "it's supposed to look like this" image looks very bad next to the SVG side on a retina display. But I think the ubiquity of SVG in browsers was clearly happening before retina screens were widespread. No doubt it is a factor in adoption.
Corel had a serious SVG effort during this early period around 2002-2004. They created a SVG Viewer and tooling around an initiative known as Smart Graphics.
2. WebGL and even Canvas are significantly more performant. I realize that's comparing apples and oranges... Still, if I had a choice for any data visualization project today I'd use WebGL rendering, or ThreeJS etc.
WebGL and even Canvas are significantly more performant.
It did seem rather unfair of the article to bash Microsoft/IE so much over SVG support, when actually today the performance and sometimes rendering quality in IE is dramatically better than the likes of Chrome and Firefox.
But in any case, you're right, performance is a significant real world concern if you're using SVG for anything beyond very simple diagrams or line art.
We use SVG all over the place, but then we have the great privilege of being able to tell our clients to only use modern browsers. It's pretty nice to be able to specify one graphic for use at all pixel densities that never gets blurry.
Oh yeah. I work for a web agency and, if I could, I would just stop using images and use only SVG. Sadly, we still need to push some visuals as large.jpg + mobile.jpg and use media query...
"Rather than embracing SVG as an alternative, Microsoft pursued a blatant copy of Flash in their too-late-to-the-table Silverlight effort."
The author seems to have missed, apart from an initial mention, VML out completely. VML was Microsoft's SVG alternative in IE 5 through 8, not Sliverlight. Sliverlight was a Flash alternative.
VML, although badly documented, can/could do much of what SVG can do, in a few cases it does it better. It was also pretty complete with IE 6 in 2001. SVG had the first very basic version in Firefox 1.5 at the end of 2005, and needed Firefox 3.0 in 2008 before you could say it was reasonably complete. MS thought they had a head-start and could win the vector battle.
The key thing, as well, with VML is that it was built into IE natively. Getting Adobe SVG or Sliverlight added onto IE into large corporate environments was near on impossible. We, fortunately, decided we didn't trust Adobe prior to them killing the IE SVG plugin and were running fully on VML at that point.
The last 10 years of my working life have been based around SVG and VML, my co-founder and I would tell you a similar story. Especially, regarding word-wrap in SVG, it's our top pain point as well. It forced us to use HTML as foreign objects in SVG to get word wrap. Of course, IE never supported FOs, Edge has only just added it.
If I remember correct, Silverlight started as Windows Vector Graphics, a Capitalised copy of all the svg elements.
I found a discussion of Microsoft on 2004, why they copied all SVG elements and capitalized them: "SVG has its own set of conventions for element and attribute names that is at odds with the existing .NET Framework class library." https://msdn.microsoft.com/en-us/library/aa480164.aspx#avalo...
Wow. Translation: Not Invented Here.
It's not Enterprise Ready until it is SillyCapsed.
To be clear, the entire quote is:
Which is a lot more than just "SVG has its own set of conventions for element and attribute names that is at odds with the existing .NET Framework class library.".
Interestingly, "VML is Microsoft's contribution to the creation of the SVG standard." I'd never heard of it either.
https://msdn.microsoft.com/en-us/library/bb250524%28v=vs.85%...
Silverlight was probably the last major Microsoft attempt at platform lock-in, but it was too late; arguably it was killed by Apple's platform lock-in barrier on iOS just as much as Flash was.
He mentions VML almost right out of the gate, here didn't he? "I have followed the standards for XML-based vector graphics closely. PGML (mainly from Adobe) and VML (mainly from Microsoft),"
Thanks. Yeah I didn't really see VML as relevant after its very inception. True it was sitting there in IE for an extra decade or two but it never had some sort of resurgence or potential that I saw. Silverlight on the other hand had serious people saying "this is the future!" When VML first came out, it had to be taken seriously. Next to PGML, not so much.
I am sad to report that it is still in active use in state-of-the-art HTML email. Only way to do rounded corners in Outlook.
Yea, Word 2000 and later is famous for VML and other IE-specific features in the HTML output, and Outlook 2007 and later uses Word for HTML email.
He forgot about Microsoft's first attempt at making a Flash/vector competitor, Liquid Motion[1]. It was out around the same time Flash 3/4 started taking off. They later tried again with Silverlight which was a nice effort but horrible timing with mobile about to kill plugins just a couple years later.
Liquid Motion seemed like it could do some damage as DHTML was huge from IE 3/4 and it had the developers on their side because Netscape was wallowing and sucked (document.layers), but they just dropped it. They also did that with tablets and phones so Microsoft usually needs a successful example they can innovate on it seems, otherwise they fumble a bit.
[1] https://en.wikipedia.org/wiki/Microsoft_Liquid_Motion
I had the bad judgement to build my VR app on top of Liquid Motion.
Then Microsoft bought Dimension-X (acquihire) and tubed the product, leaving me an orphan. Liquid Motion greatly boosted the mindshare for Java. An OpenGL code base written in Java validated both technologies. So of course it had to die.
For Sun's part, they went the full quixotic with Java 3D, for years refusing to acknowledge anyone would want to use just OpenGL as is. But for its time, Java 3D was the J2EE of scene graph libraries [ducks].
Source: I helped former Liquid Motion employee "Alligator Descartes" design and implement the first public Java OpenGL bindings called "Magician", which was copied by JOGL and others.
VML was great when you wanted to do canvas-like things with IE6 Back In The Day: http://excanvas.sourceforge.net/
I had some visual analytics tools that ran "canvas" on IE6 in 2008 thanks to VML. Never did pure VML but it was a nice crutch to have if you wanted to get very experimental and very cross-browser.
Not to mention performance (or lack thereof). Adobe SVG on a PIII/P4 was like running Photoshop on a 486SX; a small-radius Gaussian blur, like for a drop shadow, would peg the CPU for several minutes even on a simple shape.
since no one's done it yet, i'll mention Raphaël [1] that has served for a long time to provide a single interface to SVG w/VML fallback back to ie6. (supporting only svg features that can be supported/mimicked in vml)
[1] http://raphaeljs.com/
But it is now end of life. The people behind it went on to Snap.svg[1]. Raphaël was great for VML fallback but now that is no longer needed. It is interesting to see just how many people Adobe has hired that worked on SVG (and projects around it like Raphaël). When I was at Teespring, we used Raphaël and some plugins in the web-based design editor before we wrote our own equivalent (without VML support).
The huge pain point in SVG is fonts. Native SVG fonts died. Trying to do exact pixel-perfect layout in SVG for text is now very difficult. See trying to measure the width of a string in a given font.
http://snapsvg.io/
by "people" you mean Dmitry, who was hired by Adobe and subsequently wrote Snap.svg (perhaps with others, though he seems to be the primary maintainer of both libs)
I didn't name names because I didn't recall who did what. But when we were looking for people with SVG experience, I went down the contributor list to both projects and something like the top 10 were all now at Adobe. This is my recollection from over a year ago so I may have some details slightly wrong.
I think the more interesting aspect is that Adobe hires so many developers with vector graphics experience that it is harder to find them in the SF Bay Area (from the talent pool who is interested/willing to work at a startup). Obviously, this is conjecture.
But definitely a huge thanks to Dmitry for his work and for sharing it.
I was involved early with SVG. I was the Javascript test engineer at Adobe for their plugin, and I sat in on some of the working group meetings. When I left I found the marketing department had been raiding my tests for marketing content, so I contracted back to them and built a couple cool demos for adobe.com/svg.
Years later I was interviewing and my interviewer asked me a lot of questions about one example in particular. It turns out he had run across an example and it was exactly what they wanted for their project, but they didn't understand the math. He had tried to find me with no luck, going so far as to call Adobe and find my coordinator who refused to give out my name.
I opened the sample for him (it was still up), clicked on View Source and pointed to the first line that said "Author: [My fairly unique name]". His response was "DAMN IT! It was that easy?!?!?!"
love stories like that
Animations have also been a pain point for me - part of the problem being the lack of SMIL support in some browsers as well as differing behavior and support with regards to CSS animations.
IE SVG render support was very fast, thanks to their expertise with the older VML format. Chrome, Safari and Firefox were slower in SVG rendering (thousands of nodes), but had faster Canvas rendering.
An article about rise of SVG with numerous images of SVG drawings, and not a single one of them is an actual SVG :)
Maybe because the publishing platform he uses doesn't support uploading/pasting it (e.g escapes xml).
...making the irony [of them being a graphics publishing platform outfit] that much thicker
I have a few projects where allowing users to upload SVG files like other image types would be useful, but SVGs can contain javascript, so allowing straight SVGs is an XSS vulnerability. I don't know what the correct way is to strip javascript out of SVG files. There must be some library which can parse an SVG, keep only whitelisted non-Javascript-containing properties, and write out the file again, but I can't find it. (What does Wikipedia use?)
https://github.com/cure53/DOMPurify
Perfect, thanks! I looked for a long time before and couldn't find anything that seemed right.
Yeah because sanitizing client side is a great idea.
Serious question: whats wrong with that?
I think his concern is- since the security program would need to run on the attacker's computer, the attacker may simply opt not to use it, circumvent it. That being said, I don't see why it can't be used to sanitize requests to the server.
The main reason is that the server is more often than not NOT Javascript based.
Well, if you are worried about xss, that is a case of an attacker's code running on a victim's machine. If they process svgs through the lib before adding them to the dom, that would be one way to prevent the xss attack. This seems to be what DOMPurify are suggesting based on their documentation.
yeah, i dunno why they market the lib so heavily for client-side use. but it's 2015 - js is as much server as it is client
I don't think the idea is that the sanitization happens on the client when they submit content. The client can do the sanitization when they view content. Often it will make sense for the server to do it, but sometimes not. Imagine you're writing an email client web app against someone else's API, and their API gives you the raw html of email messages that people have sent to you. Then it's the client's job to sanitize that HTML for rendering.
Also you can run that library on the server with node.
You're right it's the publishing platform, but it is also my laziness. I don't know if it's the Wordpress theme I'm using or the SVG plugin I tried, but I have yet to get fluent at using SVG in this Wordpress blog: ironically it seemed to work fine on desktop but didn't resize well on mobile. I'll give it another try.
I think a lot of credit for SVG's resurrection goes to Mike Bostock for making it the core of his visualization technology. Obviously D3 is the big SVG thing now, but his 2009 work on Protovis also relied on SVG, as did Polymaps in 2010.
I argued with Mike back then that SVG was a bad choice because it didn't work in MSIE and it was sort of a forgotten technology everywhere else. Fortunately he didn't pay any attention to me. SVG is particularly handy because it lets Javascript create and alter graphics using a DOM representation. That's something you really can't do in Canvas or WebGL without reinventing parts of what DOM does.
I suggest that SVG missed it's true calling - as a modern vector animation platform. D3 is a good example of that kind of use, but I think it had a lot more potential. The ability to debug your graphics as elements can be very useful, and you get a lot of functionality built-in (e.g. DOM events).
As an example, see this unfinished asteroids SVG I wrote in '09 (before <canvas> was generally available):
http://public.codenazi.fastmail.fm/asteroids_dynamic.svg
(seriously, it's not actually a finished game - damage is disabled, there's no levels/etc, but you can move with the arrows, shoot with space, (useless) shield on x)
The problem was the (slow) reflow every time you changed the DOM. I tried a few ideas to batch changes or pre-allocating elements, but browsers just couldn't run it consistently smooth enough at the time. It's somewhat better now - maybe I should actually finish it...
Agreed. I would love to see web apps start moving to SVG. I am not a web developer myself so I could be wrong, but having played with SVG a bit, it seems SO much more suitable for making web apps than the HTML5/CSS morass we are stuck in now.
Wow this is great, I didn't even know this was possible. Would you happen to have any good resources for this stuff?
For SVG to truly rise, it needs better font/text support. It should be easy to programmatically determine the width of a string of text in a given font. Unfortunately, it is not. You can go look how libraries like D3.js do it. But ultimately, pixel-perfect text with SVG is difficult/impossible. I'd really like to know if I'm wrong about that.
On the positive side, ReactJS plays great with SVG. I'm working on some basic line charts that I want ReactJS-managed so I can render them server-side too. My line chart isn't done but I tried the server-side rendering and it's working great.
textElement.getBBox().width and textElement.getBoundingClientRect().width should give you the text width in user and client space.
Have you tried them though? Now check it out with kerning and/or italics. Do you see overhanging when you draw the rectangular box found via the API? Good example is strings that end with a character like f.
Works in theory. In practice, it does not. That is what I found but again, I'd be happy to be wrong.
That's interesting, the computed bbox seems to be slightly off on Chrome when I apply "italic" font style.
When working on it a year ago at another employer, we had a list of edge cases. I don't recall them all but some were off by quite a bit. Enough so that the work around was to do everything in SVG except text and use plain DOM position on top for text. That was a bit better. It would be wonderful to do everything in SVG.
Indeed. I just noticed yesterday that the text labels in an svg graph I'd created are changed in size by the Firefox browser. They were too big and overlapping things! Huh? Lowering my "minimum font size" pref fixed the issue.
A great way to "snatch defeat from the jaws of victory," re scalable graphics.
The only thing holding back SVG is laptops. Most phones have enough pixel density that SVGs look great and are the right choice for most non-text, non-photo assets. But pixel density is low enough on most laptops that they look fuzzy. Low-end tablets have the same issue but no one really cares about hi-if experiences on those devices.
I think it often comes down to what's the easiest asset workflow that gets us a good result. From that perspective, 1x raster + 2x raster is less work than 1x raster + SVG
Why does an SVG look fuzzier than a bitmap at low resolutions? Is it because of the lack of anti-aliasing?
>Why does an SVG look fuzzier than a bitmap at low resolutions?
It doesn't -- it's the same as a bitmap in the default resolution rendered. And it gets even better when you zoom-in on those 'low resolutions'.
That is strictly true, but the beauty of a bitmap is that you can make it look better by rendering at a larger size and then scaling down. Effectively multisampling by hand. You can also do this as a preprocessing path in your asset pipeline and get better looking results than just using an SVG outright.
This is what we do for the cards at http://greenfelt.net. We lose a lot of detail in the face cards when we render them directly to the correct size as SVGs, especially at small sizes. There's a price to pay, of course, and it's a slightly more blurry look.
Another tangentially related but interesting fact is that every card set we have rendered as a pngcrushed png (except for the absolute largest size) is a smaller than the SVG source code.
>every card set we have rendered as a pngcrushed png (except for the absolute largest size) is a smaller than the SVG source code.
Considering SVG is XML and PNG is binary, I am not totally surprised. Does that still hold after gzip compression?
It's pretty much the opposite. Too much anti-aliasing. At low resolutions, you need to be aware of the pixel boundaries to really make an image look good. Think 8-bit Nintendo/"pixel" art. You can't simply anti-alias a vector image down to a 8x10 pixel sprite. You just end up with a blurry mess.
Set your coordinates to 0.5 positions instead of whole pixels and look at the differences. Like if you draw a line from 100,100 to 200,200 try 100.5,100.5 to 200.5,200.5
For a quick glance, take a look at this nasty ultra-dense rendering in FF/Chrome and compare it to IE: http://projects.voanews.com/ebola-tracker/ (uses raphaeljs so renders in SVG or VML, whichever is supported.)
Because bitmaps target a specific resolution they can be tweaked so that features are aligned to pixel boundaries resulting in less anti-aliasing.
Truetype fonts are an example of a vector format that can still look sharp at arbitrary resolutions because they can include hinting programs that align the control points to pixel boundaries. This is why fonts tend to look sharper on Windows and Linux than MacOS X. Linux and Windows default to strong hinting, and MacOS X uses only slight hinting, preferring accurate shapes to sharpness.
> Linux and Windows default to strong hinting, and MacOS X uses only slight hinting, preferring accurate shapes to sharpness.
I know you already know these things, but for the sake of discussion (or other people).
Linux allows you configure hinting. It's true that by default (depending on how you define default) you get no hinting, but no reasonable distribution that I know of has shipped with that default for the past 7 years. Quite the opposite in my experience. Linux fonts (thankfully) look more like OS X fonts than Windows fonts.
Unfortunately, this configuration usually happens in some Gnome/Unity/XFCE/KDE configuration format, so if you want to use a better window manager with no DE, you sometimes have to recreate this from scratch, although, as someone who obsesses over font rendering and doesn't like the DEs, this is easier now than in 2000.
And then you have Google Chrome who just ships with its own font rendering. Gah.
I see a big security problem with SVG: browsers allow executing scripts in SVG files in site security context, so you have to check for a lot of script execution vectors in SVG before you allow uploading user files.
https://github.com/wikimedia/mediawiki/blob/4aa9e1/includes/...
https://github.com/wikimedia/mediawiki/blob/4aa9e1/includes/...
my understanding is that svg in <img> is safe but prevents script execution
svg in iframe + srcdoc + sandbox gives you sortof-inline svg with separate security contexts.
only plain inlined svg should be a security risk.
If you host SVG file on the same domain as the main site, I can give a direct link to the SVG file and your browser will execute arbitrary JavaScript in that context.
I think in that case setting the CSP sandbox header to "allow-scripts" would have the same effect as the iframe sandbox attribute and allow script execution in the SVG but prevent same-origin access and various other things.
Where is native support for iOS and Android? Why do we bother generating the same assets for different screen densities? Am I the only one who wants SVGs on mobile?
Everything supports SVG 1.1 these days (the end of the article talks about this).
http://caniuse.com/#feat=svg
I think the OP means in the native SDKs for those platforms.
Correct!
https://github.com/jmenter/JAMSVGImage
Xcode supports PDF IIRC. I think it bakes them into PNGs, 'cause performance.
This is a fantastic point. Made me google around, seems this was added to Android Studio 1.4
https://www.youtube.com/watch?v=8e3I-PYJNHg
Even better, they get converted to PNG at build time for older SDK targets that can't display SVG.
Your move Apple.
Apple & Xcode support the same concept, but with PDFs. You can add a PDF to an "imageset", and at build time it will be rasterized into different resolutions for different devices.
Because you have to basically implement half a browser for SVG. You need to parse the XML into a DOM and apply CSS that you also need to parse (also javascript in case of animated SVGs that use JS)
SVG specification distinguishes two types of conforming SVG viewers: static and dynamic [1]. The static viewer does not have to support scripting, animations and user interaction.
A good example of a relatively small static SVG viewer/renderer is libRSVG which is used by GNOME project to render icons.
[1] https://svgwg.org/svg2-draft/conform.html#ConformingSVGViewe...
[2] https://en.wikipedia.org/wiki/Librsvg
"relatively small"
The library takes half a megabyte under archlinux: https://www.archlinux.org/packages/extra/x86_64/librsvg/
It also requires a 1.2 megabyte css parsing library: https://www.archlinux.org/packages/extra/x86_64/libcroco/
And of course also a 8.8 MB xml parsing library: https://www.archlinux.org/packages/extra/x86_64/libxml2/
Now compare this with libpng:
https://www.archlinux.org/packages/extra/x86_64/libpng/
half a megabyte and the only real dependency is zlib, which is also in the dependency tree of librsvg
The main size is dealing with libxml, but that's readily handled by smaller xml libraries [http://pugixml.org]. I mean, maybe you don't want to do SVG on an arduino.
Directly comparing SVG and PNG libraries purely based on library size is misleading. PNG's aren't layered, don't contain semantic information, etc. For me librsvg is lightweight since its way better than installing phantomjs as I have been doing to generate embedable PNGs for documents.
One of the things I like about hybrid apps (Cordova, Ionic, etc) is that this is a solved problem since you basically develop on top of Chromium (Android) and WKWebView (iOS). I already do heavy use of SVGs on mobile apps for everything, including animations, and I'm quite happy with the results and the workflow. No more asset-hell, everything's a vector.
Design once in Illustrator (export SVGs) -> Code once -> Run everywhere
Android supports a sub-set of SVG in its VectorDrawable and AnimatedVectorDrawable classes. There is also tooling to convert SVG into VectorDrawables.
It is definitely a partial subset and creating VectorDrawables from any sort of design program is a giant PITA. The best strategy is making an SVG and then going through the XML by hand and turning it into a drawable (ugly I know).
Clearly this is the future direction of Android, but as of today it is still only half implemented.
As for why we didn't have SVG from day 1 on Android, I'm going to guess that is all a performance optimization. It's hard to overstate just how slow & weak early smart phones (iPhone & Android) were relative to today. We've expanded the scope of the apps to fill the available resources (as software engineers always do), but now there is enough head room to handle it all.
No mention of retina screens? In my experience it has pushed to use font and svg on the web.
This and the android device fragmentation (yes, also for resolutions and pixel density) is what pushed me to start replacing raster images for SVGs in all my web and hybrid mobile apps. I guess being quite good at Illustrator helped me to make the jump.
I don't bother using jpg's, png's of gifs anymore. Whenever I can, I use vector designs exported to SVGs (backgrounds, custom iconfonts, logos, shapes, animations, etc...)
That's a great point. I was talking with Doug Schepers and when I noted the resurgence of SVG that's what he said... "oh, I think the Retina screens brought it back" - it is true, SVG is beautiful on Retina screens, there are SVG Test Suite examples where the raster "it's supposed to look like this" image looks very bad next to the SVG side on a retina display. But I think the ubiquity of SVG in browsers was clearly happening before retina screens were widespread. No doubt it is a factor in adoption.
Corel had a serious SVG effort during this early period around 2002-2004. They created a SVG Viewer and tooling around an initiative known as Smart Graphics.
Here's a Press Release about it: http://www.corel.com/uk/pdfs/press/79.pdf
I'm currently working on an SVG authoring tool written in JavaScript. You can check the project on https://chrome.google.com/webstore/detail/boxy-svg/gaoogdonm...
1. ForeignObject support still sucks.
2. WebGL and even Canvas are significantly more performant. I realize that's comparing apples and oranges... Still, if I had a choice for any data visualization project today I'd use WebGL rendering, or ThreeJS etc.
WebGL and even Canvas are significantly more performant.
It did seem rather unfair of the article to bash Microsoft/IE so much over SVG support, when actually today the performance and sometimes rendering quality in IE is dramatically better than the likes of Chrome and Firefox.
But in any case, you're right, performance is a significant real world concern if you're using SVG for anything beyond very simple diagrams or line art.
We use SVG all over the place, but then we have the great privilege of being able to tell our clients to only use modern browsers. It's pretty nice to be able to specify one graphic for use at all pixel densities that never gets blurry.
Oh yeah. I work for a web agency and, if I could, I would just stop using images and use only SVG. Sadly, we still need to push some visuals as large.jpg + mobile.jpg and use media query...
Why not build your sites using SVG and render your bitmap images from those SVG files?
One of the early successes of svg, iirc, was its adoption by Linux window managing software.
I think another factor in the rise of SVG was it being used in illustration programs most notably Inkscape and its predecessor Sodipodi.
I have worked with SVG extensively, mostly through Raphael but also with Snap and D3.
It might not be a perfect standard, but it's a glorious feature set the web needs.
Should this be called the rise and fall and rise of SVG?
Or also read W3C's version of the SVG Origin Story:
http://www.w3.org/Graphics/SVG/WG/wiki/Secret_Origin_of_SVG
Or Alex Danilo's awesome history: https://www.youtube.com/watch?v=GV3GSxbW_-A
Google renders their homepage with SVG now, don't they?
Right click on google.com and do a view source.
The logo is a png. The page is a giant wad of incomprehensible, minified javascript. There are two references in there to SVGsomething, so who knows.