"Older Android" is a little hand-wavy: SVG support was only introduced in Honeycomb, so the vast, vast majority of Android browsers still don't do it. Especially painful when I was trying to make a cross-platform app with PhoneGap- everything looked great on iOS, then not at all on Android.
I ended up having to use an Illustrator -> Canvas tool (made by Microsoft, oddly), but Canvas is a huge pain when all you want to do is draw some simple shapes. Mobile devices are a huge target for this stuff because of the varying pixel densities, but Android is still mostly a no-go for SVG.
Quite a bit hand-wavy! Only because SVG support is easily detected with the likes of Modernizr http://modernizr.com/. Background images with CSS are very simple to provide both SVG and a raster fallback graphic for. Image elements aren't as simple, but I'd suggest defaulting to SVG in both cases and replacing the source if support doesn't exist. That way the issue with eventually disappear alongside legacy browser usage.
As you said the benefits of high pixel densities are visually huge. A small and temporary JS hack is a price worth paying in my opinion.
Background images with CSS are very simple to provide both SVG and a raster fallback graphic for.
Oh, sure. But I was talking about just using SVG- for mobile devices with different pixel ratios falling back to raster graphics involves making a number of different size alternatives for each graphic. Not fun.
"The following pie chart and table is based on the number of Android devices that have accessed Google Play within a 14-day period ending on the data collection date noted below."
"Animation and scripting and sprite stacks" sound like exactly the sorts of things that I, as a web surfer, deliberately turn off in my browser. There is already far too much animation and scripting etc. on the web.
Scalable graphics as a native web format is a great thing. But if the cost is yet another format filled with irritations and security holes, then no thanks.
The most successful media formats have been very narrowly focused. JPEG, GIF, PNG, MP3s, etc. do not have a zillion exciting features. You can't build a complete web application with a JPEG file. JPEG compresses photographs (and only photographs) really, really well, and that's all it does.
Maybe what scalable vector graphics need to do to catch on is to throw out the super-feature-dense SVG system and come up with something new, something simpler, something that just does scalable still images really well, something that isn't yet another enormous all-singing, all-dancing ball of security liabilities and unintended consequences.
Indeed, SVG is a bad standard because it is too complex.
There is no 100%-compatible SVG editor (except notepad) - every vector graphic editor just supports its own subset of SVG, things get lost when transferring things between "SVG-supporting" editors.
There are multiple ways to do the same thing in SVG - this makes it difficult to understand a SVG file created by someone else and it is very hard to return to a complex SVG file after few years and modify it.
The complexity of SVG makes web browsers larger and more complex (hence less secure and slower).
So, I disagree with the article. Keep away from SVG unless you really need it and maybe someone designs a simpler vector format for the web.
When I made http://emacsformacosx.com/ I decided to use SVG since I was targeting only Macs and all the popular Mac browsers supported SVG (also I wanted something snazzy looking). In the end I had to do some XHTML+SVG dual namespacey magic so that non-SVG browsers (most importantly, Google) had something to fall back on.
I checked out the retina display MacBook Pro at an Apple store the other day and I was happy to see that the SVG on the site rendered at full resolution (at least with Safari).
I think the choice to use SVG for this particular site was a net-win.
I know this is about static svg images, but
as a curiosity, about a year ago I did a small experiment with svg animations. You can see it here:
http://et.vaan.osaa.fi/
Translation: "You just can't" (as in, able, skilled)
To my surprise, it actually works on iOS devices too, except that it doesn't automatically refresh the screen. That is, after zooming it was rendered in a different position than before but not animated. As a hack, I force it to redraw with css animations, continously scaling it slightly (less than 1%).
Reading my comments, it seems ie9 didn't scale svg content according to css sizes, but drew them in "original" size.
Writing the smil animation declarations was pretty much trial by error, didn't find any practical tooling support.
I did the original image in inkscape, and then hand edited the xml for the animations. Rotating things was tough, because inkscape didn't leave the element/group centers in any predictable place, so I had to guess good rotation centers.
It easier said than done. Later this evening, I was trying to do just the same for a forum (SVG logo, with fallbacks for IE and older Firefox). I'm (thankfully) not a front-end web developer, but I thought it wouldn't take more than 15 minutes.
2. run this stupid script to swap-out logo in Firefox < 4 and IE
window.onload = function() {
if (!document.implementation.hasFeature("http://www.w3.org/TR/SVG11/feature#Image", "1.1")) { // IE, Firefox < 4
var el = document.getElementById('logo');
if (el.style.setProperty) {
el.style.setProperty('background-image', 'url("../../../logo.png")', null);
} else { //IE
el.style.backgroundImage = 'url("../../../logo.png")';
}
} else { // just to make sure
var el = document.getElementById('logo');
if (el.style.setProperty)
el.style.setProperty('background-image', 'url("../../../logo.svg")', null);
}
}
It works perfectly on all browsers now, except Opera 11 (when you zoom in, it's all messed up). I can't imagine what the problem could be.
If there is a better way of doing it (without using huge libraries), I'd be very thankful if you let me know.
It was originally an <a> tag so I didn't want to change that, and I think img tag didn't work very well with SVG and I had to use <embed>, which was another level of complexity.
But I'm by no means a web (front end) developer so I'm sure there are better ways to do this; I just didn't feel adventurous enough to spend more than 4 hours on stupid compatibility issues on older browsers :-)
The bottom link renders at an fairly low framerate in Firefox on a 3GHz core2 duo.
On Chrome it is about twice the speed but the sliding components return to a position different from where they started.
Slow on a desktop machine translates to nearly unusable on Mobile. On an ICS Android with an Allwinner A10, The slide animation consists of only two frames.
The poor performance is not intrinsic to vector based rendering, SVG is simply not the right tool for that job.
It's tolerable on my iPad 2 (iOS 6), and absolutely smooth (the smoothest animation you can imagine) on Safari 6 beta on my old Core 2 Duo 2009 MacBook Pro, so hopefully that's just a matter of browser implementation.
And I completely agree with the last statement. It's cool, but we have better tools in HTML5 for a simple animation like that.
Do any SVG renderers (especially in a browser) do subpixel rendering?
It seems like this would greatly help perceived resolution. With a bitmap, you can't necessarily assume a particular pixel color ordering, and even if you did, with tablets/phones you can't even assume a particular screen orientation. By doing subpixel rendering at view-time, it should be able to give increased resolution in all cases. It would even look best on a printer, which doesn't have separate subpixels (right?).
(Of course, without hinting like fonts have, it could also be worse in some cases.)
How so? Because they bought up all hi-res panel supply? Other manufacturers will catch up sooner or later on this, or they will face sale declines. I don't see how Apple intentionally prevent others from moving to retina displays.
If anything, the rest of the industry has to blame itself for delaying so long and investing so little on good displays. Now they have to bite the bullet by competing with each other for the remaining supply of hi-res displays. Would they see this coming a few years ago when Apple invested heavily for such strategic thing?
They've done that in other parts of the supply chain, but I was thinking more about patents. It wouldn't surprise me to find that they've patented how to have a lot of pixels in a particular geometry.
iFixit seemed to suggest the panel is from LG Phillips. I doubt Apple have much to do with the panel per se, but the actual design of the new cover glass and the way they make it that thin might be patentable.
even the ipad uses sub-pixel rendering for its fonts
No, it doesn't. No iOS devices use sub-pixel rendering, ever.
Unless you mistake it for normal anti-aliasing, which is done on pixel level.
I have less than perfect eyesight. I hold my iPad about 16" away normally. No, I cannot distinguish pixels on the Retina iPad at all. Practically I don't care what is true "retina". For the majority of people, Apple's definition of "retina" is good enough.
I have a feeling that a significant legacy mistake is going to keep SVG from wide use for years after it's ready.
No, I don't mean IE. I mean Photoshop. When every problem looks like a stack of raster layers... well, among other things, vector graphics aren't going to easily come out of that.
OTOH: maybe SVG will help pull us out of the unfortunate accident of history that's meant that Photoshop is used for web layout, but I'd bet we'll see convoluted export procedures before we say a wholesale shift to vector tools....at least, that's the historical pattern.
There is a nice SVG drawing lib called Raphael.js (http://raphaeljs.com/); it does animations pretty well and works even in IE6 (via fallback to VML). So it basically does not work only on old Android and links.
Raphael is nice if your use case is fairly simple and along the lines of the examples provided on the homepage, but I would caution people that the lib is quite buggy and not (particularly?) actively maintained.
Well, it is obvious the if you don't need in-browser drawing you should just use static image files; but if you do, Raphael is way more versatile than canvas api or tricks with CSS.
About bugs, I haven't seen any yet; what kind of them are you talking about?
My use case was a simple vector-drawing program. Many bugs related to inconsistent behavior across browsers, and things generally not working as documented (difficult to tell what is a documentation bug and what an implementation bug sometimes).
One that I actually had to fix (and submitted an as yet unacknowledged pull request for) was for arrow-ends: draw a path with an arrow head in blue, then draw one in red and watch every arrow-head on your page turn red.
I work with SVG+javascript every day. Any time a browser gets updated I get nervous. Chrome and Firefox have both screwed me numerous times by breaking their SVG DOM implementations. I usually find a workaround, but it's been somewhat of a struggle for the last two years. You thought cross-browser HTML was difficult? ugh. SVG can be hell. That said, SVG also works wonders. I must be a masochist because I do like it. It can be a challenge for sure, but the rewards are good enough to keep using it. SVG transforms are a mindfuck though.
Meh. We have used it for a while. The format itself is not particularly bad (although it's a bit fat) but the browser support is rather mediocre. For example, neither Webkit nor Firefox will do vector transformations if you apply CSS transformations on the SVG. Instead, they will do crappy raster transformations. And the rendering speed is so slow it's not even funny. So we just switched back to PNG for the time being. Maybe it will get better in a year or two.
in 2004 or 2005 i coded an SVG/JS based LOGO++ in-browser IDE and some other nice demos. (sadly the source code is now gone, thx to a corrupted time-machine backup)
i really believed at that time that SVG (at that time only working (in a sane way) via an Adobe Plugin (yeah, you read right)) would be the future. i wanted to be on the forefront of technology - of A technology - and SVG was my choice. every browser and webgraphics-company pledged support for this amazing new technology! i already saw myself talking at conferences about the amazing new webpages (we still called them pages in 2005) we can build with it.
i think i probably achieved that goal - i was an "interactive SVG" ninja, but nothing came out of it. now i will wait a bit longer how the market turns out before i touch it again. fool me once ...
FF support came along at that time (or later), too. but it was even more buggy than the Adobe plugin. the FF implementation went stagnant then, too (for years). so basically to do interactive stuff, you were stuck with Adobe.
This article doesn't address sprite vs non sprite. For most users it is much quicker to serve them up one large png with all the icons as a sprite file than a bunch of individual SVG files.
Can you use a single SVG sprite file that contains all of your SVG images for a single connection/download?
I tried to overlay an SVG logo over a photo background (jpg). While it more or less worked after futzing, it was a responsive website and re-sizing the screen caused the SVG to not stay aligned with the background jpg. It doesn't appear to be possible with CSS. So I had to just drop SVG and use a jpg instead. Lame.
Your site is working for me now in Firefox, Chrome, and Safari. It's cool visualization of data using SVG!
I see that Firefox 13 is significantly slower than Chrome and Safari, but Firefox 16's Nightly builds are much faster. (Firefox Beta 14 and Aurora 15 are just as slow as 13.)
To my untrained eye, your demo is "only" about 1.5x slower on Firefox Nightly than Chrome and Safari. Is there a way to quantify the speed difference, such as FPS or time to completion? The demo ends at datetime 2012-05-22T00:48:10.
I ended up having to use an Illustrator -> Canvas tool (made by Microsoft, oddly), but Canvas is a huge pain when all you want to do is draw some simple shapes. Mobile devices are a huge target for this stuff because of the varying pixel densities, but Android is still mostly a no-go for SVG.