Dealing with SVG images in mobile browsers | Hacker News Reader

Dealing with SVG images in mobile browsers

kristerkari.github.com

33 pointsquinnirill12 comments

I doubt that many people will bother replacing

  <img src="foo.png"/>

with tons of javascript to handle browsers not supporting SVG.

If something is well supported except for the 25% of cases where it isn't, it isn't well supported.

Some reasons why SVGs shouldn't be used all the time in webpages:

* Display time - Rendering and displaying images in a browser is incredibly time-critical. A non-trivial SVG is likely to take much longer to render and display than a PNG. My desktop still struggles to show a wikipedia map of the world - I especially don't want my phone to waste time or battery when it doesn't need to.

* SVG's are built for infinite precision. If you are browsing webpages full of small SVGs its likely you'll waste a lot of bandwidth and processing-time on sub-pixel non-displayed cruft.

* Often you actually need pixel-perfection in display, which SVG isn't really built for (hence the S) and you'll just end up drawing 1-pixel wide lines in SVG form.

tldr: Displays are based on pixels. SVGs aren't built for pixels.

SVGs also carry a preferred output size where you do have pixel-perfect control. It is a bit messy, though, as you need to position lines on half-pixels so that a line with width 1 will not fall on two pixels. I tend to prefer paths when working with pixel-perfect data for that reason.

Some icons can be smaller than their PNG equivalent (even more so when served compressed) but that mainly depends a bit on how they're authored. Many authors probably just use Inkscape/Illustrator and accept the 20 KiB of cruft that is embedded automatically instead of writing a simple sub-1-KiB SVG by hand.

> My desktop still struggles to show a wikipedia map of the world

Are you sure? Mine can render and zoom into it instantly - once the data file is cached. The first time you load it it loads in country-by-country since that's how slow it's getting the data (the typical Wikipedia world map SVG is 1.5 MB, although to be fair the PNG version is only 350 KB).

> * Often you actually need pixel-perfection in display, which SVG isn't really built for (hence the S) and you'll just end up drawing 1-pixel wide lines in SVG form.

Actually you might find it interesting that SVG supports media queries so you can include multiple presentations of an image for different sizes and even make special cases of some sizes and go for pixel perfection for them. The thing that makes your argument(s) stand true is that SVG support is horrendous (even Inkscape doesn't let you leverage many of SVG's powerful features, e.g. media queries, and worse yet, bloats your SVGs with meaningless cruft).

This is a depressing read, honestly. I can't believe it's 2013 and we can't reliably use SVG images.

Whoa, I had to look up the word "polyfill", since I had never seen in in this context before. Extra confusing since the topic was close to the filling of polygons (a common operation in vector graphics rendering).

Turns out the word was coined by Remy Sharp, and means "replicate an API using JavaScript (or Flash or whatever) if the browser doesn’t have it natively" (quote from http://remysharp.com/2010/10/08/what-is-a-polyfill/).

Interesting, but depressing to be so "out of touch". Cue shouting about lawn, et cetera.

I have mixed feelings about what to take away from this article. We actually rely exclusively on SVG in the startup I work at, so it's nice to see this topic getting some love. Then again, the lack of serious support, especially in mobile browsers (no mention of SVG not really being supported that well on iOS 4 or lower) means we have to carefully pick our battles or perhaps rethink our stack. Sad.

"no mention of SVG not really being supported that well on iOS 4 or lower)"

I'm guessing the author felt it doesn't need to be mentioned, as usage share for iOS <v5 is negligible (estimates range from 1% to 4%). In contrast, Android <v3 makes up more than 50% of Google Play users.

I made a few decisions in my startup that will rule out compatibility with IE6-8, and old versions of the Android stock browser too. I'm now quite worried about this.

I have a horrible feeling Android's "clone wars" will have the same effect as Windows did back in the day. Create a popular platform with a default browser. Stop supporting the browser on that platform, except for the newest versions/devices. A legacy that makes web developer jobs harder.

The bright side is that no-one holds onto their phones as long as they hold onto their PCs. A given phone has a ~2 year lifespan thanks to carriers subsidizing upgrades. Now if only they would stop selling Android 2.x phones.

Yeah whenever people would recommend Raphael.js, I'd find out they didn't even realize that android < 3.0 didn't even support SVG. Not to mention drawing to canvas is faster than SVG. At least there are plenty of canvas alternatives like paper.js

Reply on news.ycombinator.com