Explore My Notes

YouTube's copyright system isn't broken; the world's is | Tom Scott

Ever had any questions about copyright and fair use? Chances are this video will answer them (and, depressingly, chances are the answer is "No, that isn't fair use; yes, you need to pay a license fee"). It certainly helped clear up a number of things for me, whilst (as ever with anything Tom does) being clear about what is/isn't a grey area – and why those grey areas maybe don't matter.

I think Tom makes an extremely well-reasoned argument for why the current system is fundamentally broken, how YouTube's Content ID system is a pretty excellent bandaid that cannot and should not be relied on (but also shouldn't be trashed), and what we can do about. Chiefly, reduce copyright to a maximum of 50 years 👍

There is one thread throughout all these examples: under the current system it often doesn't matter who is actually in the right. Even if the answer to "Is it fair use?" is clear, it's actually about whether you can afford to defend a case. You could be 100% sure it's fair use, but unless you're prepared to spend the time and money to actually fight that in court? It. Doesn't. Matter.

The same, but different: breaking down accessibility, universality, and inclusion in design | Matt May

A great review of the differences and similarities between universal design, inclusive design, and plain old accessibility, from one of the originators of universal design within the web community (as Matt points out the concept's roots go back to architecture in the 1980s, which I hadn't realised).

Some useful definitions:

Accessibility is the goal to ensure that products support each individual user’s needs and preferences. This is a pretty broad definition, I’ll
admit. Notably, it doesn’t define people with disabilities as the beneficiaries, and that’s on purpose.
Universal design is the design of products and environments to be usable by all people, to the greatest extent possible, without the need for adaptation or specialized design.

Matt doesn't explicitly try to define inclusive design, but I like this attempt from OCAD U in Toronto that he highlights:

We have defined Inclusive Design as: design that considers the full range of human diversity with respect to ability, language, culture, gender, age and other forms of human difference.

I also really like this analogy of how you might define climbing a mountain in the context of inclusion:

Inclusive design is the practice of going up the mountain — we can always look for ways to include more people and situations to our designs, even if the result only gets us a few steps up the trail at a time.

Universal design, by contrast, implies that reaching the summit is the true goal. It’s all well and good to talk about inclusion, but if we’re happy enough making it to the first campground up the trail, we’ll never even try to accommodate the effort needed to go all the way.

How to change the background colour of a word in InDesign | Stack Exchange

I'm using InDesign increasingly it seems and overall I really dig it, but I recently ran into a fairly simple problem that doesn't have an official solution: inline code styling. It's pretty much a standard these days to highlight inline code with a background colour, something like this: <strong>. However, InDesign doesn't allow you to set background fill for a single word (or partial string of any kind).

Luckily, there is a workaround, which I found thanks to the user Wolff over on Stack Exchange. You use a ridiculously large underline effect to mimic a background (with non-breaking spaces for additional padding). Just select the word or phrase, go to the Character Style menu and edit the Underline Options like so:

Screenshot of Character Style Options panel in InDesign, with Underline Options selected. Underline is checked to "on", weight has a value of "13pt", type is a bold line, tint 100%, and color is set to a green. All other options are deselected.
Little tip: whilst setting up your inline code style, don't forget to save it. Makes applying it throughout a document incredibly simple.

Noopener, noreferrer, and nofollow explained | Point Jupiter

I can never remember what the differences are between noopener, noreferrer, and nofollow, or when best to use them, so here's a handy guide that covers pretty much all of the basics.

Tl;dr:

  • All three are values for the rel attribute on <a> tags;
  • There's no point using any of them unless you have target="_blank" set (i.e. the link will force a new tab to open), and if you do you should use noopener to reduce cross-site phishing risks (there's no downside);
  • Their primary goal is to restrict the access the linked page has to your website/the page linking to it;
  • noreferrer blocks analytics tracking, which you probably don't want to do (but I guess is a way to subtweet via the indie web 😂). It also prevents SEO cross-linking scores, so if you really hate a linked website and don't want to boost it in search, then use this value;
  • Ditto nofollow, though this is relevant regardless of what the target is; it just stops search engine crawlers from traversing the link, so ideal if you have it go somewhere you don't want associated with your site or search indexed, or if the link is doing fancy stuff (i.e. it should be a button 😉). There's a valid point here that user-generated content (such as comments) can benefit from applying nofollow by default, to reduce spam efficacy;
  • Apparently, nofollow is a requirement for sponsored links and ads, so you don't generate clickthrough revenue based on spiders.

(PS: the article's own tl;dr is arguably even more concise and worth a read)

How to play board games online | Masilotti

Now here's something I've been looking for: online (non-Flash) versions of popular board games. It feels like this industry should be booming right now! Board Game Arena looks pretty interesting, with a lot of great games, multiplayer options, and a cheap premium track of only $4 a month (guests can play for free). I also hadn't realised that Steam has a decent selection.

What is timeless web design? | Chris Coyier

An interesting thought experiment from Chris: if a client asked you to build a website that could last a minimum of 10 years, what would you do? Lots of influential people in his answers, but I'm most interested in some of the proposed solutions. Basically:

  • Use semantic HTML and CSS; minify JS as much as possible (and obviously no JS frameworks or dependencies);
  • No externally hosted resources or data i.e. you can't call out. Either inline, self-host, or remove everything external;
  • Clean, minimal design; simple colour palette; good typography (several people recommend system fonts, but I actually feel it would be best to host font files locally and fall back to "classic" system fonts. You never know when Windows might kill Arial, or when a new OS suddenly takes off);
  • Consider internationalisation support (who says English is the main language in 10 years?);
  • Stick to viewport units wherever possible to adapt to new screen resolutions and sizes; ditto SVG;
  • Minimal copy – "even words go stale";
  • Register the domain and hosting for the full 10 years upfront and set up auto-renewal of stuff like SSL.
Based on experience and observation in my time in the industry, I’d say it’s somewhere around 75% of websites are completely gone after 10 years, let alone particular URL’s on those websites being exactly the same (reliable external resources).

Using the URL to build database-free web apps | Bryan Braun

In all of these apps, every change you make updates the URL, instantly saving your progress in an easily sharable link. You don’t have to create an account or log in. In fact, you couldn’t if you wanted to because there’s no database! These apps are completely static.

What a fun idea. I've obviously seen (and have used) URLs contain state information in the past, such as user preferences (light/dark mode or animation), but building an entire game using nothing but URL parameters is pretty slick. The tip of encoding into base64 is great, too, as that really maximises what you can do with the space you have, though it does hurt extensibility (and readability) for your users.

13 days of WCAG 2.1 web accessibility guidelines | Sparkbox

Kasey mentioned this blog post in her talk yesterday. I wish I'd checked it out sooner, as it pretty much covers my notes from her (excellent) presentation but with greater clarity 👍 The perfect overview of the main WCAG 2.1 guidelines that all websites should strive to meet.

The cost of javascript frameworks | Tim Kadlec

Oh dear. Tim's put together some actual numbers on the impact that using a frontend framework has on the user. As a proponent of the Jamstack, which pretty much has JavaScript frameworks at its core, these types of articles are always worrying, but they remain absolutely necessary information. So let's rip off the band-aid:

Sites with Angular ship 344% more JavaScript on desktop at the 10th percentile, and 377% more on mobile. Sites with React, the next heaviest, ship 193% more  JavaScript on desktop and 270% more on mobile devices.

Ouch 😢

Vue fares a little better, then comes jQuery (no real surprises there), with "vanilla" websites in the lead (again, not surprising; as Tim puts it, you can't start with JavaScript and expect to ship less). Thread times are similar, though here React is bottom of the pile by a clear margin:

React sites bring up the tail end, spending 248% more time on desktop devices and 658% more time on mobile devices. No, 658% is not a typo. At the 10th percentile, sites with React spend 2.7s on the main thread dealing with all the JavaScript sent down.

In comparison, Angular is rocking 230%-313% at the 10th percentile. This gets "better" as you begin looking at worse sites (i.e. the 90th percentile), but the overall trend persists and the numbers are still terrifying. At the tail-end, React sites are spending 20.8 seconds just parsing the JavaScript! Even more damning for React is that single-framework sites (which should perform better across the board) actually end up performing worse for the bottom 50%. Quite why is debatable, though Tim argues for site migrations meaning that some React sites are still offloading a lot of the work to jQuery, which remains more performant.

Worse still is how badly these framework-based websites perform on mobile.

Even at the 10th percentile, React sites spend 431.5% more time on the main thread on mobile devices as they do on desktop devices.

That's equivalent to over 10 seconds just to load the page properly... Still, whilst these results are even more damning than I would have predicted, there is room for hope. Tim is right in suggesting that vanilla JavaScript is the best alternative, but he also points to other technologies which could be a positive trade-off. More performant frameworks like Svelte and Preact help a lot; SSGs such as Gatsby, NuxtJS, and NextJS also give you massive savings (whew 😊).

He even points out that there are some forks and tools beginning to appear that simply strip all that JS out of the shipped site. For instance, the No JS Gatsby plugin looks pretty great; probably something worth experimenting on for this site.

📆 23 Apr 2020  | 🔗

  • Frontend
  • JavaScript
  • React
  • performance
  • web performance
  • Gatsby
  • Jamstack
  • Angular
  • VueJS
  • NextJS
  • NuxtJS
  • data 

The thousand island archipelago | Matt Sterne

Indonesia is a part of the world high on my "to visit" list. Between Komodo dragons, Homo floresiensis, the Wallace Line, and – of course – the delicious satay dishes, there's a lot that draws me to this region. Matt's write-up of his own trip is a little OTT at times, but it contains some useful information and a cracking itinerary. I had no idea that Borobodur was the biggest Buddhist temple in the world, for example.

Also, Matt notes this rather wonderful piece of folklore:

A long time ago, [the Dragon Princess] gave birth to twins, a human boy called Gerong and a female dragon called Ora. They separated at birth and reunited as adults in the forest, over a shared love of deer meat. Ever since then, the islanders have considered the Komodos their sacred ancestors and have lived in relative harmony with  them...

How the blog broke the web | Amy Hoy

A fascinating breakdown of how the early web was forever changed by one of the first truly popular CMSs: MovableType. Most importantly, this is the likely culprit as to why so much of the web is now sorted chronologically, even though that may be a terrible model for what web pages actually are.

📆 19 Apr 2020  | 🔗

  • Frontend
  • MovableType
  • web
  • history
  • CMS
  • information architecture
  • blog 

Made By Me, But Made Possible By:

CMS:

Build: Gatsby

Deployment: GitHub

Hosting: Netlify

Connect With Me:

Twitter Twitter

Instagram Instragram

500px 500px

GitHub GitHub

Keep Up To Date:

All Posts RSS feed.

Articles RSS feed.

Journal RSS feed.

Notes RSS feed.