Exploring code on Charles Reynolds-Talbot

The Dark (Mode) Web Rises

Wed, 28 Nov 2018 20:50:37 +0000

This is part 3 in a series about why we need Dark Mode to be an inclusive design consideration.

Molly Watt
Apple need a Dark Mode
The Dark (Mode) Web Rises

In 2016, I met Molly Watt.

I was inspired by Molly and her experience of living with Usher Syndrome; a condition that has left her deaf with 5–degree vision in one eye. I wrote about my immediate desire to solve some of the problems Molly faces with using digital products.

Then, in 2017, I wrote a follow up post on how Apple (and others) need a Dark Mode; a system-level preference setting that would affect the interfaces of native, third-party apps and websites.

This year (2018), we were gifted with an update to MacOS: Mojave. Mojave shipped with a system-level Dark Mode preference setting. Finally!

Turning on Dark Mode in Mojave made instant changes to the system interface and the native Mac apps. Soon after, third-party apps started to release updates that took advantage of this preference setting too; making their interfaces work in Dark Mode. But, there was still a gap: websites.

Whilst the Safari app supported Dark Mode, there was no change to the content of the websites viewed through it. Glaring white websites were still glaringly white. It felt like a giant leap in the right direction but a small step short: until now.

Give yourself to the dark side

Please, allow me to introduce you to the prefers-color-scheme CSS media query.

Media queries are used to modify a website depending on specific characteristics (print, size, orientation, etc).

Now, we have one to detect if a user has set system-level preferences to use a light or dark colour theme.

MacOS Mojave has system-level colour preferences

This feature is not yet ready for use on general release browsers but it’s coming soon. Safari Technology Preview 68 added support last month so hopefully, it won’t be long before this finds its way into a mainstream Safari release.

Add support for Dark Mode on your website

Developers can (and should) start getting their websites ready for Dark Mode. You can install Safari Technology Preview now and start designing the perfect Dark Mode theme using colours that compliment your brand and work consistently across your website.

A simple example, to get you started:

@media screen and (prefers-color-scheme: dark) {
 body {
 background-color: black;
 color: white;
 }
}

Dark by default

You might notice that my own website is dark by default. I have made this decision as it’s not only my preference but I know it works better for Molly and for users in certain scenarios (browsing at night, migraines, hangovers, etc). Designing for the few, makes things better for the many.

I’ve used the prefers-color-scheme CSS media query to target the light preference. If you are using Safari Technology Preview on Mojave and have your preferences set to light you’ll see the light theme of my website.

You do this using:

@media screen and (prefers-color-scheme: light) {
 body {
 background-color: white;
 color: black;
 }
}

The future is dark (a good thing)

I am a designer at the UK government. This series of posts started as a result of wanting to influence the design of GOV.UK (a typically white website) so that it works better for users like Molly Watt.

So far, I haven’t got very far with this. Every potential solution seemed to come with a degree of risk and complication when considering the design principle: this is for everyone.

I reckon that using prefers-color-scheme CSS media query is a risk-free low-impact solution. It will give GOV.UK a Dark Mode for the users that prefer one and remain the same for everyone else. I’m going to prototype this and start pushing to make it happen.

I’m hopeful that, the more websites (and big brands) that implement and blog about their Dark Modes, the more chance we’ll have of seeing this feature across all browsers (not just Safari).

Other platforms need to start introducing their own system-level Dark Mode preference setting to work this way too.

Look out for a similar feature coming to iOS soon.

I can’t wait to see how websites take advantage of this new CSS media query. Share how you use it: tweet me @charles_rt or toot me @crt.

Better responsive iframe for embedded YouTube video

Thu, 09 Aug 2018 08:03:51 +0100

I started to include embedded music videos from YouTube on a couple of blog posts, just for fun.

This presented an interesting challenge; YouTube videos are embedded in iframes. You can give them a fixed height and width which ensures they display correctly but then they overflow the screen on a smaller viewport. Alternatively, you can specify a width of 100% which makes the width respond as intended but there’s no way to get the height to comply and maintain the correct aspect ratio.

I searched online and found a couple of solutions; neither of which I was keen on.

Extra HTML

The first common solution I found involved adding an additional div.wrapper around the iframe and applying CSS to both. Whilst this does work, I didn’t want to have to add extra HTML for stylistic purposes. I should be able to do this job using CSS only, on the main element.

Javascript 😒

The second solution involved the use of javascript which I wasn’t interested in. If I can get away with it, I don’t want to use any javascript on this site.

A better solution using calc()

After [a lot of] trial and error, I discovered a great use for calc(). The calc() function lets you perform calculations on CSS property values.

The clever part that makes this work is knowing the width of my main content containing block: 512px. I don’t need to worry about the iframe being responsive beyond this width. I know the width it should be. I can specify the appropriate height for a 16:9 widescreen aspect ratio.

I set width: 100%; as this should always be true even though I know the exact width it makes things simpler later. I then set height: calc((512px / 16) * 9);. Technically, I don’t have to do this. I could calculate the height manually as it won’t change when the width is above 512px but I’ve left the calculation in so you can see what changes later to make the magic happen. (512px / 16) * 9 equals the correct height for a 16:9 widescreen aspect ratio when I know the width is 512px.

When the viewport is narrower than 512px, I use a media query to make the iframe respond accordingly. The width is already set to 100% so I don’t need to worry about that. It’s the height I need to start responding at the correct size to maintain a 16:9 widescreen aspect ratio. The width of the viewport is suddenly very relevant to help achieve this. I am able to find out what the width of the viewport is by using vw as a measurement unit.

vw is equal to 1% of the width of the viewport and the browser knows what this is whenever it changes. I can use the measurement of 100vw in my calculation to track the width of the viewport and serve up the right height to maintain a responsive aspect ratio with height: calc((100vw / 16) * 9);

iframe {
 width: 100%;
 height: calc((512px / 16) * 9);
}
@media (max-width: 512px) {
 iframe {
 height: calc((100vw / 16) * 9);
 }
}

That’s it: a better responsive iframe for embedded YouTube videos using CSS only, on the element.

Dat’s the way I like it

Fri, 03 Aug 2018 19:10:07 +0100

I committed to supporting a decentralised peer-to-peer web by serving my site over dat:// as well as https://. Since starting this I have been stumped as to how to make my url over dat:// friendly, because dat://59278ae8cc9d27492b4a0a5d4392ff3c913aebd8fa079760ce732f26b70c4eef (open in BeakerBrowser) is just mean.

I could see other sites had achieved this. Beaker’s own site does exactly what I wanted with dat://beakerbrowser.com/ (open in BeakerBrowser).

I read several docs about it and kept getting confused to the point that I’d give up, hoping to return later with a fresh mind and try again.

Eventually, I have succeeded and it is ridiculously easy so I’ll share a simple step-by-step guide so you don’t have to do through the same pain.

Create a folder called .well-known in the root of your https:// served directory.
Create a file called dat in that folder.
Add the following code to that file, replacing {key} with the mega long dat URL key to your site. Fe, dat://59278ae8cc9d27492b4a0a5d4392ff3c913aebd8fa079760ce732f26b70c4eef
```
dat://{key}
TTL=60
```
Save and upload to wherever you host your https:// site.
Now, visit your site in BeakerBrowser but use dat:// instead of https:// as the URL and automagically it works 🎉

dat://charlesrt.uk is finally working and it turns out it was easy peasy hotdog squeezy.

This is my baseline

Thu, 26 Jul 2018 16:47:08 +0100

I’m throwing caution to the wind and forgetting about global CSS resets like normalize.css and Eric Meyer’s reset.css because:

I’m not convinced I need to make use of everything in these resets (I don’t even know what <kbd> is 🤷‍♂️) or support all the browsers they attempt to. Does it matter if someone visits my tiny website in IE8 and something doesn’t look perfect? I’ll give you a hint: no.
They’re pretty bloated because they’re trying to fix everything for everyone. I don’t need 341 lines of code before I’ve even written a line of my own.
There’s no point in resetting something that I’m just going to override later. I should declare the values I want to set and forget the reset.

This is my master plan: to lay only the CSS foundation I need to—when I need to—and layer on my opinionated component styling to serve as my own default for building websites: my baseline.

My Baseline

This post is out of date relative to the CSS I’m currently using on this site. I will update this and create a repo as soon as possible.

:root {
 font-family: system-ui,
 -apple-system,
 BlinkMacSystemFont,
 "Segoe UI",
 "Roboto",
 "Oxygen",
 "Ubuntu",
 "Cantarell",
 "Fira Sans",
 "Droid Sans",
 "Helvetica Neue",
 "Apple Color Emoji",
 "Segoe UI Emoji",
 "Segoe UI Symbol",
 sans-serif;
 font-size: 16px;
 line-height: 1.5;
 overflow-wrap: break-word;
 -ms-text-size-adjust: 100%;
 -webkit-text-size-adjust: 100%;
 -webkit-font-smoothing: antialiased;
 -moz-osx-font-smoothing: grayscale;
 -webkit-tap-highlight-color: transparent;
 background: black;
 color: silver;
}
body,
blockquote,
figure {
 margin: 0;
}
main {
 display: block;
 max-width: 512px;
 margin: 0 auto;
 padding: 0 1em;
}
h1,
h2,
h3,
h4,
h5,
h6 {
 font-weight: bold;
 font-weight: 800;
 line-height: 1;
}
h1 {
 font-size: 4rem;
 margin-top: 4rem;
 margin-bottom: 4rem;
}
h2 {
 font-size: 2rem;
 margin-top: 4rem;
 margin-bottom: 2rem;
}
h3 {
 font-size: 1.5rem;
 margin-top: 2rem;
 margin-bottom: 1rem;
}
h4 {
 font-size: 1rem;
 margin-top: 1rem;
 margin-bottom: 0.5rem;
}
p {
 margin-top: 1rem;
 margin-bottom: 1rem;
}
a {
 color: aqua;
}
a:link,
a:visited {
 color: aqua;
}
a:hover,
a:active,
a:focus {
 color: yellow;
}
img {
 max-width: 100%;
 height: auto;
}
figcaption {
 color: gray;
}
pre,
code {
 background: navy;
 color: gray;
 font-size: .875rem;
 letter-spacing: .05rem;
 padding: .125rem .25rem;
}

Let’s break it down.

Images

One of the immediately obvious problems viewing my website using only native browser styling is how images are rendered: huge. Well, full size to be fair, but in all circumstances that full size is much bigger than your average viewport. On mobile it’s just ridiculous so let’s add some CSS to take care of this.

img {
 max-width: 100%;
 height: auto;
}

By using max-width: 100%; images will confine themselves to the <figure> element and stop overflowing the viewport. Aspect ratios are kept in check with height: auto;

Before

Clearly there’s a problem with lack of default img styling.

After

Much better. Now you can see me, Chris and the legendary Jake Knapp.

Margins

Now my images are in control it’s clear there are some unwanted margins present. It might be necessary to play with the content rhythm later but that’s a conscious design decision that’ll need be made. In the meantime everything should be aligned consistently.

body, blockquote, figure {
 margin: 0;
}

Before

Browser defaults have made design decisions for me.

After

Consistent alignment but too close to the edge.

All content is now aligned to the very edge of the viewport and is only constrained by the width of the users browser. This isn’t ideal and can make for some lengthy reading lines.

I’m going to solve this problem by wrapping the dominant content of the page in a <main> element with a maximum width of 512px. This keeps line lengths appropriate for better readability. The content block is centred with auto margins left and right, while a little padding keeps content off the edges of smaller viewports.

main {
 display: block;
 max-width: 512px;
 margin: 0 auto;
 padding: 0 1em;
}

Better

If only, browsers did this by default.

Typography

I’ve already started to address some typographic defaults by setting a maximum width on the content to maintain a readable line length. Time to get serious.

System fonts are the new black. All browsers should use system fonts by default. This means my website will use the same core font as the device you are using. Fe, San Fransisco on iOS or Roboto on Android.

Let’s go through them:

system-ui is future proofing this concept and the latest versions of Safari and Chrome already use this so eventually we don’t have to maintain a huge stack.
-apple-system, BlinkMacSystemFont is for Apple device users and dynamically uses the correct font depending on size between San Fransisco and San Fransisco Display.
"Segoe UI", "Roboto", "Oxygen", "Ubuntu", "Cantarell", "Fira Sans", "Droid Sans" take care of every other operating system I could find.
"Helvetica Neue" is for legacy Apple devices.
"Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol" force the use of the devices emoji fonts which are often more up-to-date than the browsers.
sans-serif if all else fails.

Not all browsers share the same font-size and line-height so setting defaults for this ensures consistency and provides a base to build off. 16px and 1.5 are a great default for better reading.

On occasion, I display full URLs as part of links in content. If lengthy, these can overflow the <main> container and cause some unwanted side-scrolling. overflow-wrap: break-word; stops this from happening.

The text-size-adjust declarations stop mobile browsers from scaling your text causing rendering issues. Why they do this: I don’t know.

It’s good to use font-smoothing to make text lighter and easier to scan. This also helps prevents occasional flicker on load or scroll and takes some load off browser performance too.

Finally tap-highlight-color hides the flicker that happens when you tap an element on mobile devices. I’ll need to ensure I have suitable hover states later so users get feedback to their interaction.

:root {
 font-family: system-ui,
 -apple-system,
 BlinkMacSystemFont,
 "Segoe UI",
 "Roboto",
 "Oxygen",
 "Ubuntu",
 "Cantarell",
 "Fira Sans",
 "Droid Sans",
 "Helvetica Neue",
 "Apple Color Emoji",
 "Segoe UI Emoji",
 "Segoe UI Symbol",
 sans-serif;
 font-size: 16px;
 line-height: 1.5;
 overflow-wrap: break-word;
 -ms-text-size-adjust: 100%;
 -webkit-text-size-adjust: 100%;
 -webkit-font-smoothing: antialiased;
 -moz-osx-font-smoothing: grayscale;
 -webkit-tap-highlight-color: transparent;
}

Before

This looks a little unpleasant and the browser doesn’t understand the latest unicode [emoji] characters.

After

A much better default.

Colour

Colour choice can be highly opinionated—such as my desire for ‘dark by default’ user interfaces—but there’s sound reason behind it you can read more about in Apple and others need a dark mode for people like Molly Watt.

Where possible, baseline colours should aim for strong Level AAA contrast ratios. Whilst Level AA is the minimum, there is rarely a need to go so low and higher contrast can be better for everyone. However, go too high and you could be introducing unwanted glare.

Be mindful of the colours you choose. This is where colour choice is less about opinion and more about responsible selection and use.

Another thing to be mindful of is links. Links are the cornerstone of the internet so it’s surprising they’re still not handled well by default.

Hover states should always be honoured regardless of whether the link has been previously visited or not. On that subject, visited links don’t need their own distinguished style; they should be styled the same as regular links. Don’t forget about focus states for keyboard users.

:root {
 background: black;
 color: silver;
}
a {
 color: aqua;
}
a:link,
a:visited {
 color: aqua;
}
a:hover,
a:active,
a:focus {
 color: yellow;
}
figcaption {
 color: gray;
}
pre,
code {
 background: navy;
 color: gray;
}

After

Dark by default; Level AAA colour contrast.

Font size and margins

A lot of CSS resets aim to do just that: reset. They take away any browser styling and make everything the same so you can declare the values you want after—but. You can do this anyway. There is no need to reset a value. Just declare your own from the outset.

I enjoy working with multiples of 8 and only tend to deviate for certain elements. You can achieve good progressive size and spacing this way: 8px 16px 32px 64px 128px.

I use rem as it’s easier to work from my root em measurement which is 16px.

h1,
h2,
h3,
h4,
h5,
h6 {
 font-weight: bold;
 font-weight: 800;
 line-height: 1;
}
h1 {
 font-size: 4rem;
 margin-top: 4rem;
 margin-bottom: 4rem;
}
h2 {
 font-size: 2rem;
 margin-top: 4rem;
 margin-bottom: 2rem;
}
h3 {
 font-size: 1.5rem;
 margin-top: 2rem;
 margin-bottom: 1rem;
}
h4 {
 font-size: 1rem;
 margin-top: 1rem;
 margin-bottom: 0.5rem;
}
p {
 margin-top: 1rem;
 margin-bottom: 1rem;
}
pre,
code {
 font-size: .875rem;
 letter-spacing: .05rem;
 padding: .125rem .25rem;
}

8 16 32 64 128.

Making progress

Wed, 25 Jul 2018 10:23:59 +0100

Things are still looking basic but I’m making progress

I’ve had some time away and I’m mostly relying on train journeys to make updates so progress has been slow but I’m getting somewhere.

All of the important content from my previous website build has been migrated and is better structured from a directory perspective. Redirects are in place to ensure I don’t break the web and I have a Gulp task running to compile Stylus (my preprocessor of choice) into CSS.

I’m ready to think about my design goals and how I will structure the content better for the user so that navigation is contextual and I’m getting across the right message and flow.

Before that, I’m going to consider what a good baseline CSS should be.

Style.less

Wed, 11 Jul 2018 09:54:15 +0100

No style here

Right now, things are looking a little basic.

Style Attribute {
 🤷‍♂️
}

The plan was to get the website up and running and let your default browser styles do the work, then carefully layer on top the bare minimum required to achieve the design goals I set.

You’d think I would have done more research into Hugo before choosing it as the framework to rebuild my website. It turns out it doesn’t natively do any CSS preprocessing. I don’t know why I assumed it did—I guess because so many static site generators do.

This isn’t the end of the world—I do know how to write in vanilla CSS—I’ve just gotten used to writing in syntax, like less, and taking advantage of the power that has to offer, such as variables, mixins, etc.

Not to worry. I’ll take a small break to add some sort of Gulp task and do some of the mundane work that needs doing first; like migrating all my old blog posts and making sure redirects are in place so as not to break the web.

Design goals

Wed, 11 Jul 2018 09:40:39 +0100

Design decisions will be based on a combination of the assumptions I make on what people might want, and the message and flow I want to get across.

I also want to achieving the following goals:

move away from Jekyll and build my site with Hugo which I’ve had my eye on ✅
use only contextual navigation; no “I don’t know what I want” menu
focus on typography; include emoji (the universal language of the future) at every opportunity 😉
allow for long and short form posts
create an owned space for my content to exist first before sharing to centralised social networks.

I’ll add to and revisit this list of goals as I go.

Hello World

Wed, 11 Jul 2018 08:24:18 +0100

A screenshot of my zero dawn refresh served over the peer-to-peer web via Beaker Browser. It works!

I have been meaning to redesign my website for a long time. I want to do more than just another re:skin so I am starting from scratch and designing the site live; partly to open my process to others who want to see and learn, partly to hold myself accountable so I do it properly.

Live design: means more than just having my code commits in the open on Gitlab. Instead of large wholesale design changes magically appearing on the internet, each individual change I make can be tracked live over dat:// the peer-to-peer web, enabled by the Dat Protocol. If you use BeakerBrowser you can turn on live reloading, to experience changes and blog updates auto refresh, as they happen. This, essentially, allows me to create a live blogging engine without any additional code.

You will still be able to refresh [the old fashioned way] over https:// if you use any other browser.

I can’t promise I will blog about the reason behind every design decision: but I will try.

This, is all part of my commitment to support a better, open and decentralised web for the future.