EPISODE 1644

[INTRODUCTION]

[0:00:00] ANNOUNCER: CSS or Cascading Style Sheets, is a fundamental technology and web development that defines the presentation and layout of HTML documents. It serves as a styling language that allows developers to control the appearance of web pages. Rachel Andrew is a staff technical writer on the Google Chrome team. Before that, she worked for Mozilla and was also the editor-in-chief at Smashing Magazine. She is a member of the CSS Working Group, the Web Standards Project, and Open Web Docs. Rachel is our guest today. 

This episode is hostel by Josh Goldberg, an independent, full-time open-source developer. Josh works on projects in the TypeScript ecosystem. Most notably, TypeScritp-ESLint, the tooling that enables ESLint and Prettier to run on TypeScript code. josh is also the author of the O'Reilly Learning TypeScript book, a Microsoft MVP for developer technologies and a live code streamer on Twitch. Find Josh on Bluesky, Mastodon, Twitter, Twitch, YouTube, and dot-com as Joshua K. Goldberg

[INTERVIEW]

[0:01:16] JKG: With me here is Rachel Andrew. Rachel, welcome to Software Engineering Daily. How's it going? 

[0:01:21] RA: Hi, yes. Very good. I'm pleased to be here.

[0:01:24] JKG: Well, thanks for joining us. Could you give us a quick introduction? Who are you and what do you do?

[0:01:28] RA: Yes, I'm Rich Andrew. I currently work for Google on the Chrome team. I'm the content lead for Chrome Developer Relations, which means that I run a team of writers and we look after the website's web.dev and developer.chrome.com. I'm also a member of the CSS Working Group. I've been involved with CSS for a very, very long time, and generally the sort of open web platform.

[0:01:50] JKG: Well, thank you for all the work you've done on CSS. It's gotten quite a few new features over the last decade or two. How do you feel about the language and its direction?

[0:01:58] RA: Yes. I think it's really exciting, especially at the moment, there's so much new stuff happening. A lot of the problems that developers have had for years kind of just getting solved, which I think is super exciting. There's a ton of stuff that, maybe sort of five to 10 years ago, we thought it wasn't actually going to be possible. It's now becoming possible, and that it's really exciting. It's great to be able to sort of give that stuff to developers and then see what they want to do with it.

[0:02:23] JKG: Yes, absolutely. The explosion of the web has been continual and fantastic for quite some time now. Before we dive into that, I'd love to get to know you a little bit. Can you tell us how did you get started programming?

[0:02:34] RA: It's a very long time ago. I kind of come from the dawn of time of the web, really. I originally trained as a dancer, and went to work in the theater. I'm eventually going backstage as a theater carpenter in the West End. Then, I got pregnant with my daughter. You can't really be climbing ladders and things once pregnant. I decided, because I didn't - I left school at 16 to go and dance, so I didn't really have any useful skills. Other than, I'm old enough to be of the generation where girls learned how to type, so I could type. I thought, well, if I get a word processor, I can take in typing. I was upsold to a computer by somebody in PC World, who was like, "Oh, no. You really want a computer." So I got the thing on the internet.

I discovered just the resources and the fact that as someone who was about to have a baby and knew nothing about babies, I could find out communities, and help, and learn from people. Because there was no way to share anything at that point, there was no Facebook, or Flickr, or anywhere to put anything, you had to build a website. So these parenting forums were full of people swapping parenting tips, and also swapping website tips. Like sharing images, and graphics on these websites. I basically taught myself, and then I started teaching other people, because I would learn things that go in the forums, and I'd explain how I'd done it. That's really how both my - I got my start as a web developer, but also how I got my start as someone who writes about the web. Because really, as soon as I started learning, I started teaching it to other people. That's kind of what I've just done, really, all of my career, has been - I've learned something interesting. I've thought, "Oh, that's cool" and then I've written it up for somebody else. I'm still doing that, really. That's really how it started and how it kind of carried on.

[0:04:21] JKG: Have you always been a teacher even before you got into programming, in a sense?

[0:04:26] RA: Well, I do have a dance teaching certificate, but I was a terrible ballet teacher. I mean, what they do with you when you have a sort of a young dancer, that will get you through your teaching qualifications thinking, "Well, that's something you can do, to fall back on." But I was really, I was an awful teacher of children. It was like crowd control anyway, and I wasn't very good at it. But I did back then - the other thing I do is I used to teach adults tap classes. I mean, I was 16, and I would teach. I enjoyed that far more and that kind. I think I do enjoy teaching. I maybe just didn't enjoy teaching five-year-olds.

[0:05:05] JKG: Yes, five-year-olds are a little bit different from adults in many ways. But there are some similarities between teaching adults programming and teaching five-year-olds anything. Do you think that developers these days have a different mindset coming into how to learn to program than they did in the glory days of the old internet?

[0:05:22] RA: I think it's just the expectations of what you want to create are very different. I mean, when I started, it was pre-CSS. I started in like ninety-six. Well, CSS sort of came out in ninety-six. There were no browsers at that point. Where the version three browsers came in very soon after I started. I3 was the first browser that supported any CSS. To build a website, you had HTML, and whatever you could do in a graphics editor. That was kind of it. So we were like chopping up images and things. There wasn't much, and you could learn what you needed to know. Within a day, I could build a website, because there was only a few HTML elements to know about, and you could do that. 

Now, when you look at a website, or web application, there's so much that is there that people just expect to be available. You've got to learn an awful lot, just to be able to do what appear to be fairly basic things. I think the difference is the assumptions have changed as to what you need to know. Also, there's just so much stuff. I mean, HTML, CSS, and JavaScript are still there, and you can obviously build a site using them. But most people aren't sitting down with Notepad, and building their website anymore. So then, there's the whole ecosystem to understand, and where you fit into it, and what you want to learn. There is a lot. There's a lot to note. I think it's difficult to be able to find a path through that. Whereas, there was really only one path when I started. And that was to open up Notepad and start writing HTML tags.

[0:06:54] JKG: Sure. If you were to get started again, today, is there a particular set of tools you think you'd jump to?

[0:06:59] RA: I think it is very important that people do learn the core things. I think it is important that people understand HTML, CSS, and JavaScript. I don't think that is a realistic starting point now. I think that really is better people to think what problems they want to solve, what do they want to do. I think, the quicker you can get someone making something that works, and get them excited about what they can do. If you're talking about an absolute beginner, that's the important thing. Make something that works, then be pleased with it. Be able to say, "Hey, I put that out there." Because that's what we were doing in the early days. 

I think, if you're then wanting to progress, that's when you want to start talking about, "Well, do I need to improve my JavaScript skills? Do I actually need to understand what's going on with HTML here? Because that's a core language. But I think, just to get started, build things, make things work, see what problems you run into, and how other people are solving them. Because otherwise, it's a very long path if you start with HTML, and start building up before you get something that works, and it's cool. Start with a cool thing, play around, and then figure out where you want to go, and learn the things you need to learn together.

[0:08:08] JKG: That makes a lot of sense. Let's continue. You got into tech and programming, you are on online forums. Then somehow, some number of years later, you ended up at Google. There's a larger gap there. Could you fill in a bit of that gap for us?

[0:08:20] RA: There's about a 21, 22-year gap. I did actually work for a short period of time in kind of dot-com companies very early on. I sort of taught myself all this stuff. I fairly quickly realized that I was a terrible designer, but I was quite good at programming. I taught myself Perl, pretty much while my daughter was a tiny baby. I taught myself Perl from the Camel Books. I taught myself Linux, because to actually do anything in those days, you had to be able to install and maintain Linux, and install Apache, and so on. I was reasonably good at that sort of stuff.

I really just managed to block my way into a job in a company, what was the Webmaster then. But actually turned out to be heading a personal technical team. I did that there and another company for a short time, and then, everything was becoming terrible, dot-com, company-wise. I decided I was probably safer off on my own and went freelance, and I was then freelance or running my own companies for 20 years. I started off doing mainly Perl sort of troubleshooting and things like that, because all these dot-com companies fire the developers, but still had large stuff that needed looking after, so I was doing a bunch of that. Ended up doing development work for design agencies.

Then, for 10 years, had a content management system product, which was like a sort of WordPress competitor called Perch, which was PHP and MySQL. I spent a long time as basically a PHP developer Throughout all of that, I carried on writing, doing CSS stuff, writing books, and became over time more of a writer than a developer. That was sort of just a transition, those getting offered writing contracts. Come and do this at our docs. I did a period as editor-in-chief of Smashing Magazine, and I was actually contracting as a writer for Google. They were like, "Do you not fancy actually applying for a job?" I like the team, I like the people, I like the work. You don't often get offered a writing job like this, and the opportunity to head up a writing team. So I thought, "Well, I'll give it a go." It's just over two years now. I've been there and really enjoying it.

[0:10:30] JKG: Yes. You have over 100 articles on Smashing Magazine. I want to call that out. Are there any in particular that you remember fondly or not as fondly, the process of writing?

[0:10:40] RA: I wrote tons of stuff, just breaking down CSS specs, and things like that for Smashing, there's a bunch of series. And there's a whole load of stuff there that I still link out to from things that I'm working on now. I'll be like, "Oh, I wrote this over here," and just link to it. I did a lot of content on CSS there. I think some of that sort of stood the test of time, I guess, as I still refer to it. So yes, I did quite a lot of writing. I was already writing for Smashing, and then I ended up being editor-in-chief for a couple of years, and sort of publishing other people's stuff as well.

[0:11:12] JKG: What is an editor-in-chief when comes to an online magazine?

[0:11:16] RA: I mean, generally, I mean, for Smashing, the articles, they don't have a writing team as it were. They get articles in from the community, and they pay for them. A lot of it was - and we also had a - I don't know how they operate now, but we also had a team of editors, technical editors, who would review stuff, who were also paid per article. A lot of it, really, was just wrangling that whole process, getting the articles in from people, also approaching people who were doing interesting stuff. Like I would see someone at a conference, for example, doing a really good talk. I dropped my line and say, "Hey, do you fancy writing for us on that subject? That was interesting."

t was doing that, really, and kind of curating the stuff that was going out. So it was, I mean, to some extent, it this, what I'm doing at Google with our sites. We're making sure that we have the relevant content that developers need. I think for any, that is true of anything, is you need to have that, that understanding of who the audience are, and the ability to find the writing, find the authors, and get the stuff through. 

[0:12:16] JKG: Yes. Another large number, you've written, according to your website, over 20 books. Do I have the number right? 

[0:12:23] RA: Yes. Yes.

[0:12:24] JKG: That's a lot of books.

[0:12:26] RA: It's a lot of books, a lot of words. Yes. Again, that started in 2000. I wrote a couple of chapters for a book. I mean, all this still amazes me. I'd say, I left school at 16, I have the sort of most basic of qualifications that - so when someone said, "You fancy writing a couple of chapters for a book?" I was like, "Okay, then. You can always not use it." But I think, sort of from there, I just built my confidence. You write a couple of chapters for this book [inaudible 0:12:57], and then I wrote entire books out of a fairly popular book on CSS that went to four editions. That people still turn up at conferences, where they asked me to sign these old copies of, which is wonderful. But yes, it just sort of happened.

I think, along the way, I've sort of improved the ability to sort of explain stuff. I think I've always been quite good at learning something and explaining it to other people. That's really what this kind of writing is about. It's just about being able to take something that's a bit complicated, and make it sort of explain it clearly to somebody else. I do think too a lot, it's because none of this was super easy for me to understand, because I didn't come from that background. I don't have a computer science degree. I've had to figure everything out. Because of that, I think I kind of still get where people might struggle if they haven't got a big programming background, and they're trying to do something. I think it's actually been quite helpful to me not coming from the sort of traditional route, I guess.

[0:13:55] JKG: Sure. It's funny, because as someone who came from the traditional background, the four-year computer science degree, I'd say, yes, there is an advantage to having a different viewpoint from those folks. I don't think there's any one particular viewpoint that's better or worse than other, but I think there are a lot of tradeoffs, right? Having that diversity of approach for some folks from boot camp, some from self-taught, some from university, you get a more broad range of what people can put into the learning materials, which is, I think, a better output.

[0:14:24] RA: Yes. I think it's great when you get people together. One of the nice things about being at Google, I mean, I was independent for a very long time. The nice thing about being at Google is that there are people there who have got a range of backgrounds, so it's interesting. I think I'd always assumed that everyone at Google was computer science degrees all the way. But actually, it's not the case. There is quite a wide range of experiences and the ways people got into doing what they're doing. They really sort of make very interesting conversations, because people then pull out the different things that they know, or the different viewpoints. I think it is really important to have that diversity. Because otherwise, you end up crafting everything for a certain type of person with a certain type of background. But if you've got people with different viewpoints, you're able to catch some of that stuff, and sort of catch those assumptions that you might make.

[0:15:13] JKG: Absolutely. Let's continue. You are independent for 20 some years. You wrote several books and several articles to put it lightly, and then you ended up at Google. You've been there, you mentioned, for the last two years or so. How is that going? How do you like it over there? You seem positive so far.

[0:15:30] RA: Yes. Yes. It's a great team. Actually, I'm part of DevRel. I run a writing team that's kind of embedded within DevRel. We get to do some interesting stuff. Obviously, we're supporting the Chrome releases, features that come through, things that are landing in Chrome. I'm very involved with the web Compass project. We've got this project called Baseline, which is sort of an effort to clarify the sort of state of the web platform. I think a problem that has been all the way through my career is just like people not knowing if something is safe to use in browsers that like, "Well, is this thing okay to use? What about old browsers? Is this going to work okay?" 

It's not actually that easy to - all of the information is out there. You can go to Caniuse, you can go to MDN, and you can look individually for features, are they supported. There's not really a good overview of this whole set of things are fine to use. You can just get on and use them. Most people can use these. That's what we're trying to clarify with baseline, is that you can just look and go, "Oh, right. This thing." CSS Grid, for example. That's in baseline, that's okay to use for most people. That's been a really sort of fun project to be involved with. Because, yes, I've battled with that myself when I was a working web developer. It's fun to be able to get involved with that stuff. Those are the sort of things you need to be part of a big team to do, to actually learn that sort of stuff, and have the cross browser content and so on that makes that possible.

[0:17:00] JKG: Let's dive a little bit into Baseline. Baseline, what exactly is the Baseline project then?

[0:17:05] RA: Essentially, what we're doing working with a - it's something that we initiated, it's now not really just a Google project. We've got a group, which is working on kind of grouping web features into, because seeing that MDN breaks down web features into individual properties, or methods, or whatever. With Grid, you can go and look up Grid template columns, and see what the browser support for that CSS property is. But that's not particularly useful. Because if you want to know, can I use CSS Grid, you need to know, can I use all of the things, and not just bits of it. The web features group, they're sort of grouping is kind of creating these sets of features that - so you can sort of have a look at the web platform that is like, if I want to use this thing, if I want to use container queries, or if I want to use, the pop-up element, or whatever it is, any of these things. All the bits you need are joined in one group. So that's part of it. 

Then, we're going to be able to sort of say, well, all of this is now part of Baseline. When things enter Baseline, is because they become interoperable, so they work in all browsers. We're sort of saying, well, then, you've got [inaudible 0:18:17] Baseline newly available, which means that you've got something, which become interoperable. There's a bunch of stuff this year. Container queries, for example, became interoperable this year. That will be part of Baseline. After - in fact, just in this last sort of week, we've redefined how we're talking about baseline to add an extra sort of point in time, which is what we're calling Baseline widely available. Because for most developers, things been interoperable, things been available all browsers is a good starting point, that's useful. But actually, you need to support browsers several versions back, and you need the feature to be generally available, say, in the mobile devices that people have. Which obviously, you have a different update, cadence typically to desktop.

We've set the widely available line at 30 months. Once it then becomes newly available, it becomes interoperable. The clock starts ticking after 30 months, we deem it to be widely available. At that point, the majority of developers can use it. Now, obviously, you need to look at your own analytics, and so on. You might work in an industry where people are locked to some really old version of browsers or whatever. But for most people, that's probably going to work. So yes, the idea is that you can display these badges anyway. You can have a feature, for example, you writing an article about container queries. You could say, well, this is Baseline, newly available, or this is Baseline, widely available after 30 months. 

People get this sort of understanding of what's available on the platform, and that you're not doing this thing, where you're - for example, reading an article thinking, "Oh, great, this solves all my problems. This is exactly what I need to know when you get halfway down, and they use something which is only in Chrome, or only in Firefox." And you're like, "Well, that's -" you just use it. That's the drawing board. I think, having that clarity were really useful, because we've never really had that. We've always had to look up things on a property-by-property basis.

That's kind of where we're going. We're not fully there yet. The working group is having to map all these features. But hopefully, during the course of next year, we'll have pretty much all of the platform mapped out into feature groupings, and where it actually sits, whether it's in or out of Baseline. This has been rolled out on MDN, and we're running on our sites, and we hope to see in other places soon.

[0:20:39] JKG: Are there other major documentation sites that folks use, in addition to web.dev and MDN, that you're particularly looking forward to?

[0:20:47] RA: They're kind of the big ones, obviously. Caniuse is important for sort of status. But anywhere, could use - one of the things you want to do is create the ability for people to query the feature grouping and display stuff automatically. Have you noticed sort of JavaScript badge, so you could sort of say, "This article is using CSS Grid and retainer queries." And you can query, and then display a badge automatically based on that, which they would then, other places, or even just people's individual blogs could actually start to show the baseline status as they go along.

[0:21:18] JKG: It's interesting. In the JavaScript land, we have these very nice delineated ES20X layers, such as ES2020 that we can rely on. I've heard rumblings of larger sites starting to try to dynamically serve the right JavaScript. Let's say, if you're viewing on Chrome 20 months ago, you'll get a slightly older, larger builds that Chrome - yesterday's release. Do you see there being a future web, the baseline is some kind of programmatic API that sites can use to serve Polly or polyfill properties. Would that make sense in an HTML CSS world? 

[0:21:52] RA: It's very, very difficult to polyfill CSS, in general. We actually did look into this. We spent quite a lot of time looking into whether we could have a version of Baseline that included polyfills. But it turns out that you can't really very easily polyfill most CSS, just because performance-wise, if you start trying to polyfill layout, it all typically goes horribly wrong really quickly. I mean, like container queries, you could use JavaScript to do one thing on your page, maybe. But if you use that same JavaScript on 20 things on your page, it's going to be very, very bad in terms of performance. It's difficult to be able to give that kind of, "Oh, yes, you're fine to use this. Just dump this script in, and you'll be fine." Because actually, for most CSS, you won't be. You have to be a little bit more sort of selective about doing if you do it at all.

So yes, it doesn't make so much sense. I think a lot of this really is about clarity. I think there's a lot of opportunity for tooling. The sort of developer tools and so on that people use, been able to highlight the status of stuff people are using. I mean, like some toolings already, pulling in the browser compact data that MDN has to sort of show the status of individual properties. It'd be quite nice to be able to show that as sort of a collection. But yes, I think there's lots of opportunities.

[0:23:12] JKG: Yes, like a little squiggly in the editor.

[0:23:14] RA: Yes, exactly. I think, once we've got the whole feature set mapped, the [inaudible 0:23:20] are doing, I think, after we've got that, then there's lots more possibilities.

[0:23:26] JKG: I wonder, CSS has not the best of reputation amongst some circles of developers. Folks criticize it for being difficult to use, it's hard to center stuff. For the large part, those criticisms have not been valid for quite a few years. For example, centering stuff may have been difficult when you and I each got started, but it is no longer something that does not have native built-in support for CSS. Do you think that some of that perception comes from the difficulty in polyfilling or Ponyfilling new features in CSS?

[0:23:53] RA: Maybe. I think it's just that CSS itself is just - it's an unusual language. It's not like other things that people know, but I've learned a number of scripting and programming languages over the years. I tend not to have too much trouble hopping between one another. Because once you've learned [inaudible 0:24:12]. But CSS is completely different to anything else. I think part of the reputation is just that it doesn't behave like people expect. Yes, you can't so easily sort of fall back, or, I mean, we've got some - with things like feature queries, support, you can actually now start to fork things within your CSS to say, "I've got support" or "I haven't got support." But that wasn't possible for a long time. I think part of the reputation is just that it doesn't behave like other languages people are using, whatever it was at the time. Yes, I think that's probably most of it.

Also, just sort of every time a new generation of developers comes along, where they become further away from the history of how it got started. So there are things in CSS that seem really, really weird, because we can't actually break the web, we can't go and rewrite how the language works. So we've got a language that really came from making small formatting tweaks, documents. CSS didn't have an inner built sort of actual layout until Grid came along. There was no way to really do layout, which sort of hacked around with [inaudible 0:25:18] to make that happen. It wasn't really designed for it. 

All of these decisions, if you don't know the history seem really weird. Why is this like that? I think, yes, as people come - for those who are doing it for a long time, and sort of understand the history, and understand what's been layered on top of. But if you're new coming to this, I think it seems very, very strange, I'm sure. Because it's - these things we can add to CSS to make it more straightforward. But the weirdness still lives somewhere in there, because we can't take it away without breaking lots of sites.

[0:25:55] JKG: Well, let's play a hypothetical. Suppose I'm a no JS developer. So as close to CSS and HTML as you can get, and that I know JavaScript, but I've never actually done Visual UI, or HTML, or even CSS before. How would you explain that language to me if I were just getting started and asking you for help conceptualizing all this stuff?

[0:26:13] RA: Oh, that's a good one. I think you're talking about a language that lets you suggest a lot of the time how you want things to be. I think that's the big difference, is that everything in CSS is to some extent a suggestion, because you don't know exactly what the thing someone is looking at is. You don't know what shape it is, and you don't know, what they're going to sort of do with it. I think that is probably the key thing. It's like with CSS, you don't have full control of what anyone sees. I think if you go from that point of view, and sort of build up from well, what is the most basic thing that I want people to see. I want people to see nice typography, because that's going to make everything readable. Well, let's do that. Because everyone's going to get that nice typography.

Then you're building on that and saying, "Well, okay. This user's got a much bigger screen, so how can we make use of that with the suggestions to the browser?" I think if you think of it that way, rather than - I think what people have tried to do for a very long time, because we all came from thinking of web pages a bit like something is printed, and we're trying to recreate it. If you go from, well, let's - we want to sort of suggest things to the browser, and then build on that, depending on what people have got available, as opposed to having an idea of a rectangle, and where things fit in the rectangle and trying to force that to happen. I think you'll have an easier time of it. I think that's more the way to think about it in a sort of a modern way, and not coming from a graphic design viewpoint, is that you are offering suggestions to the browser. Most of the time, these days, those suggestions actually will get used. But you still don't know everything about what the environment is being viewed in.

[0:28:05] JKG: Isn't that a little terrifying, though, especially as someone like you who's had work in IT, or at Linux administration, where you've gotten used to that complete level of control to just let the browser do whatever it wants with your suggestions?

[0:28:17] RA: I mean, yes and no, because I think it's actually more terrifying to be under the impression that you can actually fix everything. Everything is going to be exactly as you imagined it. Now, I think back in the day, when responsive design first became a thing, everyone started doing three versions of their site. They'd be like, "All right. Well, I've got my desktop for big screens. I've got this sort of middling version, and then I've got a little narrow, skinny version. Then, people started showing those pictures of how many different devices there were, and how many different breakpoints that actually resulted in. And realize that those three breakpoints just left plenty of devices with a really weird display because they were kind of too wide, or too narrow, or whatever.

Yes. I think a sort of a modern way to look at it is to kind of go from, what is the basic thing we want people to see, and then how do we take advantage of the fact that all these devices have got amazing capabilities now, and so we can actually start to take advantage of those capabilities, where they're available. Because then, also, we can now do things like detect if somebody prefers to have dark mode, or if they prefer less animation. There's all these things that we can actually look for and respond to in our designs. When we're talking about those suggestion as well, it could be a suggestion that is knocked back because of user preference. You've done a great animation, but the person looking at it, it feels ill if they see all that animation, and so they've said, "Please don't show it to me." And so, you don't get it. 

I think if you have this approach of anything there might not happen. Here's a bit like, it is all a bit sort of chaos monkey. At any point, something could get pulled out. But I think that if you're building in that way, then it doesn't matter if things get pulled out. If that's not there, it should still work.

[0:30:06] JKG: That's a beautiful way of putting it. Well, we're intentionally chaos monkey ourselves with CSS and browsers, because we know it'll be a better result.

[0:30:15] RA: Yes. I think it's easier as well if you work in components. The nice thing about working in components is, you only have to worry about what that thing does. What does that small element do without CSS? What does it do if you don't have the animation? What does it do if you don't have room for the layout? And then, all those components eventually build up to make a hole. I think it's a lot easier thinking components, especially now, we've got things like container queries, obviously, has -which is about to land in Firefox, which will make that interoperable, which lets you, from the parent, detect what's inside. So you can say, does this thing have an image? If so, do this layout. If it doesn't have an image, do something different. 

We're getting all these abilities to actually detect a lot more what we've actually got in there, which, for most of us are working with [inaudible 0:31:08] systems, or something that's injecting stuff into the content. I think that's going to make it a lot easier. So there's lots of ways in which we can be working with the content we've got, and the sort of external environment that the page is in. It's really exciting, and I think we are just figuring out how we're going to do that as an industry.

[0:31:28] JKG: This is a new term for the conversation. Could I ask you to define what is thinking in components, and why is that such a commonly recommended practice amongst the HTML, CSS, JS stack?

[0:31:38] RA: Most designs break down into a set of components. You typically have, what people often call a major object, which is sort of a box with an image on one side and text on the other. Now, those things appear everywhere. It might be - it's an icon and text, or video and text. But that sort of pattern appears all over the place. So if you can build that once, and then drop it in around your design, where you then you get to reuse all of the markup, and CSS, and all the thinking around it. That was very difficult until we had container queries, because you couldn't know just at the size at viewpoint, you couldn't detect the size of the area you'd put a thing in. But now, we've got container queries. That makes that a lot more possible.

A lot of the time, people are now developing sort of pattern libraries, and sort of reusable chunks of content, and CSS, then able to drop around. Because obviously, reusing stuff makes sense, because you don't end up with sort of weird, slight differences, because people - you've got a design that someone's made, that everybody's reinterpreting it around the site, and it sort of slowly drifts into something different. So yes, that sort of idea of developing reusable components is, I think, over the last few years, pretty much it is how people are designing things. CSS has evolved to a point where it is really supporting that, because for a long time, what people were having to do is kind of put classes on stuff. Like, "Oh, this has got an image." You'd put image, as you know, so that you could then detect. But now with has, you can sort of avoid doing that. So yes, I think that's definitely a way we're moving forward. I feel it does simplify a lot because you're never thinking, "Oh. You used to load a page, and it's all broken in some browser. 

If you're dealing with individual components, it's a lot more. If you've got a broken component, it's probably just one thing. You've already got essentially reduced testcase there. It's just that one thing to figure out what's broken, and it's not kind of so overwhelming. I mean, in the past, designers have opened things up in like an IE6. It's just all blown apart. It's like, "Where do I even start?" That's never good.

[0:33:48] JKG: Yes, trying to open a modern web page, and an old browser such as IE6 is a form of art. You got to see the most abstract reinterpretations of website.

[0:33:57] RA: We talk about support and saying, with Baseline, I've been thinking about a lot. But the platform today is so much more solid than it was. You think 10 years ago, we don't have these huge showstoppers. We don't have browsers that are miscalculating the width of things compared to another browser. I mean, I think, generally, the platform has evolved and has become a lot more sort of stable, compliant with specifications and so on than it was.

[0:34:27] JKG: Yes. I'd love to end one last large section of our interview, talking about that evolution of the platform. If you'll permit me, I'd like to ask you three questions. One about long ago, your favorite or most excited CSS feature you remember landing? One recently, last, say five, 10 years, and then upcoming. For each of those, what's the CSS feature you're particularly excited about or remember being excited? Let's start with the oldest one. Do you remember the first time you got excited that, "Oh my gosh, this CSS thing is going to land. It's going to make everything better in some way"?

[0:34:59] RA: Right back in the day when it became possible to use CSS for layout at all. I guess it wasn't so much - I think it was more that Netscape 4 went away. Once we sort of figured out, I mean, if you look at the very early CSS layouts, we're pretty much either - you sort of using absolute positioning to dump and navigation menu in a column that you create with a big margin, or the beginnings of using floats to do kind of three column layouts and what have you. The big problem there was Netscape 4. The reason being that Netscape 4, if you use any positioning, and you resize your browser window, it would lose all the positioning information, stack everything up top left, which was obviously something of a showstopper. That was kind of the thing. We could do it. Obviously, you have people who haven't been fairly simple design to do CSS layout, but really until Netscape 4 disappeared, it wasn't - unless you're very, very careful, it wasn't really possible. I think CSS layout becoming possible at all was probably the big thing. I've been sort of involved in interest in layout sort of since then.

[0:36:10] JKG: You have at least two posts that I could find on your long-time blog, talking about table this layout, or using CSS without tables, what and why. Could you, for the newer folks in the audience, newer than 10 years, let's say. Explain what is table layout in CSS and why do we shudder at the thought of it?

[0:36:29] RA: Well, I mean, originally, everyone was laying things out with nested HTML tables, and would literally just - and in fact, graphics editors would do this for you. You take a design, you chop it up into little pieces, and then you'd use nested tables to reassemble it. That was how we did web design. It was terrible for lots of reasons. I mean, the reason everyone used Dreamweaver was because Dreamweaver would sort this out for you, and stop you from having to calculate these nested tables on your own. We're all using Dreamweaver, and we're all doing these nested tables. Of course, they completely broke up the document. So things would become, from an accessibility point of view, completely unreadable. Because everything was just put into different table cells to make the design. 

That was really the big driving force behind using CSS for layout, was that you would be able to keep your document in a sensible order, and then do layout with CSS. Rather than create a gnarly structure, and then stick your content into it. I mean, it was a bit like, if you try and do a design, an Excel spreadsheet, that's basically what we were doing. Yes, so it wasn't great.

[0:37:40] JKG: It wasn't great. Yes. All right. Let's move on. Through the era of CSS from transitions in Flex and Grid, all becoming mainstream standard usable things. I'm going to say, other than Grid, since you've mentioned it a few points now, was there a CSS feature you remember being particularly excited or enthusiastic about?

[0:37:58] RA: Yes. Let's not talk about Grid. Everyone knows that that's my favorite feature. But I think container queries, purely because it was something that we thought wasn't possible. I think it just solves that huge problem. I like the stuff that solves big problems, and I liked the things that we thought we couldn't do, but now, we can, because there's quite a lot of them, and you sort of - but I think this is - people were asking for container queries. I found an article from a few months after responsive design became a thing. So really, as soon as we could do responsive design, people were saying, "But can we see how big this box is and respond to that?" Everyone would go, "No, you can't. It's terrible, it will just break everything, you can't do that." Because it kind of - you end up with a layout that has to figure out what's inside it before you can actually do the layout, and that's all very complicated. So didn't think it would be a thing. And I think the fact that now is a thing, and the fact that it obviously it's still early days, because it is, what we would now call it, newly available with Baseline. Give it a year or so when people feel confident to use it. I think that's going to make a huge difference for people. Although it's still a fairly recent thing, I think that is a huge game changer.

[0:39:11] JKG: For sure. Why is it people thought it was impossible for so long? And as a follow up, I will then ask you, why is it now thought to be and shown to be possible instead?

[0:39:22] RA: So it's one of those things where as things develop on the platform, we're constantly - we're adding all this stuff to CSS. Often, things can build on top of each other. Now, the problem with container queries is that the layout would rely on what was inside it. So you're sort of having to calculate that, and you can end up with a base of your loop, because then, you can change the size of what's inside it. That's all bad. We ended up with this concept of containment, which was originally done as a sort of performance thing. Because if you say contain size on an element, you're basically telling the brightest of a hint to the browser that you know how big it is and it's not going to change. 

So if you've got like a single page-app type thing, and you're changing all the content using JavaScript. If you've got elements that don't change, the browser doesn't have to repaint them, it doesn't have to figure, it doesn't worry about them again. It's like, that's just a thing, and we'll leave it alone. The container queries spec was built on top of this idea of containment. By being able to have single axis containment, because what people care about is essentially the width of the inline size. By sort of building on that containment spec to say, well, we can sort of figure out what that size is, that enabled the sort of spec to be developed. Originally, it was David Baron, who was at Mozilla, that's now at Google. He kind of came up with this idea of using containment. Then, Miriam Suzanne actually took on the work, and sort of figured out all the sort of details of it.

But we wouldn't have container crews without this initial concept of, well, we know how big a thing is. We can figure out how big that is, and calculate from there. It was really a case of the language developing features, which let us build on top of them, which didn't exist before. That's sort of, in short, how that occurred. I think that happens to lots of things. One thing starts to enable another.

[0:41:16] JKG: That's rather beautiful in a way.

[0:41:19] RA: I think what's interesting about the language, when you think, CSS isn't very old. Each of these new things that enables something else to happen. They also have people asking for new things. Because once people can see, oh, it's possible to do this. It's like, well, what about this thing that we would like. So every new thing brings something else with it.

[0:41:39] JKG: Sure. CSS isn't old in the concept of human years. It's only been a few decades. But in terms of software, only a few decades is quite old. What folks I think you've mentioned don't realize is that, folks working on browsers have to contend not just with the standards, and specifications, legacy cruft, but also the implementation details. How much of your job is involved with figuring out what's impossible to do purely because one layout engine has tech debt or doesn't have tech debt?

[0:42:05] RA: Yes. I mean, that's definitely a thing. In the CSS working group, there were representatives from all of the browsers. So people who are actually browser engineers, I'm not a browser engineer, I write about these things, I can sort of read the code. I wouldn't be able to implement it myself. But we all know, it says written, but we have people who actually write that code, and know it very, very well. So, that's typically something that's asked. Because if we're creating a specification for something, there's no point having a spec if it can't be implemented. That's not - it's not going to go anywhere, because people want things to be available in all of the engines.

So yes, that's a question that comes up. If we do this, is this going to be possible, and people will look and figure that out. It might be different. It could be straightforward for one engine and really hard for another for some legacy reasons. Fairly recently, at Chrome, the rendering engine has been rewritten, the project called RenderingNG. There's some long posts on developer.chrome.com, which are really interesting if you're actually interested in the details of browser rendering engines. But that rewrite has enabled a bunch of things.

One of the things I care about is fragmentation, which is what happens when you break content into multical, for example. That's a spec I did. Or if you break content between pages. There's been a bunch of stuff in fragmentation that's been broken for a long time. It's been hard to control, like you don't end up with a heading at the end of a column, or boxes broken in unpleasant ways. Because of that rewrite, a lot of that's just been made possible. So yes, it's a big thing. We have to have things that can be implemented. There's no point. You could have a beautiful spec. But if it can't, it is not practically useful, then it is no good. 

[0:43:48] JKG: That's very true. That brings us to the last of the three questions. I'm so excited to ask this. Do you have a favorite feature and CSS you're working on now that you think will be ready within the next few years or decade?

[0:43:59] RA: I'm always very keen on the sort of the solving of problems, of things that are sort of consistent issues. One of the things I have been working on is this concept of reading order. Because we sort of have this problem with new layout, it's become very, very easy to break up the reading order, and sort of separate it from the visual order. What I mean by that, is if you have a Grid layout, and you can position things pretty much any way you like in Grid, so you can have the order of the things in the document, and you can just move them all around wherever you like. The problem then is, if you are someone who is navigating with the keyboard that you're tabbing around, you can end up kind of jumping around all over the place very, very easily. It's not so much a problem to someone say using a screen reader completely because the document order is what they're following, and it's fine. But anyone who is looking at the screen, and say, keyboard navigating, or using a screen reader, while I can also see the screen for whatever reason can get this very disjointed experience.

I think that the more we add these new layout methods, the worse it gets, because people are happily doing these things. They want to be able to do it. It's like, you might have a design, which works really well in the document order at one breakpoint, but another breakpoint, the ideal sort of visual order is different. That's something I've been quite keen to solve. I sort of made a proposal a little while ago, which kind of went through the working group process, and obviously got pulled apart by everybody, because that's what happens in the working group, because there's lots of people who have opinions and who know different parts of the picture. It goes back to this kind of diversity of people. People have different parts of the picture and different bits of understanding. But we eventually sort of got that through, and there was a resolution at TPAC, which I think gives us a way forward, which essentially gives us an ability to set the reading order of the elements within the layout.

So if your visual order is different to the DOM order, you will be able to set that, and basically ask the browser to follow, for instance, the Grid layout, rather than following the document. So we think that will probably work. There's obviously a bit of work to do, and then we'll have to try and get that actually implemented in browsers to see if it really works well. Obviously, then thing that has accessibility implications, there's a lot of a lot of checking to do there to make sure it really works well. I'm really hopeful that we can solve the problem. Also, that would open up a lot of this stuff that at the moment, we have to tell people not to do. You just have to basically say to people that, "You can't mess about with the display order away from the DOM order, because you're going to make this weird thing happen." It'd be really nice to be able to say to people, "Yes, you can do this, as long as you're careful, and you use this property, and so on." I think that's quite exciting. It'll open up more possibilities to people who really care about accessibility, but also wants us to do certain things.

[0:46:55] JKG: Yes, I've in the past been told or figured out. Yes, we just can't do it this way, some different solutions, such as having two versions of the HTML page, that CSS visibility on or off, or other shenanigans. This is really exciting. Out of curiosity, the term reading order, that's a great, great way to refer to what it's trying to do. How difficult was it to get to that term as what's being used?

[0:47:18] RA: Right. That wasn't my idea. That came from the group, because I'd been talking about the visual order, which I think - and we've talked about that for quite a while. Being the visual order, as opposed to the DOM order. But actually, reading order makes a lot more sense. Because actually, you do want it. If you're changing the order of it, you actually want everyone to follow that. It's the reading order of the document. I think that's a good example of, why the sort of the lengthy bike shedding that things go through in the working group, it gets you to a good place, because you get all of these opinions, and people pointing out problems, or people pointing out things that maybe make no sense if your first language isn't English. There's so much stuff that you can - you'd have to think about, naming stuff is really hard, and it's going to live for a long time in what we do.

I think from the outside, if you're looking at that process, you think these people don't like to talk to each other. But I think, ultimately, it gets to a good place. It can be a little frustrating at times. But I think, when you get something that works really well, by waiting, and talking about it, I think it's worth it. 

[0:48:25] JKG: Yes. In 10 years, we're going to be excited about using this excellently crafted property, and perhaps waiting an additional year for it would certainly have been worth it. When you think about dev tooling, the things that we're crafting, or rather, you're crafting now, you and yours, are going to be relevant for decades to come. That math changes compared to just writing something for a company that might be thrown away within the next few years.

[0:48:47] RA: Yes. I've worked as - I had a CMS for a long time, and I've worked on products, and a lot of working on the platform is like working on any product. You have people demanding all sorts of things that they'd like to see. You have to kind of figure out what the common use cases are. It's just that the kind of weight of doing it for the web platform is very different to doing it for a product. Just the fact that it's very difficult to take anything back once it's out there. Which, at least with the product, you can at some point say, "Right, you've got to upgrade to version three. We can't do that on the web."

[0:49:20] JKG: That's a great ending point. Do you have the time for us to chat a little bit about wacky random questions at the very end? 

[0:49:26] RA: Yes. Okay.

[0:49:28] JKG: Excellent. Who is Mr. Peeps?

[0:49:33] RA: Mr. Peeps is my parents' parrot. I think he's fairly well known in Troy, New York, which is where my parents live. My mother carries him around in a backpack, and he likes to go to music events. He likes to go to the farmers' market. I think they play music there. Yes, he's a green, I think a Senegal parrot.

[0:49:52] JKG: That's a beautiful specie. I also want to give a quick shout out, since you just shout out at the Troy farmers' market, which is excellent. I also want to shout out Mudaddy Flats, which is the first and only quesadillary that I've ever been to, and it is a staple of downtown Troy. Great place. But okay, so I pored through your blog, you've got quite a few posts there. Although many or most of them are CSS. You've got some Jensen there. You ran a marathon in 2014. Can you talk a little bit about that? 

[0:50:17] RA: Yes. I did a few marathons. The land marathon in 2014 was my first. I was supposed to do it in 2013. On a training run, I slipped and completely shattered my right elbow. I had to divert the first to next year. The most notable thing about running that marathon in 2014, was that I actually managed to do it. Because I spent an awful lot of the previous year having my arm put back together. So yes, running is dangerous. I do recommend it, I love it, but yes, don't fall, and don't run in the snow. Don't run in the snow, which is probably the best thing.

[0:50:53] JKG: All right. Final question that I wanted to ask. There may or may not in any given year be a tradition of different browser or platform teams send each other gifts for major releases. Are there any particular gifts that you remember being sent or that you remember sending cross browser team that spark joy for you?

[0:51:10] RA: This has happened. I haven't been involved with this. I think it was - I've certainly seen pictures. I think this is sort of an earlier on thing. I'm not sure if it still happens. I don't know. I'd have to ask people at Chrome. I have heard tell of it. I have not experienced such myself.

[0:51:26] JKG: I think it's a wonderful tradition. I hope that the browser teams continue to do it.

[0:51:31] RA: I think that there's a lot more camaraderie between the different browsers than people might think. We work very closely together. The platform doesn't work unless we work together. So yes, I think some of these things, ultimately, we're all working to make the web better. And so, I think, yes, there's a lot of fun and camaraderie between the different people working on these browsers.

[0:51:54] JKG: That's such a beautiful, interesting thing. I want to hone in on that, actually, if you have a minute. Because in user land, there is a lot of competition, and sometimes even hostility, the Firefox people, and the Chrome people, and the Safari, and so on. But at the platform level, are you all friends? How does that work?

[0:52:09] RA: Generally, I mean, we're all working on the same sort of stuff. Obviously, every browser is a business. There are different business interests that work through, and that do impact the browsers themselves. But in general, and particularly in things like CSS, the real core technologies, we need to work together. And increasingly, we're doing so. Things like, the say, Baseline has got involvement from the other browser, and the Interrupt Project, which is fixing interrupt issues. It's all of the browsers working together to do that.

There is a lot of collaboration between everyone. And yes, as I say, in the working group, we have to figure out what's going to work across browsers, because it just doesn't work. It's not going to work out. So there's obviously things that each browser has taken it's sort of line on certain things. But then, when it comes to the core of the platform, there's a lot of people who just really care about the developer experience and making sure that we can actually build really great sites and applications, and are trying to figure out how best to do that.

[0:53:13] JKG: That's really lovely. I'm glad that that's the mentality rather than pure competition. I think you're right. Without knowing your decades of experience of CSS, I can already see why it would just wouldn't work if every browser went off and did its own thing.

[0:53:25] RA: Right. Yes. Yes. Well, that's all the questions we had for you. Thank you so much, Rachel. Is there anything else or any links you want to plug before we hang up today?

[0:53:33] RA: You can find me rachelandrew.co.uk. I'm @RachelAndrew in most places. I tend to post mostly on Mastodon these days, but you could find me around the place. And yes, always happy if people want to ping me and say hi. I'm always happy to chat about this stuff.

[0:53:49] JKG: Well, excellent. Well, thank you for chatting with us. This has been a real pleasure. Folks, this is Software Engineering Daily with Josh Goldberg. Have a great day. Bye.

[END]