Link tags: ada

89

sparkline

Dark mode and variable fonts | CSS-Tricks

This is such a clever use of variable fonts!

We can use a lighter font weight to make the text easier to read whenever dark mode is active.

Web Sites as ‘Public Accommodation’ under a Pandemic | Adrian Roselli

If you dodged an accessibility lawsuit because you have physical locations, what does it mean when those physical locations close?

Good question.

As movie theaters, restaurant ordering, college courses, and more move to online-first delivery, the notion of a corresponding brick-and-mortar venue falls away. If the current pandemic physical distancing measures stretch into the next year as many think, then this blip becomes the de facto new normal.

Breaking looms by Matthew Ström

Another follow-on to my post about design systems and automation. Here, Matthew invokes the spirit of the much-misunderstood Luddite martyrs. It’s good stuff.

Design systems are used by greedy software companies to fatten their bottom line. UI kits replace skilled designers with cheap commoditized labor.

Agile practices pressure teams to deliver more and faster. Scrum underscores soulless feature factories that suck the joy from the craft of software development.

But progress requires more than breaking looms.

Adding Response Metadata to Cache API Explainer by Aaron Gustafson and Jungkee Song

This is a great proposal that would make the Cache API even more powerful by adding metadata to cached items, like when it was cached, how big it is, and how many times it’s been retrieved.

A short history of body copy sizes on the Web

A look at the trend towards larger and larger font sizes for body copy on the web, culminating with Resilient Web Design.

There are some good arguments here for the upper limit on the font size there being too high, so I’ve adjusted it slightly. Now on large screens, the body copy on Resilient Web Design is 32px (2 times 1em), down from 40px (2.5 times 1em).

How readable—Findings

The results are in for Daniel van Berzon’s most recent experiment into accurately measuring code readability. You can read the results and read about the methodology behind them.

HEAD - A free guide to `head` elements

A one-stop shop for all the metacrap you can put in the head of your HTML documents.

Morphosis: Goliath, David, Adam

A biblical short story from Adam Roberts.

Official Google Webmaster Central Blog [EN]: More options to help websites preview their content on Google Search

Google’s pissing over HTML again, but for once, it’s not by making up rel values:

A new way to help limit which part of a page is eligible to be shown as a snippet is the “data-nosnippet” HTML attribute on span, div, and section elements.

This is a direct contradiction of how data-* attributes are intended to be used:

…these attributes are intended for use by the site’s own scripts, and are not a generic extension mechanism for publicly-usable metadata.

Offline listings

This is brilliant technique by Remy!

If you’ve got a custom offline page that lists previously-visited pages (like I do on my site), you don’t have to choose between localStorage or IndexedDB—you can read the metadata straight from the HTML of the cached pages instead!

This seems forehead-smackingly obvious in hindsight. I’m totally stealing this.

PWA asset generator based on Puppeteer.

Automatically generates icons and splash screens based on Web App Manifest specs and Apple Human Interface Guidelines. Updates manifest.json and index.html files with the generated images.

A handy command line tool. Though be aware that it will generate the shit-ton of link elements for splash screens that Apple demands you provide for a multitude of different screen sizes.

In defence of graceful degradation and where progressive enhancement comes in by Adam Silver

This does a really good job of describing the difference between progressive enhancement and graceful degradation …but I don’t buy the conclusion: I don’t think that feature detection equates to graceful degradation. I do agree though that, when it comes to JavaScript, the result of progressive enhancement is that the language degrades gracefully.

This is progressive enhancement. An approach to making interfaces that ensures JavaScript degrades gracefully—something that HTML and CSS do automatically.

But there’s a difference between something degrading gracefully (the result) and graceful degradation (the approach).

German Naming Convention

Don’t write fopen when you can write openFile. Write throwValidationError and not throwVE. Call that name function and not fct. That’s German naming convention. Do this and your readers will appreciate it.

Bruce Lawson’s personal site  : Structured data and Google

Bruce wonders why Google seems to prefer separate chunks of JSON-LD in web pages instead of interwoven microdata attributes:

I strongly feel that metadata that is separated from the user-visible data associated with it highly susceptible to metadata partial copy-paste necrosis. User-visible text is also developer-visible text. When devs copy/ paste that, it’s very easy to forget to copy any associated metadata that’s not interleaved, leading to errors.

Is the universe pro-life? The Fermi paradox can help explain — Quartz

Living things are just a better way for nature to dissipate energy and increase the universe’s entropy.

No anthropocentric exceptionalism here; just the laws of thermodynamics.

According to the inevitable life theory, biological systems spontaneously emerge because they more efficiently disperse, or “dissipate” energy, thereby increasing the entropy of the surroundings. In other words, life is thermodynamically favorable.

As a consequence of this fact, something that seems almost magical happens, but there is nothing supernatural about it. When an inanimate system of particles, like a group of atoms, is bombarded with flowing energy (such as concentrated currents of electricity or heat), that system will often self-organize into a more complex configuration—specifically an arrangement that allows the system to more efficiently dissipate the incoming energy, converting it into entropy.

Readable Code without Prescription Glasses | Ocasta

I saw Daniel give a talk at Async where he compared linguistic rules with code style:

We find the prescriptive rules hard to follow, irrespective of how complex they are, because they are invented, arbitrary, and often go against our intuition. The descriptive rules, on the other hand, are easy to follow because they are instinctive. We learned to follow them as children by listening to, analysing and mimicking speech, armed with an inbuilt concept of the basic building blocks of grammar. We follow them subconsciously, often without even knowing the rules exists.

Thus began some thorough research into trying to uncover a universal grammar for readable code:

I am excited by the possibility of discovering descriptive readability rules, and last autumn I started an online experiment to try and find some. My experiment on howreadable.com compared various coding patterns against each other in an attempt to objectively measure their readability. I haven’t found any strong candidates for prescriptive rules so far, but the results are promising and suggest a potential way forward.

I highly recommend reading through this and watching the video of the Async talk (and conference organisers; get Daniel on your line-up!).

How Readable? | Clearleft

Cassie and I went to a great Async talk last night all about code readability, which was well-timed because it’s been on our minds all week. Cassie explains more in this post.

Sass Selectors: To Nest Or Not To Nest? | Brad Frost

The fascinating results of Brad’s survey.

Personally, I’m not a fan of nesting. I feel it obfuscates more than helps. And it makes searching for a specific selector tricky.

That said, Danielle feels quite strongly that nesting is the way to go, so on Clearleft projects, that’s how we write Sass + BEM.

inessential: The View-Source Web

Lesson learned: the discoverable and understandable web is still do-able — it’s there waiting to be discovered. It just needs some commitment from the people who make websites.

Laws of UX

  1. Fitts’s Law
  2. Hick’s Law
  3. Jakob’s Law
  4. Law of Prägnanz
  5. Law of Proximity
  6. Miller’s Law
  7. Parkinson’s Law
  8. Serial Position Effect
  9. Tesler’s Law
  10. Van Restorff Effect

Not listed:

  1. Murphy’s Law
  2. Sturgeon’s Law