They talk about the importance of accessibility in web design, how the web went from table-based layouts to modern CSS techniques, and exciting developments coming to CodePen 2.0.
Chris built CSS-Tricks, a website all about building websites, and ran it for 15 years, from 2007 to 2022, before selling it to DigitalOcean.
CodePen is an online community for frontend developers where you can build, deploy, and show-off your code. CodePen 2.0 is their all-new IDE that is currently in private beta.
Check out Chris’ blog and his podcast ShopTalk.
TRANSCRIPT
[Intro Music]
Ryan Donovan: Hello everyone, and welcome to the Stack Overflow podcast, a place to talk all things software and technology. I'm your host, Ryan Donovan, and today we're talking about CSS, the lesser-known, perhaps, of the big web technologies. But my guest today is Chris Coyier, who is the founder of CSS-Tricks and CodePen. We're gonna talk all about what the state of the art of CSS is today. So, welcome to the show, Chris.
Chris Coyier: Thanks for having me, Ryan. I can't wait to do that. Wow, man. Lesser known of the languages, that's true. I guess that's true.
Ryan Donovan: Yeah. It doesn't get the glory that I think JavaScript does.
Chris Coyier: Oh, certainly not. Yeah, certainly you can't beat big JavaScript, for sure. Yeah, yeah. I'm Co-founder of CodePen with my Co-founder Alex Vazquez. And yeah, I was the creator of CSS-Tricks. Still am the creator of it, but yeah, Digital Ocean owns it now and are doing a pretty good job of running it with my old editor, Jeff Graham. So, high five, Jeff. So, I don't know, you tell me about CSS-Tricks. You told me that this doesn't come up on the show that often.
Ryan Donovan: Yeah.
Chris Coyier: It is funny to me though, that it's on every website.
Ryan Donovan: Absolutely.
Chris Coyier: There's no alternative styling language. It's like, this is what you have.
Ryan Donovan: Well, back in the day, you just attached whatever styling directly to the tag itself.
Chris Coyier: Yeah. I didn't really make websites totally pre-CSS existing at all. I do remember that what people talk about is table based layout, which is fine, but that kind of co-existed with CSS for a while.
Ryan Donovan: Sure. Yeah. I think that the first websites I made were very much a series of tables. That was the state of the art back in the day.
Chris Coyier: It was, and it made some kind of logical sense. Spreadsheets and things go where you want them to go, and all that, and it's a little bit of a modern miracle that we were able to convince the world that that's too static, and that it's not flexible enough for the web, and stuff, which is now just like widely understood, and it's not done that much anymore. Also, an unbelievable twist of fate that that's still how emails are made.
Ryan Donovan: Yeah.
Chris Coyier: Shocking in a way. They could probably write a novel about that.
Ryan Donovan: Well, I'm sure with the state of the art right now is like a stack of divs, right? Could you do that in an email? Is that exploitable?
Chris Coyier: You can, it's just there's a few things that don't work in, because people think of the browser landscape, certainly during our comeuppance, that we, the browser wars, was very– people still think about browser support as they should, maybe less than they did at one point.
Ryan Donovan: Sure.
Chris Coyier: Gosh, there's so many browsers, and we have to support them all. What a hard life for us. That is nothing compared to email client diversity. Oh my god. Email clients are crazed. But there's still—and Microsoft is quote unquote to blame for this with really old versions of what is their main one... Outlook or whatever? But Outlook had some of them that, if you haven't heard this before, it sounds crazy, but it's true. It used Microsoft Word as its layout engine for emails that had some HTML support in it, but it was pretty weird. And so, still to this day, some versions of Outlook still use that rendering engine. The thing that you can't do with a div is smash its width down as much as you might want. And that even if you're trying to get fancy with layout, it's not like it's not gonna understand your div, but without tables, you don't have a mechanism for limiting the width of the email, which just that alone can be a non-starter.
Ryan Donovan: Especially with the emails within a sort of larger program on the web.
Chris Coyier: Yeah, totally.
Ryan Donovan: All right. Still good to deal with tables. It's funny you bring up Microsoft Word. I've done a couple Microsoft Word things. We use Save It as an HTML file, and it always produced the junkiest, most cluttered HTML, because it put all the style stuff within the tags.
Chris Coyier: Yeah. In a way, it didn't care. That's like a weird use of HTML, but I do kinda like it in that HTML, it's just an agnostic thing. It's just a tool. You use it for whatever you want, and in 99.9, all usage of HTML is just to make a website. And that's what's going on here. But its job, in this case, was to faithfully replicate that document that you built in Microsoft Word. It wasn't so much to be a Wikipedia page or whatever; it had a little bit of a different job at that point.
Ryan Donovan: Yeah. It wasn't meant to be human-edited.
Chris Coyier: It really wasn't.
Ryan Donovan: So, we've come pretty far from when I first made my first websites that's pure table-based, and we have CSS, and I think the last time I looked at CSS, it's just getting so much more robust. One of the last things that I saw that surprised me was that I think there was, somebody said, 'CSS is a fully complete programming language with conditional touring.'
Chris Coyier: Like during complete or whatever?
Ryan Donovan: Yeah.
Chris Coyier: Maybe that has come up recently because some of the very, very latest stuff, and I'm talking like, in the last few months really–
Ryan Donovan: Yeah.
Chris Coyier: Is that there's like an 'IF' function in CSS that has dropped, and the way functions work in CSS—and always have, for 15 longer, since you've been doing—is, even like URL with the parentheses on it, that's a function in CSS. There's a lot of functions now, more and more of them, but the way functions always work is that they return one value. And so, IF is no different, IF is perfect for that, it's, ' IF some condition, then return that one value.' 'Else' return some other value, and it has some 'else if' mechanism in the middle of it too. And CSS is such a strange language that it's not really top-to-bottom executed necessarily. So, it has some quirks and stuff in there, but for the most part, it makes sense. And the conditionals that you have access to within IF aren't just, ' IF 10 is bigger than five,' or whatever. It's different than that. You have a couple. 'Media' is one of them. So, 'media' is yet another function within it. So you can go, 'IF' and then inside the parentheses you can say 'media,' and then media has its own set of parentheses. And then you put a media conditional, like if the width is—and width refers to the entire page width—is wider than 500 pixels or whatever, then return the value red or something. That would be weird, but you could do that.
Ryan Donovan: Right.
Chris Coyier: 'Cause that media matches, or if it doesn't match, or if you know, all that. So, you have access to any of the media controls, and then there's a few other things, like there's a thing called style queries, which are for checking your custom properties. Now, maybe even that word might not land with you if you haven't looked at CSS in a long time. But CSS basically has variables now. You name them yourselves. You can go dash Ryan and then have that. Just about anything is a valid value for that, and then you use it later. Just that alone is a particularly powerful concept of those style queries that, just to come back to that, it's for checking the value of those. So, we can go, 'if Ryan is bigger than five, we can do that.' Now we've opened this can of worms cause you're like, 'what's five in CSS?' That's tricky.
Ryan Donovan: Oh, no.
Chris Coyier: Yeah.
Ryan Donovan: I understand in HTML five can be a complicated and controversial thing. It doesn't have a set value.
Chris Coyier: Well, I just mean– a literal five in the language CSS is a string by default. In JavaScript, not TypeScript, even JavaScript could suss out that a five is a number. You could ask it for 'type of,' or whatever in JavaScript, and it would tell you that it's a number.
Ryan Donovan: Yeah.
Chris Coyier: TypeScript, even better. You just tell it that it's a number, and then it's gonna be a number. CSS is typed too, but not in absolutely arbitrary values. If you say five px, then it's typed. It's a pixel. But that's trickier. Five PX as the value of a custom property works, but only if you apply it in just the right place. It's basically a string that says 'five px,' and then if you give it to the right thing, it knows what to do with that. But in other circumstances, it doesn't know what to do with that. I know that's a little abstract, but– I'm just doing this 'cause you were talking about newfangled CSS.
Ryan Donovan: Yeah. Yeah.
Chris Coyier: There's a way in CSS now to say, 'okay. My dash dash Ryan. That thing is a pixel value.' My intention for that is—in TypeScript or whatever—it's telling you what that variable is going to be, and then once it's going to be that value, I can do comparisons on it, I can animate it, I can do things that I wouldn't otherwise normally be able to do because CSS doesn't know what it is. It thinks it's a string. You can't animate a string.
Ryan Donovan: Well, that's an interesting thing you bring up about TypeScript, 'cause I feel like when TypeScript came in, everybody wanted do adopt TypeScript 'cause it was type safe. Has any of that sort of type safety migrated into CSS itself?
Chris Coyier: Well, that's what I mean. There's this declarative chunk of CSS that I could say, 'that value–' Ryan, sorry to keep making it about you, but the point is that you can make it whatever you want.
Ryan Donovan: I'm happy to apply to HTML.
Chris Coyier: Yeah. It's a big chunk of CSS that says, 'that variable that I'm declaring, I'm giving it a default value. I'm telling you what type it is. I'm telling you whether it should inherit or not inherit.' That's the type script of CSS. But it's in the native language now, unlike TypeScript, which is not.
Ryan Donovan: Some of the other changes I've seen when I looked at styling it was applying to text, applying to margins, borders, all that stuff. And now, I see things where it's like somebody has made a picture, and it's made it animated, and there's gradient, and there's scrolling tricks. There's a whole set of things that style applies to now that it didn't back then.
Chris Coyier: Yeah, just pick one out of a hat. There's so many things you can do that back in the day it was just kinda, ' I don't know, you just can't do that.' There was a lot of, ' nope, sorry. Can't do that.' And some of them feel very good to kick over the domino, in a way. A particularly interesting one lately has been what they call 'anchor positioning,' which is lots of other languages, something like Swift or whatever, when you're designing a layout for an app you can say, 'this chunk, this thing, which might be a div or might be anything else on the web, you should just go put it over by this other thing.' But regardless, on the web, we specifically deal with the DOM, it's this nested tree of crap. What's cool about anchor positioning is that it doesn't care about the DOM. You can take one thing and be like, 'go buy this other thing, but don't be constrained by whatever's happening in the dom.' And that used to matter a lot. Because for example, a tool tip is such a common pattern on digital, anything.
Ryan Donovan: Yeah. Yeah.
Chris Coyier: And you'd have to be like, 'oh, I have to be really careful to put the text of the tool tip inside the same div as the button, because I'm gonna use absolute positioning–' it's called in CSS, 'to make sure that the tool tip appears right over the button. And so, I have to be very dom conscious of that to make sure that they're in the same tree or close enough that I can use position relative and all this.' Anchor positioning says, 'I don't care at all. Give me the ID of the thing you're trying to anchor to, and I'll go anchor to it.' And you have all of this other stuff, like, what? On the side? Centered? On a corner? What do you mean? What do you want? And then what I like to see is, okay, that makes sense conceptually. We can do that now. We're catching up to the 90s of some other thing. That's nice to be able to do that. It's gonna come in useful all the time in CSS. But then you like look at the API that they've given you, and I think this is a beautiful part about CSS is that—it moves a little faster now, but traditionally, it's pretty slow-moving. We had that CSS 3 thing a long time ago, but since then, CSS moves, but not like JavaScript, where you get ES 2025.
Ryan Donovan: Sure, yeah.
Chris Coyier: There's just a yearly release. It's not really like that in CSS. It moves a little slower than that. And I'm not really involved in this process, but I do see over and over an example of an API that took a while to get done, but then once it is, you're like, 'wow, good job. You really thought about a lot of stuff here.' An example of that is this tool tip thing, where you're like, okay, I want this tool tip to be on, I don't know, the upper left of the button when it comes up, but what happens if that button is hugging the left side of the page?
Ryan Donovan: Right.
Chris Coyier: Now, it's gonna cut off. So, the API has this safe positioning thing where you can just be like, 'well, if that's the case, why don't you just flip over to the top right instead? Then if it touches the top, why don't you just flip over to the bottom instead?' And it has all these kind of fallback mechanisms built into it with a pretty clean API, but with a really simple one, and one [where] you can be super verbose about exactly how you want it to behave. So, you get both APIs, this like, ' I don't know, just flip it or whatever,' and this, ' under these exact circumstances, do this exact thing.' And you look at the whole API together, and you're like, that's a nice API. That's just what you want. It's easy to understand. It has helpful bits into it that you might not even have thought of, and it opens up the door for some pretty deep stuff if you need it.
Ryan Donovan: Yeah.
Chris Coyier: Nailed it.
Ryan Donovan: Yeah, I took a look at somebody's presentation of, ' here's the new stuff in CSS that you should look at.' And a lot of it seemed like stuff like that, where it's like somebody had coded this by hand once upon a time. And these are nicer shortcuts. There was some gradient stuff in there. There was some other stuff where I was like, somebody did that pixel by pixel, had a big CSS block to manage that, and now it's just a function.
Chris Coyier: A one-liner.
Ryan Donovan: Is that true?
Chris Coyier: I think of a couple examples of that. One of them is the scroll-driven animation things, which used to be definitely the territory of JavaScript, where JavaScript would be watching for the scroll event on either the whole page, or individual elements. And then, even that was tricky, 'cause scroll event, as you might know, just fires a zillion times as you're scrolling, and then you're like, 'well, but I want it to fire a lot because I'm moving something pixel by pixel, and I want it to move exactly with the motion of the scrolling. So, I'm not gonna use a, what do they call those? When you limit the number of events that fire quickly? There's ways to slow that down. Anyway, you can do that. I don't know, you're in this position where you're very much in JavaScript brain 'cause you're working on it. And then, CSS gets involved and comes out with this API, the scroll-driven animations. That's again, better than you think it's gonna be. They've thought about lots of different things. So, you can attach– I have this element, and it's animation timeline is the scrolling of the entire page. So, instead of an animation happening over, say, five seconds, or just some number that I just say, 'cause that's the thing you can do in CSS. Take this div, move it over 100 pixels over five seconds. That's easy to express in CSS. And then, you load the page, and you just watch this thing move for five seconds. Okay, great. You don't have to say five seconds anymore. You can be like, 'I want that div to move. The timeline is from 0% scrolled to 100% scrolled of the page.' So, it's not a time anymore, it's just a distance travelled. But that doesn't have to be the whole page. It can be the scroll position of a sub-element. And then, even cooler than that, they can say, 'that div, the timeline can be as it enters the page to as it leaves the page.' That could be the timeline. So, not a percentage scrolled, but just it's position within the visible viewport. It's just very clever, and that's the kind of thing that like, now, is easy to express, like you said, in a couple of lines of code, rather than who knows how much JavaScript, and JavaScript that probably doesn't even perform very well.
Ryan Donovan: Yeah. That's what I was thinking. Yeah.
Chris Coyier: It's just another magic of it. When things move down a level, which tends to be from JavaScript to CSS, or sometimes even from CSS to HTML, that things get better from a performance and accessibility standpoint.
Ryan Donovan: Yeah, I was thinking that if you're just catching a bunch of events, that's a pretty heavy ask of the system, I imagine. When it moves down to CSS, is it getting more into the guts of the system? Is it not touching events anymore?
Chris Coyier: Yeah, good question. I would imagine that everything is events at some level in there, but I think its chances of being what they call 'hardware accelerated' are just a lot higher at a level that I don't think any of us really totally understand. We'll leave that to the C people in the guts, or whatever.
Ryan Donovan: Yeah. Yeah.
Chris Coyier: But I don't know how to express that. I think there's things that you can still do poorly if you want.
Ryan Donovan: Yeah.
Chris Coyier: Sure. You can do too much or move things too granularly. I don't know what those things are, but yeah, the chances of you screwing it up are lower now, yeah.
Ryan Donovan: Yeah. Imagine that's the benefit of having those shortcut things is that you don't have to do the granular stuff anymore. But are there CSS use cases that you've seen that you've been like, 'this is wild. I didn't imagine this one possible’?
Chris Coyier: There's a good amount of 'em, really. The one that's I think the most shocking, or that came out of the most surprise place for me—I didn't even know you were all doing this—was a culmination of a bunch of features, but the end result is like a carousel, which is also very much a JavaScript thing. Everybody reached for slick slider, or the owl carousel, or whatever, because you got a bunch of things, and you want 'em to be swipeable on mobile, and you want a little left and right arrow, and you want little dots on the bottom, 'cause I'm gonna click the third dot and go to the third thing in there. The UX of all that is questionable to begin with. Lots of websites have that, like so many. It's just such a common pattern. They call it a carousel, usually.
Ryan Donovan: Yeah.
Chris Coyier: That can be done, believe it or not, with no JavaScript at all. Every one of those features, the little dots on the bottom, the left and right, the swiping, and it's a combination of these new scroll buttons they have in CSS. It's scroll snapping, it's this scroll-driven animation stuff. It's like all these little features all came together, and all of a sudden, we can do an entire carousel without a single line of JavaScript. To me, that's like, holy what?
Ryan Donovan: Yeah. I wonder how much of CSS as a whole and how much of the new features are driven by the explosion of different viewport types? With mobile and all these other things.
Chris Coyier: Yeah. We've lived through that already. That was the big responsive design revolution, where we have now media queries, and media queries can respond to those different sizes, and we can make drastically different choices in what we do at different widths. And it's not just widths, it's heights too, but it's also the capabilities of devices. You can write a single media query these days that says, ' is my cursor course or fine?' And course basically means a finger, and fine basically means a mouse cursor.
Ryan Donovan: Wow.
Chris Coyier: So, now that I know that what would and could I do? I could make my buttons bigger when I have a course pointer because it's a big old finger trying to touch it, and I have less control over that. I can make those kind of decisions. That's similar in decision to me than 'I have a 1600-pixel-wide screen' and 'I have a 550-pixel-wide screen.' That's very important. But there's lots of other important things, as well. There's even just user preferences, like some people are really– my mom is one of the most sensitive to movement with screens. There's a movie [where] the director is panning around a lot. She's wants to barf. And definitely strobing lights, she doesn't like. And now, you can express those things even on the web, and say, ' prefers reduced motion.'
Ryan Donovan: Yeah.
Chris Coyier: That's a media query. And you're like, then you should just do less movement. If you have somehow built into your app that when you click a card or something, it zooms up or it swooshes to the left, and a new card takes its place, you can be like, 'yeah, I like that. I think that looks cool.' But, 'if prefers reduced motion,' I'm just not gonna do that, or I'm gonna make it move 10 pixels to the left, or I'm just gonna have it fade out with opacity, 'cause that's people are less sensitive to just something fading.
Ryan Donovan: But that's one of those that the developer has to accommodate themselves, right? There's not some built-in, ' prefers reduced movement' that the browser imposes.
Chris Coyier: There isn't. It's nice that we have the tool, but that's a good point. Would that be nice? Sometimes you see it in things like what you might call a 'reset' or a 'starter style sheet' is people will put things in there, like you can see 'prefers reduced motion is true,' or whatever. You could see like, 'animation duration 0.1 second important,' or something. So, any animations, just do it quick, and get it over with, and that's a sledgehammer approach to it. The browser's not doing it, but you do see a little bit of global choices being made like that.
Ryan Donovan: Yeah, and I say that because there's so many accessibility features and so many accommodations that you can make now, which is great, but you as a developer have to know about them.
Chris Coyier: It's true. And that does mean that probably not most websites are taking advantage of it. We can hope that YouTube.com does, or something. And just that goes a long way. We can hope Stackoverflow.com takes advantage of it.
Ryan Donovan: Hopefully. If not, I'll get on the horn.
Chris Coyier: Yeah, there you go.
Ryan Donovan: So, you've founded CodePen, which is something I've seen on the internet, and it's one of those early code-sharing sites. Are there pieces of code on there that you feel like you refer to, or other people refer to All the time?
Chris Coyier: Oh, perhaps. We have a bookmarking feature, and I– like my own starter, I talked about, I made my own starter, and I bookmark it so I can just go back to it real quick and things like that. Yeah. Sometimes it's really surprising, like people that don't know what CodePen is at all. Like, I play music – I play with this other guy, we're both banjo players, and he's a teacher at a middle school who teaches culinary arts, and he didn't even know that I worked at CodePen, but one day, we got to talk and he was like, ' oh, there's this page we go to and I just click and it like randomizes a bunch of ingredients and stuff and makes an appetizer that my kids can make.' And the thing is sitting on CodePen. I've never seen the pen, of course. There's so many millions of pens, but it now is a big part of this guy's classroom teaching thing that he does.
Ryan Donovan: I wonder with the complications and what you've learned, like, you run a code pen, you run it within another thing that you've designed. You're running arbitrary code inside a website.
Chris Coyier: Yeah. Which is the very stupidest thing you can do online.
Ryan Donovan: Are there things you've learned from running arbitrary code on any given website?
Chris Coyier: Oh, God, you don't even know. It's most of my life, maybe.
Ryan Donovan: Yeah.
Chris Coyier: And I have a Co-founder who's even more technical than me, who's thought about this even more; but you buy a lot, client-side, just with iFrames. Just that alone is good for stopping all the kinda Access S stuff, especially because it's at another domain. So, it's like a third party iFrame, it looks like. And then in HTML, on the iFrame tag, you have ' allows attributes' and things. You can lock it down. There's content security policy that browsers have built in now, that has a lot of control over things like that. What's more dangerous than just API usage and stuff like that is spammy behavior, a lot of like crypto junk in there that's not inherently spam or nefarious, but often is just because of the nature of that world.
Ryan Donovan: Yeah.
Chris Coyier: So, that's a little unfortunate. And you have to be careful. You can't just be like, 'yeah, do whatever you want on here,' because it's one domain name, and if Google looks and sees there's all kinds of garbage on your site, the danger is—at least this used to be more true when Google traffic was most of the web, that might be changing a little bit—if Google blacklists you in Chrome or something, your business is over.
Ryan Donovan: Yeah. You're just not showing up. Yeah.
Chris Coyier: Yeah. Or if it shows some warning before you get to the site, nobody's gonna come and pay money to that site. It's just not happening. So, that you have to be really careful of, not that I wouldn't wanna be careful anyway, but there's some real kind of business risk to all that. But then, we aren't super backendy, like you can't run arbitrary Python at CodePen. We are mostly a front end platformy thing, but that's not to say that– you still, for example, can write SaaS. SaaS is a classic language that CSS– you'd write it, and it turned into CSS. Well, that's gotta make a server round-trip in our architecture to do that. And so, if you're clever enough in your SaaS code, can you break out of that processing and do something on the server SaaS? Probably not so much, but other languages had a higher likelihood of being able to do that. There's a language Pug, I don't think it's particularly dangerous, but it had a special syntax, and it could turn into HTML. But it offered, in the language, JavaScript. You could just type a dash, and then you're writing JavaScript. And you're writing JavaScript that's intended for the client, but still, it ran through a JavaScript compilation process. It itself was JavaScript, and hackers be hackers.
Ryan Donovan: Yeah.
Chris Coyier: They're gonna try to figure out a way to get access to that. So then, we lived through this, this is a long time ago now, but remember, there was a time where there wasn't cloud functions. Like, AWS invented it with Lambda—I don't know if they invented it, but they might as well have, 'cause that's the de facto implementation of it.
Ryan Donovan: Yeah. The best known. Yeah.
Chris Coyier: I would think so. And then, let's say you made your SaaS processing into a little Lambda, then it's, 'well, go ahead and break out of it.' You just broke out into the little, babiest, nothing server with nothing useful on it whatsoever. It had no network access, it had no security stuff on it. So, even that was cool. I still don't want you to do that.
Ryan Donovan: Yeah.
Chris Coyier: But who cares? You're not breaking out into anywhere that's particularly useful. That kind of stuff has been useful to us. So yeah, there's a lot of like angles to securing what we're doing. And it continues to be, it will always be vital to what we're doing. Once in a while, you'll see like a, 'you can make CodePen in two days. This is how I did it,' and all they do is grab the code and smash it together in an iframe, and you're like, 'yeah, sure. Go for it.'
Ryan Donovan: Best of luck there. Yeah, no, the history of the web is a series of increasing security attacks. I remember there were security attacks you could do in the URL bar.
Chris Coyier: Oh my gosh. Yeah.
Ryan Donovan: But, yeah. So, with CSS, what are the future-looking things? What are the things that you hope for? What are the things that you think are coming? What is the biggest thing missing in CSS?
Chris Coyier: Yeah, it's a funny question 'cause I'm sure it will continue evolving, and we'll still get cool stuff for a long time. But I don't know if it was a year ago now, maybe a little less, I was at CSS day, one of the last standing CSS only conferences, not 'cause CSS is not interesting anymore, but just 'cause COVID did weird things to conferences and all that; but it was there and so, what was nice about it is that it was a who's who of CSS stuff. And there was not a lot of chatter, but I heard definitely some hallway chat stuff of, ' we're getting close to donesie on CSS,' which is a weird thing to say. And I don't think JavaScript will ever get there, 'cause there's just so much little stuff you could do. But I don't think that's quite true. I don't think that's like next year or anything. But it is starting to feel a little bit like, what else even is there? Especially for something where you probably don't wanna evolve it absolutely forever, 'cause there's kinda limits to what you want a language like that to do.
Ryan Donovan: Right. Yeah.
Chris Coyier: You're not just gonna put JavaScript in CSS. That's obviously too far. So, where do you call it? There was pushback at the time variables came out that said, ‘eh. I don't know if that's correct for the language of CSS.' And part of their thinking was that it separates the location. You could define a variable in another file. You can define it so far away, so now any arbitrary chunk of CSS isn't meaningful in the same way that it could be, because it could be just essentially be missing dependencies. But too bad, that ship sailed. So, now we have that, but there might be more stuff like that, [but] maybe that's a little bit too far. I think Loops is generally considered a step too far. I don't know if that will ever get that. I have not heard a real hard push for loop in CSS. It's a little weird 'cause a lot of languages that process into SaaS do have loops, and they do have their uses, but I think CSS considers it maybe a step too far.
Ryan Donovan: Yeah. What would even a four-loop do in CSS? You have animations built in, and that's a loop.
Chris Coyier: Yeah, there's a certain selector in CSS called ':nth-child()' and I think that's the most common place I see loops used in something like SaaS, is 'I wanna write :nth-child(1) and :nth-child(2) and :nth-child(3) and :nth-child(4), 'cause I want to do something different to these individual 10 or 100 or a thousand selectors, and I don't wanna write a thousand selectors.
Ryan Donovan: Right.
Chris Coyier: So, I'm gonna programmatically write a loop that loops from one to a thousand. I use that I variable or whatever it is in the :nth-child(), and then in the output, I do something. Because now you have the iterator, so what can I do with the iterator? Well, I can use it in a color calculation. I could use it in an animation delay to stagger out some animations. There's all these little things I can do. For a long time, I was like, this is an obvious additio,n and wanted this is brand new, hot off the presses CSS. There's a new function. So, remember, a function only can possibly return one value. I guess that's true of JavaScript, too, isn't it?
Ryan Donovan: I think it's true of most functions. You could put in an object that has multiple–
Chris Coyier: Yeah, but then you're just returning the object. It's still one thing. Not even Go can return multiples to crap out of a function. But it's almost arbitrary at that point, 'cause returning an object is also a lot like returning multiple things. You just pluck it out, especially with Destructuring and all that. Okay, I lost the thread, but it was– the two functions are 'sibling index' and 'sibling count.' So now, what you might have used an iterator before is say, I wanna say 'animation delay, 0.1 seconds. Animation delay, 0.2 seconds. Animation delay, 0.3 seconds.' So, these three boxes come in 'whoop whoop.' A ' whoop' is a nice thing to do on a website.
Ryan Donovan: Everybody loves a 'whoop whoop whoop.'
Chris Coyier: Yeah, they do. So, I might have to write :nth-child(1) and :nth-child(2) and :nth-child(3), and then use that iterator value to say, 'animation delay really is i times 0.1 seconds,' a little calculation that would multiply the iterator by that. And now, you don't have to write nth-child(1) and :nth-child(2) and anything, you just say, all these elements that I'm selecting? They have an animation delay of their sibling index times 0.1 seconds. So, I don't need to loop over 'em anymore, it just figures out what its dom position is, and then uses that as the value. So, the need for a loop, because of these two new functions, is really low. You might wanna know the count of the siblings too, because you might want to be like, I don't know, 'your sibling index divided by your sibling count divided by 0.1 seconds.' So, it puts a cap on how long something could be, or whatever. There's just reasons why you might wanna know the count as well as the index.
Ryan Donovan: Yeah.
Chris Coyier: Anyway, that's some hot, fresh CSS for you.
Ryan Donovan: Hot, fresh CSS. Dig in.
Chris Coyier: Keep your eye on CodePen. We're long at work at a CodePen 2.0. It's now in private beta. Feel free to reach out to me if you want in on that private beta. It'll be in public beta very soon, but my goal is like, gosh, I wish we supported this language, and this language, and I wish you could make a multi-page website, and I wish all pens were deployable, and I wish you could invite somebody into it like a Google Doc. We have this laundry list of features that the CodePen of today doesn't support, and we've just put 'em all into 2.0, and it's taken us forever to get out. But perhaps the biggest thing that isn't gonna be obvious until people use it a little while is it's got its own build process now, and all these things that you decide to add to a pen, 'I want a little type script. I want a little stylus, I want to use Svelte, or whatever. You just pick 'em out like you're at the fricking grocery store. Just, 'I want a little of that, want a little of that,' and our compiler understands what you mean. It makes sure that they all work together. You don't have to worry about the glue that makes 'em all work together, but they're all individually configurable. You can tell TypeScript how to behave, for example, but I don't have to figure out how to make some new SSG understand TypeScript. You don't have to worry about that part, and that's usually what people refer to as 'Config Hell,' trying to understand how to piece this whole thing together. The CodePen's gonna do that for you while giving you a lot of this control, and I'm hoping it's like a new paradigm in a way of how websites are pieced together from a front-end perspective.
Ryan Donovan: Very cool.
Ryan Donovan: Well, it's that time of the show again where we shout out somebody who came onto Stack Overflow and dropped a little knowledge, shared some curiosity, and earned themselves a badge. Today, we're shouting out a Populous Badge winner, somebody who dropped an answer that was so good, it outscored the accepted answer. So, congrats to 'steamb' for answering, 'Why is my localhost self-signed SSL certificate suddenly invalid in Chrome?' If you're curious about that, we'll have the answer for you in the show notes. I've been Ryan Donovan. I'm the host of the Stack Overflow podcast, editor of the blog here. If you have comments, concerns, topics, if you wanna suggest a show topic—today's show was suggested by a listener, the guest was suggested by the listener—so, if you want to do that, please reach out to me at podcast@stackoverflow.com. And if you wanna reach out to me directly, you can find me on LinkedIn. Chris?
Chris Coyier: Yeah, I'm Chris Coyier. Thanks for having me on the show once again. I'm the Co-founder of CodePen that's at codepen.io. My personal blog is chriscoyier.net, where you can find my own blog and links to all the other stuff I do in the world.
Ryan Donovan: Yeah, I believe you have a podcast too, don't you?
Chris Coyier: I do. Yeah. If you just can't get enough of me, shoptalkshow.com.
Ryan Donovan: All right. Well, thanks for listening, everyone, and we'll talk to you next time.