Jeremy Keith's Blog, page 16

Who knows?

I love it when I come across some bit of CSS I���ve never heard of before.

Take this article on the text-emphasis property.

���The what property?���, I hear you ask. That was my reaction too. But look, it���s totally a thing.

Or take this article by David Bushell called CSS Button Styles You Might Not Know.

Sure enough, halfway through the article David starts talking about styling the button in an input type="file��� using the ::file-selector-button pseudo-element:

All modern browsers support it. I had no idea myself until recently.

He���s right!

Then I remembered that I���ve got a file upload input in the form I use for posting my notes here on adactio.com (in case I want to add a photo). I immediately opened up my style sheet, eager to use this new-to-me bit of CSS.

I found the bit where I style buttons and this is the selector I saw:

button,input[type="submit"],::file-selector-button

Huh. I guess I did know about that pseudo-element after all. Clearly the knowledge exited my brain shortly afterwards.

There���s that tautological cryptic saying, ���You don���t know what you don���t know.��� But I don���t even know what I do know!

Fidinpamp

If you���re a fan of gratuitous initialisms, you���ll love Google���s core web vitals. Just get a load of the obfuscation in the important-sounding metrics like CLS, FCP, LCP, and more.

To be fair to Google, this is a problem in the web performance world in general. Practioners prefer to talk about TTFB rather than ���time to first byte��� even though both contain exactly the same number of syllables.

The big news in the web performance community this month is the arrival of a new initialism. INP sounds like one of those pseudo-scientific psychologic profiles but it���s meant to stand for Interaction to Next Paint (even if they were to swear off pointless initialisms, you���d still have to pry Pointless Capitalisation from Google���s cold dead hands).

This new metric is a welcome one. It���s replacing first input delay. Sorry, First Input Delay, or FID, one of the few web vital initialisms that can be spoken as a word, making it a true acronym (fortunately fid���s successor, inp, also works as an acronym).

First Input Delay has long outstayed its welcome. It was always an outlier in the core web vitals. It didn���t seem to measure anything actually useful. I know it sounds like it���s measuring the delay until the user can interact with a web page, but when you dive into what it actually does, it���s a mess:

FID measures the time from when a user first interacts with a page (that is, when they click a link, tap on a button, or use a custom, JavaScript-powered control) to the time when the browser is actually able to begin processing event handlers in response to that interaction.

See that word ���begin��� in there? It���s doing a lot of work. First Input Delay doesn���t measure the lag between the user interaction and the browser response; it only measures the lag between the user interaction and the browser beginning to respond. The actual response could take ages, but that lag doesn���t get measured. Unlike the other core web vitals, this metric is very far removed from what actually matters to the user���s experience.

What the fid where they thinking? How the fid did this measurement ever get included in core web vitals in the first place?

Well, feel free to take what I���m about to say as pure gossip, but I have my sources, I trust ���em, and no, I���m not going to reveal ���em���

It���s because of AMP.

Remember Google AMP? An acronym so pointless they eventually just forgot it ever stood for anything?

The AMP project ended up doing incredible damage to Google���s developer relations. By colluding with the search team to privilege the appearance of AMP pages in the top news carousel, Google effectively blackmailed the entire publishing industry into using their format.

In the end, it didn���t work. It was a shit format. All they did was foster resentment and animosity:

AMP seems to have faded away. Most publishers have started dropping support, and even Google doesn���t seem to care much anymore.

It turns out that Google search wasn���t the only team infected by AMP. The core web vitals team also had to play ball.

Originally they had a genuinely useful metric for measuring the lag between input and response. But guess which pages did terribly? That���s right: AMP pages.

Rather than ship an actually-useful measurement, the core web vitals team instead had to include the broken First Input Delay, brainchild of a certain someone on the AMP team.

Now it all makes sense.

So good riddance to FID. Welcome to INP. And here���s hoping it won���t be much longer till we���re finally burying AMP.

Progressive disclosure defaults

When I wrote about my time in Amsterdam last week, I mentioned the task that the students were given:

They���re given a PDF inheritance-tax form and told to convert it for the web.

Rich had a question about that:

I’m curious to know if they had the opportunity to optimise the user experience of the form for an online environment, eg. splitting it up into a sequence of questions, using progressive disclosure, branching based on inputs, etc?

The answer is yes, very much so. Progressive disclosure was a very clear opportunity for enhancement.

You know the kind of paper form where it says ���If you answered no to this, then skip ahead to that���? On the web, we can do the skipping automatically. Or to put it another way, we can display a section of the form only when the user has ticked the appropriate box.

This is a classic example of progressive disclosure:

information is revealed when it becomes relevant to the current task.

But what should the mechanism be?

This is an interaction design pattern so JavaScript seems the best choice. JavaScript is for behaviour.

On the other hand, you can do this in CSS using the :checked pseudo-class. And the principle of least power suggests using the least powerful language suitable for a given task.

I���m torn on this. I���m not sure if there���s a correct answer. I���d probably lean towards JavaScript just because it���s then possible to dynamically update ARIA attributes like aria-expanded���very handy in combination with aria-controls. But using CSS also seems perfectly reasonable to me.

It was interesting to see which students went down the JavaScript route and which ones used CSS.

It used to be that using the :checked pseudo-class involved an adjacent sibling selector, like this:

input.disclosure-switch:checked ~ .disclosure-content { display: block;}

That meant your markup had to follow a specific pattern where the elements needed to be siblings:

...

But none of the students were doing that. They were all using :has(). That meant that their selector could be much more robust. Even if the nesting of their markup changes, the CSS will still work. Something like this:

.disclosure-container:has(.disclosure-switch:checked) .disclosure-content

That will target the .disclosure-content element anywhere inside the same .disclosure-container that has the .disclosure-switch. Much better! (Ignore these class names by the way���I’m just making them up to illustrate the idea.)

But just about every student ended up with something like this in their style sheets:

.disclosure-content { display: none;}.disclosure-container:has(.disclosure-switch:checked) .disclosure-content { display: block;}

That gets my spidey-senses tingling. It doesn’t smell right to me. Here’s why���

The simpler selector is doing the more destructive action: hiding content. There’s a reliance on the more complex selector to display content.

If a browser understands the first ruleset but not the second, that content will be hidden by default.

I know that :has() is very well supported now, but this still makes me nervous. I feel that the more risky action (hiding content) should belong to the more complex selector.

Thanks to the :not() selector, you can reverse the logic of the progressive disclosure:

.disclosure-content { display: block;}.disclosure-container:not(:has(.disclosure-switch:checked)) .disclosure-content { display: none;}

Now if a browser understands the first ruleset, but not the second, it’s not so bad. The content remains visible.

When I was explaining this way of thinking to the students, I used an analogy.

Suppose you’re building a physical product that uses electricity. What should happen if there’s a power cut? Like, if you’ve got a building with electric doors, what should happen when the power is cut off? Should the doors be locked by default? Or is it safer to default to unlocked doors?

It’s a bit of a tortured analogy, but it’s one I’ve used in the past when talking about JavaScript on the web. I like to think about JavaScript as being like electricity���

Take an existing product, like say, a toothbrush. Now imagine what you can do when you turbo-charge it with electricity: an electric toothbrush!

But also consider what happens when the electricity fails. Instead of the product becoming useless you want it to revert back to being a regular old toothbrush.

That’s the same mindset I’m encouraging for the progressive disclosure pattern. Make sure that the default state is safe. Then enhance.

What the world needs

I was having a discussion with some people recently about writing. It was quite cathartic. Everyone was sharing the kinds of things that their inner critic tells them. We were all encouraging each other to ignore that voice.

I mentioned that the two reasons for not writing that I hear most often from people are variations on ���I���ve got nothing to say.���

The first version is when someone says they���ve got nothing to say because they���re not qualified to write on a particualar topic. ���After all, there are real experts out there who know far more than me. So I���ve got nothing to say.���

But then once you do actually understand a topic, the second version appears. ���If I know about this, then everyone knows about this. It���s obvious. So I���ve got nothing to say.���

In both cases, you absolutely should be writing and sharing! In the first instance, you���ve got the beginner���s mind���a valuable perspective. In the second instance, you���ve got personal experience���another valuable perspective.

In other words, while it seems like there���s never a good time to write about something, the truth is that there���s never a bad time to write about something.

So write! Share! Publish!

Then someone in the discussion said something I always find a bit deflating. They said they had no problem writing, but they���re not so keen on publishing.

���After all���, they said, ���the world doesn���t need yet another opinion.���

This gets me down because it���s hard to argue with. It���s true that the world doesn���t need another think piece. The world doesn���t need to hear your thoughts on some topic. The world doesn���t need to hear what you���ve been up to recently.

But you know what? Screw what the world needs.

If we���re going to be hardnosed about this, then the world doesn���t need any more books. The world doesn���t need any more music. The world doesn���t need art. Heck, the world doesn���t need us at all.

So don���t publish for the world.

When I write something here on my website, I���m not thinking about the world reading it. That would be paralyzing. I do sometimes imagine that one person is reading it; someone just like me who hasn���t yet had this particular thought, or come up with that particular idea.

I���m writing for myself. I write to figure out what I think. I also publish mostly for myself���a public archive for future me. But if what I publish just happens to connect with one other person, I���m glad.

So, yeah, it���s true that the world doesn���t need you to write and share and publish. Isn���t that liberating? You���re free to write and share and publish for yourself.

Schooltijd

I was in Amsterdam last week. Usually I���m in that city for an event like the excellent CSS Day. Not this time. I was there as a guest of Vasilis. He invited me over to bother his students at the CMD (Communications and Multimedia Design) school.

There���s a specific module his students are partaking in that���s right up my alley. They���re given a PDF inheritance-tax form and told to convert it for the web.

Yes, all the excitement of taxes combined with the thrilling world of web forms.

Seriously though, I genuinely get excited by the potential for progressive enhancement here. Sure, there���s the obvious approach of building in layers; HTML first, then CSS, then a sprinkling of JavaScript. But there���s also so much potential for enhancement within each layer.

Got your form fields marked up with the right input types? Great! Now what about autocomplete, inputmode, or pattern attributes?

Got your styles all looking good on the screen? Great! Now what about print styles?

Got form validation working? Great! Now how might you use local storage to save data locally?

As well as taking this practical module, most of the students were also taking a different module looking at creative uses of CSS, like making digital fireworks, or creating works of art with a single div. It was fascinating to see how the different students responded to the different tasks. Some people loved the creative coding and dreaded the progressive enhancement. For others it was exactly the opposite.

Having to switch gears between modules reminded me of switching between prototypes and production:

Alternating between production projects and prototyping projects can be quite fun, if a little disorienting. It���s almost like I have to flip a switch in my brain to change tracks.

Here���s something I noticed: the students love using :has() in CSS. That���s so great to see! Whereas I might think about how to do something for a few minutes before I think of reaching for :has(), they���ve got front of mind. I���m jealous!

In general, their challenges weren���t with the vocabulary or syntax of HTML, CSS, and JavaScript. The more universal problem was project management. Where to start? What order to do things in? How long to spend on different tasks?

If you can get good at dealing with those questions and not getting overwhelmed, then the specifics of the actual coding will be easier to handle.

This was particularly apparent when it came to JavaScript, the layer of the web stack that was scariest for many of the students.

I encouraged them to break their JavaScript enhancements into two tasks: what you want to do, and how you then execute that.

Start by writing out the logic of your script not in JavaScript, but in whatever language you���re most comfortable with: English, Dutch, whatever. In the course of writing this down, you���ll discover and solve some logical issues. You can also run your plain-language plan past a peer to sense-check it.

It���s only then that you move on to translating your logic into JavaScript. Under each line of English or Dutch, write the corresponding JavaScript. You might as well put // in front of the plain-language sentence while you���re at it to make it a comment���now you���ve got documentation baked in.

You���ll still run into problems at this point, but they���ll be the manageable problems of syntax and typos.

So in the end, it wasn���t my knowledge of specific HTML, CSS, or JavaScript APIs that proved most useful to pass on to the students. It was advice like that around how to approach HTML, CSS, or JavaScript.

I also learned a lot during my time at the school. I had some very inspiring conversations with the web developers of tomorrow. And I was really impressed by how much the students got done just in the three days I was hanging around.

I���d love to do it again sometime.

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.