Florens Verschelde

A DevTools retrospective… and also maybe gift me a laptop?

2020-08-20T00:00:00+02:00

Do you want to gift me money on Ko-fi so that I can buy a new laptop? Now is your chance!

So my laptop died a few months ago and I’ve made do with my work computer instead, but recently I’ve considered buying a new one to not depend on work equipment.

My 5 year old laptop, which won’t start up anymore; and my 1 year old son, who — to add insult to injury — ate through the charger cable.

In the past 2 years, I’ve also spent a lot of my time — including time off from my day job — to work on Firefox DevTools as a volunteer contributor. As my involvement in this project is coming to a close, I’ve been looking back and thinking: what if I got a small something out of it, beyond a bit experience, as a small thank you?

So it’s decided: I am asking you, kind reader, to consider chipping in to help me pay for a new laptop. I’m targeting something like a Macbook Air (€1200 with VAT) or the cheapest Macbook Pro (€1500), or a similar laptop with Windows or Linux. I’ve set up a Ko-fi page with a €1350 goal, and you can give anything you want, if you appreciate the work I did.

I’m not in any financial hardship. I could buy a laptop without help, but I’ll appreciate it if I can cover most or some of the cost this way. Read on if you want more context on why I’m asking for contributions.

What did I do as a contributor?

I started contributing to Firefox DevTools in Spring 2018, initially to work on small UI details and land CSS fixes for the Inspector, Console or Network Monitor. Over two years I have:

Helped dozens of volunteers, Outreachy candidates and Google Summer of Code candidates get started with the DevTools codebase (usually over Bugzilla and Slack). I’ve also led or participated in code reviews.
Fixed 106 bugs of various sizes (from a few hours to week-long efforts).
Participated in many UX discussions to provide feedback and ideas.
Led a few design projects, including an icon refresh (shipped) and a redesign of the Settings page (accepted but not implemented).

One example: if you’re using Firefox DevTools on Linux, your experience may have improved overnight thanks to this simple CSS patch that fixed a lot of issues with font sizes and icon alignments; it took just a few lines of code, but days of investigation and tests!

I’ve worked remotely with Victoria Wang, Patrick Brosset, Nicolas Chevobbe, Harald Kirschner (hire him as a product manager!), Micah Tigley, Jason Laster, David Walsh (looking for his next role too!), Yura Zenevich and many others.

I also participated in three Mozilla All Hands weeks, which were fun! (But they were also work, somewhat tiring, and it did require me to use up my job’s paid time off.¹)

On the visible side, here are some of the design-y work I’ve done. Click through to to see full-size images.

An overview of design documents I’ve worked on in my Figma “DevTools” project. It’s mostly icon work and small mock-ups to explain ideas.

A redesign of the DevTools tab icons, made to follow the 2017 Photon Design System guidelines. This was my most visible user-facing work.

I’ve worked on a redesign of the DevTools settings page, to break it up in more readable chunks. You can try out the HTML prototype (but do try it in Firefox, since it uses CSS Logical Properties not supported by Chrome and Safari at this time), and check out the repository.

Why am I asking for money?

Because I felt like it! 😁

Just to make it clear, I don’t think I’m entitled to money here. Nobody has to give me anything! (Though if I did feel entitled to actual pay for my DevTools work, at 1-2 days a week for something like 18 months straight, I wouldn’t be asking for $1.5k.)

Anyway, here’s how the story went.

I didn’t start contributing to DevTools with money in mind. I wanted to scratch some itches, and I was excited about having patches I wrote improving a UI used by hundreds of thousands. And I also wanted to help out so that we don’t end up in a Chrome monoculture for good.

But after 6-12 months of doing good work, I ended up thinking: I like the work and it seems to be useful, let’s get paid for it and do it full time!

Sadly I’m pretty bad at advocating for myself, and I never actually applied for a role. I did reach out to a few team members, but what I heard was that there was no budget for more people, beyond maybe short-term contracts (not an option for me at the time).

Then in the last year it became clear that Mozilla management didn’t see DevTools as a vital investment, and in 2020 reorgs and layoffs have strongly impacted DevTools.

So that was it. Combined with some frustrations about not being able to do or land some work on my side because I could not secure reviews or other help², I mentally called it quits.

What prompted me to ask random people for money was this tweet:

If you're worried about the future of #Firefox, #Gecko, #MDN and other projects from #Mozilla there's one way you can help: contribute.

I always hang out in our #Introduction channel, so if you feel like coding and want to help just ping me.

—@gabrielesvelto

I have some feelings about that.

We’re talking about doing free work here. If you want those projects to succeed, are worried they might not, and want to make an impact, that could mean a lot of free work. Is that work going to lead to burnout or an increased risk of burnout?

Meanwhile, this work is adding value to projects and products (especially Gecko and Firefox) that Mozilla Corporation derives money from. That money funds big compensations for the C-Suite, and salaries for engineers that surpass anything I ever earned myself³. That’s true for many other contributors too, of course, and is part of a wider criticism of open-source.

(And maybe talking about this just after the layoffs is ill-timed, but the layoffs are the reason why people are calling for a surge of contributions.)

Finally, as I replied on Twitter, if you want people to work for free you should provide some incentives, including psychological ones. For large projects like Gecko or Firefox, the technical complexity, specific processes and bureaucracy⁴ mean it’s hard to just “scratch an itch” and see results quickly. Instead, one incentive can be to ship fixes and features to tens of thousands or millions of users — an appeal that smaller projects can’t provide.

But to be able to do that and not waste your time, you will need support from the core team. So you need that team to not be fired, cut in half or otherwise scaled down. And you will need some confidence that once your efforts pane out and your work is ready to ship to users, the product will not have been discontinued (ahem, Firefox OS). And if we cannot guarantee that, because strategic decisions lie in the hands of unaccountable corporate management, should we really call for people to provide free work?

So I was thinking about all that, all those mixed feelings about open-source, and I ended up at: you know what, fuck it, I want some money too. My friends and family always tell me I’m super bad at valuing myself and asking for money, promotions or raises — so maybe I should break the circle.

I’m asking for money. A symbolic amount, really, compared to the work I did, but still an amount that I can use for something practical.

If it works out, great, and if it doesn’t… eh. 🤷‍♀️

Thanks for reading this far, do contribute if you want to, and please share this with friends (especially if they use Firefox DevTools 😇).

Mozilla shoulders all other costs of inviting volunteer to the Mozilla All Hands, including plane tickets, hotel rooms, catering, and expense stipends. I don’t have exact numbers, but the total cost for inviting a single volunteer three times is probably in the $10–15k range? ↩
For example, for the Settings page implementation, I was motivated to do a lot of the work but would have required mentorship or timely help. One developer also had ongoing work on that panel that he could share with me, but he was moved from the DevTools team to the Firefox for Android project. ↩
To be clear, I don’t have any issue with current or former Mozilla employees, especially the great people I’ve been lucky to work with. My point is that when taking a step back and looking at Mozilla or company-sponsored open-source projects in general, some people are getting compensated and others not, and maybe it should give us pause. ↩
It seems largely similar in Chromium or WebKit; it comes with the scope of the project, not with Mozilla or Google being bad at it. ↩

PHP code typing with Kirby CMS

2020-08-12T00:00:00+02:00

As I was updating this site and writing my previous post on Kirby CMS, I sometimes struggled to get good code autocompletion.

Kirby 3 is built with PHP 7 and uses type annotations extensively, but this often won’t be reflected in an IDE. This post explores why, and what workarounds you can use.

Why you might want completions

Unlike CMSes like WordPress and Drupal which come with default themes that generate HTML code for you out of the box, Kirby uses a very hands-off approach to building web pages. You can start from scratch and write your own PHP controllers and templates to render what you want, using Kirby’s PHP API.

That’s great if you want to build something bespoke. But it also means that you’re going to spend a lot of time looking at the reference documentation. Before you know it, you’re juggling between your code editor and 15 open documentation tabs.

That’s where code completion — sometimes called “intellisense” — helps. It lets you be a bit lazy and access a lot of that reference information directly in your code editor, as you type.

Ideally, when your editor sees a PHP variable like $page in a Kirby template, it should known that $page is an instance of the Kirby\Cms\Page class. And it should offer code completions and suggestions from that class. No need to check the docs!

Sadly, this doesn’t work out of the box with Kirby, in a few common situations.

Runtime magic

Kirby tries to be approchable for people who are not pro developers or PHP programmers. Its creator, Bastian Allgeier, is a designer and developer, and wants to cater to a wider audience of designers, webmasters, tinkerers, etc. So Kirby tries to do some magic things like:

Load templates (and controllers, if any) by file name. Follow the convention, and your code will run[^2].
Automatically inject variables in your templates and in your controllers.

This means that the template for a page of type 'article' can be named site/templates/article.php and be as simple as:

<h1><?= $page->title() ?></h1>
<?= $page->text() ?>

The downside of this approach is that your code editor has no information about this $page variable. It cannot know if it’s a string, a number, or an object (and what kind of object). Your editor might even warn you that this variable was never defined, and highlight it as an error!

Kirby controllers use a different kind of magic. Controllers are defined as functions returned by a script, such as site/controllers/article.php:

<?php
return function ($page, $site) {
  // Inject two new variables, $content and $articles,
  // in the 'article' template
  return [
    'content' => $page->text()->markdown(),
    'articles' => $site->find('blog')->children()
  ];
}

See the $page and $site parameters in the function? Kirby will look at the function’s parameter names and automatically provide an instance of the current page for a parameter named $page, of the Site object for a parameter named $site, etc.

This lets us ask for a few built-in objects in any order we want, for example:

return function ($site, $kirby, $page) { … }

But again, the downside is that this is magic happening deep inside Kirby’s own code, and your IDE will have no idea what those variables are. No code completion for you!

Adding type hints and annotations

I’ve found a couple solution to this problem.

For controllers, since we’re using function parameters to “request” specific objects, we can add type declarations using PHP’s syntax:

<?php // site/controllers/article.php
use Kirby\Cms\App;
use Kirby\Cms\Page;
use Kirby\Cms\Site;

return function (Site $site, App $kirby, Page $page) {
  …
}

Note that for backward compatibility with Kirby 2, Kirby 3 provides shorter class aliases, including Kirby (for Kirby\Cms\App), Page and Site. Personally, I like using the longer, more explicit class names.

Now, let’s talk about templates. Templates will receive variables defined by Kirby (like the $page and $kirby objects), and any other variable you return in a controller.

Sadly there is no way in PHP to declare “hey I know that this $page variable exists in this context, and I’m going to tell you what it is”. Unlike in TypeScript where you could write something like:

declare var page: Page;

The good news is, there is a widely supported way to declare variable types in PHP, using the PHPDoc @var tag:

<?php // site/templates/article.php

/** @var Kirby\Cms\Page $page */

<h1><?= $page->title() ?></h1>
<?= $page->text() ?>

PHPDoc comments are not a native PHP feature, so declaring a type this way won’t affect how your code runs at all. But most code editors and IDEs with good PHP support will understand this special comment syntax, and will read it as “there is a variable $page in the current scope, and it’s an instance of the Kirby\Cms\Page class”.

And if you have created a Page Model for this template, you can declare the type using the page model’s class name, for example:

<?php // site/models/article.php

class ArticlePage extends Kirby\Cms\Page {
  public function getArticleBody(): string {
    if ($this->content()->body()->isNotEmpty()) {
      return $this->content()->body()->markdown();
    }
    return '';
  }
}

<?php // site/templates/article.php

/** @var ArticlePage $page */

<h1><?= $page->title() ?></h1>
<?= $page->getArticleBody() ?>

Making sure your editor has good PHP support

Finally, if you want to see code completions in your editor or IDE of choice, type annotations may not be enough. You also need an editor or IDE with good PHP support!

Personally, I use PhpStorm when writing more than a couple lines of PHP, because it just works. The downside is that it’s paid software, and not cheap.

I’ve also tried using Visual Studio Code with the PHP Intelephense extension. It works well, but do follow the “Quick Start” steps in the extension’s page.

There are a few other options, such as NetBeans, but I haven’t tried them out.

Where should you put logic code in Kirby CMS?

2020-06-01T12:00:00+02:00

This blog has been running on Kirby CMS for 6 years. And I’ve been migrating it from Kirby 2 to Kirby 3, which is taking a bit of work.

I like to do a bunch of custom things with my site’s structure and content, so instead of relying on “the Kirby way” I’m implementing a bunch of stuff myself.

That means writing PHP code that queries and manipulates data — often called “logic” code by programmers — and I’ve struggled a bit with understanding where I can put this code in the project.

Logic in templates? Sure.

One thing I like about Kirby is that it’s powerful and doesn’t require you to jump through hooks. So if you want to put all your logic in a template file, you can!

In the following example, we’re querying all the child pages of the current page, keeping the “Published” ones and sorting them by date, then listing the latest 20 pages.

<?php // site/templates/blog.php
$posts = $page->children()
  ->filterBy('isPublished', true)
  ->orderBy('date', 'desc')
  ->limit(20);
?>

<h1><?= $page->title() ?></h1>
<ul>
<?php foreach($posts as $item): ?>
  <li><?= $item->title() ?></li>
<?php endforeach; ?>
</ul>

(This template would be used for any page which has the 'blog' content type, meaning its content file is something like content/my-page/blog.txt. See “Creating pages” in the Kirby documentation for more information.)

Or in controllers, maybe?

Putting logic in template is great for people just getting started with Kirby, or people who may not be professional programmers. But if you want to separate your logic from the template, you can move it to a controller function:

<?php // site/controllers/blog.php

return function ($page) {
  $posts = $page->children()
    ->filterBy('isPublished', true)
    ->orderBy('date', 'desc')
    ->limit(20);
  return ['posts' => $posts];
};

But what if you want to share some logic between different templates, controllers or page types? It would be awesome if you could call something like $page->getPublishedChildren(), from anywhere.

Kirby offers two ways to do that:

Creating a page method

Page methods apply to all $page objects, regardless of page type. They’re a slightly older technique in Kirby, and in Kirby 3 you need to declare a plugin to add page methods:

<?php // site/plugins/my-plugin/index.php

Kirby::plugin('me/my-plugin', [
  'pageMethods' => [
    'getPublishedChildren' => function() {
      return $this->children()
        ->filterBy('isPublished', true)
        ->orderBy('date', 'desc')
        ->limit(20);
    }
  ]
]);

There are a few downsides to page methods:

Having to register a plugin is a bit awkward.
If you’re using PHP types and intellisense in your editor, your editor has no way to know that $this in your page method is an instance of Kirby’s Page class. That means you don’t get code completions and validation in your editor.

Creating a page model

The newer option is to use page models, which are defined as PHP classes extending Kirby’s Page class.

<?php // site/models/blog.php

class BlogPage extends Page {
  public function getPublishedChildren() {
    return $this->children()
      ->filterBy('isPublished', true)
      ->orderBy('date', 'desc')
      ->limit(20);
  }
}

This looks a little bit cleaner to me, mainly because we avoid creating a plugin. And since we’re extending the Page class, now our code editors will know what methods the $this object has¹.

And reading the Kirby documentation, and especially the Guide, it looks like Page Models are the preferred mechanism for adding functionality to page objects.

But they have one big downside: they only apply to a given page type, the 'blog' page type in this example. If you try to use $page->getPublishedChildren() on a page with a different type, you get an error.

Are we forced to use Page Methods in a plugin to share functionality between pages? Well, maybe not.

Creating a default page model

Our page models already inherit from Kirby’s Page class. What if we added one more class to that hierarchy?

Let’s start by moving our method to a new class, which we’ll call DefaultPage. Ideally we should pick a name that doesn’t match a page type (meaning we don’t have pages with a content file named default.txt).

<?php // site/models/default.php

class DefaultPage extends Page {
  public function getPublishedChildren() {
    /* ... */
  }
}

Then we can create a class for our 'blog' page type, which extends DefaultPage:

<?php // site/models/blog.php
require_once 'default.php';

class BlogPage extends DefaultPage {
  // Add methods specific to the 'blog' type
}

Note that we have to require default.php explicitly to load the DefaultPage class, because Kirby won’t load it automatically since it doesn’t match a real page type.

If we add a new page type, we can create an empty page model that inherits from DefaultPage, and it will inherit the same shared methods.

<?php // site/models/article.php
require_once 'default.php';

class ArticlePage extends DefaultPage {}

Fair warning: this means that to fully emulate a global “page method”, we have to create a page model for every single page type we have!

If that’s too verbose, your options are:

Going back to using the page method technique;
Upvoting this feature request.

Happy coding!

At least if we’re using a code editor with good support for PHP, like PhpStorm; in my experience VS Code was too limited out of the box, and I couldn’t figure out which plugins to try to improve that. ↩

A short history of body copy sizes on the Web

2020-01-01T00:00:00+01:00

It’s hard to pick a font size that is just right, especially as you try to adapt to different screens and scenarios. Looking at the recent history of how we got here can give us some perspective.

When I started working on Web stuff around 2005, there were two extremely popular font styles for body copy:

10px Verdana;
11px Arial.

Those two styles appeared on maybe 90 percent of professionally built sites, to be seen by users on IE5, IE5.5 and IE6 on Windows XP and earlier versions. They also looked similar, thanks to heavy font hinting, lack of font smoothing or sub-pixel rendering, and the fact that Verdana has a bigger x-height so 10px Verdana was roughly equal to 11px Arial, only with slightly wider letters.

Ten and 11 pixels may seem puny today, but in the early 2000s that was deemed readable for two reasons:

the 800×600 and 1024×768 screens of the late 1990s and early 2000s had biggish pixels, so the result was on the small side but not as small as it might look today;
designers and their clients were accustomed to 9, 10 and 11 point sizes for body copy in print (books, magazines, leaflets…), and the prospect of using bigger values felt like shouting at readers.

With relatively little experience of the Web as an autonomous medium, graphic designers and marketing departments relied on previous knowledge — from e.g. QuarkXPress and Microsoft Word. “How do I translate this point size, which works in my leaflet or magazine ad, to a HTML size?”

Of course, there is no way to reliably translate typographic points to pixels, because pixels don’t have a universal physical size. Screens have different pixel-per-inch ratios. The original Macintosh had a 72ppi screen (or perhaps 68ppi?¹). Twenty years later, in 2004, screens in the 80–90ppi range were common. A few years laters, pixels had gotten a bit smaller, and screens were often in the 90–120ppi range, while most iPhones had a 160ppi resolution². Despite the popular misconception, and even before the Retina transition started, the Web’s resolution was not 72ppi; it never was a single thing.

However, we don’t need to work out the exact points-per-inch resolution of every device to make sensible design choices. Trying things out should always trump dpi, ppi, Retina, or even pixel counts.

In November 2006, iA’s Oliver Reichenstein ran a simple experiment: he compared a magazine’s body copy at arms’ length and a typical site’s body copy at a common, eye-to-desktop-screen distance. The website’s text looked much smaller. Oliver argued for setting the body copy to the browser’s default, or 100%, which by convention is 16px in common browsers. In 2006, and even a few years later, it was a revolutionary proposition. Web designers and clients thought it was extreme. Five years later, we still had to fight for the death of 11px body copy (example, in French).

Text that is too small takes more time to read. Users may have to lean towards the screen, hold mobile devices closer, squint, or just concentrate more. As designers and developers, we strive to not ask for such extra effort from people who use or read our work.

On average, online text got bigger — at least in nominal pixel sizes — in the late 2000s and early 2010s. The exact reasons why are anyone’s guess, so here’s mine:

the medium’s matured, thanks to arguments such as the one spelled out by Oliver Reichenstein;
text in the 10–12px range looked tiny on the iPhone and other early smartphones (resolutions in the 150–200ppi range).

I remember web designers and developers leading the way with blogs, professional news sites and the occasional client project set in “bigger” sizes in the 14–18px range. This evolution seeped into generalist news sites, one high-profile redesign after the other; nowadays, theguardian.com has 1.0625rem (17px) text with 1.5 line-height, nytimes.com used 17px font-size and 26px line-height circa 2017, and in 2019 it went up to 20px font-size and 30px line-height on wide screens; body copy in the 18–21 pixel range is common (Medium, bostonglobe.com, newyorker.com, liberation.fr…).

Those numbers only mark a point in time. Back in 2003, 12px Arial might have been a generously big, very readable option for that majority of users on 800×600 screens with font smoothing turned off. The feeling that the browser’s default font-size was too big, which was very present when Oliver’s article was published in 2006, was partly a cultural thing, but it had some technical reasons as well. Likewise, we’ve started to feel that 16px is rather small for all but the smaller screens, again for a combination of reasons.

Then there is the very big body copy trend. In April 2012, influential web designer Jeffrey Zeldman redesigned his site with 24px Georgia body copy (and 32px for the opening paragraph of each post). Many fellow designers were puzzled, and some complained that the design was hard to read or reported having to zoom out on laptops or desktop computers to be able to read comfortably. Still, that design lasts today. Other designers have used similar sizes, e.g. Trent Walton stated his preference for 20–24px text (or 125–150%).

The most recent example of that trend is Jeremy Keith’s Resilient Web Design online book. Jeremy uses a CSS lock³ to vary the font size depending on viewport width, between two boundaries: 100% and 250%. At 320px, you get (with default browser settings) a 16px font size. At 1600px, you get 40px text. Obviously this is a design choice, and I recon that — similar to what Trent Walton described — the intended effect for laptop and desktop use is that readers lean back and read with their faces away from the screen rather than leaning towards it. It’s a design that invites taking your time instead of skimming through the text.

While that design makes for a good reading experience on smaller screens (especially smartphones and tablets, in my tests), I find it difficult on larger screens. The main issues I have with it are:

Seeing very few lines of text at a time. For instance, 10 lines of text on a 13 inch laptop. I have some level of attention deficiency when reading, and this setup removes a lot of visual context when I try to scroll and read; I generally try to fight the attention deficiency by selecting every other paragraph I’m reading, but when the design only shows one or two paragraphs at a time, that doesn’t help.
Each line of text is physically wide, requiring the reader’s eyes to span a wider angle than usual. This could have two undesired effects: readers might end up doing more fixations to read the same line of text (e.g. 3–5 instead of 2–4); and in more extreme examples, the wider eye movements could cause eye strain or fatigue.

Let’s say someone is seating in a sofa with a laptop on their lap, and currently reading an article. And let’s suppose that for this person in this setting with their own preferences and current level of fatigue etc., there exists an ideal font size for reading whatever text they’re reading. For instance, it could be 22px.

The reading process involves saccades and fixations. On each fixation (which can span a quarter of a second), they are only seeing a small portion of text in focus:

Look, I’m no scientist, so I’m hoping that’s actually representative of the real thing but take it with a spoonful of salt okay?

Now if the same text was quite bigger, but the other parameters (like the eye–screen distance) didn’t change, I’m guessing the result would look like this:

With the focus area staying the same size, and bigger text, I suspect that the eye can discern fewer letters correctly on each fixation. This is why my hypothesis is that for really big text (like Resilient Web Design’s 250% body copy on wider screens), readers will need to use more eye fixations to read the same text, and might lose in reading speed and experience fatigue sooner. I don’t have the skills needed to test this hypothesis, but I’d be wary of the very big text trend.

Personally, I favor more limited tweaks in font size. I like starting with a 100% basis for small screens, bump it for large phones or tablets (say, 110% or 115%), and maybe go up to 125% on laptops and larger screens. Then I tweak those values depending on the font I’m using, the look I’m going for, and what I’ve seen in testing on a variety of devices.

I’m also sad that we’re somehow chasing after device makers, operating system and browser developers, and trying to tweak font sizes every other year to adapt to what is out there in the market. The very concept of raising font size a bit depending on the screen width should raise eyebrows. Isn’t it the device’s job to make sure that font-size: 100% is readable?

In theory, CSS pixels should match a “reference pixel” defined as an angle of vision:

The reference pixel is the visual angle of one pixel on a device with a pixel density of 96dpi and a distance from the reader of an arm’s length. For a nominal arm’s length of 28 inches, the visual angle is therefore about 0.0213 degrees. For reading at arm’s length, 1px thus corresponds to about 0.26 mm (1/96 inch).

But this rule can only be followed if hardware makers, operating system and browser developers all collaborate towards that goal, which is rare enough. Especially since hardware vendors are more interested in selling screens optimized for video resolutions (“1080p”, “4K”), even when it makes the whole UI awkwardly small.

In theory again, browser makers should be able to change the 16px default font size to adapt to modern devices. But too much existing content relies on this default size not ever changing.

And so, we guess; we test; we tweak.

Whether technically correct or an approximation (my own calculations show a resolution of 68dpi), the “72dpi” resolution allowed designers to easily transpose point sizes to pixel sizes. Since there are 72 typographic points in an inch, at 72dpi each pixel is exactly one point. ↩
Retina displays didn’t change the “system point per inch” resolution, instead each system point was mapped to a 2×2 square of physical pixels. Since the CSS px unit works similarly as system points on those devices, and doubling the physical pixel resolution did not impact the size of HTML text, I skipped talking about resolutions measured in physical pixels (e.g. 320ppi) altogether. ↩
A Responsive Web Design technique that lets you transition smoothly between two property values when the screen gets smaller or bigger technique. First implemented in CSS by Mike Riethmuller, and developed further by Tim Brown. See The math of CSS locks for details. ↩

Et tu cliques cliques cliques, à côté du bouton ♫

2019-12-24T00:00:00+01:00

Que ce soit à la souris ou sur un écran tactile, un pourcentage de nos clics tombera à côté de la cible, voire sur le bouton voisin. C’est un peu frustrant, mais n’est-ce pas une fatalité ? Regardons ça de plus près.

Par exemple, vous avez forcément croisé la fameuse pop-up d’inscription à une indispensable newsletter :

Bien planquée dans le coin supérieur droit, une petite croix : le bouton de fermeture. Alors on se dépêche, vite on clique, et rien. Quoi ? Zoomons un peu pour voir ce qu’il se passe.

Dans sa grande bonté, le/la designer a dessiné une icone de 8 pixels de côté. Puis, lors du développement, l’intégrateur ou la développeuse ne s’est pas posé de question et a utilisé une image de 8 pixels de côté également, sans réserver un espace cliquable plus grand.

Et maintenant, troisième étape de notre histoire, l’utilisateur·trice clique à côté. Alors on réessaye, parce qu’on n’a toujours pas l’intention de s’inscrire à cette newsletter. En se méfiant, après ce premier échec et un début de frustration.

À la souris, il faut ralentir considérablement et amener le pointeur bien au dessus de l’icone, et surveiller si la flèche se transforme en main ou si un autre changement visuel signale que là, c’est bon, on peut y aller. Ensuite, on clique, mais attention : le mouvement ou la vibration du clic peuvent déplacer le pointeur de quelques pixels.
Sur un écran tactile, on prendra son doigt le plus fin et approchera l’écran presque orthogonalement pour essayer de « cliquer » le plus précisément possible. Il est rare qu’un effet visuel vienne indiquer clairement quelle partie de la pulpe du doigt a réellement touché l’écran, et s’il y en avait un il serait de toute façon masqué par notre doigt. Alors il faudra peut-être trois, cinq ou 10 essais pour fermer cette satané pop-up.

Et ça, c’est dans dans des conditions favorables : sans handicap, sans tendinite, et sans tenter d’utiliser un site important en marchant dans la rue avec un smartphone à la main.

Alors que tout ça aurait pu être beaucoup plus simple avec un bouton adapté :

Pourquoi c’est pas facile de cliquer un petit bouton ?

Et par opposition, pourquoi agrandir la zone cliquable d’un bouton faciliterait la vie des utilisateurs·trices ?

C’est le moment « pour marcher il faut mettre un pied d’vant l’autre » de cet article, mais restez avec moi, ça va bien se passer.

Première raison : pour utiliser un bouton, un lien ou tout élément interactif d’une interface, il faut déjà le trouver. Intuitivement, on comprend qu’un élément trop petit sera difficile à identifier dans une interface car peu visible.

Vous connaissez l’expression « chercher une aiguille dans une botte de foin » ? À votre avis, si une botte de foin contient une aiguille, un parapluie et un lampadaire IKEA de 2 mètres, lequel de ces objets sera le plus simple à trouver en premier ? Et en deuxième ?

Bien sûr la taille n’est pas le seul critère, d’autres rentrent en ligne de compte :

La forme. Une forme conventionnelle sera identifiée plus vite et plus souvent. Par exemple : le manche recourbé d’un parapluie cane, le texte souligné d’un lien, l’aspect surélevé d’un bouton-poussoir.
L’emplacement. La position dans la page (à un endroit attendu ou moins conventionnel), et la position par rapport à d’autres éléments (voir la loi de proximité dans la Psychologie de la forme).
Le contraste des éléments graphiques entre eux et avec leur environnement (Understanding Success Criterion 1.4.11: Non-text Contrast).

Ces critères participent à ce que le psychologue James J. Gibson a nommé l’affordance d’un objet, sujet très large et passionnant, mais que je vous propose de laisser de côté pour revenir à nos boutons.

Mettons que vous ayez aperçu et identifié le bouton de fermeture de cette satanée pop-up. Deuxième étape : il faut maintenant l’activer. Pour ça, il faut l’atteindre, et ça c’est un vrai petit voyage :

Avec une souris ou un pavé tactile, il faut déplacer le pointeur entre sa position actuelle et la position de la cible.
Sur un écran tactile, de smartphone par exemple, il faut déplacer un doigt vers la cible sans toucher l’écran, par exemple déplacer un pouce de sa position de repos vers le bouton.

Dans les deux cas, c’est un mouvement qui comprend une phase d’accélération et une phase de décélération. Et parfois, on s’arrête trop vite ou trop tard, un peu comme en voiture ou à vélo.

En ergonomie des interfaces humain-machine (IHM), on retrouve cette problématique dans la loi de Fitts. Dans les années 1950, en étudiant entre autres les cockpits d’avion de l’armée américaine, Paul Fitts estime que le temps moyen nécessaire pour atteindre physiquement une cible (par exemple un bouton ou un levier) dépend de deux paramètres : 1. la distance de la cible et 2. la taille de la cible.

(Pour plus de détail, on pourra lire cette explication très intéressante en anglais de la formule proposée par Fitts et son application aux interfaces informatiques.)

En gros, les cibles éloignées et les petites cibles demandent plus de temps. Les petites cibles éloignées étant les plus exigeantes.

Cela s’explique en partie par un phénomène connu dans l’expérience humaine et en sciences cognitives : le compromis entre la vitesse d’exécution et la précision (The speed-accuracy tradeoff: history, physiology, methodology, and behavior). Par exemple, si je veux appuyer rapidement sur un bouton sur un écran tactile, je ne vais pas prendre le temps de regarder le mouvement de mon doigt pour obtenir une information qui me permet de corriger ou optimiser mon mouvement : je risque donc de perdre en précision.

En tant que designers et développeurs·euses d’interfaces, nous pouvons faire deux suppositions :

Nos utilisateurs et utilisatrices seront souvent pressées ou distraites, et ne manipuleront pas nos interfaces délicatement et patiemment comme s’il s’agissait de fragiles nouveaux-nés.
En cas d’« erreur » de manipulation, par exemple un clic enregistré à côté d’un bouton voire sur le bouton voisin, nos utilisateurs et utilisatrices ne comprendront pas les raisons techniques et ergonomiques précises de l’erreur, et pourront percevoir l’interface comme buguée (ça m’a emmené ailleurs que prévu, j’ai dû cliquer plusieurs fois pour que ça marche, etc.), lente (j’ai dû cliquer plusieurs fois avant que ça ne finisse par réagir, ça « lague »), et plus généralement comme frustrante voire hostile.

En conséquence, notre boulot est de réduire autant que possible le nombre d’erreurs, et pour ça la loi de Fitts nous apprend que nous pouvons jouer sur la distance et sur la taille des éléments interactifs.

Petit problème : pour la distance, c’est compliqué. Elle est rarement fixe et prévisible, nous ne connaissons pas l’état du défilement de la page, la position de départ du curseur, etc. Sur smartphone, il existe des usages courants comme l’utilisation du pouce et une position de repos vers le bas de l’écran, mais même certaines distances courtes peuvent être difficiles d’accès (car il faut tordre la main ou le poignet). Donc pragmatiquement, on peut considérer qu’on a toujours une chance importante de se retrouver dans un cas difficile.

Il nous reste donc une variable majeure pour faciliter la vie des utilisatrices et utilisateurs : agrandissons-donc ces fichus boutons !

Okay mais tout le monde sait ça hein, c’est la base !

Malheureusement cette question n’est pas si connue que ça, car nous tombons tous et toutes quotidiennement sur des interfaces qui ne respectent pas ce principe. Et pas seulement sur des sites perso ou amateurs. Voici quelques exemples.

Sur Inc. (publication de Mansueto Ventures qui publie également le magazine Fast Company), les boutons de l’en-tête ont une taille cliquable minuscule (deuxième ligne, en vert). Ma proposition de correction (troisième ligne, en rose) utilise une taille minimum de 36 × 36 pixels. Idéalement il faudrait prévoir plus grand encore, et pour cela mieux répartir les boutons entre la gauche et la droite.

Mais peut-être que du côté de la presse en ligne on ne sait pas coder, alors que chez les vrais développeurs si, on sait ? Faut voir, parce que chez GitHub ce n’est pas ça non plus :

Les boutons de l’en-tête se limitent à la surface de l’icone, et cliquer à côté est excessivement aisé. La hauteur du champ de recherche pourrait être augmentée, et principaux liens du menu sont plutôt corrects sauf le lien “Marketplace” au milieu de la liste. Enfin, le texte des liens ou l’icone de profil touche le bord gauche du bouton, ce qui reste risqué : un peu de padding ne ferait pas de mal.

Peut-être que ça se passe mieux dans les entreprises spécialisées en design ? Hmm, pas toujours. On ne va pas prendre d’exemple sur le site d’Adobe, ce serait cruel. Mais si on regarde du côté d’Invision, il y a du bon et du moins bon :

Chez Invision, lorsqu’un bouton est visuellement grand, sa zone cliquable est grande également (logique…). Par contre dans l’en-tête, la plupart des liens se limitent à la surface du texte. Mention spéciale pour le petit triangle à côté de “Design Community” : il suffit de cliquer un pixel plus à droite pour cliquer dans le vide.

Un autre problème courant, qu’on peut voir dans les colonnes du pied de page, c’est l’utilisation de line-height pour espacer les éléments d’un menu. Un line-height important donne une bonne hauteur cliquable, mais dès que le texte passe sur deux ligne c’est la catastrophe. À votre avis, dans les cinq lignes de texte suivantes, combien y a-t-il de liens ?

Invision For

Startups

Pricing

Students &

Teachers

Mon conseil : combinez un line-height raisonnable (par exemple line-height: 1.5) et du padding pour obtenir une hauteur de bouton correcte, et testez avec du texte sur plusieurs lignes. Et si ça « casse » le design, parlez-en aux designers !

Autre écueil : attention à ne pas suggérer visuellement une surface cliquable, avec des couleurs de fond, des bordures, des décorations visuelles ou des effets au survol… tout en implémentant une zone cliquable plus petite. Vous invitez vos utilisateurs·trices à cliquer dans le vide !

Sur la page d’accueil de Google Design, les catégories principales montrent une bordure au survol, qui suggère une zone cliquable très large. Malheureusement, ce n’est pas le cas, et les liens ont une surface beaucoup plus réduite.

Les tailles de bouton recommandées pour les interfaces tactiles

Une taille de bouton suffisante, c’est quoi au juste ? Ça va dépendre en partie du public (certaines interfaces « expertes » ont une forte densité d’information et des contrôles plus petits que la moyenne), mais aussi du support.

Sur mobile, on peut suivre les recommandations d’Apple pour iOS et de Google pour Android, qui sont assez proches.

Les Human Interface Guidelines d’iOS recommandent une zone réactive de 44 pixels de côté minimum, et déconseillent les boutons trop rapprochés. Source : General Layout Considerations, © Apple.

Les recommandations Material Foundation de Google spécifient des zones réactives de 48 pixels de côté minimum, avec au moins 8 pixels entre les boutons. Source : Material Design: Spacing methods, © Google.

Un exemple intéressant dans cette dernière illustration : en (3), le bouton utilise un style standard de Material Design avec une hauteur de 36 pixels. Mais la zone tactile doit toujours faire au moins 48 pixels de haut, alors que faire ?

Sur certaines plateformes, on peut rendre la zone tactile d’un élément plus grande que l’élément lui-même. Par exemple, avec React Native on pourra utiliser la propriété hitSlop de certains composants.

<Button hitSlop={{ top: 6, bottom: 6, left: 0, right: 0 }}></Button>

Sur le Web, c’est plus compliqué. Deux solutions :

Utiliser un élément <a> ou <button> transparent avec du padding, et placer un <span> stylé comme un bouton à l’intérieur.
Utiliser un pseudo-élément positionné en absolu pour élargir la zone cliquable.

.my-button {
  position: relative;
}

.my-button::after {
  content: "";
  position: absolute;
  top: -6px;
  bottom: -6px;
  left: 0;
  right: 0;
}

Apparté sur les unités de mesure : iOS utilise des « points système », notés pt ; Android des “device points” notés dp ; et sur le Web on travaille en « pixels CSS », notés px. Ces trois unités sont équivalentes dans la plupart des cas, et peuvent correspondre à des quantités variables de pixels physiques (suivant la densité de l’écran et la configuration du système d’exploitation).

Les tailles de bouton pour les interfaces à la souris

Sur des interfaces qui ont été conçues principalement pour la souris, les boutons sont généralement plus petits. Par exemple sur macOS, les boutons des barres d’outils font 22 pixels de haut, et les Human Interface Guidelines pour macOS ne recommandent pas de taille minimum.

Material Design ~~recommande~~ recommandait encore récemment une taille minimum de 24 pixels pour les boutons dans les interfaces à la souris. On notera que dans ces deux exemples on pourrait facilement agrandir les zones cliquables sans modifier le design visuel. Source : Material Design: Spacing methods, © Google.

Personnellement, je trouve la recommandation de Material Design un peu faible, et préfère utiliser des zones cliquables de 30, 40 pixels ou plus. De plus, il devient compliqué de savoir si une interface sera utilisée à la souris, sur un écran tactile (en particulier avec les grandes tablettes et les ordinateurs portables tactiles), pour ne parler que des cas les plus courants ! Donc la pertinence de recommandations pour les interfaces à la souris est, à mon sens, de plus en plus contestable.

Mise à jour : les designers de Google semblent d’accord, et viennent de mettre à jour la documentation de Material Design pile au moment où nous publions cet article ! La nouvelle recommandation, à la page « Accessibilité », suggère des zones cliquables de 44 pixels de côté minimum pour les interfaces à la souris ou au stylet.

Même à la souris et sans handicap ou difficulté motrice, une cible de 24 pixels peut être difficile à atteindre, par exemple si on est un peu pressé.

Pour l’illustrer, voici un petit jeu de précision. Le but de ce jeu est de cliquer une vingtaine de cibles carrées de 24 pixels, toutes affichées exactement une seconde. Sachant que le temps de réaction humain moyen est de 250 millisecondes, cela laisse 750 millisecondes pour déplacer le pointeur et cliquer.

Je vous propose une première partie en gardant les paramètres par défaut, et on se retrouve juste après. Prêt·e ?

Alors, comment ça s’est passé ? Si vous avez obtenu un score de moins de 90, comment pouvez-vous l’améliorer (donc diminuer le taux d’erreurs) ? Vous avez trois leviers :

Augmenter la taille de la cible. Ne serait-ce qu’en montant à 32 pixels, la différence devrait être sensible.
Diminuer la taille du conteneur, et donc les distances à parcourir.
Augmenter le temps de jeu, pour être moins pressé·e.

N’hésitez pas à faire quelques essais. Et si jamais vous en tiriez quelques enseignements pour les interfaces que vous designez ou développez, ce serait bien sûr parfaitement fortuit. Bonnes parties, et joyeux Noël !

P.S. : le code du jeu est open-source et on peut le retrouver sur cette page.

Interview sur Alsacréations

2019-12-03T00:00:00+01:00

J’ai donné une petite interview pour le site alsacreations.com, un site communautaire autour des technologies web créé par Raphaël Goetter et Rodolphe Rimelé et auquel j’ai beaucoup participé il y a une dizaine d’années.

Il y a deux questions qui m’ont particulièrement intéressé, et je me permets de recopier mes réponses ici pour mémoire.

Alsacréations: Comment envisages-tu le futur de CSS ou de l’intégration en général ? (on pense notamment à CSS-in-JS)

Pour les CSS dans le JavaScript, c’est plus un symptôme de ce qu’il se passe depuis quelques années. Je n’ai rien contre ces outils, moi ça ne me gêne pas d’utiliser styled-components ou CSS Blocks, pas plus que Sass ou d’autres. Mais ça fait partie d’une tendance générale à empiler des couches techniques les unes par dessus les autres, qui correspond mieux aux schémas mentaux des développeurs·euses «classiques» que des intégrateurs·trices.

On se retrouve avec des projets où pour participer sur les styles ou l’accessibilité il faut pouvoir utiliser Git mais aussi Docker, maitriser JavaScript et React, configurer webpack, et écrire les styles dans une syntaxe JavaScript ou en pseudo-CSS. C’est quand même beaucoup d’obstacles pour des gens qui connaissent peu ces outils mais ont une expertise sur le HTML et l’accessibilité, le CSS, les navigateurs web, etc. Je parle régulièrement avec des gens qui faisaient de l’intégration web principalement ou en plus d’autres missions, et qui se sont rabattus sur du design ou de la gestion de projet car l’environnement technique devenait trop «pour et par les devs».

Je ne sais pas comment ça va évoluer, mais en tout cas je m’intéresse à tout ce qui tire un peu dans le sens inverse : permettre à des designers et/ou intégrateurs·trices de produire des choses sans être bloqué par plein de couches techniques. Peut-être une simplification des frameworks JS pour que le JS s’efface autant que possible, comme dans Svelte ? Est-ce qu’il faut forcément coder, ou bien est-ce que la manipulation directe comme dans Webflow ne fonctionnerait pas mieux au final ? Est-ce qu’on peut mélanger code et manipulation directe, pour bosser ensemble avec plusieurs profils ?

Alsacréations: Si tu avais à former un·e débutant·e en HTML et CSS, sur quels thèmes insisterais-tu particulièrement ?

Pour moi le plus important serait de rattacher HTML et CSS à un objectif plus large. Quand j’ai fait de la formation il y a 10 ans, j’avais une approche très linéaire, HTML et sémantique d’abord puis CSS ensuite, etc. Avec le recul je trouve ça un peu formel et pas très motivant.

Avec des débutant·e·s en développement web voire en développement tout court, j’insisterais sur l’idée de créer quelque chose. Dans ce cadre, HTML et CSS ne sont que deux outils sur cinq ou 6. On peut bosser sur plein de sujets : de l’animation, des ébauches d’application multimédia (par exemple une application pour générer des sons ou de la musique), une galerie de photos, mettre en page un poème ou une tablature de guitare, etc. L’important serait de publier le résultat (par exemple sur GitHub Pages, Netlify, ou en codant directement sur Glitch) et le partager à quelques personnes : voilà ce que j’ai fait.

Avec un public de développeurs·euses qui a déjà une formation initiale en développement “backend” mais très peu d’expérience en UI, le risque principal c’est le découragement car CSS est un domaine à part. Les compétences déjà acquises en Java, PHP, Python ou SQL ne se transfèrent pas vraiment à l’apprentissage de CSS (Miriam Suzanne, Why Is CSS So Weird?). Et si on n’a pas anticipé ce problème, on peut se retrouver en pleine dissonance cognitive (Natalya Shelburne, CSS at the Intersection) et abandonner.

Du coup, s’il faut se familiariser avec un nouveau domaine et une culture de design et d’ergonomie, pourquoi ne pas enseigner directement ces concepts de design, en utilisant CSS comme un exercice d’application ? Et enseigner directement des bases d’accessibilité, en utilisant HTML pour la mise en application ? En somme, viser un résultat plutôt qu’enseigner un langage.

Static site generators

2018-10-07T00:00:00+02:00

I’ve been looking for a decent static site generator to build a simple, 10-page-or-so documentation site, and I’m failing. Here are some notes on my journey, to serve as a warning sign to future travellers, and thoughts on what static site generators could do better.

What is a static site generator, really?

I’d like to try and describe static site generators as if we hadn’t encountered this class of software yet. Please do not skip this section, even if you already (think you) know the answer.

Static site generators (SSG) are a class of software programs that help with creating websites. They’re often written by developers — professionals or hobbyists — to power their own small website or blog, and as such they tend to have a limited feature set.

SSG are close parents to scripts: short programs (a few hundred lines of code), which can be used from a command prompt to achieve specific tasks. They’re often built as a hobby by one developer, sometimes getting help from a few others months or years later. They almost never offer a graphical user interface.

One core principle of those scripts is that they work with a source collection of plain text files (aka “content”), process those files to transform them to the HTML format, and wrap them in more HTML. This is often called a “build” step. Before running the build command, you would have a file tree that looks like this:

My Cool Website
└── content
    ├── 2018-09-07-cool-blog-post.txt
    └── 2018-10-01-other-blog-post.txt

And after typing some text to run a command in a “terminal” or “command prompt” application, you would get something like:

My Cool Website
├── content
│   ├── 2018-09-07-cool-blog-post.txt
│   └── 2018-10-01-other-blog-post.txt
└── output
    ├── cool-blog-post.html
    ├── index.html
    ├── other-blog-post.html
    └── rss.xml

With that setup, you get a simple blog with one HTML page for each blog post, an index (or home) page that lists published posts, and a RSS feed. You can write your own styles if you know CSS, or — with some SSG, but not all — use a “theme” or an example project as a starting point.

Users of static site generators do this work on their own computer, and after the “output” folder has been generated they are expected to know how to put those files online to publish them. This can require software such as a FTP client, or more complex setups involving one or two additional command line tools.

There are hundreds of static site generators, with many listed on StaticGen.com. Some of the most popular ones are Jekyll, Hugo and Hexo.

When it comes to editing features, there are not many to speak of. Users are expected to know what formats like HTML and Markdown are, how to prepare images themselves (in Photoshop, Gimp or similar software), how to insert images inside a page’s content by using code that may look like this:

![My cat at 4 months](./sniffles-4months.jpg)

Or even something more complex:

![My cat at 4 months]({{< imgproc sniffles-4months.jpg Resize "600x" />}})

At this point we must recognize that static site generators are tools made by developers for developers. They require a ton of previous knowledge: HTML, Markdown, command line interfaces, FTP or some other way to publish HTML files online, and of course you would need some kind of web hosting to put those files. Users will also need to dive into technical documentation for their tool of choice when they want to customize their site’s pages, work in “templates”, learn a templating language, and probably write some CSS.

The most popular static site generator, Jekyll, may have the best documentation pages of the lot. And yet, it still puts a bunch of technical language front-and-center, on the project’s home page:

Jekyll’s core message, “Get up and running in seconds”

This is developer-talk, because static site generators are tools made by developers for themselves and their peers.

On the other hand, “content management” software such as WordPress, Drupal or my personal favorite, Kirby, target a dual audience: content editors (who write and manage content), and developers (who set up the CMS and implement the site’s design and features).

I’m making this point because, if we own up to who our software’s audience is, then we can consider what we can do for that audience and hopefully design less terrible software.

A developer’s idea of elegance

I sometimes talk with developers who praise static site generators as simple, which is hogwash. I’ve seen a few projects where content editors were handed off a site based on a SSG (especially in startups where devs may dominate the conversation), and could not manage any change without a lot of training and assistance. Nothing simple about that.

What those developers probably mean is that they find static site generators elegant. A programmer thinks that a solution is elegant when it uses their current knowledge to achieve something with:

few steps,
no repetition, and
not too much indirection.

Static site generators are an elegant solution for developers because:

It rests on our previous knowledge of: file and code formats, the command line, the plain-files-and-scripts philosophy, git and ssh or scp and other deployment strategies, etc.
Using this base knowledge, it offers solutions to boring, repetitive tasks. For example, Markdown syntax lets us avoid repeating <p>…</p> tags in our content; templates let us avoid tasks like manually repeating HTML structure and updating menus and content lists.
Finally, using the filesystem to store content lets us work in a single place (avoiding database software and languages, which would be overkill for limited datasets).

I’m all for elegant solutions that fit my mindset (aka just “elegant solutions”), and I’ve used static site generators in the past, including Pelican, Hyde, Jekyll and Metalsmith.

Here’s the thing, though: it’s been a terrible experience. It turns out that static site generators are terrible at handling content. Which is too bad, because that’s one of their very few features to begin with.

Static site generators are elegant on principle, but are not designed to deal with content more complex than a handful of pages and a list of blog posts. And I’m not talking about the speed of building hundreds of pages or more (Jekyll is notoriously slow, Hugo is fast), but the sheer ability to use content however you want.

Static site generators are bad at content

Let’s back up a bit. Most static site generators were built — or at least are advertised — as alternatives to database-driven CMS software. We’ve already shown that they may only be a valid alternative for developers and technical users with a lot of prior knowledge. But they are missing another core capability of CMS software.

In your average PHP or Python CMS, as in many Web frameworks, querying content from a relational database is always possible (and more or less straightforward). Linked objects and/or hierarchical content structures are built in features. Building home pages, landing pages, lists, modular pages, product pages with many sections, etc., out of content hierarchies or relations is standard practice; CMS software that was too limited to do that either evolved or was replaced by their competition.

When I’ve used static site generators in the past ten years, there were a few pain points like lacking documentation and strange and incompatible conventions. But the nail in the coffin was always that it’s either impossible or way too hard to build a single page from several pieces of content.

Recently, I’ve looked at static site generators again, because I wanted to convert Kaliop’s Frontend Style Guide, originally built with Kirby CMS, to something that could be built to static HTML in fewer steps by developers (e.g. npm install && npm run build).

This site is made of a handful of long “chapter” pages, with a top-level table of contents which lists all chapters and their sections:

For easier content management and reordering of sections, I had broken each chapter into different section files, so that the index page is generated from three levels of content. Looking at the “General Rules” branch only, the content hierarchy looks like:

2.0
└─ general
   ├─ 1-readme
   ├─ 2-editorconfig
   ├─ 3-dry
   └─ 4-clean

When generating the full table of contents, I expect to be able to write (in pseudo-code):

for chapter in page.children:
    print chapter.title
    for section in chapter.children:
        print section.title

Similarly, when generating a chapter page, I expect that I can easily print the full chapter content:

for section in page.children:
    print section.title
    print section.content

Actual templates would be a bit more complex, since we need to wrap this content in HTML tags, and maybe pass it to template partials or components. But retrieving content from a hierarchy of local files should be straightforward.

I haven’t found a single static site generator that handles this use case gracefully. Instead, after reviewing the documentation of three dozens tools (listed on StaticGen), and actively trying to build my use case with a handful of them, I’ve seen a range of limitations and awkward workarounds:

Sometimes it’s just not possible to work with content hierarchies and partial content. (Most JavaScript static site generators fall into that category.)
Or you have to write some configuration code that populates “Collections” ahead of build time. (Too indirect, and breaks if you change your information architecture a bit. We need something a bit closer to direct manipulation!)
Finally, a short list of tools allow listing a page’s children or “resources”, but have bugs when dealing with more than one level (Gutenberg) or impose arbitrary restrictions on what page “types” can list different types of content (Hugo).

When you can list content from children, grandchildren or other locations, it’s often not possible to process this content as Markdown or access its metadata.

A few words of warning about Hugo

The Hugo static site generator, praised by many for its speed, is more capable than most. There are surely many good things to say about Hugo, but in the spirit of warning folks about the terribleness of software: I wouldn’t recommend it for anyone who wants a smooth learning experience.

For one thing, it requires learning about way too many specific concepts: Sections, Lists, Taxonomies, Page Bundles, Leaf Bundles, Template lookup order, and the perfectly unintuitive differences between a index.md page and a _index.md page. (Or are those Sections, or Bundles? Is one a Section and the other a Page? Are Sections and Bundles “pages” too? I have no idea.)

I particularly dislike the way Hugo matches a page to a dozen possible template files or more — taking a page from Drupal’s book of idiosyncratic awfulness. Now, I understand that this is meant to make it possible to use different “themes”, and at worst your pages will still render with the theme’s layouts/_default/list.html or layouts/_default/single.html templates. But if you want to write your own HTML and CSS, the template lookup stuff is a nuisance (much like it is in the Drupal world when you want any kind of control over the HTML output).

On top of the complexity of Hugo’s design, its documentation is often subpar. For instance, the “Content Management > Page Resources” page does not explain much about, well, content, or content management. I expected a description showing content examples (some markdown or a file structure maybe), then information about how to use it in templates and other contexts. Instead, it’s a kind of API documentation listing “Properties” and “Methods”.

The second issue is that while Hugo builds pages fast, it often builds the wrong thing fast. For instance, if I rename a index.md file to _index.md, I need to run the hugo command two or three times to get it to render with the correct template. Using hugo server seems even less reliable.

Hugo is also unhelpful when a source Markdown file doesn’t render anything (there is no log or warning) or outputs a cryptic <pre></pre>. This doesn’t help the learning curve.

That being said, I heard that Hugo is an interesting choice if you’re building hundreds or thousands of pages (because it builds these pages really quickly), in which case it might be worth spending a couple weeks learning to use it.

What could we do differently?

There are thousands of static site generators out there (counting a bunch of scripts with 5 stars on GitHub) because thousands of developers looked at existing solutions and said “eh, I’ll just build my own”.

As a thought experiment, here are the core topics I would look at if I wanted to build my own tool from scratch.

1. Content naming conventions

Conventions for naming content files are necessary to allow users to create content files quickly and get predictable results. Those conventions must be short, clearly defined, clearly explained (you need great docs here), and intuitive (when possible, follow existing conventions rather than roll your own).

Major issues to solve regarding source content:

What will translate to a web page?
What will be ignored?
How may users control the transformations that are applied to content (processing of Markdown or other formats, templates, image transformations)? Should this be defined in the content or elsewhere?
How do you generate alternative views for the same page, e.g. a HTML page and a RSS or Atom feed?
How can you generate category and tag pages? More generally, how do you generate any limited set of pages based on querying information from other content, without having to manually create a new (probably empty) content file?

Some of those concerns can be addressed in templates or in configuration or other code, but there’s value in using elegant conventions to let users directly manipulate or tweak content to get a desired result.

2. Give feedback on content-to-output mapping

The generator should provide, by default, feedback on which files are picked up, which are ignored, and why. When a file is picked up and processed in some way, it should say so too.

To surface this information efficiently, the generator may need to come with a GUI (a web UI could work). I would be looking at tools like Fractal for inspiration.

3. More code should happen in templates

Most generators use restrictive template engines, and feed a restricted context (aka a set of data and functions) to those templates. This seems to come from a misguided need to keep templates “simple”, “logic-less”, and other kinds of baloney. Look, in a big MVC application built by people with different roles and technical knowledge, it might be useful to have your very responsible backend developers write controllers and let designers or frontend developers write HTML in a sandbox. Well, that’s a questionable approach too.

Anyway, as we said we’re making a tool for technically-minded people, and should give them power to actually do stuff. And since we’re talking about websites built ahead-of-time, the risks of logic in templates don’t apply as much.

Another consequence of restricted templates is that SSG documentation will then tell you to work in a third place: not in content, not in templates, but in “config code”. This is a problem because A) it’s probably one place too many and B) it’s often unclear at what time this config code is running or how often: once for every page generation or template run, or just once at the start of a build?

So, do more work in templates. We’re making somewhat simple websites here, it’s going to be okay. It’s cool if you can refactor your code to avoid duplication or separate concerns or whatever, but this shouldn’t be a requirement; users will only jump through hoops if they’re working on a big enough project to justify it.

4. A full content API

There should be a full content traversal API, which could be modelled after Kirby’s API (itself inspired by jQuery). Other sources of inspiration:

Globbing, e.g. find('posts/*.md').
DOM traversal (there’s no reason why your content tree cannot be a tree of nodes).

One concern with offering a full content API in templates is that if you run a template for a thousand pages, and do the same work (including querying the filesystem) every time, you’re going to have performance issues. I have a few possible optimizations in mind (fragmenting content queries and memoization), but I’ll admit that as a UI developer this is not my forte.

On top of traversing and retrieving content, templates should be able to transform formats (Markdown to HTML, parsing JSON and maybe YAML) and process images.

5. Markdown plus front-matter is too limiting

Originating in simple blog engines, static site generators treat pages as a single content chunk (often in Markdown) with some metadata sprinkled on top. If you need several long chunks of content (say, a product short description, long description, technical specs, and a list of vendors), you’re out of luck.

Theoretically, you can put any kind of text content in YAML “front-matter”, but editing that content without breaking the YAML syntax is a pain.

One workaround is using separate files in the same folder or in subfolder, than use the content API to retrieve them. Each such “resource” can have a body and metadata.

Kirby does things a bit differently (though it’s always possible to use a page’s files or child pages too), using a custom format with arbitrary fields:

Title: My Title
----
Date: 2018-12-25
----
Desc: Short description for list views and SEO.
----
Body:
## A field contains arbitrary text
So we can use a field value and parse it as Markdown or whatever.
…
----
Notes: …
----
References: …

Other sources of inspiration:

Vue single-file components, and, well, XML
Inside the page’s body: shortcodes (WordPress, Hugo), Web Components, Vue components (Vuepress)
Separators using HTML comment syntax, like

I’m not sure what would be the “best” solution, but it should be possible to unlock more power without completely breaking with convention.

6. No theming system

A theming infrastructure imposes a lot of technical restrictions and indirection, such as template lookup orders (see: Hugo), having to specify a handful of default template names (Hugo, again), and having to specify strange content conventions for mapping content to those default template names (still Hugo). Frankly, if a user really wants a template inheritance and theme inheritance mechanism, they’ll probably bite the bullet and work with WordPress or Drupal.

In the lightweight CMS world, having a theming system is the main reason why Grav is less straightforward than Kirby (which inspired it): themes and plugins rely on metadata in pages, so you have to put detailed config-as-metadata in every page to enable and configure theme and plugin features, which often feels like randomly pressing buttons and hoping to get a result.

Styling buttons, the right way

2018-05-09T00:00:00+02:00

If you’re building a website or a web app, you probably have buttons. And maybe links that look like buttons? Anyway, it’s important to get them right.

In this tutorial we’ll create basic styles for <a> and <button> elements, and a custom .btn CSS component. You will find a demo page for each step of the process.

Demo	Section
Step 1	Resetting `<button>` styles
Step 2	Writing a “button” CSS component
Step 3	Styling hover, focus and active states
Step 4	Dealing with sticky focus styles

Resetting `<button>` styles

As a rule, 99.9% of the clickable things in your website or app should be either <a> or <button> elements. If you’re not sure what element to use in a given situation:

If it goes to a different URL or changes most of the page’s content, use a link (<a href="some_url">…</a>).
Otherwise, use a generic button (<button type="button">…</button>).

Using the correct element has a few advantages: it’s SEO-friendly (especially for links!), it works well with keyboard navigation, and it improves accessibility for all users.

In spite of this, developers rarely use the <button> element. All over the Web, we can see a lot of buttons that trigger JavaScript actions, and on closer inspection it turns out they’re coded with <div>, <span> or <a>.

Why is the <button> element so underused?

Knowledge: many developers don’t know about it (learning HTML’s 100+ elements takes a little while).
Styling: <button> comes with complex default styles, which can make it hard to achieve a custom look.

Thankfully, the styling part can be fixed!

/**
 * Reset button styles.
 * It takes a bit of work to achieve a neutral look.
 */
button {
  padding: 0;
  border: none;
  font: inherit;
  color: inherit;
  background-color: transparent;
  /* show a hand cursor on hover; some argue that we
  should keep the default arrow cursor for buttons */
  cursor: pointer;
}

We end up with buttons that look like regular text.

The downside of this approach is that now we have to style all our buttons, or users won’t recognize them (see: affordance). Another option is to use this style as a mixin (with Sass or another preprocessor) and apply it selectively:

@mixin button-reset {
  padding: 0;
  border: none;
  font: inherit;
  color: inherit;
  background-color: transparent;
  cursor: pointer;
}

.my-custom-button {
  @include button-reset;
  padding: 10px;
  background-color: skyblue;
}

<button type="button">
  I use default browser styles
</button>

<button type="button" class="my-custom-button">
  And I’m using custom styles instead
</button>

Writing a “button” CSS component

Now that we’ve removed default styles, let’s define our own button styles. This is what we’d like to do:

a “button” style that can be applied to both links or buttons;
we want to apply it selectively, because we’ll have other link and button styles in our pages.

This calls for a CSS component. A CSS component is a style or collection of styles which we can apply using classes, often on top of a few different types of HTML elements. You may be familiar with this concept from CSS frameworks like Bootstrap or Foundation.

We’ll call this component .btn (like Bootstrap does, but we’ll restrict ourselves to a single color and size, to keep things simple).

.btn {
  /* default for <button>, but useful for <a> */
  display: inline-block;
  text-align: center;
  text-decoration: none;

  /* create a small space when buttons wrap on 2 lines */
  margin: 2px 0;

  /* invisible border (will be colored on hover/focus) */
  border: solid 1px transparent;
  border-radius: 4px;

  /* size comes from text & padding (no width/height) */
  padding: 0.5em 1em;

  /* make sure colors have enough contrast! */
  color: #ffffff;
  background-color: #9555af;
}

Here is what our button component looks like:

You may be wondering why contrast is such a big deal. That second line of buttons looks nice; who doesn’t like a pastel look?

Simply put: with good contrast, you can reach more users. Some of your users have imperfect vision. Others may be looking at your site on their phone, on the go, with the daylight making things harder to read. You can check your contrast ratios here, and read more about the UX of text contrast here.

Styling hover, focus and active states

It’s cool that your button looks nice, but… users are going to interact with it, and they will need visual feedback when the button’s state changes.

Browsers come with default styles for “focus” and “active” (i.e. pressed) states, but by resetting button styles we’ve removed some of those. We would also like to have styles for mouse-over, and overall we want styles that are visible and match our design.

Let’s start with a style for the :active state, triggered briefly when your button or link is clicked:

/* old-school "down" effect on clic + color tweak */
.btn:active {
  transform: translateY(1px);
  filter: saturate(150%);
}

We could change the button’s colors, but I want to reserve this effect for our mouse-over styles:

/* inverse colors on mouse-over */
.btn:hover {
  color: #9555af;
  border-color: currentColor;
  background-color: white;
}

Let’s now add some focus styles. Users of your websites or web apps can use the keyboard or virtual keyboard (on iOS and Android) to “focus” and activate form fields, buttons, links and other interactive elements.

For some users it can be a way to speed up slow interactions, like filling a form.
For others, using a mouse or touch pointer is impossible or difficult. They rely on using the keyboard, or a specialized device, to visit websites.

In most Web projects I’ve seen, designers specify the expected mouse-over styles but not focus styles. What should we do? A simple solution is to reuse the :hover style as our :focus style:

/* inverse colors on mouse-over and focus */
.btn:hover,
.btn:focus {
  color: #9555af;
  border-color: currentColor;
  background-color: white;
}

And once you have this visible focus style (and not before!), you may want to remove the browser’s default styles for your button:

.btn {
  /* ... */
  /* all browsers: remove the default outline since
      we are rolling our own focus styles */
  outline: none;
}

/* Firefox: removes the inner border shown on focus */
.btn::-moz-focus-inner {
  border: none;
}

Try it out here; if you’re on a desktop computer, use the Tab and Shift+Tab keys to navigate between buttons:

Dealing with sticky focus styles

There is one tricky issue left. In several browsers, when you click a link or button, two pseudo-classes will apply:

:active
:focus

The “active” pseudo-class stops applying as soon as you stop pressing the mouse button or trackpad. But in some browsers, the :focus style stays until the user clicks something else on the page.

In my tests, affected browsers include Chrome (66), Edge (16), and Firefox (60, only for links). Safari (11.1) seems to be smarter and avoid this issue.

We can fix this using the new :focus-visible pseudo-class (draft specification). This feature is still not fully specified, but the idea is that browsers should set the :focus-visible state only after keyboard or keyboard-like interaction, rather than on clicks.

Since it’s not yet implemented by browsers, we will have to use a JavaScript implementation, such as this polyfill. It operates on the whole page, and sets a focus-visible class on elements that received focus when using the keyboard only.

Let’s change our styles to decouple :hover and :focus styles:

/* inverse colors on hover */
.btn:hover {
  color: #9050AA;
  border-color: currentColor;
  background-color: white;
}

/* make sure we have a visible focus ring */
.btn:focus {
  outline: none;
  box-shadow: 0 0 0 3px rgba(255, 105, 180, 0.5),
    0 0 0 1.5px rgba(255, 105, 180, 0.5);
}

Now, after we’ve included the focus-visible.js script in our page, it will add a js-focus-visible class to the <body> element. We can use this to remove focus styles from focused elements which do not have the focus-visible class:

/* hide focus style if not from keyboard navigation */
.js-focus-visible .btn:focus:not(.focus-visible) {
  box-shadow: none;
}

A simpler solution would be to declare focus styles for the focus-visible class only, but this would break if the polyfill is not active (e.g. if our JS failed to load).

This is our final result:

You can look at the final code to review everything we’ve seen in this tutorial.

Command line tips

2018-05-03T00:00:00+02:00

I’d like to share a few command line things I’ve learned in the past years.

The command what?
You need help (and tldr is great)
Bash keyboard shortcuts
MacOS: install Homebrew and GNU coreutils
How big is this directory?
How to not delete everything

The command what?

I’m talking about the command prompt found in macOS when using the built-in “Terminal” application, or on Windows when you install something like Git Bash. It’s a text-based interface where you type commands to navigate in folders, create or delete files, and much more. If you’re curious and want to get started, this tutorial is pretty good for learning from scratch.

In the next sections, examples will look like this:

# This line is a comment
$ command parameter --option

The dollar character ($) indicates a command that you can type. You should not type this character, only what comes after it.

You need help (and `tldr` is great)

Sometimes you remember the name of a command, but how should you use it? What arguments and options does it take?

Most operating systems will come with documentation files called “man pages” (man is for manual). For example if I want to be reminded how the cd (change directory) command works, I could type man cd and press the Enter key, and I would get this:

That’s great, but those doc pages are long often hard to read. Can I get a summary?

One option is to use the command’s built-in help, if it exists. For example you can call mycommand --help. But some commands don’t have a help option, some use -help (single hyphen), some use -h, some use mycommand help (no hyphen), it’s a mess!

My solution is to use the tldr command. It’s an open-source documentation project for common commands, which shows very short usage examples. It looks like this:

You can use it online, but it’s quicker to use it straight from the command line. You will need to have Node.js and npm installed to use it, though, so it’s only useful if you’re using those tools already.

Installation looks like this:

# Install with npm
$ npm install --global tldr
...

# Time to use your new powers!
$ tldr rm

Bash keyboard shortcuts

When you’re using a Terminal or command prompt on Linux or macOS, you’re probably using the Bash program. (On Windows, you can install Git Bash to use that instead of cmd.exe.)

Bash is, among other things, the program that allows you to write commands an see their output.

One thing really frustrating with Bash and terminals in general is that you can’t just click around to move the input cursor, like you would in a code editor. If you’re like me, you probably spent a lot of time using the left and right arrows to move the cursor in a line of text.

So here are a few keyboard shortcuts that can help:

Up: fill the command prompt with the last command; useful if you need to correct it. Use “Up” several times to go back in history.
Ctrl + Left and Ctrl + Right (or Alt + Left|Right on macOS): move the cursor by a full word.
Ctrl + A: move the cursor to the start of the line.
Ctrl + E: move the cursor to the end of the line.
Ctrl + K: delete all characters to the right.
Ctrl + U: delete all characters to the left.

MacOS: install Homebrew and GNU coreutils

If you’re going to work on the command line often on macOS, it’s probably a good idea to install Homebrew, which will help you install more command-line tools.

Once you’ve installed Homebrew, I recommend using GNU Core Utilities, which contains the GNU version of tools like ls or rm. Compared to the similar tools that come with macOS, they’re often a bit more usable.

# Install coreutils, then follow the instructions
# to use them instead of macOS’s built-in ones
$ brew install coreutils

How big is this directory?

I’ve had trouble remembering how to check how big a directory is. For the past 15 years, I would have to switch to a graphical file explorer to do that.

Sometimes I would find this command:

# Show the size of everything in current directory
$ du -sh *

But I would never manage to remember it. Then it hit me that it sounds a bit like “douche”, so if you need something to help you memorize it, you’re welcome.

Here’s another trick for listing folders sorted by size. This only works on Linux, or on macOS if you’re using GNU Core Utilities:

How to not delete everything

When you want to delete a directory which contains a lot of files, you’re probably going to use rm -rf. It might look like this:

$ rm -rf some/path

But if you mess up the path part, you can end up deleting the wrong folder. For instance, maybe you wanted to delete a bunch of old log files:

$ sudo rm -rf /var/log/some-program/old-logs/*

But when you types, you pressed Enter by mistake, and the resulting command is now:

$ sudo rm -rf /

Shit.

There’s one way to make this kind of human error less likely: write the -rf part last:

$ sudo rm /var/log/some-program/old-logs/* -rf

If you hit Enter by mistake, the command will be:

$ sudo rm /
rm: cannot remove '/': Is a directory

Phew.

This is a good habit to get into:

Write rm then the directory’s path.
Check the path, does it look okay?
If it’s okay, write -rf at the end.

The main issue here is that on Linux this will work perfectly, because the GNU version of rm can take options at the beginning or at the end. But on macOS, the BSD version of rm will tell you that -rf is not a file. My workaround for this is installing GNU coreutils with Homebrew.

Gradient fills for SVG icons

2018-03-26T00:00:00+02:00

In my 2016 article How to work with SVG icons, I concluded the “Advanced” section with this warning: sorry, gradient fills won’t work.

I was mostly referring to code like fill: linear-gradient(red, blue) which does not work because fill is from SVG which has its own gradient system, and linear-gradient is from CSS and made mostly for backgrounds. The two don’t mix well.

I knew we could probably use SVG’s <linearGradient/> element but hadn’t really tried it. Then a few months later I did try it, and it worked!, but I forgot to blog about it. So, how can we do this thing?

Putting gradients in your HTML

The most reliable technique I found was to add a SVG element in your HTML page (at the start or end of the <body>, for instance). It should define a <linearGradient/>:

<svg style="width:0;height:0;position:absolute;" aria-hidden="true" focusable="false">
  <linearGradient id="my-cool-gradient" x2="1" y2="1">
    <stop offset="0%" stop-color="#447799" />
    <stop offset="50%" stop-color="#224488" />
    <stop offset="100%" stop-color="#112266" />
  </linearGradient>
</svg>

This element should not be hidden with display:none, because some browsers will just ignore the gradient if we do that. Making it zero pixels high seems to work.

You can then use this gradient on your SVG icon:

<svg class="icon" fill="url(#my-cool-gradient) #447799;" aria-hidden="true" focusable="false">
  <use xlink:href="#symbol-id"></use>
</svg>

Or in your CSS:

.icon {
  /* gradient and fallback color */
  fill: url(#my-cool-gradient) #447799;
}

These two icons should be using a turquoise-to-dark-blue gradient.
Credits: Leaf by Gabriele Malaspina and Carpet by Ben Davis

Note that you cannot customize the gradient on a per-icon basis. If you want different gradients, you will need to create different SVG gradient definitions in you HTML.

Changing gradient colors with CSS variables

If we want to set our gradient colors from CSS, we could do it using CSS variables. We’re going to write our gradient definitions using CSS custom properties (var(--my-custom-property)).

<svg aria-hidden="true" focusable="false" style="width:0;height:0;position:absolute;">
  <linearGradient id="gradient-horizontal">
    <stop offset="0%" stop-color="var(--color-stop-1)" />
    <stop offset="50%" stop-color="var(--color-stop-2)" />
    <stop offset="100%" stop-color="var(--color-stop-3)" />
  </linearGradient>
  <linearGradient id="gradient-vertical" x2="0" y2="1">
    <stop offset="0%" stop-color="var(--color-stop-1)" />
    <stop offset="50%" stop-color="var(--color-stop-2)" />
    <stop offset="100%" stop-color="var(--color-stop-3)" />
  </linearGradient>
</svg>

Now we can set — and, if need be, change — those colors in our CSS:

#gradient-horizontal {
  --color-stop-1: #a770ef;
  --color-stop-2: #cf8bf3;
  --color-stop-3: #fdb99b;
}
#gradient-vertical {
  --color-stop-1: #00c3ff;
  --color-stop-2: #77e190;
  --color-stop-3: #ffff1c;
}

And, finally, use them as icon fills:

.icon-hgradient {
  fill: url(#gradient-horizontal) gray;
  /* We could use it as a stroke fill too:
  stroke: url(#gradient-horizontal) gray; */
}
.icon-vgradient {
  fill: url(#gradient-vertical) gray;
}

Here’s the result (in browser supporting CSS Custom Properties):

Testing icons with SVG gradient fills and CSS variables

The gradient fill is painted for each path of the icon. To avoid color mismatches (like the junction between the leaf and the stem), it might be useful to merge all or most paths in the icon’s source SVG.

Using gradients in external files

This technique works in Firefox, and used to work in Edge (confirmed in Edge 14 and 15, regressed in Edge 16 and Insider Preview). In the following test:

Both icons are fetched from an external sprite: sprite.svg.
The first icon uses a gradient from this HTML page, and the second one from sprite.svg.

.icon-sprite-gradient {
  fill: url(sprite.svg#my-warm-gradient) red;
}

Non-supporting browsers (Chrome, Safari, latest Edge…) should show a red fallback fill for the second icon.

Using gradients in CSS as data URLs

What if I told you that you could define your gradients in SVG, but put the SVG in your CSS as data URLs? Okay now I’m just being silly. But it works! At least it works in Firefox :P

/* Notice the `id="grad"` in the SVG URL and how we’re using it at the end. Note that the `#` in hexadecimal colors must be escaped as `%23`. */
.icon-gradient-url {
  fill: url("data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg'><linearGradient id='grad'><stop offset='0%' stop-color='%23ff00cc'/><stop offset='100%' stop-color='%23333399'/></linearGradient></svg>#grad") purple;
}

/* Same SVG, in base64 */
.icon-gradient-base64 {
  fill: url("data:image/svg+xml;base64,PHN2...zdmc+#grad") purple;
}

See how we reference the gradient’s id with #grad at the end of the URL? Only Firefox seems to understand this syntax. Eh, too bad.

Trying to show a magenta to purple gradient. Non-supporting browsers (Chrome, Safari, Edge…) should show a purple fallback fill.

Let’s recap

Yes you can have gradient fills!
But you need to include SVG gradients in your HTML
Colors can be hardcoded in the SVG gradient (in HTML), or set in CSS (using CSS variables)
All icons using a given gradient will use the same colors, you can’t override on a specific color like this:

.icon-gradient-override {
  /* This works, as shown before */
  fill: url(#gradient-horizontal) gray;
  /* But this will do nothing… */
  --color-stop-1: white;
  --color-stop-2: gray;
  --color-stop-3: black;
}

If you need a lot of different gradient fills, this technique might not work for you. Creating 10 or 20 different SVG gradients in your HTML is not practical. But for simpler use cases, this should work in all current browsers (including IE11 if we avoid CSS variables).

A few wishes for privacy settings in Firefox

2018-02-07T00:00:00+01:00

Update: as I was writing this post, Mozilla was already working on privacy features and settings. Firefox’s Tracking Protection was released in 2018 and enabled by default for all users in 2019.

Firefox could do more to limit online tracking. Recently with the Quantum effort, Mozilla rebranded Firefox along three attributes: speed, customization and privacy. Yet the browser’s defaults allow most tracking techniques by default, for the sake of compatibility with existing websites.

About tracking

Most web browsers leak a lot of user data by default. For instance:

They allow third-party services (which a website almost always uses, e.g. Google Analytics, Facebook Connect, and ad providers) to track users’ activity across many websites, using third-party and first-party cookies.
They allow sites to know where a user is coming from (with the Referer HTTP header).
Through JavaScript, they give access to a lot of information on the browser itself, the operating system I’m using, my time zone, how many processor cores I have, and some of my preferences (e.g. whether I allow cookies, which languages I prefer reading). This and other technical information can be used to identify you uniquely across the web, a practice dubbed “fingerprinting”.

I’m probably forgetting a few things. Try the EFF’s Panopticlick tool to get an idea of how resistant your browser is to tracking and fingerprinting.

Most users don’t realize how much random companies they never deal with (such as ad networks) and other companies they do deal with (such as Google and Facebook) manage to know about them.

I’ve had a few friends and relatives asking how to remove a virus from their browser… where by “a virus” they meant “many sites I visit show me the same ads that seem to know too much about me, so a virus must be spying everything I do and inject ads in my computer”. After explaining a bit, I cleaned their cookies and installed uBlock Origin for them.

Why browsers don’t do more

Of course all the technical features I mentioned are not provided for tracking users, they are simply abused that way. But why won’t browsers stop this abuse? Why even load scripts — executable code with access to a bunch of information and features! — from other domains, why enable cookies for third-parties, etc.

In short: since it was possible before, most sites rely on these loose permissions now, and would break if they were tightened.

There are still opportunities for tightening these features and preventing at least some of the massive tracking going on, but different browser vendors have different priorities:

Chrome has a good focus on security but is all-in on tracking, because spying on users is Google’s business model.
Firefox is in a strange position because their brand is about independence and privacy but ultimately the bulk of their money comes from ad-and-tracking companies: Google, Yahoo and perhaps one of their competitors in the future. Also if a website stops working in Firefox then users are likely to blame Firefox for the breakage (and not the website for their invasive tracking techniques), and jump ship to Chrome.
Upstarts like Brave target a niche of tech-savvy privacy-conscious users, which want an on-by-default ad blocker, so they have some breathing room here. Also they’re based on Chromium so that limits other kinds of breakage (e.g. all the “Chrome only” web apps launching these days, from Google and others), which buys them some goodwill.
Safari enjoys a monopolistic position on iOS (since other browsers on iOS must use WebKit for rendering pages), and has good usage numbers on macOS, so they can get away with off-by-default third-party cookies and more recent things such as Intelligent Tracking Protection.

What Mozilla is doing

Note: I’m not an employee and not a big contributor to Mozilla projects. The information in this section comes from reading updates on Mozilla blogs and Twitter accounts.

Back to Firefox. While I wish Mozilla would have their Tracking Protection feature on by default, I understand that it can be a hard sell: many Firefox users would not be aware of that feature or what its advantages are, and they would resent the occasional site breakage.

Which is why Mozilla is experimenting with such features in Private Browsing Mode only: in this mode, users can expect things to maybe break, and are warned about it.

In Private Browsing windows, Tracking Protection is on by default, and Mozilla is working on shortening the Referer HTTP header for third-party domains so that sites can only know which site you’re coming from and not which specific page (or worse, what private information the URL contained, in some bad cases).

Mozilla is also researching how often privacy-centric restrictions break websites; basically they’re trying to figure out what they can do without losing a bunch of users.

Firefox Focus is another attempt at privacy-by-default, launched as a separate product (and sub-brand).

Privacy settings should be simpler

Currently, a more private setup in Firefox requires:

Activating Tracking Protection for all sites in the “Privacy” page of the browser preferences. This setting is also way down in the page.
Tweaking some settings in the “Privacy” page, some being a bit painful to get right (blocking third-party cookies or restricting cookies to the current section only).
If you’re feeling even more adventurous, there are a bunch of settings to tweak in about:config, for HTTP Referer and more.

This should be simpler, and more palatable to most users.

My wish would be for Mozilla to design a combo of privacy features which users could activate in one click. And because nothing is ever new, in spirit it would be somewhat close to what Microsoft did with Internet Explorer’s security levels:

I don’t have fond memories of this setting because, as a developer, it meant that a client’s IE6 or IE7 would sometimes block all scripting. But in retrospect I do find that it had some merits as a preference, if not always in the specific technical choices that were made.

Two, maybe three levels of protection could be offered:

Default (current behavior, which should not stop Mozilla from upgrading its privacy by blocking third-party cookies and maybe offering something similar to Safari’s Intelligent Tracking Protection…)
More Private (enables Tracking Protection, disables third-party cookies altogether or limits them to the current session, and maybe adds some other technical restrictions such as truncating Referer and fingerprinting resistance.)
Private Browsing Only (same as #2, with some added technical restrictions and all browsing is in Private Browsing Mode)

That’s a very rough idea and maybe these specific profiles don’t make sense. But I think it’s an idea worth pursuing, to offer better privacy defaults and options to all users.

What’s more, this setting should not be hidden in the “Privacy” settings page, but should be near the top of the “General” settings page or at the top of the “Privacy” page at worst. It should also come with an onboarding campaign to explain the trade-offs of each mode and offer a chance to switch modes right there. Finally, there might be ways to reflect this setting — and maybe offer a chance to switch — on each tab, in the navigation bar or on the New Tab page itself.

I have no idea if the rambling post can be of any help achieving better privacy by default in Firefox or any browser, but here it is anyway. Thanks for reading.

Printing background colors with CSS and SVG

2018-01-24T00:00:00+01:00

A client’s site had a white SVG logo on top of a color background.

<header style="background:black">
  <img src="https://fvsch.com/articles/css-print-background/white-logo.svg"
       alt="The site’s name">
</header>

When working on the print styles, we had a problem: browsers would disable background colors and print the logo white on white. And in this case we could not change the logo image or use a filter: invert(100%) on it.

We could have used the non-standard -webkit-print-color-adjust CSS property, but what about other browsers?

Faking a background with SVG

By default, browsers will print content images. We can inject one in our page and display it as a kind of background, in 3 steps:

Use a pseudo-element (::before or ::after) and an image URL in the content property.
For a solid color, we can make a simple SVG image, which works well as a data-URL.
Finally, we use absolute positioning to place this pseudo-element in the background.

header {
  position: relative;
}
header > * {
  position: relative;
  z-index: 2;
}
header::before {
  position: absolute;
  z-index: 1;
  top: 0;
  bottom: 0;
  left: 0;
  right: 0;
  overflow: hidden;
  /*
    In the URL, change the background to your own color.
    Warning: the `#` character must be escaped as %23,
    for example: `background:%23FFFF00` (yellow).
  */
  content: url("data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 10 10' style='background:YOUR_COLOR_HERE' />");
}

Here is a fully working example in an iframe. You can test it by using your browser’s Print Preview on this page, or on the example page directly.

As noted, it’s a nice trick but don’t overuse it: you could cost your users a lot of money in printer ink.

Browser support

Works on all modern desktop browsers (tested in Edge 14–16, Firefox 58–60, Chrome 61–63, Safari 11)
Not tested on mobile browsers
Does not work in IE11

Three things to watch out for

The pseudo-element and the image are two separate entities. While the pseudo-element will cover its parent, the image will take the full width, and its height will depend on its aspect ratio. This means that the image will overflow its container, and we have to hide it with overflow:hidden.
In this example, we use a square image (viewBox='0 0 10 10'); if you need a taller image, use a rectangle one (for example viewBox='0 0 10 50').
Making sure that your url(…) is a valid data-URL can be tricky. In practice there is not a lot to escape, but if you are using double quotes to wrap your URL you will need single quotes for the XML attributes, and vice-versa. The # character identifies a fragment in URLs, so you will need to escape it using percent-encoding (%23).

Blogging with public drafts

2018-01-23T00:00:00+01:00

The last big article I published took ten days of research and writing. While I’m happy with the result, and have received positive comments, the prospect of writing another one like this is daunting. It was a year and a half ago.

Every article I write starts with a small itch to scratch, and I often decide to dedicate a few hours to it at most. And every single time, it takes at least 10 hours of work, and sometimes days. What starts as “I’ll write up this bit of information” ends up as a full guide with context and examples. I run a bunch of Google (or, lately, DuckDuckGo) searches to check if an English or French phrase does exist and means what I think it means (not always). I have a bunch of drafts that I’ve worked on for 5 or 10 hours, and that would need at least as much time to get out of the door.

It gets hard to just write some words and publish. Doubt creeps in. Does this even make sense? Who will want to read about that anyway? Hasn’t this topic been beaten to death already?

I’ve wanted to make the whole mental process easier for a long time, so here are a few steps I took already:

Scratched my old, carefully wrought design. Hello black-on-white Georgia, you look like a nice notepad to me.
Installed an editing interface, so I could work online and not on the command line (which, in practice, meant working on my own computer).

On top of that, I’d like to propose something a bit different for people who want to blog more: publish the damn draft. Finish, edit, rewrite or refine later.

I understand why print publications need cleaned-up stuff. And if I’m paying for articles, in print or not, I’d like them to be intelligent and edited. But the free blogging we do, who said it had to observe the same standards?

Talking to other ordinary bloggers (aka people who blog once in a full moon or less), it sounds like we’re holding ourselves to the unrealistic standard of published authors who often work with an editor. We try to be our own editor, but without any actual editorial review we end up doubting our words and our intent.

So here’s the trick I’d like to try: publish unfinished drafts. I mean drafts where you haven’t even reached the end of your thoughts or message. Get it out, tweet or signal-boost it maybe, and finish tomorrow or next weekend.

Just add a banner which says “hey, this is a draft and might not be complete yet; I hope to finish this article in the next days, but do go on reading”.

Reading books again

2018-01-19T00:00:00+01:00

I got my first e-reader a year ago, and it’s good.

I had pretty much stopped reading books at this point, which was a bit different from my previous experiences with reading.

ONE. As a teen I had a tendency to get bored and I spent a good chunk of those years reading science-fiction novels from the local public libraries (in French translations).

TWO. In college I was studying both French literature and English as a foreign language, so I made up a rule that all my “for fun” reading time would be in English, because at least I would be improving one of two skills. (While it did help my English skills, I also neglected to build an appreciation of classical and contemporary literature.) Then for a while I lost interest in fiction and was mostly reading essays and articles.

THREE. For context, I have some anxiety difficulties. Over time, as a result of mismanaged anxiety and changing habits — now including work, social media, and series more often than films — my attention span shortened. My capacity for sustained concentration dwindled. If something felt uncomfortable, I had to step back and switch to a different stimulus.

This affected my reading habits: I could still read articles (taking several breaks when they were long), but averaged at one and a half book per year (2 or 3 in a good year).

FOUR. In the summer of 2016, while I was burned out from (mismanaging my anxiety at) work, I tried to remember the last book I had read. (Madeline Miller’s The Song of Achilles, which I had read a year before.) As I made plans to recover, I knew that I wanted to start reading books again. Not that I think there’s something superior in that activity, but I suddenly felt nostalgic for the time when reading was a simple past-time and something I enjoyed consistently.

Or maybe I was angry and trying to get back some level of control over my fucked up mind, and hoped that reading more books would be both a sign of me getting better and a concentration practice of sorts.

FIVE. When you want to make a change in your habits, it’s natural to look for a tangible thing to change. Just picking up one of the thirty unread books you own is not particularly exciting. That’s probably why I went back to my long-held desire for a great e-reader.

Now you must understand that I’ve wanted electronic books since I read a fateful article in 2000 — technically, last century. According to the journalists and scientists in research labs, we would soon have high-resolution, color, flexible e-books. One could only imagine the resulting applications and form-factors!

The first, second, third, fourth and fifth waves of actually marketed products were mightily disappointing: gray, plastic, bulky, low resolution, and plain ugly. Every other year, I would check the e-reader market and realize that the future was a lie. E-readers were my very own flying car fixation.

But in late 2016 it seemed like there was finally something decent on the market: slightly bigger screen (8 inches instead of the ubiquitous 6 inch screens), print-level resolution, and not bulky.

The Kobo Aura One. It doesn’t suck.

I still have big dreams of foldable technicolor e-paper, but I had finally found a e-reader that was close to a paperback’s size and resolution, and I decided that it would be enough for now. Had to wait while it was sold out — turns out I’m not the only one who wanted an e-reader that is not tiny.

As for the device: it’s nice. I won’t bother you with a review, but I like how the user interface is set in Georgia — an unusual and excellent choice — and how the screen and optional back-lighting are easy on the eyes. The bigger, 8-inch format can also work well for some black-and-white graphic novels (those with not-too-dense pages, and most manga).

SIX. You know how buying new gear — a new camera, instrument, etc. — does not come with magical motivation and dedication? Yeah, so I was a bit worried about that.

In any case, I was tired of packing 4 books on vacations (and only touching one of those for a week), or hesitating to load my day bag with a heavy volume. Even if I ended up not reading much, packing just one e-reader instead would be a weight off my shoulders.

I asked a friend for a few book recommendations and she sent me a dozen epubs. I did buy a few books legally too, one without DRM and the rest loaded with the whole DRM shitshow.

In one case, after buying a digital copy of Philippe Jaccottet’s À la lumière d’hiver (which I had bought in paper format twice before), I realized that the book contained a dozen typos and — the horror — straight apostrophes everywhere! I spent hours finding a way to crack the Adobe DRM, so that I could use my HTML-fu and fix that book (and keep it in 10 years when the Adobe DRM servers are down, too).

I started reading books again, mostly during my commute, but also some nights and on vacations. I’m reading roughly one book per month, sometimes two. I’m not pressuring myself to read, it’s just convenient and offers and alternative to other pastimes (and since mine tend to happen on a computer, they’re loaded with distractions, so this one often feels like much-needed time off).

SEVEN. I’ll close this post with a few highlights from 2017:

If I Was Your Girl by Meredith Musso. Beautifully written, and an all too rare occurence: a trans character written by a trans author, in a mostly happy story.
Known Associates, by thingswithwings. I guess if I wanted to start reading fics then a 600 pages novel full of queerness was a good pick? I liked it a bunch.
Uprooted by Naomi Novik. It’s a beautiful and charming fantasy novel, with a serious tone and a lot of character.
And I’m currently finishing Gail Carriger’s Parasol Protectorate series. Not groundbreaking but good fun that made me want to read book after book.
Finally, if you work on Web or digital stuff, you should read Laura Kalbag’s Accessibility for Everyone.

It looks like I’m mostly reading books written by women these days. The only exception this year was Douglas Coupland’s Worst Person Ever (it was plain gimmicky and boring, and its transphobic twist soured me forever on this author).

ReMarkdown.css

2017-12-02T00:00:00+01:00

ReMarkdown — demo pages, npm package — is a stylesheet that renders HTML elements as if they were plain Markdown text.

Project history

ReMarkdown was created in 2011 as a CSS experiment, to see if generated content (::before and ::after pseudo-elements) could be used to create a complete text style. The goal was to write a kind of Markdown-in-reverse, styling standard HTML as if it were plain text with Markdown-like markers.

A v2 in 2014 reworked most of the styles and made the library modular using Sass, allowing custom builds with stylistic variants turned on or off.

Finally, this 2017 update improves the modularity further, and provides 2 default builds so that ReMarkdown styles can be applied with either classes or attributes.

Using ReMarkdown

ReMarkdown now comes in two flavours: class-based or attribute-based. The default flavour uses classes:

<link rel="stylesheet" href="https://unpkg.com/remarkdown.css/dist/remarkdown.css">
<div class="remarkdown">
  <h1>Default styles</h1>
</div>
<div class="remarkdown h1-underline hr-center">
  <h1>With options</h1>
</div>

And the attr flavour uses the data-remarkdown attribute instead:

<link rel="stylesheet" href="https://unpkg.com/remarkdown.css/dist/remarkdown.attr.css">
<div data-remarkdown>
  <h1>Default styles</h1>
</div>
<div data-remarkdown="h1-underline hr-center">
  <h1>With options</h1>
</div>

Both come with a dozen styles enabled by default (which means you only need class="remarkdown" or data-remarkdown on a container element to apply those styles). You can see a full list of styles on this page.

There are also two ReMarkdown-zero builds which have no default styles enabled, letting you pick all the styles you want explicitly:

<link rel="stylesheet" href="https://unpkg.com/remarkdown.css/dist/remarkdown-zero.attr.css">
<div data-remarkdown>
  <h1>Very basic styles, no Markdown markers</h1>
</div>
<div data-remarkdown="
  hn-reset hn-hash h1-underline
  hr-star hr-center
  ul-plus ol-decimal
  code-tick pre-tick
  ">
  <h1>With explicit options</h1>
</div>

If these choices are too limited for your needs, you can also create a custom build of ReMarkdown using Sass. See the “Customizing ReMarkdown” page for instructions.

Using CSS variables in SVG icons

2017-01-24T00:00:00+01:00

When I started looking into SVG some three years ago, I envisioned this language as images separate from the page (like JPEG and PNG images are, unless you base64 them), that you could style, because it’s a document, right?

Except it doesn’t quite work like that. If you keep your SVG image as a separate document, you can’t modify it from the HTML document that calls it. I asked around more than two years ago; at the time there was a draft about SVG Params, and Tab Atkins suggested I look into CSS Variables (because future improvements to SVG styling-from-a-parent-document would probably use those). But CSS Variables were only implemented in Firefox and I didn’t manage to make the most of it.

Well, we now have CSS Variables in Firefox, Chrome and Safari, and coming to an Edge near you sometime in 2017. Plus we have collectively figured out that SVG’s <symbol> and <use> elements were a nice way to use SVG icons from the same HTML page or from an external symbol sprite, so maybe we can put the two together and it’ll just work?!

Quick demo (open in new tab):

In my tests it does work well in Firefox, Chrome and Safari (as long as they support CSS custom properties). Haven’t tried with Edge’s preview yet.

The funny thing is I had totally forgot that this would work. I was sure it wouldn’t for some shadowy Shadow DOM reason, and I actually forgot I had demonstrated it working last year. Duh.

The math of CSS Locks

2016-09-01T00:00:00+02:00

A CSS lock is a Responsive Web Design technique that lets you transition smoothly between two values, depending on the current viewport size, rather than jump straight from one value to the other.

This concept was first demonstrated in 2015 by Mike Riethmuller in “Precise control over responsive typography”, and dubbed “CSS locks” by Tim Brown in “Flexible typography with CSS locks”.

I found this technique in Tim’s article and, when I tried wrapping my head around it, and creating variants of it, I had a hard time figuring out what was going on exactly. I did a lot of back-of-the-envelope calculations, and I thought it would be useful to share a mathematical explanation.

I’ll describe the technique, its limitations, and the math that make it work. But don’t worry about the math: it’s basically addition and multiplication, and I’ve broken down the steps as much as possible—also there will be nice graphs.

What’s a CSS lock?

Viewport-relative sizes

On my latest project I had a hero (full-width) banner with a title on top, and only the “desktop” mock-ups with a big font-size. I figured I wanted smaller text for small screens and something in between for medium screens. So why not make the font-size relative to the viewport width?

Early techniques for that looked like:

h1 { font-size: 4vw; /* Boom! Done. */ }

This has two downsides:

the text gets really small on smaller screens (12.8 pixels at 320px) and really big on bigger screens (64px at 1600px);
it doesn’t follow user preferences for text size.

CSS lock techniques aim to fix the first issue. Great CSS lock techniques will also try to fix the second issue: following user preferences.

The CSS lock concept

A CSS lock is a specific kind of CSS value calculation where:

there is a minimum value and a maximum value,
and two breakpoints (usually based on the viewport width),
and between those breakpoints, the actual value goes linearly from the minimum to the maximum.

“Let’s use a 20px font-size below 320px, a 40px font-size above 960px, and a value going from 20px to 40px in between.”

On the CSS side, this can look like:

h1 { font-size: 1.25rem; }

@media (min-width: 320px) {
  h1 { font-size: /* magic value from 1.25rem to 2.5rem */; }
}

@media (min-width: 960px) {
  h1 { font-size: 2.5rem; }
}

Our first challenge will be to actually implement the magic value. I’m going to spoil the fun a bit and reveal that it will look like this:

h1 {
  font-size: calc(1.25rem + viewport_relative_value);
}

Where viewport_relative_value can be a single value (e.g. 3vw) or a more complex calculation (also based on the vw unit or another viewport unit).

Limitations

Because they’re based on viewport units, CSS locks have important limitations. They only work for values that are numbers, can use calc(), and can accept pixel dimensions.

Why pixel values? Because viewport units (vw, vh, vmin and vmax) always resolve to a pixel value. For instance if the viewport width is 768px, then 1vw resolves to 7.68px.

(As a side note, there is a small error in Tim Brown’s article, where he writes that a calculation like 100vw - 30em results in a em value. It doesn’t: the browser will see 100vw as a pixel value, and will substract how many pixels 30em happen to be for that element and that property.)

Some examples of things that will not work:

a CSS lock for the opacity property, because opacity: calc(.5+1px) is an error;
a CSS lock for most transform functions (e.g. rotate: one can’t rotate by a pixel value).

Okay, so this pixel restriction looks fairly limiting, but maybe some brave souls will go ahead and identify all the properties and techniques that can make use of CSS locks.

To get the fun started, we’ll look at the font-size and line-height properties, and how we can build CSS locks for these with either pixel-based or em-based breakpoints.

CSS locks with pixel breakpoints

The demos

In the next sub-sections, we’ll explain how we arrived at the CSS code for each example.

Font size as a linear function

We want the font-size to grow proportionally between two points: 20px at 320px, and 40px at 960px. On a graph, we can write down our two points and draw a line:

What we’re seeing here in red is a simple linear function. We can write it as y = mx + b, where:

y is our font size (vertical axis),
x is the viewport width, in pixels (horizontal axis),
m is the slope of the function (“how many pixels do we add to the font size for each increase of 1px to the viewport width?”),
and b is the font-size before we add any viewport-based value.

What we would like to do is figure out the respective values of m and b. They’re the parts of the equation that don’t change.

Let’s find the value of m first. All we need is two (x,y) data points. It’s kind of like working out a speed (distance over time), but here it’s font-size over viewport width:

m = font_size_increase / viewport_increase
m = (y2 - y1) / (x2 - x1)
m = (40 - 20) / (960 - 320)
m = 20 / 640
m = 0.03125

Another way to express this calculation is:

The total increase in font-size is 20px (40 - 20). The total increase in viewport width is 640px (960 - 320). If the viewport width was growing by just 1px, how big would the increase in font-size be? It would be 20 / 640 = 0.03125px.

Now let’s calculate b.

y = mx + b
b = y - mx
b = y - 0.03125x

Since both known points verify our function, we can use the (x,y) values from the first or the second point. Let’s take the first one:

b = y1 - 0.03125 × x1
b = 20 - 0.03125 × 320
b = 10

For the record, we could have found this 10px value just by looking at the graph. But we don’t always have a graph ready. :)

Anyway, our complete linear function is:

y = 0.03125x + 10

Translating to CSS

How do we translate our function to CSS syntax? We know that y is the font-size, and that if we want to do basic operations in CSS we need calc().

font-size: calc( 0.03125x + 10px );

Not too bad. Of course it’s pseudo-CSS, because x is not valid CSS syntax. But in our linear function, x represents the viewport width, which can be expressed in CSS as 100vw.

font-size: calc( 0.03125 * 100vw + 10px );

Now this is working CSS. If we want a shorter style, we can resolve that multiplication. Since 0.03125 × 100 = 3.125:

font-size: calc( 3.125vw + 10px );

Of course we want to restrict this style to viewport widths between 320px and 960px. So let’s add some media queries:

h1 { font-size: 20px; }

@media (min-width: 320px) {
  h1 { font-size: calc( 3.125vw + 10px ); }
}

@media (min-width: 960px) {
  h1 { font-size: 40px; }
}

And now our graph looks like the one shown in the introduction.

That’s nice, although I’m not too happy about those pixel values for a font size declaration; can we do better?

Factoring user preferences in

Virtually every web browser lets users ask for smaller or bigger default text. The most common, default value is 16px, but users might change it to anything else (generally to bigger text).

I’d like to introduce this user preference in our formula, and I’m going to use rem values for that purpose. Note that similar principles apply with em or percentage values.

First thing to do is to make sure that the root font-size was not overwritten with an absolute value. For instance, if you’re using Bootstrap 3’s CSS, there’s a bit of code like this:

html {
  font-size: 10px;
}

Do not ever do this! (Thankfully, this will be fixed in Bootstrap 4.) If for any reason you really want to redefine the root em (1rem) value, you could use:

/*
 * Redefine the rem value while keeping it proportional.
 * Useful values, with default font-size of 16px:
 * • 62.5% -> 1rem = 10px, .1rem  = 1px
 * • 125%  -> 1rem = 20px, .05rem = 1px
 */
html {
  font-size: 62.5%;
}

That being said, we’re going to leave the root font-size alone, so that by default it will be equal to 16px. Let’s see what happens if we replace our pixel values with rem values in our font-size lock.

/*
 * With default user settings:
 * • 0.625rem = 10px
 * • 1.25rem  = 20px
 * • 2.5rem   = 40px
 */
h1 { font-size: 1.25rem; }

@media (min-width: 320px) {
  h1 { font-size: calc( 3.125vw + .625rem ); }
}

@media (min-width: 960px) {
  h1 { font-size: 2.5rem; }
}

If we try this code with default browser settings, we can see that it behaves like our previous pixel-based code. Great!

But since we’re doing this to support user changes, we should check how that works too. Say we have a user who configured their browser to use 24px instead of 16px as the default font-size (a 50% increase); how will the above code react? Let’s graph that:

Dotted blue line: with a base font-size of 16px.
Solid red line: with a base font-size of 24px.

At the 320px breakpoint the font size actually becomes smaller (jumping from 30px to 25px), and there’s a big jump at the higher breakpoint (45px to 60px). Woops.

To fix that, we can use the same user-configurable baseline for all 3 sizes. For instance, we could pick a 1.25rem baseline:

h1 { font-size: 1.25rem; }

@media (min-width: 320px) {
  h1 { font-size: calc( 1.25rem + 3.125vw - 10px ); }
}

@media (min-width: 960px) {
  h1 { font-size: calc( 1.25rem + 20px ); }
}

See the 3.125vw - 10px part? It’s our old linear function (of the form mx + b), but with a different value for b; let’s call it b′. In our case, since we know that our baseline value is equivalent to 20px, we can get the b′ value with a simple substraction:

b′ = b - baseline_value
b′ = 10 - 20
b′ = 10

Another strategy is to pick your baseline value before anything else, then look for the linear function that describes the font-size increase (I’m calling it y′ to differentiate it from the complete font-size y). Let’s try that quickly:

x1 = 320
x2 = 960

y′1 = 0
y′2 = 20

m = (y′2 - y′1) / (x2 - x1)
m = (20 - 0) / (960 - 320)
m = 20 / 640
m = 0.03125

b′ = y′ - mx
b′ = y′1 - 0.03125 × x1
b′ = 0 - 0.03125 × 320
b′ = -10

We end up with y′ = 0.03125x - 10, which looks like this:

With our base value in rem and additional sizes in vw and/or px, we finally get a fully working font-size lock. When the user changes their base font-size, the whole thing goes up or down and doesn’t break. Success!

Dashed magenta line: the raw font-size increase.
Dotted blue line: with a base font-size of 16px.
Solid red line: with a base font-size of 24px.

Of course it’s not exactly what the user asked for: they wanted 50% bigger fonts, and we gave them a font size that is 50% bigger on smaller viewports, and only 25% bigger on bigger viewports. But it’s a good compromise nonetheless.

Making a line-height lock

For this part, our scenario is going to be: “We want paragraphs with a 1.4 line-height at 320px and a 1.8 line-height at 960px”.

Since we’ll be working with a base value plus a dynamic value expressed in pixels, we need to know how many pixels those 1.4 and 1.8 ratios refer to. Which means we need to know the font-size of our paragraphs. Let’s say that our paragraphs use the default font-size, so probably 16px. Our data points are:

16 * 1.4 = 22.4 pixels at the lower breakpoint (320px)
16 * 1.8 = 28.8 pixels at the higher breakpoint (960px)

We’ll also use 1.4em = 22.4px as our baseline. So what we are looking at here is an increase of 6.4px. We can work out our linear formula, as before:

x1 = 320
x2 = 960

y′1 = 0
y′2 = 6.4

m = (y′2 - y′1) / (x2 - x1)
m = (6.4 - 0) / (960 - 320)
m = 6.4 / 640
m = 0.01

b′ = y′ - mx
b′ = y′1 - 0.01 × x1
b′ = 0 - 0.01 × 320
b′ = 3.2

y′ = 0.01x - 3.2

Transposing to CSS, we get:

line-height: calc( 1.4em + 1vw - 3.2px );

Important: our baseline value must be expressed as 1.4em inside of calc() expressions; the unitless ratio (1.4) notation won’t work inside calc() (all browsers), and the percent notation (140%) works in Chrome and Firefox but not in Safari.

Then we add media queries, and make sure that all declarations for the line-height value use the same baseline (1.4em).

p { line-height: 1.4em; }

@media (min-width: 320px) {
  p { line-height: calc( 1.4em + 1vw - 3.2px ); }
}

@media (min-width: 960px) {
  p { line-height: calc( 1.4em + 6.4px ); }
}

Reminder: for the high value, we can’t just use 1.8em, because we need the part that is added to our base to be expressed in pixels. If we used 1.8em (or 1.8 or 180%), the result would be alright for a base font size of 16px but would break when the user changed it.

We can graph our function, and check that it does work with a different base font-size.

Dotted blue line: with a base font-size of 16px.
Solid red line: with a base font-size of 24px.

Finally, since our line-height formula depends on the element’s own font-size, if we change that font size we have to change the formula. For instance in our line-height demo there is a paragraph with bigger text, defined like this:

.big {
  font-size: 1.66em;
}

This changes our data points:

16 * 1.66 * 1.4 = 37.184 pixels at the lower breakpoint (320px)
16 * 1.66 * 1.8 = 47.808 pixels at the higher breakpoint (960px)

We can run the calculations and get this updated formula: y′ = 0.0166x - 5.312. Then, combining the previous style and this one in our CSS, we get:

p { line-height: 1.4em; }
.big { font-size: 1.66em; }

@media (min-width: 320px) {
  p    { line-height: calc( 1.4em + 1vw - 3.2px ); }
  .big { line-height: calc( 1.4em + 1.66vw - 5.312px ); }
}

@media (min-width: 960px) {
  p    { line-height: calc( 1.4em + 6.4px ); }
  .big { line-height: calc( 1.4em + 10.624px ); }
}

Another option is to let CSS do the calculations. Since we’re using the same breakpoints and relative line-heights as for standard paragraphs, we just need to add a 1.66 factor:

p { line-height: 1.4em; }
.big { font-size: 1.66em; }

@media (min-width: 320px) {
  p    { line-height: calc( 1.4em + 1vw - 3.2px ); }
  .big { line-height: calc( 1.4em + (1vw - 3.2px) * 1.66 ); }
}
@media (min-width: 960px) {
  p    { line-height: calc( 1.4em + 6.4px ); }
  .big { line-height: calc( 1.4em + 6.4px * 1.66 ); }
}

Combining font-size and line-height locks

Okay let’s try to put it all together. Here’s our scenario: we have a fluid column of text with a H1 and a few paragraphs, and we’re going to change the font-size and line-height using the following values:

Element and property	Value at 320px	Value at 960px
H1 font-size	24px	40px
H1 line-height	1.33em	1.2em
P font-size	15px	18px
P line-height	1.5em	1.66em

You’ll notice that we’re doing two different things with the line heights. As a general rule, when text becomes bigger we should make the line-height tighter, and when a column becomes wider we should make the line-height more loose. But in our scenario, both principles apply at the same time and contradict each other! So we have to make a prioritize one aspect over the other:

For the H1, we feel that the font-size increase will be more dramatic than the column width increase.
For the paragraphs, we feel that the column width increase will be more dramatic than the subtle font-size increase.

Now, let’s pick two breakpoints. I’ll go with 320px and 960px again, yay. Let’s start by writing the font-size locks:

h1 { font-size: 1.5rem; }
/* .9375rem = 15px with default settings */
p { font-size: .9375rem; }

@media (min-width: 320px) {
  h1 { font-size: calc( 1.5rem + 2.5vw - 8px ); }
  /* .46875vw - 1.5px results in a value from 0 to 3px */
  p { font-size: calc( .9375rem + .46875vw - 1.5px ); }
}
@media (min-width: 960px) {
  h1 { font-size: calc(1.5rem + 16px); }
  p { font-size: calc( .9375rem + 3px ); }
}

Nothing new here, except for the different values.

Next, calculating the line-height locks is going to get a bit harder than what we did last time.

Let’s begin with our H1 element. We’d like to use a relative baseline value for the line-height, so we take the lowest value, 1.2em. Since the element’s font size is variable, that 1.2em is going to describe a dynamic and linear value, characterized by two points:

24 × 1.2 = 28.8px at the lower breakpoint,
40 × 1.2 = 48px at the higher breakpoint.

We also know that at the lower breakpoint, we want the line-height to be 1.33em, which we can round to just 32px.

We would like to find a linear function that describes “what we add to the 1.20em baseline”. If we remove this 1.2em baseline from our data points, we have two modified data points:

24 × (1.3333 - 1.2) = 3.2px at the lower breakpoint,
40 × (1.2 - 1.2) = 0px at the higher breakpoint.

We should end up with a negative slope. Let’s calculate that.

m = (y′2 - y′1) / (x2 - x1)
m = (0 - 3.2) / (960 - 320)
m = -3.2 / 640
m = -0.005

b′ = y′ - mx
b′ = y′1 - (-0.005 × x1)
b′ = 3.2 + 0.005 × 320
b′ = 4.8

y′ = -0.005x + 4.8

Transposed to CSS, we get:

h1 {
  line-height: calc( 1.2em - .5vw + 4.8px );
}

Let’s look at our function on a graph, and see how it relates to the related font-size function.

Dotted blue line: the line-height decrease.
Dashed red line: our line-height baseline (120% of the title’s font-size).
Solid magenta line: the final line-height.

Looking at this graph, we can see that the final line-height (magenta line) is equal to the 120% baseline (red dashes) plus the line-height decrease (blue dots). You can look at these equations on GraphSketch.com and check for yourself.

For the paragraphs, we’re going to use 1.5em as our baseline. The line-height increase we want is: (1.75 - 1.5) × 18 = 4.5px.

My calculator tells me that the formula is:
y′ = 0.00703125x - 2.25

To see the complete CSS code, look at the combined font-size plus line-height demo and its source. While resizing the browser’s window, you should see that the effect is subtle but is definitively working.

I also recommend that you test this demo after changing your browser’s base font size. Note that in that situation the exact line-height ratios are slightly different, but they still look alright; and there’s no danger of the line-height becoming smaller than the baseline value.

Automating the calculations

Throughout this part I’ve been doing all the calculations by hand or using a calculator such as Soulver.

But this process can be tedious and error-prone. Could we automate it, to reduce the chance of human error?

Our first option would be to do the whole calculation in CSS. This is a variant of the formula we’ve used in our font-size examples, with all the values spelled out:

@media (min-width: 320px) and (max-width: 959px) {
  h1 {
    font-size: calc(
      /* y1 */
      1.5rem
      /* + m × x */
      + ((40 - 24) / (960 - 320)) * 100vw
      /* - m × x1 */
      - ((40 - 24) / (960 - 320)) * 320px
    );
  }
}

That’s a bit verbose, and can be reduced further to:

@media (min-width: 320px) and (max-width: 959px) {
  h1 {
    font-size: calc( 1.5rem + 16 * (100vw - 320px) / (960 - 320) );
  }
}

This works for a combined font-size and line-height, too, but it might be less intuitive, especially with a negative slope.

@media (min-width: 320px) and (max-width: 959px) {
  h1 {
    font-size: calc( 1.5rem + 16 * (100vw - 320px) / (960 - 320) );
    /* For a negative slope, we have to invert the breakpoints */
    line-height: calc( 1.2em + 3.2 * (100vw - 960px) / (320 - 960) );
  }
}

Our second option would be to automate these calculations with a Sass mixin or a PostCSS plugin. Sadly I don’t have one to offer right now, but if you’re taking a shot at it let me know and I’ll add it to this article.

CSS locks with em breakpoints

The demos, reloaded

I’ve taken our first 3 demos and ported them from px-based breakpoints and value increments to em-based breakpoints and rem-based value increments.

In the next sub-sections we’ll describe how the specific syntax used for these demos works.

Don’t use `em` media queries with `m × 100vw`

Remember the m × 100vw syntax we used in section II (for instance in code looking like calc(base + 2.5vw))? We can’t use that with em-based media queries.

This is because in the context of a media query, both the em and the rem unit refer to one thing: the User Agent’s base font size. Which is — as we’ve said a few times already in this article — usually 16px, but it might be smaller or bigger depending on two things:

Browser or OS choices (mostly for special cases like TV browsers, and some e-readers).
User preference.

This means that if we have two breakpoints at 20em and 60em, the actual CSS widths at which they will match are:

320px and 960px for a base font size of 16px,
480px and 1440px for a base font size of 24px,
etc.

(Note that these are CSS pixels, and not device pixels. We’re not concerned with device pixels in this article as they don’t impact our calculations.)

In section II, we had examples looking like this:

font-size: calc( 3.125vw + .625rem );

If we take this syntax and replace all breakpoints with em-based breakpoints, by supposing that 1em in a media query is 16px, we could have code like this:

h1 { font-size: 1.25rem; }

/* Don’t do this :((( */
@media (min-width: 20em) {
  h1 { font-size: calc( 1.25rem + 3.125vw - 10px ); }
}

/* Or this. */
@media (min-width: 60em) {
  h1 { font-size: calc( 1.25rem + 20px ); }
}

This would indeed work if the operating system, browser and user never changed the base font size. But if for any reason it was different, mayhem would ensue.

Dotted blue line: result with a base font size of 16px.
Solid red line: result with a base font size of 24px.

What’s happening here? When we change the base font-size, our em-based breakpoints move to bigger pixel values. Our 3.125vw - 10px value is only true for specific pixel breakpoints, though!

At 320px, 3.125vw - 10px is 0px, as planned.
At 480px, on the other hand, 3.125vw - 10px is 5px.

Things get worse at the higher breakpoint:

At 960px, 3.125vw - 10px is 20px, is expected.
At 1440px, 3.125vw - 10px is 35px (15px too big).

If we want to use em-based breakpoints, we’re going to need a different technique.

Doing the math again

This technique, demonstrated in Mike Riethmuller’s article, relies on letting CSS do much of the calculation, using two variable parts:

100vw, the viewport width;
the lower breakpoint, expressed in rem.

The formula we’re going to use is:

y = m × (x - x1) / (x2 - x1)

How do we end up with this formula? Let’s retrace our steps a bit. In section II we showed that our font-size or line-height could be described as a linear function:

y = mx + b

In CSS, we can work with x (that’s 100vw). But we can’t resolve m and b to precise px or a vw values, because those are fixed pixel quantities and they would end up mismatched with our em-based breakpoints if the user ever changed the base font size.

So what we want is to see if we can replace m and b with other known values, namely our two data points, (x1,y1) and (x2,y2).

We already showed how to find b from one point in the function:

b = y - mx
b = y1 - m × x1

Putting the two together:

y = mx + b
y = mx + y1 - m × x1

We’ve eliminated b from the equation, yay!

Also, in section II we showed that what we really needed was not the complete font-size or line-height value, but the dynamic part that we add to a baseline value. We called that dynamic part y′, and we can express it as:

y  = y1 + y′
y′ = y - y1

Replacing y with the equation we found just before:

y′ = mx + y1 - m × x1 - y1
y′ = mx + y1 - m × x1 - y1

Hey look, we can eliminate the + y1 - y1 parts!

y′ = m × x - m × x1
y′ = m × (x - x1)

This is going really well. Now, can we replace m with values we actually know? We showed earlier that:

m = (y2 - y1) / (x2 - x1)

So:

y′ = (y2 - y1) / (x2 - x1) × (x - x1)

Which we can also write as:

y′ = max_value_increase × (x - x1) / (x2 - x1)

Translating to CSS

Now that’s a value we can use in CSS. Going back to our 20px-to-40px example, we could write it down as:

@media (min-width: 20em) and (max-width: 60em) {
  h1 {
    /* WARNING: this doesn’t work yet! */
    font-size: calc(
      1.25rem /* baseline value */
      + 20px /* difference between max value and baseline */
      * (100vw - 20rem) /* x - x1 */
      / (60rem - 20rem) /* x2 - x1 */
    );
  }
}

This code doesn’t work yet. It looks like it might work, but calc() in CSS has a number of restrictions when it comes to how you can do multiplications and divisions with the same or with different values.

Let’s start with the 100vw - 20rem fragment; this part works as is, and will return a pixel value.

For instance if the base font-size is 16px and the viewport width is 600px, the result will be 280px (600 - 20 × 15). If the base font-size is 24px and the viewport width is 600px, the result will be 120px (600 - 20 × 24).

Note that is that we’re using the rem unit to express our breakpoints. Why not em, you ask? Because in a CSS value, em will not refer to the base font-size, but instead it refers to the element’s own font-size (generally) or to its parent font-size (when used in the font-size property).

Ideally, we would need a CSS unit that refers to the browser’s base font-size, but this unit doesn’t exist. The closest we have is rem, and it will only refer to that base font-size if it was left completely unchanged.

That means you must make sure you don’t have code like this in your CSS:

/* Bad */
html { font-size: 10px; }

/* Equally bad */
:root { font-size: 16px; }

/* Manageable, but we'll have to write all
   our breakpoints as e.g. 20rem/1.25,
   40em/1.25, etc. */
:root { font-size: 125%; }

Things get a bit more complicated on the other side of the division.

Unitless `calc` divisors and factors

Ideally, we would like the 60rem - 20rem part to resolve to a pixel width. This would mean that the whole (x - x1) / (x2 - x1) division would resolve to a value between 0 and 1. Let’s call this value n.

For instance, with a base font-size of 16px and a viewport width width of 600px, we would get:

n = (x - x1) / (x2 - x1)
n = (600 - 320) / (960 - 320)
n = 280 / 640
n = 0.475

Sadly, it doesn’t quite work like that.

The main reason is that you can’t use pixels, or any CSS unit, for the divisor of a calc() division. (The divisor is the part on the right. Don’t worry if you didn’t remember that from school, I had to look it up.) You can only divide by a unitless value. So what are our options here?

What if we just remove the units in the divisor? What would be the result of calc((100vw - 20rem)/(60 - 20))?

Given a base font-size of 16px
Viewport width	CSS division	Result
20em (320px)	(320px - 16px × 20) / (60 - 20)	= 0px
40em (640px)	(640px - 16px × 20) / (60 - 20)	= 8px
60em (960px)	(960px - 16px × 20) / (60 - 20)	= 16px

Given a base font-size of 24px
Viewport width	CSS division	Result
20em (480px)	(480px - 24px × 20) / (60 - 20)	= 0px
40em (960px)	(960px - 24px × 20) / (60 - 20)	= 12px
60em (1440px)	(1440px - 24px × 20) / (60 - 20)	= 24px

As you’ll notice, when we stay within our breakpoints (20em to 60em), we get a value going linearly between 0rem and 1rem. We can use that!

Next up is the 20px factor we had used in our first attempt at making the CSS work. We will need to scratch that.

Our first attempt tried to achieve this kind of code:

font-size: calc( 1.25rem + 20px * n );

Where n was meant to be a value between 0 and 1. But because of the syntax restrictions for calc() divisions, we couldn’t get that 0-to-1 result we wanted.

What we did manage to get was a pixel value equivalent to 0rem and 1rem; let’s call this value r.

Another restriction affects calc() multiplications. When writing calc(a * b), either a or b should be a unitless number.

Since r already has a unit (it’s a pixel value), the other factor should be unitless.

In our example, we want a 20px increase at the higher breakpoint. 20px is 1.25rem, so we will use a 1.25 factor:

font-size: calc( 1.25rem + 1.25 * r );

This should work well, but note that the r value will change depending on the base font-size.

With a 16px base, 1.25 * r will be a value between 0px and 20px.
With a 24px base, 1.25 * r will be a value between 0px and 30px.

Let’s write the whole CSS lock, with the media queries and the low and high values:

h1 {
  font-size: 1.25rem;
}

@media (min-width: 20em) {
  /* The (100vw - 20rem) / (60 - 20) part
     resolves to 0-1rem, depending on the
     viewport width (between 20em and 60em). */
  h1 {
    font-size: calc( 1.25rem + 1.25 * (100vw - 20rem) / (60 - 20) );
  }
}

@media (min-width: 60em) {
  /* The right part of the addition *must* be a
     rem value. In this example we *could* change
     the whole declaration to font-size:2.5rem,
     but if our basline value was not expressed
     in rem we would have to use calc. */
  h1 {
    font-size: calc( 1.25rem + 1.25 * 1rem );
  }
}

Unlike the px-based font-size lock, this time when the user increases the base font-size by 50% everything gets a 50% increase: the baseline value, the variable part and the breakpoints. We get a 30px–60px range, instead of the default 20px–40px range.

Dotted blue line: result with a base font size of 16px.
Solid red line: result with a base font size of 24px.

You can check this behavior in our first em-based demo.

Line-height locks with `em`/`rem`

In our second demo, we want to change a paragraph’s line-height from 1.4 to 1.8. We’re using 1.4em as our base value, and for the variable part we use the same formula as in the font-size example.

p {
  line-height: 1.4em;
}
@media (min-width: 20em) {
  p {
    line-height: calc( 1.4em + .4 * (100vw - 20rem) / (60 - 20) );
  }
}
@media (min-width: 60em) {
  p {
    line-height: calc( 1.4em + .4 * 1rem );
  }
}

For the variable part of our line-height, we know that we want a rem value, because (100vw - 20rem) / (60 - 20) will result in a pixel value between 0rem and 1rem.

Since our paragraph’s font-size stays at 1rem, the 0.4em line-height increase we’re looking for is equivalent to .4rem. So that’s the value we use in our two calc() expressions.

Now let’s take a line-height example from our third demo. We want the H1’s line-height to decrease from 1.33 to 1.2. We also know that its font-size will change at the same time.

For that same example in section II, we had determined that the line-height decrease could be expressed by two data points:

24 × (1.3333 - 1.2) = 3.2px at the lower breakpoint,
40 × (1.2 - 1.2) = 0px at the higher breakpoint.

So we’re using a 1.2em base value, and a variable part from 3.2px to 0px. With a base font size of 16px, 3.2px is 0.2rem, so we’re going to use a .2 factor.

Finally, since we need the variable part to be zero at the higher breakpoint, we will need to invert the breakpoints in the formula:

h1 {
  line-height: calc( 1.2em + 0.2 * 1rem );
}
@media (min-width: 20em) {
  h1 {
    line-height: calc( 1.2em + 0.2 * (100vw - 60rem) / (20 - 60) );
  }
}
@media (min-width: 60em) {
  h1 {
    line-height: 1.2em;
  }
}

Two things to note here:

The .2rem value is only correct if we also have a font-size lock going from 24px to 40px. (It’s not shown here but you can see it in the demo source.)
Since we’re inverting the breakpoint values, for all viewport widths below 60em and at or above 20em, both sides of the (100vw - 60rem) / (20 - 60) division will be negative. For instance, at the lower breakpoint and with a base font size of 16px, it’s equivalent to -640px / -40. And since dividing two negative values resolves to a positive value, we don’t need to change the sign before our 0.2 factor.

Compatibility notes

IE and Edge

While developing the examples for this article, I routinely ran tests in Firefox and Chrome, and occasionally on Safari (Desktop). Sadly I must admit that Internet Explorer compatibility was never a target of main, and I fully expect IE 9 at least to find issues with complex calc() expressions.

I would still like to report on Edge and IE 11 compatibility, but have not yet found the time to do so.

Line-height base value

For line-height: calc(…) declarations, the base value should always be expressed in em, like this:

line-height: calc(1.4em + /* vw-based value */);

With CSS, you can express line-height: 1.4em in two equivalent ways: 1.4 (unitless ratio) or 140%. However, in our calc() expressions, it turns out that:

Firefox and Chrome accept 1.4em and 140%, but don’t understand 1.4;
Safari only accepts 1.4em, and doesn’t understand the other two.

Safari and window resize

In my tests, Safari 10 on macOS didn’t always update the calc() values when resizing the window or when using the Responsive Design Mode.

It seems to be an on-and-off problem. Sometimes the calc() values react to viewport changes instantly, and sometimes they need a full page refresh. If this is related to the exact code used, e.g. to the type of values used in calc(), I haven’t been able to pinpoint the precise issue.

Conclusion

A brief summary of our findings. We’ve shown two CSS lock forms:

for properties which can use dimensions,
with font-size and line-height examples,
and for either pixel-based or em-based breakpoints.

The type of breakpoint you use is a major condition. In most web projects you will want to use the same breakpoints for, say, a font-size lock, and for layout changes. Depending on your project or coding style, your breakpoints may use pixel values or em values. (I tend to prefer pixel-based breakpoints, but both have their merits. As a reminder, if you’re using em-based media queries, you should avoid pixel dimensions when sizing containers.)

With em-based media queries, the root element’s font-size should not be overriden, and you can only use one CSS lock form:

@media (min-width: 20em) and (max-width: 60em) {
  selector {
    property: calc(
      baseline_value +
      multiplier *
      (100vw - 20rem) / (60 - 20)
    );
  }
}

Where multiplier is the expected total value increase in rem, without the unit. (For example: 0.75 for a 0.75rem maximum increase.)

When using pixel-based media queries, you can override the root element’s font-size (though, if you do it, I recommend using a percentage value), and you may use two different CSS lock forms. The first one is similar to the the em/rem lock, but with pixel values:

@media (min-width: 320px) and (max-width: 960px) {
  selector {
    property: calc(
      baseline_value +
      multiplier *
      (100vw - 320px) / (960 - 320)
    );
  }
}

Where multiplier is the expected total value increase in px, without the unit. (For example: 12 for a 12px maximum increase.)

The second form doesn’t rely on the browser as much to resolve the equation; instead we calculate everything we can ourselves before feeding the values to the browser:

@media (min-width: 320px) and (max-width: 960px) {
  selector {
    property: calc(
      baseline_value + 0.25vw - 10px;
    );
  }
}

Where the 0.25vw and -10px values are calculated beforehand, perhaps thanks to a Sass or PostCSS mixin.

This last form might be a bit harder to get right (unless we’re using a good mixin), but it can make style inspection and debugging easier—as it is more obvious what values we’re adding.

CSS Selector Wars (KiwiParty 2016)

2016-07-01T00:00:00+02:00

Voici le support de présentation de ma conférence à la KiwiParty 2016 à Strasbourg. On y parle de stratégie pour gérer ses styles CSS sans provoquer des conflits dans tous les sens, avec différentes possibilités:

les conventions de nommage (BEM, par exemple)
l’approche en CSS atomiques
les espaces de nom automatiques, avec CSS Modules

Vous pouvez voir le support complet:

La vie sans jQuery

2016-05-30T00:00:00+02:00

Je voudrais discuter de comment et pourquoi sortir du jQuery par défaut sur les projets web. Pour une fois je vais tenter d’écrire un article en français et court¹.

Pour résumer mon opinion: il n’y a pas d’urgence à sortir jQuery de vos projets, et dans certains cas ça peut même être une mauvaise décision. Mais apprendre à faire sans, c’est un bon moyen pour mieux se familiariser avec JavaScript et les fonctionnalités natives des navigateurs, y compris les plus récentes (DOM4).

jQuery partout

W3Techs estime que jQuery est utilisé sur 70% des sites web. C’est gigantesque! En bientôt 10 ans depuis sa première version à l’été 2006, jQuery est devenu incontournable. Chez Kaliop, comme chez mes précédents employeurs et dans la plupart de mes projets en freelance, la question se pose rarement: on met la dernière version de jQuery — ou un fichier copié du dernier projet — vers le début de l’intégration et voilà.

La popularité de jQuery est largement méritée:

c’est un projet mature, stable et activement maintenu;
avec une API succinte et plutôt intuitive;
qui résoud aussi quelques problèmes de compatibilité.

Le mécanisme de plugins a aussi fortement contribué à son succès.

Pour autant, jQuery n’est pas magique. Tout ce que fait jQuery, vous pouvez le faire directement en utilisant les APIs natives du navigateur, en particulier le DOM. Quelques exemples pas strictement équivalents mais proches:

// Avec jQuery
var header = jQuery('.header');
header.on('click', function(event){ … });

// DOM natif
var header = document.querySelector('.header');
header.addEventListener('click', function(event){ … });

Petite pause vocabulaire

Dans cet article je parle de JavaScript, de jQuery, de DOM et d’API, alors on va essayer de définir tout ça viteuf, parce que c’est pas pareil.

JavaScript: un langage de programmation, qui est le langage de programmation utilisable dans un navigateur Web². JavaScript a une syntaxe, avec des variables, des fonctions, des objets, etc. Avec cette syntaxe on peut faire deux-trois trucs, mais dès qu’on veut sortir de la boite où tourne le moteur JavaScript, par exemple pour modifier des éléments sur la page ou envoyer une requête HTTP, il faut utiliser des… APIs.

API: pour Application Programming Interface, ce qui se traduit en français par «ensemble de fonctions pour faire des trucs avec des machins». Dans les navigateurs on trouve plein d’APIs pour faire plein de trucs avec plein de machins (des requêtes HTTP, des connexions en peer-to-peer, modifier des flux audio pour faire un synthétiseur dans ton navigateur, etc.). Et pour utiliser ces APIs on écrit du code en… JavaScript.

DOM: le Document Object Model c’est un ensemble de spécifications qui décrivent une API (eh oui) qui permet de faire des trucs avec un document HTML ou XML. Par exemple «lire» le contenu de ce document, écrire dedans, créer des éléments HTML, les injecter dans la page, modifier des attributs, etc. JavaScript tout seul ne peut pas faire ça, il a besoin du DOM. Ah oui, et dans les spécifications du DOM il y a aussi DOM Events, qui décrit un mécanisme d’évènements («l’utilisateur clique quelque part dans la page, paf ça fait un évènement, tu peux écouter cet évènement et y réagir si tu veux»).

jQuery: c’est un gros script écrit en JavaScript et qui fournit une API (la doc est sur api.jquery.com, d’ailleurs) pour faire des trucs avec un document HTML. Plus deux ou trois autres fonctionnalités utiles, comme des utilitaires pour faire des requêtes HTTP (vous connaissez peut-être sous le nom de «Ajax», sans lien de parenté avec le héros grec ou la lessive).

Et un peu d’histoire

Là comme ça, on dirait que jQuery fait la même chose que le DOM, et donc que ses créateurs se sont emmerdés à réinventer la roue. En fait ça s’est passé un peu différemment.

À l’époque de la création de jQuery, le DOM avait un nombre de fonctionnalités limitées et était, pour tout dire, assez chiant à utiliser. Il fallait écrire beaucoup de lignes de code pour faire pas grand chose. Sans parler des trucs possibles mais trop difficiles à faire.

Dev: Salut le DOM, je peux avoir tous les éléments qui ont la classe «machin»? DOM: Hmmm c’est compliqué. Dev: Mais c’est possible ou pas? DOM: Oui mais il faut faire ça d’abord, et puis ça, et enfin ça. Dev: Punaise… et sinon pour ajouter un élément juste après celui-ci, je fais comment? DOM: Tu veux pas le mettre avant, plutôt? Dev: Euh non je voudrais le mettre après. DOM: Moi j’ai juste appris à mettre des éléments avant, je sais pas les mettre après. C’est peut-être faisable en trois étapes, faut voir.

Pour corser le tout, les spécifications du DOM n’étaient pas complètement implémentées dans les navigateurs, et notamment dans Internet Explorer qui faisait une partie des trucs à sa sauce. Donc il fallait parfois écrire des fonctions qui faisent une chose dans Internet Explorer, une autre dans les autres navigateurs, pour obtenir le même résultat final.

Les projets comme Prototype, MooTools et jQuery avaient donc pour but de corriger ces différences en proposant une seule manière de faire (la leur), et aussi de faciliter l’utilisation du DOM.

Dev: jQuery, jpeux avoir les éléments avec la classe «machin»? jQuery: Bien sûr, les voilà. Dev: Cool. Et pour ajouter un élément juste après celui-ci, ça se fait en 3 étapes c’est ça? jQuery: Ouais mais je m’en occupe, tkt.

Mais alors, pourquoi faire sans?

Il y a quand même quelques bonnes raisons de se passer de jQuery, en particulier sur de petits projets qui n’ont pas des dizaines ou centaines de fonctionnalités JavaScript.

Parce que ça pèse lourd, mine de rien

Je me souviens des premières versions de jQuery, qui faisaient dans les 50 Ko avec minification. Aujourd’hui, jQuery 1.12 fait 97 Ko minifié, et jQuery 2.2 fait 85 Ko (idem pour jQuery 3.0).

Ça n’est pas excessif vu les fonctionnalités apportées, mais encore faut-il en faire réellement usage. Si c’est pour écrire 100 lignes de code maison à tout casser, ça commence à couter cher. Et comme il s’agit de JavaScript, il faut aussi compter le temps d’analyse et d’exécution de ce code (il n’est pas anodin, en particulier sur des mobiles peu performants).

Parce que jQuery bloque l’apprentissage

C’est le plus gros problème que je vois avec jQuery. Beaucoup de gens qui ont besoin de faire du JavaScript dans leur métier ne savent pas coder en JavaScript, et ne connaissent pas le DOM; iels³ ont appris à faire du jQuery (et pas toujours bien). Quand iels se retrouvent sur un projet sans jQuery, iels sont bloqués.

Si vous connaissez jQuery mais que vous ne savez pas expliquer la différence entre ces trois variables:

var test1 = $('.test');
var test2 = $('.test')[0];
var test3 = document.querySelector('.test');

… alors il vous manque la compréhension de concepts essentiels concernant jQuery, le DOM, et même la syntaxe JavaScript. Ce n’est pas un reproche, mais ça vous limite.

De plus, jQuery n’est pas une abstraction parfaite au dessus du DOM, qui permettrait de s’en passer totalement. Il y a plusieurs cas de figure où des méthodes de jQuery exposent des éléments du DOM plutôt que des objets jQuery:

var items = $('.something li'); // objet jQuery
items.on('click', function(event) {
    console.log(this); // objet HTMLLIElement
});
items.each(function(index, element){
    console.log(element); // objet HTMLLIElement
});

Pour pouvoir continuer à travailler uniquement avec les méthodes de jQuery, il faut donc re-fabriquer un objet jQuery avec ces éléments:

$('.something li').each(function(index, element){
    element = $(element);
});

Et comme les développeurs/ses³ ne savent souvent pas quelle est la différence exacte entre un objet jQuery et un objet du DOM, iels se retrouvent souvent avec des messages d’erreur du type TypeError: element.attr is not a function, et rajoutent des $() autour de leurs variables à tour de bras, même quand ce n’est pas du tout nécessaire.

Mais produire du code JavaScript+jQuery mal optimisé, ce n’est pas si grave. Le principal problème à mon sens c’est qu’on en arrive à ne pas savoir faire sans jQuery, à ne jamais avoir appris les bases du DOM ou des bases de JavaScript un peu solides. Avec quelques conséquences:

Si vous avez écrit du code théoriquement réutilisable sur d’autres projets, mais que ces projets n’utilisent pas jQuery… votre code n’est pas réutilisable.
Si un projet n’utilise pas jQuery, vous n’êtes plus capable d’intervenir dessus.

Petite anecdote: un projet en mode maintenance, datant d’il y a quelques années, utilisait MooTools (un concurrent de jQuery). Un-e développeur/se junior à qui on avait confié la réalisation d’une nouvelle fonctionnalité ne savait pas faire sans jQuery. Iel a donc rajouté jQuery (non minifié, sinon c’est moins drôle) dans le projet, et codé la fonctionnalité JavaScript demandée. Avec pour conséquence: 250 Ko de plus chargé par page, et toutes les autres fonctionnalités JS du site plantées à cause de conflits entre jQuery et MooTools.

Parce que le DOM natif s’est quand même bien amélioré

D’une part, IE8 puis IE9 ont enfin corrigé les grosses différences d’implémentation des standards (la création de gestionnaires d’évènements avec addEventListener par exemple).

D’autre part, voyant que personne n’utilisait le DOM directement car c’est trop relou, quelques améliorations bienvenues sont apparues dans les spécifications DOM:

document.querySelector et document.querySelectorAll (IE8+) pour sélectionner un ou plusieurs éléments.
element.insertAdjacentHTML (qui date de IE4 et a été standardisé ensuite).
element.classList (IE10+) qui permet d’ajouter et supprimer des classes facilement.
Et dans les spécifications DOM récentes (parfois appelées “DOM4”), les méthodes prepend, append, before, after, replaceWith, remove; document.query et document.queryAll qui améliorent quelques aspects de querySelector[All]; element.matches, element.contains, element.closest qui ressemblent beaucoup à certaines méthodes de jQuery.

Le dernier lot d’améliorations (“DOM4”) est assez récent et pas encore implémenté partout, mais il existe des polyfills plutôt légers.

Ces améliorations rendent envisageables l’utilisation de l’API DOM standard sans passer par un utilitaire un peu lourd comme jQuery (et sans s’arracher les cheveux).

Pour manipuler le DOM le plus tôt possible

Pour certaines fonctionnalités JS, mieux vaut pouvoir modifier le DOM quasi-instantanément, plutôt qu’attendre le chargement d’un gros fichier externe contenant jQuery, d’autres libs et vos scripts.

Sur certains projets, nous avons par exemple des petits scripts qui font 1, 2 ou 3 Ko minifiés, et qui sont inclus intégralement juste après les contenus HTML, et avant l’appel de jQuery ou d’autres scripts.

Il ne faut pas en abuser, mais ça peut être un bon moyen pour optimiser les performances perçues par l’utilisateur, ou éviter les demandes de clients qui trouvent que tel ou tel contenu affiché intégralement le temps que JS charge c’est innacceptable.

Pour essayer!

Si vous n’avez jamais codé sans jQuery, ou si vous l’avez fait uniquement au milieu des années 2000, ça vaut le coup d’essayer. Vous apprendrez au passage le fonctionnement du DOM natif, améliorerez sans doute votre compréhension de la syntaxe JavaScript, et comprendrez mieux ce que fait jQuery.

Sans les m… euh sans jQuery

Bon alors, comment faire pour se passer de jQuery sur un projet? Voici quelques approches intéressantes.

Le DOM natif compatible IE10+

Si vous pouvez laisser de côté le support d’IE9, pas mal de fonctionnalités DOM natives sont disponibles sans avoir à charger de lib ou de polyfill. Notamment: addEventListener, querySelector, et classList. Avec les fonctionnalités DOM plus classiques, setAttribute appendChild, innerHTML, textContent et insertAdjacentHTML, vous avez de quoi manipuler des éléments dans la page sans trop de souci.

Sur un tout petit projet, je vous recommande vraiment cette approche, qui vous aidera à consolider vos connaissances.

DOM4 avec un polyfill

Si vos besoins dépassent les choses les plus simples, les méthodes du standard DOM4 permettent de se rapprocher un peu de la facilité d’utilisation de jQuery et consors.

Deux exemples avec les méthodes DOM4:

// Contrairement à querySelectorAll qui retourne une NodeList,
// queryAll retourne un Array, ce qui facilite les boucles
document.queryAll('nav a').forEach(function(element) {
  // Faire quelque chose avec chaque lien
})

// element.closest('a') retourne l’élément lui-même si c’est
// un lien, ou son plus proche ancêtre qui est un lien. Cela
// permet de faire de la délégation d’évènement à la mano.
document.query('nav').addEventListener('click', function(ev) {
  var link = ev.target.closest('a')
  if (link) {
    // Faire quelque chose avec le lien cliqué
  }
})

Pour utiliser ces méthodes dans tous les navigateurs, on pourra se reposer sur ce polyfill (IE9+ et 10 Ko minifiés, pas mal du tout).

DOM4 et un peu plus avec Bliss

Bliss, créé par Lea Verou, est une alternative à jQuery qui repose sur les méthodes natives du DOM et quelques polyfills pour les navigateurs qui en ont besoin. Ce projet s’inspire parfois de jQuery pour certaines méthodes, mais dès que possible il conseille d’utiliser la syntaxe DOM native. C’est donc un beau projet pour apprendre le DOM moderne.

De plus lorqu’on consulte la documentation on peut cliquer les boutons Show Implementation pour voir le code correspondant à une méthode.

Les jQuery-like

Certaines libs réimplémentent l’API de jQuery en plus léger, en général en visant seulement la compatibilité avec les navigateurs récents. Par exemple Zepto.js, qui est un des projets les plus complets, vise IE10+. La syntaxe proposée est exactement la même que celle de jQuery, car c’est un projet créé pour remplacer jQuery complètement sur mobile. Certains plugins jQuery sont d’ailleurs testés pour fonctionner également avec Zepto.

Ce n’est pas une approche que je recommande, car elle pose les mêmes problèmes de limitation dans l’apprentissage du JavaScript et du DOM.

Une note sur les requêtes HTTP

Alors on va arrêter de parler d’«Ajax» parce que ce nom est stupide, et que si vous faites du code pour le Web il est temps d’apprendre à connaitre les bases de HTTP, ce qu’est une requête HTTP et une réponse HTTP. Utilisez l’onglet «Réseau» de vos devtools préférés et inspectez un peu quelques requêtes et réponses pour vous familiariser avec tout ça.

L’API classique pour faire des requêtes HTTP en JavaScript se nomme XMLHttpRequest, et vous pouvez en apprendre plus sur les requêtes HTTP en JavaScript par ici (en anglais, car je n’ai pas trouvé d’article correct en français).

jQuery fournit des méthodes pour faire des requêtes HTTP, nommées jQuery.ajax(), jQuery.get() et jQuery.getJSON(). Donc si on se passe de jQuery, il faut soit utiliser XMLHttpRequest soi-même, soit utiliser un petit utilitaire qui facilite son utilisation.

Si vous choisissez Bliss ou une autre lib légère concurrente de jQuery, vérifiez ce qu’elle propose pour les requêtes HTTP (Bliss a une méthode Bliss.fetch, par exemple).

Autre option intéressante: utiliser le nouveau standard fetch() (Can I Use), avec un polyfill tel que github/fetch (IE10+).

Mini retour d’expérience

Sur un projet récent, j’ai donc fait uniquement du JavaScript sans jQuery. J’ai utilisé:

WebReflection/dom4, tip top.
github/fetch, ce qui marchait très bien mais que j’ai fini par enlever car j’ai pu me passer des requêtes HTTP en JavaScript.
lunr.js pour de la recherche dans des données JS/JSON.

Les fonctionnalités JS à implémenter étaient:

Une navigation mobile à déplier au clic (sur 2 niveaux).
Une sorte de slider, que j’ai implémenté en ajoutant/supprimant des attributs hidden (pas d’effet d’animation, on affiche un bloc à la fois et tous les autres sont en display:none).
Une recherche full-text dans un gros fichier JSON. Ça a été la partie la plus compliquée du projet en JavaScript, et sur ce point jQuery n’aurait pas été d’une grande aide. La lib utilisée, lunr.js, est très bien, mais plutôt bas niveau donc il faut un peu de temps pour la comprendre et pas mal de code maison pour l’utiliser.

Perdu. 😁 ↩
Certains ont bien essayé de mettre d’autres langages de programmation dans le navigateur (Microsoft avec VBSCript, Google avec Dart), mais ça n’a pas pris. Sans parler des plugins qui permettaient de faire du Java (petit succès) ou de l’ActionScript (gros succès) et qui sont passés de mode. ↩
Autant que possible, cet article est écrit sans présupposer du genre des personnes même fictives mentionnées. Ainsi «développeur/se» est un raccourci pour «développeur ou développeuse» et le pronom «iels» est un néologisme qui mélange volontairement «ils» et «elles». Je suis consciente que ces mots et graphies ne facilitent pas la lecture pour celleux qui n’en ont pas l’habitude, mais ça compte pour moi donc osef. 😇 ↩ ↩

How to work with SVG icons

2016-03-27T00:00:00+01:00

March 2018 update: more reliable way to set alternative text, small fixes.

There are many ways to use SVG icons in HTML and CSS, and I haven’t tried them all. This is how we do it in our small front-end team at Kaliop. It works well for our needs, which include:

Content and communication websites, often based on big CMSes, rather than full-JS web apps.
Icons which are often simple, single-color icons (each potentially used in several different colors depending on context and user interactions). Two-color icons and gradient fills are possible too, but require a bit more work.
IE11 support.

This article is available in French and in Chinese. Many thanks to the translators!

Preparing your icons

When you get a SVG icon from a designer or from a graphics tool you use (Illustrator, Adobe Assets, Sketch, Inkscape, etc.), it’s tempting to just throw it into your project. Yet I find that reworking it a little bit in your favorite tool to make sure it’s just right can save you some headaches and improve the result.

Simple icon on an artboard in Illustrator (left) and Sketch (right)

Work with a new document or artboard

Create a new document or new artboard in your favorite tool, and copy-paste your icon in the center. It’s a great way to make sure your icon is clean and doesn’t have a ton of hidden paths lying around.

Square is easier

Your icon doesn’t have to be square, but square icons are easier to work with (unless your icon or graphic is really wide or really tall).

Exact dimensions only matter if you want to micromanage pixel fitting (to get the sharpest possible results on low dpi screens). For example if all your icons can fit on a 15 by 15 pixel grid, and are mostly used with those exact dimensions, go ahead and work with 15×15 artboards or documents. When I’m not sure, I like setting stuff on a 20×20 artboard.

Breezy on the sides

Leave a little bit of space near the edges, especially for round shapes. Browsers use anti-aliasing when rendering SVG shapes, but sometimes the extra pixels from the anti-aliasing are rendered outside of the viewBox and they’re cut off.

We didn’t leave any space around the icon, so there’s a risk that it will be rendered with squarish sides. And if the browser doesn’t render the SVG perfectly, it can get worse.

As a rule of thumb, in a 16px or 20px icon, leave 0.5px or 1px of empty space on each side. Also, remember to export the whole artboard, not the selected paths at the center, or you will lose that white space in the export.

Export to SVG

In Illustrator I just use “Save As” and pick “SVG” for the format. (It might be better to use “Export as…” and pick SVG for an optimized result.)
In Sketch you can select an artboard, click “Make Exportable” on the bottom right, and pick “SVG” for the format.
In Inkscape you can “Save As” and pick “Optimized SVG”.

Learn some SVG

You definitely should learn some SVG basics, and be able to read and understand the structure of simple SVG files. Ideally you should know about these:

Grouping elements: <svg>, <symbol>, <g>.
Visual elements: <path>, <rect>, <circle>, <line>.
Styling attributes: fill, stroke, stroke-width.

I tend to look them up in DevDocs (which simply offers a nicer view of the MDN SVG docs) when I want to know more. You don’t have to do that right now, and you can start your SVG adventure by copy-pasting code, but in time it’s helpful to learn enough to understand the code you’re copy-pasting.

When you export SVG from a design tool, it will often have a little bit or a lot of unnecessary markup, metadata and such. It can also have excessively precise path data (in the d attribute). Try using a tool such as SVGOMG and compare the before and after code to see what gets removed or simplified.

Remove color data

For single-color icons, make sure that:

In your source file, the paths are black (#000000).
In the exported code, there are no fill attributes.

If we have hardcoded fills in the SVG source, we won’t be able to change those colors from our CSS code. So it’s generally best to remove them, at least for single-color icons.

Illustrator doesn’t output fill attributes for path that are fully black (#000000). Sketch does, so you may have to open the exported SVG code and manually remove the fill="#000000" attributes.

Making a SVG sprite

This part has a lot of code, but it’s actually not complex at all. We want to create a SVG document containing <symbol> elements. Each <symbol> must have an id attribute, a viewBox attribute, and will contain the icon’s <path/> elements (or other graphical elements).

I’m calling this SVG document a sprite (in reference to sprites in computer games and CSS), but it may also be called a sprite sheet, or a symbol store.

Here’s a sprite with just one icon:

<svg xmlns="http://www.w3.org/2000/svg">
  <symbol id="cross" viewBox="0 0 20 20">
    <path d="M17.1 5.2l-2.6-2.6-4.6 4.7-4.7-4.7-2.5 2.6 4.7 4.7-4.7 4.7 2.5 2.5 4.7-4.7 4.6 4.7 2.6-2.5-4.7-4.7"/>
  </symbol>
</svg>

Adding an icon to our sprite

Say that Illustrator gave us this code for the icon show above:

<?xml version="1.0" encoding="utf-8"?>
<!-- Generator: Adobe Illustrator 19.2.0, SVG Export Plug-In . SVG Version: 6.00 Build 0)  -->
<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
  viewBox="0 0 15 15" style="enable-background:new 0 0 15 15;" xml:space="preserve">
  <path id="ARROW" d="M7.5,0.5c3.9,0,7,3.1,7,7c0,3.9-3.1,7-7,7c-3.9,0-7-3.1-7-7l0,0C0.5,3.6,3.6,0.5,7.5,0.5 C7.5,0.5,7.5,0.5,7.5,0.5L7.5,0.5L7.5,0.5z M6.1,4.7v5.6l4.2-2.8L6.1,4.7z"/>
</svg>

We can simplify it quite a bit (manually or using SVGOMG), only keeping the viewBox attribute and essential data:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 15 15">
  <path d="M7.5,0.5c3.9,0,7,3.1,7,7c0,3.9-3.1,7-7,7c-3.9,0-7-3.1-7-7l0,0C0.5,3.6,3.6,0.5,7.5,0.5 C7.5,0.5,7.5,0.5,7.5,0.5L7.5,0.5L7.5,0.5z M6.1,4.7v5.6l4.2-2.8L6.1,4.7z"/>
</svg>

Now we can copy-paste it in our sprite. We need to transform the <svg viewBox="…"> element into a <symbol id="…" viewBox="…"> element and insert it manually into our sprite:

<svg xmlns="http://www.w3.org/2000/svg">
  <symbol id="cross" viewBox="0 0 20 20">
    <path d="M17.1 5.2l-2.6-2.6-4.6 4.7-4.7-4.7-2.5 2.6 4.7 4.7-4.7 4.7 2.5 2.5 4.7-4.7 4.6 4.7 2.6-2.5-4.7-4.7"/>
  </symbol>
  <symbol id="play" viewBox="0 0 15 15">
    <path d="M7.5,0.5c3.9,0,7,3.1,7,7c0,3.9-3.1,7-7,7c-3.9,0-7-3.1-7-7l0,0C0.5,3.6,3.6,0.5,7.5,0.5 C7.5,0.5,7.5,0.5,7.5,0.5L7.5,0.5L7.5,0.5z M6.1,4.7v5.6l4.2-2.8L6.1,4.7z"/>
  </symbol>
</svg>

You can do this manually for all your icons, but there are tools that automate the process. We use gulp-svg-symbols (here’s our gulp config, if you’re curious), but there are several graphical and command-line tools that export SVG symbol sprites, including Icomoon.

Pro tip: Keep a folder with your source icons

If you make your sprite manually, I recommend keeping a folder with individual SVG icons:

assets/
  icons/
    cross.svg
    play.svg
    search.svg
    ...
public/
  sprite/
    icons.svg

Then if you need to rebuild the icons.svg or change an individual icon, you have the right sources to work with. Be careful to not let your sprite and your source folder get out of sync.

Of course if you use a build process (with Gulp or Webpack or something else), you can feed it your source folder and let it build the sprite directly.

Important: not everything is an icon

Just because something is SVG, it doesn’t mean it should go inside your SVG sprite. For instance:

Illustrations that you don’t need to style: keep as a single SVG file, and include it in your page with <img src="url/to/illustration.svg" alt="…">.
Illustrations that you want to animate: consider inlining the full SVG code in your HTML page, so you can select and style specific groups or paths or shapes, animate some parts, etc.

As a rule of thumb, if it’s a big illustration that you need to show at 100px by 100px or much bigger, or if it contains dozens of elements, it might not be an “icon”. It would probably bloat your sprite’s size, too.

Adding icons to your pages

The bad news is that in order to use our SVG icons, we have to change our HTML code. No CSS backgrounds, no ::before pseudo-elements. The least verbose HTML we can use is:

<svg>
  <use xlink:href="https://fvsch.com/path/to/icons.svg#play"></use>
</svg>

Which can look like this:

An unstyled SVG icon

Now we’re going to make this HTML a bit more verbose, in order to make it easier to style and also more accessible. I’ll show a few common patterns first, and then we’ll explain each technical choice.

Pattern A: a purely decorative icon

<svg class="icon" aria-hidden="true" focusable="false">
  <use xlink:href="https://fvsch.com/articles/svg-icons/sprite.svg#symbol-id"></use>
</svg>

Pattern B: link or button with icon and text

<a href="https://fvsch.com/news">
  <svg class="icon" aria-hidden="true" focusable="false">
    <use xlink:href="https://fvsch.com/articles/svg-icons/sprite.svg#newspaper"></use>
  </svg>
  Latest News
</a>

Pattern C: link or button with icon

This is the same as (B), but we only want to show an icon. We should still keep the text around, so that screen reader users can read it.

<a href="https://fvsch.com/news" title="Latest News">
  <svg class="icon" aria-hidden="true" focusable="false">
    <use xlink:href="https://fvsch.com/articles/svg-icons/sprite.svg#newspaper"></use>
  </svg>
  <span class="access-label">Latest News</span>
</a>

Pattern D: icon and alt text outside of a link or button

For example, if we had a table column with icons representing “Yes” and “No”:

<td title="Yes">
  <svg class="icon" aria-hidden="true" focusable="false">
    <use xlink:href="https://fvsch.com/articles/svg-icons/sprite.svg#check"></use>
  </svg>
  <span class="access-label">Yes</span>
</td>

What do our different HTML parts do?

HTML pattern	What it does
`<a title="My label">`	This is mostly a usability enhancement for some users: when you’re only showing an icon to represent a feature, it can help to show a tooltip on mouseover.
`<span class="access-label">…</span>`	We’re using a visually hidden `<span>` to provide accessible text. Other techniques like `aria-label` or SVG’s `<title>` element are not that well supported in browsers and screen readers, so this is the most reliable way. We’ll discuss the exact styles to use for our `access-label` class in the next section.
`aria-hidden="true"`	Since we’re already including accessible text outside of the SVG element, we can tell screen readers to ignore it. This prevents issues where some readers might try to read something for the icon, or read the link or button’s text twice.
`focusable="false"`	This one is for IE and Edge. In those browsers, the SVG element can get keyboard focus. This can result in the surrounding link or button being focused twice, and being read twice.
`class="icon"`	We could style the SVG element directly, but adding a class and reusing that class everywhere lets us define useful default styles for our SVG icons.

Using meaningful and localized labels

Some articles recommend associating a text label with each SVG file in your icon repository (e.g. by putting a <title> element in each <symbol>). This is a mistake, because a visual symbol can have different meanings depending on context.

A “magnifying glass” icon can mean “Show the search form” in one context, and “Submit my search query” in a second context. Your text labels should then be “Show the search form” and “Submit search query”, not “Search” (too generic) or worse “Magnifying glass” (describes the visuals and not the meaning).

On multilingual sites, your text labels should also be localized, including all text labels that are hidden by default for sighted users.

External and inline sprites

Up until now we’ve shown examples for an external sprite. But some older browsers — namely, IE 9 to IE 11 — only support inline references for <use xlink:href="#some-id"/>.

This can be polyfilled with some JavaScript (svg4everybody, svgxuse). Or you can decide to include your sprite in the HTML code of every page.

<body>
  <!-- Hidden icon data -->
  <svg aria-hidden="true" focusable="false" style="display:none">
    <symbol id="icon-play">…</symbol>
    <symbol id="icon-cross">…</symbol>
    <symbol id="icon-search">…</symbol>
  </svg>

  <!-- A visible icon -->
  <button>
    <svg aria-hidden="true" focusable="false">
      <use xlink:href="#icon-play"></use>
    </svg>
    <span class="access-label">Start playback</span>
  </button>
</body>

Each method has its pros and cons.

	Inline sprite	External sprite
Browser support	Native support in IE9+. Older Safari/WebKit needs the sprite at the beginning of the page (before any reference).	Native support in Edge 13+, Safari 9+. IE and older Safari/WebKit need a JS polyfill such as svg4everybody or svgxuse. Loading an external sprite from a different domain doesn’t work for now (even with CORS, see Chromium bug for instance). This can be polyfilled with JS using svgxuse.
Caching	No caching. The weight of your sprite (5KB, 15KB, 50KB…) is added to every page.	Sprite is a separate file and can be cached by the browser. Also it does not bloat your server-side HTTP cache.
Rendering speed	Icons are rendered instantly. On slow networks, rendering of the page structure and content may be delayed if you have a heavy SVG sprite inserted before your content.	Icons can be shown a bit late because a) they require a separate HTTP request and b) the browser did not prioritize loading this SVG file (using its look-ahead pre-parser).
Updating	When you need to update your sprite, you need to make sure it’s added to every single page. This regenerating all HTML pages if you use a static generator, or invalidating all caches.	Only one public file is changed, so managing updates and server-side caching is a bit easier.
With a CDN	Not impacted.	Warning: browsers will not load SVG referenced with `xlink:href` on a different domain or subdomain (cross-origin)! If you need to load a cross-origin SVG sprite, you will need to load it with JavaScript and inject it in the page.

I like mixing both methods, building two sprites:

A small one with essential icons (e.g. main icons used in the page header), to be inlined on each page. Target size: 5KB or less.
A bigger one with all the project’s icons, kept as an external file. Target size: 50KB or less.

On bigger projects, we might add more external sprites when some icons can be grouped together and are only used in one part of the site or for a specific feature.

Styling icons with CSS

Now that we have SVG icons and a SVG sprite, and that we learned how to add icons to our HTML, let’s look at the CSS side.

Starting with base styles

Here are the styles for our two utility classes, icon and access-label.

/**
 * Visually hidden accessible label
 * Using styles that do not hide the text in screen readers
 * We use !important because we should not apply other styles to this hidden alternative text
 */
.access-label {
  position: absolute !important;
  width: 1px !important;
  height: 1px !important;
  overflow: hidden !important;
  white-space: nowrap !important;
}

/**
 * Default icon style
 */
.icon {
  /* Use the current text color as the icon’s fill color. */
  fill: currentColor;
  /* Inherit the text’s size too. Also allows sizing the icon by changing its font-size. */
  width: 1em;
  height: 1em;
  /* The default vertical-align is `baseline`, which leaves a few pixels of space below the icon. Using `center` prevents this. For icons shown alongside text, you may want to use a more precise value, e.g. `vertical-align: -4px` or `vertical-align: -0.15em`. */
  vertical-align: middle;
  /* Paths and strokes that overflow the viewBox can show in IE11. */
  overflow: hidden;
}

With that code, by default your SVG icons should be small and use the parent’s text color. Like this:

First row of icons with default text size and color

Second row of icons with bigger text size and a green text color

Icons with our default style. The only change between the top and bottom row is the font-size and color of the container.

If the icon’s shapes do not inherit the parent’s text color (currentColor), check that you don’t have hardcoded fill attributes in your icon’s code.

Why not style the `svg` selector directly?

We might have other SVG elements in the page that are not icons. For example, a big SVG map, or an interactive SVG game. Another reason was that older Firefox versions (before Firefox 56) had a bug with the svg selector (it would apply inside the <use> element), and targetting a class avoided this issue.

Feel free to use the svg selector instead of .icon if you think that would work for your use case.

Overriding the base styles

It should be easy to override our base styles in a specific context:

.ShareComponent .icon {
  /* Change the width and height */
  font-size: 40px;
  /* Change the fill color */
  color: purple;
  /* Change the vertical-align if you need more precision
     (sometimes needed for pixel-perfect rendering) */
  vertical-align: -4px;
}

Inherited SVG styles

Many SVG style properties are inherited. For instance when we set the fill CSS property on our containing <svg> element, it trickles down to our <path>, <circle> and other graphic elements.

We can use this technique for other SVG CSS properties as well. For instance the stroke properties:

.icon-goldstar {
  fill: gold;
  stroke: coral;
  stroke-width: 5%;
  stroke-linejoin: round;
}

Star icon with default and custom styling

Most of the time we’re not going to change a lot of stuff: only the fill property for the main color, and sometimes we’ll add or tweak a stroke (kinda like a border).

Two fill colors per icon

There’s a fairly simple technique which allows an icon to have two set of paths with two different fill values (aka two colors).

<symbol id="check" viewBox="0 0 20 20">
  <!-- Will inherit the value of the fill CSS property -->
  <path d="…" />
  <!-- Will inherit the value of the color CSS property -->
  <path fill="currentColor" d="…" />
</symbol>

.icon-bicolor {
  fill: rebeccapurple;
  color: mediumturquoise;
}

Two color icons

Tip: leave some room for strokes

Remember when we said to leave some room around your shapes? It’s especially important if you plan to use strokes.

.icon-strokespace {
  fill: none;
  stroke: currentColor;
  stroke-width: 5%;
}

In SVG, strokes are always painted on both sides of the path (inside and outside). If your path touches the limits of the viewport, half the stroke will be cut off.

In this example, the first icon has no reserved blank space on the sides, and the second icon has a small one (0.5px, for a 15px viewport).

Tip: use percentages for `stroke-width`

Giving the right size to a stroke can be challenging. Look at these two examples where we set stroke-width:1px on the <svg> element:

What’s happening? The stroke-width property takes a “length” value, but that value is relative to the local coordinates of your icon. In the examples above:

The first icon has a 20px by 20px viewBox. So a 1px stroke is 1/20th of the icon’s size, big but not too big.
The second icon has a 500px by 500px viewBox. So a 1px stroke is 1/500th of the icon’s size, and that really really small.

If all your icons use a similar viewBox, that’s not a problem. But if they can differ wildly, using pixel or unitless values (stroke-width:1) is out. What should we do?

Percentages can be good. Same example, with stroke-width:5%:

Now that’s better. (For square icons, stroke-width:N% will work perfectly, but note that it can behave a bit differently for large or tall SVG elements.)

Advanced topics and tricks

With the previous sections you should have everything you need to know to use SVG icons. This next section adds some more advanced information, with perhaps fewer real-world applications.

Avoiding really big unstyled icons

What happens if your main stylesheet fails to load because the user is on a flaky connection, maybe on a train (this happens to me all the time)? The page might still render without styles.

If you have a decent HTML structure, the page will still be readable, but your icons will end up really big.

Recent browsers size the <svg> element at 300 by 150 pixels by default. Other browsers might give it a gigantic 100% width!

I recommend putting this in the <head> of your pages:

<style>.icon{width:1em;height:1em}</style>

Short and sweet.

Another approach is to always use width and height attributes on your SVG elements. It works, but if you need to resize this icon in CSS it might be a bit harder.

<svg width="20" height="20" aria-hidden="true" focusable="false">
  …
</svg>

Preloading external sprites

In the “Adding icons to your pages” section we said that icons from an external sprite can show up a bit late, partly because of the browser’s pre-load scanner (or look-ahead pre-parser or whatever) not picking up that <use xlink:href="https://fvsch.com/path/to/icons.svg#something"></use> means there is an important file to load early.

What can we do about this?

Standard and future solution: add <link rel="preload" href="https://fvsch.com/path/to/icons.svg" as="image"> in the <head> of the page (details on preload, support coming to a Chrome near you and hopefully in more browsers in the future).
Old school solution: add <img style="display:none" alt="" src="https://fvsch.com/path/to/icons.svg"> at the start of the <body>.

I haven’t actually tested those solutions, generally the “inline + external” compromise gives good enough performance that we don’t have to rely on preloading. But it’s worth investigating.

Selecting individual shapes or paths

We’ve looked at ways to customize fills, strokes etc. for all paths from a <symbol>, and 2 or more colors from different paths. But what if we could select specific paths (using classes maybe) directly in the instance of the <symbol>? Is it possible?

Right now the answer is: yes and no.

If you use external sprites, you can’t select individual paths (or other elements) inside a used <symbol>.
If you inline your sprite, you can select and style elements inside the sprite, but those styles will apply to all instances of the symbols.

So even with an inlined sprite, you could do this:

#my-symbol .style1 {
  /* Styles for one group of paths */
}
#my-symbol .style2 {
  /* Styles for another */
}

But you can’t do this:

.MyComponent-button .icon .style1 {
  /* For 1 group of paths for this icon in this context */
}
.MyComponent-button .icon .style2 {
  /* For another group */
}

In the future, there might be a standard way that allows selecting through a Shadow DOM, but that’s not sure at all (there used to be the /deep/ combinator, but it was removed).

More than two colors with CSS Custom Properties

So we can easily change colors of our SVG icons from CSS, for single-color icons (easy) and two-color icons (takes some preparation). Is there a way we could have multicolor icons with more than two customizable colors?

We might be able to do that with CSS Custom Properties (aka CSS Variables). This requires a lot of preparation on the SVG side:

<symbol id="iconic-aperture" viewBox="0 0 128 128">
  <path fill="var(--icon-color1)" d="…" />
  <path fill="var(--icon-color2)" d="…" />
  <path fill="var(--icon-color3)" d="…" />
  <path fill="var(--icon-color4)" d="…" />
  <path fill="var(--icon-color5)" d="…" />
  <path fill="var(--icon-color6)" d="…" />
</symbol>

For this demo I stole an icon from the excellent Iconic, which offers responsive, multicolor SVG icons (powered by CSS and some JS, as I understand). I tried to mimick their own multicolor example for this icon, I hope they don’t mind.

One symbol using 6 different CSS custom properties.
See in Firefox, Chrome, or Safari 9.1+

It works fairly well in supported browsers. There’s only one icon: the first instance doesn’t declare the expected variables, so it falls back to currentColor; the next two instances each declare a set of variable values.

How are percentage `stroke-width` computed?

What does the percentage correspond to in stroke-width:N%? Is it the width, the height of the icon? Turns out it’s relative to the diagonal, but with a funky formula (spec) (diagonal length divided by the square root of 2, which is close to 1.4).

What does it mean? Well for square icons the result of that formula is the side of the square. So 1% means “one percent of the width or one percent of the height”. Nice and simple.

For wider or taller icons, though, the result can change a bit:

In the second icon (aspect ratio of 2:1, shown with the same height and twice as large), the stroke-width:5% gives us a stroke that is roughly: 7.91% of the height and 3.95% of the width.

All things considered, I still recommend using percentage values for stroke-width. If you stick to square or sharish icon, you can use percent values with the understanding that they mean, roughly, “percentage of the width of the icon”.

Using gradient fills

We can’t use CSS linear-gradient(…) because this sadly cannot apply to the SVG fill property. If we want gradient fills, we will need to use SVG gradients.

Florens Verschelde

A DevTools retrospective… and also maybe gift me a laptop?

What did I do as a contributor?

Why am I asking for money?

PHP code typing with Kirby CMS

Why you might want completions

Runtime magic

Adding type hints and annotations

Making sure your editor has good PHP support

Where should you put logic code in Kirby CMS?

Logic in templates? Sure.

Or in controllers, maybe?

Creating a page method

Creating a page model

Creating a default page model

A short history of body copy sizes on the Web

Et tu cliques cliques cliques, à côté du bouton ♫

Pourquoi c’est pas facile de cliquer un petit bouton ?

Okay mais tout le monde sait ça hein, c’est la base !

Les tailles de bouton recommandées pour les interfaces tactiles

Les tailles de bouton pour les interfaces à la souris

Interview sur Alsacréations

Alsacréations: Comment envisages-tu le futur de CSS ou de l’intégration en général ? (on pense notamment à CSS-in-JS)

Alsacréations: Si tu avais à former un·e débutant·e en HTML et CSS, sur quels thèmes insisterais-tu particulièrement ?

Static site generators

What is a static site generator, really?

A developer’s idea of elegance

Static site generators are bad at content

A few words of warning about Hugo

What could we do differently?

1. Content naming conventions

2. Give feedback on content-to-output mapping

3. More code should happen in templates

4. A full content API

5. Markdown plus front-matter is too limiting

6. No theming system

Styling buttons, the right way

Resetting <button> styles

Writing a “button” CSS component

Styling hover, focus and active states

Dealing with sticky focus styles

Command line tips

The command what?

You need help (and tldr is great)

Bash keyboard shortcuts

MacOS: install Homebrew and GNU coreutils

How big is this directory?

How to not delete everything

Gradient fills for SVG icons

Putting gradients in your HTML

Changing gradient colors with CSS variables

Using gradients in external files

Using gradients in CSS as data URLs

Let’s recap

A few wishes for privacy settings in Firefox

About tracking

Why browsers don’t do more

What Mozilla is doing

Privacy settings should be simpler

Printing background colors with CSS and SVG

Faking a background with SVG

Browser support

Three things to watch out for

Blogging with public drafts

Reading books again

ReMarkdown.css

Project history

Using ReMarkdown

Using CSS variables in SVG icons

The math of CSS Locks

What’s a CSS lock?

Viewport-relative sizes

The CSS lock concept

Limitations

CSS locks with pixel breakpoints

The demos

Font size as a linear function

Translating to CSS

Factoring user preferences in

Making a line-height lock

Resetting `<button>` styles

You need help (and `tldr` is great)

Don’t use `em` media queries with `m × 100vw`

Unitless `calc` divisors and factors

Line-height locks with `em`/`rem`

Why not style the `svg` selector directly?

Tip: use percentages for `stroke-width`

How are percentage `stroke-width` computed?