README

I’ve noticed that many websites break down poorly as their webfonts fail to load for whatever reason and subsequently fall back onto the system fonts. This is quite common, especially on mobile devices with slow connections and yet it’s strange to see websites that have great typography with vendor fonts, but fall to bits when the slightest problem occurs. The measure might be too wide or the line-height too tall for that particular font; what is required of one typeface can sometimes mean actively fighting the typographic requirements of another. As the x-height of a font might call for a shorter line-height in the paragraph, the fallback may be something like Verdana that requires a considerable amount of space between each line. So how can we handle these two possible environments? What we really need here is to define two rules for typography in our stylesheets; one for the core fonts, the other for those from a vendor. Thankfully this is relatively easy if we use Modernizr. If you haven’t fooled around with Modernizr before then it’s best to describe it as magic, but technically it’s a feature detection library which will add a class to the html element depending on a browser's features. This might be support for svg, audio or even Javascript itself. On a modern Webkit browser you’ll probably see something like this appended to the html element if Javascript and Modernizr are running properly: html <html class="js no-flexbox flexbox-legacy canvas canvastext webgl no-touch geolocation postmessage websqldatabase indexeddb hashchange history draganddrop websockets rgba hsla multiplebgs backgroundsize borderimage borderradius boxshadow textshadow opacity cssanimations csscolumns cssgradients cssreflections csstransforms csstransforms3d csstransitions fontface generatedcontent video audio localstorage sessionstorage webworkers applicationcache svg inlinesvg smil svgclippaths" ></html> These classes are a standard listing of the capabilities of the device but it’s also possible to configure particular tests that we want Modernizr to run. In this case we’ll be using fontface to detect whether the custom webfonts in our stylesheets are running. If a browser does not detect those @fontface rules in our stylesheet then Modernizr will do nothing and the html element won’t have this class added to it. But now we can begin to separate the two styles like this with Sass: scss body { font-size: 100%; font-family: Georgia, serif; line-height: 1.55; font-weight: 600; .fontface & { font-size: 105%; font-family: "Poynter Serif RE", serif; line-height: 1.65; font-weight: 400; } } And there we have it. Since Modernizr requires us to have the .no-js class appended to the html element before anything happens, it will swap that out as it detects the device’s capabilities. With the code above we’ve separated the default styles that will apply to every child element within. Now we can begin to break down all of our typographic styles into two factions as necessary. Ideally this would go further, so that as a browser moves through the array of the font-family it would automatically pass through an array of predetermined styles. I’m not so sure if that’s really feasible at the moment, nor am I certain that this will work with mobile browsers with poor connections (since Modernizr might append the fontface class to the element and then fail to fully load the webfonts afterwards). This is a promising start though and since I haven’t read anything elsewhere about this technique I thought I might share it here.

Not much needs to be said about this book by Robin Kinross. Once your eyes skim over the words Hyphen Press on the title page then you probably already know what to expect. Indeed, this small English publisher has made their consistently euphoric writings on typographic history almost commonplace (as can be seen in their back catalogue which holds some of the finest books on typographic history ever printed). But what stood out to me so brightly here is Kinross’ argument about making work public, about focusing on the impact that typographic theory had on its practice. Since the beginning of the printing trade, the technology and application of certain techniques was seen as a dark art. It took several hundred years until people began to share this information about their work; fears of competition, of losing something that was theirs and the stagnant dialogue between tradesmen began to affect the progress of the community at large. Kinross describes the fascinating emergence of this conversation: > The first move in the long process of the break-down of the printing trade was the splitting of the editorial function away from the workshop and into what would become the publisher’s office. With this division, printing began to be opened up: its secrets started to be articulated. Kinross takes this idea further and into unexplored territory as he argues that modern typography had only begun with this articulation and blossoming of public consciousness, some 250 years after Gutenberg’s invention: > Printing becomes modern with the spreading of knowledge about itself: with the published description of practices; with the classification of its materials and processes; with coordination of dimensions of materials, enabling their exchange and better conjunction; with the establishment of a record of its history. Oddly enough, those that shaped and defined the medium chose not to use it. Consequently their dark art lingered in illusive and uninviting circles for so many years. But I can’t help compare this to how web designer’s work in public today; the well-known and the familiar, from Chris Coyier, John Boardley and Jeffrey Zeldman, to the less prolific figures that share tutorials about the benefits of Compass and SASS (Syntactically Awesome Style Sheets). Although similar to print in some ways, it seems that the web can only survive in the open – or under a finely tuned lens – and so each of us must record our pokings and proddings because we have a say in the future of a medium like no one else before.

As a developer I’m always on the lookout for the best applications, the fastest machines and the latest, most colourful updates to a product line. But sometimes I find that this can be unhealthy, addictive behaviour and so slowly, over the years, I’ve tried to become more critical of the tools around me. There are two questions that I try to ask as often as possible. 1. How does this [app/feature/machine/code editor etc.] influence my design and development process? 2. What can I learn from this tool beyond the immediate and fleeting short-term gains? It’s strange to think in this way though. Why should a tool do anything more than what it was designed to? Well, I think these sorts of questions give us ample opportunities to learn more about why we work in the ways that we do. Why these apps or services? What is it about their functions and style that is of interest in this field? What does this combination of techniques say about the rest of the industry collectively? What tends to bother me is when others fetishise the instruments that they use, for example in an interview when a designer or developer is asked to list their favourite applications. These might be useful in the short term but so little is revealed about their work. It’s here that we let our short term needs for the tool get in the way of the long term benefits of the working process. There’s a great interview with Jack Cheng, the writer and designer of These Days, in which he’s asked a similar sort of question. His response reminded me of this conflict between applications and methods when he replies: > True fulfilment and productivity come from applying your tools with intent. The tools can be lo-fi or hi-fi, analog or digital, but the intent stems first and foremost from a mastery over self. Your tools will not save you. There’s an even bigger risk though; when someone can’t tell the difference between the tool and the overarching practice. This can cause all sorts of problems, but perhaps the most infamous example of this is with the introduction of the horseless carriage in the late 19th century. Before the motorcycle and the automobile were given their respective names, the horseless carriage was used to describe every sort of vehicle available. It described everything from the small to the very large, from the heavy to the very light. Hundreds of years with the horse as the primary mode of transportation had confused people, and rightly so. Over time the meaning of the word ‘horse’ had become synonymous with the word ‘transport’ to such an extent that anything that hauled people about without a horse was, as ridiculous as it might sound, still horse-like. This term manages to capture how much people had mistaken the tool for the process. However, sometimes those items that we use everyday can be designed to teach us more about their inner workings and why they perform a certain function in a particular way. Last month I was obsessed with Inuit.css, an object oriented CSS framework that sets out to give front-end developers a set of rules which they can then use to scale a design system across a large web project. Essentially it’s a Lego like, ready-made sandbox for teams to work as efficiently as possible. Within this system they’re forced to break down every layout component into a series of objects. As a developer that constantly gets dazzled with large Sass files and partials hidden all over the place, it was a breath of fresh air to see this sort of stylesheet control panel, dotted with neatly labeled switches and toggles for elegantly controlling the system. The tool was dazzling. On the surface of it though, this system is not much more than a framework, although a brilliantly designed one for sure. Once you tear it apart and begin messing with all of its constituent parts however, you find so much more than what you might expect. The documentation points you to every corner of the web and to the finest minds in the field. With the numerous inline comments it delivers all of the theory behind the BEM and OOCSS methodologies. So it’s at this point where I found the tool to be separated from the process of its construction. In excruciating detail it documents not only how, but also why it was made. This simple tool for developers became a microscope through which it’s possible to analyse a process which has gone mostly unchanged for years. --- I often wonder how products, whether physical or digital, can act as more than just tools in the long term. I wonder if they can spread out somehow, becoming useful in the instant that you’re using them and yet simultaneously describe the theories behind their assembly. Either way, questions about process always lead to more fulfilling answers. They’re more journalistic in nature and, just like we would expect of a great reporter, we want to understand why things happened as much as we want to learn about what has happened. These sorts of questions shed light on why this tool or that particular feature is of use at a given moment in time and why perhaps in the future it might cease to be of use. But process related questions also make us more adaptable to these sorts of problems too. A tool won’t save us, but the process just might.

This week I came across an interesting design problem: how do you make an SVG (Scalable vector graphics) that’s being used as a background-image respond to the width of its container, yet also scale its height depending on the child elements within? For example this could be a strange shape that might be difficult or impossible to emulate with CSS and appears behind content that fluctuates; buttons, long columns of text or titles that break onto multiple lines. We want that background image to stretch horizontally to the width of the viewport but also stretch vertically depending on the content that will likely change inside. But if you simply attach an SVG (Scalable vector graphics) background image to an element and remove its dimensions within the file then the image will scale its height and width proportionately – this likely means that the edges of the image will be cut off from view but also means that any extra content we might want to add in the future simply won’t fit. The fix is easy enough though; open up the SVG (Scalable vector graphics) in a text editor and add preserveAspectRatio="none" to the SVG (Scalable vector graphics) element itself whilst also making sure to remove all width and height parameters that might have been automatically set by an app such as Illustrator. I’ve hooked up a quick example of this on Codepen, and it seems to work relatively well across various browsers. Remember though that this is obviously only suitable for browsers that support SVG (Scalable vector graphics), but with Modernizr we can test for this and give them appropriate fallbacks. But what about serving these SVG (Scalable vector graphics)s only to browsers that can support them? Well…that’s another issue altogether.

She spent her days ordering circles, squares and rectangles of color on a page. In her dreams however, in that alternate universe where she might become anything else at a moment’s notice, she believed that similar operations could be performed on breathing, heart-beating patients. Within those dreams she often believed that noses and cheeks and eyebrows could be broken down into a series of geometric constructions. From behind the surgeon’s mask she could see how these features were nothing more than nodes that have explicit relationships with other nodes; like an astronomer that watches for the constellations bloom on a cloudless night, she couldn’t help but draw these things together and make strange assumptions about this network of features. This face is worth talking to, this book is worth reading, that star is worth following. If a single feature was an inch to the left, six centimetres wider, a grade or two lighter, then everything would be different. It wasn’t daydreaming however that had ruined her potential for a career in medicine. It was the blood. But at least with book design she appreciated how the pages would refuse to scream and pour thick, liquid pints of red from their innards when the construction was wrong.