
In this podcast series, Bruce interviews people from across different communities and industries who, in their own way, are fighting for a better web.
In this episode, Bruce chats with Miriam Suzanne, a CSS expert and independent contributor to the CSS Working Group, to talk about all things CSS. They geek out over the latest and greatest features like Cascade Layers, @Scope, Mixins, and Container Queries, exploring how these features impact web design. They also discuss her recent blogpost “Tech continues to be political”.
You can donate to support Miriam’s independent contributions at OddBird open source.
Transcript
[Bruce:] Hello, everybody, and welcome to the For a Better Web podcast. I’m Bruce Lawson, and I do technical comms for Vivaldi, who make a browser for PCs, desktops, mobiles, and vehicles. I’m talking cars. And once a month or so, I have a chat with somebody who is working in their own way, in their own industry, to make the web a better place. And today, it’s my absolute pleasure to be chatting to Miriam Suzanne. She’s also known as Mia, so that’s what I’m going to call her. All the way from the sunny United States, thank you for getting up so early, Mia, and welcome to the podcast.
[Mia:] Oh, thank you so much. It’s lovely to be here. Thanks for staying up so late.
[Bruce:] it’s only four o’clock here it’s not even dark in the autumnal (autumnal?!) wintery UK. So Mia, you came –it seemed to me– from, just exploded onto the scene in the CSS working group about, I don’t know, four or five years ago now. I’ve lost track of time since COVID.
[Mia:] Yeah. I joined the working group right when Denver locked down, at least. It was like the same week. So I think I caused it. I don’t remember coming from nowhere. It’s not my memory of it, but…yeah.
[Bruce:] You were involved with SASS , et cetera. I discovered later that I wasn’t in the SASS world, so you sort of exploded onto the scene for me personally. (I’m just going to cough. Excuse me, listeners.) And in that time, you’ve produced some major specs for the CSS working group that have made their way pretty damn fast, actually, into browsers. It’s CSS Layers, Container Queries, and there’s another one, Scoping. Is that still happening? Yeah,
[Mia:] Scope is happening. It’s part of Interop this year. A few issues we still need to resolve. And then I’ve been working on mixins and functions as well.
[Bruce:] So direct inheritance from your SASS days.
[Mia:] Yeah, everybody keeps saying that these new features in CSS will kill SASS, and I guess that’s my job. I don’t think it’ll work, but I’ll do what I can.
[Bruce:] So you invented SASS to make writing complex CSS easier for developers. Is that reasonable?
[Mia:] Well, I didn’t invent it. I sort of got involved several years in. I was playing with various layout systems around 2008, 2009, and they were all pretty, I don’t know, locked down, not real flexible. And then I saw what Natalie Downe was doing at ClearLeft with sort of a really responsive. This was before capital RWD, responsive web design trademark. She was doing something that was sort of a combination of fluid grids inside of em-based containers. So it was responding to font size and also the browser size and just had a lot of flexibility. So I was using her system, but it involved a lot of math. It was sort of every width involved this same equation to determine the width of anything, the right percentages. And I was tired of doing that same equation over and over. And my brother said, have you seen this SASS thing? That’s basically what it does, is it does equations for you. So I started using SASS for that, and I made a little tool that would sort of let me do Natalie Down’s system very flexibly, sort of a grid system system, so that I wouldn’t have to use the pre-built class libraries. And when SASS took off and became popular, I happened to be the person that had a SASS grid system. And so I sort of rode that wave because, yeah, people wanted to use SASS then and they wanted a grid system. So there I was.
[Bruce:] Now we have grids natively in CSS and you’re working on mixins and functions, et cetera. Why would SASS continue to live if it’s being replaced or various bits of it are finding their way into modern CSS?
[Mia:] Well, it’s the same reason that Node exists, I suppose. It’s useful sometimes to do things on the server without making the browser do it. So if you’ve got some design logic happening and you want to keep that logic and not just flatten it to the results, but it’s going to be the same all the time, it’s going to be constant in some way, there’s no reason to make the reader’s browser do that work. So I think of that particularly for design systems, color management. There’s all sorts of ways that I want to store and manipulate colors that don’t really affect the browser. They’re just sort of helping me do it. But if you don’t need that, great: stop using SASS. There’s no reason people should hang on to it longer than they need. And I think it’s great. It’s great if these new features in CSS replace SASS for you, but I don’t think they will for everyone. I think larger projects, projects with a lot of sort of design logic in them, design systems, will still have a use for that.
[Bruce:] I guess it’s like CSS took lots of inspiration from things like jQuery. And this is a, you know, it’s a great thing that developers invent something like jQuery or SASS and work out the way that feels best to developers. And then the CSS working group subsequently fold that into the language natively rather than trying to invent something. But jQuery ain’t gone nowhere, even though, you know, allegedly lots of it is being replaced by modern CSS. Simply, I guess, because A, people know how to use it. And B, if it’s working for you, who’s going to pay you to refactor old code? Exactly.
[Mia:] And both parts of that are fine, right? It’s fine that a lot less sites are using jQuery, and it’s fine that some still find it useful. It’s great.
[Bruce:] So how well does it work you being effectively a lone wolf, inventing browser features, in a working group that is pretty much I guess dominated by people from Apple, Google, Microsoft and the other big tech companies. And I don’t mean they dominate because they’re overbearing. It’s just because they have budgets to pay people to do this stuff. And you’re on your own. How were you received? How does it work out? How does it happen?
[Mia:] Yeah, it’s interesting. And that’s changed over the last year or so. So when I joined, there were actually quite a few. And there’s still several that are sort of independent members, invited experts. But it used to be more. So Rachel Andrew used to be an invited expert. Elika Etimad (Fantasai) was an invited expert. Florian still is. There’s various others. There’s a number of us, so I wasn’t coming into it as like the only, the only person not working for one of the major companies. since then, a lot of those people have gone to either Apple or Google. So it feels like there are fewer and fewer of us just in the last year or so, but there are still a few. it’s not a strange thing I was welcomed very warmly. Elika in particular did a lot to sort of show me around and invite me to collaborate on things, and just a lot of sort of teaching from her I think she’s been part of the working group in high school I think or something.
[Bruce:] Forever. Fantasai has been there forever, hasn’t she?
[Mia:] Yeah. And, yeah, I’ve felt very welcomed, but it is interesting. I mean, nothing happens without the browsers agreeing to it. And that’s because we’re designing features for browsers. So we can’t enforce anything. It all has to be agreement and collaboration across the three major engines.
[Bruce:] Which is great and particularly good that they are receptive to the perspectives of people who are outside those engines. Because like any world, you can get tunnel vision, or live in a bubble or choose your metaphor. But I have found that the working groups are particularly receptive to outside perspectives.
[Mia:] Yeah, and the CSS working group, and maybe this is true of other working groups too, the people from the browser engines in the working group are browser engineers. A lot of them haven’t built a website in the last five years. It’s not what they do. They build browser engines, not websites. So I was scared coming in because I don’t know how to build a browser engine. And it seemed absurd to me that I could work on Container Queries where the major issue is a browser engine sort of loop. And I don’t know anything about browser engine loops. So it seemed weird that I could come in and help with this.
But from their perspective, it was very much like, well, it was also absurd that they could fix it. without having somebody who builds websites. And the whole thing was a collaboration. It took all of us going back and forth and me being like, no, this is what works for writing the CSS and them being like, no, this is what works for writing the browser engine. And, yeah. So nobody in the group has all of the knowledge. Yeah, you’re muted.
[Bruce:] It reminds me of when the WHAT Working Group invented AppCache many years ago and Hixie –Ian Hickson– who’s a brilliant editor and spec writer just pulled this idea out of his hat and it got implemented and all of the web dev community hated it, because it just wasn’t flexible enough and eventually it got replaced by Service Worker. And I think only recently AppCache was actually taken out of the engines because it got no use. And that really drove home to me the importance of having actual web developers working on the standards right from the get-go. And to be fair, the CSS Working Group do seem to have understood that. We’ve seen great interest in, for example, how they specify CSS Masonry, with Jen and Rachel coming in with different WebKit and Chrome proposals, and saying to developers, what makes sense to you? How would you like to write this? And I think that’s fantastic.
[Mia:] Yeah, I really like, I sort of, Masonry is not my top priority, but I really like the back and forth on it. And I’m particularly excited because I think it goes into conversations of future layouts we could have and how we want to keep building this language more broadly. There are a lot of good ideas for future layout techniques that have come out of the masonry back and forth. So even if you don’t care particularly about having a Pinterest-style site or something, there’s still a lot in that conversation that’s worth looking at.
[Bruce:] And I’ve personally found the tone of the conversation really – I was going to say heartwarming. Yeah, actually heartwarming, because I’m not clever enough to be able to think through the ramifications of a syntax that doesn’t exist yet, and work out its limitations. Other people are clever enough to do so. But even when people disagreed, they were doing it from a position of mutual respect and always trying to make sure that the user, in a spec’s case, that’s a developer, a web developer, gets the best experience. And I thought that was great.
So you’ve mentioned Container Queries, which was one of the specs that you worked on. I guess by the word worked on, do we mean edited? Did you kind of make the initial proposal? And obviously you didn’t work on it alone.
[Mia:] Yeah, no. I made the initial proposal for cascade layers, which is what got me into the group. But Container Queries, I mean, people have been asking for Container Queries under various names, Element Queries, et cetera, since 2011. was the earliest that I found, although it might have been earlier. But it’s basically like we got media queries in 2010, and everybody said, these are great. They would be even better if they were on a container immediately. And browsers said, that will never happen. And here we are.
But no, I came in. I was working on Cascade Layers, and I was doing it independently. And Nicole Sullivan reached out. She was at Google at that point. She’s not anymore. And said, we’ll help fund your work in the working group. If you’ll also take a look at container queries, we think it can be solved now. And I had a panic attacks! I was like, it’s been sitting there since 2011 and nobody’s figured it out. And now you want the newest person in the group to work on it! But Brian Kardell and David Baron had both just recently written proposals on different approaches. So a lot of it was just taking their work, talking to them, and being a person who had a little bit of funding to do this. And picking it up and looking at what they had proposed and talking through it with people.
And yeah, so then I became an editor on that specification. And there’s, you know, three or four editors on most modules in CSS. So I was joining Tab and Elika and maybe David. I don’t remember who else was on that specification. Or maybe Florian. And yeah, Florian was part of that one. Talking through it with them and getting a lot of guidance from Elika and Florian, particularly on how to write a spec. And then doing a lot of it collaboratively with them. And back and forth with Ian Kilpatrick at Google a lot. He was the engineer who sort of said, I see a path for this. Here’s how we would do it in the browser engines.
[Bruce:] And for listeners who aren’t necessarily CSS writers, Media Queries is when you can say, if the width of my viewport, my screen is below or above such, you know, make it two columns, make it one column. Element queries, well, would you mind giving us the elevator pitch, please, Mia?
[Mia:] Yeah. So container queries are, I mean, the most basic feature is the same thing, saying how wide is the container that I’m in. But at this point, instead of just looking at the viewport, the browser window, we’re able to look at a smaller container in the site. So we could say, look at the sidebar. I’m a component in the sidebar. How big is the sidebar? Do I need to go to a sort of a smaller layout or something if I don’t have much space? And then if that same component is moved into a main area and it has more space, can it re-layout because it knows how much space it has?
The part that I found really interesting was, you know, when we talk about media queries or when people were requesting container queries, the width of a thing is what we talk about most. But if you look at the whole list of container queries, there’s, you know, is there a cursor or how thick is the pointer? Is it a very fine pointer like a mouse cursor? Is it a very thick pointer like a finger? Does the interface support hovering? All these questions about the interface that don’t really, they apply to the media. They’re questions about the media. And when we’re looking at a container, we also can ask different questions. And they’re not the same questions we would ask of an interface. So instead of asking, like, does this support hover? How big is the pointer? We could say, what is the computed value of a custom property? We could say, is my color scheme light or dark? We could ask all these sorts of questions that an element might be able to answer. So that’s where I started to get really excited. It was like, oh, there’s more than just sizes here. We could start asking other questions of containers. What all do we want to ask a container? Are you overflowing? Are you scrollable? Things like that.
[Bruce:] Are those in the spec now? Are you overflowing? Are you scrollable?
[Mia:] We’re working on them. Are you overflowing? There’s a proposal there that Chrome has been working on. There’s one for are you positioned sticky and currently stuck, which is an interesting one. So as you start to scroll and something sticks to the top, you can now, you’d be able to query for that. There’s other proposals there. Are you in a snapping context and currently snapped, I think is one. And we do have style queries, I think, are now everywhere already, which is the ability to ask, is there a particular value of a custom property?
[Bruce:] It’s been less than a year since I was writing web pages. And this is new to me. So you take your eyes off CSS for about 25 seconds and the world has changed from below you. Yeah, it’s been moving really quickly lately. No, no, no shortage of thanks to you, actually, for that. There’s also my favorite is Layers.
[Mia:] Mine too.
[Bruce:] Well, people didn’t like the Cascade for reasons. I love the Cascade. And people wanted a way to remove the Cascade from CSS. And you came in and went, let’s add to the Cascade, just to spite all the people who hate the Cascade, presumably. Not hate the Cascade.
[Mia:] Just out of spite. Just out of spite.
[Bruce:] From your spitefulness, great things happen. Could you give us the airport, the bird’s eye view of CSS layering, please?
[Mia:] So right before I was in the working group, I had a contract with Mozilla when Jen Simmons was at Mozilla, and she was trying to start a sort of educational program, a YouTube channel, really, Mozilla developer channel on YouTube. and she asked if I would come in and help create some of the videos and help teach CSS. So I went there and I was working on a series. She would sort of ask me questions and be like, can you answer this in a video? She was like, why do people dislike CSS? What’s the thing that they’re pushing against? So one of my first videos there was why is CSS so weird? And I was just trying to get at this, like, what is the thing that is surprising people when they interact with this? And I talked a little bit about the history and why we have the cascade.
But then she was like, okay, why do people want something like CSS in JavaScript or Tailwind? What’s the problem that they’re running into? Why are they doing this? What’s the issue in CSS, or what’s the misunderstanding, or the problem?
So I was working on a series about the cascade and trying to think through that question. And the conclusion that I came to, I don’t know if I’m right, was it seemed to me like the cascade is this really interesting idea. It’s got all these parts to it. But the only part that authors are interfacing with regularly is specificity. This is the part that they’re thinking about in the cascade, and it’s one out of eight or nine steps. But it’s the one that we think about the most. And in specificity, we have three layers. We’ve got IDs, which you’re only allowed to use once per page. They’re pretty powerful, but we can only use them once. That’s pretty limiting. And then we’ve got classes and attributes, which we can use over and over. We can rename them. So we have total flexibility, name them anything we want. We can use them anywhere we want. Total flexibility, just there. And then we have element names, types. A “p” for a paragraph or an “a” for an anchor link. And those, we can use them all over the page, but we don’t get to define them.Or we didn’t used to get to define them. Now there’s ways we could.
So in that, we have this whole cascade with all these different layering algorithms. And the one place where we work, the only thing that we have flexibility around is inside of one layer of specificity. And so what happens is we start fighting over how many classes and attributes we’re allowed to use in a selector. And it becomes, it feels dangerous to use too many. And so we get these naming conventions that insist we only use one. And then once we’re only using one class for every selector, then we have this problem where everything is based on source order. The last thing will always win. We have no other control besides that.
And then we start loading our pages, our CSS component-based using JavaScript frameworks. And those, they don’t know the order of the things. There’s this set of components. We’ll load the styles for that set of components. And our order gets out of whack. And so now we have lost all control of the cascade. We have no say. The browser’s just doing things. And so now we’re like, okay, the cascade is a problem. We need to make sure that there’s no conflicts between anything. We need to never touch the cascade.
And I looked at it and said the opposite. Well, what if the problem is that we don’t have enough control or we don’t have enough say in what we’re intending? What do we intend to override what? If we had more ways of saying that, maybe we could get around this. And the cascade already has origins, which is that the browser goes first and it lays down some defaults. And then users get to provide their preferences across the whole web. And then we come in and we override everybody. But that’s not how it’s supposed to work. We’re not supposed to be the final say. So then it goes backwards. The user gets to set important preferences that will override us. And then the browser gets to set important, basically things that are out of bounds. When the browser uses important, nobody could argue. So we’ve got this system of importance that gives us this balance of power.
So I went back to Jen and I said, I think what we would need is something like this. And Jen said, that’s a proposal for the working group. Here’s where you post it. I’m going to see if the working group will work on this. And that’s how I ended up in the working group, working on cascade layers, which are basically origins, but we control them. Within an origin we get to say what goes first and sets the defaults and what comes last and then we get to use importance to reverse that so if we’ve got defaults that should override everything we can set those and that’s where cascade layers came from.
[Bruce:] That’s extraordinary. How how long did it take from your initial idea to a relatively firmed-up spec?
[Mia:] It was from the first idea it was a year or so, year and a half, till we had a a decent spec and then I don’t remember when it started shipping I don’t remember if that was or 2023. I had proposed it early 2020 or late 2019. But from the point where we had a decent spec to it, shipping and browsers was very fast. And all the spec editors kept telling me, don’t expect this in the future. This is never going to happen for you again. Yeah, I was surprised how quick it went.
[Bruce:] My one experience of proposing something was the <picture> element in 2011. And I think it, and my proposal was rubbish. I mean, Tab and Simon Pieters and lots of people looked at it and rightly picked holes in it and came up with a much better, more sane proposal, that happened to still be called picture because they wouldn’t allow it to be called the Bruce element. But I think it was five years from the initial idea until it was shipping in browsers, which felt like an eternity.
[Mia:] Yeah. Well, and I started working on Scope around then, too. And Scope is just now starting to ship. And that’s one, actually, to go back to something you said earlier, that’s one where the working group tried to ship Scope in 2014 and felt like they got it wrong. And so this time around, there’s been a lot of caution. There’s been a lot of like, are we sure? Are we sure that this works this time? And that still keeps me up at night. Yeah.
[Bruce:] Well, yeah, because once it’s shipping on the web, you can’t take it out. It’s very, very hard. Because you can guarantee that somebody somewhere is using almost every weird combination of markup or styling. simply because it is a worldwide web with the 7 billion people on this marvelous blue orb of ours and more than 7 billion websites probably. Nobody’s counted. But yeah, the stuff that you’re proposing now will still be around in 100 years’ time. It’s kind of mind-boggling.
[Mia:] Yeah, if the web can survive that long.
[Bruce:] What makes you say that? What makes you worry?
[Mia:] Yeah. I mean, I guess it feels like there’s been a real vibe shift in the last year or two. I can point to “AI” maybe in all sorts of air quotes, And it feels like, you know, there are people who don’t seem to believe in the web I believe in, and they seem to have more money. And at least for me, the web is about that thing that the cascade comes out of, which is how do we let users set their preferences? So the initial browsers only had browser styles and user preferences. That’s it. No author styles. Because the user should have control over how things look. And they should get to choose their browser. And the browser should fit a device. So if you’re looking at something on a watch or you’re listening to it on a speaker, those should be different than if you’re looking at it on a desktop. And if you’re looking at it on a desktop with only one color, that should be different than if you’re looking at it on a color desktop. Right. So we’ve got all these different places that our content is going to go. How could we even imagine styling it? And so we didn’t. But there was some frustration from all sides that the web is boring if nobody can style it and if every website looks the same. So CSS, there were a rush of proposals. CSS wasn’t the only one. At that point, it was called CHSS, Cascading HTML Style Sheets. And the reason, as far as I can tell, the reason it won and became the final thing is because it helped answer this question. How do we make sure that users still have control and that browsers can still adapt our content to any device? How do we ensure that flexibility and also give ourselves an ability to style a thing and express some sort of, whether it’s artistic sentiment or brand continuity or whatever, express something and make the web more interesting. But let that all be stripped away. And the cascade answers that question. Here’s a way of determining who wins in what situations. and collaborating without ever talking to each other. And I think that’s a beautiful vision for what a web could be. It sort of builds in an idea of accessibility from the start, of like even if I ship something that is yellow on green, you have the ability as the user to say, No, thanks. Restyle this. Show me what it would look like with my own color. Show me what it looks like zoomed in. That’s the web I want. I don’t think it’s the web that big business necessarily wants. I don’t think it’s best for your brand consistency if people can come in and say no. So I see why there would be, I don’t know, interests in pushing something else. I don’t know.
[Bruce:] I remember years ago, I interviewed Håkon Wium Lie who, with Bert Bos, co-created CSS, and it was the 25th anniversary of the first official CSS proposal. And Håkon told me, I think I asked him, you know, what didn’t make it that you wish had? And he said there was some kind of percentage marker that said, you know, I only want this, I only really care about this 40%. So if the user cares about it 60%, they win. But it was too cumbersome a UI for the time to allow each different effectively knob and lever of CSS to be changed by the user. But it’s a fascinating idea.
[Mia:] Yeah, it’s what became importance. But it was a percentage value. The weirder thing was it wasn’t just that if I say 40% and the user says 60%, they win. It was that then we, and I love this and also can’t imagine it working but I also really want it: We would then merge the two values and get a weighted average.
[Bruce:] Yeah, that’s it.
[Mia:] Right. So if I wanted blue and they wanted red, we would then have to find something that is 40 to 60 percent balance there between those two colors, which is absurd. But as an artist, that is absurd in a beautiful way. I love that.
[Bruce:] It’s interesting you say as an artist, because somewhere on your site, you say, “I hope to create art and software that celebrates the queerness of human experience”. Can you talk to that for a few minutes?
[Mia:] Yeah, I think that’s what drew me to the web was this sense to me of like, I was studying theater. That’s what I studied in college, theater and creative writing. And I was thinking a lot about a difference between theater that tries to make you feel, make everybody in the audience feel the same things at the same time. which, you know, we can think of, there are some movies that are great at that. We all cry at the same point, right?
[Bruce:] Dumbo, and Bambi.
[Mia:] yeah. We all feel it. We all have the same shared experience. And that’s interesting, but what if we made theatre that gives all of us sort of different experiences and then we have to talk about them? And it’s giving us different associations. And I don’t know. I think there’s something really interesting in that. And that’s sort of the, the field that I was coming out of was thinking about how do I make, how do I make theater that lets everybody feel a little bit different? And then we have to talk about it. and there’s some, there’s some queerness in that. I was reading queer theory at the same time, right. sort of an idea that like, well, there’s not, there’s not one normal universal thing that then people deviate from. There’s just lots of people. and we all have, there are things that are similar about us, but a lot of what we share is being different and unique in a variety of ways that overlap, and having different experiences. And could we make art that respects those differences and, and somehow builds on them? So then, when I started playing with the web, and I started playing with the web because my theater needed a site. and I asked my brother if he would build it and he said, no, but I’ll show you how. And he, he was sort of like, I think you’ll find the CSS thing. Interesting. It’s sort of a new thing. but there are some people writing about it. I started reading your stuff. I started reading Eric Meyers and Estelle and all sorts of people. and I got really into, especially Eric Meyers Edge site. This was early two thousands. He was doing such weird, wacky experiments with CSS. and I was into the semantics and the sort of declarative language. It was all, I had, my brother was a programmer, so I had like dabbled with like, what’s this programming thing? And I always went away being like, I don’t, it’s not, it’s not for my mind. I’m, I’m an artist, I’m visual, I’m associative. And CSS felt like that to me. It was like visual and associative. Those are the things that does. So yeah, I got interested in a web that maybe could do the same thing I was trying to do with theater, could be different for different people. Everybody sees something slightly different and that’s okay. and that’s part of the art that we can make on the web is letting people see different things and have different experiences. and let that be part of it, not a flaw in it.
[Bruce:] I’d never thought of it that way. Brechtian-Queer CSS.
[Mia:] Yeah. Brechtian CSS. I love it.
[Bruce:] I studied English Literature and Drama at university as well. It’s funny, actually, how many of particularly my generation of people on the web who had studied, and possibly had a career before the web, actually came from the arts. Zeldman was a bass player, ppk was a bassist, I was a theater actor director musician it’s bizarre.
[Mia:] yeah, Rachel Andrew’s from theater, Jen was from theater.
[Bruce:] i didn’t know jen was from theater
[Mia:] yeah yeah, Jen did theater tech. I remember being at a conference once this was probably in the 2010s and somebody asked how many in the audience had a computer science degree and a couple hands went up. And then they said how many of you have a music degree and half the room raised their hand. And i thought that was great, i think especially with music there’s something about making art for math or or something. There’s a tight relationship there.
[Bruce:] Yeah. Speaking of somebody for whom music is my primary hobby, I find it a blend of art and science, the relationship between the frequencies of chords that sound nice and not, etc. The rhythms that stimulate or soothe, etc. We’ll have to set up another podcast to talk about Brechtian Queer musical CSS.
[Mia:] Yeah, I’m also a bass player. So now I’m curious if most of the web plays bass.
[Bruce:] A lot do. The guy who helps me with my music is the old bassist from my high school band. And I used to mock him for playing bass because he’s only got four strings and you only play one note at a time. Until I tried to play bass, and it’s really bloody hard, really hard. Never mock a bassist again.
It’s weird because you’re sounding, I mean, yeah, your background isn’t, your education isn’t techie, but you’re evidently deeply, deeply technically minded. And yet you describe yourself as a “Web Luddite”. I believe a lot of people misunderstand what the Luddites were actually about. But could you just briefly explain (because I know we’ve nearly used all our allocated time) what is a web Luddite and why are you one?
[Mia:] Well, I don’t know. I put the two words together because I’m a Luddite and I like the web. The Luddites, and I am not an expert, I’m not a historian, but I’m fascinated by the Luddites because they were a labor movement. They were sort of a unionization against factories trying to replace them with weaving machines, stockinets. And they didn’t, they weren’t against the technology. They used the technology, but they were often working from home on their own schedules, learning a craft, developing their craft, building a livelihood for their families out of their craft. And then the factory started to replace them with something cheaper and less crafted and put them out of work. And they did not break all machines. They broke machines at factories that were cutting their wages and laying them off and trying to replace them. They said, no, we get to keep our livelihoods. You don’t get to replace us with something worse. And we’re going to fight back. And, you know, on some scales, they won some fights. They convinced some factory owners to give them their jobs back, let them keep working, let them keep their wages.
Overall, though, the government sided with factories and tried to put down the Luddites, often sending in military and executing Luddites or suspected Luddites. So that’s the movement that I’m looking at. And I’m looking around right now and I’m saying there’s a lot of big companies that want to destroy craft and lower our wages, lay us all off. And I look around at that and say, I want to break your machines. That’s what I want. And that’s a difficult position to be in when you also have a career that is client-based.
[Bruce:] I completely agree with you. And I’m from the UK, of course, where the Luddites were either started or were most active. Yeah, they didn’t hate technology. They hated technology that hated humanity. I suppose the way I’d describe it. And it’s all deeply political, which brings me to the last question I want to ask you (simply because I’ve taken up loads of your time). You recently wrote a really eye-opening blog post on how tech is still political. Why now? Why does that need saying now? Why did you say it?
[Mia:] Well, I live in the U.S. and if we are to believe the Executive Orders coming from the current administration, my life is becoming illegal. I am losing my rights. I’m a trans woman in the U.S. and I am being declared fraudulent. I am being declared a threat. And I look around and it seems to me like we built the infrastructure for this administration and the tech industry broadly.
And there are ways in which I never wanted to be in tech. I wanted to build some websites. But also, I understand that this is, I don’t know, that we are somehow an industry or something. And that the billionaires today, the oligarchs today are coming out of our field and they are intentionally building technology that is against humanity. They are the ones trying to put us out of work. They have a clear right-wing bias that they are explicit about. They say it in all of their materials. I mean, when you read Andreessen’s manifestos, it’s all pure capital and anti-human, in my view.
And all of the tech companies are circling their wagons around Trump. And it doesn’t seem to me that we can separate the art from the artist when they are building the tools actively that are being weaponized against us. And they’re weaponizing AI as a tool in government against people. And all of these tools, I think it feels absurd to me to say the tools that they are building and they are telling us are right-wing tools with a right-wing vision that are going to put us down, that we would look at those and say, well, how much time can it save me as I’m writing my CSS code? Can it do a few of the keystrokes for me? Is that good enough? Does it work? I don’t know. I just can’t do that.
I’m being made illegal, and AI is being used as part of that project, and it’s being developed by those people. how am I supposed to look at it and say, well, it’s probably not political. It’s just a tool. It’s just like a hammer. Just happens to be a hammer that they’re pointing at me.
[Bruce:] I hear you. I hear you. I just wish there’s something I could practically do. But hopefully people will listen to this. And, of course, in the show notes, I will link to all the blog posts I’ve mentioned, and all of the specs I’ve mentioned, and people will be able to spread the words as they see fit. Oh, I’m sorry to have ended on a bit of a downer.
[Mia:] Well, if you’ve got any more, I’ve got a few more minutes if you need.
[Bruce:] I’m good. Thank you, Mia. Thank you for all the work that you do. It’s really appreciated. You know that.
[Mia:] Thank you, too. I loved HTML5 Doctor back in the day. I appreciate what you’ve done for this open web, and I hope we can all pick up the great Hammer Enoch together and break the machines.
[Bruce:] Perfect. Miriam Suzanne, thank you very much for being our guest. And thank you very much again for all that you do on the web, and off.
[Mia:] Yeah.
[Bruce:] See you next time, listeners and viewer. And thank you for being here.
Show notes
- Miriam’s website
- Miriam on Mastodon: @mia
- Miriam’s work website: OddBird
- Cascading HTML style sheets (original proposal)
- CSS Container Queries spec
- CSS Mixins and Functions spec
- Cascade Layers spec
- @Scope spec (Working Draft)
- Choosing a Masonry Syntax in CSS
- Tech continues to be political
You can donate to support Miriam’s independent contributions at OddBird open source.