

Dealing with SVG images in mobile browsers - quinnirill
http://kristerkari.github.com/adventures-in-webkit-land/blog/2013/03/08/dealing-with-svg-images-in-mobile-browsers/

======
mich41
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.

------
twelvechairs
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.

~~~
kalleboo
> 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).

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

------
unwind
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.

------
imalolz
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.

~~~
Samuel_Michon
_"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.

------
cbeach
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.

~~~
flyingbuttress
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.

------
edtechdev
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

