SVG, Use it Already | Hacker News Reader

SVG, Use it Already

dbushell.com

95 pointsfelipellrocha65 comments

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

> "vast vast majority"

seems wrong - http://developer.android.com/about/dashboards/index.html

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

In the chart you link, it’s 90.2%. How vast a majority do you need?

heh, I confused Honeycomb and Gingerbread, my bad

Worth noting the stock browser is not the only option on android-- Although it is still no doubt a strong majority that lack SVG support.

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.

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

Nice. FWIW: it's flawless under Chrome for Android on my GNex too.

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.

I wasted about 4 hours on that thing... The result is here: http://173.242.122.166/irmug/local/http/www.irmug.com/ using these logos: http://173.242.122.166/irmug/logo.svg and http://173.242.122.166/irmug/logo.png

This is what I finally decided to do:

1. CSS (for #logo element):

    background: url(../../../../logo.png) no-repeat center center;
    background: rgba(0,0,0,0) url(../../../../logo.svg) no-repeat center center;
    width: 588px;
    height: 198px;

(borrowed from https://gist.github.com/1565894 - note two backgrounds!)

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.

That's an interesting solution, but wouldn't you normally want the logo in an img tag, so it gets loaded sooner?

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 :-)

BTW, check this out: "20 SVG uses that will make your jaw drop" http://www.netmagazine.com/features/20-svg-uses-will-make-yo...

This one will really make your jaw drop (you have to click on different parts): http://upload.wikimedia.org/wikipedia/commons/6/6c/Trajans-C...

And everything old is new again.

Everyone hated java applets 15 years ago.

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.

Bottom link renders very nicely on my MBP2,1 C2D 2006-7 with Chrome Stable.

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

If Apple really pushes the whole industry into Retina-era, we can probably forget about subpixels in a year or two.

Or probably not, since even the ipad uses sub-pixel rendering for its fonts.

You'll need closer to 600dpi in order to not be able to distinguish pixels.

If you still think your ipad/iphone is true retina. Put a single strand of hair on the screen, you'll now be able to see the pixels.

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.

Seems you are right. I took a closer look at the screen and it just uses pixel based anti-aliasing.

Thanks.

Just based on recent history, wouldn't Apple more likely try to prevent the rest of the industry from moving to Retina-like displays?

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?

"Because they bought up all hi-res panel supply?"

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.

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.

D3.js (http://d3js.org/) is another option to consider. Haven't used it much myself, but the examples show the wide array of possibilities.

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.

Do you have any alternatives you would recommend?

d3.js (http://d3js.org/) is pretty awesome and seems to be quickly becoming the standard

If Go is your thing, consider SVGo (http://github.com/ajstarks/svgo). For samples, see: http://www.flickr.com/photos/ajstarks/sets/72157623441699483...

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.

Here are the 258 open issues in github:

    https://github.com/DmitryBaranovskiy/raphael/issues

I'm not trying to bad-mouth other peoples' work; just point out the current state of the project as I've experienced it, for the benefit of others.

SVGs cost more than bitmaps, it's the law of spline demand.

For small and complex things yeah, for big and simple not at all.

SVG graphics on the new iPad look amazing.

And probably even more so on one of those new MacBook Pros that I can't afford...

...anyone mind donating one to a poor, deprived Linux PC user? ;)

Indeed. Who uses IE8 or earlier or Android Gingerbread's default browser anyway? No one I care about... totally worth it!

/ducks

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

update: year numbers

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

Adobe SVG Viewer 6.0 preview 1 was released in July '03 and not updated since.

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?

Is there a tutorial for this?

It is possible to do this, but there's tricks of setting font-size and background-size involved to get the background sprite image to scale correctly.

I got this info from somewhere in The Googles, so the information is out there.

I haven't yet tried this on older browsers, so it may need extra help when I decided what browsers my app will support

Why bother when a compressed PNG is even smaller and has far broader support with less shim nonsense?

Resolution independence?

I get worried when I see SVG....I don't want Javascript and CSS embedded in something that I might over look and think is an image....

Embedded JavaScript code can't harm you if you use SVG via <img> tag or background-image CSS property.

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.

You can set the size in CSS just as you can with any element.

Right, but I wanted it to fluidly resize in the WP twentyeleven theme, so setting it to a fixed size wouldn't work.

FWIW, none of the browser hacks--including canvg http://code.google.com/p/canvg/issues/detail?id=109 (which is active than svgweb) have no support for marker element.

I just made this with SVG: http://ex1.lynndylanhurley.com/timeline

It runs really great in Chrome + Safari, but Firefox performance is awful.

*edit: grammar

Is the site down? The map loads but the progress spinner just spins (seemingly) forever on Chrome, Safari, and Firefox (on my fast MacBook Pro).

I'm a developer at Mozilla, so I wanted to test your site so I could file an SVG performance bug for Firefox. :)

It should be working. I would really appreciate any advice you might have - can you please check again?

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.

Could SVG become widely used for animated decorations? Like you always see in games and television news programs?

I think you mean Motion Graphics, and specifically Idents. http://www.google.com/search?q=ident%20motion%20graphics

I'd say its a some way off yet, but wouldn't bet against it.

SVG is worse than png, for tiny images

Reply on news.ycombinator.com