Dan Q

Firefox Daylight Makes Me Sad

I love Firefox, as I’ve doubtless said before. In 2005 it reached the point at which (with the right combination of add-ons) it could replace Opera as my default browser. Going mobile, I used it on my N900 (still an underrated device) back in 2010, and later I’d use it on my Android devices. I love the power, productivity, performance, and privacy Firefox helps to give me.

Enter the latest iteration of the Android version, Firefox Daylight, which came out last week.

First, the good: this latest version of Firefox for Android is fast. Blazingly fast. The privacy controls are clearer and easier to access. Having picture-in-picture mode on mobile is a nice touch, as is the new generation of tracking prevention features.

But Firefox Daylight still makes me frown. And it’s a trio of smaller things that really niggle:

1. Top or bottom toolbar… but top is a second-class citizen.

In theory, I like the idea of having the address bar and its friends at the bottom of the screen where it’s more-accessible to your thumb. I’ve even tried it, independently. in years past. But it’s too much of a mental leap for me nowadays, plus it doesn’t cleanly fit into the “scroll down and the address bar disappears” user experience that’s become commonplace.

Making bottom toolbar the default was perhaps a little radical, then, but at least Mozilla provided an option to put it back at the top. But… it’s not quite right:

Even with the toolbar moved back to the top, some controls associated with it stay at the bottom. Want to open a new tab? You have to press the “tabs” button at the top of the screen, then the “plus” button at the bottom of the screen, then – probably – the address bar back at the top of the screen again! You’ve just covered two complete lengths of the screen to do something that used to require none. Not a satisfactory experience.

2. Tab previews were more space-efficient before

You’ve probably already spotted the other change to the “current tabs” view. Previously, open tabs were shown as mini previews with their titles above. Now they’re shown as tiny (sometimes absent) icon-sized previews with their titles alongside. This allows the domain name to be shown, which is nice, but not nice enough to justify reducing the instant visual recognition the previous interface provided.

It’s not even like you can fit more tabs onto a screen. The capacity is basically the same. You’re just making smaller hit targets with less recognisable graphics. Plus: previously the most-recent tabs were at the bottom (close to where your thumb is, which was the justification for making the address bar default to the bottom); now they’re at the top, further adding to the distance travelled.

3. Plugin support is terrible

I know first hand that implementing backwards-compatibility is hard, but breaking most plugins and then providing a list of nine or so popular/recommended ones that still works isn’t a great experience.

Feels a bit like this was released before it was ready.

For the time being, I’m using Fennec F-Droid as my primary mobile browser. It picks up exactly where Firefox for Android left off, and it doesn’t break my workflow. I hope to switch back to regular Firefox for Android someday, but Daylight needs “finishing” first.

Dan Q couldn’t find GC4RAQ8 Kingston loop N010

This checkin to GC4RAQ8 Kingston loop N010 reflects a geocaching.com log entry. See more of Dan's cache logs.

A reasonable search didn’t find this one, even with help from the hint. Either it’s been consumed by the wild undergrowth or else I just couldn’t lay an eye on it.

Dan Q found GC140G9 Thames Path: Newbridge (not)

This checkin to GC140G9 Thames Path: Newbridge (not) reflects a geocaching.com log entry. See more of Dan's cache logs.

Came down to the river to launch my partner’s brother on a swimming expedition (pictured putting on his wetsuit) downstream and to triple-check access to my nearby new cache GC8YZKJ. Recent logs about the cache being submerged made me worry and I spent some time looking too-close to the water’s edge, but as soon as I expanded my search I caught sight of it immediately. TFTC!

Holograms on Chocolate

This is a repost promoting content originally published elsewhere. See more things Dan's reposted.

Applied Science (YouTube)

This is incredibly cool. Using (mostly) common household tools and chemicals and a significant amount of effort, Ben (who already built himself a home electron microscope, as you do) demonstrates how you can etch a hologram directly into chocolate, resulting in a completely edible hologram. I’d never even thought before about the fact that a hologram could be embossed into almost any opaque surface before, so this blew my mind. In hindsight it makes perfect sense, but it still looks like magic to see it done.

Run Club Goes for a Swim

Out on a Run Club expedition up the Thames Path this evening, took a quick dip in the river with Robin.

Also available on: QTube.

Oxford’s Long-Lost Zoo

Oxford has many things, but it doesn’t have a zoo. But for a few years in the 1930s, it did, and it’s a fascinating story that starts with marmalade and ends with a geocache.

With thanks to John Amor, whose book Gosford Hill & Oxford Zoo (ISBN 978-0-9544474-5-8) answered my initial research questions, and to the Bodleian Libraries for giving me the resources to go deeper. Also thanks to my Alphamattic teammates for listening to me talk about a different bit of Oxford history and encouraging me to make this video.

Music: Don’t Turn Around, by Ivan Chew (ramblinglibrarian), used under a CC-Attribution-NonCommercial license.
Some footage of Oxford provided by Steve B (@bigantvideo), used under the Pexels license.
Uses photos taken prior to 1925 of unknown provenance or subsequently released into the public domain.

Parts of this video were filmed during COVID-19 lockdown restrictions. Appropriate social distancing practices were applied.

Also available via YouTube and QTube.

To the future occupants of my office at the MIT Media Lab

This is a repost promoting content originally published elsewhere. See more things Dan's reposted.

Hi. My name is Ethan Zuckerman. From 2011-2020, I enjoyed working in this office. I led a research group at the Media Lab called the Center for Civic Media, and I taught here and in Comparative Media Studies and Writing. I resigned in the summer of 2019, but stayed at the lab to help my students graduate and find jobs and to wind down our grants. When COVID-19 hit in March 2020, I left campus and came back on August 14 to clean out my office and to leave you this note.

I’m leaving the note because the previous occupant left me a note of sorts. I was working here late one night. I looked up above my desk and saw a visegrip pliers attached to part of the HVAC system. I climbed up to investigate and found a brief note telling the MIT facilities department that the air conditioning had been disabled (using the vice grips, I presume) as part of a research project and that one should contact him with any questions.

That helped explain one of the peculiarities of the office. When I moved in, attached to the window was a contraption that swallowed the window handle and could be operated with red or green buttons attached to a small circuitboard. Press the green button and the window would open very, very slowly. Red would close it equally slowly. I wondered whether the mysterious researcher might be able to remove it and reattach the window handle. So I emailed him.

…

Ethan Zuckerman

I’m reminded of that time eleven years ago that I looked up the person who’d gotten my (recycled) university username and emailed them. Except Ethan’s note, passed on to the next person to occupy his former office at MIT, is much cooler. And not just because it speaks so eloquently to the quirky and bizarre culture of the place (Aber’s got its own weird culture too, y’know!) but because it passes on a slice of engineering history that its previous owner lived with, but perhaps never truly understood. A fun read.

Dan Q posted a note for GC591VV You Can’t Do It Alone!

This checkin to GC591VV You Can't Do It Alone! reflects a geocaching.com log entry. See more of Dan's cache logs.

Thanks! I wasn’t able to find all the bits when I archived it so I assumed it had been muggled; thanks to Oxford Stone for tidying up the bits I failed to!

Note #17583

Needed new UPS batteries.
Almost bought from @insight_uk but they require registration to checkout.
Purchased from @SourceUPSLtd instead.
Moral: having no “guest checkout” costs you business.

Think Like a Tomato

This is a repost promoting content originally published elsewhere. See more things Dan's reposted.

Ruth tweeted:

Smallest child, while watering plants: “To grow a tomato, we have to think like a tomato!”

Adorable.

Also: I want him on my side when the killer tomatoes attack.

Loading CSS Asynchronously Without JS Dependency

tl;dr? skip to the proof-of-concept/demo of lazy-loading CSS where possible while still loading it “conventionally” to users without Javascript

In a “daily tip” a couple of days ago, the excellent Chris Ferdinandi recommended an approach to loading CSS asynchronously based on a refined technique by Scott Jehl. The short of it is that you load your stylesheets like this:

<link rel="stylesheet" href="/path/to/my.css" media="print" onload="this.media='all'">

You see what that’s doing? It’s loading the stylesheet for the print medium, but then when the document finishes loading it’s switching the media type from “print” to “all”. Because it didn’t apply to begin with the stylesheet isn’t render-blocking. You can use this to delay secondary styles so the page essentials can load at full speed.

This website's Lighthouse score showing a Total Blocking Time of 0ms. — Reducing blocking times, like I have on *this* page, is one of many steps in optimising perceived page performance.

I don’t like this approach. I mean: I love the elegance… I just don’t like the implications.

Why I don’t like lazy-loading CSS using Javascript

Using Javascript to load CSS, in order to prevent that CSS blocking rendering, feels to me like it conceptually breaks the Web. It certainly violates the expectations of progressive enhancement, because it introduces a level of fault-intolerance that I consider (mostly) unacceptable.

CSS and Javascript are independent of one another. A well-designed progressively-enhanced page should function with HTML only, HTML-and-CSS only, HTML-and-JS only, or all three.CSS adds style, and JS adds behvaiour to a page; and when you insist that the user agent uses Javascript in order to load stylistic elements, you violate the separation of these technologies (I’m looking at you, the majority of heavyweight front-end frameworks!).

If you’re thinking that the only people affected are nerds like me who browse with Javascript wholly or partially disabled, you’re wrong: gov.uk research shows that around 1% of your visitors have Javascript fail for some reason or another: because it’s disabled (whether for preference, privacy, compatibility with accessibility technologies, or whaterver), blocked, firewalled, or they’re using a browser that you didn’t expect.

Can we lazy-load CSS in a way that doesn’t depend on Javascript? (spoiler: yes)

Chris’s daily tip got me thinking: could there exist a way to load CSS in a non-render-blocking way but which degraded gracefully in the event that Javascript was unavailable? I.e. if Javascript is working, lazy-load CSS, otherwise: load conventionally as a fallback. It turns out, there is!

In principle, it’s this:

Link your stylesheet from within a <noscript> block, thereby only exposing it where Javascript is disabled. Give it a custom attribute to make it easy to find later, e.g. <noscript lazyload> (if you’re a standards purist, you might prefer to use a data- attribute).
Have your Javascript extract the contents of these <noscript> blocks and reinject them. In modern browsers, this is as simple as e.g. [...document.querySelectorAll('noscript[lazyload]')].forEach(ns=>ns.outerHTML=ns.innerHTML).

If you need support for Internet Explorer, you need a little more work, because Internet Explorer doesn’t expose<noscript> blocks to the DOM in a helpful way. There are a variety of possible workarounds; I’ve implemented one but not put too much thought into it because I rarely have to think about Internet Explorer these days.

In any case, I’ve implemented a proof of concept/demonstration if you’d like to see it in action: just take a look and view source (or read the page) for details. Or view the source alone via this gist.

Lazy-loading CSS using my approach provides most of the benefits of other approaches… but works properly in environments without Javascript too.

Update: Chris Ferdinandi’s refined this into an even cleaner approach that takes the best of both worlds.

Building a Playframe (Timelapse Video)

This week, with help from Robin and JTA, I built a TropicTemple Tall XXL climbing frame in the garden of our new house. Manufacturer Fatmoose provided us with a pallet-load of lumber and a sack of accessories, delivered to our driveway, based on a design Ruth and I customised using their website, and we assembled it on-site over the course of around three days. The video above is a timelapse taken from our kitchen window using a tablet I set up for that purpose, interspersed with close-up snippets of us assembling it and of the children testing it out.

Playframe in VR — You can explore the play equipment in VR, if you like.

I’ve also built a Virtual Tour so you can explore the playframe using your computer, phone, or VR headset. Take a look!

The video is also available via:

Note #17552

I’m unlikely to get a graduation ceremony like last time (on account of social distancing and whatnot), but I get a certificate to acknowledge my most-recent qualification.

Dan Q found GC3MFPY Dogfort v Catfort – Sailor Dog

This checkin to GC3MFPY Dogfort v Catfort - Sailor Dog reflects a geocaching.com log entry. See more of Dan's cache logs.

Well, it’s been a long while since I saw an intact Dogfort vs. Catfort!

After dropping the kids off at their respective summer camp activities for the day, my car advised me that, owing to traffic, I ought to consider taking the B4044 most of the way home rather than the usual A-roads. Sure, I thought… that takes me through Farmoor where I think there might be caches I haven’t found! I parked not at the nearby car park but in a layby in Filchampstead to enjoy a walk along the nearby footpath first.

Coordinates were spot on and cache was easy to spot despite camouflage. Re-hid slightly deeper. TFTC!

Bodley and the Bookworms – Scan and Deliver

This is a repost promoting content originally published elsewhere. See more things Dan's reposted.

Bodleian Libraries (YouTube)

You know that strange moment when you see your old coworkers on YouTube doing a cover of an Adam and the Ants song? No: just me?

Still good to see the Bodleian put a fun spin on promoting their lockdown-friendly reader services. For some reason they’ve marked this video “not embeddable” (?) in their YouTube settings, so I’ve “fixed” the copy above for you.