Noel: Hey everybody, welcome to PodRocket. I'm Noel, lead engineer. With me today is Stephanie Eckles. Stephanie's a software engineer at Microsoft. She's author of Modern CSS, co-host of the Word Warp Podcast, and so much more. Thanks for coming on Stephanie. How's it going? Stephanie Eckles: Doing well, thanks. Thanks for inviting me. Noel: Yeah, of course. Of course. Yeah. I feel like there's a bunch of stuff we could talk about today, but let's kind of just start with your background a little bit. Kind of, where do you come from? How'd you get into web and software? And how did that progress to where you are now? Stephanie Eckles: Yeah, absolutely. So my total time interacting with the web professionally is about 15 years, but as kind of an early teen, I happened to go to a summer camp where I was given a copy of Macromedia Flash. Noel: Oh yeah. Nice. Stephanie Eckles: So little context there, you can attempt to do the math on that. So, yeah, that was exciting. That was, for those that aren't familiar, which I wouldn't blame you these days, Flash was heavily, kind of had two ways to enact with it. One, maybe you were just doing strictly animation. So you would do key frame animation. Frame by frame, drawing out your shapes, your characters. I mean, people did really complex things with it. But also it was the way to produce really interactive, immersive experiences before we had the maturity that we have today of JavaScript and other animation libraries. Stephanie Eckles: Unfortunately it was woefully inaccessible, but we also, unfortunately weren't worried about that at the time. But for me, none of those things, I had no idea about accessibility or any semantics, nothing. For me, it was my gateway, because it meant I could put my, and I'm doing very heavy quotes here, my art on the web. Stephanie Eckles: So that led to me just exploring what is HTML, because I had to learn a tiny bit to embed the Flash file. Had to learn about servers, FTP, all these things. It was much more manual. We didn't have the niceties of GitHub and things like that. Noel: Yeah. Right, right, right. Stephanie Eckles: But anyway, so along the way, that led to me discovering WordPress, because that was the beginning of its reign, as it were. And I ended up actually spending a decade of my career, developing, working in marketing and advertising agencies. My degree is actually in advertising, but doing internships related to web development. But again, being around long enough that I remember when the article came out about responsive web design, and I was working for an advertising agency at the time. Going through that whole transformation. Stephanie Eckles: But so all those kind of experiences led to, like you said, where I am today. Had a few other experiences where I led the development of a multi-platform design system in my previous role. I'm still doing a little bit of design systems work, something I do enjoy. But I kind of found that we were kind of having a gap in some educational resources around CSS. Where a lot of what I would see get traction on social media, or even across kind of the big publications was really focused on kind of more the tricks idea, tricks and hacks. And meanwhile, CSS as the language has grown up just immensely. Especially over the last couple years. And so, Modern CSS is in depth tutorials on practical applications of CSS. The intent is to help you both address a specific problem. For example, the most popular articles are around customizing form inputs, but also to teach you related things, to just improve and upgrade your toolbox along the way. So introduce you to all that Modern CSS has to offer, get you more familiar with layout methods, like grid and flex, and introduce other related topics that are very important for the modern web, accessibility and semantics, and things like that. Noel: Yeah. Nice. Awesome. Thank you for that. Thank you for that kind of that breakdown. You talked about how the content that you were seeing most often, or you were reaching most often was CSS tutorials and content that was kind of like tricks and hacks. Was kind of how it was viewed. Do you feel that is a product of SEO optimization? People creating content that would bubble up high when they're like, oh, how do I make a text box shift to the left side of its surrounding div. So then they end up on a page that's like specifically to do this thing. Do you think that kind of led to this culture of like 10 quick CSS tricks, or what do you think drove that? Stephanie Eckles: Yeah, I think that's a good theory that SEO would've played a part for some people, but I think on Twitter hacks that are easy to rock in a couple seconds is what gets traction. And it doesn't matter if it's accurate and it doesn't matter how useful it is, unfortunately. And that's not an in-depth tutorial isn't going to address that, but for folks that are wanting to fill a skills gap that they have, that's more kind of the market I'm hoping ends up enjoying my materials. And I think there's absolutely a place for those tricks and hacks. I'm not trying to cast those in a negative light. You still learn things. I love creative coding. I absolutely encourage experimentation and play. That's where my other project came out of, Style Stage. So absolutely. I want that to exist on the web. Stephanie Eckles: I think that, to your point of where this kind of came from though, was also that CSS has kind of had an unfortunately bad rap. And again, that's what I'm hoping to address is exposing folks to what is now available, so that we can move on from things that truly were hacks, because we have actual improved methods native to the language that requires 0% hacks. Noel: Yes. Nice, nice. Yes. Do you think that that bad rap that CSS kind of has now, is that a product of shortcomings of its capabilities before? Or do you think it was how people would go about trying to write CSS first stuff they were building? Stephanie Eckles: A combination. It hugely depends. Everybody's lens for anything that they do on the web is so different. And it is influenced by your journey to the web, how much mentorship and guidance you've had. If you're solo, if you're on a team, what that team makeup is like, and I think your own motivation to seek out and learn new things. And all these things are valid. We're all, at the end of the day, we need to do what we need to get done, right? But yeah, there are, even the originators of getting CSS into the web, there's actually a list of things that they acknowledge were kind of mistakes, and that's okay. Hindsight's 2020. There's no way when they could have predicted some of these things that early on, because if we remember, the web itself is what? 30 years old. Noel: Yeah. Right. Stephanie Eckles: So this is not a very long timeline we're talking about. We expect there to be improvements just like there's improvements in JavaScript. But also, all that said, I think an important thing to keep in mind is again, just like JavaScript, CSS has been colored by not having browser compatibility. And sometimes that's been harder to polyfill. That's been harder to get around. And that's led into some of that negative press, if you will. But that's improving. And we're actually at kind of peak cross browser compatibility and something that the top browser makers, Chromium, Safari, and Firefox are actively working towards. There's a project called Interop. They did it last year, 2021. So now it's 2022, and they are making a concerted effort to have cross compatibility of these upcoming features, which is really exciting. And it's definitely important to me to spread that message. So folks can help move on from those negative sentiments or older, outdated ideas they have about the language. Noel: Yeah. Nice, nice. I feel like Interop has come up on the last several episodes I've hosted. Stephanie Eckles: I'm sure. Noel: Everybody keeps landing on it or talking about it. And I know it's always encouraging to see that there's time and energy being spent, ensuring we're building out standards, making sure the web is still open and accessible. It's very encouraging when there's a lot of other like bleak stuff going on in the tech space. It's good to see. Cool. So yeah, I'm curious then when you decided to start Modern CSS, were you envisioning your readers coming and landing on an article and kind of using what it was talking about to fix a specific problem they were having? Or were you kind of hoping people would come at it more to like take it as if it were a course, and go through and read, just read content actively and then apply it as needed in their day to day work? Stephanie Eckles: Yeah. So like I said, my degree's in advertising, I worked in advertising marketing. So I had my own lens of kind of a preformed idea of how to structure my posts, which was trying to hit at a few different angles. I definitely know, fully aware of the SEO angle. Noel: Yeah. Right, right. Stephanie Eckles: And so, absolutely knowing that a subset of users, my analytics support this a hundred percent, a subset of users are coming just for the answer. So I want to make that discoverable. You'll find that most, especially the early articles have code pins. So you can skip right down to the quote unquote answer, right? But then I also try to structure it in a way that the folks that are there and wanting to learn more deeply, they want to know the why that they can also be served. Stephanie Eckles: And so, there's definitely been an evolution for when I started this series and how I approach articles. The first several where... So the full name of it is Modern CSS Solutions for Old CSS Problems. So especially the first ones in this series really adhere to that where literally they were problems I had that now can be addressed with CSS versus for example, a jQuery plugin, which again, given my history over the web jQuery was a big part of my own story. Stephanie Eckles: So that's kind of where it started and it's evolved. It's gotten more in depth and, but again, every article is intended to be you practical tips. That's the solid theme throughout everything. It's not necessarily a course, but I am looking at how to maybe help surface the content if folks, you can kind of use it as a learning path for sure. You certainly can go through it and find kind of a build up of skills. So, but it's not officially a course at this point. Noel: Yeah, yeah. No. Totally, totally. Yeah. I guess I'm curious, this is like a very broad and hard to answer question, but do you think that aren't doing enough kind of proactive reading on the CSS tools. What's out there, what can be used and they treat it as more of a crutch where they're going and finding a specific, like give me the little CSS selector blurb to fix this given problem I'm having. But not actually learning the CSS as a, I don't want to use the word framework, but just like learning the language and using it well as they would their like backend or JavaScripts, like the code that they're writing for those [inaudible 00:13:04]. Stephanie Eckles: Yeah, absolutely. So it's something I think about a lot, and again, have my own biased viewpoint about it, for sure. Noel: Yeah. Right, right. Stephanie Eckles: Again, it comes back to we're all trying to do a job at the end of the day. So while I wish folks would take time to learn it more deeply, and while I definitely encourage that, there's a lot of pros to doing that. Mostly because you'll avoid hacks, you'll have cleaner code base, more consumable code base by your team. But also recognizing that there are barriers to that, whether it's just a matter of time, whether it's a matter of not being able to document those decisions in a sustainable way for your team. But that's going to be with any part of the stack, any choice you make in your stack. And so, yeah, I expect it to be approached different ways. Stephanie Eckles: You'll see a comment under a common theme is I'll really push, not push, but I try to incorporate aspects of particularly layout methods, flex and grid, and really showing the power of those. Because it's important to me to convey that while you may think that, have an idea in your mind of what responsive design is, we have got to evolve beyond what we've sort of built up already as best practices, because we have so many different devices, more than we've ever had, and that will continue to grow. And when I'm talking devices, a concern there is both a variance in viewport sizes, but also device capabilities, and very critically, user capabilities. So why are they making that choice for a particular device? What settings do they have? So with CSS, there's user preferences we can tap into. And if you're not aware of that, you're not going to be able to use it. So for me, it's more about not necessarily changing minds, but exposing folks to what is available and sort of gently, hopefully, help guide them to choosing what's best for their user, but also, works best for their team. Noel: Yeah. There I feel like there's so much. There's so much to delve into there, and I understand why engineers become overwhelmed by it so easily. Just like it's such a huge problem space. I was just talking yesterday just to friends and one of them was a web dev, one wasn't, we were just talking about alternate character sets and reading directions and all this stuff. And it's just like, it's such an interesting problem that I don't think anything before the web really had to solve quite this acutely of like, we're trying to make a thing that can be consumed by almost anyone on the planet. How does one even go about doing that? And we're doing our best to take these tools, namely CSS, to figure that out. But it's such a huge task. It's so massive. Stephanie Eckles: Absolutely. Emily: Hey, this is Emily, one of the producers for PodRocket. I'm so glad you're enjoying this episode. You probably hear this from lots of other podcasts, but we really do appreciate our listeners. Without you, there would be no podcast. And because of that, it would really help if you could follow us on Apple Podcast, so we can continue to bring you conversations with great devs like Evan Eu and Rich Harris. In return, we'll send you some awesome PodRocket stickers. So check out the show notes on this episode and follow the link to claim your stickers as a small thanks for following us on Apple Podcast. All right, back to the show. Noel: So if you're a web dev and you're getting into this space, how do you take all of this stuff that you know you want to be doing correctly, and how do you work towards doing it right? But knowing that it's probably not going to be perfect on your first try and staying motivated and not getting discouraged. Stephanie Eckles: Yeah. So, like I said, I'm a big, big proponent of experimentation and play. So what I mean by that is if you hear about something cool, drop yourself into code pin, poke at it, look at examples that other people have put out there, because people are very quick to put out examples even of this very cutting edge experimental stuff. And even though we know some of these upcoming things, like container queries, scope, the has parent selector, these things that you might have started to hear about, we know that cross browser compatibility is coming. It's on the way, it's being worked on. Some have polyfills, but jump into the browsers where it's supported. Usually, I think all of the Canary or preview versions have these things. But experiment not just to understand them yourselves, but also to be able to give feedback back to the language. Stephanie Eckles: And I know I tangent a little bit off of what you were talking about, but experimentation's a huge part of it and just understanding it. And alongside that you understand, is it something that is applicable to what you're working on? And it might not be, and that's completely fine. But also just kind of curating your network of follow the folks that are involved in making specs. An easy one is to follow dev advocates from the different browsers, because they're going to keep you up to date in a really easy to digest way. Following even the GitHub issues if you want to go even deeper. Those are the different ways just to keep apprised of what is happening, and it can feel overwhelming, but keep in mind, again, you don't have to use any of these things that are coming out, only if it's right and fits what your needs are. And so, I think that helps keep the overwhelm to a minimum, but yeah, it's really just again, about exposure, knowing it's available, and choosing it when it's right. A right fit. Noel: Yeah. Nice, awesome. Awesome. I feel like that's not a terrible transition. I wanted to ask about a talk you gave recently at Beyond Tellerrand called Scaling CSS Layout Beyond Pixels. And it focuses on responsive design, and the issues that we'll run into if we continue to use pixel height, width measurements, using those values for element sizes. I feel like most devs kind of know that is a thing they shouldn't be doing, but I have a hunch that a lot don't know exactly why. Could you speak to that a little bit? Stephanie Eckles: Yeah, absolutely. So this is a topic I've become a little more focused on over the last few months. And the idea is that pixels are something that's familiar. It's a concept you're introduced to very early on. Typically, I mean, it's probably the first measurement you use. Maybe you expand to percents in some cases, if you're beginning to build out grids of using whatever layout method. But, when you are in a situation where you are building against a layout, and if your only concern is matching that layout, and that layout happens to perhaps only be a desktop layout, and maybe you're using a framework that you're sort of just assuming works for you in terms of, again, our kind of traditional views of responsive design. Then you may miss the advantages some of the more modern features have for us for scaling your design. And I mean, scaling quite literally in terms of zooming, and also resize of the view port. Stephanie Eckles: So if zooming seems like it came out of left field, it's because it's an accessibility consideration. We have kind of two main criteria to consider there. One is related to being able to resize text up to 200% and also the criterion related to reflow, which states that at a 1,280 pixel wide desktop, a user should be able to zoom up to 400%, and it should not cause two dimensional scrolling unexpectedly. So overall the experience should be one dimensional vertical scrolling essentially. And when you are only using pixels, and particularly when you're developing against break points, you are only worried about the view port. You're probably not testing these other environments and you're going to encounter either failure of that text size, especially if you're defining font size and pixels, because it won't resize under certain circumstances and you're going to run into overflow or too much or too little space in the reflow context. Stephanie Eckles: So instead we have a few other methods available. There's properties, there's functions, and then my favorite tool of all time, grid layout. Also flex, but grid has some particular advantages in some cases. So those are the kinds of things I talked about. And the idea is making spacing around elements and making sizing of elements. Harking back to a term that Jen Simmons coined, which is intrinsic web design, which ultimately means how our designs will adapt to available space, but also having them more intrinsically linked to the actual content that we have in our layouts. \. Stephanie Eckles: And so, yeah, rather than having these strict skills that are based on pixels and these strict break points, we're going to set up our layouts and our sizes and spacing in ways that just is more flexible, no matter what the user context is. So, that's the overall idea. Noel: No, yeah, that's perfect. Thank you. So just to wind back a little bit, you talked about reflow and setting pixel widths for elements can get us into trouble when we're on weird aspect ratios and a user tries to zoom. Can you speak a little more to why that is? Why does setting a pixel width for a div cause us to get into trouble when a user's zoomed in on a small device? Stephanie Eckles: Yeah. So, it goes back to just a pixel is the least flexible unit we have. Least dynamic unit we have. Instead, kind of looking at the more dynamic units like REM, which is going to be dynamic to the base font size. So especially when we're talking about the zoom context, that's an important upgrade to use for your font size, but also anything that is font size relative. I tend to use it for most of my spacing, my primary spacing unit. Stephanie Eckles: But then coupling that with, like I said, for example, the math functions. Clamp might be one that's familiar to folks if they've heard over experimented with fluid typography. So clamp is a math function where we give it three values. The first is a minimum allowed value. The middle one is our ideal value, which is where we use a dynamic unit. And the third value is the maximum allowed value. So what clamps allows you to do is essentially define a range, and based on the context where that context may be viewport size, if you decide to use viewport units as that middle dynamic value, or I also like to use it for padding and use a percent value. Stephanie Eckles: And what's cool about padding and percent, just as an example of how this dynamicness works is that padding, when you use percent, that percent is relative to the width or the inline size of the element. So it's actually container relevant, if you will. This is something that has existed as a behavior, pretty much CSS's history, I believe. And when you throw that at clamp, that means, for example, if you picture a grid of cards and if you use this percent idea on your panning, when those cards in that grid are more narrow, your padding just intrinsically becomes more narrow as well. And when those cards are allowed to be larger, have more space, then they can have that padding grow a little bit. And it just feels more contextually appropriate. And then when it's at that narrow view, you have benefits of gaining back line length and things like that to make legibility better of that content. Stephanie Eckles: So just finding those ways to switch. And as I said, the contrast to that would be break point dictated classes. That again are solely based on viewport, and that's not appropriate for the context I just described. So, that's just one example of the type of upgrade that we can make. Noel: Yeah. So I feel like people end up using break points, because they're working on something. They have a specific layout in mind. And they realize, oh, when I hit a certain screen width, I want these things on the right side to pop down below the top element. What is wrong with using explicit break point widths to do that? And what better tools should people be using outside of these functions that can help us compute values dynamically? What tooling should devs be reaching for? Stephanie Eckles: Yeah. So I'm not going to say should as a hard and fast rule. For sure, you will continue. We will continue to use break points. There are scenarios where, of course the complexity of what you're trying to achieve when we're talking about more or less available space, we will still have concerns that are most appropriate to handle with a viewport-based media query. So in the situation you just described, if that's the whole page layout, there are ways using flex and grid that we can address that. Some folks view that as a little too clever or not readable, and that's a valid concern. So there are instances where you'll still use view viewport media queries. I definitely want to make that clear. Stephanie Eckles: But when we consider the layouts of today, we see a lot of commonality. So a grid based layout is a huge commonality. You're going to find that everywhere. Where we have, depending on how long you've been on the web, you may be used to working against a 12 column grid and have that really rigidly defined. Again, most of the frameworks that exist are going to have break point based utility classes that you are responsible for manually adding to define how many columns and things so that it breaks appropriately. Stephanie Eckles: So another option is to use CSS grid or flex, but grid is my favorite method. So I'll talk about that one. And we can provide a one line, extremely dynamic definition for our grid template columns, where given the amount of available space, the browser will work out the mechanics of laying out the grid, how many items can fit across in a row, and without a media query, handle breaking those down and stacking them up. So that basic baseline functionality that you're probably expecting a grid to have, can be greatly simplified. And you still maintain control over the sort of intrinsic break point. We still end up defining sort of whichever unit you find appropriate. I like the ch unit, which is the character unit, for when you anticipate that grid to start breaking down and stacking. Stephanie Eckles: So you still have that measure of control. You, of course, still retain control over how wide that container can grow, which you would set in a more traditional method, width and so forth. But you just don't have to worry about managing break points. And so, whether it's a zoom context or whether it's a smaller device, this is going to be a method that more gracefully handles those in between points that you may not have addressed with your break points. And we have other methods in grid that can even further expand upon that. Help you build out if you don't need a three column grid precisely, but just need more dynamics, spacing of elements. I encourage folks to look into more of what grid has to offer. So that's another thing that I had discussed in that talk. Noel: Nice. Awesome. Awesome. Anyway, kind of last big question here is you touched a little bit on how you've done work in design systems or on design systems in the past. Do you feel that design systems are kind of butting up against really responsive layouts by definition? Or do you think that we're just being overly stringent on in certain dimensions with how design systems are saying content should be arranged and spaced? Stephanie Eckles: Yeah. So, I'm a proponent of design systems. I'm a proponent of whether you call it a design system or not, componentizing your styles to make them easier to understand work with, share amongst a team. Whatever that looks like for you. What I have seen as stumbling blocks is largely related to accessibility, whether that's text resizing, or resizing of view ports, and sometimes these situations arise simply because we haven't considered that our user doesn't use a full screen browser. I've encountered this myself. I like to do half screen on my laptop for working on certain things. And it's kind of amusing, but also mostly frustrating when a design is clearly developed against a break point and that half Z resize isn't a tablet. So guess what? The layout's broken. Stephanie Eckles: And the other kind of caution and a pitfall I've seen, whether it's a design system or working with the framework, is assuming that that viewpoint size also correlates to the device capabilities. But what I mean by that is if you assume that a narrow view port means a touch interface, you're dropping functionality that you definitely shouldn't be dropping, or making other decisions. So it's just being aware of those pitfalls and there's ways to address those. Stephanie Eckles: In terms of layout, yeah, like I said, I think it's mostly not considering those in between parts of your break point. And just generally being less flexible to the context that your component could end up in. We end up doing a lot of orchestration from the page level, and that's partly limitation of the tools that we have now, and partly limitation of, that I don't know how to solve, but that I am aware of, of having documentation, having training that allows developers to very effectively work with those components and include those considerations, because it's one thing to build a component and a whole other thing to implement that component. And you don't have control of that second part when you're building it initially. So yeah, just pitfalls, just things to be aware of, and it's really individual per team. Noel: Yeah, totally, totally. Yeah. Like we were saying before, it's just such a huge problem we're trying to solve elegantly and make it easy for every everyone. Make it easy for devs, but also users, and bring it all together. So yeah. I think everyone, putting together resources like this is super beneficial for the kind of web community at large. Yeah. Awesome. Noel: So, yeah, I guess with that, is there anything else you want to point our listeners to or plug? Touch on at all? Stephanie Eckles: Yeah, so if I may, for those of you listening before kind of mid-July, if you are interested in upgrading your toolbox about CSS, I run a workshop with Smashing Conferences. And so. That is coming up this July and we'll cover a whole lot of stuff. So if you have been feeling, after hearing this, like, wow, I'm missing a lot of what is being offered these days, that's the goal of the workshop, to get you up to speed. So we'd love to see folks there. And if you happen to scan over any of the Modern CSS articles, I'm always open to feedback. So yeah, get in touch. Noel: Awesome. Cool. Well, thanks for coming on and chatting with me, Stephanie. It's been a pleasure. Yeah. Hopefully we get in touch and chat again soon. Stephanie Eckles: All right. Thank you so much. Kate: Thanks for listening to PodRocket. You can find us @podrocketpod on Twitter, and don't forget to subscribe, rate, and review on Apple Podcast. Thanks.