Understanding the Impact of Scaling

At this point I’m sure you will be asking just how we managed to make our SVG graphic change shape and position, without changing its sizes. The key to it lies in the viewport – we’re not moving our SVG, but moving the viewport instead:

We initially don’t see any change once we’ve run step 3 and added in the viewBox attribute – our viewBox is 500px by 100px, which is identical to the viewport. Notice though that we’ve specified both a circle and a square in our SVG, yet only the former is showing? If we change our viewBox values to 25 25 500 100, this shifts our canvas up and to the left; this aligns it to the origin (25, 25), hiding part of the circle and revealing the top part of the square.

When we remove the square element and change the viewBox values, we don’t shift the canvas this time, but set the viewBox to only cover half the width and height of our viewport. This has the effect of scaling our viewBox, so that all four corners align with the viewport – this doubles the size of the canvas, scaling the circle to twice the size to fit.

If we had doubled the size of our viewBox values, then this would have had the opposite effect of shrinking our graphic – there is twice as much to cover in the same space, so the elements are shrunken to fit.

Our final change completely alters the aspect ratio of our circle – the viewBox is set as 1:2, against the viewport, which has a ratio of 5:1. This means that the circle’s height is stretched by a factor of 10, but its height remains constant; the stretching comes from the presence of preserveAspectRatio to none.

Okay – let’s move on: over the course of this exercise, we’ve touched on some of the key concepts for scaling SVG graphics. At the heart of this scaling lies the SVG coordinate system, which controls where our canvas is displayed. Each time we create a new SVG element, we also create a new coordinate system; let’s take a look at how it works in more detail.

Applying Coordinates to an SVG

Enough of the talk – let’s get stuck into some code! As any teacher will say, there is no substitute for practice, so over the course of the next couple of pages, we will work our way through some examples of creating and positioning SVG elements, so we can see the effects of setting values as coordinates for an SVG drawing.

For this exercise, we’re going to make use of Codepen as an interactive demo – this means we will see the results of our change immediately, without having to manually refresh the screen:

The changes we’ve made in our exercise have been very straightforward, yet we’ve only scratched the surface of what is possible! Trouble is, we’re still a little limited in what we can do: How can we take things further? Well, the answer comes in the form of a useful little toolkit – it may be small, but it will help earn its keep when working with SVG: let me introduce the SVG Scaling Toolbox.

We’ve already used parts of it in previous exercises, but as scaling SVGs can be tricky, it’s worth spending some time to get to know it in more detail. It comes in several parts – we’ll kick off with a look first at setting heights and widths of SVG elements.

Setting Height and Width Attributes

This seems pretty reasonable, right? We can use any one of several different units of measure, such as ems, rems, picas, or even millimeters (mm) – SVG can use standard CSS units when referring to dimensions of an image.

In our example, the <svg> element doesn’t specify any units though; by default, this equates to pixels, unless we specify a named unit. Now – assuming we have set suitable values: at first glance, one would expect any set on an SVG container, to implicitly set an aspect ratio, so that an SVG will scale in the same way as normal images. Sound reasonable, right…?

There’s one word that comes to mind – ouch! The safest way to control width and height is to not set it in code. Instead, set it within your CSS; this will allow the SVG to scale accordingly. To be sure that we set a suitable aspect ratio, and that the drawing scales to fit, we need the second tool in our kit – the viewBox. We’ve already used it a few times, so let’s take a moment to explore this in more detail.

Implementing a viewBox

Until now, we’re using a canvas that could be of any size, and that we’ve applied something called a viewBox to define the extent of what we can see at any one point. But – what really is a viewBox, and how does it work when we apply it to our code?

This little example creates an <svg> element with a width of 400 pixels and a height of 300. We’ve applied a viewBox attribute to the <svg>, which contains four coordinates, to define the view box of the <svg> element. These coordinates start with the x and y starting points (“point zero”), with width and height controlling its size.

It’s worth noting that if we were to work with other non-SVG elements, then the CSS properties object-fit and object-position work in a similar manner to the viewBox attribute.

When we’ve set a viewBox in our code, our SVG graphic will scale to fit its size, without loss of quality. However, we should note that it will not by default stretch or distort the image if the dimensions we’ve given it do not match the aspect ratio that has been set. Instead, the scale will change to preserve the aspect ratio that has been set – this is set using the preserveAspectRatio attribute, so let’s dive in and see what this in means for us in more detail.

Preserving the Aspect Ratio

Ask anyone to think of famous double acts, and one might get a variety of answers – Cagney and Lacey, Smokey and the Bandit…the list is endless! How does this relate to SVGs, I hear you ask…?

Well, leaving aside the reference to well-known films, one might say that the viewBox parameter is but one half of a double act (if you excuse the pun!) – It’s partner in crime is preserveAspectRatio. By itself, it has no effect on our SVG, but when teamed up with viewBox, its role is to define how an image should be scaled, if the viewBox doesn’t match our viewport’s aspect ratio.

In most cases, we can simply set it with default behavior, which works well in most cases – our image will be scaled until it fits the available space, allowing for any extra space around the image.

For a full list of options, please refer to https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/preserveAspectRatio .

An interesting point worth noting that this second attribute works in a similar fashion to standard CSS for background images – the closest equivalent for meet is background-size: contain, and for slice, we could use background-size: cover. The only thing to be aware of is that when using slice, it will scale the image to the largest dimension, and may or may not slice off the rest – the latter depends on how we have (or have not) set the value of the overflow property!

We may of course decide not to specify a value at all, and rely on it simply using the default of none. This allows the SVG to scale more like a raster image (but clearly with better resolution) – it will stretch or squash the image to fit the height and width values specified in our code.

To really understand how the coordinate system works, and the impact of changing viewBox or preserveAspectRatio properties, I would recommend trying out the interactive demo by Sarah Soueidan, at https://www.sarasoueidan.com/demos/interactive-svg-coordinate-system/  – this is a great eye-opener!

Right – enough chitchat: time we got physical with some code! Although the Scaling Toolbox attributes may look straightforward enough, their simplicity belies the strength of their power; let’s put some of that to use, with a quick demo to see the impact of setting these values in code.

Understanding How It Works

So – what did happen in our demo? The key to understanding it is that we have not changed the image itself (even though it may appear so), but we have changed how we view that image. Let me explain what I mean:

Notice how in two out of the three cases, our viewBox doesn’t change size; in the third example, we reduce the size, which has the effect of zooming in on our image, so it becomes more enlarged.

Our first example sets preserveAspectRatio to none – this tells our viewBox to scale to fit the size of our viewport, effectively (in this instance) aligning both to the same set of coordinates as each other. The net effect of this is that the image itself is not scaled accordingly but squashed into whatever dimensions we specify: this results in something of a distorted image!

In comparison, setting xMidYMax slice tells our viewBox to scale our graphic; we align the smallest value of our viewBox (point zero) with the smallest value of our viewport. The key here is the use of meet – this tells the viewBox to scale up to, but not over the edge: in other words, “Align the image to be horizontally centered, but push it towards the bottom edge of our view box.”

Our third and final example takes a different tack – this time, our viewBox does not have a uniform size; it follows the same principle of alignment as our second example. This time though, we’ve set our second attribute to slice – this scales the SVG to the point that no empty space is left; it makes it look like we’ve really zoomed in on our image! If we were using standard CSS, then the equivalent would be background-size: cover.

Okay – time for a change of subject: as a developer, I’m sure you will be familiar with the need to make content available on multiple devices, right? We live in an age where more people access the Internet through devices other than a standard desktop PC; this will only increase over time!

At this point, I’m sure you will be asking what does this mean for SVG images – how easy is it to make an image responsive? Thankfully it is easy enough to do, and in fact we can use many of the same principles we might use for other content. Let’s take a moment to explore what is required in more detail.

Introducing the Golden Rules

Ouch – it looks a little scary, but many of these guidelines can be automated: for example, we can use Node.js to automate tasks such as optimizing and minifying our code. These guidelines are not just about pure coding, but also about the creative thought and testing processes – after all, there’s more to just producing code, right?

Okay – let’s move on: time, I think, for a demo! We’ve talked a lot about how to make images responsive, so why not put this into action and see what it looks like in practice? With that in mind, let’s take a standard image and run through the steps to make it responsive, before applying media queries to help make our image truly responsive.

Updating SVG Images

For our next exercise, we’ll use a standard SVG image  – this time it will be of my favorite drinks, coffee! Yes, I’m sure this will be something many developers can relate to – long nights of coding, regular bouts of caffeine to keep going…not healthy I know, but sometimes needs must…

But I digress – we’ll use an SVG from the openclipart.org site; our one can be found at https://openclipart.org/detail/293550/coffee-to-go . I’ve already included a copy in the code download; please feel free to substitute if you want to use a different image.

Go ahead and try resizing your browser window – what happens? Hopefully you will see that the image resizes automatically, without any loss of quality. The key here is that we’ve used the code we outlined in “Making SVG Content Responsive”; this proves that it is very easy to resize a basic SVG image. Granted, it might not work for some images, but it should be enough to cater for most standard SVG images.

Take a look at the CSS file used for this demo – you will see some of the code commented out. This is with good reason: you may find occasions when we don’t need to specify all of the code we used earlier, and that you can get away with just the attributes that have not been commented out.

Okay – what’s next, I wonder? We’ve touched on the basics of making images responsive, but there may be occasions when we find that simply adding max-width values isn’t enough. This might be for images that become unreadable on small screens, or where it isn’t necessary to display some content on particular devices. This is a perfect opportunity to use media queries, so let’s dive in and take a look at how we can set these up to work with SVG images in more detail.

Using Media Queries with SVG Content

Creating content that responds to a particular device can be a real minefield – there are so many decisions to make! What do we display? Do we hide X, and show Y instead…?

With standard formats such as JPEG or PNG, it’s simply a case of showing or hiding them, or perhaps resizing them to allow for the change in size of their location. But with SVG, this opens up some real possibilities – instead of changing the whole image, how about affecting a part of it? Yes, you heard me right – it’s easy to do, and adds a degree of flexibility to what we can achieve. It’s a perfect opportunity for a quick demo, so let’s dive in and see how easy it is to remove elements from an SVG image.

See how easy that was? All we’re doing is applying a technique that will be familiar to anyone who has developed responsive sites before; the trick (if anything) is where to apply the media query. As we’ve seen in our demo, the query must be inside the SVG; placing it outside might make better sense from an architectural perspective, but this is one of those occasions where we’re obliged to keep the rules within the SVG!

There is indeed a benefit to this approach – as media queries have to be stored internally, they will only ever react to the viewport of the image, not of the browser; it means that we can control how images look, independently of how they will be used.

The code within these <defs> tags is just standard media query code, to hide the two elements identified earlier in our code.

Understanding the Pitfalls

Up until now, I’ve painted what might seem a rosy picture – in that all we need to do is add a little code, and that all will be well, right...?

In many cases, it would seem that the 80:20 rule would apply, but in reverse – the easy (20%) part is to add the code, but the harder, “bigger picture” part is making sure our site works as we expect!

Let’s change tack – we’ve almost reached the end of our journey through scaling SVG, but I want to leave you with some parting comments on one particular subject: Do we make our images responsive, or adaptive? Is there a right or wrong answer, or is it just a case of choosing one we prefer…?

Making SVG images Adaptive or Responsive ?

Making images responsive can be a double-edged sword – while the code required can be very easy to implement, I’ll bet there are still questions being asked as to how images should be made “responsive” in the first place, right?

In truth, there are lots of different options we could use – many date from some years ago, and have either fallen out of favor, or been superseded by techniques that are cleaner and simpler to implement. This isn’t helped by some of the terms that we may hear – it can get very confusing!

To start with, you might have heard of the phrase “adaptive” – what does that mean, and how does it differ? Well, if you were referring to standard images, it’s about caching various sizes of an image, then serving the most appropriate size based on the detected screen size in use. This method relies on server-side code, which isn’t ideal – it’s a dated approach, and there are definitely better alternatives available. But – some people may treat the adaptive approach as referring to the use of media queries, which is a perfectly valid approach: perhaps you can understand why it might seem confusing! This isn’t helped by the fact that we can nest SVG images inside each other – not only is our main SVG now responsive, but the ones inside will also be too…

If we use this approach, we may need to set a max-width value to be sure that our image remains visible at extremes, but our image will always remain in scale with the rest of our document.

There is no one single right or wrong answer to solving this conundrum – the easy answer is that it will depend on individual circumstances. The technology is such now that we should not need to rely on server-side solutions to display images; we can use markup such as <picture> and the srcset attribute to render the appropriate image for the desired screen width. This should remove the need for media queries for all browser except IE; for this browser, we can use a polyfill such as Scott Jehl’s picturefill library, available at http://scottjehl.github.io/picturefill/ .

As a good starting point though, we can specify percentage values in place of static sizes; this will cover most scenarios, although there may be occasions where a more complex solution is required. Part of what we do will depend on which browsers we support – it may be a case of using the <picture> element, which does support a form of media query; I personally think this approach is cleaner than using media queries, but that is just personal preference! Whichever route we decide to use, I think that old adage of “test, test and test again” is so apt – any method we use should be tested to ensure maximum compatibility for the browsers we choose to support when using our site.