Why have SVG images not yet replaced PNG on the web?
blog.sekera.cz
blog.sekera.cz
The abandonment has resulted in much-needed improvements to SVG being delayed. The last full release of SVG was 1.1 which was in 2003, we won't see another full release until SVG 2 which is expected in 2014, over a decade later!
Never mind the fact the browser implementations of SVG are still riddled with bugs and none are complete.
HTML4: 1998
HTML5: 2014
HTML4: 1998
XHTML: 2000
HTML5: 2014
Also, I blame IE 6.
We have solved this problem with fonts, but it is extremely complex, both for the artist and for the rendering code.
Yes, if its mostly double-sized resolution then blurring shouldnt be a prob,
And when it is some strange "1.something" or "2.something" resolution, then probably also PNGs will look blurred, unles you dont supply exact special PNGs for such resolutions
For me, that would be one of the main reasons against SVG
I wonder though - would it be possible to apply hinting to svg with javascript?
If we start seeing 4K screens, worrying about those blurry anti-aliasing lines is going to seem absurd.
Use your phone to contrast AA to non-AA. The difference is still pretty enormous in my opinion.
When people provide icons in many physical sizes, the icons generally aren't mere scaling up and down, because even if you can hint so the lines themselves don't blur the details will get so small the whole icon becomes a mess. Apple even has a note on this in their HIG:
> If an icon’s content or shape is overly complex, the details can become confusing and may appear blurry at smaller sizes.
note that this is not about logical size and retina displays, it's about physical size and the viewer's eye's power of resolution.
That sounds more like a problem than a solution to me.
You can no longer expect bitmap pixels to map to device pixels in any reasonable way. (Heck, just turn your desktop browser zoom to 90% or 110%.)
There was a time for hinting, but it's long gone.
So the only size increase really comes from the edges. In practice, this means that an 8x size increase will often only increase the file size by around 10x.
The SVGs in question were 6kB and 568kB in size, respectively.
At 25% size (around 256x256px) the PNGs were 13kB and 30kB respectively.
At 100% size (around 1024x1024px) they were 60kB and 266kB respectively.
I scaled the complex image to 200% (2048x2048) just out of curiosity, and it became 841kB, roughly 28x the size of the smallest, which uses 1/64 as many pixels. It is interesting that the complex image seems to approach size growing with area at the high end of resolution. Of course, this is a sample of 2.
But is hinting even possible in a format that supports multiple colors? It does not seem obvious to me that it is.
* Browser support is still new and in places still a little rough
* IE support has only recently arrived
* SVG creation tools are either rough or expensive
* SVG can create sub-Flash-like performance if used carelessly
* SVG has no detail optimisation (or detail hinting)
I think we're about to see SVG usage pick-up steam now that IE has support and retina displays are becoming commonplace. Hopefully we'll get the tools and performance we deserve.
I'm very hopeful for SVG in the next 18 months.
> * SVG can creat sub-Flash-like performance if used carelessly
Could you elaborate on that? What should I be aware of if exporting vector art from, say, Illustrator or Inkscape?
Drop shadows and filters in general are a concern. Not so much on desktop browsers nowadays, but in mobile very much.
Too much detail has been the cause of the worst performance (and crashing) I've seen — one image of a playing card froze my iPad.
http://code.google.com/p/vectorized-playing-cards/
try this guy: http://www.totalnonsense.com/misc_images/Jack_of_Spades_vect...
Blurs can be slow on large images.
Drawing Big SVGs can be problematic too.
Perfect. You just know that it will be used carelessly, too. Some of my low-powered devices are already stumbling under the concept of a "modern" website (which seems to revolve mainly around using as much js as can possibly fit onscreen), I'm not looking forward to widespread adoption of this next piece of "progress".
On top of this was Wikipedia's use of an SVG->PNG renderer that is openly acknowledged to render worse than its competitors (which were not great), for better performance.
Until there's a reference implementation of SVG... a real spec with an exhaustive ACID-style test on every single feature... I won't revisit trying to work in it.
That being said, back then I struggled fairly often with annoying bugs in Wikimedia's backend renderer rsvg. It got better over time but back then browser support was also very spotty. By now SVG is still my favorite vector format to use, mainly because it's trivial to write scripts around (it's just XML after all) and converting to PNG if you need it (or whatever else is needed) is trivial.²
So generally I'd say SVG is very much not dead, it's just rarely used directly on the web, except for interactive things where hit-testing arbitrary shapes is important.
____
¹ I used to vectorize a few (around 200–300, I think) flags on Wikimedia Commons and for simple shapes I concentrated on it was usually a difference of 350 bytes vs. 2–3 KiB. I wrote my code by hand for the most part, utilizing a few templates for common flag formats (n horizontal or vertical stripes, checkerboard, etc.) and small scripts for the more annoying things to write by hand, like wavy lines.
² Current use case from today: action bar icons on Android. When creating them in Eclipse from an image it only generates enabled, not disabled icons and I have to remember what padding I used and select the correct theme. After two or three changes in the source images (which were SVG anyway) it was enough and I just wrote a tiny script to generate them. Another use case were the images in my final thesis which I kept in SVG because back then I wasn't sure yet whether to use Word (needs EMF) or LaTeX (needs PDF) for writing. The fact that I needed Graphviz a lot which outputs nice, clean SVG also helped.
Meanwhile, pixel rasters are a finite array of bytes, confined to specific dimensions and resolutions. Plain old integers in 24 bit color with an 8 bit transparency channel.
And, specifically with respect to PNG, those pixel values are compressed row-by-row, using the DEFLATE algorithm.
With tools like ImageOptim, and ImageAlpha, you can make PNGs INSANELY small with 0 or an imperceptible loss in quality.
For example, PNGs do insanely well when you have few numbers of colors that are repeating often. I've had had images that were 640px by 960px (pixel style art) that compressed down to sub 3kb with no quality loss. Good luck getting that with an SVG.
(Yes, there are certain types of images that PNGs are a terrible solution for, however, really, what I mean here is, right tool for the job.)
e.g. no blend mode except "normal" really works reliably across browsers yet. And just a reminder: it's 2013, everyone.
Next question...
But I agree with your argument regarding to something is not properly - yes, that can be the reason why people don't see the whole thing as reliable
Compared to what? What alternative does reliably have blend?
So the only alternative is something that's been pre-composited down to pixels for you, probably in a png.
- SVG will be smaller than a bitmap
- The sub-pixel rendering isn't really an issue (do you check that all the lines are aligned on pixels when you export something from illustrator?)
- No advanced/poorly supported features are necessary
Platform support is still a stumbling block, but that will get better. I seriously considered going svg-only for the vector-friendly illustrations in the new edition of http://eloquentjavascript.net . But in order to not screw over people on old devices, I will probably use svg with png fallbacks instead.
Chiefly among these new features are (1) inlining directly into html (2) making them interactive via javascript.
Both #1 and #2 are possible in theory, but in my experience these features are very painful practice... both of these are still very buggy. That's the problem with SVGs: Most of the new "options" they open up are still not ready for prime time.
I had an article in MSDN Magazine promoting SVG graphics 10 friggin' years ago, and it made use of inline SVG and JavaScript animations, to fantastic effect. Since then I've used SVG in countless places, with very little downside. The major problem are some laggard browsers, but if you have a supporting browser neither inlining and script are a problem whatsoever.
SVG is one of those technologies where many (such as myself) overestimated the short-term impact, and under-estimated the long term impact. As a technology it was usable and enormously powerful in some situations ten years ago, but it is really just starting to gain serious inertia.
Exporting SVG is difficult, requires specific tools, and is gonna render differently depending on the browser.
SVG solved a problem exactly no one had.
I think PNG and SVG inherently solve somewhat different problems in the realm of image representation, so there are going to be cases where each of them has the clear upper hand. However, with pixel density going up and file sizes and network bandwidth not being the limiting factors in many cases, I'd guess SVG will command increasingly bigger share of uses.
SVG has been out for awhile, long before Retina design became a part of the web development workflow, and yet, when faced with the challenge, most web shops didn't swap to an SVG workflow.
They just designed everything at twice the resolution.
Even Apple, who was leading the way for a hot second there on HDPI and vector assets, has swapped to mostly using 2x image assets.
The whole "will we swap to vectors?" debate already happened.
2) Pixel choices by vector renderers are generally dramatically worse than a human artist's choices. We don't want accuracy, we want perceptual emphasis. Look at NES Mario in your head, then look at the blur you'd get if you took a modern hi-res Mario and vector rendered it at that size. For icons, this can be murder.
3) IE <= 8 is still a pretty significant chunk of your viewers.
4) There's a lot of knowledge built up around how to work with pixel images, especially when sprite sheeting for performance. Much of that knowledge needs to be re-learned for vector. Even when it's a good idea, many developers feel they don't have the time for a knowledge overhaul.
5) A big chunk of the web is legacy sites. This is why you still see javascript in html comments, or the occasional isindex. They aren't getting updated, pretty much ever.
6) For visually complex sites, SVG can still drag on budget and older mobile devices.
7) Older android had SVG turned off in Chrome.
8) It's a lot harder to get vector artists than pixel artists; it's a lot harder for artists to give developers SVG than pixel images.
9) Because it isn't trendy yet.
At https://starthq.com we do use SVG for the logo and all icons. Falling back to PNG for older browsers requires a CSS hack though and that fails on some older mobile devices.
Naturally, there are a number of web resources, but none of them felt authoritative (in the sense of complete coverage). Furthermore, they used different techniques, so it was hard to integrate code samples from different sources. Finally, some had outright errors (my vague memory is that some of this was due to the documentation being written before a working implementation was available).
All of this had the effect of making me feel like SVG was a bit of a backwater. I liked the technology, and was willing to use it since I had total control of the machine I was going to run the demo on. However, I didn't feel comfortable with the idea that I could make the demos public and have them run anywhere.
Not time enough. Plenty of people still use IE8, which doesn't.
<object type="image/svg+xml" width="640" height="480" data="http://example.com/image.svg">
<img src="http://example.com/image.png"/>
</object>I'm an artist who's been using Adobe Illustrator as her primary medium for thirteen years. Here's some reasons why my site is still serving up tons of bitmap images:
- Any interesting vector image will be a much larger file as an svg than a web-res png/gif/jpg.
- Sophisticated effects in AI can get lost in the transition to SVG. I don't know if this is AI's fault, SVG's lack of support, or the fault of the various things rendering the SVG, and the first point leaves me disinterested in experimenting.
That said, I have been playing with using web fonts for sets of simple images.
Also, most of my artist friends are completely baffled by AI; they prefer bitmap programs like Photoshop, Sai, or Artrage.
Although SVG is "readable" in a text editor, all but the simplest shapes are extremely complex and require the use of graphics editors such as Inkscape. Vector formats are definitely the future for source images as they can generate any size bitmap you need for any device. However, as a delivery format, SVG will likely be relegated to niche and specialized sites (e.g. data visualizations and animations) for quite a while.
I want to use SVG, particularly in Javascript apps. It seems like a more elegant solution/workflow for things like icons. It would certainly beat abusing fonts to put small images on a page. but it has sort of missed its opportunity.
See: http://www.pushing-pixels.org/2011/11/04/about-those-vector-...
d3.js is bringing svg charting to the web in a major way. Most, if not all, modern web dashboards are using it.
Google Maps has been using SVG icons for custom markers for awhile, embedded into their json configuration. This may not be strictly 'the web', but it is a major component of online GIS applications.
Where I currently work we can't support SVGs with some projects due to a bug in the middleware we're mandated to use.
http://en.wikipedia.org/wiki/Portable_Network_Graphics#Compr...