Articles by
Robin Rendle

Technical writer, CEO of staring blankly at a screen full of CSS, pro-blogger

The Line of Death

Eric Lawrence has written a pretty scary post about browser security and malicious websites that hope to trick us:

When building applications that display untrusted content, security designers have a major problem— if an attacker has full control of a block of pixels, he can make those pixels look like anything he wants, including the UI of the application itself. He can then induce the user to undertake an unsafe action, and a user will be none-the-wiser.

And the problem is even worse on mobile:

Virtually all mobile operating systems suffer from the same issue– due to UI space constraints, there are no trustworthy pixels, allowing any application to spoof another application or the operating system itself

Get Started with Debugging JavaScript in Chrome DevTools

Kayce Basques wrote an excellent interactive tutorial that explores how to debug JavaScript with DevTools. Kayce looks into a number of techniques and options that I was completely unaware of and, as he notes in the beginning of the tutorial, if you’re still using console.log to find bugs in your code (like me) then this article is written just for you (also me).

Indie Microblogging: owning your short-form writing

Manton Reece has a Kickstarter for a new kind of social network and a book, both of which aim to encourage folks to write independently again:

In the earlier days of the web, we always published to our own web site. If you weren’t happy with your web host, or they went out of business, you could move your files and your domain name, and nothing would break.

Today, most writing instead goes into a small number of centralized social networking sites, where you can’t move your content, advertisements and fake news are everywhere, and if one of these sites fails, your content disappears from the internet. Too many sites have gone away and taken our posts and photos with them.

Chrome Bias (and Finding Things To Like in Firefox)

Chrome has been my default browser for many years now, but I’ve been thinking that my familiarity with just one browser has become a problem. If I tend to design for a single browser, then I’ll start to make assumptions that those features are available for everyone. Then I’m likely to miss important differences between browsers which could introduce bugs into the codebase or influence the amount of time I spend designing a feature.

I’ve started to call this problem “Chrome Bias”, and over the past week, I decided I would do something about it by switching to Firefox. This way I could figure out what’s new in one of the most popular web browsers out there. But! While I was running this little experiment of mine, I found three Firefox features that you might not know about if you suffer from extreme Chrome Bias like I do.


Experimenting with Color Fonts

Over the past couple of weeks there’s been a lot of excitement over color fonts. Adobe describes the technology like this:

OpenType-SVG is a font format in which an OpenType font has all or just some of its glyphs represented as SVG (scalable vector graphics) artwork. This allows the display of multiple colors and gradients in a single glyph. Because of these features, we also refer to OpenType-SVG fonts as “color fonts”.

Back in March, Roel Nieskens wrote about his experience building a color font and described the problem that they intend to solve:

Typography on the web is in single color: characters are either black or red, never black and red.


A Handmade SVG Bar Chart (featuring some SVG positioning gotchas)

Let's take a look at some things I learned about positioning elements within SVG that I discovered whilst making a (seemingly) simple bar chart earlier this week.

You don't have much choice but to position things in SVG. SVG is a declarative graphics format, and what are graphics but positioned drawing instructions? There are plenty of gotchas and potentially frustrating situations though, so let's get down to it.


“OpenType Variations Fonts”

Over on the Typekit Blog, Tim Brown has written about an exciting development in the world of web fonts: an improvement to the OpenType font file specification.

This might not sound all that exciting at first, but “variable fonts” allows designers and developers to embed a single font file into a webpage and then interpolate the various widths and weights we need from a single file. That means smaller files, fewer requests, and more flexibility for designers. However, this format isn’t available to use in browsers yet. Instead, it shows that there’s a dedicated effort from Google, Microsoft, Apple and Adobe moving forward:

Imagine condensing or extending glyph widths ever so slightly, to accommodate narrow and wide viewports. Imagine raising your favorite font’s x-height just a touch at small sizes. Imagine sharpening or rounding your brand typeface in ways its type designer intended, for the purposes of art direction. Imagine shortening descenders imperceptibly so that headings can be set nice and tight without letters crashing into one another. Imagine this all happening live on the web, as a natural part of responsive design.

If you’re interested in learning more, we wrote about the call for a responsive font format which explains why it’s going to be so darn helpful in the future. John Hudson also wrote a long overview of the whole story, and the spec is here.

When is the Right Time to Think about Web Performance?

Web performance is vital, but lately I’ve felt that the topic has only been brought up by front-end developers, and only becomes a point of discussion at the end of a project. Subsequently, whenever I hear about solutions to trim down large websites, I can’t help but feel that these are merely suggestions or tricks that developers and engineers should employ after the initial design process has kicked off.