The day before the conference I gave a whole-day workshop on Responsive Web Design, teaching design and development approaches and — more importantly — a new workflow more adapted to the demands of the new way of working. I was helped hugely in this by the fact that I’d recently finished reading Stephen Hay’s new book, Responsive Design Workflow.

Disclaimers: I received this book for free from the publisher; I know Stephen (mostly from online); and he recently gave my own new book a very nice review. With all that you could question my impartiality, but while I don’t claim to be free from bias, it’s very lucky indeed that this is a great book in its own rights and I don’t have any conflict about recommending it.

The book is broken into eleven chapters, ten of which each cover a step in the new process that Stephen uses. Highly detailed wireframes are out, as are static Photoshop designs, being replaced by more content-led phases: a content inventory, rough content-led wireframes with breakpoint graphs, early stage markup, and lots of rapid prototyping.

Next the book goes on to detail new approaches to design, starting with designing in the browser and creating automated screenshots, and moving on to creating style guides and pattern libraries. All of this is carefully considered, and makes perfect sense in the light of the different way we have to work in order to put responsive design at the heart of our builds.

It must be stressed that this book is not about the responsive workflow, but a responsive workflow; one that Stephen has adopted in the projects on which he works. At times the book becomes very detailed in describing some of the software and processes he uses, which may not be relevant to the way you work; but he makes clear that this is not going to work for everybody, and that you should be planning your own way to suit the particular methods of your organisation.

And that’s what makes this a very important book: it’s a considered, detailed, cogent examination of the shortcomings of the way we work and a proposal for a better way. Even if you think every step he proposes is unsuitable for you (which I find highly unlikely) you’ll at least be forced into considering an alternative, because these problems are real and require a solution.

It’s also clearly and informally written, with plenty of grace, wit and insight. It leaves me quite envious.

The issue at hand is this: to add an event listener to an element, you use the addEventListener() method with the type of event, and the name of the listener — most often, a call to a pre-defined function:

el.addEventListener('click', foo);

When you want to remove the listener, you use the removeEventListener() method, with the same arguments to ensure that only the specified event and listener combination is removed:

el.removeEventListener('click', foo);

Simple. But it becomes less straightforward when you use an anonymous function as the listener, perhaps because you want to call another function and pass arguments to it:

el.addEventListener('click', function() {
  foo(bar,baz);
});

In order to remove this listener you have to know the name of it. But it’s anonymous! What are we to do? The answer is ridiculously simple: don’t use anonymous functions. You could instead name the function in the listener, then remove it when the function has run:

el.addEventListener('click', function _func() {
  foo(bar,baz);
  el.removeEventListener('click', _func);
});

Alternatively, you could assign the function to a variable, then use that variable as the listener:

var _func = function() {
  foo(bar,baz);
}
el.addEventListener('click', _func);

And remove it by using the variable name again:

el.removeEventListener('click', _func);

These solutions seem so obvious that I debated whether it was worth recording them here, but in my searches I couldn’t find them listed anywhere; I hope that by writing them up I’ll save someone some searching time in the future.

On the previous day, Thursday 13th June, I’ll be giving a one-day Responsive Web Design workshop, where I’ll be teaching the full process of creating a responsive website: planning and strategy, prototyping, tools, design deliverables, and, of course, coding. Alternatively, if your CSS is not quite up to scratch and you need a refresher before the conference, Eric Meyer will be giving a workshop which will teach you all you need to know.

Each workshop costs €300, and the conference day costs €250 (Dutch VAT of 21% will be added to both). Full details, programme and tickets are all on CSSDay.nl, along with a nice little Easter egg I found out about today: click on a speakers name on the Programme page to see some live examples of their chosen subject!

Oh, and as if my conference and some fantastic talks weren’t enough, as a bonus you get to spend a few days in beautiful Amsterdam. I’m really excited to be a part of this, and hope to see you there!

The positives

Some mobile apps are extremely well made and I would have no difficulty at all in switching to them today. Of special note are Twitter and Facebook, which have — as far as I can tell — full feature parity (in all the features I use, anyway) with their native siblings. Twitter in particular have taken a lot of time and effort to provide a first-class experience on the mobile web.

The Guardian’s mobile site is also beautifully designed — better even than the native app, in my opinion — and BBC News and Sport are also of the highest quality. Google’s mobile apps — Gmail, Calendar, Reader, and Maps — are not quite as slick as the native versions, but are undoubtedly very functional and usable.

The negatives

A few of the apps I use frequently were just not up to scratch on mobile. I have to single out Foursquare who, somewhat surprisingly for such a mobile-focused service, have a shockingly poor mobile web offering, not optimised for modern phones at all. The Google+ app was pretty poor while I was testing, although a new version has just been released which seems much better. Instagram’s mobile site is okay, but is purely for consumption — there’s no way to add new photos. But these apps were nice to haves rather than essential, so I could have done without them if I’d switched to an all-web OS.

The problem came with the lack of system settings. For example, unlike Niels Matthijs I like to have notifications for certain content, and web apps on Android don’t have access to notifications.

More seriously, there is no integration between apps at all; unlike with Android’s Intents, I can’t begin a task in one app then send it to another; each mobile web app is an island unto itself, so I can’t tweet a photo from my gallery, or save a link to Pocket or Evernote.

The biggest annoyance, however, was that running an instance of an app wouldn’t make it visible in other tabs; for example, if I had Twitter in tab A then followed a link to a Tweet in tab B, a new instance of Twitter would open in tab C. My tabs soon filled up with multiple instances of the same app.

The conclusion

It’s likely that if I were coming at a web-based OS afresh I would develop new habits and ways of working to achieve my behavioural goals. However, as a convert from a system that works for me, with inter-app operation and notifications, I found myself extremely limited and became frustrated quite quickly. This means that I don’t feel I can switch to web apps permanently right now, and that’s a shame because in some cases I didn’t miss native apps at all.

All the problems I mentioned above are problems that Firefox OS will have to solve, and I believe that they have the APIs to do it; however, if an outreach process to get big apps to use Web Activities and Notifications isn’t underway already, it should be started very soon.

Update: It occurred to me after writing this that my mental model of what I expect from apps would probably be very different if I were an iOS user, where each app is essentially an island anyway, and notifications are generally much fewer or non-existent. However, the issue with multiple instances of an app being opened in new tabs is annoying regardless of your current choice of platform.

Reporting notes

Stats are taken from Google Analytics from the period 1st January 2013 to 26th April 2013 (it took me a few days to write this post). I’m going to give the mean average of stats between the two sites, noting where there is significant variation — and I’ll speculate on the variation at the end of the post.

I decided not to use the stats from this blog as it tends to skew towards a very non-typical audience, consisting in large part of the tech-savvy and early adopters. Instead I’m using two sites I manage which I think have a more ‘normal’ set of visitors (no offence intended, dear reader).

To keep the sites anonymous I’ll refer to them as Site A and Site B. Site A is for news and opinions on Arsenal football club. It’s London-centric but has an international audience, and had an average of 1,935 unique visitors per day in the selected period. Site B is a hyper-local blog for a London neighbourhood, and its audience reflects that. It had an average of 120 unique visitors per day. Both sites are updated semi-frequently but irregularly.

Selected stats

The percentage split between mobile (including tablet) and non-mobile is 31.2 to 68.9. Of those mobile visitors, iOS accounted for 68.4 percent and Android for 23.3. Blackberry was a distant third, with other mobile OSes barely registering.

In overall OS stats, Windows is still by far the dominant platform, with more than double the visits of the second-placed iOS. Some strong variation to note here: Site A had 12.2 percent of visitors using OS X, with Site B on 27.1.

In overall browser stats, Safari is the perhaps surprising leader, thanks to the large share that iOS holds. Some very strong variance to note: Site A actually had Opera Mini in fourth place with 7 percent share, beating Android into sixth, while on Site B there were no hits at all from Opera Mini.

Breaking Internet Explorer into the different versions, IE9 is the most popular followed closely by IE8. Very gratifyingly, IE6 is barely existent and soon to be gone altogether. There was a point of strong variance here: Site A had IE8 on 42.1 percent of the IE share and IE9 on 41.6, while Site B had the same versions on 35.3 and 50.3 percent respectively.

Finally, in my original tweets I noted that over 98 percent of visitors running iOS devices used their phone in portrait mode, but this is incorrect; in fact Safari for iOS only shows dimensions for the portait mode, even when in landscape, so there’s no way to get this figure. Android devices don’t follow the same pattern, however, so there we can see that an average of 92 percent of visits were made using a device in portrait mode. I can’t be sure where the false iOS figures came from; perhaps other browsers on iOS, or jailbroken devices.

Speculation on variance

There are a number of points of strong variation: in visitors using OS X; in the use of Opera Mini; and in IE8 vs IE9. My broad theory to explain this is that Site A has a global audience, including a not insignificant number in emerging markets across Africa and Asia, whereas Site B is almost exclusively visited by (comparatively) wealthy Londoners, which explains the higher number of Macs in Site B, and the use of Opera Mini on Site A (from areas with poorer network coverage and a higher incidence of low-end handsets). As for IE, I’d speculate that you need a genuine copy of Windows 7 to run it, and I believe that Site A’s global popularity would mean that it’s used on pirated Windows which couldn’t install it.

Of course, this is all speculation, and with the limited sample base I have, especially on Site B, it could just be an aberration in the data. As always, it pays to use many different data sets.

If you’ve used Mustache, Handlebars or any similar front-end templating library you’ll be quite familiar with how the template element works: you just include it in your document (it’s apparently legal inside head or body), perhaps with a unique id for easy reference, and add some markup inside it; for example:

<template id="foo">
  <h2>Hello, world!</h2>
  <hr>
</template>

The template element will be parsed by the browser but not rendered in the page; the markup inside is considered completely inert, meaning no style rules will be applied, and no assets loaded. In order to use the template markup you’ll need to activate it by placing it into the DOM using JavaScript. As an illustration let’s presume I have the above markup in my document, along with some content which will be rendered:

<div id="bar">
  <h1>The template element</h1>
</div>

What I want to do is make a copy of the markup inside the template element by using the cloneNode() method on the content property, then insert it into the DOM; I’ll do this using the appendChild() method. To achieve this, my script looks like so:

var foo = document.getElementById('foo'),
    bar = document.getElementById('bar'),
    cloned = foo.content.cloneNode(true);
bar.appendChild(cloned);

Now the h2 and hr elements will be appended to div#bar, after the h1 element; note that the markup becomes active at this point, so any relevant assets will be loaded. The resulting markup will appear like so:

<div id="bar">
  <h1>The template element</h1>
  <h2>Hello, world!</h2>
  <hr>
</div>

You can see the result for yourself in this example file:

Demo: the template element

As mentioned, this is already implemented in Chrome Canary (you’ll need to enable the experimental WebKit features flag in chrome://flags/) and Firefox Nightly, although there’s no news yet on when this will be in a release version.

This is a really simple example, but hopefully you can see how rich with potential this is; you can dynamically update the code each time you clone it, making it totally reusable. The template element is just a small part of Web Components, which I’ll be aiming to cover in more detail over the coming months.

NB: After writing this post I found the article HTML’s New Template Tag on HTML5 Rocks!, which covers the subject in a little more depth. It’s written by Eric Bidelman, who’s pretty much the authority on Web Components.

Update: I should point out that when the spec is fully implemented, templates will be shareable across multiple pages by linking to them in the document head:

<link rel="import" href="templates.html">

Creating your icon

To get started you need one other piece of software, which is a graphics package capable of exporting SVG. You can use Adobe Illustrator if you have it, or consider the fantastic SVG Edit if not. I prefer Inkscape, which is fully featured and free (although the interface has a slight learning curve).

IcoMoon icons are based on 16x16 pixel grid by default, so in your vector graphics software make a new document on a square grid which is a multiple of 16 on each side; I find that 512 is ample for most icons, although you could use, for example, 256, 1024 or 2048. The larger your grid, the more detailed your icon can be — but do bear in mind that detail doesn’t always scale down well.

The next step is to draw your icon. You’ll want to overlay a grid on the canvas to help with the positioning of the components of your icon. If you can, change the units of your grid to multiples of 16; if that’s not possible, size and position objects by dividing the dimensions of the canvas by 16. For example, when I’m working on a canvas that’s 512 squared I use multiples of 32 (512 ÷ 16); so if I want an object that will be 4×4 in size and 2 from the top in my finished pixel grid, I make it 128×128 and 64 from the top in Inkscape.

It’s also very important to make sure that objects snap to the grid you’ve created; if they don’t then the browser’s rendering engine will use aliasing to try to compensate when scaling, which can result in fuzzy edges on your icon — the opposite of what you’re aiming for. The following image shows my icon aligned to the grid (left) and off it (right).

Using a scaled grid and snapping objects to it will help a lot in making the icon perfectly scalable.

IcoMoon has some good tips on making icons that import well, and one that has tripped me up many times is that you should not use strokes, as they’re not rendered; use shapes only, or at least convert your strokes to shapes.

Adding your icon to a font

When your icon is complete, export the file as an SVG, then fire up IcoMoon. The first step of using this is to import your SVG file(s); if they’ve been built correctly they’ll be shown in the Your Custom Icons section. Highlight the ones you want to use in your font, and proceed to the next step by tapping the Font button.

On the following page all of your new icons are shown, and you can rearrange them and assign them to different characters in the UTF table. When you’re satisfied with your organisation, tap Download and you’ll be presented with an archive file, inside which is a folder containing your font in WOFF, TTF, EOT and SVG formats. You can then add these to your document using @font-face.

Below is the icon I made earlier, shown at three different sizes so you can see for yourself how nicely it scales.

• a
• a
• a

That’s about it. You may need to tweak and finesse a few times initially until you get the desired result, but that’s really all there is to creating your own icon fonts.

Before I explain that drawback, let me set the scene with some very simple example markup of a list used for navigation:

<ul>
<li>Nav One</li>
<li>Nav Two</li>
<li>Nav Three</li>
<li>Nav Four</li>
</ul>

And some CSS to make it display horizontally:

li {
  display: inline-block;
  width: 25%;
}

As you can see in the following example, when this renders there’s a small amount of whitespace between each child item; this can cause a problem if you want to use percentage widths to fill the parent, as the whitespace forces the final element onto a new line.

• Nav One
• Nav Two
• Nav Three
• Nav Four

This is caused by the markup being broken over multiple lines; when items are displayed as inline-block any carriage returns or tabs in the markup are recognised as a whitespace character. That being the case, you can fix this problem by writing your markup with no space between the items:

<ul><li>Nav One</li><li>Nav Two</li><li>Nav Three</li><li>Nav Four</li></ul>

If you prefer a CSS approach the usual fix for this is to set a negative margin-right value on each child element, but I recently happened upon another approach: as each element is rendered as if it were a word in a sentence, it’s also possible to use a negative value on the word-spacing property of the parent:

ul { word-spacing: -0.26em; }

The value seems to be about 25% of the font size, except in Firefox where it seems to be 26%. Note that this is only relevant for font-size values of 16px or over; below that, the percentage should be increased. Anyway, the result is that the whitespace is removed:

• Nav One
• Nav Two
• Nav Three
• Nav Four

There is a drawback to this, in that the value of word-spacing is inherited by all of the child elements, so if they contain multiple-word values you’ll have to restore word-spacing to its default value:

li { word-spacing: 0; }

• Nav One
• Nav Two
• Nav Three
• Nav Four

The initial keyword would be even better here, but its use is somewhat limited as it’s not yet supported by Internet Explorer.

As this method potentially relies on using two properties, I’m not sure it’s any better than using a negative value on margin-right; really I just wanted to record this for future use, as I haven’t seen it documented elsewhere.

Update: I have to hold my hands up and admit that I didn’t properly test the first version of this article. The value of word-spacing is relative to font-size, so the value I originally used in my examples, 4px, is only relevant at the default font-size of 16px. The updated value I’ve used instead, 0.26em, works better in all of the browsers I’ve tested but you may need to double-check this yourself — there is certainly some unexpected behaviour in Safari.

The best approach might be an alternative suggested in the comments; set a font-size of 0 on the parent to remove the whitespace problem, then set the desired font size on the children; e.g.:

ul { font-size: 0; }
li { font-size: 1.6rem; }