Dissecting the Markup Code

If we are not able to make use of a library, then clearly we need to add code to manage functionality otherwise taken care of by the library. One might be forgiven for thinking that we are between a rock and a hard place – what we gain in site speed (from not calling extra resources), we risk losing when adding additional code! Granted, we won’t be adding so much, but it is a risk we still need to manage carefully.

Keeping this in mind, let’s take a look at the code we used in more detail – we will split this into two parts, starting with creating each object used in the demo:

We then create the first of our additional shapes – a polygon, which will be displayed as a triangle on screen. We’ve used the createElementNS method to construct it, passing in the SVG namespace.

It’s important to note that when creating SVG objects in code, we should use this to construct our shape, when we might otherwise have used createElement.

Why? There is a valid reason for this – using document.createElement is the standard method for creating elements within JavaScript. However, SVG as a format uses namespaces; we can separate common elements or objects that are on the same page but were created using different sources. If we use createElementNS, this simply allows us to group common elements together with a common namespace (or identity tag), so that we can style only those elements that should be styled.

It’s worth noting that you can get away with using .setAttribute but ideally should use .setAttributeNS for the same reason. Take a look at the code coming up for the Bezier curve – you will see both formats in use, although the latter is preferable!

bezier.id = “bezier”; At this point, all of our objects have been created – I profess that they haven’t all been positioned in ideal locations onscreen, but then this is all part of experimenting with code! Let’s move on and take a look at the second part of the code we’ve used in this demo, beginning with moving our viewBox dynamically.

Dissecting Our Code – the Functions Used

Although much of our code caters for creating the additional SVG objects, this is only part of the story – we’ve added in a handful of functions to illustrate how we might manipulate these SVG objects using nothing more than plain JavaScript.

We can clearly see that the code used is standard JavaScript, but with one exception – we’ve used the setAttributeNS method to recalculate the position of our viewBox. If you remember from the previous section, we talked about the fact that SVG is a format that relies on the use of namespaces, so specifying it here avoids the risk of collision with other code on the page intended for other applications.

Phew – that was one monster deconstruct! That aside, it shows that we can manipulate SVG elements using nothing more than plain JavaScript, although one must weigh up whether it is worth the effort required if your project demands anything more than a simple effect using SVG. It is always worth considering if your solution can be achieved using plain JavaScript, although the pressures and demands on your time and project may mean that using a library is the most effective and practical option!

Dissecting the Demo

If we take a look at the markup for our demo, we can see the bulk of our demo is contained within a standard SVG object that sits inside the .container div. Inside this SVG we use a <rect> that provides the border effect, along with the content div that houses both the image and image label.

The key to making it work lies in the style rule applied to the <rect> element and the associated hover event. In this case, we’ve applied three stroke values, namely stroke-dasharray, stroke-dashoffset, and stroke-width. The first controls the length of each dash around the image, interspersed with the whitespace; stroke-dashoffset controls at what point we start the border, and stroke-width for the thickness of this border.

We start by setting dashes of 150 units, followed by spaces of 210 units wide; we want this to start from point zero, so stroke-dashoffset is not needed and therefore set to zero. At the same time, our border is set to 0.1875rem, or 3px thick.

When hovering over the .container element, this is set to inherit child elements, so it includes the image and text; the border thickness increases to 0.375rem or 6px. At the same time, we no longer want our border to have gaps, so set it to 2560; this has the effect of showing one long dash around the entirety of the image.

Okay – let’s move on: time for something different, methinks! I don’t know about you, but I’ve lost count of the number of sites that use the same format for navigating around the site. Sure, it might be the classic hamburger approach for mobile or responsive sites, but in many cases, it is likely to be the typical linear affair. I think it’s time to change that and go for something a little more unusual…

Understanding How It Works

If we take a closer look at the code we put together in our Codepen demo, it might at first glance look a little complex. However, this example relies on one simple trick – we’re animating content from one state to another but doing it in stages (just like a bus travels from point A to B via C).

A large part of our markup forms the background container, inside we start with an empty placeholder for our circular menu (#menu). We also specify some simple markup to create a series of blocks (within the .navbar class), which will act as our background content. The real meat of our markup though is in two SVG group elements, inside of which are a number of SVG paths: the animgroup takes care of animating the circular menu, while the linegroup creates the fake menu entries.

To make our demo work, we’ve used the morph.to method from the morphSVG plug-in, to animate the content. This sets the starting point as #state1, which we then morph to #state2 using a Sine.easeIn easing effect. We then immediately jump back to #state1 and morph through to #state3, this time using an Elastic.easeOut easing effect. We then finish off the demo with two event handlers, which check to make sure we are at point zero (i.e., can animate to the circular menu) or reset the code so that the animated menu can reverse direction and be closed back to our original content.

Okay – let’s change tack and move onto something completely different: lazy loading. I’m sure you will be familiar with the principle of placeholders that are subsequently replaced with the real image, right? Well, instead of inserting lots of lo-res images as placeholders, how about using SVG to create something similar?

Breaking Apart Our Code

We begin first with setting a div with a class of imageContainer ; this is purely to group the two parts of our demo together. The first part of our code is our SVG image; we’ve used a random one in our code, but this could easily be a company logo or motif. It doesn’t really matter what we use, although I would recommend keeping it simple. The more complex our SVG, the more code it requires; we’re not going to see it for too long, so detail will be redundant.

The second part of our demo is really simple – we include a single div (with a class of image) as a placeholder for our final image. This is loaded using a plain vanilla script; in this, we get a reference to the aforementioned div, then set our picture from the Unsplash library as the background image. We then add a class of image-displayed; it’s not used in our demo but would act as a trigger to confirm that the image has been loaded on the page.

I hope you’re suitably rested after that mini demo, as I have a real corker of an exercise coming up for you! For our next demo, we’ll be revisiting a subject we’ve already touched on earlier in the book. – creating charts. Remember how we created various types, such as bar and pie charts? They were easy enough to do; this time though, we’ll put a whole new spin on things, and incorporate a simple pie chart into a template-based framework.

Dissecting the Code

If you were asked to write a summary of this demo, you might be forgiven for thinking where it is that one would start to explore how it works, there is so much code! Our demo looks complex, but in reality, it is simpler than it looks: a good chunk is there to support Require.js and the loading of data. The crux of our demo centers around two files – ractive.html and demo.js; these contain the markup and script required to make our demo operate. Let’s take a look at the code in more detail, starting with ractive.html.

If you open up ractive.html, a large chunk of it contains standard HTML markup; you will notice that much of this code has been wrapped in a <script> block. The difference here is in the use of the <....type="text/ractive"> tag; this is used by Ractive to define the template in our demo (more on this shortly).

Take a closer look at the code though, and you will see several examples of {{...}} in the code. These are used as placeholders for our content – take, for example, the item.name and item.population values in line 27.

These correspond to the name and population values in our JSON file; the {{# curves: num }} loop runs through each item in the JSON file and populates the values in our markup. It’s worth noting though that we make use of a number of functions in our placeholders – a good example is in line 23, where we call the function {{ lighten(color) }} to create a lighter shade of one of our base colors, before inserting it into our markup.

Exploring the Ractive Script Code

Although the markup plays an important role, it’s only when you view the script does it all begin to come together and make more sense. If we open the demo.js file, we can see two blocks at the start – the first configures Require.js to point it to the script libraries we will use. The second initiates them as a dependency; the script files are not called until they are needed in the script.

Next up comes a request to load in our JSON file – for this we are using standard jQuery for convenience; we could use JavaScript (and given this is the only time it is used, it might be no bad thing to remove a big dependency!). Before we get to our Ractive script though, we have one final variable definition – this uses the Colors library to mix two colors to help create our color scheme for the chart.

With these definitions out of the way, we now move onto our Ractive object – this is made up of three elements, namely el, template, and data. The first, el, is our target for where the compiled template will be inserted – in this case, the div with an ID of pie. The template attribute corresponds to the template we will use; remember the script block we created in our markup file, which has the ID of myTemplate? This is what we will use to generate our final markup.

The third and final section is data – this contains all of the functions and attributes used in our markup. This can contain all kinds of content; this might range from simple values such as r or R (used to specify the radius of our pie chart), through to datasets (used to specify which data files to use) and colors, where we create our palette based on the two defined base colors.

We also have a couple of extra functions of note – move and point handle the location of each label, while lighten is used to create a lighter shade of color for our palette. We then round out our demo with a call to loadCountries, to initiate our Pie chart with the appropriate data from the JSON file.

I would strongly recommend taking a look at the compiled code from within your browser’s DOM inspector – the compiled version will look something like the screenshot shown in Figure 10-6. It will help you to understand how the source code has been transformed into the final solution.

It might seem a lot of code, but this is a fairly in-depth example – partially to show off that complexity should not be an issue when using SVG, but also to show a real-world example of how SVG can be incorporated into sites written using frameworks such as Ractive. It is worth spending time understanding how this is put together – you may not use Ractive (although it is a great tool to use), but many of the principles also apply to the bigger versions such as Angular or React.

Okay – let’s move on: we’re almost at the end of our journey through using SVG, but to help round out our adventure, we will finish with some smaller, but equally interesting examples, of how we might use SVG in a more practical context in our projects.

Tilting UI Effect

Our first example comes courtesy of the developer Neil Pearce – he’s used a mini library called Tilt.js. Created by Gijs Rogé, the library itself can be downloaded from https://gijsroge.github.io/tilt.js/ .

Neil has put this library to great use, by creating two cards that display information from a mocked-up page that wouldn’t be out of place on a hotel website. You can see the demo on Codepen at https://codepen.io/2975/pen/WJwxYv  – try hovering over each card in turn: notice how it tilts slightly as you move the mouse over each (Figure 10-7):

In this instance, the demo illustrates how we can make use of other libraries to manipulate SVG elements with little difficulty; the animation effect is managed within the SVG, while the tilting effect comes from the Tilt.js library.

Panning and Zooming Images

This next example features a simple take on an age-old problem – viewing images close up, particularly those with lots of detail.

The developer Anders Riutta has created a library that enables anyone to pan or zoom in on an SVG image for this purpose; it can be downloaded from GitHub at https://github.com/ariutta/svg-pan-zoom . We can see it in use with one of the demos provided on the main website; as an example, Figure 10-8 shows an inline SVG image of a tiger in close-up.

This is just one way of navigating around SVG images – the library offers support for a host of different options, such as embedded SVGs, custom events, animation, and using custom controls.

You can see the original demo on the main website at http://ariutta.github.io/svg-pan-zoom/demo/inline.html .

Tracking Progress

Our final example makes use of one of SVG’s key strengths – the ability to use the <path> element to create any kind of shape, simply by providing suitable coordinates.

This is put to good use in the Progressbar.js library; created by Kimmo Brunfeldt, this library can be downloaded from http://kimmobrunfeldt.github.io/progressbar.js/ . It’s designed for use in modern browsers, released within the last two to three years; this includes IE10 and 11! The library produces a clean and slick design – we can see it in action in a screenshot shown in Figure 10-9.

To really understand how SVG plays its part in this library, I would recommend taking a peek at the code behind this example; Figure 10-10 shows what the SVG code looks like from our example.

The great thing about this library is that we don’t even have to provide the path coordinates to use if we want to use a standard shape; Progressbar.js provides a number of pre-built options such as circle or line. If though we want to push the boat out (so to speak), we can of course provide our custom path coordinates in the markup and let the library take care of the rest…!