Tags: css

1158

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.

Saturday, June 18th, 2022

CSS Day 2022

I was in Amsterdam two weeks ago for CSS Day. It was glorious!

I mean, even without the conference it was just so nice to travel somewhere—by direct train, no less!—and spend some time in a beautiful European city enjoying the good weather.

And of course the conference was great too. I’ve been to CSS Day many times. I love it although technically it should be CSS days now—the conference runs for two days.

It’s an event that really treats CSS for what it is—a powerful language worthy of respect. Also, it has bitterballen.

This time I wasn’t just there as an attendee. I also had the pleasure of opening up the show. I gave a talk called In And Out Of Style, a look at the history—and alternative histories—of CSS.

The video is already online! I’ll get the talk transcribed and publish the text here soon. Meanwhile here’s a list of links to relevant material.

I really, really enjoyed giving this talk. It was so nice to be speaking to a room—or in this case, a church—with real people. I’m done giving talks to my screen. It’s just not the same. Giving this talk made me realise how much I need that feedback from the crowd—the laughs, the nods, maybe even the occasional lightbulb appearing over someone’s head.

As usual, my talk was broad and philosophical in nature. Big-picture pretentious talks are kind of my thing. In this case, I knew that I could safely brush over the details of all the exciting new CSS stuff I mentioned because other talks would be diving deep. And boy, did they ever dive deep!

It’s a cliché to use the adjective “inspiring” to describe a conference, but given all that’s happening in the world of CSS right now, it was almost inevitable that CSS Day would be very inspiring indeed this year. Cascade layers, scoped styles, container queries, custom properties, colour spaces, animation and much much more.

If anything, it was almost too much. If I had one minor quibble with the event it would be that seven talks in a day felt like one talk too many to my poor brain (I think that Marc gets the format just right with Beyond Tellerrand—two days of six talks each). But what a great complaint to have—that there was a glut of great talks!

They’ve already announced the dates for next year’s CSS Day(s): June 8th and 9th, 2023. I strongly suspect that I’ll be there.

Thank you very much to ppk, Krijn, Martijn, and everyone involved in making this year’s CSS Day so good!

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

Monday, June 6th, 2022

Paper Prototype CSS

A stylesheet to imitate paper—perfect for low-fidelity prototypes that you want to test.

Monday, May 23rd, 2022

Min-Max-Value Interpolation

Here’s a really nice little tool inspired by Utopia for generating one-off clamp() values for fluid type or spacing.

Thursday, May 5th, 2022

Tim Brown: CSS forces

Some interesting thoughts from Tim here. What if CSS could “displace” design decisions from one area to another?

For example, a flexible line spacing value in one container could influence margins that surround the text block. That change in spaciousness may mean that nearby headings need size or spacing adjustments to stay feeling connected.

This feels like the complete opposite way that most people approach design systems—modular, componentised, and discrete—but very in-line with the way that CSS has been designed—interconnected, relational and cascading.

Wednesday, May 4th, 2022

Fluid Type Scale - Generate responsive font-size variables

This is kind of a Utopia lite: pop in your minimum and maximum font sizes along with a modular scale and it spits out some custom properties for clamp() declarations.

Contextual Spacing For Intrinsic Web Design | Modern CSS Solutions

To complement her talk at Beyond Tellerrand, Stephanie goes through some of the powerful CSS features that enable intrinsic web design. These are all great tools for the declarative design approach I was talking about:

Tuesday, May 3rd, 2022

Bugblogging

A while back I wrote a blog post called Web Audio API weirdness on iOS. I described a bug in Mobile Safari along with a hacky fix. I finished by saying:

If you ever find yourself getting weird but inconsistent behaviour on iOS using the Web Audio API, this nasty little hack could help.

Recently Jonathan Aldrich posted a thread about the same bug. He included a link to my blog post. He also said:

Thanks so much for your post, this was a truly pernicious problem!

That warms the cockles of my heart. It’s very gratifying to know that documenting the bug (and the fix) helped someone out. Or, as I put it:

Yay for bugblogging!

Forgive the Germanic compound word, but in this case I think it fits.

Bugblogging doesn’t need to involve a solution. Just documenting a bug is a good thing to do. Recently I documented a bug with progressive web apps on iOS. Before that I documented a bug in Facebook Container for Firefox. When I documented some weird behaviour with the Web Share API in Safari on iOS, I wasn’t even sure it was a bug but Tess was pretty sure it was and filed a proper bug report.

I’ve benefited from other people bugblogging. Phil Nash wrote Service workers: beware Safari’s range request. That was exactly what I needed to solve a problem I’d been having. And then that post about Phil solving my problem helped Peter Rukavina solve a similar issue so he wrote Phil Nash and Jeremy Keith Save the Safari Video Playback Day.

Again, this warmed the cockles of my heart. Bugblogging is worth doing just for the reward of that feeling.

There’s a similar kind of blog post where, instead of writing about a bug, you write about a particular technique. In one way, this is the opposite of bugblogging because you’re writing about things working exactly as they should. But these posts have a similar feeling to bugblogging because they also result in a warm glow when someone finds them useful.

Here are some recent examples of these kinds of posts—tipblogging?—that I’ve found useful:

All three are very handy tips. Thanks, Eric! Thanks, Rich! Thanks, Stephanie!

Sunday, May 1st, 2022

Trust • Robin Rendle

Robin adds a long-zoom perspective on my recent post:

I am extremely confident that pretty much any HTML I write today will render the same way in 50 years’ time. How confident am I that my CSS will work correctly? Mmmm…70%. Hand-written JavaScript? Way less, maybe 50%. A third-party service I install on a website or link to? 0% confident. Heck, I’m doubtful that any third-party service will survive until next year, let alone 50 years from now.

Thursday, April 28th, 2022

Suspicion

I’ve already had some thoughtful responses to yesterday’s post about trust. I wrapped up my thoughts with a request:

I would love it if someone could explain why they avoid native browser features but use third-party code.

Chris obliged:

I can’t speak for the industry, but I have a guess. Third-party code (like the referenced Bootstrap and React) have a history of smoothing over significant cross-browser issues and providing better-than-browser ergonomic APIs. jQuery was created to smooth over cross-browser JavaScript problems. That’s trust.

Very true! jQuery is the canonical example of a library smoothing over the bumpy landscape of browser compatibilities. But jQuery is also the canonical example of a library we no longer need because the browsers have caught up …and those browsers support standards directly influenced by jQuery. That’s a library success story!

Charles Harries takes on my question in his post Libraries over browser features:

I think this perspective of trust has been hammered into developers over the past maybe like 5 years of JavaScript development based almost exclusively on inequality of browser feature support. Things are looking good in 2022; but as recently as 2019, 4 of the 5 top web developer needs had to do with browser compatibility.

Browser compatibility is one of the underlying promises that libraries—especially the big ones that Jeremy references, like React and Bootstrap—make to developers.

So again, it’s browser incompatibilities that made libraries attractive.

Jim Nielsen responds with the same message in his post Trusting Browsers:

We distrust the browser because we’ve been trained to. Years of fighting browser deficiencies where libraries filled the gaps. Browser enemy; library friend.

For example: jQuery did wonders to normalize working across browsers. Write code once, run it in any browser — confidently.

Three for three. My question has been answered: people gravitated towards libraries because browsers had inconsistent implementations.

I’m deliberately using the past tense there. I think Jim is onto something when he says that we’ve been trained not to trust browsers to have parity when it comes to supporting standards. But that has changed.

Charles again:

This approach isn’t a sustainable practice, and I’m trying to do as little of it as I can. Jeremy is right to be suspicious of third-party code. Cross-browser compatibility has gotten a lot better, and campaigns like Interop 2022 are doing a lot to reduce the burden. It’s getting better, but the exasperated I-just-want-it-to-work mindset is tough to uninstall.

I agree. Inertia is a powerful force. No matter how good cross-browser compatibility gets, it’s going to take a long time for developers to shed their suspicion.

Jim is glass-half-full kind of guy:

I’m optimistic that trust in browser-native features and APIs is being restored.

He also points to a very sensible mindset when it comes to third-party libraries and frameworks:

In this sense, third-party code and abstractions can be wonderful polyfills for the web platform. The idea being that the default posture should be: leverage as much of the web platform as possible, then where there are gaps to creating great user experiences, fill them in with exploratory library or framework features (features which, conceivably, could one day become native in browsers).

Yes! A kind of progressive enhancement approach to using third-party code makes a lot of sense. I’ve always maintained that you should treat libraries and frameworks like cattle, not pets. Don’t get too attached. If the library is solving a genuine need, it will be replaced by stable web standards in browsers (again, see jQuery).

I think that third-party libraries and frameworks work best as polyfills. But the whole point of polyfills is that you only use them when the browsers don’t supply features natively (and you also go back and remove the polyfill later when browsers do support the feature). But that’s not how people are using libraries and frameworks today. Developers are reaching for them by default instead of treating them as a last resort.

I like Jim’s proposed design princple:

Where available, default to browser-native features over third party code, abstractions, or idioms.

(P.S. It’s kind of lovely to see this kind of thoughtful blog-to-blog conversation happening. Right at a time when Twitter is about to go down the tubes, this is a demonstration of an actual public square with more nuanced discussion. Make your own website and join the conversation!)

Wednesday, April 27th, 2022

Flexibly Centering an Element with Side-Aligned Content – Eric’s Archived Thoughts

This is a great little tip from Eric for those situations when you want an element to be centred but you want the content inside that element to remain uncentred:

max-inline-size: max-content;
margin-inline: auto;

And I completely concur with his closing thoughts on CSS today:

It’s a nice little example of the quiet revolution that’s been happening in CSS of late. Hard things are becoming easy, and more than easy, simple. Simple in the sense of “direct and not complex”, not in the sense of “obvious and basic”. There’s a sense of growing maturity in the language, and I’m really happy to see it.

Trust

I’ve noticed a strange mindset amongst front-end/full-stack developers. At least it seems strange to me. But maybe I’m the one with the strange mindset and everyone else knows something I don’t.

It’s to do with trust and suspicion.

I’ve made no secret of the fact that I’m suspicious of third-party code and dependencies in general. Every dependency you add to a project is one more potential single point of failure. You have to trust that the strangers who wrote that code knew what they were doing. I’m still somewhat flabbergasted that developers regularly add dependencies—via npm or yarn or whatever—that then pull in even more dependencies, all while assuming good faith and competence on the part of every person involved.

It’s a touching expression of faith in your fellow humans, but I’m not keen on the idea of faith-based development.

I’m much more trusting of native browser features—HTML elements, CSS features, and JavaScript APIs. They’re not always perfect, but a lot of thought goes into their development. By the time they land in browsers, a whole lot of smart people have kicked the tyres and considered many different angles. As a bonus, I don’t need to install them. Even better, end users don’t need to install them.

And yet, the mindset I’ve noticed is that many developers are suspicious of browser features but trusting of third-party libraries.

When I write and talk about using service workers, I often come across scepticism from developers about writing the service worker code. “Is there a library I can use?” they ask. “Well, yes” I reply, “but then you’ve got to understand the library, and the time it takes you to do that could be spent understanding the native code.” So even though a library might not offer any new functionality—just a different idion—many developers are more likely to trust the third-party library than they are to trust the underlying code that the third-party library is abstracting!

Developers are more likely to trust, say, Bootstrap than they are to trust CSS grid or custom properties. Developers are more likely to trust React than they are to trust web components.

On the one hand, I get it. Bootstrap and React are very popular. That popularity speaks volumes. If lots of people use a technology, it must be a safe bet, right?

But if we’re talking about popularity, every single browser today ships with support for features like grid, custom properties, service workers and web components. No third-party framework can even come close to that install base.

And the fact that these technologies have shipped in stable browsers means they’re vetted. They’ve been through a rigourous testing phase. They’ve effectively got a seal of approval from each individual browser maker. To me, that seems like a much bigger signal of trustworthiness than the popularity of a third-party library or framework.

So I’m kind of confused by this prevalent mindset of trusting third-party code more than built-in browser features.

Is it because of the job market? When recruiters are looking for developers, their laundry list is usually third-party technologies: React, Vue, Bootstrap, etc. It’s rare to find a job ad that lists native browser technologies: flexbox, grid, service workers, web components.

I would love it if someone could explain why they avoid native browser features but use third-party code.

Until then, I shall remain perplexed.

Tuesday, April 26th, 2022

Speaking at CSS Day 2022

I’m very excited about speaking at CSS Day this year. My talk is called In And Out Of Style:

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!

Technically, CSS Day won’t be the first outing for this talk but it will be the in-person debut. I had the chance to give the talk online last week at An Event Apart. Giving a talk online isn’t quite the same as speaking on stage, but I got enough feedback from the attendees that I’m feeling confident about giving the talk in Amsterdam. It went down well with the audience at An Event Apart.

If the description has you intrigued, come along to CSS Day to hear the talk in person. And if you like the subject matter, I’ve put together these links to go with the talk…

Blog posts

Presentations

Proposals (email)

Papers (PDF)

People (Wikipedia)

Tuesday, April 19th, 2022

Upcoming events

I see that Russell is planning to bring back Interesting this year. This makes me happy. Just seeing the return of in-person gatherings—run safely—is giving me life.

I don’t think I’m alone in this. I think that lots of people are yearning for some in-person contact after two years of online events. The good news is that there are some excellent in-person web conferences on the horizon.

Beyond Tellerrand is back in Düsseldorf on May 2nd and 3rd. Marc ran some of the best online events during lockdown with his Stay Curious cafés, but there’s nothing beats the atmosphere of Beyond Tellerrand on its home turf.

If you can’t make it Düsseldorf—I probably can’t because I’m getting my passport renewed right now—there’s All Day Hey in Leeds on May 5th. Harry has put a terrific line-up together for this one-day, very affordable event.

June is shaping up to be a good month for events too. First of all, there’s CSS Day in Amsterdam on June 9th and 10th. I really, really like this event. I’m not just saying that because I’m speaking at this year’s CSS Day. I just love the way that the conference treats CSS with respect. If you self-identigy as a CSS person, then this is the opportunity to be with your people.

But again, if you can’t make it Amsterdam, never fear. The Pixel Pioneers conference returns to Bristol on June 10th. Another one-day event in the UK with a great line-up.

Finally, there’s the big one at the end of June. UX London runs from June 28th to June 30th:

Bringing the UX community back together

Yes, I’m biased because I’m curating the line-up but this is shaping up to be unmissable! It’s going to be so good to gather with our peers and get our brains filled by the finest of design minds.

Be the browser’s mentor, not its micromanager. - Build Excellent Websites

This one-page site that Andy has made to illustrate his talk at All Day Hey is exactly what I was talking about with declarative design.

Give the browser some solid rules and hints, then let it make the right decisions for the people that visit it, based on their device, connection quality and capabilities. This is how they will get a genuinely great user experience, rather than a fragmented, broken one.

Thursday, April 14th, 2022

Declarative design

I feel like in the past few years there’s been a number of web design approaches that share a similar mindset. Intrinsic web design by Jen; Every Layout by Andy and Heydon; Utopia by Trys and James.

To some extent, their strengths lie in technological advances in CSS: flexbox, grid, calc, and so on. But more importantly, they share an approach. They all focus on creating the right inputs rather than trying to control every possible output. Leave the final calculations for those outputs to the browser—that’s what computers are good at.

As Andy puts it:

Be the browser’s mentor, not its micromanager.

Reflecting on Utopia’s approach, Jim Nielsen wrote:

We say CSS is “declarative”, but the more and more I write breakpoints to accommodate all the different ways a design can change across the viewport spectrum, the more I feel like I’m writing imperative code. At what quantity does a set of declarative rules begin to look like imperative instructions?

In contrast, one of the principles of Utopia is to be declarative and “describe what is to be done rather than command how to do it”. This approach declares a set of rules such that you could pick any viewport width and, using a formula, derive what the type size and spacing would be at that size.

Declarative! Maybe that’s the word I’ve been looking for to describe the commonalities between Utopia, Every Layout, and intrinsic web design.

So if declarative design is a thing, does that also mean imperative design is also a thing? And what might the tools and technologies for imperative design look like?

I think that Tailwind might be a good example of an imperative design tool. It’s only about the specific outputs. Systematic thinking is actively discouraged; instead you say exactly what you want the final pixels on the screen to be.

I’m not saying that declarative tools—like Utopia—are right and that imperative tools—like Tailwind—are wrong. As always, it depends. In this case, it depends on the mindset you have.

If you agree with this statement, you should probably use an imperative design tool:

CSS is broken and I want my tools to work around the way CSS has been designed.

But if you agree with this statement, you should probably use a declarative design tool:

CSS is awesome and I want my tools to amplify the way that CSS had been designed.

If you agree with the first statement but you then try using a declarative tool like Utopia or Every Layout, you will probably have a bad time. You’ll probably hate it. You may declare the tool to be “bad”.

Likewise if you agree with the second statement but you then try using an imperative tool like Tailwind, you will probably have a bad time. You’ll probably hate it. You may declare the tool to be “bad”.

It all depends on whether the philosophy behind the tool matches your own philosophy. If those philosophies match up, then using the tool will be productive and that tool will act as an amplifier—a bicycle for the mind. But if the philosophy of the tool doesn’t match your own philosophy, then you will be fighting the tool at every step—it will slow you down.

Knowing that this spectrum exists between declarative tools and imperative tools can help you when you’re evaluating technology. You can assess whether a web design tool is being marketed on the premise that CSS is broken or on the premise that CSS is awesome.

I wonder whether your path into web design and development might also factor into which end of the spectrum you’d identify with. Like, if your background is in declarative languages like HTML and CSS, maybe intrisic web design really resonates. But if your background is in imperative languages like JavaScript, perhaps Tailwind makes more sense to you.

Again, there’s no right or wrong here. This is about matching the right tool to the right mindset.

Personally, the declarative design approach fits me like a glove. It feels like it’s in the tradition of John’s A Dao Of Web Design or Ethan’s Responsive Web Design—ways of working with the grain of the web.

Tuesday, April 12th, 2022

CSS Quick Tip: Animating in a newly added element | Stephanie Eckles

I can see myself almost certainly needing to use this clever technique at some point so I’m going to squirrel it away now for future me.

Thoughts on Exerting Control With Media Queries - Jim Nielsen’s Blog

Some thoughts on CSS, media queries, and fluid type prompted by Utopia:

We say CSS is “declarative”, but the more and more I write breakpoints to accommodate all the different ways a design can change across the viewport spectrum, the more I feel like I’m writing imperative code. At what quantity does a set of declarative rules begin to look like imperative instructions?

In contrast, one of the principles of Utopia is to be declarative and “describe what is to be done rather than command how to do it”. This approach declares a set of rules such that you could pick any viewport width and, using a formula, derive what the type size and spacing would be at that size.