Transcript
Joy Heron: Hello everyone, and welcome to a new Conversation about Software Engineering. Today on the CaSE Podcast I will be talking with Rachel Andrew. Rachel Andrew is the editor-in-chief of Smashing Magazine, an active member of the CSS Working Group, and co-founder of Perch CMS and Notist.
Joy Heron: She has given many talks and written many articles and books, and I'm absolutely thrilled to be able to talk with her today. Welcome to the show, Rachel.
Rachel Andrew: Hi, thank you for having me here.
Joy Heron: To begin with, you've done loads of things... I'd be really interested in knowing your journey, how you got to where you are today.
Rachel Andrew: It's been quite a long journey. I've been involved with the web for over 20 years at this point... So it goes back a long way. It wasn't ever something I was intending to do, partly because this didn't exist when I was at school, so I couldn't have had this in mind anyway... But I actually intended to go into the theater, so I trained as a dancer. Then I went backstage; I went backstage in London's West End for a couple of years, as a theater carpenter and so on.
Rachel Andrew: Then I got pregnant with my daughter, and having a baby doesn't really work when you have the unsociable hours of the theater... So I kind of ended up with a computer, because I was trying to figure out what I was going to do. I am old enough to have learned to touch-type at school, which is what they did with girls when I went to school; you learned to type.
Joy Heron: Oh, really?
Rachel Andrew: Yes... So I thought, "Well, I could take in typing for people. That's something I'm quite good at." So I was gonna get a word processor and I ended up with a computer and because of that I sort of started poking around with the internet and with the web, and sort of finding community there... Because I was a young mom, so I didn't really know any other mother -- all my friends were blokes who worked in the theater... So that was my driving force. At the time, if you wanted to put things online, you had to build a website, because there was no Facebook, or Flickr, or all these places to put things that we have now. So I learned HTML, and there wasn't even CSS at the time; there was just HTML, so I learned HTML in order to be able to share things about my daughter, and meet with my new friends online.
Rachel Andrew: So that's really where this started... And back then, if you learned a bit about HTML, you suddenly became a person who knew about websites. That was kind of like an important thing, because websites were new, and people were trying to build them for their businesses... So I just sort of fell into building other people websites.
Rachel Andrew: So just through this strange set of coincidences -- I think because I'm very structured in my thinking, and I like the idea of standards, and being able to read a spec, and then write HTML that would comply with that spec and it would work, I liked that idea... So when the Web Standards Project was starting to campaign for standard support in browsers and for developers to comply with standards, that just really spoke to me... So that was really the beginning of my involvement with the Web platform and with Web Standards - it was just seeming completely logical that we should have these standards, and browsers should care about them, and web developers should care about them, too.
Rachel Andrew: So that was really where it all started, was just me writing about the things I was learning, essentially, as I went along. And really, in terms of my career as someone who works on the web platform, that's really all I ever do. I learn something interesting, I kind of think "Oh, that might be handy for somebody else" and I write it up. I'm still doing that today; 20 years on, I'm still doing that. I'm still learning something, finding out about something, and writing that up for other people to help them understand it, too.
Joy Heron: Well, I do love your newsletter. You send out a newsletter I think every Tuesday evening?
Rachel Andrew: Yes, I send that every Tuesday.
Joy Heron: The articles you post, they're always very interesting; different topics, kind of going into depth on this little thing that is new, and I may not have seen before. We'll definitely link to your newsletter in the show notes.
Joy Heron: I find it interesting, you were talking about "Oh yeah, I got started on the web, and I fell into learning HTML", and then fast-forward you're here now, and you're still doing... You're doing loads of things now. You've founded two companies - is that correct?
Rachel Andrew: Yes, I've got two products. I've founded those with my husband, Drew McLellan. We have Perch, which is a CMS, and that's ten years old now. We've been doing that for a very long time... And also Notist, which is newer, and that is an application for public speakers; basically, a place to build your online portfolio. That really came about because I'm a public speaker, I do a lot of speaking, and I kind of wanted something that was like Notist. I wanted a way to build up that collection of not just the talks, but also all the other things that go along with them; the tweets that people make, and the resources, and the code... Notist lets you collect all that stuff together, and create a bit of a portfolio of yourself as a speaker, but also a good resource for anyone who went to your talk, or even who didn't; who just was following along online and thought "Oh, I'd like to see what this was like", they can go and see the slides, and maybe a video, and everything else.
Rachel Andrew: So those are the two products that we have... And they really came out of us working as a consultancy and building websites for the people. When I went freelance originally in 2001 - I've been working for myself since 2001 - I was just building websites for people. In fact, I was doing a lot of just troubleshooting for people, because at the time - this was just after the first dotcom crash, and a lot of companies had actually got rid of their web developers, but they still had stuff that needed fixing... And I like solving problems, and I've always been quite good at picking apart stuff that's going wrong, and fixing it up... So really for the first about three years I was a web developer, as a freelancer; that's really what I was doing. I was just working on other people's stuff.
Joy Heron: You probably learned a lot that way.
Rachel Andrew: Yes, you do learn a lot that way... Unpicking a mess. When you can see where the previous developer coded themselves into a corner and ran away screaming - that's kind of fun.
Joy Heron: And you know never go back there again?
Rachel Andrew: Yes, yes... So I did a lot of that. Working in Perl, and Classic ASP with VBScript, and then ultimately PHP. So really, I was mainly a backend developer. The frontend stuff has always just been interesting to me, and it's quite interesting that I'm known as a frontend person. At one point I was really thinking of going into systems administration, because I'm very interested in that, and always have been. And I'm a sort of reasonable sysadmin if I need to be. So there were lots of places in the stack that I could have ended up, and it just sort of happened that this is the path I ended up on ultimately.
Joy Heron: I do find that interesting, because I'm also a full-stack developer, but I find CSS, for instance, really interesting... So I play around with it and have fun with it, and then as soon as I can do CSS, everyone's like "Okay, she's a frontend developer."
Rachel Andrew: Yes, yes...!
Joy Heron: I mean, the fact that I can do CSS doesn't negate the fact that I can also do other things, but... Yes, okay.
Rachel Andrew: There's a funny thing there... People do want to pigeonhole you, and I've always been "Well, this is just all about solving problems", and you solve the problems with the right part of the stack. I think if you don't have a bit of a holistic overview and aren't open to that, you're quite likely to try and solve problems in the wrong place. You're going to try and solve problems in the frontend that should be solved with server-side code, or that actually should be solved somewhere in your systems. Maybe you need to be looking at something you're doing with Apache, or NGINX to actually solve this problem properly.
Rachel Andrew: So having that holistic view has always been very useful to me, because I don't just think "Oh, it's got to be this thing I already know about to solve this." I might think "Oh, actually, is there anything else out there that might fix this problem?"
Rachel Andrew: A good example of that is when I moved all of our server over to using Puppet for configuration management... And I was trying to fix problems of servers getting out of sync with each other, and certain things not being updated, and so on... I was trying to fix that with a bunch of messy Perl script. Then I was sort of like "Hang on, somebody else has probably solved this problem." Then I discovered configuration management, and started learning about that.
Rachel Andrew: I think it's that openness to this huge spread of stuff - that probably is one of the biggest things in my career; I am very happy just to jump around across the stack and figure out... And if I don't know about it, I'll find somebody else who does, and I get them involved, and say "You know, I think this is probably the way to go with this." So I think that's quite key in the way I see things.
Joy Heron: I agree. So you're one of the active members of the CSS Working Group... Were you part of the CSS Working Group from the beginning?
Rachel Andrew: No, it's actually fairly recent. The way that this stuff works is that the W3C -- companies essentially are members of the W3C. So you have companies like Microsoft, or other browser companies, Google, Mozilla, and really anyone who's got an interest in web technologies. There's a whole bunch of different people; there's people who work in publishing, there's automotive people from car manufacturing... Because lots of different companies actually have an interest in web technologies.
Rachel Andrew: So once your company is a member of the W3C, you can then opt individuals who work in your company onto these different working groups. So the majority of people on the CSS Working Group are representatives of a company who is a member of W3C. So there's lots of people from Google, and Mozilla obviously. But there's also other people from other companies, too.
Rachel Andrew: You then have a bunch of what you call invited experts. Now, these are people who aren't actually members of the W3C, but know some stuff about CSS, so they're useful to be involved. That was really originally how I was involved. I was asked to be an invited expert; so then I could go along to meetings, and participate.
Rachel Andrew: I'm actually now on the CSS Working Group as a member, because I'm the representative for a Dutch organization of web developers called Frontiers. They joined the W3C basically to represent web developers, and they asked me to be their representative, because I already kind of know how all this stuff works... So they give me a stipend as well, to sort of fund some of my work on the platform... Which is great, because as an invited expert you basically just have an expensive hobby. So it's quite nice to have some funding for the travel that's involved, and so on.
Rachel Andrew: So I've only really been a member/part of the group officially for -- it's probably about three years now. But really, I've kind of been on the edges of that, and made comments, posting to mailing lists, writing about the things the Working Group have been doing for much, much longer. You don't have to be a member of the CSS Working Group to contribute. We do all of our stuff in the open; everything's on GitHub, it's GitHub issues. There's lots and lots of other people who contribute to the discussions, who aren't officially members... And that is very much welcomed and encouraged.
Joy Heron: I can imagine when you're talking about the actual implementation, people who are only developers don't really know everything that goes into developing features for CSS...
Rachel Andrew: Yes... It's very like developing features for any product. It's just that the web has -- we have this whole issue that we can't actually break the past; we can't break the web of the past. So there's a lot of things that go into adding a new feature to the platform that really speak to that compatibility, of the browsers of the past and so on.
Rachel Andrew: But it is really much like adding any feature to a product. A lot of discussion has to go on, engineers have to say "Well, I don't think we can actually do that in our engine. Can we achieve this in a different way?" We're wanting to solve lots of use cases with the feature. We don't want to have something that's very specific to one use case... Just like in any product.
Rachel Andrew: So as a product person, and someone who's built products, I think there are a lot of things that are quite common in working on platform features... And I've got better at understanding how browser engines work over the years, but I'm certainly not an expert. But that's the thing with the CSS Working Group - there's lots of us from different points of view. So I might say "Hey, web developers would really like this to work like this", and a browser engineer might say "Yeah, that's fine, but this isn't going to perform well, for this reason", for example.
Rachel Andrew: So there's all this discussion back and forth to come up with the best solutions that will work in browsers, can be implemented, and will solve real problems for developers.
Joy Heron: I don't want to get into the basics of CSS... We actually had the first CaSE Podcast episodes with Jen Simmons, and that goes into the basics of CSS, so I'll link to that in the show notes... But I'm curious to hear your perspective on how CSS has changed over the years.
Rachel Andrew: Yes, one of the things that I've been talking quite a lot about, particularly around layout, is the fact that we've got really for the first time with Grid and Flexbox and sort of related specifications for layout for the web, which we haven't had; CSS didn't have any kind of layout system until they came along. We had things like Floats and so on, which could be hacked around to make them behave like they looked like a grid, but really we were using sort of a quirk of the way that behaves.
Rachel Andrew: So we've got this new layout system, but also what has happened over the last couple of years really is a kind of refactoring of a lot of the specifications to really clarify that this is a system, and to make it a lot clearer how things work... And that's in terms of the way we talk about things in the specs, the way that different features are introduced... And I think it's really great for -- anyone coming along now as a developer is going to be handed something which is an awful lot clearer, and less full of weird tricks than CSS was maybe five years ago... And I think that that's really good. It feels like it's kind of grown up as a platform, and that we can add new things in a way that's very consistent, rather than each of these specs being completely different to each other, and behaving in weird ways.
Joy Heron: Has there been a change in attitudes for CSS?
Rachel Andrew: I think maybe in some parts. A lot of the attitudes towards CSS were quite outdated; a lot of the attitudes to CSS are remembering the CSS of ten years ago, and are remembering the browser support of ten years ago... Because browser support is so much better these days. We don't have a norm of show-stopping bugs all the time. We have browsers that haven't yet implemented something, but lack of support is very different to buggy support. It's a lot easier to deal with "Oh, this thing does not work in this browser." That's easier than "Well, this thing does kind of work, but it works a different way to every other browser." Now, that's horrible to deal with. So we don't have so much of that sort of behavior.
Rachel Andrew: When you see stuff on Twitter, and you talk to people, you realize that actually the CSS they're talking about and the browser compatibility they're talking about is ten years out of date. That's something I've been quite keen on, is just sharing how things have changed, and how support has got better. Hopefully, new people don't come along and get told "Oh, CSS is this weird, buggy thing, that does random things all the time", because that really isn't the case anymore.
Joy Heron: Do you think it's easier to learn CSS now than it was ten years ago?
Rachel Andrew: Absolutely. And I think that anyone coming along now has a much better sort of experience; their first experience of learning CSS is a lot more straightforward. And when I teach -- because I teach workshops, and usually in a workshop I'll have a mixture of people who have been doing CSS for years, and think they kind of know it, and brand new people. And I will find that the brand new people understand things like Grid and Flexbox and how it all ties together far more quickly than the people who have been building websites with floats and so on forever, and hacking around all the bugs.
Rachel Andrew: I think that's because we've now got this nice, clear system, but those of us who've been doing this for a long time are kind of just waiting for CSS to come and bite us, we're waiting for it to go wrong, and we've got all these assumptions about how things work, which we have to relearn. So it's quite interesting seeing how quickly new people can pick this stuff up.
Joy Heron: I'd like to attempt to talk a little bit about the newer things that have been happening in CSS Layout. I know it is a bit difficult, maybe because it's an audio medium, and Layout is a very visual topic... But maybe you could attempt to tell us about some of the newer features with the CSS Layout?
Rachel Andrew: Yes, so some of the stuff that I'm excited about -- obviously, we got Grid Layout in browsers in 2017, and that was kind of level one of the spec, as it were. We've now got sort of a new feature called Subgrid, which basically lets us inherit the grids of sizing, the track sizing down through indirect children. Because the thing about any change to the display property in CSS - if you say "display grid" or "display flex", that only affects the direct children of that element. So if you have things nested further down inside the grid, they're not gonna be able to be laid out on the same grid. Subgrid basically gives us a way to do that.
Rachel Andrew: So that's pretty exciting... I think people thinking "Oh, this my grid on my page", they would like to be able to lay out not just the direct child elements, but other things. So I think it helps with that. That's new, and that's only implemented at the moment in Firefox, but hopefully we'll see that coming up in other browsers, too.
Rachel Andrew: Other sort of interesting stuff... Just in terms of new layout, both Grid and Flexbox - when they came along, they sort of snuck into the tapestry this writing-mode-agnostic way of looking at layout. In the past, we always laid everything out from top-right, bottom-left; the sort of physical dimensions of the screen. But of course, there's good chunks of the world who actually have different writing modes, who have vertical writing modes, and so on. So the newer CSS is kind of writing-mode-agnostic; we talk about the block in the inline dimension, as in the block direction, the direction that paragraphs go in your writing mode, and inline is the direction that sentences run in your writing mode. So we have sort of the start and end of those dimensions.
Rachel Andrew: Now, Grid and Flexbox never really talk about top-right, bottom-left, they talk about start and end, and block and inline... Which then gets a bit weird, because everything else in CSS - your margins, your paddings, your borders, all those things - they talk about top-right, bottom-left. So as well as the writing mode spec, which deals with writing modes, whether you're in a horizontal or vertical writing mode, we've got logical properties and values, which maps logical flow relative properties onto the old properties which deal with physical directions. So you'll have just a margin-block-start and so on, rather than margin-top. So there's this sort of set of mappings there.
Rachel Andrew: Ultimately, I think we'll write CSS according to those logical float-relative properties most of the time, because it just makes more sense, and it saves this weird sort of inconsistency between how layout is working and how everything else works.
Joy Heron: Is that already supported in all major browsers?
Rachel Andrew: It is, yes. Well, most of the logical properties are supported everywhere now. There are some newer things that haven't quite got support, but things like your margin padding, border properties - those all have support. So that's quite interesting... It means you can create a grid layout, and then tip it on its side by assessing the writing mode to a vertical writing mode... And everything works in the same way. It literally is just tipped over, because rather than having a width, you'd have an inline size; then in a vertical mode, inline size runs top to bottom, rather than left to right. So that's quite a big change, and I think we see a lot more of that, and new things that come into CSS will all take on this writing-mode-agnostic way of being.
Joy Heron: So if we were to start learning CSS today, we should probably start with those logical properties, as opposed to the physical...
Rachel Andrew: Yes, I think understanding that they exist -- obviously, for backwards-compatibility you're going to need to use physical stuff, but I think more importantly is understanding what those things are, understanding what block and inline is, and understanding how that maps to layout, and so on... Because I think it makes it less confusing. Because when people started using Flexbox, for example, they were often very confused as to "Well, why can't we just say 'left', or 'right'?" So I think it's quite a good way to teach people, is to introduce this stuff early, so they can sort of understand why we're using this terminology that we're using.
Joy Heron: I know there's also the multi-column layout spec... Could you talk a little bit about that? I don't really know what the status is...
Rachel Andrew: Okay, so multi-column is actually quite an old spec. It was one of the original CSS3 modules, as it were, when CSS moved from 2 to 3. So it's been around for a long time. People don't particularly use it on the web, because it has been reasonably buggy, and there hasn't been support for some of the features in Firefox. It's also not particularly useful in a lot of ways on the web, because what multi-column does is it arranges your content into columns, a bit like in a newspaper.
Rachel Andrew: Now, that's not a great reading experience on the web, if there's any chance that those columns could get taller than your viewport, because then you'd have to scroll up and down to read... Which - that's not what we do on the web. It's used extensively in print, and something that a lot of people aren't really aware of is that a huge amount of books and magazines and so on have actually published using CSS. There are user agents that basically output HTML and CSS to PDF, so it can be printed.
Rachel Andrew: So multi-column is used a lot there, and is really useful. I'm one of the co-editors on this specification, so... A lot of the feedback I get on multi-column is actually from the print world, rather than the web world.
Rachel Andrew: We've got some ideas as to how to make multi-column more useful to web developers. There are some useful use cases for it. Multi-column is good for things like -- if you've got like a set of checkboxes that are all laid out in one line, and you just want to collapse them down into columns, that's the sort of thing multi-column is quite useful for. You can use it for small bits of UI... But yes, it's existed for a long time, but every time I write about it, someone will say "Oh, I didn't even know this existed."
Rachel Andrew: Firefox have recently implemented a bunch of this stuff that was causing problems, and they've implemented the column-span properties to expand elements across columns. And we're kind of getting the spec to a point -- the spec was kind of abandoned at one point, and no one was doing the edits on it so I've been trying to fix the spec up and get the spec to a point where it's nice and stable, so that we can move on and add new features that will make it more useful to web developers.
Joy Heron: Is there any chance we'll ever get container queries?
Rachel Andrew: Everyone always asks... We all know this is important. There are some difficult things to solve around container queries. I think that some of the things that people ask for are actually solved just because of the way that a new layout works. We're far less tied to needing to use media queries than we were...
Joy Heron: Yes. Maybe, to take one step back, you could explain what container queries are, just briefly, for anyone who doesn't know what they are.
Rachel Andrew: Yes, container queries and element queries are this idea -- the moment you use media queries, you're basically tied to the viewport. So the viewport changes, and you can say "Well, what if my viewport is less than this size, or more than this size? I'm going to make these changes to my CSS." That doesn't work so well if you're dealing with an individual component. And a lot of us work with components these days. What you actually want is "Well, if this component is a certain size, what happens?"
Rachel Andrew: It's absolutely the number one request from people whenever you say "What do you want on the Web platform?" And yes, particularly when you're working in a component library, and you don't know where those things are going to sit, then it would be very useful. There are a lot of people discussing this, all of the time... And there are various ways to get around it to some degree, all of which are not perfect.
Rachel Andrew: I kind of think that at some point it will be sorted. If we had looked back ten years, something like Grid wouldn't have been possible. There's so much stuff that's in CSS now that is possible, that wasn't... But I think it's just a hard problem. And yes, we could spec it, but then also the browser vendors need to be happy to implement it. So I think it does need to be this thing that kind of comes -- a bit like Grid was... That we decide "Yes, this absolutely needs to happen", and a lot of people need to get together and be very committed to bringing it to life, both from a spec point of view, but also in the browser engines... Because it's no use to us if it only ends up in one browser.
Rachel Andrew: So it's a difficult thing... Everyone involved with CSS knows it's what web developers want, and I keep answering this question, but I think it just touches on quite a lot of hard problems.
Joy Heron: Is there anything developers could do to help -- if there's some kind of functionality that we want, but we don't know how to implement it, is there any way we could help out, or provide input, or say "I'm really interested in this"?
Rachel Andrew: It's really tough with big issues like container queries. Generally -- you know, I say to people, "If you want something on the Web platform, please write about it, come and post to the CSS Working Group and raise it as an issue on our GitHub." Because when it's fairly small things -- really, we would like people bringing that to our attention and say "Hey, I've got this use case that isn't met in CSS. How can we do that?"
Rachel Andrew: There's lots and lots of things that go into the Web platform which have come from requests from web developers. I think the problem with a big standout feature like container queries is that it's being used as an example of the CSS Working Group not taking the input of web developers seriously... And actually, the reality is it's just a really hard problem to solve.
Rachel Andrew: There's lots of smaller problems which we solve all the time, that come through from the web community... And what I would say is that this stuff is quite a long game. Very occasionally, someone will suggest something which gets into a spec super-quickly, and that's usually because someone is working on that spec right now, and you just hit lucky. You raise your thing at the exact time that that spec is being worked on, and it gets written in.
Rachel Andrew: More often, you will raise an issue - and it doesn't matter whether you're a CSS Working Group member or just another web developer... You know, more often people will raise an issue and it will sit there for a year, and you will think "Nobody has taken any notice of that", and then suddenly it'll get picked up and discussed, and potentially implemented... And that's just the nature of standards development. There are very few people writing specs, there are very few browser engineers actually (say) doing layout... So stuff just gets prioritized.
Rachel Andrew: What I would say is if something ends up as an issue on the working group, it will get discussed. We don't just close issues out of hand. They'll wait around, and they will get discussed... But it is a long game. If you suggest things to the CSS Working Group, you're not going to have it for your project probably this year, maybe not next year... By the time these things have been discussed, gone into a spec, and then gone into browsers. So if you're contributing, you're kind of doing so for your future self, and for the good of the web. Understanding that you're participating in something which has quite a lot of gravity and weight, and therefore takes a while to happen is sort of worth knowing.
Joy Heron: You mentioned components before... One thing I find interesting is this idea of "How do we structure CSS for maintainability purposes?" And I don't know if you could share your favorite methods for organizing CSS...
Rachel Andrew: For me, if I am building a website, I like to work in a component library. I tend to use Fractal, but there's a lot of these things, like Pattern Lab and so on... So working essentially in components, but ultimately compiling that stuff out into a single stylesheet... So it lets me kind of work in a way that's quite nice, having things scoped to a component. But then I'm just going to end up ultimately with just some CSS. I'm not doing CSS-in-JS, or anything like that; I'm just writing CSS. I've just found a way to write it in a way that lets me deal with one component at a time, rather than the entire stylesheet.
Rachel Andrew: I'm less interested in the different sort of approaches inside BEM, and so on. For myself, if I'm just doing a site, I probably don't really use any of those things. I just write some CSS. I'm sure there are lots of things you could pick out in my stuff to say "Oh yes, you always use this naming", or what have you... But if I'm working with other people, then I'll just use what they're using.
Rachel Andrew: I think that coming up with a method to manage this stuff if you're working in a team is important, and you should use the method that works well for whatever you're doing, and for the team you've got. And if you come into that team - well, you just have to fall into line and use what there is.
Rachel Andrew: I'm fairly pragmatic about this stuff... I think as long as what you're doing isn't causing a giant performance problem, it's not causing an accessibility problem, as long as everyone on your team is able to understand what's going on, and that if someone else has to be dropped into the middle of that, they can understand what's going on, you're probably not going to go too far with that.
Rachel Andrew: People always like to know exactly that you recommend, and I tend to recommend "Well, solve the problems you've got." Probably the biggest thing I would warn against is looking at what Facebook do, and saying "Oh, this is what we should do, because Facebook are a really good company and they're using it for their stuff, so it must be a good idea." You'd be massively over-engineering what you're doing for a small site, for example.
Rachel Andrew: So I think that's probably the thing to look at - what's appropriate for the size of project and team that I'm working on, rather than read a bunch of articles written by massive companies, with teams of hundreds and hundreds of developers... Because they don't actually relate to what most of us are doing, and you're just making work for yourself really.
Joy Heron: So when we are developing now using CSS there's a lot of layout - we already talked a little bit about it - there's layout opportunities in the CSS itself. Is there still a use case for big frameworks like Bootstrap or Foundation when things like CSS Grid can take over some of that layouting responsibility?
Rachel Andrew: I think that these things solve two problems. They're not just about the grid. They were very useful in terms of the grid when we didn't have a good way to do a layout in CSS. So they would manage the float-based and then a Flexbox-based grid. You can use these things without using a grid framework to start with... And I think they solve another problem, because what they do is they give your team consistency; they give you a pattern library, essentially, without you having to write one. Now, that can be quite useful.
Rachel Andrew: If you haven't got a big design team helping you with this stuff, if you haven't got the resources to come up with your own framework, then maybe inheriting somebody else's isn't necessarily a bad idea. And so I think that in a lot of cases these can be very useful. They're certainly not terrible; the big frameworks are doing a lot of work in terms of accessibility, and trying to make good decisions... Yes, your website will look a bit like everybody else's, but to be honest, it's probably better to use something like bootstrap and have something that's consistent and well thought through, than to end up with a hodge podge of stuff because you haven't had time to do that work yourself.
Rachel Andrew: So yes, again, I'm fairly practical about this stuff... And if that lets you get your product launched, then cool. You can always go back later and redevelop with your own thing, once you know that your product is making money and it's really worth doing that. So again, it's looking at the situation you're in. If you can afford to spend the time creating your own stuff, then obviously you're going to end up with a much more performant and customized framework for your own situation. You're not going to inherit a load of stuff that's to suit everybody... But I don't think it's a bad thing to start with these things.
Joy Heron: Do you have any rules of thumb for writing good CSS? I know that "good" is subjective, but...
Rachel Andrew: Generally, to use as little as I need. It's very easy to start over-engineering stuff and start thinking "Well, you know, this component might need to be used in all these other different kinds of ways." Well, fine. If it does, you can go back and edit it. It's very easy to get yourself down into a sort of big thing of trying to over-engineer what you're doing. So I try and be as simple as possible, with most things.
Joy Heron: I have one question about the browser engines, because Edge just moved away from using an internal rendering engine to using Chromium... And I'm wondering what effect that will have on the Web platform as a whole. Do you have any insights on that, or worries, or you don't think it's a problem...?
Rachel Andrew: I think a bit of everything... I am worried about it, because I think losing independent rendering engines is a problem. And not just for the fact that "Oh, then we've really just got Chromium and then Firefox", but also just that rendering engines are where experiments can happen. We've got Grid because the Internet Explorer team implemented it initially in IE10. So the first implementation of Grid was done by the Microsoft team. And we see that with all browsers - they're trying out different things. Firefox has done the first implementation of Subgrid.
Rachel Andrew: So if we lose rendering engines, we lose one place where that stuff can happen. That said, Microsoft have kept all of their developers; as far I know, engineers are still working on stuff, and now they're doing projects in conjunction with the Chrome team. So they have recently shipped some better defaults for form controls, for example. That's been a joint project between Microsoft engineers and Google engineers. There's been a bunch of accessibility stuff that Microsoft have been working on...
Rachel Andrew: So it could be a good thing, in some ways, because rather than having to continue to work on this rendering engine, those engineers are now freed up to say "Right, we think this thing should go into Chromium. We'll work on it." And that's another group of engineers working on Chromium, which is obviously very important for the platform at this point, because so many browsers are based on it. So that could be a good thing.
Rachel Andrew: But I am slightly nervous about the overall impact and long-term impact. But the short-term impact seems to be positive, and I know there are really good people at Microsoft who are very keen to be supporting standards, and doing really good work... So I know that the thinking behind it is solid and good. But how that is playing out in five years' time, I don't know. We'll see.
Joy Heron: It worries me a little bit, because I fear that if Chrome can move so much faster than, say, Safari or Firefox, they'll be starting to implement features, and Firefox and Safari will only have the time to play catch-up, and won't be able to have the time or the resources to implement new features... Or Chrome will already have implemented features that only Chrome can use, so developers decide "Oh, we'll only support Chrome, because everyone uses Chrome anyway."
Rachel Andrew: It is a worry, and it's a worry in terms of this sort of stuff I work on. We are seeing at the moment that Firefox have actually implemented an awful lot - particularly in terms of CSS - that Chrome haven't yet... So they're certainly keeping up with things, and actually doing more in some areas. But it's something definitely that I would want people to keep an eye on.
Rachel Andrew: As I said, it is worth remembering there are other people involved with the platform. The print side of things - those are user agents and rendering engines that do render; they're not web rendering engines, but they are rendering CSS, and so on. So there are other places that are involved in the platform that aren't just the browser engines that we tend to talk about.
Rachel Andrew: We'll see what happens there... But there's a lot of people, both in and out of Google, who are concerned about this. It's not just something that people who aren't involved with Google are worried about. Generally, people who work on the web do care quite a lot about the platform, and it being good, and it surviving, going forward... So there are a lot of good people thinking about this and caring about it.
Joy Heron: I just have one more question before we can wrap up, and that's concerning accessibility. How can we ensure that our site is accessible or usable for a maximum number of users? I don't know if you have any resources or tips for doing that...
Rachel Andrew: Yes, so in terms of layout -- layout is kind of my big thing, so I'll mention a tool that I think is really useful. There's a tool called Accessibility Insights. The URL for that is accessibilityinsights.io. This came from the Microsoft team. It's basically a sort of accessibility checker for your site; you can add it to Chrome.
Rachel Andrew: One of the really neat things that it has is this sort of tab stop checker. Basically, it checks that you haven't messed up the keyboard navigation order of your site. This matters a lot, because with things like Grid and Flexbox it's very easy to essentially make the source order of your site, which is what things tab through the document, and anyone having the document read out, say by a screen reader, they follow the source. If you've jumbled things up by using Grid Layout or by changing the order of things in Flexbox, you could actually make this a really weird experience, where if you're tabbing around, you're kind of jumping all over the place, rather than tabbing logically through the document.
Rachel Andrew: So that's one of the things that's in the Accessibility Insights tool, is this quick check that shows you the order that someone will navigate through your document, so you can prevent those sorts of things happening... Because all these nice, new things we've got in CSS do come with them the potential of causing accessibility problems. So I think that keeping aware of that, keeping mindful of that as you're developing is really important.
Joy Heron: Well, that's all the questions that I had for you... Is there anything else that you would like to add?
Rachel Andrew: Just to keep in touch with what we're doing at the CSS Working Group, and so on. It's a much more open process than I think a lot of people are aware... And generally, we're very happy to be getting feedback from developers. So the more of that we get, the better we can make the platform for everyone... So I'm very keen to encourage people to check out what's happening with the process, and keep in touch, and talk to us.
Joy Heron: Is there anywhere where people can follow you online, and all the work that you're doing?
Rachel Andrew: Yes, I'm on Twitter at @RachelAndrew, and most of the places on the web I'm usually Rachel Andrew. My personal website is RachelAndrew.co.uk. From those places I try and post all the stuff that I've been writing at some point too, to RachelAndrew.co.uk, so people can find it all in one place... So that's quite a good place to see what I've been writing about.
Joy Heron: Well, thank you very much for your time. We'll definitely link to all of these things in the show notes. So thank you, Rachel.
Rachel Andrew: Okay, thank you. It's been great to chat to you.
Joy Heron: Yes, it's been great chatting with you, too. And to all our listeners, until next time.