#21 – Chris Coyier Talks About Why He Sold CSS-Tricks

On the podcast today we have Chris Coyier.

Chris has been a user and educator in the WordPress and web development space for many years. He’s an author, podcaster, developer, but is perhaps best known for his website CSS-Tricks.

CSS-Tricks has been a valuable source of information about CSS for over 15 years. Updated multiple times a week, the site has articles about every aspect of styling your website. It’s gone through several iterations over those years, not just in how it looks, but in the manner in which it is managed and maintained. If you’re searching for any CSS related content, it’s quite likely that CSS-Tricks will be one of the top results.

A few weeks ago Chris decided it was time for CSS-Tricks to find a new home and it’s now owned and operated by Digital Ocean, a popular cloud computing service provider.

This podcast is all about the journey that Chris has had running CSS-Tricks.

We go right back to the start and talk about what his motivations were for starting, and then continuing to run the site. Were there any low points where he lost his motivation to keep it going? How has the site changed over the years? Why did he finally decide to sell the site, and how he landed upon Digital Ocean as the new custodian?

It’s been a remarkable journey, and you’ll hear that there were many twists and turns along the way.

Useful links.

CSS-Tricks

Chris’ personal website

Digging into WordPress

Codepen

Transcript

[00:00:00] Nathan Wrigley: Welcome to the Jukebox podcast from WP Tavern. My name is Nathan Wrigley. Jukebox is a podcast which is dedicated to all things, WordPress, the people, the events, the plugins, the blocks, the themes, and in this case CSS. If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast, player of choice, or by going to WP tavern dot com forward slash feed forward slash podcast. And you can also copy that URL into most podcast players. If you have a topic that you’d like us to feature on the podcast, I’m very keen to hear from you and hopefully get you, or your idea featured on the show. Head over to WP tavern dot com forward slash contact forward slash jukebox, and use the contact form there.

So on the podcast today, we have Chris Coyier. Chris has been a user and educator in the WordPress and web development space for many years. He’s an author, podcaster, developer, but it’s perhaps best known for his website. CSS-Tricks. CSS-Tricks has been a valuable source of information about CSS for over 15 years.

Updated multiple times a week, the site has articles about every aspect of styling your website. It’s gone through several iterations over those years, not just in the way it looks, but in the manner in which it’s managed and maintained. A few weeks ago, Chris decided that it was time for CSS-Tricks to find a new home, and it’s now owned and operated by Digital Ocean, a popular cloud computing service provider.

This podcast is all about the journey that Chris has had running CSS-Tricks. We go right back to the start, and talk about what his motivations were for starting, and then continuing to run the site. Were there any low points where he lost his motivation to keep it going? How has the site changed over the years? And why did he finally decide to sell the site and how he landed upon Digital Ocean as the new custodian? It’s been a remarkable journey, and you’ll hear that there were many twists and turns along the way.

If you’re interested in finding out more, you can find all the links in the show notes by heading over to WP tavern dot com forward slash podcast, where you’ll find all the other episodes.

And so without further delay, I bring you Chris Coyier.

I am joined on the podcast today by Chris Coyier. Hello Chris.

[00:03:05] Chris Coyier: Hello Nathan, pleasure to be here. Thanks for having me.

[00:03:08] Nathan Wrigley: Yeah, thank you for joining us on the Tavern Jukebox podcast today. We’re here to talk about a project which has been going on, it really feels like as long as I’ve been into the internet, and that is CSS-Tricks. I am pretty certain that if you are in any way connected with web design, development, WordPress, whatever, you will have come across CSS-Tricks, and the podcast has come about because of a choice that you made.

I was going to say last week, but I bet it goes back way further than that, to sell CSS-Tricks. And Chris, can we get into that a little bit later? First of all, can I just ask you some generic questions? I hate to be boring, but it would be good for anybody that hasn’t heard of you, small though that audience would be, tell us about you. What’s your background with WordPress and technology? Just give us your backstory basically.

[00:03:57] Chris Coyier: Oh, sure. To kind of focus it I suppose on CSS-Tricks a bit. It was started in 2007, so it is kind of old, I think there is something of a generation of front-end specific developers that where, I was coming up in this industry at the same time that they were. And you know, I’ve been a very consistent blogger, I guess, throughout that time, you know, I would probably write a blog post today for those 15 years practically. Most of them landing on CSS-Tricks.com. It’s a WordPress website. It’s always been a WordPress website. I’ve tried to run it as a pretty like stock WordPress site. Just go with the flow of what WordPress does. I only mentioned that because this is a WordPress specific website.

So I feel like WordPress people might like to know some specifics about the WordPress nature of it. Even as far as, Gutenberg and the block editor and all that, trying to get on board as soon as possible and embrace that a bit. So it’s kind of a middle-aged website in a way that when I started it, I didn’t feel like I am riding the wave, the early wave of blogging or anything like that. Not at all. I feel like I was, at the time, I might’ve felt late to it.

[00:05:05] Nathan Wrigley: Did you begin because you had a burning desire to blog or was it a burning desire to blog about CSS? What was the purpose?

[00:05:14] Chris Coyier: I think it was both of those things. Well, just because there was some desire that writing and publishing, somewhere deep in me was a good idea, or that I got a kick out of it in some way. The idea that the words that I write can be published so quickly and so easily, and that anybody in the world can read it and react to it. And I can just be part of this global community. I think that’s cool. I still think that’s very cool.

[00:05:40] Nathan Wrigley: How did you land on CSS as the thing? Were you in employment at the time where that was a concept that you were learning or really getting into? Was it a hobby?

[00:05:48] Chris Coyier: I mean the short answer is that I was into the web, but I wasn’t getting exposure to it at school, as much as I wanted to. We didn’t really learn HTML and CSS web stuff at school. And I was like, why not? This is weird. You know, this is clearly happening, but it was just too early for a state university to have latched on early enough to it.

So I was kind of learning on the side and getting kicked out of wow, I can, I can actually make websites. And I graduate college and that hobby persists, what I really want is this point, I’m like, I wish this was my job. Because clearly it’s some people’s jobs.

Why can’t it be my job? And I’m looking for jobs, I can’t get one. I try and try and just couldn’t be hired as a web. I think I was probably focused on being a web designer mostly because my degree from university ended up being in art and graphic design, and focusing on ceramics really, and I knew I couldn’t hack it as a ceramic artist, but I was interested in the aesthetics, mostly, and the communication aspects of the web.

So I’m trying to get a job as a web designer and I’m like, I know I’m not very good, but I still want to work in it. But I relegated myself to like, I’m not good enough yet. So, let me just work on getting better at it while I do something else. And that’s something else was working in the printing industry. I worked for years and years in digital prepress it was called, which is essentially taking documents from designers and getting them ready to run on physical printing presses.

I worked in the printing industry for a long time. That’s the industry that my mom is in. And she kind of helped me find jobs in that arena. Which was nice, it was fine. At least it was working on computers, and my whole life just learning computer stuff was always of interest to me. It’s not like I was masterful at it, but I feel like I took to the job of digital prepress, which was manipulating these documents.

Being clever with design stuff and solving the issues that designers had and getting their documents to press. You’d be surprised at the kind of the garbage shape that design documents come in. They’re almost never really quite ready to be printed. They’re full of mistakes and bad assumptions and things.

Anyway, even while I’m doing that, and I end up working some really weird shifts, like some graveyard shift, 6:00 PM to 6:00 AM stuff because these printing shops run 24 hours a day to get the jobs done and they need somebody in prepress on staff all night long. And it was the less busy of the shifts to, you know, there’s nobody in the office.

So if there was nothing to do, I’d be poking around at building websites. And then I go home and work on websites. It was such a fun hobby to me that I’d enjoyed the spirit of making anything online. So fun.

[00:08:26] Nathan Wrigley: So there was no intention at the beginning for this to be anything more than a hobby, a labor of love. It was just tinkering and playing.

[00:08:33] Chris Coyier: Well, there was a bit, there was actually because, I’ll always remember this blog that was about earning income or at least side income from blogging specifically. It was Darren Rose’s pro blogger.com or.net or something. And he had a couple of blogs that he made money on the side. And then he would blog about that blog. It was very meta.

I think he had some like camera review website or something. He was a photographer and he would write about reviews of cameras and equipment and stuff and put affiliate links on it. And it was probably before the days of sponsored content so much, but it was the days of where display ads were good money.

He clearly made good money off just blogging. Off just the idea of, I can create content and I can monetize it. And I did have that in me somewhere. I was like, maybe this isn’t my job, but I would love to make some side income. Who wouldn’t, you know? Side income’s awesome. Even if it’s beer money fine.

So I would start various blogs with the idea of, all I gotta do is, stick with this, make content, put ads on it, get beer money, be happy, you know, as a little idea. And I had loads of different ideas of this. One of them was, you know, making websites about Adobe products, in the spirit of providing help.

And I had this friend who has working phone support for Adobe, but third party. Adobe hires some third-party company to do their phone support, or they did at the time. And he would know, he had his finger on the pulse of what people call in about, and be like, let’s turn that into a blog post.

It’s like dang near every phone call. Might as well leverage that in an SEO kind of fashion and be like, what does this error code mean? Or how do I turn my PDF into a EPS or who knows what. So we’d blog those and then, hopefully get some SEO value on it, and put Google Adsense on it and get some beer money. And that we did, it just that it wasn’t very passionate.

I didn’t care that much about solving people’s PDF problems, in retrospect, you know. At the time I’m like, I don’t even know how much you need to care. If it made money, hand over fist, maybe I could have gained the passion for it. I don’t know. But one of the blogs I started was a, at this point, I’d built probably dozens of websites, all garbage, but Hey, I built them. And I built it with WordPress notably because I don’t know how I picked it, I just did. It seemed like the right choice at the time for spinning up a website fairly quickly. And as far as I know, WordPress was always kind of a CSS, even the very early days of WordPress, all the themes were CSS. You know, even though it was very early web, I think that embraced that early spirit of CSS.

[00:11:10] Nathan Wrigley: So it was a case of throwing spaghetti against the wall of various different topics. And CSS was the one that landed and stuck.

[00:11:16] Chris Coyier: Yeah, it was the least successful of them, but it was the most fun one to write. And then that success changed as I, as the other ones dropped off. I focused on this one. Mostly because it was just fun. And I think fun has a way of sticking, it’s the stickiest spaghetti as it were. And then little early success started to happen, you know. Like I get an email from, at the time, one of the big businesses, at least in this little niche industry I was in was PSD to HTML. And that was just a generic term, meaning all y’all know Photoshop, but very few people know HTML and CSS. So just send them your Photoshop file and they’ll send you back a website.

And it ended up being this kind of commoditized industry where there’s not just one, but lots of companies doing this, and charging really, like a hundred bucks, they would do that for. And I was always like, weirdly, not fundamentally opposed to it, but I was like the kind of people I’m talking to on this website, aren’t the kind of people that would use that service because they’re trying to do it themselves.

But at the same time, I think there was probably people that were trying to do it themselves, but then would give up and be like, oh, this is too complicated. I’ll just pay somebody a hundred bucks and get it. So I think those companies must have saw that in my audience and wanted to pay me money to put display ads on the website for them.

And one of them was quite literally called PSD to HTML. And it was so unofficial, I was just like, oh, I dunno, PayPal me a hundred bucks or something. And I put the little ad on there, and then I would notch up the price over time. Once in a while they would want to go bigger, you know, can you make the ad bigger? Sure. How about 250 bucks then, you know? And then I hand managed that for a long time. We had Treehouse became a sponsor for many years, and that was also very much just a handshake agreement and PayPal transfers. And I would hand craft the ads that I would put on the site, but the, eventually that fell away to more like traditional self service. Send us the asset. And I became a partner with this company called buy sell ads, who was our advertising partner all the way until I sold the website. They’re a great company that handles the sales and placement of ads on websites.

[00:13:33] Nathan Wrigley: Over time, it’s become something which was a hobby, which you didn’t anticipate becoming successful it because of the content became successful. And you stumbled into ways of monetizing it and justifying it in terms of the hours that you were spending on.

[00:13:48] Chris Coyier: Exactly. that’s a good way to say it.

[00:13:50] Nathan Wrigley: I do like that it wasn’t intentional. It was just, it just occurred over time and it may have done, and it may not have done. Rewind history 15 years and maybe that spaghetti didn’t stick and something else would’ve done.

[00:14:03] Chris Coyier: Yeah. I mean, I don’t know that it was entirely chance and I mean, it was a, that was a big part of it, but it was evolved to rank content that worked. And learned from that. And I evolved business model wise to double down on the things that were working and get rid of the things that weren’t working. It definitely was like labor and trying to understand the business and changing the business to make sure that it worked.

[00:14:30] Nathan Wrigley: Did it become more intentional over time? So as you began 15 years ago and it was what it was. And then five years later it was something slightly different. There was a financial benefit to keeping it going. And five years later after that, it was even more so. Did you modify it to become a business? Did you take on staff and guest writers so that your audience was satisfied?

[00:14:50] Chris Coyier: Yeah. there was some kind of moments where those things happened. For one thing, the first employee I ever hired, I think was Sarah Cope. The idea was we wanted to sell t-shirts and swag and stuff. So maybe I would just print a bunch of stuff. And then when somebody ordered it, we’d ship it out. We’d have a kind of a permanent swag business. But there wasn’t really companies around at the time that would just manage that all for you. Like there probably is now. So Sarah just did it. I had all this stuff printed, it went to her house. She lived in Ohio. She had a whole room of her house that got kind of taken over by swag.

And she would just, every day or every other day or whatever, run to the post office and mail out the orders that came in and all that. So that kind of cracked the nut on having an employee. And then she would help with more site stuff over time and then got too busy for it or swags started to diminish and sales and stuff, you know, things change over time.

I forget what was the end of it, but eventually she stopped working for CSS-Tricks and then other people would come on. You know, I had Jeff Graham was with me for so many years all the way up until the end at CSS-Tricks. And now he’s even going to go over to Digital Ocean and help continue working on the site there. He came on as like an editor and a writer, but then, you know, fell into more editing and more like site management and dealing with sponsors and just dealing with authors and just doing a ton of stuff on the site. That was kind of a moment when Jeff helped take over on some of that stuff. Partially naturally, just cause I, I felt too busy and I needed the help. These things are little moments in time where the site shifted and changed. Like, there was a whole, a whole period of time where I was trying to get staff writers.

I wanted to have a staff, like a magazine would. Of writers and that kind of worked for a little while, and then kind of stopped working for whatever reason. I can’t really remember. And we kind of fell back into a, just a one-off writer spirit, which was, the model that we ended with. I’m sure if I kept running the site for years to come, that that model would shift again over time. I’m not sure.

That model was pretty nice. Write in with your pitch, we work with you on your pitch. We publish the article, we pay for it. That’s what CSS-Tricks is today. And I think is the plan of how Digital Ocean is going to run it as well, because vibes pretty well with their content model.

[00:17:07] Nathan Wrigley: We’ll come to that in a minute. I’m just going to stay on the personal side of things, if that’s all right. We’ll split the next few minutes up into upsides and downsides. So you’ve got this project, CSS-Tricks, it’s taken off, you got money coming in and there’s bound to be upsides and bound to be downsides.

So let’s just explore those. Let’s get the downsides out of the way shall we? What are some of the things that looking back over the last 15 years, you recall as moments of headaches, heartaches, things that you wish you’d done differently or things that you wish, perhaps you’d never done at all?

[00:17:37] Chris Coyier: That’s tricky. There’s really not that many. I didn’t take as many risks running this site as other people and specifically entrepreneurs have. I’m really betting the farm on this and, if something goes wrong, I could be risking my house and home on it. I pretty much always have had other jobs as I did this. So my worry level was always lowish on what happens at CSS-Tricks. I always had in the back of my mind, like, man, if this thing gets burned to the ground, oh, well, there’s always something else I can do. But there’d be a little moments, at one time we published a sponsored post from some company that we really shouldn’t have.

It was like a company that sold SSL certificates, but that was actually kind of slimy about doing it. And that kind of like embarrassing moment where you get called out on it and you’re like, ooh. Or we publish something that, an article that didn’t take accessibility in mind nearly as well as it should have. Not just ignored it, but straight up bad accessibility practices in it and getting called out for that and having that be embarrassing, not great. Having people disagree with other advertisers or something. Those are moments that don’t feel good, but really aren’t that bad.

[00:18:48] Nathan Wrigley: No. Did you ever find it to be? I don’t know, maybe the words treadmill are suitable here. Was it ever, ever moments where you thought, oh, really? I’ve got to write an article for CSS-Tricks because I haven’t done one for a week or so. Did you ever feel it to be a grind or a noose around your neck?

[00:19:04] Chris Coyier: Sometimes the sponsorship related stuff felt like that. Honestly, it kind of did at the end. There was moments where you’d wake up and be like, oh my gosh, I totally forgot about this. It’s got to go out today. I got to wrangle the content for it. I got to basically look up with this company does because it made it this far, so it, it’s probably not abhorrent. It was agreed upon earlier, but I haven’t really researched what they do entirely yet. And it has to be my words. So it’s going to be a really quick turnaround and like, there’s some stress to that, that I didn’t really like. You know, what’s never stressful for me was writing about web stuff. If it’s just write a blog post about some link that I’ve saved, that I really, I saved on purpose cause I’m into it, and want to share it. I always liked that. I still like that. That’s not stressful to me.

What’s stressful is the stuff that you’re like. The only reason I run ads is to keep the site going because there’s people that need to be paid. This is a business that I’ve chosen to run. The agreement has already been made. Part of that agreement is that this content is going to run at this date at this time. And I do other things as well. You know, I have a podcast of my own and I have a much, much bigger project in Codepen that I’m a boss of, I’m a co-founder of, and I have responsibility for that needs the attention.

So if I’m off writing a blog post, that’s attention of mine that’s not being spent on Codepen and that’s something I wanted to change.

[00:20:29] Nathan Wrigley: Maybe a feeling of being spread too thin, but nothing too bad.

[00:20:33] Chris Coyier: Nothing too bad, that’s, that’s exactly right. I still, you know, I’m still waiting for that relief in a way. As you and I are talking, we’re less than a month off of the sale there’s still like, so much work to do that I haven’t felt any particular, the treadmill hasn’t stopped yet.

[00:20:49] Nathan Wrigley: Maybe we should have organized this podcast six months from now, and maybe you’d have felt the full weight of the relief.

[00:20:55] Chris Coyier: I’m enjoying the fact though that I get to be out on podcasts like this and talk about it though. So I appreciate that because, it’s nice to know that it’s at least a little bit of news In this industry.

[00:21:05] Nathan Wrigley: In my book, it’s a big piece of news. Let’s do the positives. Let’s do the upsides. So you’ve got a very successful website. You’ve affected a lot of people. You’ve helped a lot of people. You’ve probably met a lot of people. But there may be some unexpected consequences as well. So again, the same sort of question, but in reverse, if you look back over the last 15 years, what are the things that you’re really pleased about, that came about because of CSS-Tricks?

[00:21:32] Chris Coyier: Well, there’s so many. I was always pleased publishing an article and hearing people’s reactions to it. I think that’s part of the motivation and why it never became so painful or it never felt like a treadmill to write actual content, because it’s so satisfying. Even the early days, all the way through it, to write something and have people say like, oh yeah, I see what you mean there, that’s interesting.

Or have it actually influenced the article, or the industry in some way, you know, that you write some code that people use on their website and then they tell you about it or that they got some job because of something that they learned from CSS-Tricks or something. So satisfying, so satisfying, you know. And to kind of help people’s career in that way.

Sometimes they write for CSS-Tricks and that’s a seminal moment in their life and good things open for them. That was true for me too, though in that that CSS-Tricks was the thing that opened the door for me in other ways, like my first job. I had one job as a web designer that I kind of fell back wards into that was, it was great. It was, it was good to be hired finally to do web design work. And I was very happy to have that job, but it didn’t quite feel like a tech job. It wasn’t a startup. I was kind of the only web guy there not a newbie somewhere where everybody else knew more about building websites than I did, which is kind of what I wanted. And if I didn’t have CSS-Tricks, I’m not sure I would have been able to break into the industry in a way.

So CSS-Tricks exists. I used it in the early days, such a fan of this website, Wufoo. Which is a form builder thing. Yeah. Really great days for me. I was able to gush about it to some degree on CSS-Tricks, which doesn’t go unnoticed, if anybody was gushing about Codepen, I would, I would know about it, but blog posts have that kind of power.

I end up getting a job at Wufoo, which was my real break into the industry of tech. It was great for me cause I made more money and it gave CSS-Tricks more clout and it helped Wufoo too I’m sure, and really was just a virtuous cycle that started by virtue of that. And then I got to experience what acquisitions were like because Wufoo got purchased by Survey Monkey, which is a huge deal in my life.

Even though I had no ownership of Wufoo, I still got to like, take the ride with everybody else who did. And we all moved out to California because that’s where Survey Monkey was based. And that was just such a big transformative moment and lots of change, but really all positive in the end.

[00:23:57] Nathan Wrigley: Yeah, it’s amazing how much you can anchor back to CSS-Tricks. Just the fact that you’ve moved across country and perhaps the seed of that was a blog that you started many years before. That’s pretty remarkable.

[00:24:08] Chris Coyier: Speaking was a part of it too. It hasn’t been a huge part of my career monetarily, cause I think that it would be difficult to make your job, speaking at conferences. I don’t know if the pay is quite there in this industry. But, it can be part of a whole, that if you speak at conferences, then more people read your blog and you’re able to write a book and sell the book and all those things kind of feed into each other.

And CSS-Tricks definitely opened the door for me speaking at conferences, which I used to do a lot of. So that was a very positive thing. You know, that’s what I, and that’s what I got.

[00:24:40] Nathan Wrigley: It’s opened many doors by the sounds of it. Yeah. remarkable. So, more recently the news broke that you’d decided to sell it. Let’s just take that into two parts. The first part is why did you sell it? If you’re prepared to discuss that? And the second part is how. How do you even sell a blog? Maybe there’s a company which organized that kind of thing for you, or maybe you just stumbled into somebody and it just got done on the back of a placemat or something like that.

I don’t know. So let’s go first with why and then we’ll do the, how. Why did you decide to sell it?

[00:25:11] Chris Coyier: It’s all kind of mixed together because I didn’t set out to do it. I didn’t even shop it around really. I mean, maybe I should have or something, but I, it’s not really my style I guess. They came knocking, and I understood why. I was like, okay. Right away, it made sense to me why they would want it. I don’t think there’s a lot of suitors out there.

If I was making a list of companies that would have any desire to own CSS-Tricks. I don’t think the list is that long. I don’t mean to sell myself short, maybe it is. It doesn’t seem like blogs are a hotly traded commodity these days, you know. You don’t see a lot of blog acquisitions in a way. Especially one that’s so personal.

I think a lot of people attach CSS-Tricks to me, even though there’s so many guest writers that I’m kind of the face behind the site for better or worse. So why would you want to buy this thing that already has this face, you know? But in the case of Digital Ocean, they have long since doubled down on content marketing anyway. They would advertise on CSS-Tricks.

So they knew the potential of, surely they had analytics numbers of how successful that can be and probably were running internal numbers. That’s like, wow, what if we could do a lot more of that only, you know, we own the site so that the competition of who’s being shown advertising wise on the site falls away and it’s only us.

Content wise, I knew this, but I didn’t know to the degree of which this was true until this was further along, is that they have tons of content on their site that’s much more backend focused. I’m less backend focused as a person. So I just wasn’t as aware of it, I guess, but people that do lots of backend work, find their way to information on Digital Ocean’s site a lot.

It has just loads of good information that’s well regarded in the industry. To compliment that with buying more content that, hopefully is well-regarded content on the front end side, maybe fills a gap for them, especially knowing how important front end development is getting in the world of web development period.

I think there is a shift towards there just being a lot more front end developers because that skillset of knowing Javascript, and how much like easier hosting and stuff is getting and what a shift to JAMstack and stuff. I know that’s, a weird subject in WordPress land, but there’s a lot of that going on industry-wide.

I’m sure everyone can see that and being like, well, we should be catering, advertising, talking to front end developers as much as we are backend developers, because they’re starting to be the decision makers to, on even things like hosting. Which is what Digital Ocean is there like a cloud provider of services.

So they should be on front end developers radars as much as backend developers. And so I got it. You know, I was like, I understand why you would want this. And they’ve had some, they’re public now. So they have some money to spend and some money they, you know, so, so I was like, oh, I get that too. You know, maybe this really is a match made in heaven. And so knowing that, they could run the site, they could do it with more people than we have. You know, like I said, I’m trying to spend all my time on Codepen. So like, I haven’t sat down to say, okay, we got Jeff, we got Robin at the site. Maybe I should, like what’s a business plan for 2022, 2023 here?

Should we hire five more people and make a play at X, Y, and Z? Should we, what should we do? You know what? I would do, nothing. I would just be like, nah, let’s just keep doing what we’re doing. I don’t have the time to, to think about this. I don’t have time to staff up and, yada yada.

So when they’re like, we can put our whole community team behind this. I’m giving it to a site that I know why they want it. I have provable evidence that they do a good job with content. We can run the site with less advertising in general on it, which has always appeals to me as somebody who’s redesigned the site 19 times, the idea of redesigning the site without as much having to, to incorporate advertising into every corner of it possible seemed appealing to me. Like we could run the site a little cleaner that way and have all these people behind it and breathe new life into it.

And then of course there’s the money which I cannot talk about and don’t want to talk about, but, obviously that’s a part of decision-making duh, right. And having that be like, yeah, okay. That seems fair to me. Right on. I’ll get some of my time back, the site goes to a good place, that’s going to take care of it. It’s not even being redirected or anything. It just stays right where it is. So if you were an author who’s written for CSS-Tricks, it’s irrelevant to you.

Your, your byline stays right there. URL stays right there. If anything, your website is just being taken care of, or your article is just being taken care of by more people with even higher incentive than I had to take care of it and presented in a cleaner way, that’s just seems like a big old win-win. When I got to thinking about it and talking with my family about it, I’m like, it’s time for this change.

[00:29:58] Nathan Wrigley: Yeah. In the WordPress space, there’s been lots of acquisitions recently.

[00:30:02] Chris Coyier: Oh, yeah, what’s up with that.

[00:30:04] Nathan Wrigley: The thing, which always is released in the press release, which comes out the same day as everything is finally tied up and make public always makes the point that nothing is going to change. You know, it’s going to stay exactly the same.

Did you have any sort of red lines, any things that you said, please may we keep this bit as it is right now? Or are you just handing it over and saying, okay, it’s yours. You do what you wish.

[00:30:27] Chris Coyier: They told me early on that they were going to not, they were going to leave the site where it is. So that was part of my decision making. Now I can’t enforce that. There’s nothing in the, in any legal agreement that says that they can never change anything. I mean, it’s their site now they can do whatever they want for it, but it’s held true already, you know.

They’re just running it as it is there. And I think that’s, that’s a smart decision for now, I think because it’s complicated enough site, you might as well get to know it pretty intimately before you start making changes anyway. But I’ve seen it held true before though. I mean, when I went through that Wufoo Survey Monkey transition, you can go to Wufoo.com right now and they left it alone.

If anything, they just made it a little better over time. It hasn’t seen like intensive new development or anything, but it’s still a pretty darn nice website to make a web form on. So I lived through experiences where that stuff is no lie.

[00:31:17] Nathan Wrigley: Yeah. The only change that’s visible to me is they’ve put a fairly minimal logo next to the logo. If you know what I mean. It says powered by Digital Ocean.

[00:31:24] Chris Coyier: I mean, I did that.

[00:31:25] Nathan Wrigley: Oh, you did that. Okay. Yeah. But aside from that, it does seem to be exactly the same great content in exactly the same display. Just a complete aside from me, I have to commend your design. 19 ways that you’ve designed the site over many years. Every one of them breathtakingly good, so bravo for all of that.

[00:31:44] Chris Coyier: Yeah.

[00:31:45] Nathan Wrigley: Yeah, you’re welcome. It’s all tied up. The deal is done. You’ve mentioned a couple of times that you are going to concentrate on the project, which I think it’s fair to say is the one which provides for your family more than any other, Codepen. Have I got that right? Or are you, are you looking to branch out and use up that time that was on CSS-Tricks with something new or are you totally doubling down on Codepen?

[00:32:08] Chris Coyier: You know, if I had time that I really wanted to spend doing a side project thing, I would, I’d rather just stare at the ceiling at this point. I could use some, I use a little break. But now that time’s going to go to Codepen. Codepen, needs, we are in the middle of big, I mean, I guess changes is the right way to do it, but we have some big ideas for what Codepen could be, and we’ve had these ideas for a long time.

[00:32:31] Nathan Wrigley: Can I just stop you there actually. And can you just tell us what Codepen is? I know what it is, but maybe there’s a collection of people that will really benefit from using it. So yeah, just, yeah. Tell us what it is.

[00:32:41] Chris Coyier: Yeah. You know, and it started off as a thing for CSS-Tricks anyway. I mean, the stories are interwoven in a way. So Codepen is like a code editor in the browser. So pen is like the term we have for a thing that you create on Codepen, and it’s a social network in that you sign up for it, you have an account, do you have a profile on it?

It’s free to do so. Uh, and then there’s pro features. So it’s, uh, it’s a SaaS product, but freemium, you know, like you can sign up for pro and you get extra stuff. But the point of it is, you know, I follow you, you follow me, you’re making work, I’m making work and we can like each other’s work and talk about it and all that.

And those work are those pens and pens are HTML, CSS and JavaScript. It’s entirely focused on the front end side of the web. And people use it to like build little demos. They’re like, look at this, look at this thing that I’ve made. And sometimes it’s art. Sometimes it’s a reduced test case for a problem they’re having. Sometimes it’s a little example of something they’re going to send to a client. Sometimes it’s just an exploration of a cool idea they want to get out of their head. Sometimes they’re learning some new technology that they’ve never played with before. So why not do it on Codepen, because it’s so quick and easy to get started?

Sometimes people learning do it because it has this built in ability, basically when you stop typing into one of the editors, the code editors on Codepen, there’s a preview right next to it that instantly updates. So there’s that mental connection between the code that you’re writing in the output for it? Which of course you can wire up locally as well, but on Codepen, it’s just a website. So you click a button and you’re in that environment immediately. You don’t have to install anything. You can come back to it later and it’s still waiting there for you. You don’t have to save it to your file system and worry about losing it. You can search for it. I know I’ve just spit out a lot of words there, but the core of it is it’s easy to use code editor, right in the browser that has social features attached to it.

[00:34:38] Nathan Wrigley: So you’re going to be doubling down on work there. And presumably you’ve got a little bit of extra time to do that. What’s on the roadmap.

[00:34:44] Chris Coyier: Yeah. I mean, I can’t tell you everything in the whole roadmap, but some of it is fairly obvious in the stuff we’ve talked about already is that we want you to be able to do more on Codepen, but without losing the simplicity, that’s already there. There’s just the world of web development is ever-changing, which is just like a very obvious thing to say, but there’s always new libraries and new processors and new ways to approach building websites.

And we kind of want to embrace that change and build and change and morph our online editor experience to be just more ready forever change. You know, ready for whatever comes along the industry and gets ready for it and just make a much better online editor experience to the point where you’re like, this is so good, I want to use it. That you use Codepen because the editor experience is just so good, and integrates with everything that you need it to be integrated with and can build whatever you want to build with it, but still keeps that like simplicity keeps that catching people earlier in their careers.

That’s the one thing Codepen does well is we catch people early in their coding careers as they’re just starting to learn. I want to keep them, as they level up and learn more.

[00:35:54] Nathan Wrigley: Well, it’s linked from almost everywhere, isn’t it? If you’re learning something off a third-party website, you more or less guarantee that there’s a Codepen link on that somewhere, sort of demonstrating, okay, this bit of code will output this, okay, go and check on Codepen. It’s just used absolutely everywhere. It’s a sublimely good product.

[00:36:11] Chris Coyier: For me as I’m running Codepen, all I see is the things that it can’t do, you know, or the things that I wish that I could do. And so I want to, want to fix those, fix those gaps and get even more people. And then the business model, there’s some advertising on it like CSS-Tricks because there’s a lot of eyeballs on Codepen and it’s money worth making if you can. But I’d prefer to run it without that, if I could.

I’m sure that’s not good news to our, you know, our advertising partners or whatever, but sorry about that. I’d rather Just have the product be so good that that’s the way. It’s already 75% there. But the idea being that if you’re pro you know, you get all these extra things, you get the ability to make things private and you get the ability to collaborate with people in real time, and you get the ability to upload assets that will be your host for your assets if we want. And there’s all these things that you get for being pro.

I want to make those even bigger and better and bolder and have there be much more reasons for you to go and stay pro on Codepen. I think there’s just a lot of opportunity there. And, but this is a big thing.

Like CSS-Tricks I feel like I could run alone if I had to. You know what I mean, cause it’s just a blog, right? I know WordPress pretty well. I can write. That’s fine. Codepen I cannot. Codepen and I, there’s no way I can run alone. This is a very collaborative effort that takes lots of different skill sets to pull off. And it’s just, it’s the biggest thing I’ve ever done. And if we pull off everything that we’re trying to pull off, it will be the biggest thing I ever do.

[00:37:37] Nathan Wrigley: Just to wrangle it back to WordPress quickly toward the end. You’ve been with WordPress for a long time. You said every iteration of the website has been on WordPress. There’s been a lot of WordPress content. Obviously everything to do with CSS is helping every WordPress website. And I seem to recall purchasing digging into WordPress, your book Jeff Starr right back in the day, when I think he was still on version one. Are we going to see you hanging around the WordPress space at any point, or is that, is that a book which is closing?

[00:38:05] Chris Coyier: I’m very sure you will. I mean that would be like, absolutely no promises here, but wouldn’t that be neat. If you could build a WordPress site on Codepen? It’s not like we’re barking up that tree immediately, but like, that’s the kind of thing I have my eye on, you know, like, wouldn’t that be cool if CodePen was so advanced, you could build a WordPress site on it? Anyway, don’t read too much into that. But if I was going to build a new website tomorrow, and it was content focused in any way. I would just immediately pick WordPress to do it. I have ideas all the time. I was just driving around this morning and thought of some things that I think would be cool to build and do in WordPress. And I’m like, well, I absolutely don’t have time for that now, but I’m going to build that someday gosh, darn it.

[00:38:45] Nathan Wrigley: Well, it would be very nice to have Chris Coyier in our community for decades to come. Chris, for all of the hard work that you’ve done over the years, making everybody’s life easier to learn CSS, we thank you really, really has helped a lot of people, me included in that list. So firstly, thanks for that.

And secondly, thank you for coming on the podcast today. I really appreciate it. Just before we go. What are in the future, the best places to find you? That’s probably different to how it was six weeks ago.

[00:39:12] Chris Coyier: Well, not really, cause I you know, I’m a big proponent of having a, uh, a personal website. So mine is chriscoyier.net, a WordPress site of course. I did redesign it. It was on my list to do post-acquisition cause I was like, well, you know, I need to not have one of the first sentences say that I own and run CSS-Tricks on it. So I could have easily updated that sentence, but it’s also kind of my style to, just blah, I’m going to redesign it in an hour.

[00:39:38] Nathan Wrigley: I like it, by the way, it’s very, very bold and beautiful.

[00:39:42] Chris Coyier: That was about an hour’s worth of work this morning. Cause you know, the bones of a WordPress site, that’s this simple anyway, there’s no, it’s just a very simple header, a very simple footer and then just a couple of custom post types in there for the different types. There’s very little to this and I’ve done it so many times that really I’m not even exaggerating, it really was probably just a couple hours worth of work to knock out a little design like that and kind of update the text for what I want to that to say.

But all that said, it’s really my home base because rather than give you my Twitter or something, I’d rather give you my personal website, get the RSS feed. You know, you do want to follow me on Twitter, that’s all linked up from my personal website. Again, chriscoyier.net.

[00:40:20] Nathan Wrigley: Chris Coyier. Thank you so much for coming on the podcast today. I really appreciate it.

[00:40:24] Chris Coyier: My pleasure Nathan. Thank you.

Collective #697



Creating a Schema-Based Form System

Tania Rascia shows how to make a form system where we can simply define the schema of a form and pass it into a component that takes care of all the common form needs.

Read it








Inclusive Design

Read about inclusive design which describes methodologies to create products that understand and enable people of all backgrounds and abilities.

Check it out





California Design System

The California Design System makes it easy for state digital teams to build accessible, consistent, and performant services and products. Interesting to learn from.

Check it out




dddraw

A free and simple online drawing tool that makes it easy to freehand draw SVGs.

Check it out





SkyBot

Super cool project: Luke Berndt made a system that shoots photos of all the airplanes that fly over his house.

Check it out


The post Collective #697 appeared first on Codrops.

Different Favicon for Development

I bet a lot of us tend to have the production website and the development website up simultaneously a lot. It's almost a developer cliché at this point to make some local change, refresh, refresh, refresh, refresh, and just not see the change, only to discover you were looking at the production website, not your local development website.

It's just funny at first, but it's frustrating if it happens a lot. It's also totally avoidable by having an obvious visual¹ difference between the two sites. An easy way to do that? Different favicons.

There is no real trick to this. I literally just have a different favicon.ico file in development than I do in production. On this (WordPress) site, I only version control and deploy the wp-content folder, which is not the root of the site where the favicon lives. Any files at the root I have to manually SFTP in to change. I simply changed my local version, and there it sits, being all different.

Other trickery

Speaking of favicons...

This has me wondering what best practices for favicons are in 2020, at least for garden variety content websites like this.

I hate to say it, but I don't really care about what the icon is when someone adds this site to the home screen on an iPad, ya know? Aside from one fellow who wanted a copy of the whole database to use the site offline to teach prisoners, nobody has ever asked me about "installing" CSS-Tricks.

Nor do I care about the tile color on a Windows 8 tablet or to customize the color of the browser chrome on Android. That kinda stuff tends to be part of the process when "generating" favicons.

I do care that the favicon looks good on high-resolution displays (a 32×32 graphic isn't much of a splurge). I like the idea of SVG favicons. I like the idea of making sure dark mode is handled. I like the idea of doing this with as little code and files as possible. Anyone dig into this lately and want to enlighten me?

  1. "Visual" difference. Hm. I wonder what could be done for developers with visual impairments? Ideas?

The post Different Favicon for Development appeared first on CSS-Tricks.

CSS-Only Carousel

It's kind of amazing how far HTML and CSS will take you when building a carousel/slideshow.

  1. Setting some boxes in a horizontal row with flexbox is easy.
  2. Showing only one box at a time with overflow and making it swipable with -webkit-overflow-scrolling is easy.
  3. You can make the "slides" line up nicely with scroll-snap-type.
  4. A couple of #jump-links is all you need to make navigation for it, which you can make all nice and smooth with scroll-behavior.

See the Pen
Real Simple Slider
by Chris Coyier (@chriscoyier)
on CodePen.

Christian Schaefer has taken it a little further with next and previous buttons, plus an auto-play feature that stops playing once interaction starts.

See the Pen
A CSS-only Carousel Slider
by Christian Schaefer (@Schepp)
on CodePen.

About that auto-play thing — it's a bonafide CSS trick:

  1. First I slowly offset the scroll snap points to the right, making the scroll area follow along due to being snapped to them.
  2. After having scrolled the width of a whole slide, I deactivate the snapping. The scroll area is now untied from the scroll snap points.
  3. Now I let the scroll snap points jump back to their initial positions without them "snap-dragging" the scroll area back with them
  4. Then I re-engage the snapping which now lets the scroll area snap to a different snap point 🤯

Cool.

JavaScript-powered slideshows (e.g. with Flickty) can be real nice, too. There is just something neat about getting it done with so little code.

See the Pen
Flickity - wrapAround
by Dave DeSandro (@desandro)
on CodePen.

The post CSS-Only Carousel appeared first on CSS-Tricks.

How Auto Margins Work in Flexbox

Robin has covered this before, but I've heard some confusion about it in the past few weeks and saw another person take a stab at explaining it, and I wanted to join the party.

Say you have a flex container with some flex items inside that don't fill the whole area.

See the Pen
ZEYLVEX
by Chris Coyier (@chriscoyier)
on CodePen.

Now I want to push that "Menu" item to the far right. That's where auto margins come in. If I put a margin-left: auto; on it, it'll push as far away as it possibly can on that row.

See the Pen
WNbRLbG
by Chris Coyier (@chriscoyier)
on CodePen.

Actually, you might consider margin-inline-start: auto; instead and start using logical properties everywhere so that you're all set should you need to change direction.

See the Pen
gObgZpb
by Chris Coyier (@chriscoyier)
on CodePen.

Also, note that auto margins work in both directions as long as there is room to push. In this example, it's not alignment that is moving the menu down, it's an auto margin.

See the Pen
XWJpobE
by Chris Coyier (@chriscoyier)
on CodePen.

The post How Auto Margins Work in Flexbox appeared first on CSS-Tricks.

Moving Rainbow Underlines

I absolutely love the design of the Sandwich site. Among many beautiful features are these headlines with rainbow underlines that move as you scroll. It's not scroll-jacking — it's just a minor design feature that uses scroll position to enact a little movement.

To draw the rainbows themselves, we could use a linear gradient with hard-stops, the same kinda concept as drawing stripes in CSS. That's a big ol' chunk of CSS, which is fine, but I see they've opted for a background-image instead. Here's that as an SVG, which is 661 bytes (tiny tiny). We can make it look like an underline by setting the background-size to limit the height and position it along the bottom with background-position.

We'll do it on an inline element so the underline breaks where the words break:

h1 {
  span {
    background-image: url(spectrum.svg);
    background-repeat: repeat-x;
    background-size: 100vw 0.2em;
    background-position: left bottom 5px; 
  }
}

To animate it, we move the background-position-x. Not a particularly performant thing to animate, but we're not really animating it anyway — it's just moving based on scroll position. Rather than manually manipulate the background-position-x, we'll set it with a custom property, then manipulate the custom property with JavaScript.

background-position-x: var(--scrollPos);

Updating that variable while the page scrolls is easy peezy:

window.addEventListener("scroll", e => {
  let scrollTop = document.body.scrollTop ? document.body.scrollTop : document.documentElement.scrollTop; 
  let newPos = scrollTop + "px";
  document.documentElement.style.setProperty('--scrollPos', newPos);
});

Here it is working!

See the Pen
Rainbow Underlines
by Chris Coyier (@chriscoyier)
on CodePen.

See that kinda janky line where I'm either using document.body or document.documentElement? That's a stupid cross-browser thing where the "scrolling element" is different in Safari versus everything else.

While doing this I learned that you can use document.scrollingElement instead to avoid the pain there. I'll leave a comment in the code about that, but leave the original line for posterity.

The post Moving Rainbow Underlines appeared first on CSS-Tricks.

Raw GraphQL Querying

GraphQL has all kinds of awesome tooling built around it. But like everything on the web, it ultimately comes down to data shootin' across the ol' network and responses coming back. If you need to talk to a GraphQL API endpoint, you don't absolutely have to use some kind of framework or library to make requests against it. As a matter of fact, you can do it pretty cleanly in vanilla JavaScript.

Take the Pokémon API, available in GraphQL, which I found via this list of APIs. It has a GraphiQL interface for exploring.

From that page, you can execute queries and see the results. You can also poke into the Network tab in DevTools and see the payload for requests it sends off, and see that it's just a bit of JSON that is POSTed.

We can make our own JSON in that format too! First, we'll make it an object in the right format, utilizing template literals to make the GraphQL query look nice (which is actually required because the query syntax is dependent on white-space). Then we JSON-ify it with the native JavaScript API and POST it via the also-native fetch API.

See the Pen
Raw GraphQL
by Chris Coyier (@chriscoyier)
on CodePen.

Easy cheesy. And no fancy tooling to request exactly what you need, which is the core benefit of GraphQL.

The post Raw GraphQL Querying appeared first on CSS-Tricks.

Oh Hey, Padding Percentage is Based on the Parent Element’s Width

I learned something about percentage-based (%) padding today that I had totally wrong in my head! I always thought that percentage padding was based on the element itself. So if an element is 1,000 pixels wide with padding-top: 50%, that padding is 500 pixels. It's weird having top padding based on width, but that's how it works — but only sorta. The 50% is based on the parent element's width, not itself. That's the part that confused me.

The only time I've ever messed with percentage padding is to do the aspect ratio boxes trick. The element is of fluid width, but you want to maintain an aspect ratio, hence the percentage padding trick. In that scenario, the width of the element is the width of the parent, so my incorrect mental model just never mattered.

It doesn't take much to prove it:

See the Pen
% padding is based on parent, not itself
by Chris Coyier (@chriscoyier)
on CodePen.

Thanks to Cameron Clark for the email about this:

The difference is moot when you have a block element that expands to fill the width of its parent completely, as in every example used in this article. But when you set any width on the element other than 100%, this misunderstanding will lead to baffling results.

They pointed to this article by Aayush Arora who claims that only 1% of developers knew this.

The post Oh Hey, Padding Percentage is Based on the Parent Element’s Width appeared first on CSS-Tricks.

CSS-Tricks Chronicle XXXVII

Chronicle posts are opportunities for me to round-up things that I haven't gotten a chance to post about yet, rounded up together. It's stuff like podcasts I've had the good fortune of being on, conferences I've been at or are going to be at, happenings at ShopTalk and CodePen, and more.

My talk at JAMstack_conf

We recorded a live episode of ShopTalk Show as well:

A guest on The Product Business Podcast

Happenings at CodePen

As I write and publish this, we're rolling out a really cool new UI feature. Wherever you're browsing CodePen you see grids of items. For example, a 6-up grid of Pens. Click them and it takes you to the Pen Editor (there are some shortcuts, like clicking the views number takes you to Full Page View and clicking the comments number takes you to Details View). Now, there is a prominent action that will expand the Pen into a modal right on that page. This will allow you to play with the Pen, see it's code, see the description, tags, comments... really everything related to that Pen, and without leaving the page you were on. It's a faster, easier, and more fun way to browse around CodePen. If you're not PRO, there are some ads as part of it, which helped justify it from a business perspective.

Other newer features include any-size Teams, user blocking, and private-by-default.

Oh! And way nicer Collections handling:

Part of life at CodePen is also all the things we do very consistently week after week, like publish our weekly newsletter The CodePen Spark, publish our podcast CodePen Radio, and produce weekly Challenges to give everyone a fresh prompt to build something from if you could use the nudge.

Upgrading to PRO is the best thing you can do to support me and these sites.

My talk at FITC's Web Unleashed

My talk at Craft CMS's dotall Conf

I was on a panel discussion there as well: The Future of Web Development Panel with Ryan Irelan, Andrew Welch, Matsuko Friedland, Marion Newlevant, and myself. Here's that video:

Conferences

I don't have any more conferences in 2019, but I'll be at a handful of them in 2020 I'm sure. Obviously I'm pretty interested in anything that gets into front-end web development.

Remember we have a whole calendar site for upcoming front-end development-related conferences! Please submit any you happen to see missing.

The only ones I have booked firmly so far are Smashing Conf in April / San Francisco and June / Austin.

Happenings at ShopTalk

We don't even really have "seasons" on ShopTalk Show. Instead, we're just really consistent and put out a show every week. We'll be skipping just one show over the holidays (that's a little nuts, honestly, we should plan to take a longer break next year).

We're edging extremely close to hitting episode #400. I think it'll end up being in February. Considering we do about a show a week, that's getting on eight years. Questions like: Are we played out? Are people finding us still? Are people afraid to jump in? Are people as engaged with the show this far in? - have been going through my mind. But anytime we mention stuff along those lines on the show, we hear from lots of people just starting to listen, having no trouble, and enjoying it. I think having a "brand" as established as we've done with ShopTalk Show is ultimately a good thing and worth keeping on largely as-is. We might not be as hot'n'fresh as some new names in podcasting, but even I find our show consistently interesting.

Some of our top-downloaded shows in the last few months:

Ducktapes

I was on an episode of the Duck Tapes Podcast they called SVG with Chris Coyier:

The post CSS-Tricks Chronicle XXXVII appeared first on CSS-Tricks.

Show Search Button when Search Field is Non-Empty

I think the :placeholder-shown selector is tremendously cool. It allows you to select the placeholder of an input (<input placeholder="...">) when that placeholder is present. Meaning, the input does not yet have any value. You might think input[value] could do that, or help match on the actual value, but it can't.

This makes :placeholder-shown one of the few CSS properties that we have that can react to user-initiated state joining the likes of :hover-and-friends, :checked (checkbox hack!), and the also-awesome :focus-within.

One way we can use it is to check whether the user entered any text into a search field. If yes, then reveal the search button visually (never hide it for assistive tech). If no, then leave it hidden. It's just a fun little "space-saving" technique not terrible unlike float labels.

So, perhaps we start with a semantic search form:

<form action="#" method="GET" class="search-form">
  <!-- Placeholders aren't labels! So let's have a real label -->
  <label for="search" class="screen-reader-text">Search</label>
  <input id="search" type="search" class="search-input" placeholder="Enter search terms...">
  <button class="search-button">Search</button>
</form>

We hide the search label visually with one of those special screen-reader-only classes because it will always be hidden visually. But we'll hide the button by pushing it outside the form with hidden overflow.

.search-form {
  /* we'll re-use this number, so DRYing up */
  --searchButtonWidth: 75px;

  overflow: hidden;
  position: relative;
}

.search-input {
  /* take full width of form */
  width: 100%;
}

.search-button {
  position: absolute; 
  /* push outside the form, hiding it */
  left: 100%;
  width: var(--searchButtonWidth);
}

Then the trick is to pull the search button back in when the placeholder goes away (user has entered a value):

/* ... */

.search-input:not(:placeholder-shown) ~ .search-button {
  /* pull back the negative value of the width */
  transform: translateX(calc(-1 * var(--searchButtonWidth)));
}
.search-button {
  position: absolute; 
  left: 100%;
  width: var(--searchButtonWidth);
  /* animate it */
  transition: 0.2s;
}

Which ends up like this:

See the Pen
:placeholder-shown revealing button
by Chris Coyier (@chriscoyier)
on CodePen.

I saw this idea in a Pen by Liam Johnston. Cool idea, Liam!

I know that using the placeholder attribute at all is questionable, so your mileage may vary. I'll admit that I'm mostly intrigued by the state-handling aspects of it directly in CSS and how it can be used — like the infamous checkbox hack.

Support is good. One of those where when Edge is firmly Chromium, it's in the clear.

This browser support data is from Caniuse, which has more detail. A number indicates that browser supports the feature at that version and up.

Desktop

ChromeOperaFirefoxIEEdgeSafari
47345111*769

Mobile / Tablet

iOS SafariOpera MobileOpera MiniAndroidAndroid ChromeAndroid Firefox
9.0-9.2NoNo767868

The post Show Search Button when Search Field is Non-Empty appeared first on CSS-Tricks.

Ten-Ton Widgets

At a recent conference talk (sorry, I forget which one), there was a quick example of poor web performance in the form of a third-party widget. The example showed a site that installed the widget in order to add a "email us" button fixed to the bottom right of the viewport. Not even a live-chat widget — just an email thing. It weighed in at something like 470KB, which is straight bananas.

Just in case you are someone who feels trapped into using a ten-ton widget because you aren't yet sure how to replicate the same functionality, I've prepared a small chunk of HTML for you.

It's 602 Bytes, or about 1/10th of 1% of the size of that other widget — with nothing to download, parse or render block.

See the Pen
Mailto Fixed Postion Widget
by Chris Coyier (@chriscoyier)
on CodePen.

Perhaps on your own site, you'd move the styles out to your stylesheet and add in some hover and focus styles.

It's not that third-party JavaScript has to be bad. It just has a habit of being bad.

My friend Richard showed me a new product he built called Surfacer. It's like an RSS widget that you can put anywhere.

See the Pen
Surfacer
by Chris Coyier (@chriscoyier)
on CodePen.

That's a 773 Byte JavaScript file that does a 3.5KB Ajax request for data, and you'd place it at the end of the document to avoid any render-blocking. It would be nice to see more of this kind of thing.

The post Ten-Ton Widgets appeared first on CSS-Tricks.

Stop Animations During Window Resizing

Say you have page that has a bunch of transitions and animations on all sorts of elements. Some of them get triggered when the window is resized because they have to do with size of the page or position or padding or something. It doesn't really matter what it is, the fact that the transition or animation runs may contribute to a feeling of jankiness as you resize the window. If those transitions or animations don't deliver any benefit in those scenarios, you can turn them off!

The trick is to apply a class that universally shuts off all the transitions and animations:

let resizeTimer;
window.addEventListener("resize", () => {
  document.body.classList.add("resize-animation-stopper");
  clearTimeout(resizeTimer);
  resizeTimer = setTimeout(() => {
    document.body.classList.remove("resize-animation-stopper");
  }, 400);
});

Now we have a resize-animation-stopper class on the <body> that can force disable any transition or animation while the window is being resized, and goes away after the timeout clears.

.resize-animation-stopper * {
  animation: none !important;
  transition: none !important;
}

There is probably some more performant way of doing this than setTimeout, but that's the concept. I use this right here on this very site (v17) after noticing some significant resizing jank. It hasn't entirely eliminated the jank but it's noticeably better.

Here's an example:

See the Pen
Turn off animation on resize?
by Chris Coyier (@chriscoyier)
on CodePen.

That demo is mostly just for the working code. There probably isn't enough going on transitions-wise to notice much resize jank.

The post Stop Animations During Window Resizing appeared first on CSS-Tricks.

The Teletype Text Element Lives On… at Least on This Site

It was this: <tt>

I say "was" because it's deprecated. It may still "work" (like everybody's favorite <marquee> in some browsers), but it could stop working anytime, they say. The whole purpose of it was to display text in a monospace font, like the way Teletype machines used to.

Dave used it jokingly the other day.

Which got me thinking how much I used to use that element!

Right here on CSS-Tricks. See, in my early days, I learned about that element and how its job is to set text as monospace. I thought, oh! like code! and then for years that's how I marked up code on this site. I had never heard of the <code> element! When I did, I switched over to that. But I still haven't updated every single article from <tt> to <code>. It lingers in articles like this:

I bring this up just because it's a funny little example of not knowing what you don't know. It's worth having a little sympathy for people early in their journey and just doing things that get the job done because that's all they know. We've all been there... and are always still there to some degree.

The post The Teletype Text Element Lives On… at Least on This Site appeared first on CSS-Tricks.

Some Hands-On with the HTML Dialog Element

This is me looking at the HTML <dialog> element for the first time. I've been aware of it for a while, but haven't taken it for a spin yet. It has some pretty cool and compelling features. I can't decide for you if you should use it in production on your sites, but I'd think it's starting to be possible.

It's not just a semantic element, it has APIs and special CSS.

We'll get to that stuff in a moment, but it's notable because it makes the browser support stuff significant.

When we first got HTML5 elements like <article>, it pretty much didn't matter if the browser supported it or not because nothing was worse-off in those scenarios if you used it. You could make it block-level and it was just like a meaningless div you would have used anyway.

That said, I wouldn't just use <dialog> as a "more semantic <div> replacement." It's got too much functionality for that.

Let's do the browser support thing.

As I write:

  • Chrome's got it (37+), so Edge is about to get it.
  • Firefox has the User-Agent (UA) styles in place (69+), but the functionality is behind a dom.dialog_element.enabled flag. Even with the flag, it doesn't look like we get the CSS stuff yet.
  • No support from Safari.

It's polyfillable.

It's certainly more compelling to use features with a better support than this, but I'd say it's close and it might just cross the line if you're the polyfilling type anyway.

On to the juicy stuff.

A dialog is either open or not.

<dialog>
  I'm closed.
</dialog>

<dialog open>
  I'm open.
</dialog>

There is some UA styling to them.

It seems to match in Chrome and Firefox. The UA stylesheet has it centered with auto margins, thick black lines, sized to content.

See the Pen
Basic Open Dialog
by Chris Coyier (@chriscoyier)
on CodePen.

Like any UA styles, you'll almost surely override them with your own fancy dialog styles — shadows and typography and whatever else matches your site's style.

There is a JavaScript API for opening and closing them.

Say you have a reference to the element named dialog:

dialog.show();
dialog.hide();

See the Pen
Basic Togglable Dialog
by Chris Coyier (@chriscoyier)
on CodePen.

You should probably use this more explicit command though:

dialog.showModal();

That's what makes the backdrop work (and we'll get to that soon). I'm not sure I quite grok it, but the the spec talks about a "pending dialog stack" and this API will open the modal pending that stack. Here's a modal that can open a second stacking modal:

See the Pen
Basic Open Dialog
by Chris Coyier (@chriscoyier)
on CodePen.

There's also an HTML-based way close them.

If you put a special kind of form in there, submitting the form will close the modal.

<form method="dialog">
  <button>Close</button>
</form>

See the Pen
Dialog with Form that Closes Dialog
by Chris Coyier (@chriscoyier)
on CodePen.

Notice that if you programmatically open the dialog, you get a backdrop cover.

This has always been one of the more finicky things about building your own dialogs. A common UI pattern is to darken the background behind the dialog to focus attention on the dialog.

We get that for free with <dialog>, assuming you open it via JavaScript. You control the look of it with the ::backdrop pseudo-element. Instead of the low-opacity black default, let's do red with stripes:

See the Pen
Custom Dialog Backdrop
by Chris Coyier (@chriscoyier)
on CodePen.

Cool bonus: you can use backdrop-filter to do stuff like blur the background.

See the Pen
Native Dialog
by Chris Coyier (@chriscoyier)
on CodePen.

It moves focus for you

I don't know much about this stuff, but I can fire up VoiceOver on my Mac and see the dialog come into focus see that when I trigger the button that opens the modal.

It doesn't trap focus there, and I hear that's ideal for modals. We have a clever idea for that utilizing CSS you could explore.

Rob Dodson said: "modals are actually the boss battle at the end of web accessibility." Kinda nice that the native browser version helps with a lot of that. You even automatically get the Escape key closing functionality, which is great. There's no click outside to close, though. Perhaps someday pending user feedback.

Ire's article is a go-to resource for building your own dialogs and a ton of accessibility considerations when using them.

The post Some Hands-On with the HTML Dialog Element appeared first on CSS-Tricks.

Breakout Buttons

Andy covers a technique where a semantic <button> is used within a card component, but really, the whole card is clickable. The trick is to put a pseudo-element that goes beyond the button, covering the entire card. The tradeoff is that the pseudo-element sits on top of the text, so text selection is hampered a bit. I believe this is better than making the whole dang area a <button> because that would sacrifice semantics and likely cause extreme weirdness for assistive technology.

See the Pen
Semantic, progressively enhanced “break-out” button
by Andy Bell (@andybelldesign)
on CodePen.

You could do the same thing if your situation requires an <a> link instead of a <button>, but if that's the case, you actually can wrap the whole area in the link without much grief then wrap the part that appears to be a button in a span or something to make it look like a button.

This reminds me of the nested link problem: a large linked block that contains other different linked areas in it. Definitely can't nest anchor links. Sara Soueidan had the best answer where the "covering" link is placed within the card and absolutely positioned to cover the area while other links inside could be be layered on top with z-index.

I've moved her solution to a Pen for reference:

See the Pen
Nested Links Solution
by Chris Coyier (@chriscoyier)
on CodePen.

The post Breakout Buttons appeared first on CSS-Tricks.

Filtering Data Client-Side: Comparing CSS, jQuery, and React

Say you have a list of 100 names:

<ul>
  <li>Randy Hilpert</li>
  <li>Peggie Jacobi</li>
  <li>Ethelyn Nolan Sr.</li> 
  <!-- and then some -->
</ul>

...or file names, or phone numbers, or whatever. And you want to filter them client-side, meaning you aren't making a server-side request to search through data and return results. You just want to type "rand" and have it filter the list to include "Randy Hilpert" and "Danika Randall" because they both have that string of characters in them. Everything else isn't included in the results.

Let's look at how we might do that with different technologies.

CSS can sorta do it, with a little help.

CSS can't select things based on the content they contain, but it can select on attributes and the values of those attributes. So let's move the names into attributes as well.

<ul>
  <li data-name="Randy Hilpert">Randy Hilpert</li>
  <li data-name="Peggie Jacobi">Peggie Jacobi</li>
  <li data-name="Ethelyn Nolan Sr.">Ethelyn Nolan Sr.</li> 
  ...
</ul>

Now to filter that list for names that contain "rand", it's very easy:

li {
  display: none;
}
li[data-name*="rand" i] {
  display: list-item;
}

Note the i on Line 4. That means "case insensitive" which is very useful here.

To make this work dynamically with a filter <input>, we'll need to get JavaScript involved to not only react to the filter being typed in, but generate CSS that matches what is being searched.

Say we have a <style> block sitting on the page:

<style id="cssFilter">
  /* dynamically generated CSS will be put in here */
</style>

We can watch for changes on our filter input and generate that CSS:

filterElement.addEventListener("input", e => {
  let filter = e.target.value;
  let css = filter ? `
    li {
      display: none;
    }
    li[data-name*="${filter}" i] {
      display: list-item;
    }
  ` : ``;
  window.cssFilter.innerHTML = css;
});

Note that we're emptying out the style block when the filter is empty, so all results show.

See the Pen
Filtering Technique: CSS
by Chris Coyier (@chriscoyier)
on CodePen.

I'll admit it's a smidge weird to leverage CSS for this, but Tim Carry once took it way further if you're interested in the concept.

jQuery makes it even easier.

Since we need JavaScript anyway, perhaps jQuery is an acceptable tool. There are two notable changes here:

  • jQuery can select items based on the content they contain. It has a selector API just for this. We don't need the extra attribute anymore.
  • This keeps all the filtering to a single technology.

We still watch the input for typing, then if we have a filter term, we hide all the list items and reveal the ones that contain our filter term. Otherwise, we reveal them all again:

const listItems = $("li");

$("#filter").on("input", function() {
  let filter = $(this).val();
  if (filter) {
    listItems.hide();
    $(`li:contains('${filter}')`).show();
  } else {
    listItems.show();
  }
});

It's takes more fiddling to make the filter case-insensitive than CSS does, but we can do it by overriding the default method:

jQuery.expr[':'].contains = function(a, i, m) {
  return jQuery(a).text().toUpperCase()
      .indexOf(m[3].toUpperCase()) >= 0;
};

See the Pen
Filtering Technique: jQuery
by Chris Coyier (@chriscoyier)
on CodePen.

React can do it with state and rendering only what it needs.

There is no one-true-way to do this in React, but I would think it's React-y to keep the list of names as data (like an Array), map over them, and only render what you need. Changes in the input filter the data itself and React re-renders as necessary.

If we have an names = [array, of, names], we can filter it pretty easily:

filteredNames = names.filter(name => {
  return name.includes(filter);
});

This time, case sensitivity can be done like this:

filteredNames = names.filter(name => {
  return name.toUpperCase().includes(filter.toUpperCase());
});

Then we'd do the typical .map() thing in JSX to loop over our array and output the names.

See the Pen
Filtering Technique: React
by Chris Coyier (@chriscoyier)
on CodePen.

I don't have any particular preference

This isn't the kind of thing you choose a technology for. You do it in whatever technology you already have. I also don't think any one approach is particularly heavier than the rest in terms of technical debt.

The post Filtering Data Client-Side: Comparing CSS, jQuery, and React appeared first on CSS-Tricks.

Nested Gradients with background-clip

I can't say I use background-clip all that often. I'd wager it's hardly ever used in day-to-day CSS work. But I was reminded of it in a post by Stefan Judis, which coincidentally was itself a learning-response post to a post over here by Ana Tudor.

Here's a quick explanation.

You've probably seen this thing a million times:

The box model visualizer in DevTools.

That's showing you the size and position of an element, as well as how that size is made up: content size, padding, margin, and border.

Those things aren't just theoretical to help with understanding and debugging. Elements actually have a content-box, padding-box, and border-box. Perhaps we encounter that most often when we literally set the box-sizing property. (It's tremendously useful to universally set it to border-box).

Those values are the same values as background-clip uses! Meaning that you can set a background to only cover those specific areas. And because multiple backgrounds is a thing, that means we can have multiple backgrounds with different clipping on each.

Like this:

See the Pen
Multiple background-clip
by Chris Coyier (@chriscoyier)
on CodePen.

But that's boring and there are many ways to pull off that effect, like using borders, outline, and box-shadow or any combination of them.

What is more interesting is the fact that those backgrounds could be gradients, and that's a lot harder to pull off any other way!

See the Pen
Nested Gradients
by Chris Coyier (@chriscoyier)
on CodePen.

The post Nested Gradients with background-clip appeared first on CSS-Tricks.

Lazy load embedded YouTube videos

This is a very clever idea via Arthur Corenzan. Rather than use the default YouTube embed, which adds a crapload of resources to a page whether the user plays the video or not, use the little tiny placeholder webpage that is just an image you can click that is linked to the YouTube embed.

It still behaves essentially exactly the same: click, play video in place.

The trick is rooted in srcdoc, a feature of <iframe> where you can put the entire contents of an HTML document in the attribute. It's like inline styling but an inline-entire-documenting sort of thing. I've used it in the past when I embedded MailChimp-created newsletters on this site. I'd save the email into the database as a complete HTML document, retrieve it as needed, and chuck it into an <iframe> with srcdoc.

Arthur credits Remy for a tweak to get it working in IE 11 and Adrian for some accessibility tweaks.

I also agree with Hugh in the comments of that post. Now that native lazy loading has dropped in Chrome (see our coverage) we might as well slap loading="lazy" on there too, as that will mean no requests at all if it renders out of viewport.

I'll embed a demo here too:

See the Pen
Lazy Loaded YouTube Video
by Chris Coyier (@chriscoyier)
on CodePen.

Direct Link to ArticlePermalink

The post Lazy load embedded YouTube videos appeared first on CSS-Tricks.