Another approach we can take to the problem is to use JavaScript to detect SVG support. Alexis Deveria wrote a script which detects if your browser supports SVG and, if not, replace the images with PNG. It’s a good script, but I wondered if there was an alternative.

I’ve come up with a script based on Alexis’s, but which simply adds a class to the body of the document, allowing you to specify alternative images if SVG support isn’t implemented on a visitor’s browser. Update: Changed the script to use onload instead of addEventListener to ensure compatibility with IE. Still looking into Opera issue.

Here’s the script:

function setCSS() {
  var docBody = document.getElementsByTagName('body');
  docBody[0].className = 'svg';
}
function SVGDetect() {
  var testImg = 'data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSIyNzUiIGhlaWdodD0iMjc1Ij48L3N2Zz4%3D';
  var img = document.createElement('img');
  img.setAttribute('src', testImg);
  img.onload = setCSS;
}
img.onload = SVGDetect;

This creates an img element with an SVG data URI and tests to see if the browser loads it; if it does, it adds a class of svg to the body. To finish the method you just need to add alternatives in your stylesheet:

div { background-image: url('image.png'); }
.svg div { background-image: url('image.svg'); }

Here’s a demo: Using SVG in CSS with JavaScript detection. View it in Safari, Chrome, Opera, IE9 beta or Firefox 4 beta to see the SVGs, and Firefox 3.6 or IE8 to see the PNGs. Try zooming in to the page to see the advantage of using SVG.

There are a couple of drawbacks with this method that need to be ironed out: first is that in theory it doesn’t work in browsers which allow SVG in the img element but not in background-image — in practice, however, there are no browsers where this is an issue; second is that it loads the PNG images first, and there’s a brief delay before the SVG images replace them — the script definitely needs tweaking to stop this, so consider it Version 0.1.

This technique is for the CSS background-image only; if you want to replace img elements I advise you to use Alexis’ script instead. As always, if you see a way in which my code could be optimised, don’t hesitate to let me know.

The drawback of this is that it’s not ready for use just yet—browsers that don’t support SVG in background-image will not provide any fallback, even if you supply another background-image value; so in non-supporting browsers, no image at all will be displayed.

This was annoying me a little, and I couldn’t find any workarounds that didn’t use JavaScript. However, after a bit of head-scratching I’ve come up with a way to get around it.

In order to have browsers which don’t support SVG display a PNG image instead, you should use this code:

E {
background-image:  url('image.png');
background-image:  none,url('image.svg'), url('image.png');
background-size: 100% 100%;
}

Browsers which support SVG and multiple backgrounds will show the SVG; browsers which don’t support SVG will fall back to the PNG in the background-image stack. As far as I know, all browsers which support SVG also support multiple backgrounds; any which don’t (i.e. IE) will fall back to the PNG in the first background-image declaration.

Update: Thanks to a comment I have amended this technique. IE was not falling back to the first background-image as it should have done, but I got around this by adding a none value in the declaration. This invalidates the rule in IE and forces the fallback to the previous declaration.

You can see a demonstration of it here: Background SVG with PNG fallback — demo.

This technique is not without its own caveats, however. First and foremost, the SVG must not have a transparent background, or else the PNG in the background layer below it will probably show through. Also, depending on how fast the SVG file loads, the PNG file may show up first and then be covered over.

Finally, if you’re using the same background image at different sizes and either your browser doesn’t support background-size or you don’t want automatically resized PNGs, you’ll have to use the rule for each instance:

E {
background-image:  url('image-small.png');
background-image:  none,url('image.svg'), url('image-small.png');
background-size: 100% 100%;
}

F {
background-image:  url('image-large.png');
background-image:  none,url('image.svg'), url('image-large.png');
background-size: 100% 100%;
}

And of course, if you’re creating multiple PNG images anyway, you may feel there’s not a lot of point in using SVG images as well. I’ll be the first to admit that this isn’t a completely bulletproof technique, but I offer it in the hope that in certain circumstances it could be useful.

You can now use SVG with the img element, as well as the background image in CSS.

I know you can already use SVG in background-image with Safari, Chrome and Opera, and this, coupled with Internet Explorer’s push towards SVG and the strong chance this will be available in IE9, made me decide to take a closer look.

I’ve put together a little demo page which you can view with Safari, Chrome, Opera or Firefox 4 nightlies:

SVG in background-image demo

The same image is used many times at different sizes on this page, displaying the grand advantage of SVG over PNG: it can be resized without the same loss of quality that bitmap images suffer.

Implementation is very easy:

E { background-image: url('image.svg'); }

You’ll notice also a box labelled ‘SVGZ’ — the background-image on this element is in the compressed SVG format, SVGZ:

E { background-image: url('image.svgz'); }

The file size is less than one-third of the non-compressed version. In order to use this, you may need to configure your server; full instructions for Apache servers can be found here.

The drawback is that it’s not ready for use just yet — browsers that don’t support SVG in background-image will not provide any fallback, even if you supply another background-image value; so in non-supporting browsers, no image at all will be displayed.

Update: I’ve found a technique for using SVG images with PNG fallback.

The image used in this demo is from All Free Vectors.

Update (21/12/2010): Changed information about SVGZ, thanks to the comment from Robert Longson below.

I won’t be so bold as to make any specific predictions about the year ahead — more of the same is my best guess! — but here are a few articles I’ve read recently which have an eye on the future.

5 Exciting Things to Look Forward to in HTML 5

Don’t get too excited about the first point (‘new HTML elements that improve our ability to describe content’) as there’s no way for them to degrade gracefully in many browsers, but the rest are pretty interesting and — importantly — already being implemented.

SVG Is The Future Of Application Development

Maybe on the mobile web, where the SVG-compliant Safari and Opera (and perhaps Firefox/Fennec in the future) are commonplace, but IE doesn’t support SVG and perhaps never will.

Getting Real About Agile Design and Contract Killer

Although the digital sector seems pretty healthy at the moment, the global recession is bound to bite harder next year. These articles give some practical advice on how to make sure you don’t get bitten too.

Also: Browsers

Early 2009 should also see new releases of each of the major browsers: IE8, Firefox 3.1, Safari 4, Opera 10, and a bug–free version of Chrome; lots of new features to play with and — crucially — a standards-compliant base to develop on.

Luckily there are a few tools out there which will help you show off the benefits of using Microformats, and involve little work from you.

King amongst tools, of course, is Operator, an add-on for Firefox which finds data in pages and presents you with options to transform them using a series of web-based tools. If the person you’re trying to convince doesn’t use Firefox and/or have Operator installed, however, there are a few good tools available online to show their potential.

hAtom is a microformat used for marking up blog posts or other serialised content. Using the Optimus tool you can turn any page marked up with hAtom into an RSS feed, by adding a link on your page in the following format:

http://microformatique.com/optimus/
?uri=http://www.example.com/&format=RSS

Optimus will return correctly formatted XML for users to subscribe to. It’s also a decent validator for other Microformats (although actually seems to struggle a little with hAtom in that department).

hCard is the standard for marking up contact details, and there is a tool from Brian Suda which will convert them into vCards for you; Technorati also have a test implementation of this tool available, which I’ll link to as they no doubt have better servers. To extract vCards from a page which has hCard markup, simply create a link in this format:

http://feeds.technorati.com/contacts/http://www.example.com/

You can then either save the generated vCard, or add it directly to your address book.

Also from Brian Suda / Technorati comes the hCalendar tool, which transforms your data into the iCalendar standard. Again, you just link to your marked-up page using a specially formatted URL, although this time you get two choices;

http://feeds.technorati.com/events/http://www.example.com/

… returns a single .ics file with each of your events to add to a calendar; while:

webcal://feeds.technorati.com/events/http://www.example.com/

… produces a webcal feed which is updated regularly, allowing subscription to your events.

Implement these tools on your web pages and you’ll have a suite of neat features you can impress your visitors and peers with. It’s a real advantage of using Microformats.

So that’s why I was delighted to hear about the 3.1 release of my favourite browser, and doubly delighted when I found out which features the team are planning to work on for inclusion in it:

For CSS, already implemented are the full range of CSS3 selectors and the text-shadow property, and planned to join them are @media queries; for fans of nice typography, font-stretch and word-wrap are on their way, along with my favourite feature of all: @font-face! There will also be a lot of existing CSS bugs fixed.

Beyond FF3.1 (and therefore probably in FF4, currently scheduled for the latter half of next year, I believe) we may expect to see calculated values and the new modules proposed by the Webkit team, Animations and Transition.

Back in FF3.1 — and for typography fans again — SVG fonts should be implemented so that you can use the XML standard to creat text effects. SVG files will be allowed through the img tag, although no news yet whether that will apply to background-image also.

Still on SVG, SMIL, which allows the use of media files in SVG, will also be implemented. This will be complemented by the audio and video elements from HTML5.

Firefox 4 will also feature the new JavaScript VM Tamarin, open-sourced by Adobe, for richer and faster multimedia display.

That’s all pretty exciting stuff. I wonder what the recently-announced Safari 4 and Opera 10 will counter with?

First (and foremost), it wasn’t really about Microformats. The first speaker talked about RDFa and GRDDL, the second about RDFa and FOAF.

Second, the presumption was that we had an extremely high level of technical knowledge; a presumption that wasn’t true, in my case at least. I’m fairly new to Microformats but I have a pretty good idea of what they’re about; both talks went over my head anyway. And my poor wife, who’s learning about them for the first time, had no idea what was going on.

The description of the event said:

We hope that no matter your experience level, you’ll find the evening informative, enjoyable and inspiring.

I didn’t. In fact, it may well have been counter-productive for me; it took a subject I’m excited about, and made it sound complicated and boring.

I’m sure that some people would have got a lot out of it — the man next to me who’s studying for his pHD in artificial intelligence certainly seemed to enjoy it — but I think the organisers should have been more honest about the technical knowledge required, and saved some attendees a bit of time.

I did get a book for asking a question, however, so it wasn’t a total loss.

Online applications have been given a huge boost with offline storage and new HTML 5 features, but where are the shiny graphical hooks for us to play with? Below are three new features I’d like to see implemented in Firefox 3.1 (which I’ve just made up).

NB: This might seem a bit previous, as Firefox 3 hasn’t actually been released yet, but I’ve been using the nightlies for a while and it seems unlikely that any of these features will be implemented before launch.

1. SVG in img and background-image

   I believe Opera 9.5 will be the first browser to do this, and I think it’s an excellent idea. SVG allows us to make scalable, lightweight, vector elements (which can interacted with via scripting). This tutorial on dev.opera.com, How to do photoshop-like effects in SVG, gives an example of what’s possible.

2. CSS3 Selectors

   The W3C released a snapshot of CSS specs they consider stable last year; basically it covers namespaces, colour, and selectors. Firefox 3 does implement some of the new colour declarations (RGBA, HSL, HSLA), but its support for selectors has fallen behind Opera and Safari/Webkit. nth-child and its siblings may not be essential, but they’re certainly useful.

3. More experimental CSS properties

   Webkit has taken the lead on this, with text-shadow, box-shadow, multiple backgrounds, and many more, available for testing with the –webkit– prefix; and Opera is not far behind. Firefox, however, doesn’t seem to have implemented any of these according to any documentation I can find. I know the W3’s specs haven’t been finalised yet, but how are we supposed to experiment and provide feedback if our browser doesn’t support them? Mozilla was the first browser to feature columns and rounded corners, but that early experimentation seems to have been abandoned.

Come on, Firefox team; you’ve made the best browser on the market (IMHO), now give us the best layout and rendering engine to back it up.

If adopted widely, the use of SVG in <img /> and background-image could be responsible for some big changes in website design.

Take a look at this example of images in SVG (you’ll need an SVG-capable browser), which displays four photos at random positions and sizes on the page. Images could be pulled at random from Flickr (or wherever) and rotated, resized, and placed in the page as a background. Combined with multiple images, you could create layers of effect, almost like collages… pretty revolutionary.

div { background-image:
url('layer1.svg') left top,
url('layer2.svg') left top,
url('layer3.svg') left top;
}

It looks like Opera will be first to implement this feature with their 9.5 release, previews of which should be available soon. No definitive word on whether they’ll implement multiple backgrounds, but I’m hopeful.