Today I replaced the Skeleton based layout on this site with a CSS Grid based layout. I’ve been wanting to make the move for a while and finally found the time after waking up at stupid o’clock this morning.

I wanted to do a like-for-like replacement and stick with the 12 column layout. I’m not quite ready for a complete redesign just yet.

Based on this clever repeating column trick from the Mozilla Developer Network this is how I went about it.

First up, create a 12 column grid I can add to any container I want:

.layout {
    display: grid;
    grid-template-columns: repeat(12, [col-start] 1fr);
    grid-column-gap: 2rem;
}

Taking a small-screen first approach, set the immediate children to span 10 of the columns, offset by one:

.layout > * {
    /* All grid elements to span 10 cols offset by 1 */
    grid-column: col-start 2 / span 10;
}

Adding my .layout class to the header and footer elements, and then wrapping main and aside in a div with that class gave me my basic layout. Then as the viewport gets wider, I can just do this on the required breakpoints:

@media screen and (min-width: 1000px) {
    .layout-main {
        grid-column: col-start 2 / span 5;
    }

    .layout-sidebar {
        grid-column: col-start 8 / span 4;
    }
}

I could have simplified the syntax and removed the line names by omitting col-start, but named lines are very powerful and I might want to play with them later.

The end result is my CSS payload has gone from around 20k to just under 6k, and my markup is a lot simpler.

It was ridiculously quick and painless. From branching my repository to deploying the final code took just over an hour, and I’m sure fifteen minutes of that was me double checking I hadn’t missed something. As Jeremy said :

I think I may need to recalibrate the estimation part of my brain to account for just how powerful CSS grid is.

(Thanks to Mat for pointing me towards to Pun Generator for the title)

Ethan wrote today about his gif repository and how he manages it. As some friends will know I also have a repository, which was entirely inspired by Ethan.

I say “inspired”, what I mean is “blatantly ripped off from”.

The repository sits in a subdirectory hanging off one of my domains. I can’t quite remember why it ended up in a subdirectory, it’s not like I’m running short of domains, but there it sits. One thing on my to-do list is moving it somewhere else.

Like Ethan there isn’t much technical going on behind the scenes, it’s a standard Apache directory listing which gives me simple ordering. It’s refreshing in an old school way, but I do sometimes get the itch to dig into Apache’s AutoIndex Formatting and fancy it up a bit.

Transferring files isn’t something I’ve spent a huge amount of time over. I’ve always been a bit of command line nerd, so interesting files get saved to my desktop, and then secure copied up to the server. It happens so often now that there are 75 entries in my history file for running that one command for the last 3 months alone.

This post came about from a little back and forth with Ethan where I said I would write something, and he’s good people, so I hate to let him down.

Plus it’s fun to write about little projects.

Go forth and create little projects!

A fascinating and poignant Twitter thread from Marcin Wichary, about user interfaces that accidentally collect memories, and tell a story about the past.

Fascinated by UIs that accidentally amass memories. One of them is the wi-fi “preferred networks” pane – unexpected reminders of business trips, vacations, accidental detours, once frequented and now closed cafés. pic.twitter.com/r137dZI0r8

— Marcin Wichary (@mwichary) 14 May 2018

I wonder what I would see if I fired up any of the old social apps I don’t use any more, like Adium, or Textual.

Via this ongoing Metafilter post with more funny and sad stories of accidental memories.

Tetris, on a bloody soldering iron!

Each time you lose the game the soldering iron tip temperature increases by 10 degrees.

Via this Metafilter thread about the Nintendo Switch exploit.

Well I would say that, wouldn’t I.

I’m referring to a recent edition of Jason Kottke and Tim Carmody’s Noticing newsletter.

Jason asked Noticing readers to send in links to their blogs and newsletters, or their favourite blogs and newsletters written by someone else, and as he says:

My inbox exploded with replies. I couldn’t include all (or even most!) of the links I got, but below is a good sampling representative of the types of blogs and newsletters I received.

It’s a great list, and I’ll be adding a few of them to my RSS feeds.

There’s also a fantastic quote from Kari about why she writes:

I also keep it out of spite, because I refuse to let social media take everything. Those shapeless, formless platforms haven’t earned it and don’t deserve it. I’ve blogged about this many times, but I still believe it: When I log into Facebook, I see Facebook. When I visit your blog, I see you.

This place feels more like me than any other platform I use out there.

Dubstep songs are often criticized as sound extremely computer generated and often just too aggressive/“digital” for a lot of people to enjoy. It’s not uncommon for people to joke that they sound like someone had added a bassline and drums to modem noises

For some tracks this is truer than others. After all, it’s a genre with more aggressive interpretations and more relaxed ones.

But that had me thinking, how much effort would it be to actually embed machine readable data inside a dubstep track, while ensuring that the sound could be enjoyed by humans as well…

Encoding data in dubstep drops.

I want to call this something punny. Dubsteg? Dubsteganography? Dubstepanography?

Via O’Reilly’s Four Short Links (which is well worth space in your RSS reader).

For the longest time I’ve had Google Analytics running on this site. On the occasions when a post got popular, it would be fun to look at the real-time data, see where visitors were coming from, understand how my words were making it around the web.

As of today I’ve removed their analytics code, and will be going back to good old server side logs.

A number of things have led me to this decision.

One is my renewed interest in the Indieweb and wanting to be less reliant on outside parties.

Another is performance, less scripting means less bytes.

And finally, and most importantly, privacy. As seductive and interesting as it is watching people visit the site in real-time, and digging down into the paths they took, why do I need to know any of that? I’m not a business, I don’t have “funnels”, “conversions”, or “targets”. You come, you read, you leave.

The server logs will still be grabbing some data. Specifically when you visited, what you visited, who referred you (if anyone), and your browser.

It’s a blunt tool, but I’m okay with that.

Last night I attended the always excellent JS Oxford, and as well as having my mind expanded by both Jo and Ruth’s talks (Lemmings make an excellent analogy for multi-threading, who knew!), I gave a brief talk on the Indieweb movement.

If you’ve not heard of Indieweb movement before, it’s a push to encourage people to claim their own bit of the web, for their identity and content, free from corporate platforms. It’s not about abandoning those platforms, but ensuring that you have control of your content if something goes wrong.

From the Indieweb site:

Your content is yours

When you post something on the web, it should belong to you, not a corporation. Too many companies have gone out of business and lost all of their users’ data. By joining the IndieWeb, your content stays yours and in your control.

You are better connected

Your articles and status messages can go to all services, not just one, allowing you to engage with everyone. Even replies and likes on other services can come back to your site so they’re all in one place.

I’ve been interested in the Indieweb for a while, after attending IndieWebCamp Brighton in 2016, and I’ve been slowly implementing Indieweb features on here ever since.

So far I’ve added rel="me" attributes to allow distributed verification, and to enable Indieauth support, h-card to establish identity, and h-entry for information discovery. Behind the scenes I’m looking at webmentions (Thanks to Perch’s first class support), and there’s the ever-eternal photo management thing I keep picking up and then running away from.

The great thing about the Indieweb is that you can implement as much or as little as you want, and it always gives you something to work on. It doesn’t matter where you start. The act of getting your own domain is the first step on a longer journey.

To that end I’m interested in organising an IndieWebCamp Oxford this year. If this sounds like something that interests you, then come find me in the Digital Oxford Slack, or on Twitter.

Frank Chimero really nails something I’ve been feeling for a while now but have been unable to put into words (emphasis mine).

Illegibility comes from complexity without clarity. I believe that the legibility of the source is one of the most important properties of the web. It’s the main thing that keeps the door open to independent, unmediated contributions to the network. If you can write markup, you don’t need Medium or Twitter or Instagram (though they’re nice to have). And the best way to help someone write markup is to make sure they can read markup.

Learning to code through reading source was how I get started. The first site I ever built is still out there thanks to archive.org, and I delight in showing the ramshackle beginnings of my career to new students at Codebar and Code First:Girls.

Frank continues (again, emphasis mine).

As someone who has decades of experience on the web, I hate to compare myself to the tortoise, but hey, if it fits, it fits. Let’s be more like that tortoise: diligent, direct, and purposeful. The web needs pockets of slowness and thoughtfulness as its reach and power continues to increase. What we depend upon must be properly built and intelligently formed. We need to create space for complexity’s important sibling: nuance.

Yes!

As Jeremy has said in Resilient Web Design:

Here’s a three‐step approach I take to web design:

1. Identify core functionality.
2. Make that functionality available using the simplest possible technology.
3. Enhance!

I continually go back to these three rules. I want to build things that others can learn from.