Jeremy Keith's Blog, page 22

Tragedy

There are two kinds of time-travel stories.

There are time-travel stories that explore the many-worlds hypothesis. Going back in time and making a change forks the universe. But the universe is constantly forking anyway. So effectively the time travel is a kind of universe-hopping (there���s a big crossover here with the alternative history subgenre).

The problem with multiverse stories is that there���s always a reset available. No matter how bad things get, there���s a parallel universe where everything is hunky dory.

The other kind of time travel story explores the idea of a block universe. There is one single timeline.

This is what you���ll find in Tenet, for example, or for a beautiful reduced test case, the Ted Chiang short story What���s Expected Of Us. That gets straight to the heart of the biggest implication of a block universe���the lack of free will.

There���s no changing what has happened or what will happen. In fact, the very act of trying to change the past often turns out to be the cause of what you���re trying to prevent in the present (like in Twelve Monkeys).

I���ve often referred to these single-timeline stories as being like Greek tragedies. But only recently���as I���ve been reading quite a bit of Greek mythology���have I realised that the reverse is also true:

Greek tragedies are time-travel stories.

Hear me out���

Time-travel stories aren���t actually about physically travelling in time. That���s just a convenience for the important part���information travelling in time. That���s at the heart of most time-travel stories; informaton from the future travelling back to the past.

William Gibson���s The Peripheral���very much a many-worlds story with its alternate universe ���stubs������takes this to its extreme. Nothing phyiscal ever travels in time. But in an age of telecommuting, nothing has to. Our time travellers are remote workers.

That book also highlights the power dynamics inherent in information wealth. Knowledge of the future gives you an advantage that you can exploit in the past. This is what Mark Twain���s Connecticut yankee does in King Arthur���s court.

This power dynamic is brilliantly inverted in Octavia Butler���s brilliant Kindred. No amount of information can help you if your place in society is determined by the colour of your skin.

Anyway, the point is that information flow is what matters in time-travel stories. Therefore any story where information travels backwards in time is a time-travel story.

That includes any story with a prophecy. A prophecy is information about the future, like:

Oedipus will kill his father and marry his mother.

You can try to change your fate, but you���ll just end up triggering it instead.

Greek tragedies are time-travel stories.

Innovation

I did an episode of the Clearleft podcast on innovation a while back:

Everyone wants to be innovative ���but no one wants to take risks.

The word innovation is often bandied about in an unquestioned positive way. But if we acknowledge that innovation is���by definition���risky, then the exhortations sound less positive.

���We provide innovative solutions for businesses!��� becomes ���We provide risky solutions for businesses!���

I was reminded of this when I saw the website for the Podcast Standards Project. The original text on the website described the project as:

���a grassroots coalition working to establish modern, open standards, to enable innovation in the podcast industry.

I pushed back on that wording (partly because I���ve seen the word ���innovation��� used as a smoke screen for user-hostile practices like tracking and surveillance). The wording has since changed to:

���a grassroots coalition dedicated to creating standards and practices that improve the open podcasting ecosystem for both listeners and creators.

That���s better. It���s more precise.

Am I nitpicking? Only if you think that ���innovation��� and ���improvement��� are synonyms. I don���t think they are.

Innovation implies change. Improvement implies positive change.

Not all change is positive. Not all innovation is positive.

Innovation goes hand in hand with disruption. Again, disruption involves change. But not necessarily positive change.

Think about the antonyms of change and disruption: stasis and stability. Those words don���t sound very exciting, but in some arenas they���re exactly what you should be aiming for; arenas like infrastructure or standards.

Not to get all pace layers-y here, but it seems to me that every endeavour has a sweet spot for innovation. For some projects, too little innovation is bad. For others, too much innovation is worse.

The trick is knowing which kind of project you���re working on.

(As a side note, I think some people use the word innovation to describe the generative, divergent phase of a design project: ���how might we come up with innovative new approaches?��� But we already have a word to describe the practice of generating novel and interesting ideas. That word isn���t innovation. It���s creativity.)

The intersectionality of web performance

Web performance is an unalloyed good. No one has ever complained that a website is too fast.

So the benefit is pretty obvious. Users like fast websites. But there are other benefits to web performance. And they don���t all get equal airtime.

Business

A lot of good web performance practices come down to the first half of Postel���s Law: be conservative in what send. Images, fonts, JavaScript ���remove what you don���t need and optimise the hell out of what���s left.

That can translate to savings. If you���re paying for the bandwidth every time a hefty file is downloaded, your monthly bill could get pretty big.

So apart from the indirect business benefits of happy users converting to happy customers, there can be a real nuts���n���bolts bottom-line saving to be made by having a snappy website.

Sustainability

This is related to the cost-savings benefit. If you���re shipping less stuff down the wire, and you���re optimising what you do send, then there���s less energy required.

Whether less energy directly translates to a smaller carbon footprint depends on how the energy is being generated. If your servers are running on 100% renewable energy sources, then reducing the output of your responses won���t reduce your carbon footprint.

But there���s an energy cost at the other end too. Think of all the devices making requests to your server. If you���re making those devices work hard���by downloading, parsing, executing lots of JavaScript, for example���then you���re draining battery life. And you can���t guarantee that the battery will be replenished from renewable energy sources.

That���s why sites like the website carbon calculator have so much crossover with web performance:

From data centres to transmission networks to the billions of connected devices that we hold in our hands, it is all consuming electricity, and in turn producing carbon emissions equal to or greater than the global aviation industry. Yikes!

Inclusivity

There comes a point when a slow website isn���t just inconvenient, it���s inaccessible.

I���ve always liked the German phrase for accessible: barrierefrei���free of barriers. With every file you add to a website���s dependencies, you���re adding one more barrier. Eventually the barrier is insurmountable for people with older devices or slower internet connections. If they can no longer access your website, your website is quite literally inaccessible.

Making the case

I���ve noticed that when it comes to making the argument in favour of better web performance, people often default to the business benefits.

I get it. We���re always being told to speak the language of business. The psychology seems pretty straightforward; if you think that the people you���re trying to convince are mostly concerned with the bottom line, use the language of commerce to change their minds.

But that���s always felt reductive to me.

Sure, those people almost certainly do care about the business. Who doesn���t? But they���re also humans. I feel like if really want to convince them, speak to their hearts. Show them the bigger picture.

Eliel Saarinen said:

Always design a thing by considering it in its next larger context; a chair in a room, a room in a house, a house in an environment, an environment in a city��plan.

I think the same could apply to making the case for web performance. Don���t stop at the obvious benefits. Go wider. Show the big-picture implications.

Spring

Spring is arriving. It���s just taking its time.

There are little signs. Buds on the trees. The first asparagus of the year. Daffodils. Changing the clocks. A stretch in the evenings. But the weather remains, for the most part, chilly and grim.

Reality is refusing to behave like a fast-forward montage leading up to to a single day when you throw open the curtains and springtime is suddenly there in all its glory.

That���s okay. I can wait. I���ve had a lot of practice over the past three years. We all have. Staying home, biding time, saving lives.

But hunkering down during The Situation isn���t like taking shelter during an air raid. There isn���t a signal that sounds to indicate ���all clear!��� It���s more like going from Winter to Spring. It���s slow, almost impercetible. But it is happening.

I���ve noticed a subtle change in my risk assessment over the past few months. I still think about COVID-19. I still factor it into my calculations. But it���s no longer the first thing I think of.

That���s a subtle change. It doesn���t seem like that long ago when COVID was at the forefront of my mind, especially if I was weighing up an excursion. Is it worth going to that restaurant? How badly do I want to go to that gig? Should I go to that conference?

Now I find myself thinking of COVID as less of a factor in my decision-making. It���s still there, but it has slowly slipped down the ranking.

I know that other people feel differently. For some people, COVID slipped out of their minds long ago. For others, it���s still very much front and centre. There isn���t a consensus on how to evaluate the risks. Like I said:

It���s like when you���re driving and you think that everyone going faster than you is a maniac, and everyone going slower than you is an idiot.

COVID-19 isn���t going away. But perhaps The Situation is.

The Situation has been gradually fading away. There isn���t a single moment where, from one day to the next, we can say ���this marks the point where The Situation ended.��� Even if there were, it would be a different moment for everyone.

As of today, the COVID-19 app officially stops working. Perhaps today is as good a day as any to say Spring has arrived. The season of rebirth.

Assumption

While I���m talking about the SVGs on The Session, I thought I���d share something else related to the rendering of the sheet music.

Like I said, I use the brilliant abcjs JavaScript library. It converts ABC notation into sheet music on the fly, which still blows my mind.

If you view source on the rendered SVG, you���ll see that the path and rect elements have been hard-coded with a colour value of #000000. That makes sense. You���d want to display sheet music on a light background, probably white. So it seems like a safe assumption.

Ah, but when it comes to front-end development, assumptions are like little hidden bombs just waiting to go off!

I got an email the other day:

Hi Jeremy,

I have vision problems, so I need to use high-contrast mode (using Windows 11). In high-contrast mode, the sheet-music view is just black!

Doh! All my CSS adapts just fine to high-contrast mode, but those hardcoded hex values in the SVG aren���t going to be affected by high-contrtast mode.

Stepping back, the underlying problem was that I didn���t have a full separation of concerns. Most of my styling information was in my CSS, but not all. Those hex values in the SVG should really be encoded in my style sheet.

I couldn���t remove the hardcoded hex values���not without messing around with JavaScript beyond my comprehension���so I made the fix in CSS:

[fill="#000000"] { fill: currentColor;}[stroke="#000000"] { stroke: currentColor;}

That seemed to do the trick. I wrote back to the person who had emailed me, and they were pleased as punch:

Well done, Thanks!�� The staff, dots, etc. all appear as white on a black background.�� When I click “Print”, it looks like it still comes out black on a white background, as expected.

I���m very grateful that they brought the issue to my attention. If they hadn���t, that assumption would still be lying in wait, preparing to ambush someone else.

Workaround

Two weeks ago, I wrote:

I woke up today to a very annoying new bug in Firefox. The browser shits the bed in an unpredictable fashion when rounding up single pixel line widths in SVG. That���s quite a problem on The Session where all the sheet music is rendered in SVG. Those thin lines in sheet music are kind of important.

Paul Rosen, who makes abcjs, the JavaScript library that renders sheet music on The Session, managed to get a fix out pretty quickly. But I use an older version of the library and updating it would introduce some side-effects that would take me a while to work around. So that option wasn���t available to me.

In this situation, when the problem is caused by a browser bug, the correct course of action is to file a bug with the browser. That had already been done. Now all I could do was twiddle my thumbs and wait for the next release of the browser, which would hopefully ship with the fix.

But I figured I may as well try to find a temporary workaround in the meantime.

At first, I looked at diving into the internals of the JavaScript���that���s where the instructions are given for drawing the SVGs.

But then I stopped and thought, ���If the problem is with the rendering of the SVG, maybe CSS can help.���

I started messing around with SVG-specific CSS properties like stroke, fill, and so on. With dev tools open, I started targeting the paths that acted as bar lines in the sheet music, playing around with widths, opacities, and fills.

It was the debugging equivalent of throwing spaghetti at the wall. Remarkably, it actually worked.

I found a solution with this nonsensical bit of CSS:

stroke: currentColor;stroke-opacity: 0;

For some reason, rather than making all the barlines disappear, this ensured they were visible.

It���s the worst kind of hacky fix���the kind where you have no idea why it works, but it does.

So I shipped it.

And at pretty much exactly the same time, a new version of Firefox dropped …with the bug fixed.

I can���t deny that there was a certain satisfaction in being able to work around a browser bug. But there���s much more satisfaction in deleting the hacky workaround when it���s no longer needed.

Remote

Before The Situation, I used to work in the Clearleft studio quite a bit. Maybe I���d do a bit of work at home for an hour or two before heading in, but I���d spend most of my working day with my colleagues.

That all changed three years ago:

Clearleft is a remote-working company right now. I mean, that���s hardly surprising���just about everyone I know is working from home.

Clearleft has remained remote-first. We���ve still got our studio space, though we���ve cut back to just having one floor. But most of the time people are working from home. I still occasionally pop into the studio���I���m actually writing this in the studio right now���but mostly I work out of my own house.

It���s funny how the old ways of thinking have been flipped. If I want to get work done, I stay home. If I want to socialise, I go into the studio.

For a lot of the work I do���writing, podcasting, some video calls, maybe some coding���my home environment works better than the studio. In the Before Times I���d have to put on headphones to block out the distractions of a humming workplace. Of course I miss the serendipitous chats with my co-workers but that���s why it���s nice to still have the option of popping into the studio.

Jessica has always worked from home. Our flat isn���t very big but we���ve got our own separate spaces so we don���t disturb one another too much.

For a while now we���ve been thinking that we could just as easily work from another country. I was inspired by a (video) chat I had with Luke when he casually mentioned that he was in Cypress. Why not? As long as the internet connection is good, the location doesn���t make any difference to the work.

So Jessica and I spent the last week working in Ortygia, Sicily.

It was pretty much the perfect choice. It���s not a huge bustling city. In fact it was really quiet. But there was still plenty to explore���winding alleyways, beautiful old buildings, and of course plenty of amazing food.

The time difference was just one hour. We used the extra hour in the morning to go to the market to get some of the magnificent local fruits and vegetables to make some excellent lunches.

We made sure that we found an AirBnB place with a good internet connection and separate workspaces. All in all, it worked out great. And because we were there for a week, we didn���t feel the pressure to run around to try to see everything.

We spent the days working and the evenings having a nice sundowner appertivo followed by some pasta or seafood.

It was simultaneously productive and relaxing.

Read-only web apps

The most cartoonish misrepresentation of progressive enhancement is that it means making everything work without JavaScript.

No. Progressive enhancement means making sure your core functionality works without JavaScript.

In my book Resilient Web Design, I quoted Wilto:

Lots of cool features on the Boston Globe don���t work when JS breaks; ���reading the news��� is not one of��them.

That���s an example where the core functionality is readily identifiable. It���s a newspaper. The core functionality is reading the news.

It isn���t always so straightforward though. A lot of services that self-identify as ���apps��� will claim that even their core functionality requires JavaScript.

Surely I don���t expect Gmail or Google Docs to provide core functionality without JavaScript?

In those particular cases, I actually do. I believe that a textarea in a form would do the job nicely. But I get it. That might take a lot of re-engineering.

So how about this compromise���

Your app should work in a read-only mode without JavaScript.

Without JavaScript I should still be able to read my email in Gmail, even if you don���t let me compose, reply, or organise my messages.

Without JavaScript I should still be able to view a document in Google Docs, even if you don���t let me comment or edit the document.

Even with something as interactive as Figma or Photoshop, I think I should still be able to view a design file without JavaScript.

Making this distinction between read-only mode and read/write mode could be very useful, especially at the start of a project.

Begin by creating the read-only mode that doesn���t require JavaScript. That alone will make for a solid foundation to build upon. Now you���ve built a fallback for any unexpected failures.

Now start adding the read/write functionally. You���re enhancing what���s already there. Progressively.

Heck, you might even find some opportunities to provide some read/write functionality that doesn���t require JavaScript. But if JavaScript is needed, that���s absolutely fine.

So if you���re about to build a web app and you���re pretty sure it requires JavaScript, why not pause and consider whether you can provide a read-only version.

Progressive disclosure with HTML

Robin penned a little love letter to the details element. I agree. It is a joyous piece of declarative power.

That said, don���t go overboard with it. It���s not a drop-in replacement for more complex widgets. But it is a handy encapsulation of straightforward progressive disclosure.

Just last week I added a couple of more details elements to The Session ���kind of. There���s a bit of server-side conditional logic involved to determine whether details is the right element.

When you���re looking at a tune, one of the pieces of information you see is how many recordings there of that tune. Now if there are a lot of recordings, then there���s some additional information about which other tunes this one gets recorded with. That information is extra. Mere details, if you will.

You can see it in action on this tune listing. Thanks to the details element, the extra information is available to those who want it, but by default that information is tucked away���very handy for not clogging up that part of the page.

There are 181 recordings of this tune.This tune has been recorded together with���������

Likewise, each tune page includes any aliases for the tune (in Irish music, the same tune can have many different titles���and the same title can be attached to many different tunes). If a tune has just a handful of aliases, they���re displayed in situ. But once you start listing out more than twenty names, it gets overwhelming.

The details element rides to the rescue once again.

Compare the tune I mentioned above, which only has a few aliases, to another tune that is known by many names.

Again, the main gist is immediately available to everyone���how many aliases are there? But if you want to go through them all, you can toggle that details element open.

You can effectively think of the summary element as the TL;DR of HTML.

There are 31 other names for this tune.

Also known as���

There���s another classic use of the details element: frequently asked questions. In the case of The Session, I���ve marked up the house rules and FAQs inside details elements, with the rule or question as the summary.

But there���s one house rule that���s most important (���Be civil���) so that details element gets an additional open attribute.

Be civil

Contributions should be constructive and polite, not mean-spirited or contributed with the intention of causing trouble.

Browser history

I woke up today to a very annoying new bug in Firefox. The browser shits the bed in an unpredictable fashion when rounding up single pixel line widths in SVG. That���s quite a problem on The Session where all the sheet music is rendered in SVG. Those thin lines in sheet music are kind of important.

Browser bugs like these are very frustrating. There���s nothing you can do from your side other than filing a bug. The locus of control is very much with the developers of the browser.

Still, the occasional regression in a browser is a price I���m willing to pay for a plurality of rendering engines. Call me old-fashioned but I still value the ecological impact of browser diversity.

That said, I understand the argument for converging on a single rendering engine. I don���t agree with it but I understand it. It���s like this…

Back in the bad old days of the original browser wars, the browser companies just made shit up. That made life a misery for web developers. The Web Standards Project knocked some heads together. Netscape and Microsoft would agree to support standards.

So that���s where the bar was set: browsers agreed to work to the same standards, but competed by having different rendering engines.

There���s an argument to be made for raising that bar: browsers agree to work to the same standards, and have the same shared rendering engine, but compete by innovating in all other areas���the browser chrome, personalisation, privacy, and so on.

Like I said, I understand the argument. I just don���t agree with it.

One reason for zeroing in a single rendering engine is that it���s just too damned hard to create or maintain an entirely different rendering engine now that web standards are incredibly powerful and complex. Only a very large company with very deep pockets can hope to be a rendering engine player. Google. Apple. Heck, even Microsoft threw in the towel and abandoned their rendering engine in favour of Blink and V8.

And yet. Andreas Kling recently wrote about the Ladybird browser. How we’re building a browser when it’s supposed to be impossible:

The ECMAScript, HTML, and CSS specifications today are (for the most part) stellar technical documents whose algorithms can be implemented with considerably less effort and guesswork than in the past.

I���ll be watching that project with interest. Not because I plan to use the brower. I���d just like to see some evidence against the complexity argument.

Meanwhile most other browser projects are building on the raised bar of a shared browser engine. Blisk, Brave, and Arc all use Chromium under the hood.

Arc is the most interesting one. Built by the wonderfully named Browser Company of New York, it���s attempting to inject some fresh thinking into everything outside of the rendering engine.

Experiments like Arc feel like they could have more in common with tools-for-thought software like Obsidian and Roam Research. Those tools build knowledge graphs of connected nodes. A kind of hypertext of ideas. But we���ve already got hypertext tools we use every day: web browsers. It���s just that they don���t do much with the accumulated knowledge of our web browsing. Our browsing history is a boring reverse chronological list instead of a cool-looking knowledge graph or timeline.

For inspiration we can go all the way back to Vannevar Bush���s genuinely seminal 1945 article, As We May Think. Bush imagined device, the Memex, was a direct inspiration on Douglas Engelbart, Ted Nelson, and Tim Berners-Lee.

The article describes a kind of hypertext machine that worked with microfilm. Thanks to Tim Berners-Lee���s World Wide Web, we now have a global digital hypertext system that we access every day through our browsers.

But the article also described the idea of ���associative trails���:

Wholly new forms of encyclopedias will appear, ready made with a mesh of associative trails running through them, ready to be dropped into the memex and there amplified.

Our browsing histories are a kind of associative trail. They���re as unique as fingerprints. Even if everyone in the world started on the same URL, our browsing histories would quickly diverge.

Bush imagined that these associative trails could be shared:

The lawyer has at his touch the associated opinions and decisions of his whole experience, and of the experience of friends and authorities.

Heck, making a useful browsing history could be a real skill:

There is a new profession of trail blazers, those who find delight in the task of establishing useful trails through the enormous mass of the common record.

Taking something personal and making it public isn���t a new idea. It was what drove the wave of web 2.0 startups. Before Flickr, your photos were private. Before Delicous, your bookmarks were private. Before Last.fm, what music you were listening to was private.

I���m not saying that we should all make our browsing histories public. That would be a security nightmare. But I am saying there���s a lot of untapped potential in our browsing histories.

Let���s say we keep our browsing histories private, but make better use of them.

From what I���ve seen of large language model tools, the people getting most use of out of them are training them on a specific corpus. Like, ���take this book and then answer my questions about the characters and plot��� or ���take this codebase and then answer my questions about the code.��� If you treat these chatbots as calculators for words they can be useful for some tasks.

Large language model tools are getting smaller and more portable. It���s not hard to imagine one getting bundled into a web browser. It feeds on your browsing history. The bigger your browsing history, the more useful it can be.

Except, y���know, for the times when it just make shit up.

Vannevar Bush didn���t predict a Memex that would hallucinate bits of microfilm that didn���t exist.