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:
- The width of the viewport
- The font size
- The number of images in a group
- The number of images to be shown in a row
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
(compared to the
1.6rem I used to have). I then set a
rems on the
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
- If the screen is smaller than 400 pixels, each image should take up the full width of the article.
- If the screen is between 400 pixels and
70.75em, each image should take up 400 pixels.
- If the screen is
70.75emor 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):
.image &-link 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.
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
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,
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.
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.
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. I need something more uniform and versatile.
I took inspiration from Sara Soueidan’s blog. Its text is too light, 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.
- I noticed old-style & proportional numerals in the code blocks. I added a rule to enforce lining & tabular numerals in all such contexts. I also removed the unintended justification.
- Links in lists of entries such as the homepage used to be highlighted as a single block on hover or focus, which was an unintended consequence of some old styling. Now the highlighting obeys line breaks.
- I am already considering replacing Proxima Nova.
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.
- 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.↩
- Which deserves an entry on its own.↩