How not to struggle with CSS, with Kevin Powell

How not to struggle with CSS, with Kevin Powell

πŸŽ™ About the episode

Meet Kevin Powell πŸ‡¨πŸ‡¦! Kevin is a CSS Evangelist and educator. He makes weekly YouTube videos, streams on twitch, writes articles, and teaches courses. His mission is to show new developers that CSS is fun and teach them how it works... and why it works the way it does.

In this episode, you'll learn how not to get frustrated with CSS, how to debug it, why people struggle with it, and how come we might never see a launch of CSS 4. Kevin also explains why different browsers render CSS differently and how much should you actually care about that. Alex and Kevin also discuss how the web gets made behind the scenes and how you can join the conversation and suggest the features you'd like to see in certain technologies. Plus: Bad design trends, tools and plugins, CSS memes, and tabs vs spaces.

πŸ”— Connect with Kevin

⏰ Timestamps

  • How Kevin found himself in the world of web design (01:28)
  • Can a new developer focus solely on CSS? (04:26)
  • What is a CSS Evangelist? (07:12)
  • Why do people struggle with CSS? (09:04)
  • Why CSS works the way it does (12:15)
  • CSS tools you should use (14:12)
  • CSS extensions for your editor (16:14)
  • The learning curve of CSS and the importance of experience 18:04
  • Why different browsers render CSS differently (and why it sometimes doesn't work) (21:18)
  • Progressive enhancement and accessibility (25:53)
  • The history of CSS (29:21)
  • Will there ever be a CSS4? (33:11)
  • How to stay in the loop and join the conversation around features (35:18)
  • Quick-fire questions (37:33)

🧰 Resources mentioned

⭐️ Leave a Review

If you enjoy this episode please leave a 5 star review here and let us know who you want to see on the next podcast.

You can also Tweet Alex from Scrimba at @bookercodes and tell them what lessons you learned from the episode so they can thank you personally for tuning in πŸ™

πŸ’¬ Transcript

Alex Booker (00:00):
Hello, and welcome to The Scrimba Podcast. On this weekly show, I speak with successful devs about their advice on learning to code and getting your first junior developer job. I'm Alex, and today I'm joined by Scrimba teacher and CSS guru, Kevin Powell. Kevin has offered some of our most popular modules on CSS, responsive web design and working with Figma and design systems. This has also been an explosive year of growth for Kevin's YouTube channel where he's attracted half a million subs, teaching developers how to use and appreciate CSS.

Kevin Powell (00:36):
A lot of people don't appreciate CSS as much as JavaScript. The whole idea is just to show people that once you sort of get your mind into that frame of mind, it's actually a lot of fun.

Alex Booker (00:47):
I was personally really interested to learn more about how Kevin got into web developments himself and why he chose to specialize in CSS, of all things. This was a fantastic opportunity as well to learn about Kevin's environment, like what tools and VS code plugins he uses to write CSS and stay productive. We'll jump into the episode in just a second, but have you noticed by the way that CSS3 was released in 2011. A good 12 years later, there is no sign of CSS4. What's up with that? I guess we better speak with Kevin and find out. You are listening to The Scrimba Podcast. Let's get into it.

Kevin Powell (01:28):
So I've had a bit of a probably different path than most people, just that I sort of accidentally found myself here. I first started with making websites and anything like that back when I was in high school, near the end of high school, which would be the late nineties. So the web was a very different place back then and it was just mucking around to make silly websites or whatever. I think I was part of a Star Wars RPG, so we wanted just like a simple website that would lead to our form or whatever it was, a lot of Photoshop and slicing up the Photoshop and then bringing in table based layouts and mucking around, nothing serious. But it was one of those things that I would just sort of randomly come back to every now and then. I mean, every time I'd sort of come back, it would be like, oh, things have changed a little bit. Now CSS can do more than it could. We don't use like the center element anymore or the font size and all of that.
Now we're doing it like this. So it was always sort of like, come back, refresh, see all the new things that are going on and then not do anything for a while. My path through school and everything, I started in the sciences. I switched to film. I have a degree in film. I went to university and got a BA in urban planning. So obviously none of that ended up working out. After I graduated from university, I was working a pretty menial job and I was pretty depressed with the situation and my wife was like, "We can get by if you want to go back to school again." So I found a pretty short vocational program for design and the reason I ended up even circling back to that was because all that time that I had spent just mucking around in Photoshop and everything. So it seemed like something that I at least enjoyed doing. So I circled back to that, did that, graduated from there and started working luckily within that.
And the job I had was a really good job, but the pay wasn't fantastic. So I started doing freelance work on the side and a lot of the freelance work I was doing was for like UI design. And at the back of my mind, I was like, oh, if people are paying me to do the design of a UI, maybe they'll also pay me to make the website since I'm giving them a design. It's something I've done before, especially when I was back in school, I sort of dove back into that side, even though the program didn't really touch on it very much, but I sort of rekindled my joy of making websites. And that was around the whole CSS3 thing coming out. So it was just this whole new world of everything at the same time, which was pretty exciting. And then, yeah, I started doing that on the side a lot. I was having a lot of fun with it.
I was doing WordPress development then since it was freelance work. So it was making themes or most of the time child themes. So I had sort of a base theme that I'd have and I'd strip it down or I'd just delete the CSS file basically and restyle the site so it would look like what the client needed and muck around a little bit with PHP to get some extra functionality and little things like that. After a while of doing that, I actually got hired to be a teacher at my old school. And when I went back there, again it was primarily focused on design, but they'd added some new web content and they found out I had web experience. So me and one other new teacher got all of the web classes and that sort of is what pushed me from actually making things to teaching of web development and all of that.

Alex Booker (04:26):
Of course, when that opportunity came up, you were a perfect candidate. It sounded like a match made in heaven. It seems from the outside looking in that you pretty much focus on the CSS and design side of things. How do you feel about that speaking to new developers? Do you think there's room in the industry to just focus on CSS and design or do you think it's important to also learn things like, I'm thinking about JavaScript, but also frameworks like React and backend and stuff like that.

Kevin Powell (04:53):
Yeah. I'd like to tell people that you could all just focus on HTML and CSS and be fine. I don't think it's realistic in today's industry for most people. I do know a few people that focus solely on the CSS side of things, but I think if you want to get into that, you need to be not just like I can throw a website together, it has to be a lot higher level where you're working with design systems. You need to sort of be at that next stage where you're sort of doing a lot of work and taking that away from the JavaScript developers. I can never pronounce his last name, but the person I'm specifically thinking about is Mike, I think it starts with an A. You can find him as Peruvian Idol on Twitch, if ever you want to watch some design system stuff with CSS. And he just does design systems and everything there. And like he says, his job is really to write a lot of CSS so the JavaScript developers don't have to, and the value there is it saves them time because it's not what they're comfortable with.
So he can save the company a lot of money than a bunch of people working on something they're not comfortable with. But I think in general, a good knowledge of JavaScript is important for most people. So if you're looking to break into the industry, if you want to be available for the most jobs possible, having a good understanding there, I think, is an important thing to have. That said, I do think that understanding and a good knowledge of HTL and CSS is still really important and sometimes gets overlooked and it can be overlooked by people learning, but it can also be overlooked by companies when they're hiring and stuff. It's one of those things, that's what the user is directly interacting with. The JavaScript might be putting in the functionality, but what the person sees is the HTML and the CSS on the page. So I think a good understanding of all three is important.

Alex Booker (06:28):
If you were to focus on CSS, it really is like a specialty. You're solving something very specific for teams. It's not uncommon for companies projects to evolve year over year. And at one point they have so much technical data essentially, they can no longer move quickly and innovate with the competition or release the features they want. And I guess this is where design systems come in, but sometimes you need somebody with that experience who's done it before to help guide them. But maybe instead of just like coming out of the gate and saying, oh, I'm going to be that person, maybe start off a bit more well rounded and then figure out what it is exactly you enjoy the most, and if it happens to be CSS or something, as it sounds like it was in your case. Tell me a bit about this CSS evangelist sort of title that I sometimes see you described as.
It sounds like a wicked purpose, by the way. You kind of build things that help people build things, right? Or you teach people how to build things. I think that's a really cool purpose, but this CSS evangelist term, what does it mean to you?

Kevin Powell (07:24):
It's a little bit, like I said, where a lot of people don't appreciate CSS as much as JavaScript. I guess there's two different ways of seeing that. There's some people that are coming from more of a computer science background that run into CSS and then they just get frustrated by it and they see it as a frustrating language that doesn't work the way it should. And there's new people that are coming in that get the advice to sort of focus more on JavaScript. And so what I want to do is show people that CSS is fun, that it makes sense, and that it's different, but just because it's different doesn't mean it's bad, you just have to sort of figure out how it works and understand how it works. After you do that and you put a bit of a time investment into it, it can be a ton of fun. And I think part of the reason I was even drawn to it in the first place is because I did have a bit more of the design.
Well, I mean, I was doing it before I got into the design side of things too, but it is obviously the language of design itself because it makes the design show up on the page or on the screen. And so it is a bit of tinkering and a bit of playing with and trying to get things to work. And it's a lot less absolute. Miriam Susan has a really good talk about why CSS is so weird. And it's just talking about how compared to other languages, it's a language that deals with unknowns, right? You don't know the size of the person's screen. You don't know the pixel density of the screen. You don't know the color gamut of their screen. You don't know even if they're on a big screen. How big is their view port and everything? And are they using a mouse? Are they using a touch device? Are they interacting with a keyboard? There's all these things you don't know. I think that's why people get frustrated by it. You're sort of dealing with all these unknowns, it can be really strange and difficult.
So I think me, the whole CSS evangelist idea is just to show people that once you sort of get your mind into that frame of mind, it's actually a lot of fun and we can all enjoy it and do something cool with it.

Alex Booker (09:04):
Why do you think it is that just so many people struggle with it?

Kevin Powell (09:07):
I think part of it is there are a lot of unknowns, so that's frustrating. When I started, I'd take a Photoshop document that was a set size, you slice it up and then you just sort of make it happen at that specific size. I mean, it had its own difficulties with table based layouts, but until we had to worry about responsive designs, you were just literally taking a Photoshop file and making it work and you didn't have to worry about anything. You set everything absolute values and you could make it work. And now there's responsiveness. So you start figuring things out and then you realize it breaks at big screens or it breaks at small screens. So that's frustrating because it's not working the way you intended it to. And then if you don't know all the tools we have at our disposal, then it can be actually pretty hard to fix. Or you might have a ton of code that you need to delete and start that over again and that can be frustrating.
So I think that's a large part of it. And I also just think that because it's such a simple language at its core, it's a declarative language; color, blue, background, red. It sort of tricks us into thinking it's a very simple language because that's the first things you learn, usually is to set the font color, set a background color, maybe set a width on something. But you learn the very basics and you go, oh, this is easy. I can do this. But there's actually a lot more to it. Whether it's things like the Flexbox algorithm or just the page layout algorithms that are actually really complex in what the browser's doing behind the scenes to get things to work, understanding the formatting context and stacking context and all these things that are there that are talked about a little bit less, so you're not always aware of them and the implications they have.
So you just run into these dead ends that you get frustrated with just because you didn't even know that that was a limitation or that was something that you had to worry about. When you're coming in those situations, you can easily see why it can be so frustrating.

Alex Booker (10:43):
Coming up on The Scrimba Podcast, what's the deal with CSS4?

Kevin Powell (10:47):
So there will probably maybe never be a CSS4.

Alex Booker (10:52):
If you are enjoying this episode of The Scrimba Podcast, please do us at Scrimba a favor and share this episode with your friends on social media, like on Twitter, for example, or in your community like on discord maybe. Word of mouth is genuinely the best way to support a podcast that you like and help us reach other new developers and support the show. So a big thank you in advance. As you probably know by now, on The Scrimba Podcast, we alternate one week with an expert like Kevin and then the next week with a newly hired developer, someone just a few months ahead of you potentially who got hired. Next week, I'm talking with Kennedy, a successful Scrimba student from Florida.

Kennedy (11:31):
I wanted to be an air traffic controller. So I actually got my degree in aviation operations, but it's hard to get into the field. So I was a manager at a hotel near Disney World, actually. So my husband, he told me about UI/UX design and I'd heard about coding before and I thought it would be something I like because I like solving puzzles and that kind of thing, and just overall, I really love learning.

Alex Booker (11:58):
That's next week on The Scrimba Podcast, so make sure to subscribe as not to miss it. Back to the interview with Kevin. I think one thing people struggle with compared to JavaScript a little bit and other, what we might call traditional imperative programming languages is that there is a degree of sort of, the fancy word I think is static analysis, where if you write the code in VS code, sometimes it will predict that it's not going to work before you run it. And then when you do run it and there's an error, assuming it's not a logic error or something, you have a call stack and some hint about where to go next. But with CSS, you open your browser and you're like, huh?

Kevin Powell (12:37):
And I think that's one of those things that people see as a problem with CSS. I mean, a big part of HTML and CSS is making sure that the information gets there and that the user has something. So that's why it doesn't fail, right? That property will fail, but in failing it just means it doesn't work and it's not being applied. It's even like the classic CSS is awesome meme with the awesome overflowing of the side, and obviously people hate that.

Alex Booker (13:02):
Yeah. Or that mug with the CSS kind of coming out of the side of the mug.

Kevin Powell (13:07):

Alex Booker (13:07):

Kevin Powell (13:07):
Yeah. Exactly. Yeah. And it's frustrating when you have overflows and stuff, but that's CSS trying not to have information disappear. I can't remember what site it is. There's a site that I go on quite often because I think it shows up in my feed on my phone for news articles and stuff, and they mucked up something with their eye frames. And at first I thought it was like this one time, but it's just this recurring thing where there's ads that are in the middle of an article and the ad will cover text. I think it's the first line of text in the next paragraph or something and you just have no idea because a line of text is missing and you just have the middle of a sentence. And naturally, that's what CSS is trying to prevent by allowing overflows. So if you do make a mistake that, well, the user can still access that content and stuff. And it's the same thing, if you try putting width purple, it doesn't break your site, it just doesn't apply the width purple because it doesn't make sense.
But like you said, it's really frustrating when you're trying to find these problems and that's the debugging experience of CSS is very different from the debugging experience of other languages, for sure.

Alex Booker (14:12):
If you start writing CSS in Notepad or something or maybe VS code without any extensions and you never right click inspect element and dig deeper into the development console, you are probably going to have a very frustrating experience because you're not using the tools available to you, and that's okay. Probably you just haven't learned about them yet. So I wanted to ask you, Kevin, are there any sorts of go-to tools or techniques you use when you're writing CSS to make the developments experience more enjoyable?

Kevin Powell (14:39):
So definitely a lot of dev tools. For people that are writing CSS, I'd still recommend the Firefox dev tools over Chrome's

Alex Booker (14:46):

Kevin Powell (14:47):
Chrome's dev tools have improved a lot. They have like their grid inspector and in flex inspector now, which are really good, even though I still prefer Firefox's just because the labeling is a little bit more clear. There's a lot of good things in the Chrome ones, but the reason I'd suggest it, especially if you're early on with your CSS is if you try doing, let's just say you do a justified content center and it's not working and you can't figure out why, in Chrome, it just shows you that you've applied it and it's a valid property so there's nothing wrong with it. In Firefox, it will gray it out and it puts a little tool tip next to it and it'll tell you that this is a valid property, but it's not working because you haven't declared display flex. So any of those situations, we have like a property that relies on a different context being applied. So display grid, display flex, columns, other things like that.
Firefox actually says, yeah, this is fine, but here's why it's not working, which I think is super, super helpful. Even finding typos and stuff like that, because a lot of the time, you do background, whatever, and it doesn't work and you're sort of pulling your hair out, and I've been there with the stupidest things. But typos are a big thing. In VS code, sometimes it'll highlight it when you make some, but opening it up in the dev tools and then just seeing that it's crossed out and it's saying it's an invalid property and you're like, wait, what? And then you look and you're like, oh yeah, I've spelled background with a K-C instead of a C-K or whatever.

Alex Booker (16:05):
Take it for me as a Britain, misspelling color the British way and so on.

Kevin Powell (16:09):
Yeah. I'm in Canada, so we have the same thing. I've been there. Yeah.

Alex Booker (16:14):
Do you use any sorts of extensions within your editor?

Kevin Powell (16:17):
Specific to CSS, I can't think of something off the top of my head that I use, actually.

Alex Booker (16:22):
I have this feeling that CSS is inherently quite hard to build extensions for because you can't really predict what it's going to do until you are in the browser. I think the name stands for cascading style sheets, right? And this idea that your styles are always being inherited, it's quite difficult, I think, of an editor to build up all the context about what exactly is happening because you have no notion of the browser's default CSS or if you're referencing a reset CSS, for example, it might be hard to predict. And so maybe the right attitude is just to use Firefox in this case and see what it can tell you about what's happening.

Kevin Powell (17:00):
Yeah. And even like you said, you might have one class that's doing your display flex and a different class that's setting the alignment or it's an aligned self or whatever it is. So our editor doesn't know these relationships that you're building within the CSS and how you're using all of your different classes. So yeah, the main [inaudible 00:17:17] I know people use, or I don't know if it's considered [inaudible 00:17:19], but there's ones that when you save it can reorder the properties. So some people like alphabetical. I did a video on how I like to organize mine and then a few people in the comments were saying, oh, I have an extension that will do it sort of to group all the positioning properties, so position top, bottom, left, right at a group, the display or background with margin and padding type of thing. So you can write really messy CSS, hit save, and then it will reorder it. And the nice thing with those is then if you've written width two times, it'll stick them together and you see them right away if it's on the same selector, of course.
But at least then you don't run into those issues where you've put the same property two times and you're trying to figure out why one of them is not working and it's because you have it five lines lower down doing something different, which I still do to this day and it's-

Alex Booker (18:04):
I have been there. Yeah. I mean, it's not quite the same thing, but I remember learning Adobe Premiere, for example. And I went in there and I got super frustrated because I kept pressing the wrong keyboard shortcuts or the cursor kept changing to some icon I didn't recognize. And I was getting annoyed and I was like, oh, this should be easier. And I took a step back and I realized, this is a professional tool. They've edited movies on this that we've seen in the cinemas. Why should I assume I can learn it in a day or two? And I went back and I learned all the fundamentals. And I think of CSS, sometimes we fall into a similar trap and it might be to do with that sort of Dunning–Kruger effect thing where at first it might seem so easy, but understanding things like how presidents works, either with selectors, whether a class is selected before, an ID or for a pseudo selector, for example, and then understanding in what order properties are interpreted and think, these sort of fundamental things, you're not going to see the impact of them right away.
They're not going to make your website look better overnight, but they will build you up as a developer. So when you run into these issues, and I think the cycles you're experiencing today, Kevin, where you've built so much experience you're like and you have a suspicion, don't you? Like, oh, maybe that was wrong. And then you bring in some tools to just make it more obvious.

Kevin Powell (19:11):
A hundred percent. And the more experience you get with CSS, the more you start realizing the mistakes are usually the same things popping their head up. You come up with this mental checklist of, is there a typo? Is something else overriding that for some reason? And our dev tools can help us find those things. But you sort of start seeing 90% of the mistakes are these really silly ones a lot of the time, and you sort of catch them a lot quicker. I do think what you're saying though is a hundred percent spot on. And I think it's one of the things I've been thinking about a lot lately and I'm not sure the best approach to it because we learn about things like the box model and inheritance and the cascade generalities within it. You learn those like day one and then you never really go back to it. It's this big information dump on fundamental things, but you're learning all those things.
You're learning how the properties work, you're learning all the properties because there's so many properties to learn. There's no way that that one early dump of information just all sunk in there and you really understand it. It's just, you have this general idea that it exists. And so that's one thing I am thinking about is like, how can I frame looking at these things again later on to someone and being like, no, you should go back to the box model because maybe you don't understand this part about it, or there's things that you don't hear a lot about like formatting contexts where you have the regular block and you have display block, display in line, we have display grid, but what are those actually doing and what's the effect, because in a regular formatting context, you have collapsing margins. So the bottom margin of one thing will collapse into the top margin of another thing and they sort of combine into one margin.
Or even the most frustrating thing is if you have a child inside a parent and you add margin top to the child, it could potentially push down the parent. And that's counterintuitive. It's really weird, but once that's a thing, you know why it's happening. But then a lot of these behaviors also change if you use flex or grid. And that again becomes frustrating because people don't really understand why things are different in different situations and stuff and trying to revisit a lot of those core concepts and a lot of those basic things once you have a little bit of experience and you're sort of getting comfortable with the different things you are doing is really important, so you actually have a better understanding of why things are happening the way they are.

Alex Booker (21:18):
This is all very good and well, Kevin, but please tell us why does my CSS work in one browser, but not the other one?

Kevin Powell (21:24):
One thing I will say to anyone who complains about browser compatibility today hasn't been writing code for too long because it's a lot better now than it was even five years ago, and it was better five years ago than it was earlier than that. I mean, at one point we had competing specs on how to style browsers. It was actually Internet Explorer that made CSS a thing because Firefox, or at the time it would've been Netscape, was working on a different thing. So things have been a lot more difficult. And then that was kind of funny because Internet Explorer got us there, but then it was the one that caused us the most trouble long term when we had to deal with like [inaudible 00:21:59] and stuff. But yeah, so I think it's gotten a lot better. The biggest thing now is the speed of development of CSS has taken off recently.
It's a really fun time to be in my position where I'm teaching people because there's all these new things to talk about, which if I had started doing all of this eight years ago, there was just this long period of stagnation. Even before CSS3, there was years of nothing. Then we had a whole bunch of new stuff and then we had a long time of nothing again, except other than grid really in these little things that would come up. But right now there's so much coming and I was a little bit concerned actually at one point last year because I was seeing Safari was working on this, Chrome was working on this other thing, Firefox was working on implementing this other thing. And so I was like, we have all these new things coming, but if the browsers aren't aligning on which one they're supporting, first, we're just going to have this ecosystem where we can't actually use any of them because every browser's supporting different stuff. But it does seem like there is some alignment that's coming around, which is good to see.
One of the big things now is just CSS is growing up very quickly. There's a lot of new things coming and you do have to be careful to make sure that it's great when you hear me talk about it on my YouTube channel or I tweet about it or whatever it is, but do make sure that it's something that's supported by all the browsers. There's ways of also dealing with things like that. But I think another thing that's really important to think about with the web in general is, is it a problem if they don't all look the same? And if you're working for a client or a boss that's telling you, no, they have to look identical, obviously it's a little bit harder to say, no, no, it's fine, when you know the person paying your bills is telling you otherwise, but it's one of those things that for me, I've always found really strange because one user will visit a website on their phone and then they'll visit the same website on their computer, and that one user will get two different experiences because it's a different layout, the menu's probably different.
It's not the same at all. One's a touch interface, one's using the mouse so there's different interactions. So it's one website, one user, two completely different experiences, but then you want every single user, different people who are visiting the same site to have the exact same experience if they're on the same device. And I don't see why that's so important as long as they're having a functional experience. So even when it comes to like supporting Internet Explorer now, which a lot of the big companies are not worrying about Internet Explorer anymore, but if you have an eCommerce place or something, you can't always say like, oh, it's only 2% of our revenue, who cares? It's still 2% of your revenue. But to me, the site needs to work for them. It doesn't need to be exactly the same thing with all the bells and whistles that someone else is getting to. And I think that's where the idea of like progressive enhancements come in and all of that.
There's all this new stuff coming. We can use it, but just make sure that if the browser doesn't support it, that it doesn't break the site for them. And as long as it's not breaking it, they can still use it, for me, I don't see the issue with that. But again, it's not always easy to convince your boss or your client of the same thing. So it's easy for me to say this, but I do hope that over time we can get that attitude to shift a little bit because the whole idea of pixel perfect on something, I think that should be a banned word or something. It doesn't exist and it's never going to exist again.

Alex Booker (25:04):
Some of the past, doesn't it?

Kevin Powell (25:05):
Yes. Yeah, definitely.

Alex Booker (25:06):
Yeah. Like maybe in the nineties, early 2000s, designing in Photoshop and then getting a developer to turn it into a website was all the rage. But obviously back then, it was a lot slower to build a website so you wanted to nail the design first. These days, you can do quite rapid iteration. In fact, arguably you could tweak an element quicker in CSS than you could in Figma or Photoshop. At least some designers and developers I've worked with have subscribed to that philosophy. But just on the subject of progressive enhancement, as I will jump on the opportunity to teach people listening about it because it's one of my ideals of the web, it's this idea, right? That even if you strip everything back to the HTML essentially, it should still semantically look and feel like a real website. Even if your JavaScript can't load because you have a slow internet connection or even if the images can't load, there should still be that alt text.
There should still ideally be that ability to submit a form using just a form with the post method and no asynchronous job. The thing is, this is a nice ideal and it helps in a lot of ways, such as accessibility and if you're in a rural area of slow internet. And actually when your website breaks, which it probably will at some point, it doesn't break as bad because at least it's got the bones, right? The structures, right? And arguably is good for things like SEO and stuff as well, but probably not really because Google is so used to people not building their websites in that way, but they learned how to actually figure out the true structure and intention. So there's less motivation even to sort of write semantic HTML and things. So yes, it's a nice ideal and I want to see if you agree. I feel like in practice in the real world, it doesn't actually exist. It's quite hard to find in the real world because it seems to come at the cost of productivity in a sense.
It's quicker just to kind of bandaid it together. It's quite a difficult use case to make to your team or your boss and say, hey, I think we should really take it back to the bones and make sure it works because they're probably more focused on delivering a feature, right?

Kevin Powell (26:55):
I think what you said is a hundred percent spot on, especially like I hear this, just circling back to the SEO for a second, because I've been championing a lot more accessibility lately. And the amount of times that I see replies about, oh, that's also great for SEO purposes and stuff, and I'm like, well, that's not why I'm talking about it. I'm talking about it to make sure that everybody who's visiting your site can actually use your site. And if that does give an SEO benefit, then that's like a really nice bonus and maybe that's how you can justify it to your boss. But I think it's the same thing with just general accessibility and with progressive enhancement. It's one of those things that if you're trying to do it after the fact, it's a lot of work. Whereas if you take an approach from the beginning of wanting to go with that route, you incur a lot less [inaudible 00:27:37] and you can make something probably without that much more work, as long as you're thinking about it from the beginning rather than doing it after the fact.
It can be hard to justify if you're working on a team where you're doing your weekly or biweekly sprints or something and something needs to get shipped and you're on a tight deadline. So I think that's why often it actually does get pushed to the side. But again, it raises the risk of having this extra technical debt that then has to be circled back to and ends up being three times as much work. So I guess it depends on the situation, obviously, people are in and everything, but I think when you have the opportunity to go into it with these things front of mind rather than it being this thing that we have to bake in after the fact, it turns out not to be that bad and there's lots of solutions out there that exist for most of the problems you have to build. So part of it, like you said, just having a form that can work just because it works without having to rely on acing JavaScript or using buttons for what buttons are made for and using form elements for what they're made for.
And there's so many simple, simple, simple wins that people don't use because they end up trying to customize something that already exists and they're trying to reinvent the wheel sometimes. So at certain situations it's actually more work than it could have been if you just did things from the beginning. But there's lots of design patterns and there's lots of things that exist out there already. You don't have to do it from scratch. You can find progressively enhance basically anything you want these days and then just sort of tweak it to what you need it to do for your use case. And again, I understand why it happens a hundred percent because it's one of those things me as an educator, it's really easy to talk about the benefits of it and this is how you can do it and everything, but it's very different when you are under the stress of a deadline and all of that. So I do understand that side of things too.

Alex Booker (29:21):
I just wanted to circle back, Kevin, so quickly to what you were saying before about, you sort of mentioned CSS1, CSS2, CSS3, and we were also talking about how different web browsers have to implement CSS in a sense. I think what we're kind of talking about is like a CSS standard or specification where, as I understand it, a committee of very smart and very experienced people trying to achieve a consensus about what new features should be added to CSS. And then in order to bring that to reality, they have to describe in a standard, which is just written text really, what exactly that interface is going to look like such as the spelling of the property, how it relates to other properties, what values are acceptable. And they really have to be as detailed as possible about what the expected behavior is. And then different browser implementers. We're talking about the web engines, like I guess it's Chromium in Chrome. And I forget, it's not Gecko anymore in Firefox, is it?
They have some kind of web engine, I suppose. And then it's up to those developers to then build the CSS language in their specific browser. And this, I think, over the years is where a lot of confusion happened because we were talking about Internet Explorer going rogue. Well, they had different ideas about what should be in CSS compared to Firefox and Google. And that was a problem because it would work in Internet Explorer, but Google would use a completely different sort of value or something like that. And then even when it comes to implementation, I don't know if that margin top thing you were talking about is considered a feature or a bug. Maybe it could be interpreted in different ways and different browsers and that's where things get a bit confusing, but the question I have for you is, I had a bit of research and it looks to me like CSS1 was released in, I think, 1996. CSS2, a few years later in 1998. Do you remember what sort of timeline CSS3 came out? Was it like the early 2000s or something when it first became a thing?

Kevin Powell (31:09):
That sounds right? I know it was a really, really long gap. And even from when it became a thing to when it was implemented was also a long journey.

Alex Booker (31:18):
Good point. Yeah.

Kevin Powell (31:19):
I don't remember when it officially hit, but it was like, here's a bunch of new stuff and you can sort of use them for a long time. That was an interesting time and that was also the beginning of the prefixes.

Alex Booker (31:29):
Oh, I remember those. Yeah.

Kevin Powell (31:30):
Luckily that's mostly becoming a thing of the past, even though for a few things, we still need them. For anyone who doesn't know, prefixes was when you had... I remember border-radius, you had to do it. So you had like for every rendering engine, so pretty much every different browser, they didn't really follow the official spec when they started putting in border-radius, but they all wanted to have it. So they all prefixed it so it'd be like -[inaudible 00:31:53], - border-radius, - MS, - border-radius. You had O for Opera and you had five different ones really. If you look at old CSS gradient generators, the code they would spit out to work in all the browsers was insane just because it was the same thing over and over and over with all the prefixes, of course, then we got Autoprefixer which saved us on that. But that was because they all were trying to implement these things for CSS3, but it wasn't officially up to the spec.
So they wanted to prefix it just to make sure that until we get this working officially properly, we're going to prefix it because this is our own interpretation of it. And that existed for a lot of stuff for a long time. And then slowly as they sort of standardized everything and they all followed what the spec was actually saying, at least that's how I understand it, that's when the prefixes started disappearing, which we're all happy about. Now there's a few things that only work with prefixes because they're not things that are actually part of the spec. One of the things is if you want a custom scroll bar, Chromium has their own implementation versus the Firefox uses the official spec, but Chromium doesn't. And Chromium uses the web kit one, which will also work for Safari. But yeah, they sort of went rogue and did their own thing, so that's why they prefix it and they do their own things on that.
So if a browser sort of does something that's not part of the official spec, that's when a prefix might still exist. There's one for text outline or something like that too that they all use.

Alex Booker (33:11):
We're like 10, 15 years, maybe even 20 years later now. Where is CSS4?

Kevin Powell (33:16):
So there'll probably maybe never be a CSS4. One of the reasons CSS3 took so long to happen is because up until then, when there would be an upgrade on it, they need to just do like, okay, we've added these things so we need to finish the spec on all these new things before we can publish this new CSS3. And CSS3 added lots of stuff. So it took a really long time to agree on everything to then officially, okay, we've done these 35 different things that we wanted to update. They are all done, we can ship that. They realized that was a problem. So when CSS3, and this is the same with HTML5, they've both taken this more organic approach now where everything's split off into its own spec. So you have like a layout spec. You have a text spec. So everything's on its own. Grid has its own spec and it's at level one, whereas color, I think we're reaching up to color level five now. So everything is on its own level so they can be updated independently.
And that's one of the reasons that CSS is now growing, I think, at a much faster pace because if we want to introduce new color functions, well, we only need to agree on, okay, here's the new color syntax and here's the new color properties or values we're going to have. That's good, perfect. Ship that. Don't worry about anything else. And so everything can grow independently of the other stuff. There's a few people that do think we should have in name only a CSS4.

Alex Booker (34:39):
Yeah. Like a checkpoint.

Kevin Powell (34:40):
Exactly. Because CSS3, it was a really good marketing push, really. It was, here's a whole bunch of these new exciting things that have just landed. Check them all out. It got people excited about CSS again. There's some people saying, we should do this now just to sort of let people know, look at all this new stuff that's here in CSS, because we have container queries on the way, we have layers now, scoping is on the way, nesting is on the way, all these completely new things coming. So is it worth celebrating and doing something just to sort of let everybody know who doesn't have their ear to the ground that there's all these new things that are here and get people talking about it.

Alex Booker (35:13):
Marketing's important. It helps developers know what they can adopt and push the web forward.

Kevin Powell (35:18):
I've started to poke my head in a lot more on some of the developing specs to keep an eye on them and see what's happening because, I mean, you could look at all of them. There's just pretty much a GitHub repo for everything that's sort of in the way. So I follow container queries from the very beginning. So I'm sort of seeing the process a little bit more at this point and following along because, I mean, anybody can sort of officially propose something. If you have an idea for how something should be done or there's something in CSS that you think would be a cool addition, you can start talking to people and it's a very formal sort of way to actually put in a proposal. You can't just say, hey, add this in. But you can follow conversations that sort of start that way of saying like, here's a problem I currently have. There's no current solution to it. Here's some ideas I have to how it would work, how things could evolve from here.
And it starts a conversation going of like, well, that wouldn't work because of this or maybe the naming of it would have to be this or what would the scope be? But the ideas start going on. And then from that, then it can make more progress and eventually actually turn into an official proposal. And then that goes through all the stages of once it's a proposal, it sort of follows on from there. So yeah, I've sort of been more curious about that side of things. So I've been lurking mostly, A, to keep like an ear to the ground of things that are on the way, but more in terms of seeing the process play out and maybe if ever voicing some opinion at one point or another, but I haven't gotten to that point yet.

Alex Booker (36:42):
Completely understandable. It's a very rigorous process, isn't it? It's sometimes difficult to join the conversation once it's already started because there's so much kind of context around it and it's understandable that there should be a lot of friction almost. Well, I suppose it's a difficult balance because there should be enough friction that you really have to think this through because if you add too much too fast, it's going to become a bit organic and messy and bloated and you really want to consider, what is the actual problem this solves and are we solving it in the best way? But that is the cool thing about open source. And one thing I love about the web is just a lot of the times of these proposals, people will create... I'm a bit more involved in JavaScript than CSS, I have to say, but they will create things like a polyfill or a Babel plugin that demonstrates a little sample of what this could be. It kind of gets the imagination going and makes it easier to have a discussion.
No one listening has to worry about this at all, but it's super fun to know that this is how the web gets made at a fundamental level. Anyway, Kevin, just to wrap things up, how do you feel about some fun quick fire questions?

Kevin Powell (37:43):
Yeah, definitely.

Alex Booker (37:46):
Your favorite thing about CSS?

Kevin Powell (37:49):
Oh my goodness. I don't know if I can do that as a quick fire one. I'll just say grid in general. I really like layout in general and I think grid solved a lot of the problems that I was after and makes my life a lot easier.

Alex Booker (38:00):
No more tables or floats left. Okay.

Kevin Powell (38:02):
Oh my goodness. Yeah.

Alex Booker (38:04):
What about your least favorite thing in CSS? Something that just you think, oh, this should be more intuitive.

Kevin Powell (38:08):
Definitely collapsing margins that we were talking about before. They shouldn't have been a thing. We have to live with them now that they're here, but a hundred percent. If we could do away with them, I'd be very happy.

Alex Booker (38:17):
And that's why there's this rigorous process for new features so that doesn't happen again, I assume. What about design trends? What is one design trend you see emerging that you're excited to see more of on the web?

Kevin Powell (38:26):
Oh, I don't know. I find a lot of the trends I don't get behind and then they disappear.

Alex Booker (38:32):
That's okay. Parallax scrolling and scroll jacking was a trend for a bit, mind you. So they're not all good.

Kevin Powell (38:37):
But even I see things like Glassmorphism and some other things, but to keep it short, I think what's cool with the trends is this new thing comes, people go overboard with it because it's this new thing, and then it sort of fades off, but you keep these little fun things with it. So even like parallax scrolling and let's say scroll jacking, but if it's done in subtle ways that maybe isn't a bad thing or could be like a nice little touch, or the Glassmorphism I've seen used in clever ways, but very subdued ways and not like here's my entire site that has these weird layering and blurs and everything going on. But yeah, I can't think of any current upcoming ones that I'm super excited about.

Alex Booker (39:13):
A lot of people regard you as sort of a go-to person for help and advice and information about CSS, which kind makes me wonder, who do you go to for advice and information about CSS?

Kevin Powell (39:24):
There's a few blogs and newsletters and a whole bunch of people on Twitter that I follow.

Alex Booker (39:29):
Anyone we can link?

Kevin Powell (39:30):
I'm going to forget people, for sure, but I've mentioned Miriam Susan already. There's Miriam Susan, Adam Argyle and Una Kravets who are at Chrome. They're CSS advocates at Chrome. Stephanie Eckles. Stephanie's awesome on Twitter. She also has a blog,, which is fantastic looking at modern solutions of stuff. She has a Twitch as well that she does some stuff on sometimes. Man, I feel bad for the people I'm forgetting off the top of my head.

Alex Booker (39:55):
We can always link people in the show notes. Few more quick fire questions. We would love to learn a bit more just about you, Kevin. Let me ask you, what do you prefer? Coffee or tea?

Kevin Powell (40:04):
Coffee, definitely.

Alex Booker (40:05):
What is your favorite TV show or series that you've watched recently?

Kevin Powell (40:08):
That one's not so easy. I can't think of a good one. I've watched a few that I've been disappointed. The last one, I guess, I really got into is The Mandalorian, but that's been a little bit now. There's been a few others that I'm watching lately, but it's just sort of like, oh, I have some spare time. I'm not going out of my way to watch them.

Alex Booker (40:22):
Finally, and this is a very personal question, Kevin. I hope you don't mind my asking, but do you prefer tabs or spaces?

Kevin Powell (40:30):
I mean, I set it for two spaces, so I hit tab, it does two spaces. I've heard a lot of arguments for four being more accessible just because it's more clear, but I like two spaces. That's my default.

Alex Booker (40:43):
Good to know. Kevin, thank you so much for joining me on The Scrimba Podcast. It's been a pleasure.

Kevin Powell (40:48):
Oh, thanks a lot for having me. It's been a lot of fun.

Alex Booker (40:49):
That was Kevin Powell, a Scrimba teacher, CSS YouTuber, and all around nice guy. Thank you for listening. If you've made it this far in the episode, you might want to subscribe to The Scrimba Podcast for more helpful and uplifting episodes with recently hired juniors and industry experts like Kevin. You can also tweet at me, your host, Alex Booker, and share what lessons you learned from the episode so I can thank you personally for tuning in. My Twitter handle is in the show notes. See you next week.