Jeremy Keith's Blog, page 14

Indie webbing

The past weekend���s Indie Web Camp Brighton was wonderful! Many thanks to Mark and Paul for all their work putting it together.

There was a great turn-out. It felt like the perfect time for an Indie Web Camp. There���s a real appetite for getting away from ever more extractive silos and staking claim to our own corners of the web. Most of the attendees were at their first ever Indie Web Camp.

Paul asked me to oversee the schedule planning on day one, which I was happy to do. We made sure that first-timers got first dibs on proposing sessions. In the end, every single session was proposed by new attendees.

Day two was all about putting ideas into practice: coding, designing, and writing on our own website. I���m always blown away by how much gets done in just one short day. Best of all is when there���s someone who starts the weekend without their own website but finishes with a live site. That happened again this time.

I spent the second day tinkering with something I started at Indie Web Camp Nuremberg in October. Back then, I got related posts working here on my journal; a list of suggested follow-up posts to read based on the tags of the current post.

I wanted to do the same for my links; show links related to the one I���m currently linking to. It didn���t take too long to get that up and running.

But then I thought about it some more and realised it would be good to also show blog posts related to the link. So I did that. Then I realised it would be really good to show related links under blog posts too.

So now, if everything���s working correctly, then at the end of this post you will not only see related blog posts I���ve previously written, but also links related to the content of this post.

It was a very inspiring weekend. There���s something about being in a room with other people working on their websites that makes me super productive.

While we were hacking away on day two, somebody mentioned that they still find hard to explain the indie web to people.

���It���s having your own website���, I said.

But surely there���s more to it than that, they wondered.

Nope. If someone has their own website, then they���re part of the indie web. It doesn���t matter if that website is made with a complicated home-rolled tech stack or if it���s a Squarespace site.

What you do with your own website is entirely up to you. The technologies are just plumbing wether it���s webmentions, RSS, or anything else. None of it is a requirement. Heck, even HTML is optional. If you want to put plain text files on your website, go for it. It���s your website.

Bookmarklets for testing your website

I���m at day two of Indie Web Camp Brighton.

Day one was excellent. It was really hard to choose which sessions to go to because they all sounded interesting. That���s a good problem to have.

I ended up participating in:

a session on POSSE,a session on NFC tags,a session on writing, anda session on testing your website that was hosted by Ros

In that testing session I shared some of the bookmarklets I use regularly.

Bookmarklets? They���re bookmarks that sit in the toolbar of your desktop browser. Just like any other bookmark, they���re links. The difference is that these links begin with javascript: rather than http. That means you can put programmatic instructions inside the link. Click the bookmark and the JavaScript gets executed.

In my mind, there are two different approaches to making a bookmarklet. One kind of bookmarklet contains lots of clever JavaScript���that���s where the smart stuff happens. The other kind of bookmarklet is deliberately dumb. All they do is take the URL of the current page and pass it to another service���that���s where the smart stuff happens.

I like that second kind of bookmarklet.

Here are some bookmarklets I���ve made. You can drag any of them up to the toolbar of your browser. Or you could create a folder called, say, ���bookmarklets���, and drag these links up there.

Validation: This bookmarklet will validate the HTML of whatever page you���re on.

Validate HTML

Carbon: This bookmarklet will run the domain through the website carbon calculator.

Calculate carbon

Accessibility: This bookmarklet will run the current page through the Website Accessibility Evaluation Tools.

WAVE

Performance: This bookmarklet will take the current page and it run it through PageSpeed Insights, which includes a Lighthouse test.

PageSpeed

HTTPS: This bookmarklet will run your site through the SSL checker from SSL Labs.

SSL Report

Headers: This bookmarklet will test the security headers on your website.

Security Headers

Drag any of those links to your browser���s toolbar to ���install��� them. If you don���t like one, you can delete it the same way you can delete any other bookmark.

Patterns Day

The third Patterns Day happened yesterday. It was lovely!

The last time we had a Patterns Day was in 2019. After five years it felt very, very good to be back in the beautiful Duke Of York���s for another full day of design systems nerdery.

I wasn���t the only one who felt that way. A lot of people told me how much they enjoyed the event, which swelled my heart with happiness. I���m genuinely grateful to everyone who came���thank you so much!

The talks were, of course, excellent. I feel pretty good about the flow of the day. I tried to mix and match between big-picture talks with broad themes and nitty-gritty talks diving into details. The contrast worked really well.

In the pub afterwards it was fascinating to hear how much the different talks resonated with people. So many people felt seen, in the best possible way. It���s quite gratifying to hear that you���re not alone, that other people are struggling with the same kinds of issues with design systems as you are.

At the very first Patterns Day when it was still early days for design systems, there was still a certain amount of cheerleading, bigging up all the benefits of design systems. In 2024 there���s a lot more real talk about how much hard work there is. The design systems struggle is real.

There was another overarching theme at this year���s Patterns Day. Even though there was plenty of coverage of technical details like design tokens, typography and components, the big takeaway was all about people. Collaboration. Agreement. Community. These are the real foundations of a design system that works.

I���m so grateful to all the wonderful speakers yesterday for reminding us of what really matters.

UX London early-bird pricing ends soon

Just look at who���s speaking at UX London this year! That���s a damned fine line-up, if I do say so myself. Which I do.

If you haven���t procured a ticket yet, allow me to gently remind you that early-bird ticket sales finish on March 14th. So if you want to avail of that bargain of a price, get in there now.

The event will be three days long. You can buy a ticket for all three days, or you can buy individual day tickets (but buying a three-day ticket works out cheaper per day).

The first day, Tuesday, June 18th, focuses on UX research.

The second day, Wednesday, June 19th, focuses on product design.

The third day, Thursday, June 20th, focuses on design ops and design systems.

Each day features a morning of inspiring talks and an afternoon of brilliant workshops. I���ll be adding titles and descriptions for all of them soon, but in the meantime, don���t dilly dally���get your ticket today!

A Book Apart

2010 was a good year for me. I moved into a new home. Salter Cane released an album. We had a really good dConstruct. And I wrote a book.

It was HTML5 For Web Designers, the very first title from a new indie publisher called A Book Apart.

Back then, I wrote about the writing process, Jason wrote about the design, Mandy wrote about editing, and Jeffrey wrote a lovely foreword. What a dream team!

From there, A Book Apart went from strength to strength. Under Katel���s stewardship, they released the must-have books for web design and development.

One of the perks of being an author for A Book Apart is that I get a copy of every book published. I have a shelf of slim but colourful book spines.

Now, after 14 years and 60 titles, the collection is complete. A Book Apart won���t be publishing any more new books. Don���t worry���you can still buy the existing titles at all good bookshops, like bookshop.org. They made sure to prepare the way for this decision.

I don���t know if I���ll ever be able to express how grateful I am to everyone at A Book Apart. They treated me very, very well. Heck, they even let me publish a second book.

Thank you, team���it was a pleasure and honour to collaborate with you.

PageSpeed Insights bookmarklet

I���m a little obsessed with web performance. I like being able to check a page���s core web vitals quickly and easily.

Four years ago, I made a Lighthouse bookmarklet. Whatever web page you were on, when you clicked on the bookmarklet you���d get the Lighthouse results for that page. Handy!

It doesn���t work anymore. This is probably because Google are in the loop. Four years is pretty good innings for anything involving that company.

I kid (mostly). Lighthouse itself is still going strong, despite being a Google product. But the bookmarklet needs updating.

Rather than just get Lighthouse results, I figured that the full PageSpeed Insights results would be even better. If your website is in the Chrome UX report, you get to see those CrUX details too.

So here���s the updated bookmarklet:

PageSpeed Insights

Drag that up to your desktop browser���s bookmarks toolbar. Press it whenever you want to test the page you���re on.

Tone and style

I���ve mentioned before that one of my roles at Clearleft is to be a content buddy:

If anyone is writing a talk, or a blog post, or a proposal and they want an extra pair of eyes on it, I���m there to help.

Ideally this happens in real time over video while we both have the same Google doc open:

That way, instead of just getting the suggestions, we can talk through the reasoning behind each one.

I was doing that recently with Rebecca when she was writing an announcement blog post for the Leading Design on-demand platform.

Talking through the structure, I suggested this narrative flow:

Start by describing the problem from the reader���s perspective���put yourself in their shoes and enumerate their struggles. This is the part of the story where you describe the dragon in all its horrifying detail.Now show them the sword, the supernatural aid that you can hand to them. Describe the product in purely subjective terms. No need to use adjectives. Let the scale of the offering speak for itself.Then step back into the reader���s shoes and describe what life will be like after they���ve signed up and they���ve slain the dragon.Finish with the call to adventure.

I think that blog post turned out well. And we both had good fun wrangling it into shape.

Today I was working on another great blog post, this time by Luke. Alas, the content buddying couldn���t be in real time so I had to make my suggestions asynchronously.

I still like to provide some reasoning for my changes, so I scattered comments throughout. I was also able to refer to something I put together a little while back…

Here���s the Clearleft tone of voice and style guide document.

I tried to keep it as short as possible. There���s always a danger that the style guide section in particular could grow and grow, so I kept to specific things that have come up in actual usage.

I hadn���t looked at it in a while so I was able to see it with somewhat fresh eyes today. Inevitably I spotted some things that could be better. But overall, I think it���s pretty good.

It���s just for internal use at Clearleft, but rather than have it live in a Google Drive or Dropbox folder, I figured it would be easier to refer to it with a URL. And we���ve always liked sharing our processes openly. So even though it���s probably of no interest to anyone outside of Clearleft, here it is: toneofvoice.clearleft.com

Speedier tunes

I wrote a little while back about improving performance on The Session by reducing runtime JavaScript in favour of caching on the server. This is on the pages for tunes, where the SVGs for the sheetmusic are now inlined instead of being generated on the fly.

It worked. But I also wrote:

A page like that with lots of sheetmusic and plenty of comments is going to have a hefty page weight and a large DOM size. I���ve still got a fair bit of main-thread work happening, but now the bulk of it is style and layout, whereas previously I had the JavaScript overhead on top of that.

Take a tune like Out On The Ocean. It has 27 settings. That���s a lot of SVG markup that needs to be parsed, styled and rendered, even if it���s inline.

Then I remembered a very handy CSS property called content-visibility:

It enables the user agent to skip an element’s rendering work (including layout and painting) until it is needed ��� which makes the initial page load much faster.

Sounds great! But there are two gotchas.

The first gotcha is that if a browser doesn���t paint the element, it doesn���t know how much space the element should take up. So you need to provide dimensions. At the very least you need to provide a height value. Otherwise when the element comes into view and gets rendered, it pushes down on the content below it. You���d see a sudden jump in the scrollbar position.

The solution is to provide a value for contain-intrinsic-size. If your content is dynamic���from, say, a CMS���then you���re out of luck. You don���t know how long the content is.

Luckily, in my case, I could take a stab at it. I know how many lines of sheetmusic there are for each tune setting. Each line takes up roughly the same amount of space. If I multiply that amount of space by the number of lines then I���ve got a pretty good approximation of the height of the sheetmusic. I apply this with the contain-intrinsic-block-size property.

So each piece of sheetmusic has an inline style attribute with declarations like this:

content-visibility: auto;contain-intrinsic-block-size: 380px;

It works a treat. I did a before-and-after check with pagespeed insights on the page for Out On The Ocean. The ���style and layout��� part of the main thread work went down considerably. Total blocking time went from more than 600 milliseconds to less than 400 milliseconds.

Not a bad result for a little bit of CSS!

I said there was a second gotcha. That���s browser support.

Right now content-visibility is only supported in Chrome and Edge. But that���s okay. This is a progressive enhancement. Adding this CSS has no detrimental effect on the browsers that don���t understand it (and when they do ship support for it, it���ll just start working). I���ve said it before and I���ll say it again: the forgiving error-parsing in HTML and CSS is a killer feature of the web. Browsers just ignore what they don���t understand. That���s what makes progressive enhancement like this possible.

And actually, there���s something you can do for all browsers. Even browsers that don���t support content-visibility still understand containment. So they���ll understand contain-intrinsic-size. Pair that with a contain declaration like this to tell the browser that this chunk of content isn���t going to reflow or get repainted:

contain: layout paint;

Here���s what MDN says about contain:

The contain CSS property indicates that an element and its contents are, as much as possible, independent from the rest of the document tree. Containment enables isolating a subsection of the DOM, providing performance benefits by limiting calculations of layout, style, paint, size, or any combination to a DOM subtree rather than the entire page.

So if you���ve got a chunk of static content, you might as well apply contain to it.

Again, not bad for a little bit of CSS!

Rotten Apple

The European Union���s Digital Markets Act is being enforced and Apple aren���t happy about it.

Most of the discussion around this topic has centred on the requirement for Apple to provision alternative app stores. I don���t really care about that because I don���t really care about native apps. With one exception: I care about web browsers.

That���s the other part of the DMA that���s being enforced: Apple finally have to allow alternative browsing engines. Hallelujah!

Instead of graciously acknowledging that this is what���s best for users, Apple are throwing a tantrum.

First of all, they���re going to ringfence any compliance to users in the European Union. Expect some very interesting edge cases to emerge in a world where people don���t spent their entire lives in one country.

Secondly, Apple keep insisting that this will be very, very bad for security. You can read Apple���s announcement on being forced to comply but as you do you so, I���d like you to remember one thing: every nightmare scenario they describe for the security of users in the EU is exactly what currently happens on Macs everywhere in the world.

This includes risks from installing software from unknown developers that are not subject to the Apple Developer Program requirements, installing software that compromises system integrity with malware or other malicious code, the distribution of pirated software, exposure to illicit, objectionable, and harmful content due to lower content and moderation standards, and increased risks of scams, fraud, and abuse.

Users of macOS everywhere are currently exposed to all the risks that will supposedly overwhelm iOS users in the European Union. Weirdly, the sky hasn���t fallen.

It���s the same with web browsers. I just got a new Mac. It came with one browser pre-installed: Safari. It���s a good browser. But I also have the option of installing another browser, like Firefox (which I���ve done). A lot of people just use Safari. That���s good. That���s choice. Everyone wins.

Now Apple need to provide parity on iOS, at least for users in the EU. Again, Apple are decribing this coming scenario as an absolute security nightmare. But again, the conditions they���re describing are what already exist on macOS.

All Apple is being asked to do is offer than the same level of choice on mobile that everyone already enjoys on their computers. Rather than comply reasonably, Apple have found a way to throw their toys of the pram.

As of the next update to iOS, users in the EU will no longer have homescreen apps. Those web apps will now launch in a browser window. Presumably they���ll also lose the ability to send push notifications: being a homescreen app was a prerequisite for that functionality.

This is a huge regression that only serves to harm and confuse users.

I have a website about traditional Irish music. Guess where a significant amount of the audience is based? That���s right: Ireland. In the European Union.

There is no native app for The Session, but you can install it on your phone nonetheless. Lots of people have done that. After a while they forget that they didn���t install it from an app store: it behaves just like any other app on their homescreen.

That���s all about to change. I���m going to get a lot of emails from confused users wondering why their app is broken, now opening in a regular browser window. And I won���t be able to do anything about it, other than to tell them to take it up with Apple.

Presumably Apple is hoping that users will direct their anger at the EU commission instead. They���re doing their best to claim that they���re being forced to make this change. That���s completely untrue. A lie:

This is emphatically not required by the EU���s Digital Markets Act (DMA). It���s a circumvention of both the spirit and the letter of the Act, and if the EU allows it, then the DMA will have failed in its aim to allow fair and effective browser and web app competition.

Throughout all their communications on this topic, Apple are sticking to their abuser logic:

Look what you made me do!

This is going to hurt me more than it hurts you.

Apple���s petulant policy of malicious compliance is extremely maddening. What they���re about to do to users in the EU is just nasty.

This is a very dark time for the web.

I feel bad for the Safari team. They���ve been working really hard recently to make Safari a very competitive browser with great standards support with a quicker release cycle than we���ve seen before. Then it all gets completely torpedoed at the level of the operating system.

I really hope that Apple won���t get away with their plan to burn down web apps on iOS in the EU. But hope isn���t enough. We need to tell the EU commission how much damage this will do.

If you���ve ever built a web app, then your users will suffer. Remember, it���s a world wide web, including the European Union.

Create a PDF with the following information:

Your company���s name.Your name.That your company operates or services the EU.How many users your service has in the EU��(approximately).The level of impact this will have on your business.The problems this will cause your business.Whether or not the submission is confidential.

The submission can be as short or long as you want. Send it to contactus@open-web-advocacy.org, ideally before Monday, February 19th.

I know that���s a lot to ask of you on your weekend, but this really matters for the future of the web.

At the very least, I encourage to get involved with the great work being done by the Open Web Advocacy group. They���re also on Discord.

Please don���t let Apple bully an entire continent of users.

Federation syndication

I���m quite sure this is of no interest to anyone but me, but I finally managed to fix a longstanding weird issue with my website.

I realise that me telling you about a bug specific to my website is like me telling you about a dream I had last night���fascinating for me; incredibly dull for you.

For some reason, my site was being brought to its knees anytime I syndicated a note to Mastodon. I rolled up my sleeves to try to figure out what the problem could be. I was fairly certain the problem was with my code���I���m not much of a back-end programmer.

My tech stack is classic LAMP: Linux, Apache, MySQL and PHP. When I post a note, it gets saved to my database. Then I make a curl request to the Mastodon API to syndicate the post over there. That���s when my CPU starts climbing and my server gets all ���bad gateway!��� on me.

After spending far too long pulling apart my PHP and curl code, I had to come to the conclusion that I was doing nothing wrong there.

I started watching which processes were making the server fall over. It was MySQL. That seemed odd, because I���m not doing anything too crazy with my database reads.

Then I realised that the problem wasn���t any particular query. The problem was volume. But it only happened when I posted a note to Mastodon.

That���s when I had a lightbulb moment about how the fediverse works.

When I post a note to Mastodon, it includes a link back to the original note to my site. At this point Mastodon does its federation magic and starts spreading the post to all the instances subscribed to my account. And every single one of them follows the link back to the note on my site ���all at the same time.

This isn���t a problem when I syndicate my blog posts, because I���ve got a caching mechanism in place for those. I didn���t think I���d need any caching for little ol��� notes. I was wrong.

A simple solution would be not to include the link back to the original note. But I like the reminder that what you see on Mastodon is just a copy. So now I���ve got the same caching mechanism for my notes as I do for my journal (and I did my links while I was at it). Everything is hunky-dory. I can syndicate to Mastodon with impunity.

See? I told you it would only be of interest to me. Although I guess there���s a lesson here. Something something caching.