Digital coffee 🤖☕️

I’ve been getting a bunch of emails recently with web- and tech-related questions from collaborators, friends, clients, family members, almost everyone I know. I suspect this has to do with the huge shift we’ve all made recently in the way we work and live our lives.

Related to this, I’m offering offering free 30 minute slots every Tuesday afternoon GMT to anyone that wants to have digital coffee over Google Hangouts. I haven’t decided how long to do this, but I’ll try to continue until we’re past the worst of current events.

The point is to offer individuals – particularly those that are self-employed or run small businesses – an opportunity to ask nebulous tech-y questions. But I’m happy to talk about anything! WFH tips, recipe ideas, the best movie you’ve seen recently, great sci fi authors, how to grow herbs indoors (I could use some pointers). Only thing I’d probably rather not talk a lot about is COVID-19, please and thank you.

I can’t promise to have all the answers, but I can promise my insight and some nice face-to-face time. We could all use a bit of that right now.

If you think you’d benefit from this, feel free to sign up for a slot. If you know someone that might benefit from this, point them my way.

This is directly inspired by Carly Ayers’s Digital Coffee as linked to on Google’s Hack to Help: COVID-19 site. Nice idea.

Moving your email from one host to another

I recently helped an artist friend move an email address associated with her domain name from one host to another. These are the steps we took.

TL;DR — Moving email from one host to another is a pain. If you have to take it on yourself, take each step carefully and when in doubt, get in touch with your email hosting provider for advice.

Read full instructions

Where are the non-English programming languages? Thoughts prompted by a small but mighty bug

A short two-parter

Part 1: A small-but-mighty bug

I’m doing a few coding-for-designers workshops with the students in the MA Graphic Media Design programme at the LCC, the first one was this past Thursday.

We’re focusing on web stuff since that’s what they expressed the most interest in and it’s in my wheelhouse. We started with a broad and brief overview of code, about how we use human-readable programming languages to communicate with computers. But 99% of the time, when we say “human-readable” we really mean “English-based”. More on this later.

After my short intro, we put together a simple webpage with HTML and CSS. A few of the students ran in to a small-but-mighty bug that I’ve never encountered before.

We were working on a basic CSS rule set, something like:

body {
  background-color: linear-gradient(blue, pink);
}

And for one of the students, it just wasn’t working. I checked it a bunch of times, it was all typed perfectly. No missing spaces or characters, spelling was fine. VSCode indicated that the background-color declaration wasn’t finished, which seemed weird. I looked really closely at it and noticed that the semicolon seemed a little thinner than the others in the file.

Turns out that the student had typed a full-width semicolon (U+FF1B) instead of a semicolon (U+003B). The full-width semicolon is used in Chinese to “demarcate parallel structures in a paragraph”. Another student ran in to the same problem a few minutes later, using a full-width left curly bracket (U+FF5B) instead of a left curly bracket (U+007B).

I had asked them to type in a semicolon, to type in a curly bracket, and so they typed the characters the way they normally do in their native languages. Super understandable.

If you were just starting to learn what code is and how it works, I can’t imagine how hard it would be to debug this sort of language-based problem on your own.

Part 2: Where are the non-English programming languages?

Gretchen McCulloch wrote a very worthwhile Wired article titled “Coding Is for Everyone—as Long as You Speak English”. I feel like every programmer / dev should read it.

Programming doesn’t have to be English-centric. As McCulloch puts it:

The computer doesn’t care. The computer is already running an invisible program (a compiler) to translate your IF or <body> into the 1s and 0s that it functions in, and it would function just as effectively if we used a potato emoji 🥔 to stand for IF and the obscure 15th century Cyrillic symbol multiocular O ꙮ to stand for <body>.

How would we go about implementing non-English HTML tags? W3C has an FAQ on the topic where they state that “HTML or XHTML tags are all pre-defined (in English) and must remain that way if they are to be correctly recognized by user agents (eg. browsers).

Since browsers just implement the standards set by W3C (I’m pretty sure that’s right?), I’m guessing that W3C would have to approve it if we wanted native non-English HTML support. It seems like it would be a bit of a mountain to climb but if we take something like Wikipedia’s translation efforts as an example, surely there are tons of people out there that would help with translation?

Gonna keep an eye on this. Need to find a book or good article on the history of ALGOL.

Using CSS, HTML, and maybe a little logic to display images with a consistent surface area

Every once in a while, I have to figure out how to display images on the web with a consistent surface area. It’s usually in relation to making a lot of logos with very different aspect ratios look evenly sized so that none of them stick out like a sore thumb.

I haven’t had to do this in a while but came across a tweet by Nick Sherman that prompted me to think about it again.

To achieve an evenly-sized group of images, you have to calculate a maximum width that is proportionate to the surface area you want. To do this, you need to be able to calculate a square root, you need the width and height of each original image, and all of your images need to be tightly cropped since extra negative space will throw things off visually.

In the past, I’ve achieved this with logic since vanilla CSS doesn’t currently support a sqrt() function (more on this later). I’ve usually used PHP since I tend to work with Kirby CMS pretty often.

The function in PHP:

function max_img_width($img_width, $img_height, $ideal_area) {
  $max_width = round($img_width * sqrt($ideal_area / ($img_width * $img_height)));
  echo $max_width;
}

And the function in use + corresponding HTML:

<img style="max-width: <?php max_img_width(1500, 3000, 40000); ?>px;" src="https://piperhaywood.com/my-image.jpg">

A CSS-only solution that works now

There seems to be a CSS-only way to go about this though. Apparently you can approximate square roots in CSS by using a series of CSS variables and calc(), see more info in this thread.

Here’s the CSS and the image markup:

img {
  --width: 0;
  --height: 0;
  --ideal-area: 40000;
  --area: calc(var(--logo-width) * var(--logo-height));
  --ratio: calc(var(--ideal-area) / var(--area));
  --guess01: calc(calc(var(--ratio) + calc( var(--ratio) / var(--ratio))) / 2);
  --guess02: calc(calc(var(--guess01) + calc( var(--ratio) / var(--guess01))) / 2);
  --guess03: calc(calc(var(--guess02) + calc( var(--ratio) / var(--guess02))) / 2);
  --guess04: calc(calc(var(--guess03) + calc( var(--ratio) / var(--guess03))) / 2);
  --guess05: calc(calc(var(--guess04) + calc( var(--ratio) / var(--guess04))) / 2);
  --guess06: calc(calc(var(--guess05) + calc( var(--ratio) / var(--guess05))) / 2);
  --guess07: calc(calc(var(--guess06) + calc( var(--ratio) / var(--guess06))) / 2);
  --guess08: calc(calc(var(--guess07) + calc( var(--ratio) / var(--guess07))) / 2);
  max-width: calc(var(--width) * var(--guess08) / 2 * 1px);
}
<img style="--width: 1500; --height: 3000;" src="https://piperhaywood.com/my-image.jpg">

I’d want to do some more browser testing since this results in a pretty gnarly calc() situation by --guess08, but at first glance this seems like it might be a worthwhile solution. It doesn’t give us exactly proportionate surface areas but it gets very close. It only starts to fall apart with super skyscraper-y and letterbox-y images.

A few quick notes regarding why this is written as it is and ways that it could be tweaked:

I capped the number of guesses at eight because any more seemed to just fail, Chrome and Safari wouldn’t interpret such a big calc() equation.

I set the default width and height to zero so that there is no max width restriction if the image tag is missing the width and height CSS variables. This could be changed, as could the ideal area variable (increase to get larger images, decrease to get smaller).

The 1px value in the max-width calculation is required so that the value is interpreted as a unit. That said, it doesn’t have to be pixels! Could change this to another unit like 1em or 1%.

If I wanted to display these evenly centred, I’d probably give the images some margin and then wrap them in a container with styles as below:

.container {
  align-items: center;
  display: flex;
  flex-wrap: wrap;
  justify-content: center;
}

Could also use CSS grid for a more consistent spacing result.

And a final reminder: this only visually scales the images. Try to avoid loading a 3000px wide image if you’re going to be displaying it around 200px wide, your users and the planet will thank you.

A CSS-only solution that might work in the future

So apparently more complex math functions including sqrt() might be coming to CSS in the future! See this issue raised by Lea Verou in the CSS specifications editor’s drafts repo and the exponential functions section from CSS Values and Units Module Level 4 in the W3C editor’s draft from 3 February 2020 (a couple days ago!).

I’m not sure when this would become part of the spec and no idea if / when the browsers might implement them, but here is a snippet that should work with that new function in theory:

img {
  --width: 0;
  --height: 0;
  --ideal-area: 40000;
  max-width: calc(var(--width) * sqrt(calc(var(--ideal-area) / calc(var(--width) * var(--height)))) / 2 * 1px);
}

I’m happy that Nick asked the question on Twitter, I actually need this on an upcoming project where I’ve only got Twig to work with which doesn’t support square roots, and I’d prefer to avoid JavaScript in this instance. Hopefully this is the solution, will update here if so.

A picture says a thousand words, so see Nick’s very nice demo of area-based image sizing with CSS to check out one possible outcome.


Edit 05.02.20

Edited a few words for clarity, added Nick’s demo, added future example incorporating a CSS-based sqrt() function.

Thanks Sam Baldwin for bringing future math function support in CSS to my attention!

Edit 06.02.20

Simplified the PHP + HTML example.

The original PHP + HTML example used a --max-width CSS variable instead of just applying a max-width directly. I used a CSS variable because I thought that they were compliant with a strict Content Security Policy that includes the style-src directive set to unsafe-inline. That assumption was incorrect, though there does seem to be some discussion about the topic.

Thanks Lizzie Malcolm for questioning the CSS var usage in the PHP example!

Edit 18.02.20

Changed parenthesis-enclosed arithmetic so that each is enclosed in calc(). Plain CSS seems to interpret arithmetic enclosed in parenthesis just fine, but SASS doesn’t seem to like it.

Selecting open, free, or commons licenses for content and code

Content and code licensing is a bit of a minefield.

The first thing to remember is that in the UK and USA at least, all creative works are automatically protected by copyright from the moment they are made. The creator retains exclusive rights to their work, and nobody can share, copy, or use the work without the creator’s direct permission unless they are sharing it in fair use (critique, comment, parody, etc.). This is the reasoning behind the classic “all rights reserved” statement you often see in relation to a creative work.

Cover of “Copy This Book” by Eric Schrijver

But it is foolish to believe that “all rights reserved” will always be respected for content online. Tumblr and other platforms have made it so effortless to share others’ work that the public perception of copyright is seriously warped. Creators are very welcome to reserve their rights to all of their work but if they’re releasing it online under such terms, they should be prepared for a lot of violations.

The nature of the Internet created a need for less restrictive copyright licenses, and a whole host of open, free, and commons licenses have filled the void. This is my experience navigating the space for my own work including some of the resources I’ve used, the licenses I have chosen, and my reasoning.

Continue reading

Switching from Google Analytics to Matomo (f.k.a. Piwik) on WordPress

It’s a new decade, time to leave Google Analytics.

A big part of me wants to say screw it, just get rid of analytics altogether. But I find it interesting. I’ve never used it to decide what to write, and I don’t think I ever will, but it’s just fascinating to find out what makes the rounds. I’ll never know why a short post about repairing my mom’s straw bag was my most popular post for years, but I’m glad to know a lot of people checked it out.

So I decided to keep my Google Analytics property in place and just locked it down as much as I could. I adjusted the script to respect users’ Do Not Track browser settings (Paul Fawkesley has a short article about how to do this). I also configured Google Analytics to anonymise IP addresses, and I deliberately disabled Data Collection for Advertising Features, Demographics and Interest Reports, User-ID, and all data-sharing settings. I also set a low data retention policy to make sure old data would get deleted.

None of this changed the fact that I was still sharing data with Google.

Read more

Date-based colour

Read “Dynamic, Date-Based Color with JavaScript, HSL, and CSS Variables” by Rob Weychert

This is such a useful article. His implementation on Tinnitus Tracker is definitely more involved than what I’ve done on this site, particularly what he’s done to account for inherent saturation levels and lightness vs luminance. And his colour wheel mapping is slightly offset from mine. I feel like August is the reddest month! I’ve wanted to reconsider the colour here for a while, particularly since the accessibility of some of the hues isn’t up-to-snuff. Rob’s write-up might make that adjustment a bit more straightforward which is a big relief.

I remember being really interested in where Grant Custer went with colour on his blog when I started screwing around with colour on this site. See his blog in 2013 on the Internet Archive. I wanted to see whether or not there was some way to ambiguously reflect where I was in the world, particularly since I live so far away from most of my family.

The first version of the colour experimentation on this site mapped the HSL values to the season, temperature, and time of day where I was at the time the site was visited. This is an example from Paris in late 2016. The hue value was mapped to the date/season (same as now), and the lightness was mapped to the time of day using Moment.js and Moment Timezone. The goal was to map the saturation to the weather where I was using the OpenWeatherMap API with stormy and cloudy days being less saturated, but that never came to be since the weather descriptions weren’t consistent enough. I ended up mapping the saturation to the temperature instead, but I don’t think it was quite as effective.

When I turned the site in to a blog first and foremost, I dropped the location and weather aspect. It could be fun to return to it since it might bring a bit more variation, particularly on the list page. Might be a little wild though, and it might be a massive headache to introduce location and weather on old posts… At bare minimum, I could probably incorporate the time of day as lightness. We’ll see!

“I don’t think we know how to separate when we’re feeling pity and when we’re feeling inspiration.”

A short surfing with coffee. It’s getting quiet as clients and collaborators head off for the holidays, so I played inbox catch-up this morning

Issue 227 of Rachel Andrew’s CSS Layout News is full of excellent reading and listening related to accessible and inclusive design. The link I dug most in to was “Future Accessibility Guidelines—for People Who Can’t Wait to Read Them” by Alan Dalton. His article led me to Liz Jackson’s Interaction 2019 keynote “Empathy reifies disability stigmas”. Part way through, she recommends the book Pathological Altruism. Looks like a big read (and it’s not cheap!) but it seems very worthwhile.

From about 8min 28sec in to her talk:

Step two of the design thinking process is defining the problem — but because disabled people are rarely able to lead, it often becomes us that are defined as the problem rather than the problem being defined as the problem. It becomes about what we can or can’t do, rather than how something does or doesn’t work for us.

So you have our insights gleaned, we’re defined as the problem, and then designers enter this iterative process of ideation, prototyping, and testing which leads to the unacknowledged stick stepper design thinking or as I call it, design thanking.

Because we’re expected to be grateful for that which has been done for us.

Her talk is roughly 20 minutes long and well worth a watch.

Thanks to Sam for the CSS Layout News recommendation.

Notes from MozFest 2019

This is super delayed! I typed up my rough notes right after MozFest finished in October but never pressed publish. Voila.

MozFest is 10 years old! This was their last year at Ravensbourne in London. Sad, but I’m excited to see where it heads next.

This is a haphazard brain-dump of everything I want to remember and follow up on, a lot of questions for future consideration and resources that I need to explore. See also Common Knowledge’s notes from MozFest written by Gemma Copeland.

Read more