Tags: presentation

444

sparkline

Friday, June 24th, 2022

Talking about style

I’ve published a transcription of the talk I gave at CSS Day:

In And Out Of Style.

The title is intended to have double meaning. The obvious reference is that CSS is about styling web pages. But the talk also covers some long-term trends looking at ideas that have appear, disappear, and reappear over time. Hence, style as in trends and fashion.

There are some hyperlinks in the transcript but I also published a list of links if you’re interested in diving deeper into some of the topics mentioned in the talk.

I also published the slides but, as usual, they don’t make much sense out of context. They’re on Noti.st too.

I made an audio recording for your huffduffing pleasure.

There are two videos of this talk. On Vimeo, there’s the version I pre-recorded for An Event Apart online. On YouTube, there’s the recording from CSS Day.

It’s kind of interesting to compare the two (well, interesting to me, anyway). The pre-recorded version feels like a documentary. The live version has more a different vibe and it obviously has more audience interaction. I think my style of delivery suits a live audience best.

I invite you to read, watch, or listen to In And Out Of Style, whichever you prefer.

Wednesday, June 22nd, 2022

In And Out Of Style

A presentation from An Event Apart Spring Summit held online in April 2022 and the opening presentation at CSS Day held in Amsterdam in June 2022.

Hello, my name is Jeremy and I am speaking to you today from Brighton on the south coast of England.

I want to tell you about something that happened here in Brighton back in 1985 (pretty sure it took place in one of those buildings along the seafront there). In 1985 Brighton was host to the International Information Theory Symposium. Fascinating.

Something exciting happened there. Word began to go around that there was an unexpected guest attending the event. This unexpected guest was this man, Claude Shannon. The way it was described later was somebody said it was as if Newton had showed up at a physics conference.

He wasn’t even meant to be there, but he was convinced at the dinner after the event to get up and say a few words. And he did, he got up and he started to talk, but he felt like he was losing the audience. So he proceeded to do some juggling.

That’s so Claude Shannon. He was very much into games. He took games very seriously. He was a very playful kind of person.

For example, he invented this machine, which is called the most beautiful machine, also the most useless machine. But I think it’s just wonderful. I mean, it’s like the perfect encapsulation of cybernetics, the ideal feedback loop.

But the reason why people were excited that Claude Shannon was at this event wasn’t because of the most beautiful machine. And it wasn’t because of his juggling. It was because of information theory.

Because Claude Shannon, it’s not like he just revolutionized the field of information theory; Claude Shannon pretty much invented the field of information theory in one fell swoop. In a paper in 1948 called the Mathematical Theory of Communication.

Here’s the TLDR. This is the mathematical part. I won’t go into the details of the mathematical part, but what I recall from Claude Shannon’s work is that he was able to effectively boil information down into fundamental particles. The idea that there’s a single bit of information.

This idea of entropy, the idea that for information to travel between communicator and the receiver, you’ve got the signal that you’re trying to transmit, but there’s also noise. And this noise is unavoidable.

And like I said, this idea of the bit; that any piece of information could be reduced down to a fundamental particle: a one or a zero; on or off, which of course is exactly how computers work. So it’s no exaggeration to say that Claude Shannon is like the father of the digital age.

And one other thing I take from Claude Shannon’s work is that when it comes to communication of information, context matters. In other words, that the expectation between the receiver and the communicator can make a lot of difference.

Shared context

So to give you an example of shared context being very important in information communication I want to illustrate it with a story from the pre-digital age. This is a story from the age of the electrical telegraph.

Now this story is probably completely apocryphal. In some versions of the story, it involves the novelist Victor Hugo. In other versions, it’s Oscar Wilde. But the point is there’s an author. He’s just published a book and now he’s gone off on holiday after writing the book. But while he’s on holiday, he’s really curious to know, how is the book doing? What are the sales like?

So he sends a telegram to his publisher, but because there’s enough shared context between the publisher and the author, all he sends is a single character. A question mark.

?

And then, because there’s this shared context between the publisher and the author and the publisher wants to let the author know that actually sales are going really, really well, the publisher also sends back a telegram with a single character. An exclamation mark.

!

So this is a classic example of the importance of context. I mean, you’re just sending a single character and yet both parties understand the message being conveyed.

Context matters. Shared context matters.

Now I want to try an experiment with you to test how much shared context there is between me (I’m going to try to transmit a message) and you (the receiver of the message).

So we’re starting with a blank slate. And now I’m going to provide one piece of information. Okay. Here’s the piece of information. Probably doesn’t tell you much. A diagonal line. There’s not enough context here.

All right. Back to the blank slate. I’m now going to provide another piece of information.

Okay. Again, in isolation, this probably doesn’t tell you much just another diagonal line. But if I combine it with the first bit of information, then now maybe it starts to become something you can parse. And if I provide just one more bit of information, now maybe it clicks into place that the piece of information I’m trying to convey is ten minutes past ten.

And yet all I’ve done here is I’ve provided you with two diagonal lines in a circle. Yet somehow two diagonal lines in a circle, when we have the shared context of how to read an analogue clock face, is enough to communicate ten minutes past ten.

(The time, by the way, is completely arbitrary. The only reason I chose that time is just that if you ever look at an advertisement for a watch, it’ll usually be ten past ten because the angles of the arms on the watch nicely frame the logo of the watchmaker.)

But anyway, the point is: with enough shared context, two diagonal lines in a circle are enough for me to communicate the piece of information, “ten minutes past ten o’clock.”

I mean, maybe you’re a digital native born in a 21st century, in which case you’re looking at this and thinking, “I just see two diagonal lines in a circle”, but if you can read an analogue clock face, then we have that shared context.

Where did this context come from? Why is it that that clock faces are set up the way they are? Why do clocks go clockwise? It seems like a fairly arbitrary decision.

It is somewhat arbitrary, but one neat solution is that the reason why clocks go in a clockwise direction is that that’s the way that a shadow on a sundial would travel …in the Northern hemisphere.

Now if you look at a sundial in the Southern hemisphere, like this one here—this is in Wellington, in New Zealand—the shadow would actually go in a counterclockwise direction.

A sundial in the Southern hemisphere.

So really it’s almost an accident of history that we have clocks that go clockwise. If clocks had been invented in the Southern hemisphere, then they would go in the other direction. It’s pretty arbitrary, but now we’ve decided, we’ve kind of settled on this arbitrary movement of clocks that they go clockwise and we’re stuck with it.

Because inertia is a very powerful force. If you tried to change the way the clocks work you’d have your work cut out for you, even if the reason why clocks work the way they do is arbitrary to begin with.

Inertia

You know, a very wise person once said the most dangerous phrase in the English language is “We’ve always done it that way.” And that very wise person was the brilliant computer scientist, rear admiral Grace Hopper.

Grace Hopper

She used to say:

Humans are allergic to change.

She said:

I try to fight that. And that’s why I have a clock on my wall that runs counterclockwise.

Right? It kind of drives home this idea that, hey, this is an arbitrary decision.

And it’s kind of weird for us to look at a clock that runs counterclockwise. I actually managed to find a watch a few years ago that worked like this, that ran counterclockwise. And I wore it for a while and I was able to train my brain to read the clock this way. And it worked fine, but it completely broke my brain for reading normal clocks. So I kind of had to just stop doing it.

But I’m fascinated by these examples of fairly arbitrary decisions made sometime in the past that you’re then stuck with, because it’s very hard to change the inertia. But only recently did I find out that there’s a term for this phenomenon. This is called path dependence.

Path dependence

History is full of path dependence. The classic example is if you wanted to make a new train or a new stretch of railway track, you’re gonna have to use the existing gauge of the railway in question. Now it’s not that there’s one gauge of railway that’s better or worse than any other gauge, but if someone’s made that decision in the past, it’s very hard to change. And you really do want to settle on one gauge so that you don’t have to switch trains when you move between different parts of a country (this actually happened down in Australia, where they had different gauges for the railways, it was kind of a mess).

It’s the canonical example of why you need standards. But really the point of standards isn’t necessarily to enshrine the best way of doing something. The point of standards is to enshrine the agreement. “Hey, let’s all agree to do things this.”

Whether the standard is good, bad, better or worse than other ways of doing things is in some ways less important than the agreement. You just need to have everyone agree on something.

Like, there’s a standard for which side of the road you drive on in your country. And it doesn’t really matter whether the standard is for it to be on the left side of the road or the right hand side of the road. But it really matters that you all agree on the same side of the road.

Agreement and standards brings us very nicely to the World Wide web. Because I think the World Wide web is a fantastic example of agreement.

The web is agreement

There’s a friend of mine, Paul Downey, who does these wonderful illustrations. Fantastic. He has this one called “the web is agreement.” Whenever I think about the word agreement, this is what I think of: that the web is agreement. And he does these kind of Hieronymous Bosch and Breughel-like images of all the different formats and standards that we use on the web.

The Web Is Agreement by Paul Downey.

And if you think about what the World Wide Web is, this combination of HTTP and URLs and HTML. This was, you know, when the web was first created. Yeah, these are just agreements.

I mean, HTTP is a protocol and that word protocol literally means agreement. (If you think about diplomatic protocols that are like diplomatic agreements, right?)

URLs, “Hey, let’s all agree to use this addressing scheme.”

And HTML, “If we all agree to use this format, then we get interoperability.”

So these formats, these protocols, this set of standards or agreements came from Sir Tim Berners-Lee. This was back when he was working at CERN at the nuclear physics laboratory in the late 1980s, early ’90s.

I’m somewhat fascinated about the birth of the web, which is why it was a huge honour and pleasure for me to be invited to CERN a few years back. This was in the run up to the 30th anniversary of the original proposal that Tim Berners-Lee submitted for what later became the World Wide web. And we did this project and you can check out the project at worldwideweb30.com.

This wonderful group of people came together for a week to kind of hack on something. And what we were hacking on was this project to recreate the very first web browser …but that you could run it in a modern web browser. This is what it looked like.

The first web browser was also called confusingly WorldWideWeb. It was created by Tim Berners-Lee on his NeXT machine. And this was the first demonstration of those three things working together: HTTP, URLs and HTML.

Now I say we were working on this. I didn’t make this part. This was the really smart bit; much cleverer people were working on the smart bit. What I worked on was the website that accompanied the project.

And specifically I worked on creating a timeline.

Timeline

Remember this is coming up on the 30th anniversary of the web, and I thought it’d be fascinating to not just graph out the 30 years that the web has existed, but also look back at the 30 years before the web existed to see what were the influences that fed into the web.

What I was looking at here really was the path dependencies. What were the path dependencies in computing and networks, hypertext and formats that all fed into that creation of the World Wide Web?

So let’s take formats, for example. Tim Berners-Lee creates HTML along with URLs and HTTP.

And if I show you these elements, they should be quite familiar to you. You recognize what this language is, right? Yeah. Clearly this language is…

SGML. Standard Generalized Markup Language.

Specifically, it’s a flavor of SGML that was being used in CERN at the time. And Tim Berners-Lee thought rather than create his own format, he would use what people were already used to.

He kind of had the same insight that Grace Hopper had, that humans are allergic to change. But instead of trying to change that, he sort of went with the flow.

So he took SGML and basically copied it to make HTML, introducing one new element, which is the, A element.

So, you know, there’s a path dependency, even in the name, right? You think Standard Generalized Markup Language. Oh right. And now we have HyperText Markup Language. So even the name HTML seems to have a path dependency to SGML.

But it goes deeper.

SGML was a specialized version of GML. And GML was supposed to stand for Generalized Markup Language. Except the people who created GML were named Goldfarb, Mosher, and Lorie, which is probably the real reason why it was named GML.

And later we got SGML and then we got HTML. So it turns out there’s a path dependency in the phrase “HTML” that goes back to three dudes wanting to get their names into a format many, many years ago.

Styling

What about styling when it came to the early web?

There’s no CSS at this point. But if you look at this first web browser—and this is the very first web page on the web, which is still available at its original URL—you can see that different types of elements are styled differently.

The links are styled differently than the text around them. The heading is styled differently to the body copy. This definition list has formatting going on. You can see the spacing there. So something is doing some styling.

Well, when we were at this hack week at CERN, we had access to the original source code for this project. We found this file in there.

And this is, I guess, the user agent style sheet. This is the bit that tells the first web browser how to style headings, how to style lists, how to style definitions.

It’s not very readable, but you can tell that, you know, there’s a lot of values here, not many property names, but if you squinted it just right, you can imagine, okay, this is some form of a style sheet.

It became clear though that it wasn’t enough to just allow the user agent to do the styling. Authors—that’s developers and designers—authors also needed a way to provide styling information.

Now for a while there, it looked like the way this was gonna happen was going to be in HTML. People started adding these proprietary elements and attributes to HTML that were all about presentation, all about styling. And that’s not what HTML is for. HTML is about structure, about the semantics, the meaning of a document.

It was really important that there’d be some kind of separation of concerns, that you would use one format—HTML—for your structure, and that there should be a separate format, some other kind of language, for styling.

The question is, what should that other format be?

Well, pretty early on, some proposals started coming in early mailing lists to do with the World Wide Web. Pretty much everyone on the web in the first few months was making their own web browser. It was by nerds for nerds.

Rob Raisch

I think the first proposal for some kind of styling for authors came from Rob Raisch, who was at O’Reilly at the time.

He sent an email to the www-talk mailing list in June of 1993, with this proposal as a way of styling.

@BODY fo(fa=he,si=18)

Now, again, looking at this, it’s not CSS, but if you squint just right, you can sort of make sense of it. It’s kind of like looking at a clock running counterclockwise. It’s not what we’re used to, but you feel like you could parse it.

Clearly the priority here was to do with brevity. We’ve got these two character things like FO for font, FA for face, HE for Helvetica, SI for size. You put that all together and you can say the font face should be Helvetica and the font size should be 18 of whatever unit we’re talking about here.

So, you know, just about able to parse it, there is the concept here of, you know, some kind of selector, right? The way that we say we’re talking about the BODY, we’re talking about the paragraph or talking about B or I.

Pei Wei

The next proposal that came along was by Pei Wei, who was building the Viola web browser. He sent an email to the www-talk mailing list in October of 1993. And he was able to put his entire style sheet in his proposal.

This is what it looks like. Kind of similar to what we saw before. We’ve got the idea of properties and values, but with equal signs rather than colons that we used to now.

But what’s really interesting here is this idea of nesting. We’ve got nesting going on in this proposal which is something that we’re really only just getting in CSS.

Håkon Wium Lie

Now, the next proposal came from Håkon Wium Lie. This was October of 1994 and he called his proposal Cascading HTML Style Sheets. And it looked like this.

h1.font.size = 24pt 100%

And again, you can kind of parse this, right? It’s not what we’re used to, but you squint at it and you can make sense of it. You can see the way that the selector and the properties are kind of scrunched together with this dot syntax. And again, there’s an equal sign rather than a colon, but we get it. It’s like, okay, the font size of an H1 element should be 24 points. Got it.

But wait, what’s this percentage after it, like this 100% or this 40%?

Influence

Well, this is a really interesting part of this proposal. This was this idea of influence. The idea that an author should be able to effectively say how much they care about a particular style being applied.

So if you really want that heading to be that size, you say 100%, I care about this. But if you only half care, you could say 50%.

And the idea was that users would also be providing styles and users would also specify how much they cared, how much influence they wanted to exert exert on the styles.

And then there’s kind of a bit of hand-wavy logic where it’s like, “And then the user agent figures out what the final style should be.”

And that last part it turned out was really hard to do. So this idea of influence somewhat fell by the wayside. But I think it’s very powerful and it definitely matched the ideas of Tim Berners-Lee with his first web browser, this idea that the web should be a read and write medium.

Because that first web browser—WorldWideWeb—wasn’t just a browser. It was also an editor.

The idea was you would open a document from the web, you’re looking at it and you think “I wanna make changes to this document. I’m gonna create my own copy, put it on my server and make the changes.”

Now it turned out that was really hard. And so that was one of the first things that got dropped from the World Wide Web, which is a bit of a shame because I think it is a very, very powerful idea, a very empowering idea.

We somewhat got back this idea of a read/write web with things like wikis and blogs and even social media to a certain extent.

And the idea that users should have influence over the styles of a website? Well, that survived in web browsers for quite a while, with this concept of user style sheets.

This is different to user agent style sheets. This was literally that in your browser, you could specify styles to override what an author has specified.

This got dropped from browsers over time because it turned out to be a real power-user feature. Most people weren’t using this. These days, if you want to apply styles as a user, you have to install a browser extension, some kind of plugin. Or your operating system has some kind of translation of like, “these are my preferences at the operating system level” and those get translated to the browser.

I think it’s a real shame that we lost user style sheets. I thought it was a very empowering feature. I get it. It was, you know, somewhat of an edge case. It was power-user feature, but I think it’s a shame we lost it.

I do see, however, a bit of a resurgence in the idea of giving users control over styling with some of the things we’re seeing in CSS, particularly in the media queries level five, this idea of what are being called preference queries. You can say, you know, prefers a color scheme, like dark mode prefers reduced motion, prefers reduced data.

Now it’s a bit different because it’s still up to the author of the style sheet on that website to honour these preferences, right? You still have to write the styles to do the right thing to respect the colour scheme or reduced motion or reduced data.

Though, you know, some browsers are looking into automatically applying some of this stuff automatically: inverting colors and reducing motion.

And on the whole, I welcome the idea that users should have more of a say in how websites are styled. I think it’s a good thing.

So we’re seeing a bit of a resurgence of this idea of influence in modern CSS.

And speaking of modern CSS being somewhat foreshadowed in Håkon’s original proposal, here’s something else that was in that original proposal…

font.size = 12pt
h1.font.size = font.size * 3
h2.font.size = font.size * 2.5
h3.font.size = font.size * 2

If you look at this, you can kind of figure out what’s going on. That there’s kind of a declaration at the top to say there’s a variable, if you like, that’s 12 points. And then that variable is used throughout the style sheet. It’s multiplied by different numbers.

And really, we’ve got this now in CSS, thanks to custom properties and calc(), right? The ability to set variables and do calculations on those variables. But it took a long time between this original proposal and this very modern CSS that we have today.

Bert Bos

The final proposal I want to mention came from Bert Bos. This was also in 1994 and his proposal looked like this.

I think this is the first time we started to see colons rather than equal signs for properties and values. But again, you can see the way that the selectors and the properties sort of munged together with this dot syntax.

It’s parsable, right? Again, it’s like looking at a clock running counterclockwise, but you can understand what’s going on here.

So Bert’s proposal is interesting. It’s one more proposal. But what I really like about what Bert did was Bert also provided design principles.

In other words, the thinking behind the proposal. Because like I was kind of saying, you know, the standard itself, in some ways, isn’t the important thing. The important thing is the agreement. So let’s all try and agree on what we’re trying to accomplish with some kind of style sheet language. And I will also freely admit I’m just a sucker for design principles.

Design principles

I’m fascinated by design principles. I even collect them. This is like my equivalent of my interesting rock collection. A collection of design principles at principles.adactio.com.

And if you go there, I’ve collected design principles from individuals, from organizations, and I have Bert’s principles there.

And they’re worth reading through, but one of the issues with Bert’s principles is there’s a lot of them. These are all the different things that feed into the design of a style sheet language. And these are all good things, but I think what’s missing here is some kind of prioritization.

Because the hard part about design principles, isn’t saying what you value. The hard part about design principles is saying we value one thing over another.

So let’s take two of these. We see simplicity and longevity. Well, do we value simplicity more than longevity? Do we value longevity more than simplicity? That’s actually the hard part, to specify the priorities.

So I think it’s a bit of a shame that there isn’t prioritization here, but I think it’s still fascinating that we can look at all of the things that Bert was imagining we have to balance in some kind of style sheet language.

Well, it became pretty clear that Bert and Håkon were working on the same sort of thing. And so they pooled their resources together and kids, that’s where CSS comes from. Jointly from Bert and Håkon.

CSS

And what they settled on—with all of those different design principles and all of the ideas from the different proposals that came before—this is what we got:

selector {
  property: value;
}

This one pattern. You’ve got a selector, a property and a value. Then we’ve got these special characters for syntax, right? Curly braces, colons, semicolons, but really it’s somewhat arbitrary. The point is that all of CSS pretty much can be boiled down to this one pattern: selector, property, value.

It’s a very simple pattern. And yet it allows for endless complexity. I mean, this is our shared context on the web for styling. If you think about the number of websites out there, right? Billions. And every one of them has a different style sheet and every one of them is different. And yet all of them use the same pattern at its root.

It’s the classic example of how a simple rule can create a complex system. And I think this might also be at the heart of why CSS can be misunderstood. Because this pattern is very simple and because it’s very simple, people might think well, CSS is therefore easy.

But there’s a difference between simplicity and easiness.

Like, you can learn the idea of CSS in an hour, right? Because effectively this pattern is it. You need to get your head around selector, property, value.

But you can then spend a lifetime trying to master CSS because of all the possible combinations of selectors and properties and values, right? It’s a lifetime of learning.

So this is where I think some of the disconnect comes with people thinking, “Oh yeah, I’ll pick up CSS. No problem. It’s easy.” And actually, no. It’s simple, but it’s not easy.

And CSS has grown over time, right? We keep getting more selectors, we keep getting more properties and we keep getting more values. It grows and grows while still maintaining this fundamental pattern.

Hacks

And if we look at where the growth of CSS has come from, you know, a lot of the time it came from hacks. And I don’t mean literal CSS hacks, like the box model hack or tan hack for any anybody old enough to remember that.

I mean hacks in a sense of its original use of a clever solution to a problem, but probably not a great long term solution.

Layout

So the classic example of hacks on the web would’ve been layout. You know, in the early days we were using tables for layout. We had transparent gifs, one pixel by one pixel gifs that we would give width and height to allow us to make all the layouts we wanted. And it worked, but it was a hack.

So then we got CSS and we switched to using floats for layout, which was better. But, you know, it was still a hack because floats weren’t intended for layout. They were intended for, you know, having text flow around images.

And it’s only relatively recently in the history of the web that we finally are able to throw away our hacks and use proper layout tools.

Because now we’ve got flexbox and we’ve got grid and these are made for layout. It took quite a while for us to get there.

But you know, in the early days of the web, it wasn’t even clear if CSS should attempt to do layout or whether there should be a third format specifically for layout. Because maybe there needed to be that separation of concerns between structure (you’ve got HTML), styling (you’ve got CSS), and some third technology for layout which could be considered like its own its own thing.

I mean, if you think about it today, we kind of sequester layout into media queries. So you could imagine that being a separate technology.

But anyway, it became clear over time that CSS should be the home for layout as well as other kinds of styling.

And that’s what we’ve got now. We’ve got flexbox. We’ve got grid. We got proper layout on the web so we were able to stop using our hacks and use the real native tools.

Typography

It’s a similar story with typography.

If you wanted to use a font that wasn’t one of the system fonts that most people would have installed, well, you went into Photoshop and you made an image of text using the font you wanted, and now the user would have to download that image file and the text wasn’t selectable, it was a fixed width, it came with all sorts of problems. And we came up with very clever solutions to do what’s called image replacement in CSS, but they were all hacks.

And now we don’t need the hacks because we’ve got the @font-face rule. So we can literally specify the typeface we want to use. We can stop using the hacks.

Graphic design

We used a lot of hacks for graphic design as well. Things that we weren’t quite able to do natively in CSS.

I’m gonna air my laundry here and show you a website I made back in 2005. This was the website for my first book called DOM Scripting and it’s very much of its time.

This is the very 2005-feeling design. You see the way we’ve got that element there with rounded corners? And you see the way that there’s a gradient in the background of the page? Well, back in 2005, we didn’t have rounded corners in CSS and we didn’t have gradients.

So those rounded corners? Those are images that have been absolutely positioned into that element.

And that gradient is actually an image. It’s a one pixel wide, but very, very tall image that is tiled across the entire background.

So these were hacks and they worked, but obviously I wouldn’t need to do that today. Today, I’ve got border-radius to do my rounded corners and I got linear-gradient to do my gradients.

Ironically, right as we got the power to do rounded corners and gradients in CSS natively, we all collectively decided that, nah, actually what we want is flat design …which we could have been doing all along!

Anyway, let me show you another example. This is a website that dates back even further. This is my own personal website, adactio.com.

This design hasn’t really changed in over 20 years, but I have updated the technology.

Let’s the take image at the top. You can see that’s been given some treatment as a corner has been sliced out of one edge and a gradient has been applied so it fades out.

Now it used to be that I would have to do that in Photoshop. I’d take the original image, I’d slice off the corner, I’d add a gradient layer on top of it.

Well now I don’t need Photoshop because I can use clip-path to take off the corner. I can use a linear gradient using generated content—using the ::after pseudo element—to get the exact same result.

So now I’ve got something that looks pretty much the same, except where I had to do it in Photoshop before, now I’m able to do it natively in CSS.

And that might not sound like much of a win because the end result looks the same, right?

Except now when I’m applying a prefers-color-scheme style sheet and I give a dark mode to my site, I don’t have to make a separate image. Because this is being done natively in CSS. The gradient is in CSS. The clip path is in CSS. It’s all native to CSS.

Material honesty

This comes down to this idea of material honesty. About using the right material for the job, rather than using a material that’s pretending to be something else, whether that’s, you know, an image of text, pretending to be a font or an image of a gradient, pretending to be a real gradient or, you know, any of those graphic design tricks.

We can now be materially honest in CSS because we’ve got grid and flexbox and border-radius and @font-face. It’s more honest.

And also it’s easier, right? It’s less work to avoid the hacks.

Like, one of my favorite examples of something we got recently in CSS to avoid the hacks. It’s a small thing, but it makes a big difference in my opinion, is just styling things like check boxes and radio buttons.

We’ve always been able to do it, but it involved a hack where you’d hide the real checkbox off screen. And then you’d use a background image to show the different states of the checkbox. And it was fine and it worked and we could make it accessible.

But now we can just use accent-color and it’s easier.

So there’s been this movement from hacks to native CSS. And in a way, the hacks show the direction of travel. The hacks show us what the future could be.

Tools

The other place CSS has borrowed from or learned from, has been in our tools. Like the tools we use to generate our CSS.

Sass is the classic example, right? Sass is this enormously popular pre-processor for CSS and people were using Sass to do things you couldn’t do natively in CSS.

And I feel like one of the genius bits of design in Sass was that it worked a lot like the way HTML worked in the early days compared to SGML.

Remember, I was talking about how Tim Berners-Lee took SGML and literally turned it into HTML? Like, you were able to take an SGML document and change the file extension, and it would be a valid HTML document. And so that really helped with the adoption of HTML.

Well, that’s the same with Sass. You could take your existing style sheet document and just changed the file extension to .scss and it was already valid Sass, right? You didn’t have to learn a new syntax.

This isn’t supposition on my part—that this was a reason for the huge success of Sass—because actually Sass had two options, two different syntaxes, and you could choose.

There was this .sass syntax and the .scss syntax.

And with the .sass syntax, it used significant white space. It was more condensed, right? It used indentation.

But with .scss it used the syntax you were already familiar with from CSS.

So you could say that the .sass syntax was more efficient. You could say it’s a better format, but humans are allergic to change. And the .scss syntax was familiar enough that people go, “oh yeah, I get this.”

You could, you could take your existing CSS and just start using the features of Sass you wanted to.

And people overwhelmingly chose the .scss syntax over the .sass syntax. I got to meet Hampton Catlin who invented Sass and he confirmed the numbers for me. He said, yeah, it was a no brainer. Basically the .sass syntax lacks familiarity. It’s like looking at a clock running counter-clockwise.

But anyway, people started using Sass to do things like nesting, calculations (these mix-ins), variables; all these things that we now do in CSS.

Of course, the reason we can do these things in CSS is because Sass proved that there was a desire for these things.

So now you really don’t need Sass for a lot of stuff, but the reason you don’t need Sass is because of Sass. Sass paved the way. Sass showed that there was a demand for this stuff. And now it’s native in the CSS. We don’t need that tool anymore.

And I feel like that’s a test of a really good tool. A really successful tool is when it becomes redundant.

In the JavaScript world, jQuery is a classic example of this, right?

With jQuery you were able to do things using a CSS syntax, whereas otherwise you had to use this long winded DOM syntax of document.getElementsByTagName or getElementById.

Whereas in jQuerythe idea was, “Hey, if you already know how to select something in CSS, just use that syntax again!”

It’s using what people are familiar with. Humans are allergic to change.

But these days we don’t need jQuery because in the DOM, we’ve got querySelectorAll, we’ve got querySelector. We can use CSS selectors to do our DOM scripting.

Why don’t we need jQuery anymore? Because of jQuery.

jQuery showed that this was a really clever idea. It was something people wanted. And so now it’s been standardized. We don’t need jQuery.

So I really feel like the goal of any good library should be to make itself obsolete. It’s so successful, it’s no longer needed.

And you could kind of see this in the history of the web with Sass, with jQuery, even with something like Flash.

You know, Flash showed the way. It showed that, “Hey, we want a way to do animation. We need some way to do video on the web.” And people were using Flash because there was no other way to do those things.

Now we don’t need Flash or jQuery or Sass because we get them natively.

So all of these are almost like research and development for the web.

They’re kind of like hacks, but I think a better way of thinking about them is they’re more like polyfills—these are things we can use until we get a standardized way of doing it.

I think it’s fascinating to look at our tools and see what can they tell us about what’s coming into standards.

Methodologies

A whole set of tools are these methodologies that people came up with, like OOCSS from Nicole Sullivan. And there’s BEM. And SMACSS was another one. There’s a whole bunch.

But I’m fascinated by these because these aren’t an example of some technology we needed to lobby browser makers to implement. Because these are really agreements.

These are agreements. These are saying, “let’s all agree to structure our CSS in a certain way.” Nothing needed to change in browsers, right?

And all of these are testament to the power of the cascade. Because what they do is they almost deliberately limit the cascade, which is seen as almost being too powerful.

So they’re not really tools, they’re methodologies. Or another way of putting it is they are agreements.

Again, the power of saying “let’s all agree to do something.”

Scale

And the problem that most of them are trying to solve is trying to do CSS at scale, trying to do CSS when you’ve got a large team. Which is interesting to think about like, why wasn’t CSS designed to scale well like this?

Miriam Suzanne said:

Large companies find HTML and CSS frustrating “at scale” because the web is fundamentally an anticapitalist mashup art experiment designed to give consumers all the power.

Okay, it’s funny, but it’s kind of funny ’cause it’s true. If you look at those design principles that Bert Bos came up with, it was very much about empowering the end user, that CSS needed to be accessible. It needed to be something you could learn quickly.

So, you know, thinking about CSS as something that needs to be able to scale to multiple teams of people? That wasn’t really on the cards for CSS back then. It wasn’t a priority.

And maybe that’s why we came up with these methodologies like BEM and OOCSS and SMACSS to try and manage this stuff.

But even these methodologies, now the ideas behind them are finding their way into the standards. Now we’re getting cascade layers and scope in CSS.

To me, this feels like a return of this idea of influence that Håkon Wium Lie was talking about all those years ago.

Now it’s not so much about the influence between an author and a user; it’s about the influence between multiple authors working on, on a giant code base.

So it’s a very exciting time for CSS to see these new tools arrive that can solve these scale problems.

But I do ask myself, what’s still missing in CSS? And this is a great question to ask of JavaScript as well:

What’s still missing?

And you can answer the question by looking at what are we still using tools for? What are we still having to polyfil because we don’t yet have it natively in the browser?

And to answer this question, I’m gonna just quickly finish with three components that kind of demonstrate where CSS is still missing some features.

button

Let’s start with a button component.

All right. If you wanna implement a button component, you’ve kind of got two options. You can use a button element and then you style it with CSS to look however you want. Or you can, you know, make up your own button component using a div or a span, add the CSS and JavaScript and ARIA.

Really there’s absolutely no reason to do that. In this case, it’s a no brainer. You use a button element and you style it with CSS. I cannot think of any reason why you would not do that. There used to be reasons like ages ago in Internet Explorer it used to be hard to style buttons. Those days are long gone.

So in this case, really simple answer to the question. Material honesty. Use a button element. Use CSS to style it.

dropdown

All right. What about a dropdown component? There’s a number of options, you click in and you get a select dropdown.

Well, again, you can use a select element style with CSS, or you can just make your own dropdown component with a div and JavaScript and a bunch of ARIA to try and make it accessible.

Now here, I would still say, use a select element and style it with CSS, but you are gonna hit a limit. Like the open state of the dropdown is kind of out of our control. There’s not much you can do in CSS. So if you really care about styling the open state of a dropdown, I guess I can understand why you would reach for making your own with a div and JavaScript and ARIA.

I mean, I personally wouldn’t do it. But I guess I can see it, because CSS isn’t there yet. We don’t yet have the power to style a dropdown.

date picker

What about a date picker component? You click into it, the user chooses a date.

Again, there appears to be an obvious solution here, which is use input type="date". Boom. You’re done style it how you want, right?

Well, good luck with that. If you’ve ever try to style input type="date", there’s actually very little you can do. And so if you care about the styling of the date selector, you probably are gonna have to make up your own with a bunch of divs and JavaScript and try to make it accessible with ARIA.

Yeah, it’s a real shame.

So I think these three components kind of show the battle ground, if you will, where CSS is still falling short a bit, where we have to still use hacks. It’s kind of this battle between the under-engineered solution—just use the native HTML element—and the over-engineered solution, right? We’re gonna have to create all the functionality and all the accessibility by ourselves.

And I used to get mad at people choosing the hacks, choosing the over-engineered solution. But I realized that it’s kind of like, you know, trying to reduce teen pregnancy by telling people to just stop having sex. Abstinence isn’t realistic. People are going to do it anyway. And the question is, well, how do we make it better and safer in the long run?

So I think that’s the real battleground, is how do we style elements like select and date pickers natively in CSS? And that’s why I think the work being done by the open UI group is really, really important.

It’s at open-ui.org.

And they say:

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

I think it’s really important work. And I think that’s where we should be putting our effort.

The future

Because, you know, the difference between doing something natively in a web browser and doing something with a framework or with JavaScript is context.

Web browsers are the shared context between users and authors.

Whereas, if you want to use a framework or a library, you have to ship that context to the end user. And that puts a burden on them. It’s not good for performance. It’s not good for the user experience.

So web browsers are where past agreements live on today and they live on into the future.

When something lands in a browser, it stays in a browser. So by using what’s in web browsers, you are benefiting from decades of work by multitudes of people. And it’s better for users.

So treat frameworks and libraries as polyfils. Use them as a temporary measure when there’s something that’s still not possible in browsers (this is very true of JavaScript frameworks).

They can point the way to a shared context in the future, but they themselves are not the future. So don’t get too attached. Treat them as cattle, not pets.

Use frameworks and libraries as scaffolding to help you build. But they are not a foundation.

Web standards in the browser are your foundation to build upon.

You know, having an awareness of the history of technologies from sun dials to web browsers, it can help you understand the way things are today. And in some ways the lessons of path dependence and inertia are sort of grim, right? Because of some arbitrary decision in the past, we are now stuck with the consequences in our clockfaces, in CSS. And it’s very, very hard to change that.

But there’s another way to look at this.

Nothing was inevitable. Which means nothing is inevitable (you know, except for entropy and the heat death of the universe).

So if someone tells you, “Hey, that’s just the way things are; accept it”, don’t believe it.

Understand your position in the timeline.

Yes, the present moment is the result of decisions made in the past, many of them arbitrary, but that also means the future will be highly influenced by the decisions you make today even if those decisions seem small and inconsequential.

The choices you make now could turn out to have long-lasting repercussions into the future.

So make your decisions wisely. You are literally creating the future.

And I’m looking forward to seeing the results.

Thank you.

Sunday, June 19th, 2022

Backup

I’m standing on a huge stage in a giant hangar-like room already filled with at least a thousand people. More are arriving. I’m due to start speaking in a few minutes. But there’s a problem with my laptop. It connects to the external screen, then disconnects, then connects, then disconnects. The technicians are on the stage with me, quickly swapping out adaptors and cables as they try to figure out a fix.

This is a pretty standard stress dream for me. Except this wasn’t a dream. This was happening for real at the giant We Are Developers World Congress in Berlin last week.

In the run-up to the event, the organisers had sent out emails about providing my slide deck ahead of time so it could go on a shared machine. I understand why this makes life easier for the people running the event, but it can be a red flag for speakers. It’s never quite the same as presenting from your own laptop with its familiar layout of the presentation display in Keynote.

Fortunately the organisers also said that I could present from my own laptop if I wanted to so that’s what I opted for.

One week before the talk in Berlin I was in Amsterdam for CSS Day. During a break between talks I was catching up with Michelle. We ended up swapping conference horror stories around technical issues (prompted by some of our fellow speakers having issues with Keynote on the brand new M1 laptops).

Michelle told me about a situation where she was supposed to be presenting from her own laptop, but because of last-minute technical issues, all the talks were being transferred to a single computer via USB sticks.

“But the fonts!” I said. “Yes”, Michelle responded. Even though she had put the fonts on the USB stick, things got muddled in the rush. If you open the Keynote file before installing the fonts, Keynote will perform font substitution and then it’s too late. This is exactly what happened with Michelle’s code examples, messing them up.

“You know”, I said, “I was thinking about having a back-up version of my talks that’s made entirely out of images—export every slide as an image, then make a new deck by importing all those images.”

“I’ve done that”, said Michelle. “But there isn’t a quick way to do it.”

I was still thinking about our conversation when I was on the Eurostar train back to England. I had plenty of time to kill with spotty internet connectivity. And that huge Berlin event was less than a week away.

I opened up the Keynote file of the Berlin presentation. I selected File, Export to, Images.

Then I created a new blank deck ready for the painstaking work that Michelle had warned me about. I figured I’d have to drag in each image individually. The presentation had 89 slides.

But I thought it was worth trying a shortcut first. I selected all of the images in Finder. Then I dragged them over to the far left column in Keynote, the one that shows the thumbnails of all the slides.

It worked!

Each image was now its own slide. I selected all 89 slides and applied my standard transition: a one second dissolve.

That was pretty much it. I now had a version of my talk that had no fonts whatsoever.

If you’re going to try this, it works best if don’t have too many transitions within slides. Like, let’s say you’ve got three words that you introduce—by clicking—one by one. You could have one slide with all three words, each one with its own build effect. But the other option is to have three slides: each one like the previous slide but with one more word added. If you use that second technique, then the exporting and importing will work smoothly.

Oh, and if you have lots and lots of notes, you’ll have to manually copy them over. My notes tend to be fairly minimal—a few prompts and the occasional time check (notes that say “5 minutes” or “10 minutes” so I can guage how my pacing is going).

Back to that stage in Berlin. The clock is ticking. My laptop is misbehaving.

One of the other speakers who will be on later in the day was hoping to test his laptop too. It’s Håkon. His presentation includes in-browser demos that won’t work on a shared machine. But he doesn’t get a chance to test his laptop just yet—my little emergency has taken precedent.

“Luckily”, I tell him, “I’ve got a backup of my presentation that’s just images to avoid any font issues.” He points out the irony: we spent years battling against the practice of text-as-images on the web and now here we are using that technique once again.

My laptop continues to misbehave. It connects, it disconnects, connects, disconnects. We’re going to have to run the presentation from the house machine. I’m handed a USB stick. I put my images-only version of the talk on there. I’m handed a clicker (I can’t use my own clicker with the house machine). I’m quickly ushered backstage while the MC announces my talk, a few minutes behind schedule.

It works. It feels a little strange not being able to look at my own laptop, but the on-stage monitors have the presentation display including my notes. The unfamiliar clicker feels awkward but hopefully nobody notices. I deliver my talk and it seems to go over well.

I think I’ll be making image-only versions of all my talks from now on. Hopefully I won’t ever need them, but just knowing that the backup is there is reassuring.

Mind you, if you’re the kind of person who likes to fiddle with your slides right up until the moment of presenting, then this technique won’t be very useful for you. But for me, not being able to fiddle with my slides after a certain point is a feature, not a bug.

Friday, June 17th, 2022

Jeremy Keith | In And Out Of Style | CSS Day 2022 - YouTube

Here’s the video of my opening talk at this year’s CSS Day, which I thoroughly enjoyed!

It’s an exciting time for CSS! It feels like new features are being added every day. And yet, through it all, CSS has managed to remain an accessible language for anyone making websites. Is this an inevitable part of the design of CSS? Or has CSS been formed by chance? Let’s take a look at the history—and some alternative histories—of the World Wide Web to better understand where we are today. And then, let’s cast our gaze to the future!

Jeremy Keith | In And Out Of Style | CSS Day 2022

Tuesday, May 24th, 2022

The complete line-up for UX London

The line-up for UX London is now complete!

Two thematically-linked talks have been added to day one. Emma Parnell will be talking about the work she did with NHS Digital on the booking service for Covid-19 vaccinations. Videha Sharma—an NHS surgeon!—will be talking about co-designing and prototyping in healthcare.

There’s a bunch of new additions to day three. Amir Ansari will be talking about design systems in an enterprise setting and there’ll be two different workshops on design systems from John Bevan and Julia Belling.

But don’t worry; if design systems aren’t your jam, you’ve got options. Also on day three, Alastair Somerville will be getting tactile in his workshop on sensory UX. And Trenton Moss will be sharing his mind-control tricks in his workshop, “How to sell in your work to anyone.”

You can peruse the full schedule at your leisure. But don’t wait too long before getting your tickets. Standard pricing ends in ten days on Friday, June 3rd.

And don’t forget, you get quite a discount when you buy five or more tickets at a time so bring the whole team. UX London should be your off-site.

Wednesday, May 18th, 2022

UX London should be your off-site

Check out the line up for this year’s UX London. I know I’m biased, but damn! That’s objectively an excellent roster of smart, interesting people.

When I was first putting that page together I had the name of each speaker followed by their job title and company. But when I stopped and thought about it—not to be too blunt—I realised “who cares?”. What matters is what they’ll be talking about.

And, wow, what they’ll be talking about sounds great! Designing for your international audiences, designing with the autistic community, how to win stakeholders and influence processes, the importance of clear writing in product development, designing good services, design systems for humans, and more. Not to mention workshops like designing your own research methods for a very diverse audience, writing for people who hate writing, and harnessing design systems.

You can peruse the schedule—which is almost complete now—to get a feel for how each day will flow.

But I’m not just excited about this year’s UX London because of the great talks and workshops. I’m also really, really excited at the prospect of gathering together—in person!—over the course of three days with my peers. That means meeting new and interesting people, but frankly, it’s going to be just as wonderful to hang out with my co-workers.

Clearleft has been a remote-only company for the past two years. We’ve still got our studio and people can go there if they like (but no pressure). It’s all gone better than I thought it would given how much of an in-person culture we had before the pandemic hit. But it does mean that it’s rare for us all to be together in the same place (if you don’t count Zoom as a place).

UX London is going to be like our off-site. Everyone from Clearleft is going to be there, regardless of whether “UX” or “design” appears in their job title. I know that the talks will resonate regardless. When I was putting the line-up together I made sure that all the talks would have general appeal, regardless of whether you were a researcher, a content designer, a product designer, a product manager, or anything else.

I’m guessing that the last two years have been, shall we say, interesting at your workplace too. And even if you’ve also been adapting well to remote work, I think you’ll agree that the value of having off-site gatherings has increased tenfold.

So do what we’re doing. Make UX London your off-site gathering. It’ll be a terrific three-day gathering in the sunshine in London from Tuesday, June 28th to Thursday, June 30th at the bright and airy Tobacco Dock.

If you need to convince your boss, I’ve supplied a list of reasons to attend. But you should get your tickets soon—standard pricing ends in just over two weeks on Friday, June 3rd. After that there’ll only be last-chance tickets available.

Thursday, April 28th, 2022

How to Imagine Climate Futures - Long Now

The best climate fiction can do more than spur us to action to save the world we have — it can help us conceptualize the worlds, both beautiful and dire, that may lie ahead. These stories can be maps to the future, tools for understanding the complex systems that intertwine with the changing climates to come.

Monday, April 25th, 2022

TEDxBrighton 2022

I went to TEDxBrighton on Friday. I didn’t actually realise it was happening until just a couple of days beforehand, but I once I knew, I figured I should take advantage of it being right here in my own town.

All in all, it was a terrific day. The MCing by Adam Pearson was great—just the right mix of enthusiasm and tongue-in-cheek humour. The curation of the line-up worked well too. The day was broken up into four loosely-themed sections. As I’m currently in the process of curating an event myself, I can appreciate how challenging it is.

Each section opened with a musical act. Again, having been involved behind the scenes with many events myself, I was impressed by the audaciousness, just from a logistical perspective. It all went relatively smoothly.

The talks at a TED or TEDx event can be a mixed bag. You can have a scientist on stage distilling years of research into a succint message followed by someone talking nonsense about some pseudo-psychological self-help scheme. But at TEDxBrighton, we lucked out.

A highlight for me was Dr James Mannion talking about implementation science—something that felt directly applicable to design work. Victoria Jenkins was also terrific, and again, her points about inclusive design felt very relevant. And of course I really enjoyed the space-based talks by Melissa Thorpe and Bianca Cefalo. Now that I think about it, just about everyone was great: Katie Vincent, Lewis Wedlock, Dina Nayeri—they all wowed me.

With one exception. There was a talk that was supposed to be about the future of democracy. In reality it quickly veered into DAOs before descending into a pitch for crypto and NFTs. The call to action was literally for everyone in the audience to go out and get a crypto wallet and buy an NFT …using ethereum no less! We were exhorted to use an unbelievably wasteful and energy-intensive proof-of-work technology to get our hands on a receipt for a JPG …from the same stage that would later highlight the work of climate activists like Tommie Eaton. It was really quite disgusting. The fear-based message of the talk was literally about getting in on the scheme before it’s too late. At one point we were told to “do the research.” I’m surprised we weren’t all told that we’re “not going to make it.”

A disgraceful shill for a ponzi scheme would’ve ruined any other event. Fortunately the line-up at TEDxBrighton was so strong that one scam artist couldn’t torpedo the day. Just like crypto itself—and associated bollocks like NFTs and web3—it was infuriating to have to sit through it in the short term, but then it just faded away into insignificance. One desperate peddler of snake oil couldn’t make a dent in an otherwise great day.

Tuesday, April 12th, 2022

Starting and finishing

Someone was asking recently about advice for public speaking. This was specifically for in-person events now that we’re returning to actual live conferences.

Everyone’s speaking style is different so there’s no universal advice. That said, just about everyone recommends practicing. Practice your talk. Then practice it again and again.

That’s good advice but it’s also quite time-consuming. Something I’ve recommended in the past is to really concentrate on the start and the end of the talk.

You should be able to deliver the first five minutes of your talk in your sleep. If something is going to throw you, it’s likely to happen at the beginning of your talk. Whether it’s a technical hitch or just the weirdness and nerves of standing on stage, you want to be able to cruise through that part of the talk on auto-pilot. After five minutes or so, your nerves will have calmed and any audio or visual oddities should be sorted.

Likewise you want to really nail the last few minutes of your talk. Have a good strong ending that you can deliver convincingly.

Make it very clear when you’re done—usually through a decisive “thank you!”—to let the audience know that they may now burst into rapturous applause. Beware the false ending. “Thank you …and this is my Twitter handle. I always like hearing from people. So. Yeah.” Remember, the audience is on your side and they want to show their appreciation for your talk but you have to let them know without any doubt when the talk is done.

At band practice we sometimes joke “Hey, as long as we all start together and finish together, that’s what matters.” It’s funny because there’s a kernel of truth to it. If you start a song with a great intro and you finish the song with a tight rock’n’roll ending, nobody’s going to remember if somebody flubbed a note halfway through.

So, yes, practice your talk. But really practice the start and the end of your talk.

Tuesday, November 30th, 2021

Speakers | State of the Browser 2021

All the talks from this year’s State Of The Browser event are online, and they’re all worth watching.

I laughed out loud at multiple points during Heydon’s talk.

Friday, November 5th, 2021

Memories of Ajax

I just finished watching The Billion Dollar Code, a German language miniseries on Netflix. It’s no Halt and Catch Fire, but it combines ’90s nostalgia, early web tech, and an opportunity for me to exercise my German comprehension.

It’s based on a true story, but with amalgamated characters. The plot, which centres around the preparation for a court case, inevitably invites comparison to The Social Network, although this time the viewpoint is from that of the underdogs trying to take on the incumbent. The incumbent is Google. The underdogs are ART+COM, artist-hackers who created the technology later used by Google Earth.

Early on, one of the characters says something about creating a one-to-one model of the whole world. That phrase struck me as familiar…

I remember being at the inaugural Future Of Web Apps conference in London back in 2006. Discussing the talks with friends afterwards, we all got a kick out of the speaker from Google, who happened to be German. His content and delivery was like a wonderfully Stranglovesque mad scientist. I’m sure I remember him saying something like “vee made a vun-to-vun model of the vurld.”

His name was Steffen Meschkat. I liveblogged the talk at the time. Turns out he was indeed on the team at ART+COM when they created Terravision, the technology later appropriated by Google (he ended up working at Google, which doesn’t make for as exciting a story as the TV show).

His 2006 talk was all about Ajax, something he was very familiar with, being on the Google Maps team. The Internet Archive even has a copy of the original audio!

It’s easy to forget now just how much hype there was around Ajax back then. It prompted me to write a book about combining Ajax and progressive enhancement.

These days, no one talks about Ajax. But that’s not because the technology went away. Quite the opposite. The technology became so ubiquituous that it no longer even needs a label.

A web developer today might ask “what’s Ajax?” in the same way that a fish might ask “what’s water?”

Wednesday, November 3rd, 2021

Publishing The State Of The Web

Back in April I gave a talk at An Event Apart Spring Summit. The talk was called The State Of The Web, and I’ve published the transcript. I’ve also published the video.

I put a lot of work into this talk and I think it paid off. I wrote about preparing the talk. I also wrote about recording it. I also published links related to the talk. It was an intense process, but a rewarding one.

I almost called the talk The Overview Effect. My main goal with the talk was to instil a sense of perspective. Hence the references to the famous Earthrise photograph.

On the one hand, I wanted the audience to grasp just how far the web has come. So the first half of the talk is a bit of a trip down memory lane, with a constant return to just how much we can accomplish in browsers today. It’s all very positive and upbeat.

Then I twist the knife. Having shown just how far we’ve progressed technically, I switch gears the moment I say:

The biggest challenges facing the World Wide Web today are not technical challenges.

Then I dive into those challenges, as I see them. It turns out that technical challenges would be preferable to the seemingly intractable problems of today’s web.

I almost wish I could’ve flipped the order: talk about the negative stuff first but then finish with the positive. I worry that the talk could be a bit of a downer. Still, I tried to finish on an optimistic note.

I won’t spoil it any more for you. Watch the video or have a read of The State Of The Web.

Tuesday, November 2nd, 2021

The State Of The Web on Vimeo

Here’s the video of my latest conference talk—I really like how it turned out.

The World Wide Web has come a long way in its three decades of existence. There’s so much we can do now with HTML, CSS, and JavaScript: animation, layout, powerful APIs… we can even make websites that work offline! And yet the web isn’t exactly looking rosy right now. The problems we face aren’t technical in nature. We’re facing a crisis of expectations: we’ve convinced people that the web is slow, buggy, and inaccessible. But it doesn’t have to be this way. There is no fate but what we make. In this perspective-setting talk, we’ll go on a journey to the past, present, and future of web design and development. You’ll laugh, you’ll cry, and by the end, you’ll be ready to make the web better.

I’ve also published a transcript.

The State Of The Web

The opening presentation from An Event Apart Spring Summit held online in April 2021.

Hello, my friends. I’d like us to try to collectively achieve something today. What I’d like us to achieve is a sense of perspective.

To do this we need to take a step back and cast an eye on the past.

For example, I can look back and say “Wow, what a terrible year!”

A year of death. A year of polarisation. Of inequality. A corrupt government. Protests in the street as people struggled to fight against systemic racism.

Yes, I am of course talking about the year 1968.

The past

By the end of 1968, the United States of America was a nation in turmoil. Civil rights. The war in Vietnam. It felt like the polarising issues of the day were splitting the country in two.

But in the final week of the year, something happened that offered a sense of perspective.

In an audacious move, NASA decided to bring forward the schedule of its Apollo programme. Apollo 7 was a success but that mission was confined to Earth orbit. For Apollo 8, human beings would leave Earth’s orbit for the first time in history. The bold plan was to fly to and around the moon before returning safely to Earth.

From today’s perspective, you might just see it as a dry run for Apollo 11 when human beings would step foot on the moon. But at the time, it was an unbelievably bold move. A literal moonshot.

On the winter solstice, December 21st 1968, Jim Lovell, Frank Borman, and Bill Anders were launched on their six day mission to the moon and back.

The mission was a success. Everything went according to plan. But the reason why we remember the Apollo 8 mission today is for something that wasn’t planned.

First of all, after the translunar injection when the crew had left Earth orbit and were on their way to the moon (already the furthest distance ever travelled by our species), someone—probably Bill Anders—pointed a camera back at Earth.

This was the first picture ever taken by a human being of the whole earth. It’s quite a perspective-setting sight, seeing the whole Earth. To us today, it’s almost commonplace. But remember that were was a time when no one had ever seen this view.

In fact, throughout the 1960s activist Stewart Brand had a campaign, handing out buttons with the question, “Why haven’t we seen a photograph of the whole Earth yet?”

I like the “yet” at the end of that. It gives it a conspiracy-tinged edge.

Stewart Brand suspected that if people could see their home planet in one image, it could reset their perspectives. They would truly grok the idea of Spaceship Earth, as Buckminster Fuller would say. The idea came to Brand when he was on a rooftop, tripping on acid, experiencing the horizon curve away from him and giving him quite a sense of perspective.

Later, he would start the Whole Earth Catalog. It was like a print version of Wikipedia, with everything you needed to know to run a commune.

Later still, he went on to found the Long Now Foundation, an organisation dedicated to long-term thinking. I’m a proud member.

Their most famous project is the clock of the long now, which will keep time for 10,000 years. This is just a scale model in the Science Museum in London. The full-size clock is being built inside a mountain on geologically stable ground. Just thinking about the engineering challenges involved is bound to give you a certain sense of perspective.

But let’s snap back from 10,000 in the future to that Apollo 8 mission in December of 1968.

This picture of the whole earth wasn’t the most important picture taken by Bill Anders on that flight. By Christmas Eve, the crew had reached the moon and successfully entered lunar orbit.

Oh my God! Look at that picture over there! There’s the Earth coming up. Wow, that’s pretty.

Hey, don’t take that, it’s not scheduled.

You got a color film, Jim? Hand me that roll of color quick, would you…

Oh man, that’s…

Quick! Quick!

This is what Bill Anders captured.

Earthrise.

I could try to describe it. But they should’ve sent a poet.

Fifty years later, this poet puts it beautifully. This is Amanda Gorman’s poem Earthrise.

On Christmas Eve, 1968, astronaut Bill Anders

Snapped a photo of the earth

As Apollo 8 orbited the moon.

Those three guys

Were surprised

To see from their eyes

Our planet looked like an earthrise

A blue orb hovering over the moon’s gray horizon,

with deep oceans and silver skies.
It was our world’s first glance at itself

Our first chance to see a shared reality,

A declared stance and a commonality;
A glimpse into our planet’s mirror,

And as threats drew nearer,

Our own urgency became clearer,

As we realize that we hold nothing dearer

than this floating body we all call home.

Astronauts have been known to experience something called the overview effect. It’s a profound change in perspective that comes from seeing the totality of our home planet in all its beauty and fragility.

The Earthrise photograph gave the world a taste of the overview effect, right at a time when it was most needed.

The World Wide Web

I wonder if it’s possible to get an overview effect for the World Wide Web?

There is no photograph of the whole web. We can’t see the web. We can’t travel into space and look back at our online home.

But we can travel back in time. Let’s travel back to 1945.

That was the year that an article was published in The Atlantic Monthly by Vannevar Bush. He was a pop scientist of his day, like Neil de Grasse Tyson or Bill Nye.

The article was called As We May Think. In the article, Bush describes a hypothetical device called a memex.

Imagine a desk filled with reams and reams of microfilm. The operator of this device can find information and also make connections between bits of information, linking them together in whatever way makes sense to them.

This sounds a lot like hypertext. That word would be coined decades later by Ted Nelson to describe “text which is not constrained to be linear.”

Vannevar Bush’s idea of the memex and Ted Nelson’s ideas about hypertext would be a big influence on Tim Berners-Lee, the creator of the World Wide Web.

But his big breakthrough wasn’t just making hypertext into a reality. Other people had already done that.

Douglas Engelbart, who wanted to make the computer equivalent of the memex, had already demonstrated a working hypertext system in 1968 in an astonishing demonstration that came to be known as The Mother Of All Demos.

The idea of hypertext was kind of like a choose-your-own-adventure book. Individual pieces of text in a book are connected with unique identifiers and you can jump from one piece of text to another within the same book.

But what if you could jump between books? That’s the other piece of the puzzle.

The idea of connecting computers together came from the concept of “time sharing” allowing you to remotely access another computer.

With funding from the US Department of Defence’s Advance Research Projects Agency, time sharing was taken to the next level with the creation of a computer network called the ARPANET.

It grew. And it grew. Until it was no longer just a network of computers. It was a network of networks. Or internetwork. Internet, for short.

Tim Berners-Lee took the infrastructure of the internet and mashed it up with the idea of hypertext. Instead of imagining hypertext as a book with interconnected concepts, he imaged a library of books where you could jump from one idea in one book to another idea in a completely different book in a completely different part of the library.

This was the World Wide Web. And Tim Berners-Lee called it the World Wide Web even when it only existed on his computer. You have to admire the chutspah of that!

But the really incredible thing is that it worked! In March of 1989 he proposed a global hypertext system, where anybody could create new pages without asking anyone for permission, and anyone could access those pages no matter what kind of device or operating system they were using.

And that’s what we have today. While the World Wide Web might seem inevitable in hindsight, it was anything but. It is a remarkable achievement.

The World Wide Web was somewhat lacking in colour originally. When I started making websites in the mid nineties, colour had arrived but it was limited.

Colour

When I started making websites in the mid nineties, colour had arrived but it was somewhat limited.

We had a palette of 216 web safe colours. You knew if a colour was “web safe” if the hexadecimal notation was three sets of duplicated values. If you altered one of those values even slightly, there was no guarantee that the colour would display consistently on the monitors of the time.

I have a confession to make: I kind of liked this constraint in a weird way. To this day, if I have a colour value that’s almost web-safe, I can’t resist nudging it slightly.

Fortunately, monitors improved. They got flatter for one thing. They were also capable of displaying plenty of colours.

And we also got more and more ways of specifying colours. As well as hexadecimal, we got RGB: Red, Green, Blue. Better yet, we got RGBa …with alpha transparency. That’s opacity to you and me.

Then we got HSL: hue, saturation, lightness. Or should I say HSLa: hue, saturation, lightness, and alpha transparency.

And there are more colour spaces on the way. HWB (hue, whiteness, blackness), LAB, LCH. And there’s work on a color() function so you can specify even more colour spaces.

Typography

In the beginning, typography on the World Wide Web was non-existent. Your browser used whatever was available on your operating system.

That situation continued for quite a while. You’d have to guess which fonts were likely to be available on Windows or Mac.

If you wanted to use a sans-serif typeface, there was Arial on Windows and Helvetica on the Mac. Verdana was a pretty safe bet too.

For a while your only safe option for a serif typeface was Times New Roman. When Mathew Carter’s Georgia was released, it was a godsend. Here was a typeface specifically designed for the screen.

Later Microsoft released another four fonts designed for the screen. Four new fonts! It felt like we were being spoiled.

But what if you wanted to use a typeface that didn’t come installed with an operating system? Well, you went into Photoshop and made an image of the text. Now the user had to download additional images. The text wasn’t selectable and it was a fixed width.

We came up with all sorts of clever techniques to do what was called “image replacement” for text. Some of the techniques involved CSS and background images. One of the techniques involved Flash. It was called sIFR: Scalable Inman Flash Replacement. A later technique called Cufón converted the letter shapes into paths in Canvas.

All of these techniques were hacks. Very clever hacks, but hacks nonetheless. They were clever and they worked but they always reminded me of Samuel Johnson’s description of a dog walking on its hind legs:

It is not done well but you are surprised to find it done at all.

What if you wanted to use an actual font file in a web page?

There was only one browser that supported font embedding: Microsoft’s Internet Explorer. The catch was that you had to use a proprietary font format called Embedded Open Type.

Both type foundries and browser makers were nervous about allowing regular font files to be embedded in web pages. They were worried about licensing. Wouldn’t this lead to even more people downloading fonts illegally? How would the licensing be enforced?

The impasse was broken with a two-pronged approach. First of all, we got a new font format called Web Open Font Format or WOFF. It could be used to take a regular font file and wrap it in a light veneer of metadata about licensing. There’s a sequel that’s even better than the original, WOFF2.

The other breakthrough was the creation of intermediary services like Typekit and Fontdeck. They would take care of serving the actual font files, making sure they couldn’t be easily downloaded. They could also keep track of numbers to ensure that type foundries were being compensated fairly.

Over time it became clear to type foundries that most web designers wanted to do the right thing when it came to licensing fonts. And so these days, you can probably license a font straight from a type foundry for use on the web and host it yourself.

You might need to buy a few different weights. Regular. Bold. Maybe italic. What about extra bold? Or a light weight? It all starts to add up, especially for the end user who has to download all those files.

I remember being at the web typography conference Ampersand years ago and hearing a talk from Nick Sherman. He asked us to imagine one single font file that could go from light to regular to bold and everything in between. What he described sounded like science fiction.

It is now science fact, indistinguishable from magic. Variable fonts are here. You can typeset text on the web to be light, or regular, or bold, or anything in between.

When you use CSS to declare the font-weight property, you can use keywords like “normal” or “bold” but you can also use corresponding numbers like 400 or 700. There’s a scale with nine options from 100 to 900. But why isn’t the scale simply one to nine?

Well, even though the idea of variable fonts would have been pure fantasy when this part of CSS was being specced, the authors had some foresight:

One of the reasons we chose to use three-digit numbers was to support intermediate values in the future.

With the creation of variable fonts, Håkon Wium Lee added:

And the future is now.

On today’s web you could have 999 font-weight options.

Images

In the beginning, the World Wide Web was a medium for text only. There were no images and certainly no videos.

In an early mailing list discussion, there was talk of creating a new HTML element for images. Perhaps it should be called “icon”. Or maybe it should be more generic and be called “embed”. Tim Berners-Lee said he imagined using the rel attribute on the A element for embedding images.

While this discussion was happening, Marc Andreessen popped in to say that he had just shipped a new HTML element in the Mosaic browser. It’s called IMG and it takes an attribute called SRC that points to the source of the image.

This was a self-closing tag so there was no way to put fallback content in between the opening and closing tags if the image couldn’t be displayed. So the ALT attribute was introduced instead to provide an alternative description of the image.

For the images themselves, there were really only two choices. JPG for photographic images. GIF for icons or anything that needed basic transparency. GIFs could also do animation and today, that’s pretty much all they’re used for. That’s because there was a concerted campaign to ditch the GIF format on the web. Unisys, who owned the rights to a compression algorithm used by the GIF format, had started to make noises about potentially demanding license fees for its use.

The Portable Network Graphics format—or PNG—was created in response. It was more performant and it allowed you to have proper alpha transparency.

These were all bitmap formats. What if you wanted a vector format for images that would retain crispness at any size or resolution? There was only one option: Flash. You’d have to embed a Flash movie in your web page just to get the benefit of vector graphics.

By the 21st century there were some eggheads working on a text-based vector file format that could be embedded in webpages, but it sounded like a pipe dream. It was called SVG for Scalable Vector Graphics. The format was dreamed up in 2001 but for years, not a single browser supported it. It was like some theoretical graphical Shangri-La.

But by 2011, every major browser supported it. Styleable, scriptable, animatable, vector graphics have gone from fantasy to reality.

There’s more choice in the world of bitmap images too. WebP is well supported. AVIF is is gaining support.

The IMG element itself has grown too. You can use the srcset attribute to give the browser a range of images to choose from to best suit the user’s device and network connection. You can use the loading attribute to get lazy loading of images for free—no JavaScript required.

We now have audio in HTML. No JavaScript required. We now have video in HTML. No JavaScript required.

These elements have been designed with more thought than the IMG element. They are not self-closing elements, by design. You can put fallback content between the opening and closing tags.

The audio and video elements arrived long after the IMG element. For a long time, there was no easy way to do video or audio on the web.

That was very frustrating for me. The first websites I ever built were for bands. The only way to stream music was with a proprietary plug-in like Real Audio.

Or Flash.

While the web standards were still being worked on, Flash delivered the goods with streaming audio and video. This happened over and over. Flash gave us vector graphics, animation, video, and more. But the price was lock-in. Flash was a proprietary format.

Still, Flash showed the web standards bodies the direction of travel. Flash was the hare. Web standards were the tortoise.

We know how that race ended.

In a way, Flash was like the Research and Development incubator for the World Wide Web. We got CSS animations, SVG, and streaming video because Flash showed that there was an appetite for them.

Until web standards provide a way to do something, designers and developers will reach for whatever tool gets the job done. Take layout, for example.

Layout

In the early days of the web, you could have any layout you wanted …as long as it was a single column.

Before long, HTML expanded to provide some rudimentary formatting for that single column of text. Presentational elements and attributes were invented. And even when elements and attributes weren’t meant to be used for formatting, people got creative.

Tables for layout. A single pixel GIF that could be given width and height. These were clever solutions. But they were hacks. And they were in danger of turning HTML into a presentational language instead of a language for structuring content.

CSS came to the rescue. A language specifically for presentation.

But we still didn’t get proper layout tools. There was a lot of debate in the early days about whether CSS should even attempt to provide layout tools or whether that was a job for a separate technology.

We could lay things out using the float property, but really that was just another hack.

Floats were an improvement over tables for layout, but we only swapped one tool for another. Our collective thinking still wasn’t very web-like.

For example, designers and developers insisted on building websites with a fixed width. This started in the era of table layouts and carried over into CSS.

To start with, the fixed width was 640 pixels. Then it was 800 pixels. Then people settled on the magical number of 960 pixels. Designers and developers didn’t seem at all concerned that people had different sized screens.

That was until the iPhone came out. It caused a panic. What fixed width were we supposed to design for now?

The answer was there all along. Even before the web appeared in mobile devices, it was possible to build fluid layouts that would adapt to screen size. It’s just that the majority of designers and developers chose not to build in this way.

I was pleased that mobile came along and shook things up. It exposed the assumptions that people were making. And it forced designers and developers to think in a more fluid, webby way.

Even better, CSS had expanded to include media queries so it was possible to alter layouts at different breakpoints.

Ethan came along and put a nice bow on it with his definition of responsive design: fluid media, fluid layouts, and media queries.

I fell in love with responsive web design instantly becuase it matched how I was already thinking about the web. I was one of the handful of weirdos who insisted on building fluid websites when everyone else was using fixed-width layouts.

But I thought that responsive web design would struggle to take hold.

I’m delighted to say that I was wrong. Responsive web design has become the default!

If I could go back to my past self in the mid 2000s, I’d love to tell them that in the future, everyone would be building with fluid layouts (and also that time travel had been invented apparently).

Not only that, but we finally have proper layout tools for the web. Flexbox. Grid. No more hacks. We’re even getting container queries soon (thanks, Miriam!).

Web browsers now are positively overflowing with fantastic design tools that would have been unimaginable to my past self. Support for these technologies is pretty much universal.

When browsers differ today, it’s only terms of which standards they don’t yet support. There was a time when browsers differed massively in how they handled basic web technologies.

There was a time when being a web developer meant understanding all the different quirks between browsers.

And browser makers spent a ludicrous amount of time reverse-engineering the quirky behaviour of whichever browser was the market leader.

That changed with HTML5. We remember HTML5 for introducing new APIs, new form fields, and new structural elements. But the biggest innovation was completely invisible. For the first time, error-handling was standardised. Browsers had a set of rules they could work from. Once browsers adopted this consistent approach to error-handling, cross-browser differences dried up.

That was good news for web developers. We were sick of dealing with different browsers taking different approaches. We had been burned with JavaScript.

JavaScript

In the beginning, there was no scripting on the web, just like there was no styling. Tim Berners-Lee wasn’t opposed to the idea of executing arbitrary code on the web. But he pointed out that you’d need everyone to agree on which programming language browsers would use.

You need something really powerful, but at the same time ubiquitous. Remember a facet of the web is universal readership. There is no universal interpreted programming language.

This problem of which language to choose was solved in the usual way. Brendan Eich, who was working at Netscape, created a completely new programming language in just ten days. It would be called… LiveScript. Then the marketing department got involved and because Java was the new hotness at the time, this scripting language was renamed to… JavaScript. Even though it has nothing to do with Java. Java is to JavaScript as ham is to hamster.

The important thing is that multiple browsers implemented it. Then the hype started. We were told about this great new technology called DHTML. The D stood for dynamic! This would allow us to programmatically manipulate elements in a web page.

But… the two major browsers at the time, Netscape Navigator and Internet Explorer, used two completely incompatible syntaxes. For Netscape Navigator you’d use document.layers. For Internet Explorer it was document.all.

This was when developers said enough was enough. We wanted standards. The Web Standards Project was formed and we lobbied browser makers to implement web standards, like CSS and also the Document Object Model. This was a standardised way of manipulating elements in a web page. You could use methods like getElementById and getElementsByTagName.

That worked fine, but it was yet another vocabulary to learn. If you already knew CSS, then you already understood how to get an element by ID and get elements by tag name, but with a different syntax.

John Resig created jQuery so that you could use the CSS syntax to do DOM scripting. There were lots of other JavaScript libraries released around the same time, but jQuery was by far the most popular. Clearly, this syntax was something that developers wanted.

Now we no longer need jQuery. We’ve got querySelector and querySelectorAll. But the reason we no longer need jQuery is because of jQuery. Just like Flash, jQuery showed what developers wanted. And just as with Flash, the web standards took more time. But now jQuery is obsolete …precisely because it was so successful.

It’s a similar story with Sass and CSS. There was a time when Sass was the only way to have a feature like variables. But now with custom properties available in CSS, Sass is becoming increasingly obsolete …precisely because it was so successful and showed the direction of travel.

In a way, jQuery and Sass (and maybe even Flash) were kind of like polyfills. That’s a term that my friend Remy Sharp coined for JavaScript libraries that fill in the gaps until browsers have implemented web standards.

By way of explanation to anyone in the States, Polyfilla is a brand name in the UK for what you call spackling paste. So JavaScript libraries like jQuery spackled over the gaps in browsers.

But some capabilities can’t be polyfilled. If a browser doesn’t provide API access to a particular sensor, for example, there’s no way to spackle that gap.

For quite a while, if you wanted access to device APIs, you’d have to build a native app. But over time, that has changed. Now browsers are capable of providing app-like experiences. You can get location data. You can access the camera. You can provide notifications. You can even make websites work offline using service workers.

Native apps had all these capabilities before web browsers. Just as with Flash and jQuery, native apps pointed the way. The gap always looks insurmountable to begin with. But over time, the web always manages to catch up.

At the beginning of 2021, Ire said:

By the end of the year, I would predict that any major native mobile application could be instead built using native web capabilities.

The present

The web has come along way. It has grown and evolved. Browsers have become more and more powerful while maintaining backward compatibility.

In the past we had to hack our way around the technological limitations of the web and we had a long wish list of features we wanted.

I’m not saying we’re done. I’m sure that more features will keep coming. But our wish list has shrunk.

The biggest challenges facing the World Wide Web today are not technical challenges.

Today it is possible to create beautiful websites that make full use of colour, typography, layout, animation, and more. But this isn’t what users experience.

This is what users experience. A tedious frustrating game of whack-a-mole with websites that claim to value our privacy while asking us to relinquish it.

This is not a technical problem. It is a design decision. The decision might not be made by anyone with designer in their job title, but make no mistake, business decisions have a direct effect on user experience.

On the face of it, the problem seems to be with the business model of advertising. But that’s not quite right. To be more precise, the problem is with the business model of behavioural advertising. That relies on intermediaries to amass huge amounts of personal data so that they can supposedly serve up relevant advertising.

But contextual advertising, which serves up ads based on the content you’re looking at doesn’t require the invasive collection of personal data. And it works. Behavioural advertising, despite being a huge industry that depends on people giving up their privacy, doesn’t even work very well. And on the few occasions when it does work, it just feels creepy.

The problem is not advertising. The problem is tracking. The greatest trick the middlemen ever pulled was convincing us that you can’t have effective advertising without tracking. That is false. But they’ve managed to skew our sense of perspective so that invasive advertising seems inevitable.

Advertising was always possible on the web. You could publish anything and an ad is just one more thing you could choose to publish. But tracking was impossible. That’s because the early web was stateless. A browser requests a resource from a server and once that transaction is done, they both promptly forget about it. That made it very hard to do things like online shopping or logging into an account.

Two technologies were created later that enabled state on the web. Cookies and JavaScript. If these technologies had been limited to a same origin policy, they would have nicely solved the problems of online shopping and authentication.

But these technologies work across domains. Third party cookies and third-party JavaScript enables users to be tracked as they move from site to site. The web gone from having no state to having too much.

There is hope. Browsers like Firefox and Safari are blocking third-party cookies by default. Personally, I’d love it if third-party JavaScript got the same treatment. You can also install add-ons to make your browser more secure, although these add-ons are often labelled ad-blockers, which is a shame. Because the problem is not advertising. The problem is tracking.

Perhaps none of this applies to you anyway. You may be thinking that this is a problem for websites. But you build web apps.

Personally I’m not keen on the idea of dividing the entirety of the World Wide Web into two vaguely-defined categories. I have yet to hear a good definition of “web app” other than “a website that requires JavaScript to work.”

But the phrase “single page app” has a more definite meaning. It refers to an architectural decision. That decision is to reinvent the web browser inside a web browser.

In a sense, it’s a testament to the power of JavaScript that you can choose to do this. Browsers render content and perform navigations, but if you’d rather recreate that functionality from scratch in JavaScript, you can.

But should you? Browsers have increased in complexity so that we can build without complexity. We can use the built-in power of modern HTML, CSS, and JavaScript to make web browsers do the work. If we work with the grain of the web, we can accomplish more and more with less and less code.

But that isn’t what happened. Instead developers have recreated form controls like dropdowns and datepickers from scratch using divs and lashings and lashings of JavaScript.

Perhaps this points to some missing features on the web. It’s still too hard to style native dropdowns and datepickers (but that’s being worked on—there’s standards work underway to give us more styling control over form elements). But that doesn’t explain why developers would choose to recreate something like a button using divs and JavaScript when the button element already exists and can be styled any way you like.

I think there’s a certain mindset being applied to web development here. And that mindset comes from the world of software. Again, it’s a testament to how far the web has come that it can be treated as a software platform on par with operating systems like iOS, Android, or Windows. There’s a lot to be learned from the world of software development, like testing, for example. But the web is different. When a user navigates to a URL, it shouldn’t feel like they’re installing a piece of software.

We should be aiming to keep our payloads as small as possible. And given how powerful browsers have become, we need fewer and fewer dependencies—fewer and fewer polyfills.

But performance has gotten worse. Payloads have gotten bigger. Dependencies like JavaScript frameworks have become more and more widespread even as they became less and less necessary.

When asked to justify the enormous payloads, web developers have responded by saying that user’s expectations have changed. That is correct, but not in the way that I think they mean.

When I talk to people about using the web—especially on mobile—their expectations are that they will have a terrible experience. That websites will be slow to load. And I guarantee you that none of them are saying, “Well I’d be annoyed if this were a website but seeing as this is a web app, I’m absolutely fine with this terrible experience.”

I said that the biggest challenges facing the World Wide Web today are not technical challenges. I think the biggest challenge facing the web today is people’s expectations.

There is no technical reason for websites or web apps to be so frustrating. But we have collectively led people to expect a bad experience on the web.

Our intentions may be have good. We thought users wanted nice page transitions and form elements that were on-brand. But if you talk to people, you find out that what they want is to accomplish their task without megabytes of JavaScript getting in the way.

There’s a great German word, “Verschlimmbessern”: the act of making something worse in the attempt to make it better. Perhaps we verschlimmbessert the web.

Let’s step back. Get some perspective. Instead of assuming that a single page app architecture is needed, ask what users need to accomplish. Instead of assuming you need a CSS framework or a JavaScript library, see what you can do in browsers today with native CSS and vanilla JavaScript. Don’t include a bunch of dependencies by default just in case you might need them. Instead, as Rachel puts it:

Stop solving problems you don’t yet have.

Lean into what web browsers can accomplish today. If you find something missing, that’s the time to reach for a library …but treat it like a polyfill. Whereas web standards stick around, every library and framework comes with a limited lifespan. Treat them as cattle, not pets.

I understand that tools and frameworks can make your life easier. And if we’re talking about server-side frameworks, then I say “Go for it.” Or if you’re using build tools that sit on your computer to do version control, linting, pre-processing, or transpiling, then I say “Go for it.”

But once you make users download tools or frameworks, you’re making them pay a tax for your developer convenience.

We need to value user needs above developer convenience. If I have the choice of making something the user’s problem or making it my problem, I’ll make it my problem every time. That’s my job.

We need to change people’s expectations of the World Wide Web, especially on mobile. Otherwise, the web will be lost.

The future

Two years ago, I had the great honour of being invited to CERN to mark the 30th anniversary of the original proposal for the World Wide Web. One of the other people there was the journalist Zeynep Tüfekçi. She was on a panel along with Tim Berners-Lee and other luminaries of the early web. At the end of the panel discussion, she was asked:

What would you tell the next generation about how to use this wonderful tool?

She replied:

If you have something wonderful, if you do not defend it, you will lose it. If you do not defend the magic and the things that make it wonderful, it’s just not going to stay magical by itself.

I believe that we can save the web. I believe that we can change people’s expectations. We’ll do that by showing them what the web is capable of.

It sounds like a moonshot. But, y’know, moonshots aren’t made possible by astronauts. They’re made possible by people like Poppy Northcutt in mission control. Katherine Johnson running the numbers. And Margaret Hamilton inventing the field of software engineering to create the software for the lunar lander. Individual people working together on something bigger than any one person.

There’s a story told about the first time President Kennedy visited NASA. While he was a getting a tour of the place, he introduced himself to a janitor. And the president asked the janitor what he did. The janitor answered:

I’m helping put a man on the moon.

It’s the kind of story that’s trotted out by company bosses to make you feel good about having your labour exploited for the team. But that janitor’s loyalty wasn’t to NASA, an organisation. He was working for something bigger.

I encourage you to have that sense of perspective. Whatever company or organisation you happen to be working for right now, remember that you are building something bigger.

The future of the World Wide Web is in good hands. It’s in your hands.

Tuesday, October 19th, 2021

HTML with Superpowers - daverupert.com

A great talk from Dave on web components:

I think if you were using Web Components before 2020 you were an early adopter and you probably have some scars to show for it. But in 2021, now that all modern browsers support Web Components, I think they’re worth investigating. They have one superpower that no other JavaScript framework offers called the Shadow DOM which is both powerful but frustrating. But another superpower — the power I’m most excited about — is that you can use them standalone without any frameworks, build tools, or package managers.

The talk makes a callback to my talk Building from a few years back. I like that. It feels like a long thoughtful converstation.

Thursday, October 7th, 2021

Getting Started with PWAs [Workshop]

The slides from Aaron’s workshop at today’s PWA Summit. I really like the idea of checking navigator.connection.downlink and navigator.connection.saveData inside a service worker to serve different or fewer assets!

Have Single-Page Apps Ruined the Web? | Transitional Apps with Rich Harris, NYTimes - YouTube

This is a terrific and nuanced talk that packs a lot into less than twenty minutes.

I heartily concur with Rich’s assessment that most websites aren’t apps or documents but something in between. It’s a continuum. And I really like Rich’s proposed approach: transitional web apps.

(The secret sauce in transitional web apps is progressive enhancement.)

Have Single-Page Apps Ruined the Web? | Transitional Apps with Rich Harris, NYTimes

Monday, August 30th, 2021

Representation and what happened to women in Tech

Men specialized in hardware while software development was seen as an exciting alternative to secretarial work. In 1967, Cosmopolitan published an article titled The Computer Girls, encouraging young women to pursue careers in computer science. So the curve went up, and continued to do so up until 1984. That’s when personal computers appeared.

Marketing matters:

When Apple released the Macintosh 128K and the Commodore 64 was introduced to the market, they were presented as toys. And, as toys were gendered, they were targeted at boys. We can look at advertisements from that time and quickly find a pattern: fathers and sons, young men, even one where a man is being undressed by two women with the motto Two bytes are better than one. It’s more evident with the ads for computer games; if women appear, they do so sexualized and half-naked. Not that appealing for young girls, one could imagine.

Friday, August 6th, 2021

Browsers and Representation - Jim Nielsen’s Blog

It feels like the web we’re making now is a web designed for commercial interests.

If the web is “for everyone”, how and where are “everyone’s” interested being represented?

Browsers are not an enterprise of the people. We do not elect our browser representatives who decide what a browser is and is not.

Monday, June 21st, 2021

Talking about sci-fi

I gave my sci-fi talk last week at Marc’s Stay Curious event. I really like the format of these evening events: two talks followed by joint discussion, interspersed with music from Tobi. This particular evening was especially enjoyable, with some great discussion points being raised.

Steph and I had already colluded ahead of time on how we were going to split up the talks. She would go narrow and dive into one specific subgenre, solarpunk. I would go broad and give a big picture overview of science fiction literature.

Obviously I couldn’t possibly squeeze the entire subject of sci-fi into one short talk, so all I could really do was give my own personal subjective account. Hence, the talk is called Sci-fi and Me. I’ve published the transcript, uploaded the slides and the audio, and Marc has published the video on YouTube and Vimeo. Kudos to Tina Pham for going above and beyond to deliver a supremely accurate transcript with a super-fast turnaround.

I divided the talk into three sections. The first is my own personal story of growing up in small-town Ireland and reading every sci-fi book I could get my hands on from the local library. The second part was a quick history of sci-fi publishing covering the last two hundred years. The third and final part was a run-down of ten topics that sci-fi deals with. For each topic, I gave a brief explanation, mentioned a few books and then chose one that best represents that particular topic. That was hard.

  1. Planetary romance. I mentioned the John Carter books of Edgar Rice Burroughs, the Helliconia trilogy by Brian Aldiss, and the Riverworld saga by Philip José Farmer. I chose Dune by Frank Herbert.
  2. Space opera. I mentioned the Skylark and Lensman books by E.E. ‘Doc’ Smith, the Revelation Space series by Alastair Reynolds, and the Machineries of Empire books by Yoon Ha Lee. I chose Ancillary Justice by Ann Leckie.
  3. Generation starships. I mentioned Non-Stop by Brian Aldiss. I chose Aurora by Kim Stanley Robinson.
  4. Utopia. I mentioned the Culture novels by Iain M. Banks. I chose The Dispossessed by Ursula Le Guin
  5. Dystopia. I mentioned The Handmaid’s Tale by Margaret Atwood and Fahrenheit 451 by Ray Bradbury. I chose 1984 by George Orwell.
  6. Post-apocalypse. I mentioned The Drought and The Drowned World by J.G. Ballard, Day Of The Triffids by John Wyndham, The Road by Cormac McCarthy, and Oryx and Crake by Margaret Atwood. I chose Station Eleven by Emily St. John Mandel.
  7. Artificial intelligence. I mentioned Machines Like Me by Ian McEwan and Klara And The Sun by Kazuo Ishiguro. I chose I, Robot by Isaac Asimov.
  8. First contact. I mentioned The War Of The Worlds by H.G. Wells, Childhood’s End and Rendezvous With Rama by Arthur C. Clarke, Solaris by Stanislaw Lem, and Contact by Carl Sagan. I chose Stories Of Your Life And Others by Ted Chiang.
  9. Time travel. I mentioned The Time Machine by H.G. Wells, The Shining Girls by Lauren Beukes, and The Peripheral by William Gibson. I chose Kindred by Octavia Butler.
  10. Alternative history. I mentioned A Transatlantic Tunnel, Hurrah! by Harry Harrison. I chose The Man In The High Castle by Philip K. Dick.
  11. Cyberpunk. I mentioned Snowcrash by Neal Stephenson. I chose Neuromancer by William Gibson.

Okay, that’s eleven, not ten, but that last one is a bit of a cheat—it’s a subgenre rather than a topic. But it allowed me to segue nicely into Steph’s talk.

Here’s a list of those eleven books. I can recommend each and every one of them. Still, the problem with going with this topic-based approach was that some of my favourite sci-fi books of all time fall outside of any kind of classification system. Where would I put The Demolished Man by Alfred Bester, one of my all-time favourites? How could I classify Philip K. Dick books like Ubik, The Three Stigmata Of Palmer Eldritch, or A Scanner Darkly? And where would I even begin to describe the books of Christopher Priest?

But despite the inevitable gaps, I’m really pleased with how the overall talk turned out. I had a lot of fun preparing it and even more fun presenting it. It made a nice change from the usual topics I talk about. Incidentally, if you’ve got a conference or a podcast and you ever want me to talk about something other than the web, I’m always happy to blather on about sci-fi.

Here’s the talk. I hope you like it.