Modern CSS with Stephanie Eckles

Episode Description

Stephanie Eckles discusses the evolution of modern CSS, the trade-offs of CSS-in-JS, accessibility with JavaScript, and her work with Eleventy.

Episode Summary

Stephanie Eckles joins the show to share her perspective on what makes CSS "modern," drawing on nearly 15 years of professional web development experience. The conversation traces CSS's evolution from the days of float-based layouts, table-based designs, and IE6 hacks through the arrival of border-radius and box shadows in the Web 2.0 era, and on to the transformative impact of Flexbox and Grid. Eckles explains why browser parity is just as important as language features in defining this modern era. The discussion turns to CSS-in-JS solutions and utility frameworks, where she argues these are often stopgap measures for teams lacking deep CSS expertise, and notes that native CSS features like cascade layers, scope, and container queries are on the way to address the same pain points. A key segment covers when JavaScript is genuinely necessary for accessibility—interactive components like modals, tooltips, and dropdown menus require JavaScript for focus management and keyboard events, even if CSS handles positioning and styling. The conversation then shifts to Eleventy, where Eckles shares her enthusiasm for the static site generator's flexibility, its serverless capabilities for dynamic routes and search, and why she still pairs it with Sass. She closes with predictions about CSS trends, emphasizing better browser tooling, continued language evolution, and the importance of community education.

Chapters

00:00:00 - Introducing Stephanie Eckles and Defining Modern CSS

The hosts welcome Stephanie Eckles, recognized for her work in both the CSS and Eleventy communities, and set the stage for a conversation about what "modern CSS" actually means. Anthony notes the show has recently made an effort to bring on dedicated CSS experts and asks Stephanie about the origin of the term.

Stephanie explains that while she didn't coin the phrase, she helped popularize it. With nearly 15 years in professional web development, she's witnessed the language's transformation firsthand—from battling IE6 bugs to leveraging today's powerful browser capabilities. She emphasizes that the "modern" label reflects not just new features but also the unprecedented pace of CSS evolution and the strong cross-browser support backing it.

00:03:08 - The Evolution from Tables and Floats to Flexbox and Grid

Chris raises the question of whether CSS truly became modern at some point or has simply been evolving continuously. The group traces the history from table-based layouts in Dreamweaver, through the Web 2.0 era of border-radius, box shadows, and gradients, to Bootstrap's 12-column float grid system and the eventual arrival of Flexbox.

Stephanie recounts learning CSS in a college class when three-column float layouts were the standard and responsive design wasn't yet a concern. She highlights how each wave of features—from eliminating jQuery hacks for visual effects to abandoning floats entirely—removed real pain points. The discussion underscores that browser compatibility has been just as critical as feature development in making CSS feel truly modern.

00:09:43 - CSS-in-JS, Scoping, and the Cascade Trade-offs

Chris pivots to CSS-in-JS, asking why developers gravitate toward solutions like styled-components over native CSS. Stephanie draws on her experience leading a cross-browser design system built on Material UI, explaining that CSS-in-JS and similar frameworks often serve as stopgap solutions for teams that lack deep CSS skills or want to avoid cascade and inheritance issues.

Anthony presses on whether scoping everything is inherently bad, and Stephanie clarifies it's about trade-offs, not right or wrong. She argues that bypassing the cascade can lead to missed reusable patterns, duplicated styles, and gaps in accessibility. The conversation connects to BEM methodology and how React's ecosystem has fragmented CSS approaches, with Chris noting that many of these "new" problems echo challenges developers have faced for years.

00:15:33 - Native CSS Solutions: Cascade Layers, Scope, and Container Queries

Stephanie pivots to what the CSS Working Group is doing to address the very problems that CSS-in-JS tries to solve. She highlights two proposals—cascade layers and native scope—that are actively being developed and are expected to land in browsers, noting that teams locked into external solutions may miss these powerful native alternatives.

The discussion touches on the performance implications of adopting native features over JavaScript-based workarounds. Stephanie frames this as part of her broader mission to educate developers about what CSS can already do and what's coming soon, encouraging people to avoid reinventing solutions that the web platform itself is building in. Container queries also come up as a long-awaited feature with significant progress already made.

00:16:45 - JavaScript, CSS, and Accessibility

Anthony steers the conversation toward accessibility, referencing a stream Stephanie did with Ben Myers about when JavaScript is genuinely necessary. Stephanie explains that while CSS-only solutions for components like modals, tooltips, tabs, and dropdown menus are creative, they often rely on checkbox hacks that create confusing experiences for screen reader users.

She breaks down why interactive components need JavaScript for focus management, keyboard navigation, and proper event handling, while CSS still handles the visual presentation like positioning modals with Grid. Drawing on four years of working closely with accessibility experts, she advocates for understanding both tools and using each where it's strongest, rather than forcing CSS to handle everything alone.

00:20:32 - Modern CSS Toolbox: Selectors, Math Functions, and Sass

Anthony asks Stephanie to highlight key modern CSS features beyond Grid and Flexbox. She points to advanced selectors that aid with scoping and inheritance, and CSS math functions that enable responsive, device-friendly scaling for things like fluid typography and dynamic spacing—areas where CSS can now replace what previously required JavaScript.

The conversation transitions to Sass, where Stephanie explains why she continues to use it alongside native CSS custom properties. She values Sass for file organization, static variable handling, sophisticated theming structures, and utilities like color functions and each loops for generating component variants. The discussion also briefly covers PostCSS, with Stephanie noting she uses it only for Autoprefixer and CSSNano at the end of her build process.

00:28:52 - Eleventy Serverless and Expanding Static Site Capabilities

The focus shifts to Eleventy Serverless, which Stephanie has explored extensively. She explains how it allows developers to create dynamic routes processed by Eleventy on a server, combining the generator's templating and data features with capabilities typically associated with frameworks like Next.js, all while keeping the rest of the site static.

Stephanie shares practical examples, including a demo app that processes image URLs to find focal points and a static search implementation that eliminates the need for services like Algolia. She also mentions Zach Leatherman's experiments with OAuth through Eleventy Serverless, noting that these capabilities are breaking down the traditional limitations of static Jamstack sites and pushing Eleventy toward full-stack territory.

00:31:43 - Streaming, Community, and the Future of CSS

Stephanie discusses her approach to streaming, explaining she initially started to practice presenting live for virtual workshops and conferences. She describes her Dev Roulette show featuring mystery guests and shares how streaming has expanded her network and connected her with communities she wouldn't have found otherwise.

The episode closes with Chris asking about CSS trends over the next three to five years. Stephanie predicts cascade layers, scope, and container queries will be the biggest additions, alongside smaller but impactful features like new color functions and math capabilities. She emphasizes that browser compatibility and improved developer tooling—like Chromium's Grid visualization—will be just as important as language evolution, and encourages developers to write about both their CSS discoveries and struggles to help shape the language's future.

Transcript

00:00:00 - Anthony Campolo

It's a car-centric world. You did have trains, though, until you ruined that. How dare we. We'll bring back trains just for you, Chris. Trains are the way. Stephanie Eckles, welcome to the show.

00:00:20 - Stephanie Eckles

Thank you.

00:00:21 - Anthony Campolo

You are a very well-known personality in both the CSS world and the Eleventy world. We have a lot of great stuff to get into. You also do a lot of streaming. I've gotten the pleasure of watching quite a lot of your streams with guests like Ben Myers and other good friends of mine, so I'm really happy to have you.

We've made an effort to bring on some real CSS experts recently because it's something that we have kind of neglected throughout the first year of the show, I think. You are one of the biggest proponents of what you're calling modern CSS. First of all, I'd be curious, is that a term you're coining or someone else is using? Where did that specific term come from?

00:01:02 - Stephanie Eckles

Good question. I'm sure I read someone else reference it. I will not claim to have coined it. I will claim to have made it more popular as the phrase being used.

Modern CSS felt appropriate to me because I have been a professional web developer for almost 15 years, so I've seen a good chunk of the evolution of the modern web as a whole. Being able to compare, in my own career history, the tools and capabilities that we have both in the language and in browsers today versus 10 or 15 years ago, and of course more for those folks that have been around since the very beginning. I remember some of my first bug busting was in IE6 and IE7. Compared to that, I would call what we have now modern, for sure. It is definitely paving the way forward in this huge push toward the rapid evolution of CSS as a language. So all those factors combined.

00:01:58 - Anthony Campolo

CSS has been something that I know historically developers used to complain a lot about and really, really hated. But I think that it's a lot harder to complain about it now because, as you're saying, there's just so many things that have been added to the language and things that have really helped with developer ergonomics, layouts, and all sorts of stuff.

So for me, if I was to think of when it kind of transitions from pre-modern to modern, I usually think of Flexbox as a big crossing point. This is kind of interesting because, in my bootcamp, we would learn CSS up to Flexbox. They didn't teach us Grid, even though this was in 2020. Grid was definitely a thing by then, but it seems like they felt that Grid was a little bit too modern. But I think that you probably tell people to use Grid today, right?

00:02:49 - Stephanie Eckles

Yes, absolutely. In fact, I just had to look it up this past week so I had this stat ready. We have had Grid stable in our evergreen browsers since 2017. So that's four years. Absolutely. That misconception is something that has been a motivator for the work that I do, for sure.

00:03:08 - Christopher Burns

Fifteen years is a very long time. It's almost like we're Russian dolls. I've been doing development double the amount of time Anthony's been doing development. You've been doing development double the amount of time I've been doing development. And obviously when I started learning to program websites, Bootstrap 3 was at its height. We had tools like Gulp and Grunt, and they were the main tools.

Where I'm going with this is you've obviously just spoken about Flexbox as the changing factor of a modern language, but when has CSS been modern? Because in my eyes it's always been the same. It's always just been a language from day one, a modern language that goes hand in hand with HTML. I never saw it as this next evolution, like Flexbox and Grid were the next evolution. But then I can see how you would say they were, because in the Bootstrap days we had cols of 12 that we used, and we did a lot of tricks.

[00:04:08] So has it become modern, or was it always modern and it's just changing? Evolutionary.

00:04:15 - Stephanie Eckles

Yeah, a really good question. I think that you could point to a couple of things where folks who had been having different pains could definitely point out, like, this made my life easier. Yes, ultimately it's evolution of the language.

Flexbox, but also I'd have to go see which came first. I believe before Flexbox, at least before it reached maturity, one of the big things was, and this is going to sound silly if you are newer to the field, getting border radius and box shadows and gradients. I don't want to dive into a tangent of Web 3, but we called that Web 2.0, when we got all those things. That terminology wrapped it up because it removed so many hacks within just a few months. We all got performance gains because we didn't have to use jQuery as much for some of these things or try to slice and dice out of Photoshop to achieve repeating seamless box shadows and all of these things. It sounds kind of silly, but those were real pain points, especially because the design of that time demanded those features.

[00:05:17] That was definitely one of the things that started to turn the language, and then definitely Flexbox. We were able to abandon floats, which again came with their own trickiness and hacks and nightmares. I definitely hear what you're saying.

When I started, when I can point to being aware of CSS as a powerful language, was I took a one-hour credit class at my college. It was just like an opt-in class on CSS, which at that time they were teaching tables. But that professor was clearly looking ahead, like, okay, I'm going to attempt to offer them what we have available. I had been hitting my head against the wall. I'd been trying to build a WordPress theme, and the style at that time was three columns, two sidebars, and a large content area in the middle. Every site looked like that, every WordPress site, and that was very tricky to do. So this class opened my eyes to how to fix my floats and also how to do absolute positioning, which was okay because we didn't have the iPhone yet, so we weren't worried about responsive design yet.

[00:06:19] For me, I can understand the idea of, oh, I just didn't know about the feature in the language, but not necessarily recognizing that a particular feature was newer or necessarily being aware of the support of that feature. But I think the support factor is the other reason for not entirely calling things evolution. It is an evolution, but at this particular time over the last couple years and the pace of the language right now, it's not just the pace of the language, but it's also having that parity across browsers. That's another huge part of why I feel comfortable calling this period of time, you know, when we've achieved this more modern language, these more modern features and capabilities, is because of the browser support also backing those things.

00:07:01 - Christopher Burns

There's a really interesting word you used there. You said we dumped float. That's such an interesting statement. If you've joined the web industry after Flex came out, you won't even understand the tricks we had to play with float that came back in the Bootstrap 3 days. I remember building my first website in a table in Dreamweaver back in secondary school in the UK, so that would be like 12, 13, 14. Now I'm 25, so that must have been 12 years. Tables were the thing then.

Then you had that moment where the grid was created, as in Bootstrap really pioneered the concept of a grid, i.e., 12 columns, that a div could be floated between multiple columns. You always thought in sixes or threes or twos. If you want two equal boxes it would be six and six, or three, three, three, three, and that's your fours. So you had that.

[00:08:09] It wasn't necessarily responsiveness yet, as you said, because iPhones still weren't massive, but they were starting to take off. But then that's when we had to, if I remember, start playing around with class names, just like we do today with Tailwind, before we had media queries properly in Bootstrap. This is a long time ago.

00:08:29 - Stephanie Eckles

I grew up with Bootstrap 2. I'm trying to remember too.

00:08:33 - Christopher Burns

Yeah. It's that evolution of today: a grid is no longer a grid of 12. If you want two equal boxes, you do a grid of two. It's a really good abstraction.

So, as you said about the language being modern towards the concept of grid, the concept has been ingrained into us for like 12 years, but it's only been part of the language for, I forgot the date you said. But it's that abstraction.

My big question that I have with what was not in the framework before is core concepts of CSS-in-JS. What do you think the benefits are that everybody is using that over standard CSS? Because all it's doing is allowing you to define your CSS styles in JavaScript and basically have them injected in. The only reason I can see now in using it over CSS is variable support. I think personally it's so much easier to define a color variable in CSS-in-JS than it is in standard CSS. You know, if you look at styled components, one of the default customizations is make the button red with the simple primary thing.

[00:09:43] Doing that in standard CSS, I think more knowledge is needed, if you get what I'm saying.

00:09:50 - Stephanie Eckles

No, I absolutely do. Just as relevant experience to what you're talking about, I led the development of a cross-browser design system for a couple of years. And what that meant is suddenly I found myself primarily writing React while also building out the design system, which included caring about semantic, accessible HTML, for starters, and then building out our CSS framework. Disclaimer: we did base it on Material, so we were using Material UI, and they have a really great theming system. It's really well thought through.

That said, when you're talking about that as a general solution, the idea of CSS-in-JS or related solutions there, what I found through that experience, talking to different devs, doing research around that field, was that similar to other CSS frameworks in general, it's a stopgap solution for not having that full skill set on every team. And like you said, not learning CSS maybe as deeply. It's a fascinating phenomenon. I can't fault teams for seeking those solutions. Of course, there are super valid reasons they choose that solution.

[00:10:53] I just find it a little unfortunate, because it means that the front of the front end and CSS become less valued as a skill. I imagine designers are feeling a little less valued as well because they're getting replaced with those solutions instead, which brings up other concerns related to UX and accessibility.

But anyway, I know the reasons. People will try to say it's performance. Essentially what they're trying to solve is issues they may perceive with the CSS cascade and inheritance. So by using those solutions, they are essentially scoping every single style and encapsulating that and not even having to worry about styles escaping.

00:11:34 - Anthony Campolo

So what is the issue with that? It sounds like you're saying that's a bad thing and that shouldn't be done. Could you dig into why it's a bad thing to scope everything and to ignore the cascade entirely?

00:11:44 - Stephanie Eckles

It's not a bad thing. It's just what those solutions are addressing. So you either learn and embrace CSS or you pick up the solution because it works. It's not necessarily negative.

However, I think one downside, again, coming from a design-systems-minded background, is maybe not being able to spot those repeatable patterns. What also gets skipped in that process is the understanding that, just like the rest of your application that you're building out, CSS has to be architected. It's no less valid. What also gets skipped is if you're not able to peel back and look at things from a component-based structure, whether that's a true design system or just shifting your mentality, you maybe are building things more than once. I'm talking now about your whole system versus just CSS, but you'll probably be writing the same CSS styles more than once, too. This is where our utility frameworks have come from. That opens up another bag of worms of trying to upgrade solutions and all kinds of things.

[00:12:40] So I'm not saying these things are negative. It's just being aware of the trade-offs that are happening here. Being aware of your own team skills is probably what it comes down to. It's often either skipped as a core skill set of having that front of the front end in place of all full-stack developers. When that happens, you're probably missing some accessibility because you're missing that skill set that's focused on the end user as much as just making the system work and plugging in those readily available solutions. I'm advocating for being aware of those different trade-offs, not necessarily saying this is bad, but just be aware.

00:13:15 - Christopher Burns

As you said, Anthony, why is it bad to scope it? Instead of having it all cascading, even from 2000, we've been looking for ways to encapsulate that CSS, making sure that it's not as reusable, more specific.

This is where I bring up my good old days as a CSS developer. BEM, or BEAM, whichever way you say it, the standard classic thing. I've quickly pulled up the CSS-Tricks article on it, obviously from 2015. You look at that from seven years ago now, the concept is exactly the same as what we're trying to do with CSS-in-JS now, of encapsulation, making sure you can understand what the element is just by its markup structure.

I think the most interesting thing about it all is, has React just ruined everything? The more I learn React and the more I learn things like Vue and Svelte and other things, the more I think, yeah, React is just making everything really complicated and just pulls you completely out of that old way of web development. But it's not necessarily the old way because so many other frameworks still do it that way today.

It's just, as you say, when you drop it, as I've dropped it for React, you start thinking in the React way of everything. And that's where even doing BEM in React is a little bit harder, because obviously there's 20,000 ways of doing CSS in React, and which one's the best one? Who really knows? Should you even do it? Who really knows? Is Tailwind really good? Who really knows? I was gonna say, well, we don't know yet. Let's ask in five years.

We like to think the landscapes are moving really fast, but we're still dealing with old problems, is what I'm trying to say. Not old problems, but old thoughts. Old things like how should we do a calculation? How should we make sure that I can easily change a button from my primary color to my secondary color? And then we've had tons of other things chucked in there since, like Flex and Grid, that made it all simpler. But then we've had other things like dark mode scheme, accessibility hooks, more responsiveness. There's just so much. So much has happened since BEM was released.

00:15:33 - Stephanie Eckles

One quick note before we leave that topic: It's not as if the folks in charge of writing the CSS language, the CSS Working Group, are completely unaware of those solutions. Of course they're not. They're amazingly aware of them. And in fact, they're working on two proposals in particular that will address those things in native CSS.

Just want to mention them. For those that haven't heard that this is on the way, we have both cascade layers and also actual scope in CSS that is coming. These are not completely theoretical. Cascade layers is being worked on. It should probably land experimentally pretty soon, and scope is in a very good place as well.

So again, in terms of the modern CSS idea, if you shoehorn yourself into these solutions, you may miss what's native to the language. And that comes back to you on cost and performance and probably that whole thing we all battle against as we try to do our jobs but also stay up to date on things, trying to reinvent the wheel. And then that wheel lands in the web platform itself.

So, I mean, that's kind of where I found myself, just trying to generally educate about what is available and really address those practical needs.

00:16:45 - Anthony Campolo

So now I was curious about that, kind of segueing off of this, is that when I was watching a stream you did with Ben Myers, you were having a conversation about when to actually use JavaScript for accessibility. We've talked about accessibility so far, and this is something that I know you are a very big proponent of, and it's one of the things I really love about your work.

We brought Ben on last year to do a whole episode on accessibility, and I've learned so much from Ben about all of this. You two had a great conversation, which is that you shouldn't be afraid of JavaScript and you shouldn't really try to create a zero JavaScript solution, because there are things that you can do with JavaScript that are useful and do make websites more accessible. It's about knowing what those are and how to do that correctly.

So I'd be curious if you can go into that a little bit. What would actually be an appropriate time to use JavaScript and not CSS for accessibility?

00:17:39 - Stephanie Eckles

Yeah, absolutely. I'm really very passionate about this topic, so much so that I have an article on Smashing Magazine exactly about it.

I love seeing folks' creativity. There's so much of course that is related to CSS. Folks love building CSS-only games or art, which isn't intended to be functional necessarily. But there are specific components, basically any component that has interactivity tied to it. I'm not talking about the items that would be exempted from that, like standard checkboxes, radio buttons, ones where you're simply picking up on the checked state, for example, and giving it a slight style. We have to think about other accessibility concerns, but we don't necessarily need JavaScript for those events at a standard, basic level.

But the ones I've seen, like creative solutions that attempt to be CSS-only, would include things like tooltips, modals, tabs, carousels, and dropdown menus. Most of those you can get a decent way there, but you're probably using hacks. In fact, a lot of those use something like a checkbox because it gives you the ability to tap into a boolean state. Folks are like, oh, okay, if I have a boolean state available, then I can change what gets rendered to the page if I can detect essentially true or false.

The problem is that when you generate a component that is made visible by checkbox, starting way back at perceiving what that element is going to do, folks who are maybe not sighted will encounter that and have it read to them as a checkbox. Then that might be confusing. Then also, if you are revealing content that's like a tooltip or dropdown menu, that might not necessarily be logical to them. You might also need to have those events controlled by keyboard or accessible by a series of commands. So you have all these events.

[00:19:35] Events are thrown to JavaScript and that's appropriate. We can get a lot of the way there, and definitely on the styling part alone. For example, positioning that modal in the window. We can now do that with Grid rather than trying to use JavaScript to measure client height or whatever you may have done in the past to position that modal. We can do that part with CSS, but we have to tap into JavaScript to manage focus and some other related events.

Yeah, definitely something I'm passionate about, something I've had to learn a lot about as well through my own career development and being fortunate to have had about four years now where I've had pretty direct access to some really fantastic accessibility experts and advocates to be able to learn those things. So definitely a key part of these things. Again, it doesn't mean that CSS is completely out of the solution. It can get you a lot of the way there, but there's still a little bit left for JavaScript on those more interactive components.

00:20:32 - Anthony Campolo

Yeah, it's the right tool for the job is really what it always comes down to.

I'd like to get into some Eleventy stuff, but before we go off of modern CSS, there was a really great Learn with Jason you did where you just went down the list and taught a whole ton of stuff, so I'll point people there. But are there any other specific things that you'd like to point out as what you consider key pieces of modern CSS beyond Grid and some of the other things we've already talked about?

00:20:58 - Stephanie Eckles

Yeah, Grid and Flex are definitely something I talk a lot about. I think that getting more familiar with the different selectors in CSS, sometimes it's really about just going back to the basics so you can help choose the right thing for the job, like you were saying earlier.

Selectors are something you may have gone over super briefly a long time ago, but we have some really sophisticated ones now, including ones that can help with the idea of both scoping and inheritance. So I have a couple of articles on those.

Something else I've been really into that's definitely a modern category would be our CSS math functions, being able to wield those. There's so many practical applications for those, from controlling dimensions, but also doing it in a way that is future-friendly for the huge array of devices that we have to deal with. I'm talking about being able to sort of intelligently build in ways to scale up and down, which also has implications for accessibility, things like fluid type sizing, controlling spacing across changing aspect ratios of devices.

[00:22:00] So all of these things where now you can do those. That would be an example, kind of the reverse of what we were just talking about, where you can bring stuff back into CSS that maybe you were handling via JavaScript. That's pretty exciting. That's fun to get familiar with and add to your toolbox, as I tend to say. But yeah, there's just so many practical applications of Grid, so it's definitely something you'll find me talking about, maybe the most.

00:22:22 - Anthony Campolo

Awesome. Yeah, and we're dropping tons and tons of links here for anyone who's listening to this and wants to learn more. You are such a prolific content creator, something I really admire about you, and you have your own podcast. Why don't you tell us a little bit about that? You were really, I think, a core Eleventy advocate. You have a specific term you call yourself. What was it?

00:22:43 - Stephanie Eckles

I think for a while I was saying that I was the unofficial ambassador.

00:22:47 - Anthony Campolo

That's the one.

00:22:48 - Stephanie Eckles

Yeah. The podcast, we've talked about Eleventy. It's kind of a general-purpose podcast. I'm a co-host for it. It's called Word Wrap. We definitely did talk about it at some point. But I have the site 11ty.Rocks, and I'm a little behind on updating it.

But for my own personal work, Eleventy static site generator is my primary tool of choice. Or even if I'm spinning up a demo work environment, I tend to reach for it just because it includes BrowserSync, so I don't have to rewire that up, which I definitely have done in the past. I don't have to copy in a Gulp config or something, but I love the flexibility of it. It literally got me re-excited about web development, and it has been my enabler for all of my projects because it has a ton of flexibility.

If you're unfamiliar with it, it has ten different templating languages. It's great to be able to write in Markdown in one, you know, my primary blog area, but also have flexibility for templating features to loop through things or generate a random item or something like that.

[00:23:48] It has a really easy way to hook into external data, so you can create a file that does a fetch, and that data is instantly available to you anywhere in your site, which is really awesome. And of course, the features you might expect, being able to template things. It's really customizable to how you want to do your assets. There's not a bundler included. Folks have created starters. The community is really great. So there's starters that include Webpack, Parcel, Rollup, whatever bundler of choice you would like.

00:24:15 - Anthony Campolo

What are your thoughts on Slinkity?

00:24:17 - Stephanie Eckles

I think it's a really fun project to watch. I don't currently have a use case for it, but I know that a ton of people do. I'm just not doing a lot of interactive projects personally. I have one that was built with Eleventy, but it was very low key. It was not a full SPA or anything. It was just one section on the site that needed interactivity, so vanilla was totally fine.

But yeah, Slinkity is exciting. It's using, to talk about modern, probably the most modern phrase we have right now besides Web 3 would be islands architecture. Being able to hydrate just parts of the page when you'd need to, essentially, is my understanding of what that boils down to.

So I mean that's great. The idea too is that with Eleventy folks can write JSX or these other things that they're familiar with as templating languages and static renders, unless you need to hydrate. So very cool idea. I'm on board with it, absolutely, especially from a performance perspective.

[00:25:09] Yeah, very well thought through, and got to love Ben Holmes. He's a great maintainer and creator of that. Such a good community member.

00:25:15 - Anthony Campolo

Yeah, and you mentioned starters. You have your own starter, the Eleventy Sass Boilerplate. I know that Sass is something that seems to have stuck around, surprisingly enough, despite CSS bringing in many Sass features into the language. So what do you think is the appeal of Sass? Why do people still use Sass? What has kind of kept it in the web dev conversation?

00:25:40 - Stephanie Eckles

One thing we don't have in native CSS as easily, that I appreciate in Sass, is just being able to more easily organize my different parts and pieces, but still, for example, have a typography-dedicated file and so forth. But I can ultimately bring those in and compose those into my stylesheet.

I appreciate that there's also, even though we have CSS custom properties, which I definitely am making heavy use of, I still will use Sass for those properties that are static or I need to maybe do math operations ahead of time. You're going to have currently more sophisticated math methods in Sass, but some of those are coming to CSS as well.

Also, if you're building out a framework or a design system with Sass, you can set up your structure for theming in a bit more sophisticated way as well. I also enjoy, again, if I'm thinking about creating variations of components, for example, like I want to generate different colors of my buttons, I like being able to feed it a list of colors and then it outputs the class names in an each loop.

[00:26:39] So just kind of shortcuts that I appreciate. Nesting is coming to CSS, but of course it's not completely stable yet and it won't be stable for quite a while. I do enjoy personally that syntax. I know that's a little polarizing, but I do enjoy it.

You'll see in my work, and something I teach in a workshop I do, we intermix Sass and custom properties. It's just, are they intended to be compiled in the browser? Are you taking advantage of some inheritance that's going on there, or is it more static and it's best served in Sass, or are you using other Sass methods? I mentioned math. I also use various Sass color functions to quickly create variants and things. For me, it still has a lot of practical applications. And even with different things coming to CSS, I will probably not be moving away from Sass anytime soon.

00:27:25 - Christopher Burns

What are your thoughts on PostCSS as a replacement for Sass? To my understanding, both tools can accomplish the same things, but one has it all built in by default, Sass, and with the other you can get the Sass experience of nesting and everything, but it requires plugins. Do you think there's room for both to exist still in the future, after CSS has implemented a lot of the things that they had stood themselves apart from for a while, if that makes sense?

00:28:02 - Stephanie Eckles

It makes sense. I don't have very much experience with PostCSS, though. I use it at the end of my build process only to run Autoprefixer and CSSNano. Then recently I added the plugin to convert logical properties so that I could start writing them in my stylesheet, but for now they're getting converted to non-logical properties. Those are the only ones I personally use.

Sass, I think maybe another benefit is, like you said, since it's plugin-based for PostCSS, not having to research which ones to compose together, especially if you're documenting things or sharing among a team, just being able to load the one thing in your builds.

But again, not having too much experience, I have not ever wired together different CSS things for a build. So I know Adam Argyle talks about that a lot. He's the main advocate I see for it. He's not a core maintainer necessarily, but yeah, just not my wheelhouse of knowledge.

00:28:52 - Anthony Campolo

We slid back into the CSS for a couple more Eleventy things I was curious about. I know that you've messed around a lot with Eleventy Serverless to the point of kind of breaking it, I think.

00:29:02 - Stephanie Eckles

Yeah, yeah.

00:29:03 - Anthony Campolo

How are you using Eleventy Serverless? What do you think is interesting about it and how it's going to expand out the capabilities of Eleventy?

00:29:11 - Stephanie Eckles

The summary on Eleventy Serverless is using what you're possibly familiar with, though it's actually not even within a serverless function. It's kind of a confusing name, but the idea is that you are throwing a build of Eleventy to whatever server. This is going to be a little bit host-dependent too, if they can do it. But you can create essentially dynamic routes, but you're ultimately processing those with Eleventy. So you have all the features of Eleventy, like the templating and data processing, but you can generate a dynamic route essentially that might be one of the motivating reasons you folks have had for choosing React or something, or Next, if all they ultimately want is static. Maybe Eleventy Serverless can fill that for you.

So I used it to create just kind of a demo app where you could give it an image URL and optionally some other parameters. What it does is it returns you some CSS to find the focal point of that image. So if it's a portrait, to make sure that whatever crop you would like on it, whatever the aspect ratio, that face is within the frame. That was kind of interesting because that was using Eleventy but also gave me the ability to incorporate the sharp package.

[00:30:18] So basically any other tools that you would need for processing, again, that maybe you would not reach for a static tool to do a dynamic result. That's what Eleventy is going to actually offer for you. So it's nice because it's opt-in, so you don't have to use it. If you choose Serverless, you can do it on one route. It doesn't mean that your whole site becomes generated that way. You can keep everything else perfectly static.

But yeah, there's just a lot of opportunities. I know Zach, the creator, Zach Leatherman, was just experimenting with it for OAuth and doing that validation. So definitely it is going to really kick down the doors of what we thought were limits on static Jamstack sites.

00:30:57 - Anthony Campolo

Yeah, that's awesome. And bringing in auth and stuff like that, that is FSJam's wheelhouse right there. That's one of the big things we're always talking about. You need to have that if you want to build an application and not a website. So I think it's so great that it's like, we want to be full stack too. We're all about that.

00:31:14 - Stephanie Eckles

Yeah, I kind of forgot I did that search one that you added in there too. But yeah, it definitely opens up the idea of completely static search. So not even having to use Algolia is super great, but the idea of just a simple form submit and then returning search results, that's something I worked through how to do with Eleventy Serverless. Super practical use case, right? Because of course that's going to be dynamic, but you don't have to pre-generate that or anything. You can still get similar functionality. So yeah, really exciting potential use cases for that.

00:31:43 - Anthony Campolo

Great. You are a prolific streamer, along with all the other content you do in terms of writing and podcasting. I'd be curious to know when you stream. How do you think about that? Do you bring on guests? Do you just create your own content? Do you like going on other people's streams? What do you think is kind of the value add of streaming for you?

00:32:04 - Stephanie Eckles

Great question. When I initially started doing it, it was because I was selfishly needing practice for presenting live for an extended period of time. As I was heading into doing my first virtual workshop series, I can say that if that's something folks are interested in, increasing their general confidence for that or virtual conferences, I highly recommend starting to stream. It also helped me not feel like I had to be completely polished every time, which was big.

I did a show for a couple months there. I called it Dev Roulette, where I brought in mystery guests. I think we did six or seven shows, a few with CSS-related guests and then a few with accessibility. I'd like to bring that back for the new year, but I just got other things that I had going on.

Otherwise, I've enjoyed joining other folks' streams. I think the back and forth is really nice because, otherwise, you're sort of talking to your chat and they may or may not be super interactive, depending on the subject matter and time of day and so forth.

[00:33:03] So it can be really fun to either go in with a full agenda or to just be casual and welcome chaos and see where the stream leads you both. It can be fun. It's definitely how I found some of my favorite communities, though.

Another big pro, I think, is otherwise Twitter is my main place that I'm interacting with folks or finding news about what's going on in the web world. So streams have been awesome for just expanding my overall network and meeting some new folks and, of course, learning tons of new things about all sorts of stuff. So I really appreciate folks like Alex Trost on Front End Horse or Jason Lengstorf on Learn with Jason, who are committed to bringing on different guests, and you can learn so much in such a short amount of time. So it's a very cool medium that's been fun to watch get more traction over the last year or so.

00:33:50 - Anthony Campolo

Yeah, we had Jason on a while ago, episode 38, and it hasn't ended yet. But we have Alex Trost we interviewed a couple of weeks ago, so he'll have an episode coming up as well.

Streaming is just so much fun. I love it. I love streaming myself. I love hanging out on other people's streams. The thing you said about using it as a networking opportunity, it's so great to expose you to all these people doing all this fantastic work out in the web dev community. There's just so much going on, and giving people that space to just, you know, for an hour, be like, here, let me show you all the stuff I can do. I love that. I'm all about that.

As we're closing it out here, are there any other questions you have, Chris, that you want to cover?

00:34:30 - Christopher Burns

You mentioned two of the things coming to CSS, native CSS. What do you think the trends are going to be in the next three to five years?

00:34:39 - Stephanie Eckles

Trends. Trends in terms of the language evolution, web trends.

00:34:44 - Christopher Burns

Trends as in the language of just CSS, what we're going to do with it, or where the language is going to evolve to.

00:34:51 - Stephanie Eckles

I think it's going to be cascade layers and scope. The other big one that has a lot of progress already made is container queries. These are all in response to either issues we've had for a long time or bringing some of those external solutions back into the language.

I think we'll probably see more of that. Those are covering some really big pain points, especially container queries. That has been pretty long standing. I think it's going to be smaller but impactful features, maybe less impactful in terms of scope of who's using them, things coming to the language, things like different color features, like I said, more math functions.

I think what we're going to also see, though, is making sure browsers get all that compatibility. That's going to be the biggest push. The language is evolving, but also just getting browsers on board to get those in as soon as possible so we can use them, I think.

[00:35:44] Alongside of that too is better tooling within browsers would probably be the upcoming push versus maybe slightly less in the language. Not that it will stop evolving, but better debugging tools and things is something I see already. I've seen a lot of movement in even just the last few months, and I see that part continuing, and also the education part continuing. At least I'm hopeful.

Basically, if you have learned something in CSS recently, please write about it. Likewise, if you have a constant struggle, please write about it because the CSS Working Group is watching and listening, and you never know if those will make it back into browsers in the language.

00:36:24 - Christopher Burns

I have to admit that the dev tools that Chromium has been adding around Grid support are really quite good to actually allow you to visualize the actual grid on the page. Not just pretend you know what the grid looks like, but actually just show the grid.

I guess my final two quick questions: Pixels or rems?

00:36:44 - Stephanie Eckles

Rems 100%.

00:36:47 - Anthony Campolo

Rems versus ems. I thought everyone knows you're never supposed to use pixels.

00:36:51 - Christopher Burns

People still use pixels. Okay. Rems versus ems.

00:36:55 - Stephanie Eckles

Rems most of the time, unless I actually want it to be font relative.

00:36:59 - Christopher Burns

And that's not even describing the difference between the two. And also what color format do you define your colors in?

00:37:06 - Stephanie Eckles

I've become more of an HSL person, but that's just been in the last few months.

00:37:12 - Christopher Burns

There we go. HSL. Everyone talks about using it for how long it's been supported now for years. So many of us still use RGB. But yeah. Thank you for coming on the show. Where can listeners find you?

00:37:26 - Stephanie Eckles

Yeah. So definitely most active on Twitter, @5t3ph, which is also my username on GitHub and CodePen and most places. And if you are interested in improving and upgrading your CSS toolbox, my main place that I'm writing is ModernCSS.dev. And I guess from either of those places you can get back to the other stuff I'm working on.

00:37:49 - Anthony Campolo

Very cool. Thank you so much for being here and sharing all of your knowledge on the wide, wide array of things you do. I'm just so glad that you're out there putting out all this content, because I learned so much from it. So keep doing what you're doing.

00:38:02 - Stephanie Eckles

Thank you very much. Thanks for having me.

00:38:34 - Anthony Campolo

It's good. Awesome.