Nice to see SVG continuing to gain traction. I've almost entirely eliminated PNG from new work. For the (still fairly common) browsers that don't support SVG, I either use a simple bit of Javascript to replace the SVG references with PNG fallbacks, or—if the image is referenced via CSS—I can do it entirely with CSS's built-in fallback mechanism.
So far, I've been using iconmonstr —http://iconmonstr.com/ —for my icon source. He has a large variety of high-quality icons available as SVG or PNG.
Not exactly SVG <script> tag makes it slightly malicious. If you don't actually inspect the contents of your SVG file. Yes SVG supports executing javascript internally.
I originally thought this post was going to be about that as a few blog posts have popped up about the malicious things you can do with SVG.
Thanks for the iconmonstr.com link. I've been searching for a while for libre-licensed smileys and it's surprisingly hard to find a set that doesn't look creepy.
According to Eisenberg & Bellamy-Royds' (excellent) "SVG Essentials", you should be able to create a fallback by using an <object> tag. Assuming that works (I haven't tried it), it could be a more direct approach than Javascript.
The <object> element is the general-purpose way of embedding external files in HTML and XHTML... Any content in between the [start and end tags] will be rendered only if the object data itself cannot be displayed.
It seems that using of <object> - not the best solution. For example in construction like
<object data="image.svg" type="image/svg + xml">
<img src="fallback_image.jpg" />
</object>
fallback image will always be loaded. To avoid this you need to use additional tricks like conditional comments... We need some more elegant trick to do that :)
Interesting idea, and I don't doubt that it would work (though I also haven't tried it).
I prefer to keep my HTML semantic when I can, and <img/> is more accurate than <object/>. Since SVG support is now over 90% of deployed browsers, I'd rather use Javascript for the edge cases.
Resolution independence is the main reason. No matter what the screen density, the images will look sharp. And, there's even the possibility that rendering engines can use their own tricks (such as sub-pixel rendering) to make it look even better (though I'm not sure if any browsers actually do this).
File sizes can be better (though they're occasionally worse), and I'm not doing anything fancy enough to be straining any [CG]PU made in the past decade.
Also, I really like the fact that the image format more closely represents the actual intent of the image creator. "Draw a line from [ax, ay] to [bx, by]" is much more accurate than "Draw a pixel at [ax, ay], then draw a pixel at [ax+1, ay+2], then draw a pixel..."
Few do, but creating SVG on the fly is also much more straight forward than other formats (no need to learn a specific image library). I've seen people do graphing engines which generate an SVG graph. Although this benefit is a lot less beneficial now when we have canvas support in a lot of browsers.
SVG is plain text XML after all. Not binary blobs.
Opera Mini goes through their own proxy essentially. Their goal was to minimize mobile bandwidth but the net effect is bypassing censorship. I work at a public high school and this browser is very popular with the kids on their phones for this reason. There is a good article about it here http://en.wikipedia.org/wiki/Opera_Mini
Over 3% of the overall market (thanks to Windows XP/IE 8) and over 9.1% of the Android ecosystem, ouch.
Fortunately once 2.3 and below disappear we won't have this problem again with Android, as 4.0 and above are Google Chrome for Android supported (and update via the Play Store). No more tying the OS version to the browser version, which was always a terrible idea (looking at you Microsoft!).
> No more tying the OS version to the browser version, which was always a terrible idea (looking at you Microsoft!).
I mean, this hasn't really been the case ever. IE versions did historically only come out with new OSes, but once out, could be downloaded on the previous few OS versions. So I wouldn't call that tying the versions together.
Starting with IE2, which was included with Windows 95 OSR 1 and Windows NT 4.0 but compatible with 3.1 and stock 95, and going all the way to the latest version, IE11, which was released with 8.1 and Server 2012 R2, but can be installed on 7 and Server 2008 R2.
> I mean, this hasn't really been the case ever. IE versions did historically only come out with new OSes, but once out, could be downloaded on the previous few OS versions. So I wouldn't call that tying the versions together.
People on Windows XP cannot install Internet Explorer 9, 10, 11, or 12. People on Vista cannot install IE 8. People on Windows 8 cannot install IE 9.
Explain to me how this isn't tying one thing to another thing? If IE was stone alone it likely would be backwards compatible with XP.
> Starting with IE2, which was included with Windows 95 OSR 1 and Windows NT 4.0 but compatible with 3.1 and stock 95, and going all the way to the latest version, IE11, which was released with 8.1 and Server 2012 R2, but can be installed on 7 and Server 2008 R2.
They implement a single OS version backward compatibility, good for them. It doesn't disprove that the two are tied together. The fact you cannot install IE 9 on XP but can install Chrome or Firefox, kind of hurts your case.
Just like how Firefox doesn't support XP and XPSP1. At some point, old OSes won't be supported, that's just how software works, it takes extra time to support older OSes. Microsoft only supporting one or two previous OSes doesn't suddenly tie the OS version to the browser version. If Microsoft only supported ONE OS per browser, then sure, but if you can update (even if it's limited to a few versions), then the two are not directly tied.
So far, I've been using iconmonstr —http://iconmonstr.com/ —for my icon source. He has a large variety of high-quality icons available as SVG or PNG.