After boasting about having conquered images last time, I discovered they were not, in point of fact, always correctly sized. On narrower screens, certain configurations overflowed their containers and the pages. Even the main text of the articles spilled outside the boundaries. I quickly added checks to prevent the overflow and began contemplating the overarching problems.

I thought my grid cleverly took into account all of these variables:

But a one-line grid would only account for the first and second. I could not expect the same grid to magically respond to all four when I myself could not articulate how the presentation should change.

I spent a few days thinking about how many images should be shown next to each other and how big they should be, and in response to which variables. Should a single image grow until a certain point before being replaced by two smaller images? Should there only be one row of fixed-size images? Both?


Let us step back for a moment. Text on A Place For My Head starts out at 1.3rem so that it’s larger and easier to read than usual but not, I hope, uncomfortable on smaller devices. I am forever extolling the virtues of larger text and could have implemented fluid typography that grows with the viewport, but that technique plays havoc with zooming, something I rely heavily upon. My compromise is to have a single breakpoint increasing the font size to 1.7rem (compared to the 1.6rem I used to have). I then set a max-width in rems on the article element to maintain the right measure, as I wrote about last time.

Consequently, the upper bound on how large any image on the page can be is half the the width of the entry at its largest, i.e. 38rem ÷ 2 = 19rem. Therefore, my groups must cater to three possibilities:

  1. If the screen is smaller than 400 pixels, each image should take up the full width of the article.
  2. If the screen is between 400 pixels and 70.75em, each image should take up 400 pixels.
  3. If the screen is 70.75em or larger, each image should take up half of the width of the article.

Implementing this with Flexbox instead of Grid—because there is now only one dimension to be concerned with—doesn’t require much (pardon the BEM-like Sass):

    max-width: min(100%, 400px)
  &-group > &-link
    @media (min-width: 70.75em)
      flex: 0 0 calc(50% - var(--margin) / 2)

This will implement the behaviour I want on larger screens and keep the images far enough apart.

The sizes attribute requires more careful attention. The media queries have to be specified in ems, which are measured against the browser’s initial font size, not anything related to the page (in other words, they’re equivalent to rems in this context). Given that the maximum width is 38rem and the base font size is 1.7rem (ignoring smaller screens for now, since they won’t reach the maximum width except in edge cases), I set a breakpoint for 38em × 1.7 = 64.6rem with padding, i.e. 70.75em, and size images at 19rem beyond that. I believe this, along with my new, much longer list of image widths behind the scenes, should ensure you always see appropriately-sized images on any screen and at any zoom level or font size (within reason).

All this let me reimplement group-level captions—which you might see someday soon—but not before I had spent two hours trying to understand why flex-wrap appeared to have no effect on my code. (I had forgotten that flex-flow is a shorthand property. It was not my finest moment.)

On comments and ‘mini’ posts

I don’t think I will have comments, or at least not a server-side solution. Nor will I implement other kinds of posts. On the contrary, I intend to hide the few music posts I’ve already published (but not delete them, because Cool URIs don't change). Instead, my plan at the moment is to run an instance of a federated social media network. More specifically, I want to run Pleroma, which is compatible with the prehistoric elephant in the room. I will disallow signing up, instead directing new users to the main Fediverse.

I realize it may seem odd to have, effectively, a single-user instance. There is certainly a legal aspect to it: I don’t wish to accept personal liability for what others might put on the network. More than that, though, it’s a decision born of carefully considering what I want from this site: not a community—not right now, likely not ever. I want to carve out a space from where I can interact with the rest of the world. Federated social networks offer a place to share many, many brief notes about interesting things that don’t merit a full entry here but can be part of a conversation. If I later felt the need to elaborate, A Place For My Head continues to exist. I can even share entries on the network so people have another way to stay abreast of my scintillating writing, especially if they join the Fediverse, which has much more to attract them.

On a tangentially related note, I’ve come to think of comments as a supplement rather than a core concern. The exceptions are a drop in the ocean of the Internet. Therefore, I would now be willing to embrace a JavaScript-only solution. However, just as I don’t want to grow a miniature social network of my own, I have no desire to cultivate a community of regular commenters (leaving aside the question of how feasible that would be in any case). Being able to participate in conversations across the web at will is enjoyable; being an administrator or a moderator is not.

Unfortunately, these grand plans will have to wait for DigitalOcean to resolve some general issues I’ve been facing. It may be a while. I can only start to discover what obstacles lie in wait for Pleroma on Kubernetes once that’s done.

I may yet choose to implement a solution for displaying Webmentions, considering all the trouble I took over receiving them, but I’m not certain.


And now, the most obvious change. Let me say at the outset that I really like Dolly, the typeface I’ve been using for the past month and a half. Its shape is pleasing and mostly refined. It includes amenities such as small caps. Nevertheless, when I look at it now, two things stand out. First, its regular weight feels too heavy to me, as a result of which the bold headings don’t have quite the power I’d like. Second, the aforementioned pleasing shape has too many odd contours that break its regularity.

An entry set in Dolly.
Note the ‘ck’ in ‘backend’, the ‘tt’ in ‘written’, and the ‘x’ in ‘example’.

I like a lot about Dolly, but I must bid it farewell. In its place, I wish I could have used my favourite, the classically beautiful and polished Adobe Garamond, but that felt like a step further in the wrong direction. Garamond is a fine and delicate creature. It doesn’t sit well in mixed writing.[1] I need something more uniform and versatile.

I took inspiration from Sara Soueidan’s blog. Its text is too light,[2] but the site is clean, simple, straightforward, and æsthetically pleasing—everything I aspire to achieve here. I admire the careful useful of whitespace, the clear hierarchy of sizes, and the typeface itself.

That last turned out to be Fira Sans. I would gladly have stolen borrowed the choice, but Fira and its ilk are too common for my tastes. After some experimentation, I decided to essay that, ah, most unpopular of fonts, Proxima Nova. How do I reconcile my hesitation towards Fira Sans with my willingness to adopt a different popular font, you ask? Simple: I don’t even try.

At any rate, Proxima Nova immediately lends a sense of balance to the page. It’s dark enough in its normal weight to be legible while still providing contrast with the vast array of heavier and lighter weights. Since it lacks small capitals, I’ve turned to condensed versions or different weights to see how they sit in those places. Of course, I’m not bound by my decisions, as I’m still relying on my Adobe Fonts subscription to try out various faces until I make a more final choice—unlike, say, using MyFonts, which makes it nigh impossible to evaluate a face in context.

To go with the new typographical character of the site, I’ve restored the left-aligned headings on entry pages and increased the spacing again. It felt right. I’ll work out a proper typographical scale when I have a moment.


This entry took a long time to finish because, apart from the claims of several side projects on my time, there were so many subtle and drastic changes to make and verify. I don’t like being slow to publish, but I think it’s worth it if the quality is commensurate.

  1. Similarly, I really like Mercure (thanks Robin Rendle!), but, on top of being another high-contrast serif, it only comes in regular and italic styles. I’m sure a skilled designer could create a beautiful hierarchy with just those two. I am not that skilled designer.
  2. Which deserves an entry on its own.

Next in series: (#13 in Colophon: Finding A Place For My Head)