Explore My Notes

A guide to responsive images | CSS Tricks

A pretty exhaustive overview of the HTML and CSS options that we now have for responsive image layouts. Here are some key takeaways:

  • Prioritise srcset for the best performance gains, <picture> for the greatest level of editorial control (think different images for dark mode, or completely different layouts on smaller/larger screens);
  • Setting the lowest resolution image within a srcset to the src value is normally best;
  • The RespImageLint tool is very useful for determining srcset sizes attributes;
  • There's also the LazySizes library for lazy-loading images;
  • Despite clever tooling, sizes remain tricky to get right and often benefit from templating abstractions (as does the whole responsive image malarkey in total);
  • If you need to be able to zoom in on an image and serve a higher resolution image as it happens, srcset lets you achieve that by specifying widths wider than the viewport i.e. 300vw;
  • Art direction using the <picture> element can be used to serve static images instead of GIFs for users who prefer reduced motion (there are any interesting niche use cases with links out to full resources);
  • The <picture> element also provides a chance to use more performant image formats such as WebP, whilst providing a graceful fallback for older browsers;
  • You can combine <picture> and srcset if needed, which may net some further performance savings;
  • Netlify (and a bunch of other CDN services) offer automatic image resizing based on URL parameters;
  • Don't forget the value of using object-fit and object-position to handle the bits in-between breakpoints as well;
  • There's also a huge list of further reading and sources at the end of the article.

📆 27 May 2020  | 🔗

  • HTML & CSS
  • Frontend
  • Web Design
  • web performance
  • image
  • responsive design
  • picture
  • srcset
  • src
  • object fit
  • object position
  • viewport
  • HTML
  • CSS
  • linter
  • tool
  • lazy loading
  • guide 

Latex.css | Vincent Dörig

A bespoke stylesheet that automatically styles semantic HTML to look like Latex.

Example of text styled like Latex, including author details, an abstract, and a contents table.
There's something super appealing to me with how clean Latex looks. I really don't think it gets enough credit for producing such nice looking content.

Pitfalls of card UIs | Dave Rupert

In some ways this outcome is the opposite of what you were intending. You wanted a Card UI where everything was simple and uniform, but what you end up with is a CSS gallery website filled with baby websites.

A great breakdown from Dave as to why the typical card UI pattern has some inherent issues. Some elements – like making cards all the same height and dealing with responsively collapsing card lists – are now irrelevant thanks to flexbox and CSS grid, but others are inherent to the format. Issues with block links are one potential headache, but you also present information in a slightly bizarre reading format and create a default UI hierarchy that demands a lot of borders. I feel like that last point subtly hits an issue I have with this site's design on the head. Interesting.

The perfect block link solution | CSS Tricks

An interesting look at a "block links" at "card links": when you want large sections of HTML to be one big clickable link. It's a very common pattern and something I've done a lot, but it's also deeply problematic. It creates a double-standard UX where it is now a pattern that I expect and therefore get annoyed at when it doesn't work: see a blog post, for example, as a card and I expect to be able to click anywhere to read the article. But at the same time, when I'm scrolling down a page on my phone it's incredibly frustrating when a seemingly blank area suddenly redirects me to a new page.

It's also a terrible pattern from an accessibility perspective, because the normal implementation – wrapping the whole section in an <a> tag – screws up navigation by screen readers. It can also impact keyboard users too.

So, overall, a common pattern that is now practically an expected user interaction but which has deep flaws and should likely be stamped out. That paradox is an issue. Vikas has done a good job of outlining the current solutions to that problem alongside their respective pros/cons and comes to an interesting conclusion. He argues for semantically marked up HTML segments (good ✔) with linked headlines and "read more" text (though with better copy than "read more"; also good ✔) which is then progressively enhanced with JavaScript to listen to click events within the parent element (interesting). That allows the whole section to be clickable for JS users, whilst providing semantically relevant links as a fallback, and can be further improved using the window.getSelection() method so that users can still select or highlight text without inadvertently "clicking" the card itself (excellent ✔✔). Clever little trick 👍

const card = document.querySelector(".card")
const mainLink = document.querySelector('.main-link')


card.addEventListener("click", handleClick)


function handleClick(event) {
  const isTextSelected = window.getSelection().toString();
  if (!isTextSelected) {
    mainLink.click();
  }
}

An introduction to the indie web | Chris Aldrich

I often end up feeling a little overwhelmed by the whole IndieWeb movement, but I found Chris has done a great job of breaking down a) what they're trying to achieve and b) why it can be useful at a personal level. There are times when I feel like I need to spend hours carefully reading over documentation and considering various implementation requirements to be a part of the IndieWeb. Chris reminds me that it's okay to pick and choose the pieces that make the most sense for me:

Everyone’s desires and needs will be different. Work on what you find most interesting and useful first...

📆 26 May 2020  | 🔗

  • Frontend
  • IndieWeb
  • mission statement
  • guide
  • implementation 

Harfest 2013 Playlist | Harry Violet

Whilst sorting out some old hard drives I discovered some videos from the cancelled 2013 Harfest festival (only link I could find now). I was one of only about a dozen people who didn't live locally and had already travelled down by the time it was cancelled, so we had a small acoustic set with the one band in a similar situation that evening at the farm it was meant to take place at. Anyway, I was trying to work out who that band was and stumbled onto this playlist. Unfortunately, it looks like most of the bands in the lineup are lost to time, but maybe this might stick around. There's something in this about the impermanence of the web...

Intro to JavaScript promises | Jake Archibald

An overview of JS promises for all skill levels. Starts with an excellent analogy of thread-blocking as sneezing:

You don't want to write code that's sneezy.

You can effectively think of promises as stripped-down event listeners. They wait for a specific thing to happen, then they trigger a response, whilst recording either a success or failure state. That makes them particularly useful for asynchronous functionality:

This is extremely useful for async success/failure, because you're less interested in the exact time something became available, and more interested in reacting to the outcome.

As a result, promises can have four states: fulfilled (yay!), rejected (failure...), pending (waiting around for the trigger), or settled (no longer pending). There's also thenable but... what?!

Because of these states, you can use promises to build sequential logic chains using then() and catch(). Jake's got a whole bunch of great code examples which are worth checking over for exact syntax and useful shortcuts. Because promises are effectively set once, they also allow you to reuse initial results. For example, if you fetch an array of URLs from an API using a promise, you can then keep referring back to the output of that promise to loop through the array and fetch data from each URL, without consistently re-fetching the original info.

Also useful to know:

Promise rejections skip forward to the next then() with a rejection callback (or catch(), since it's equivalent).

One of the hardest concepts when working with async logic is that content order is always unknown. For example, if you're fetching a list of URLs and then want to loop through that list to return article information, you can't just use a for loop. Loops aren't "async-aware", so they would output the content in whatever arbitrary order the promise had resolved in. Your code wouldn't always return the same result when given the same input – not ideal! Again, Jake has a useful example of how to convert that type of logic into a promise chain.

Better yet, promises give us the ability to make use of multi-thread data fetching within the browser:

Promise.all takes an array of promises and creates a promise that fulfills when all of them successfully complete.

That can actually reduce your code length and significantly increase load times. Neat.

Jake also takes a look at how generators in JS can help write async code in a way that reads like synchronous code. Also neat.

Generate an SEO-friendly sitemap for Gatsby | Josh W Comeau

Josh keeps publishing articles that are both interesting to read and specifically useful to problems that I'm currently working on, but this time his article became the inspiration to solve a problem I've been ignoring for ages. As a result, my site should now have a sitemap (hooray!) thanks to this excellent tutorial on gatsby-plugin-sitemap. It was incredibly easy to follow, so I figured I'd log it here in case I ever need to come back to it 👏👏

I also fully endorse this sentiment:

I really don't want to have to care about SEO. It's all very nebulous, and it attracts so many snake-oil salespeople. SEO websites are the worst. And yet, if you want people to see the stuff that you build, SEO remains super important.

I don't think I mind that much about the discovery side of SEO, but when getting a boost is this simple why not go for it? I may not be chasing views, but I also don't want to hinder them.

Fix paper feed issues Canon Pixma MG5750 | Canon

More for personal use than as a note. Our Canon Pixma printer (model number: MG5750) is pretty excellent, but over time the likelihood of it actually printing when asked has decreased. The number one culprit is an inability to pull in paper, no matter what we do. Today that reached a head when printing some pictures and left us functionally without a printer, so I did some Googling and found this troubleshooting guide by Canon. On the one hand, it's pretty hidden; on the other, it's great that it exists at all.

Turns out there's a maintenance mode which "cleans" the feed rollers. No idea what it actually does, but my guess is some form of percussive maintenance, hence the warnings not to do it too often. Whatever it did worked though, and our paper is now gliding through smooth as a hot knife through butter 👍

📆 18 May 2020  | 🔗

  • Technology
  • printer
  • Canon
  • Pixma
  • MG57500
  • troubleshoot
  • guide
  • fix
  • paper 

The Langhalm Moor community buyout | Rewilding Britain

A great community project happening in Langham, just into South Scotland and only a stone's throw from where I grew up. It's a beautiful area with plenty of wildlife already (including a solid population of endangered hen harriers), which makes this plan to turn an old grouse moor into a nature reserve doubly excellent. Of course, I can't help but feel a little smug that the grouse moor has become "no longer economically viable" too 😏

The only issue is that they need to raise a whopping amount of money: £6m. I've donated a small bit (what I can, considering everything right now) and you can too, but even if their crowdfunding is fully successful they're still only halfway there. I'm hopeful that government grants might cover some of that cost (so are they) but it still feels crazy that effectively fallow land can cost that much to become a nature reserve. Fingers crossed 🤞

📆 18 May 2020  | 🔗

  • Natural World
  • rewilding
  • Langham
  • moor
  • grouse moor
  • nature reserve
  • conservation 

Medieval road-trips and the invention of print | I Love Typography

The tale of Hans Gensfleisch, later Johannes Gutenberg, and the invention of the Gutenberg press. Packed with interesting historical tidbits:

  • The Austrian city of Strasbourg was known as Argentina during Medieval times – a reduction of Argentoratum as it was called by the Romans – and frequently appears under that title in manuscripts;
  • During his time in Strasbourg, Hans/Johannes likely witnessed the completion of the impressive cathedral, then that tallest building in northern Europe;
  • Our modern-day interpretation of "roman fonts" (think Times New Roman) aren't Roman at all. They're based on the mistaken identification of what was actually Carolingian minuscule, a script invented during the time of Charlemagne and later revived by Italian humanists;
  • I really like the image of Medieval pilgrimage as the equivalent of modern wanderlust and can't help but wonder if their pins aren't that far removed from modern backpacker pins 😂;
  • It's also amazing to know that pilgrim badges were effectively curios, to the extent that you could buy "parody" versions, often phallic or obscene variants of common pins – they truly were just gap-year students after all!
  • Gutenberg got his main start (certainly as far as we can tell) by making and selling badges for the Aachen pilgrimage, including ones with mirrors in them that could "capture the relics' reflection or 'sacred emanations'" and allow pilgrims that couldn't get close to the most sacred of relics to still leave with some amount of their divine blessing;
  • Gutenberg and his business partners were effectively building their press in secret. If true, that would make Strasbourg the source of Gutenberg's revelations around printing, something which is not unlikely. He was already casting metal objects in the form of pilgrim badges or pins and one of his business partners owned a paper mill, so all the pieces of the puzzle were present.

The myth of perfect ARIA support | Eric Bailey

A look at why ARIA should be treated like any other web technology:

All web technology has compatibility issues... [and] ARIA is a web technology.

In other words: use semantic HTML wherever possible so that you keep ARIA use to a minimum; break complicated interactions down as much as possible to prevent ARIA overlapping and getting muddled; always check for support (like you would with any other web language); use automated accessibility tools like WAVE and Axe; test your code. Just like JavaScript, CSS, or anything else, it's best to keep things simple so, as Eric puts it:

ARIA should be the last tool you pull out of your toolbox, not your first.

📆 18 May 2020  | 🔗

  • Inclusion
  • ARIA
  • compatibility
  • semantic HTML
  • accessibility
  • a11y
  • WAVE
  • Axe 

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.