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.
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.
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.
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.
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 :)
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..."
SVG is plain text XML after all. Not binary blobs.
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!).
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.
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.