Jeremy Keith

Jeremy Keith

Making websites. Writing books. Hosting a podcast. Speaking at events. Living in Brighton. Working at Clearleft. Playing music. Taking photos. Answering email.

Journal 2810 sparkline Links 9256 sparkline Articles 79 sparkline Notes 6073 sparkline

Thursday, September 9th, 2021

Chrome is the new Safari. And so are Edge and Firefox. – Hello my name is Niels Leenheer

You may not realise that all browsers on iOS are required to use the same rendering engine as Safari. On other platforms, this is not the case.

A terrific in-depth look at the frustrating state of the web on iOS.

So it’s not just one browser that falls behind. It’s all browsers on iOS. The whole web on iOS falls behind. And iOS has become so important that the entire web platform is being held back as a result.

And this damning assessment is mercifully free of conspiracy theories.

The Safari and Chrome team both want to make the web safer and work hard to improve the web. But they do have different views on what the web should be.

Google is focussing on improving the web by making it more capable.

Safari seems to focus on improving the web as it currently is.

Read the whole thing—it’s excellent!

There can only be one proper solution: Apple needs to open up their App Store to browsers with other rendering engines. Scrap rule 2.5.6 and allow other browsers on iOS and let them genuinely compete. Even though Apple has been forced to compromise on some App Store rules, I have little hope for this to happen.

Accent all areas

Whenever a new version of Chrome comes out, there’s an accompanying blog post listing what’s new. Chrome 93 just came out and, sure enough, Pete has written a blog post about it.

But what I think is the most exciting addition to the browser isn’t listed.

What is this feature that’s got me so excited?

Okay, I’ve probably oversold it now because actually, it looks like a rather small trivial addition. It’s the accent-color property in CSS.

Up until now, accent colour was controlled by the operating system. If you’re on a Mac, go to “System Preferences” and then “General”. There you’ll see an option to change your accent colour. Try picking a different colour. You’ll see that change cascade down into the other form fields in that preference pane: checkboxes, radio buttons, and dropdowns.

Your choice will also cascade down into web pages. Any web page that uses native checkboxes, radio buttons and other interface elements will inherit that colour.

This is how interface elements are supposed to work. The browser inherits the look’n’feel of the inputs from the operating system.

That’s the theory anyway. In practice, form elements—such as dropdowns—can look different from browser to browser, something that shouldn’t be happening if the browsers are all inheriting from the operating system.

Anyway, it’s probably this supposed separation of responsibility between browser and operating system which has led to the current situation with form fields and CSS. Authors can style form fields up to a point, but there’s always a line that you don’t get to cross.

The accent colour of a selected radio button or a checkbox has historically been on the other side of that line. You either had to accept that you couldn’t change the colour, or you had to make your own checkbox or radio button interface. You could use CSS to hide the native element and replace it with an image instead.

That feels a bit over-engineered and frankly kind of hacky. It reminds me of the bad old days of image replacement for text before we had web fonts.

Now, with the accent-color property in CSS, authors can over-ride the choice that the user has set at the operating system level.

On the one hand, this doesn’t feel great to me. Who are we to make that decision? Shouldn’t the user’s choice take primacy over our choices?

But then again, where do we draw the line? We’re allowed over-ride link colours. We’re allowed over-ride font choices.

Ultimately I think it’s a good thing that authors can now specify an accent colour. What makes me think that is the behaviour that authors have shown if they don’t have this ability—they do it anyway, and in a hackier manner. This is why I think the work of the Open UI group is so important. If developers don’t get a standardised way to customise native form controls, they’ll just recreate their own over-engineered versions.

The purpose of Open UI to the web platform is to allow web developers to style and extend built-in web UI controls, such as select dropdowns, checkboxes, radio buttons, and date/color pickers.

Trying to stop developers from styling checkboxes and radio buttons is like trying to stop teenagers from having sex. You might as well accept that it’s going to happen and give them contraception so they can at least do it safely.

So I welcome this new CSS condom.

You can see accent-color in action in this demo. Change the value of the accent-color property to see the form fields update:

:root {
  accent-color: rebeccapurple;
}

Applying it at the document level like that will make it universal, but you can also use the property on an element-by-element basis using whatever selector you want.

That demo works in Chrome and Edge 93, the current release. It also works in Firefox 92, which literally just landed (like as I was writing this blog post, support for accent-color magically arrived!).

As for Safari, well, who knows? If Apple published a roadmap, then developers would have a clue when to expect a property like this to land. But we mere mortals cannot be trusted with such important hush-hush information.

In the meantime, keep an eye on Can I Use. And lack of support on one browser is no reason not to use accent-color anyway. It’s a progressive enhancement. Add it to your CSS today and it will work in more browsers in the future.

Can we have custom media queries, please?

I knew that custom properties don’t work in media queries but I had no idea that there was such a thing as custom media queries, which effectively do the same thing.

But this is not implemented in any browser. Boo! This would be so useful! If browser makers can overcame the technical hurdles with container queries, I’m sure they can deliver custom media queries.

Wednesday, September 8th, 2021

Coaching on the Clearleft podcast

Season three of the Clearleft podcast is here!

The first episode is a nice gentle one to ease into things. It’s about coaching …and training …and mentorship. Basically I wanted to find out what the differences are between those three things.

But I must confess, there’s a commercial reason why this episode is coming out now. There’s a somewhat salesy promotion of an upcoming coaching programme with Julia Whitney. This is definitely the most overt marketing I’ve done on the Clearleft podcast, but if you listen to the episode, I think you’ll agree that it fits well with the theme.

Fear not, future episodes will not feature this level of cross-promotion. Far from it. You can expect some very revealing podcast episodes that pull no punches in getting under the skin of design at Clearleft.

The stars of this episode are my colleagues Rebecca and Chris, who were an absolute joy to interview.

Have a listen and hear for yourself.

Tuesday, September 7th, 2021

as days pass by — Talking to the Competition and Markets Authority about Apple

What I would like is that I can give users the best experience on the web, on the best mobile hardware. That best mobile hardware is Apple’s, but at the moment if I want to choose Apple hardware I have to choose a sub-par web experience. Nobody can fix this other than Apple, and there are a bunch of approaches that they could take — they could make Safari be a best-in-class experience for the web, or they could allow other people to collaborate on making the browser best-in-class, or they could stop blocking other browsers from their hardware. People have lots of opinions about which of these, or what else, could and should be done about this; I think pretty much everyone thinks that something should be done about it, though.

The Single-Page-App Morality Play – Baldur Bjarnason

I keep seeing Single-Page-Apps with huge JS files that only, in terms of concrete User Experience (UX) benefits, deliver client-side validation of forms plus analytics. Apps rarely leverage the potential of a Single-Page-App. It’s still just the same ‘click, wait for load’ navigation cycle. Same as the one you get with Multi-Page-Apps. Except buggier and with a much slower initial loading time.

When you look at performance, cross-platform and mobile support, reliability, and accessibility, nearly every Single-Page-App you can find in the wild is a failure on multiple fronts.

Replacing those with even a mediocre Multi-Page-App is generally going to be a substantial win. You usually see improvements on all of the issues mentioned above. You get the same general UX except with more reliable loading, history management, and loading features—provided by the browser.

Before you dismiss Baldur as a hater based on what I’ve just quoted, you should really read the whole article. The issue he points to is not with the technical architecture of single page apps, but with management.

Single-Page-Apps can be fantastic. Most teams will mess them up because most teams operate in dysfunctional organisations.

A lot of what he says really resonates with me. Over and over again I’ve seen projects where the technical decison around which monolithic client-side JavaScript framework to use has been made even before a problem has been defined.

Baldur’s conclusion chimes a lot with what I’ve been saying in conference talks this year: the biggest challenges facing the web are not technical in nature.

The biggest hindrance to the web’s progress isn’t non-expert developers, tooling, libraries, Single-Page-Apps, or Multi-Page-Apps.

It’s always humans.

Using the platform

Elise Hein documents what it was like to build a website (or web app, if you prefer) the stackless way:

  • use custom elements (for modular HTML without frameworks)
  • use the in-browser package manager (for JavaScript packages without build tools)
  • match pages with files (to avoid routing and simplify architecture)
  • stick to standards (to avoid obsolescence and framework fatigue)

Her conclusions are similar to my own: ES6 modules mean you can kiss your bundler goodbye; web components are a mixed bag—it’s frustrating that Apple are refusing to allow native elements to be extended. Interestingly, Elise feels that a CSS preprocessor is still needed for her because she wants to be able to nest selectors …but even that’s on its way now!

Perhaps we might get to the stage where it isn’t an automatic default to assume you’ll need bundling, concatenation, transpiling, preprocessing, and all those other tasks that we’ve become dependent on build tools for.

I have a special disdain for beginner JavaScript tutorials that have you run create-react-app as the first step, and this exercise has only strengthened my conviction that every beginner programmer should get to grips with HTML, CSS and vanilla JS before delving into frameworks. Features native to the web are what all frameworks share, and knowing the platform makes for a stronger foundation in the face of change.

Monday, September 6th, 2021

Season three of the Clearleft podcast

If you’re not already subscribed to the Clearleft podcast, you should probably remedy that. The third season is about to drop any day now.

Once again, the season will comprise six episodes released on a weekly schedule.

That’s a cadence I more or less picked at random, but I think it’s working out well. Six episodes are enough for the podcast to sustain your interest without overstaying its welcome. And by taking nice long breaks between seasons, you’re never going to end up with that podcast problem of having a backlog of episodes that you never seem to get around to listening to.

That said, if you did fancy going through the backlog, there’s a mere twelve episodes for you to catch up on. Six from season one and six from season two. None of the episodes are overly long. Again, I don’t want this podcast to overstay its welcome. I respect your time. A typical episode is somewhere between 20 and 25 minutes of multiple viewpoints and voices.

You can subscribe to the RSS feed or use whichever service you prefer to get your podcasts from: Apple, Google, Spotify, Stitcher, Deezer, TuneIn, Castro, Pocket Casts, Player FM, or my own personal choice, Overcast.

Or you could just huffduff whichever episodes sound most appealing to you. But honestly, and I may be biased here, they’re all pretty darn great so I recommend subscribing.

If you subscribe now, then the episodes from season three will magically appear in your podcast software of choice. Again, I know I’m biased, but this is going to be an excellent season featuring some very smart folks sharing their stories.

Just to be clear, in case you haven’t listened to the Clearleft podcast before, this isn’t your usual podcast format. Yes, I interview people but I don’t release one interview per episode. Instead, each episode zeroes in one topic, and features different opinions from different people. It’s tight and snappy with no filler. That involves a lot of production and editing work, but I think it’s worth it for the end result.

Can you tell that I’m excited?

Sunday, September 5th, 2021

IndieWeb Events: Gardens and Streams II

September 25th, online:

We’ll discuss and brainstorm ideas related to wikis, commonplace books, digital gardens, zettelkasten, and note taking on personal websites and how they might interoperate or communicate with each other. This can include IndieWeb building blocks, user interfaces, functionalities, and everyones’ ideas surrounding these. Bring your thoughts, ideas, and let’s discuss and build.

Saturday, September 4th, 2021

Thinking about my recent trip to Zürich, I must admit that there are many advantages to living in Switzerland.

The flag is a big plus, for one thing.