What this now does is instead of saying “add margin to the left”, it says “regardless of direction, put margin on the starting side”. If the language of the document was
right to left, like Arabic, that margin would be on the right hand side.
…
This is clever. If you use e.g. margin-left on every list element after the first to put space “between” them, the spacing isn’t quite right when the order of the elements
is reversed, for example because your page has been automatically translated into a language that reads in the opposite direction (e.g. right-to-left, rather than left-to-right). When
you use margin-left in this way you’re imposing a language-direction-centric bias on your content, and there’s no need: margin-inline-start and its friends
are widely-supported and says what you mean: “place a margin before this element”. I’ll be trying to remember to
use this where it’s appropriate from now on.
We’re discussing the possibility of a Subdivision geohash achievement for people who’ve reached every “X in a
Y”, and Fippe pointed out that I’m only a hash in the Vale of White Horse from being able to claim such an
achievement for Oxfordshire’s regions. And then this hashpoint appears right in the Vale of White Horse: it’s like it’s an omen!
Technically it’s a workday so this might have to be a lunchtime expedition, but I think that might be workable. I’ve got an electric vehicle with a hundred-and-something miles
worth of batteries in the tank and it looks like there might be a lay-by nearby the hashpoint (with a geocache in it!): I can drive down there at lunchtime, walk carefully back up the main road, and try to
get to the hashpoint!
Expedition
I worked hard to clear an hour of my day to take a trip, then jumped in my (new) electric car and set off towards the hashpoint. As I passed Newbridge I briefly considered stopping and
checking up on my geocache there but feeling pressed for time I decided to push on. I parked in the lay-by where
GC5XHJG is apparently hidden but couldn’t find it: I didn’t search for long because the farmer in the adjacent field
was watching me with suspicion and I figured that anyway I could hunt for it on the way back.
Walking along the A338 was treacherous! There are no paths, only a verge covered in thick grass and spiky plants, and a significant number of the larger vehicles (and virtually all of
the motorbikes) didn’t seem to be obeying the 60mph speed limit!
Reaching the gate, I crawled under (reckoning that it’s probably there to stop vehicles and not humans) and wandered along the lane. I saw a red kite and a heron doing their thing
before I reached the bridge, crossed Letcombe Brook, and followed the edge of the field. Stuffing my face with blackberries as I went, it wasn’t long before I reached the hashpoint on
one edge of the field.
I took a short-cut back before realising that this would put me in the wrong place to leave a The Internet Was Here sign, so I doubled-back to place it on the gate I’d crawled under.
Then I returned to the lay-by, where another car had just pulled up (right over the GZ of the geocache I’d hoped to find!) and didn’t seem to be going anywhere. Sadly I couldn’t wait
around all day – I had work to do! – so I went home, following the satnav in the car in a route that resulted in a figure-of-eight tracklog.
Parked my car in this lay-by while on my way to the 2020-09-09 51 -1 geohashpoint. Took a quick look for the cache but the farmer in the adjacent field parked his tractor right
alongside me and was watching with suspicion, so I thought better of it and decided to come back after visiting the hashpoint and try again.
The geohashing expedition was a success, and I returned to the lay-by for another attempt… but somebody else had parked here (pretty much exactly where I’d measured the coordinates to
be… boo!). I waited for a while but they didn’t seem like they were leaving so I abandoned my search: I’ll try again next time I’m in the vicinity.
Enter the latest iteration of the Android version, Firefox Daylight, which came
out last week.
When you first run Firefox Daylight, you’re asked where you want the address bar, among other things.
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:
Sure, I’ll move my thumb the entire height of the screen every time I want to open a new tab.
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.
The old interface put the oft-used “add tab” button in the toolbar in the same place as the “tabs” button you just pressed. Much better.
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.
No uMatrix. No Violentmonkey (or any
equivalent). No Ghostery, even! Feels like surfing the Web with one hand tied behind my back.
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.
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.
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!
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.
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.
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.
…
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.
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!
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.
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.
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.
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.
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!
