Seb picks his top ten typefaces inspired by calligraphy.
Tuesday, October 19th, 2021
Thursday, October 7th, 2021
I’ve noticed a trend in recent years—a trend that I’ve admittedly been part of myself—where performance-minded developers will rebuild a site and then post a screenshot of their Lighthouse score on social media to show off how fast it is.
But I’m going to respectfully decline Phil’s advice to use any of the RUM analytics providers he recommends that require me to put another
script element on my site. One third-party script is one third-party script too many.
Keep this link handy to share with your boss or client. It is almost certainly not worth your while optimising for Internet Explorer.
Note: Google aren’t turning IE users away. Instead they’ll get a reduced scriptless experience. That’s the way to do it. Remember:
nomodule are your friends for cutting the mustard.
Importantly, Google has not simply cut off Internet Explorer 11 from using Google Search, leaving people unable to search the web. Instead, Internet Explorer customers are now shown a rudimentary “fallback experience” for Google Search, which can perform basic searches but isn’t as fully featured as Google is on modern browsers.
Tuesday, October 5th, 2021
This is such a handy tool for building forms! Choose different combinations of
autocomplete attributes on
input elements and see how that will be conveyed to users on iOS and Android devices.
Saturday, October 2nd, 2021
This speculative version of the internet archive invites you to see how websites will look in 2046.
Thursday, September 30th, 2021
If Apple allowed Safari to actually compete, it would be better for web developers, businesses, consumers, and for the health of the web. Come on, Apple, set Safari free!
Wednesday, September 29th, 2021
Internet users use fewer different websites today than they did 20 years ago, and spend most of their “Web” time in app versions of websites (which often provide a better experience only because site owners strategically make it so to increase their lock-in and data harvesting potential). Truly exploring the Web now requires extra effort, like exercising an underused muscle. And if you begin and end your Web experience on just one to three services, that just feels kind of… sad, to me. Wasted potential.
Tuesday, September 28th, 2021
I have this expensive computer in my pocket and it feels unfair that it is hamstrung in this very specific way of not allowing other browser engines. I also have an Apple laptop and it’s not hamstrung in that way, and I really hope it never is.
Sunday, September 26th, 2021
The wood wide web has been a powerhouse metaphor for popularizing the mutualistic relationships of healthy forests. But like a struggling forest, the web is no longer healthy. It has been wounded and depleted in the pursuit of profit. Going online today is not an invigorating walk through a green woodland—it’s rush-hour traffic alongside a freeway median of diseased trees, littered with the detritus of late capitalism. If we want to repair this damage, we must look to the wisdom of the forest and listen to ecologists like Simard when they tell us just how sustainable, interdependent, life-giving systems work.
A beautiful piece by the brilliant Claire L. Evans.
The project of decentralizing the web is vast, and only just beginning. It means finding a way to uproot our expression and communication from the walled gardens of tech platforms, and finding novel ways to distribute the responsibilities of infrastructure across a collective network. But we needn’t start from nothing.
Thursday, September 16th, 2021
Writing the Clearleft newsletter
I think it’s a really good newsletter, but then again, I’m the one who writes it. It just kind of worked out that way. In theory, anyone at Clearleft could write an edition of the newsletter.
To make that prospect less intimidating, I put together a document for my colleagues describing how I go about creating a new edition of the newsletter. Then I thought it might be interesting for other people outside of Clearleft to get a peek at how the sausage is made.
So here’s what I wrote…
The description of the newsletter is:
A round-up of handpicked hyperlinks from Clearleft, covering design, technology, and culture.
It usually has three links (maybe four, tops) on a single topic.
The topic can be anything that’s interesting, especially if it’s related to design or technology. Every now and then the topic can be something that incorporates an item that’s specifically Clearleft-related (a case study, an event, a job opening). In general it’s not very salesy at all so people will tolerate the occasional plug.
You can use the “iiiinteresting” Slack channel to find potential topics of interest. I’ve gotten in the habit of popping potential newsletter fodder in there, and then adding related links in a thread.
Imagine you’re telling a friend about something cool you’ve just discovered. You can sound excited. Don’t worry about this looking unprofessional—it’s better to come across as enthusiastic than too robotic. You can put real feelings on display: anger, disappointment, happiness.
That said, you can also just stick to the facts and describe each link in turn, letting the content speak for itself.
If you’re expressing a feeling or an opinion, use the personal pronoun “I”. Don’t use “we” unless you’re specifically referring to Clearleft.
But most of the time, you won’t be using any pronouns at all:
So-and-so has written an article in such-and-such magazine on this-particular-topic.
You might find it useful to have connecting phrases as you move from link to link:
Speaking of some-specific-thing, this-other-person has a different viewpoint.
On the subject of this-particular-topic, so-and-so wrote something about this a while back.
The format of the newsletter is:
- An introductory sentence or short paragraph.
- A sentence describing the first link, ending with the title of the item in bold.
- A link to the item on its own separate line.
- An excerpt from the link, usually a sentence or two, styled as a quote.
- Repeat steps 2 to 4 another two times.
Take a look through the archive of previous newsletters to get a feel for it.
Currently the newsletter is called dConstruct from Clearleft. The subject line of every edition is in the format:
dConstruct from Clearleft — Title of the edition
(Note that’s an em dash with a space on either side of it separating the name of the newsletter and the title of the edition)
I often try to come up with a pun-based title (often a punny portmanteau) but that’s not necessary. It should be nice and short though: just one or two words.
Tuesday, September 14th, 2021
I was doing some accessibility work with a client a little while back. It was mostly giving their site the once-over, highlighting any issues that we could then discuss. It was an audit of sorts.
While I was doing this I started to realise that not all accessibility issues are created equal. I don’t just mean in their severity. I mean that some issues can—and should—be caught early on, while other issues can only be found later.
Take colour contrast. This is something that should be checked before a line of code is written. When designs are being sketched out and then refined in a graphical editor like Figma, that’s the time to check the ratio between background and foreground colours to make sure there’s enough contrast between them. You can catch this kind of thing later on, but by then it’s likely to come with a higher cost—you might have to literally go back to the drawing board. It’s better to find the issue when you’re at the drawing board the first time.
Then there’s the HTML. Most accessibility issues here can be caught before the site goes live. Usually they’re issues of ommission: form fields that don’t have an explicitly associated
label element (using the
id attributes); images that don’t have
alt text; pages that don’t have sensible heading levels or landmark regions like
nav. None of these are particularly onerous to fix and they come with the biggest bang for your buck. If you’ve got sensible forms, sensible headings,
alt text on images, and a solid document structure, you’ve already covered the vast majority of accessibility issues with very little overhead. Some of these checks can also be automated:
alt text for images;
labels for inputs.
So if you commission an accessibility audit, you should hope to get feedback that’s mostly in that third category—interactive widgets.
If you get feedback on document structure and other semantic issues with the HTML, you should fix those issues, sure, but you should also see what you can do to stop those issues going live again in the future. Perhaps you can add some steps in the build process. Or maybe it’s more about making sure the devs are aware of these low-hanging fruit. Or perhaps there’s a framework or content management system that’s stopping you from improving your HTML. Then you need to execute a plan for ditching that software.
If you get feedback about colour contrast issues, just fixing the immediate problem isn’t going to address the underlying issue. There’s a process problem, or perhaps a communication issue. In that case, don’t look for a technical solution. A design system, for example, will not magically fix a workflow issue or route around the problem of designers and developers not talking to each other.
When you commission an accessibility audit, you want to make sure you’re getting the most out of it. Don’t squander it on issues that you can catch and fix yourself. Make sure that the bulk of the audit is being spent on the specific issues that are unique to your site.
Monday, September 13th, 2021
Stakeholders of styling
When I wrote about the new
accent-color property in CSS, I pondered how much control a web developer should have over styling form controls:
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 came down on the side of granting authors more control:
If developers don’t get a standardised way to customise native form controls, they’ll just recreate their own over-engineered versions.
This question of “who gets to decide?” used to be much more prevelant in the early days of the web. One way to think about this is that there are three stakeholders involved in the presentation of a web page:
- The author of the page. “Author” is spec-speak for designer or developer.
- The user.
- The browser, or user agent. A piece of software tries to balance the needs of both author and user. But, as the name implies, the user takes precedence.
These days we tend to think of web design a single-stakeholder undertaking. The author decides how something should be presented and then executes that decision using CSS.
But as Eric once said, every line of you CSS you write is a suggestion to the browser. That’s not how we think about CSS though. We think of CSS like a series of instructions rather than suggestions. Never mind respecting the user’s preferences; one of the first things we do is reset all the user agent’s styles.
In the early days of the web, more consideration was given to the idea of style suggestions rather than instructions. Heck, users could always over-ride any of your suggestions with their own user stylesheet. These days, users would need to install a browser extension to do the same thing.
h2.font.size = 20pt 40%
Here, the requested influence is reduced to 40%. If a style sheet later in the cascade also requests influence over h2.font.size, up to 60% can be granted. When the document is rendered, a weighted average of the two requests is calculated, and the final font size is determined.
I think the only remnant of “influence” left in CSS is accidental. It’s in the specificity of selectors …and the
I think it’s a shame that user stylesheets are no longer a thing. But I get why they were dropped from browsers. They date from a time when it was mostly nerds using the web, before “regular folks” came on board. I understand why it became a little-used feature, suitable for being dropped. But the principle of it still rankles slightly.
But in recent years there has been a slight return to the multi-stakeholder concept of styling websites. Thanks to
prefers-color-scheme, a responsible author can choose to bow to the wishes of the user.
I was reminded of this when I added a dark mode to my website:
Y’know, when I first heard about Apple adding dark mode to their OS—and also to CSS—I thought, “Oh, great, Apple are making shit up again!” But then I realised that, like user style sheets, this is one more reminder to designers and developers that they don’t get the last word—users do.
Thursday, September 9th, 2021
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.
Tuesday, September 7th, 2021
Bruce Lawson’s personal site : Briefing to the UK Competition and Markets Authority on Apple’s iOS browser monopoly and Progressive Web Apps
Following on from Stuart’s, here’s Bruce’s presentation to the CMA on Apple’s monopolistic practices and hostility to progressive web apps.
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.
A profile of Brewster Kahle and the Internet Archive in the San Francisco Chronicle.
Monday, September 6th, 2021
At its core, and despite its appropriation, Solarpunk imagines a radically different societal and economic structure.
Sunday, September 5th, 2021
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.