The most straightforward way to use an SVG graphic is exactly how you would insert any image into an HTML document. We just use a good ol' img tag:

<img src="mySconeVector.svg" alt="Amazing line art of a scone" />

This makes the SVG behave more or less like any other image. Not much more to say about that.

The object tag is the container recommended by the W3C for holding non-HTML content in a web page (the specification for object is at http://www.w3.org/TR/html5/embedded-content-0.html). We can make use of it to insert an SVG into our page like this:

<object data="img/svgfile.svg" type="image/svg+xml">
    <span class="fallback-info">Your browser doesn't support SVG</span>
</object>

Either a data or type attribute is required, although I would always recommend adding both. The data attribute is where you link out to the SVG asset in the same manner you would link to any other asset. The type attribute describes the MIME type relevant for the content. In this instance, image/svg+xml is the MIME (Internet media type) type to indicate the data is SVG. You can also add a width and height attribute too if you want to constrain the size of the SVG with this container.

An SVG inserted into the page via an object tag is also accessible with JavaScript so that's one reason to insert them this way. However, an additional bonus of using the object tag is that it provides a simple mechanism for when a browser doesn't understand the data type. For example, if that prior object element was viewed in Internet Explorer 8 (which has no support for SVG), it would simply see the message 'Your browser doesn't support SVG'. You can use this space to provide a fallback image in an img tag. However, be warned that from my cursory testing, the browser will always download the fallback image, regardless of whether it actually needs it. Therefore, if you want your site to load in the shortest possible time (you do, trust me) this might not actually be the best choice.

An alternative approach to providing a fallback would be to add a background-image via the CSS. For example, in our example above, our fallback span has a class of .fallback-info. We could make use of this in CSS to link to a suitable background-image. That way the background-image will only be downloaded if required.

SVGs can be used as a background image in CSS, much the same way as any other image format (PNG, JPG, GIF). There's nothing special about the way you reference them:

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

For older browsers that don't support SVG, you might want to include a 'fallback' image in a more widely supported format (typically PNG). Here's one way to do that for Internet Explorer 8 and Android 2, as IE8 doesn't support SVG or background-size, and Android 2.3 doesn't support SVG and requires a vendor prefix for background-size:

.item {
    background: url('image.png') no-repeat;
    background: url('image.svg') left top / auto auto no-repeat;
}

In CSS, where two equivalent properties are applied, the one further down the style sheet will always overrule those above. In CSS, a browser will always disregard a property/value pair in a rule it cannot make sense of. Therefore, in this case the older browsers get the PNG, as they cannot make use of the SVG or understand an un-prefixed background-size property, while newer browsers that could actually use either, take the bottom one as it supersedes the first.

You can also provide fallbacks with the aid of Modernizr; the JavaScript tool for feature testing the browser (Modernizr is discussed more fully in Chapter 5, CSS3 – Selectors, Typography, Color Modes, and New Features). Modernizr has individual tests for some of the different SVG insertion methods, and the next version of Modernizr (unreleased at the time of writing) may have something more specific for SVG in CSS. For now however, you can do this:

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

Or invert the logic if preferred:

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

When Feature Queries are more fully supported, you could also do this:

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

@supports (fill: black) {
    .item {
        background-image: url('image.svg');
    }
}

The @supports rule works here because fill is a SVG property so if the browser understands that, it would take the lower rule over the first.

If your needs for SVG are primarily static background images, perhaps for icons and the like, I highly recommend implementing SVGs as background images. That's because there are a number of tools that will automatically create image sprites or style sheet assets (which means including the SVGs as data URIs), fallback PNG assets, and requisite style sheets from any individual SVGs you create. Using SVGs this way is very well supported, the images themselves cache well (so performance wise they work very well), and it's simple to implement.

If you're reading that prior section and wondering what on earth a data Uniform Resource Identifier (URI) is, in relation to CSS, it's a means of including what would ordinarily be an external asset, such as an image, within the CSS file itself. Therefore, where we might do this to link at an external image file:

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

We could simply include the image inside our style sheet with a data URI like this:

.data-uri {
  background-image: url(data:image/svg+xml,%3C%3Fxml%20version%3D%221.0%22%20encoding%3D%22UTF-8%22%20standalone%3D%22no%22%3F%3E%0A%3Csvg%20width%3D%22198px%22%20height%3D%22188px%22%20viewBox%3D%220%200%20198%20188%22%20version%3D%221.1%22%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%20xmlns%3Axlink%3D%22http%3A%2F%2Fwww.w3.org%2F1999%2Fxlink%22%20xmlns%3Asketch%3D%22http%3A%2F%2Fwww.bohemiancoding.com%2Fsketch%2Fns%22%3E%0A%20%20%20%20%3C%21--%20Generator%3A%20Sketch%203.2.2%20%289983%29%20-%20http%3A%2F%2Fwww.bohemiancoding.com%2Fsketch%20--%3E%0A%20%20%20%20%3Ctitle%3EStar%201%3C%2Ftitle%3E%0A%20%20%20%20%3Cdesc%3ECreated%20with%20Sketch.%3C%2Fdesc%3E%0A%20%20%20%20%3Cdefs%3E%3C%2Fdefs%3E%0A%20%20%20%20%3Cg%20id%3D%22Page-1%22%20stroke%3D%22none%22%20stroke-width%3D%221%22%20fill%3D%22none%22%20fill-rule%3D%22evenodd%22%20sketch%3Atype%3D%22MSPage%22%3E%0A%20%20%20%20%20%20%20%20%3Cpolygon%20id%3D%22Star-1%22%20stroke%3D%22%23979797%22%20stroke-width%3D%223%22%20fill%3D%22%23F8E81C%22%20sketch%3Atype%3D%22MSShapeGroup%22%20points%3D%2299%20154%2040.2214748%20184.901699%2051.4471742%20119.45085%203.89434837%2073.0983006%2069.6107374%2063.5491503%2099%204%20128.389263%2063.5491503%20194.105652%2073.0983006%20146.552826%20119.45085%20157.778525%20184.901699%20%22%3E%3C%2Fpolygon%3E%0A%20%20%20%20%3C%2Fg%3E%0A%3C%2Fsvg%3E);
}

It's not pretty but it provides a way to negate a separate request over the network. There are different encoding methods for data URIs and plenty of tools available to create data URIs from your assets.

If encoding SVGs in this manner, I would suggest avoiding the base64 method as it doesn't compress as well as text for SVG content.

My personal recommendation, tool wise, for generating image sprites or data URI assets, is Iconizr (http://iconizr.com/). It gives you complete control over how you would like your resultant SVG and fallback PNG assets. You can have the SVGs and fallback PNG files output as data URIs or image sprites and it even includes the requisite JavaScript snippet for loading the correct asset if you opt for data URIs; highly recommended.

Also, if you are wondering whether to choose data URIs or image sprites for your projects, I did further research on the pros and cons of data URIs or image sprites that you may be interested in should you be facing the same choice: http://benfrain.com/image-sprites-data-uris-icon-fonts-v-svgs/

While I'm a big fan of SVGs as background images, if you want to animate them dynamically, or inject values into them via JavaScript, then it will be best to opt for inserting SVG data 'inline' into the HTML.