Tags: rag

129

sparkline

Sunday, July 17th, 2022

Thursday, July 14th, 2022

Body Margin 8px | Miriam Eric Suzanne

I love this kind of spelunking into the history of why things are they way they are on the web!

Here, Detective Chief Inspector Suzanne tries to get to the bottom of why every browser has eight pixels of margin applied to the body element in the user-agent stylesheet.

Wednesday, July 13th, 2022

How normal am I?

A fascinating interactive journey through biometrics using your face.

Tuesday, April 26th, 2022

Progressively Enhanced Builds - Jim Nielsen’s Blog

Rather than thinking, “how do I combine a bunch of disparate content, templates, and tooling into a functioning website?”, you might think “how do I start at a functioning website with content and then use templates and build tooling to enhance it?”

I think Jim is onto something here. The more dependencies you have in your build process, the likelier it is that over time one of them will become a single point of failure. A progressive enhancement approach to build tools means you’d still be able to launch your site (even if it’s not in its ideal state).

I want to be able to view, edit, and if need be ship a website, even if the build process fails. In essence, if the build does fail I can still take all the source files, put them on a server, and the website remains functional (however crude).

Monday, April 4th, 2022

UA gotta be kidding

Brian recounts the sordid messy history of user-agent strings.

I remember somebody once describing a user-agent string as “a reverse-chronological history of web browsers.”

Thursday, November 4th, 2021

A Web Browser Built for Me • Robin Rendle

What I want instead is an anarchist web browser.

What I’d really like to see is a browser that cuts things out, that takes things away from the web. Colors, fonts, confusion. Do you need an enormous JavaScript engine under the hood to power a modern web browser? I don’t think you do. Do you need all the extensions? All the latest CSS features? Nah, mate.

Throw away everything and start again and focus intensely about what people care about when it comes to the web.

Monday, September 20th, 2021

New principle: Do not design around third-party tools unless it actually breaks the Web · Issue #335 · w3ctag/design-principles

There’s a really interesting discussion here, kicked off by Lea, about balancing long-term standards with short-term pragmatism. Specifically, it’s about naming things.

Naming things is hard. Naming things in standards, doubly so.

Tuesday, July 27th, 2021

Safeguarding music | Global Music Vault | Svalbard

This sounds like an interesting long-term storage project, but colour me extremely sceptical of their hand-wavey vagueness around their supposedly flawless technical solution:

This technology will be revealed to the world in the near future.

Also, they keep hyping up the Svalbard location as though it were purpose-built for this project, rather than the global seed bank (which they don’t even mention).

This might be a good way to do marketing, but it’s a shitty way to go about digital preservation.

Saturday, July 24th, 2021

Reflections as the Internet Archive turns 25

Brewster Kahle:

The World Wide Web at its best is a mechanism for people to share what they know, almost always for free, and to find one’s community no matter where you are in the world.

Friday, July 9th, 2021

Bruce Lawson’s personal site  : prefers-reduced-motion and browser defaults

I think Bruce is onto something here:

It seems to me that browsers could do more to protect their users. Browsers are, after all, user agents that protect the visitor from pop-ups, malicious sites, autoplaying videos and other denizens of the underworld. They should also protect users against nausea and migraines, regardless of whether the developer thought to (or had the tools available to).

So, I propose that browsers should never respect scroll-behavior: smooth; if a user prefers reduced motion, regardless of whether a developer has set the media query.

Saturday, July 3rd, 2021

The Internet Is Rotting - The Atlantic

A terrific piece by Jonathan Zittrain on bitrot and online digital preservation:

Too much has been lost already. The glue that holds humanity’s knowledge together is coming undone.

Tuesday, June 8th, 2021

mmm.page

This is a fun drag’n’drop way to make websites. And I like the philosophy:

Websites shouldn’t all look the same. We prefer campy, kitschy, messy, imperfect.

Monday, May 24th, 2021

Principles of User Privacy (PUP)

This looks like an excellent proposal for agreement around discussing privacy on the web.

The section on user agents resonates with what I wrote recently about not considering Google Chrome a user agent any more:

Its fiduciary duties include:

  • Duty of Protection
  • Duty of Discretion
  • Duty of Honesty
  • Duty of Loyalty

Monday, March 8th, 2021

Progressive enhancement and accessibility redux - QuirksBlog

This is a really interesting take on the intersection between accessibility and progressive enhancement (which I always felt was there, but this expresses it well):

Accessibility aims to optimize an experience across a spectrum of user capabilities. Progressive enhancement aims to optimize an experience across a spectrum of user agent capabilities.

Indeed, if you broaden the definition of “user agent” to include a user’s physiology, I think the concepts become nearly identical.

Tuesday, February 23rd, 2021

Introducing State Partitioning - Mozilla Hacks - the Web developer blog

This is a terrific approach to tackling cross-site surveillance. I’d love it to be implemented in all browsers. I can imagine Safari implementing this. Chrome …we’ll see.

Friday, December 18th, 2020

Conditional JavaScript - JavaScript - Dev Tips

This is a good round-up of APIs you can use to decide if and how much JavaScript to load. I might look into using storage.estimate() in service workers to figure out how much gets pre-cached.

Tuesday, December 15th, 2020

Are your Anchor Links Accessible? | Amber Wilson

I really like the way that Amber doesn’t go straight to the end solution but instead talks through her thought process when adding a feature to her site.

Thursday, November 12th, 2020

Caching and storing

When I was speaking at conferences last year about service workers, I’d introduce the Cache API. I wanted some way of explaining the difference between caching and other kinds of storage.

The way I explained was that, while you might store stuff for a long time, you’d only cache stuff that you knew you were going to need again. So according to that definition, when you make a backup of your hard drive, that’s not caching …becuase you hope you’ll never need to use the backup.

But that explanation never sat well with me. Then more recently, I was chatting with Amber about caching. Once again, we trying to define the difference between, say, the Cache API and things like LocalStorage and IndexedDB. At some point, we realised the fundamental difference: caches are for copies.

Think about it. If you store something in LocalStorage or IndexedDB, that’s the canonical home for that data. But anything you put into a cache must be a copy of something that exists elsewhere. That’s true of the Cache API, the browser cache, and caches on the server. An item in one of those caches is never the original—it’s always a copy of something that has a canonical home elsewhere.

By that definition, backing up your hard drive definitely is caching.

Anyway, I was glad to finally have a working definition to differentiate between caching and storing.

Wednesday, October 21st, 2020

Chrome exempts Google sites from user site data settings

Collusion between three separate services owned by the same company: the Google search engine, the YouTube website, and the Chrome web browser.

Gosh, this kind of information could be really damaging if there were, say, antitrust proceedings initiated.

In the meantime, use Firefox

Wednesday, October 14th, 2020

Saving forms

I added a long-overdue enhancement to The Session recently. Here’s the scenario…

You’re on a web page with a comment form. You type your well-considered thoughts into a textarea field. But then something happens. Maybe you accidentally navigate away from the page or maybe your network connection goes down right when you try to submit the form.

This is a textbook case for storing data locally on the user’s device …at least until it has safely been transmitted to the server. So that’s what I set about doing.

My first decision was choosing how to store the data locally. There are multiple APIs available: sessionStorage, IndexedDB, localStorage. It was clear that sessionStorage wasn’t right for this particular use case: I needed the data to be saved across browser sessions. So it was down to IndexedDB or localStorage. IndexedDB is the more versatile and powerful—because it’s asynchronous—but localStorage is nice and straightforward so I decided on that. I’m not sure if that was the right decision though.

Alright, so I’m going to store the contents of a form in localStorage. It accepts key/value pairs. I’ll make the key the current URL. The value will be the contents of that textarea. I can store other form fields too. Even though localStorage technically only stores one value, that value can be a JSON object so in reality you can store multiple values with one key (just remember to parse the JSON when you retrieve it).

Now I know what I’m going to store (the textarea contents) and how I’m going to store it (localStorage). The next question is when should I do it?

I could play it safe and store the comment whenever the user presses a key within the textarea. But that seems like overkill. It would be more efficient to only save when the user leaves the current page for any reason.

Alright then, I’ll use the unload event. No! Bad Jeremy! If I use that then the browser can’t reliably add the current page to the cache it uses for faster back-forwards navigations. The page life cycle is complicated.

So beforeunload then? Well, maybe. But modern browsers also support a pagehide event that looks like a better option.

In either case, just adding a listener for the event could screw up the caching of the page for back-forwards navigations. I should only listen for the event if I know that I need to store the contents of the textarea. And in order to know if the user has interacted with the textarea, I’m back to listening for key presses again.

But wait a minute! I don’t have to listen for every key press. If the user has typed anything, that’s enough for me. I only need to listen for the first key press in the textarea.

Handily, addEventListener accepts an object of options. One of those options is called “once”. If I set that to true, then the event listener is only fired once.

So I set up a cascade of event listeners. If the user types anything into the textarea, that fires an event listener (just once) that then adds the event listener for when the page is unloaded—and that’s when the textarea contents are put into localStorage.

I’ve abstracted my code into a gist. Here’s what it does:

  1. Cut the mustard. If this browser doesn’t support localStorage, bail out.
  2. Set the localStorage key to be the current URL.
  3. If there’s already an entry for the current URL, update the textarea with the value in localStorage.
  4. Write a function to store the contents of the textarea in localStorage but don’t call the function yet.
  5. The first time that a key is pressed inside the textarea, start listening for the page being unloaded.
  6. When the page is being unloaded, invoke that function that stores the contents of the textarea in localStorage.
  7. When the form is submitted, remove the entry in localStorage for the current URL.

That last step isn’t something I’m doing on The Session. Instead I’m relying on getting something back from the server to indicate that the form was successfully submitted. If you can do something like that, I’d recommend that instead of listening to the form submission event. After all, something could still go wrong between the form being submitted and the data being received by the server.

Still, this bit of code is better than nothing. Remember, it’s intended as an enhancement. You should be able to drop it into any project and improve the user experience a little bit. Ideally, no one will ever notice it’s there—it’s the kind of enhancement that only kicks in when something goes wrong. A little smidgen of resilient web design. A defensive enhancement.