Search

495: Snow Blower Won’t Start, CSS Resets, Nuking Margin, Making Your Website Better, Testing on a Craptop

Download MP3

Chris can't remember how to get his snow blower working, and Dave can't remember how to use Docker. We're also talking CSS Reset, nuking margin, one thing you can do to make your website better, getting rid of 3rd party Javascript, testing your product on a craptop, and defensive CSS.

Guests

Chris Coyier and Dave Rupert in silly sunglasses and a sign that says Shawp Tawlkk Shough DOT COM

Chris Coyier and Dave Rupert

This episode is with just Chris & Dave, ShopTalk Show's hosts. Chris is the co-founder of CodePen and creator of CSS-Tricks, and Dave is lead developer at Paravel.

Time Jump Links

  • 00:58 Starting the snowblower is to starting Docker
  • 05:39 CSS Reset
  • 14:47 Nuking margin?
  • 17:45 Sponsor: Automattic
  • 19:16 What's one thing you can do to make your website better?
  • 23:57 Sponsor: Backlight
  • 25:25 Getting rid of 3rd party javascript
  • 32:38 Test your product on a craptop
  • 37:29 Defensive CSS

Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show. This is kind of a shorty episode. I'm Dave Rupert and with me is Chris Coyier. Hey, Chris. How are you doing today?

Chris Coyier: I'm doing darn fine here. It was supposed to dump snow on us last night and it didn't, so I'm kind of grateful for it because I can't get my snowblower started. Every year, there's a learning curve. Then you get it and you think, "Oh, I got it!" You know? Now I've solved my snowblower. I've had that thing four years.

Dave: Mm-hmm.

Chris: I take it out of storage and it doesn't start. I'm like, "Oh, yeah. That learning curve that I conquered the last three years has now disappeared, and now I don't know how to do it."

I don't know what the technological metaphor there is, but you step away from Web development for nine months and come back, you're probably going to be a little rusty.

Dave: Oh, man. The commands you typed yesterday don't work today.

Chris: Yeah.

Dave: I had that this week. I upgraded NPM update, this Prisma. I'm using Prisma or adapter. I went from version 2.30 to version 3.6 - all the new. I'm doing good. I fired it up. Works on my local machine. Beautiful. Beautiful.

Chris: Yeah.

Dave: Lovely. Just magnificent.

Chris: That is beautiful.

Dave: But then the deploy failed. And it didn't update. And I didn't know what was going on. And so, everything broke, [laughter] and I don't know why.

I then spun up my localhost. Guess what. The local host I was using five minutes before that was now also broke. I guess I had to restart my dev server, and I didn't do that appropriately - or whatever.

Anyway, it was all broke, and so I had to revert. Then, of course, I'm breaking stuff while I revert, but whatever. I reverted them all. [Laughter] Then I get it up, and guess what. It still didn't work because the back-end server uses a different version of Prisma. And so, I had to update that, and I think stuff is still broken. I don't know.

Chris: Yeah. That's just one dependency? Yeah.

Dave: I sneezed. [Laughter] Amazon had an outage. Now stuff doesn't work. I don't know. It's so weird.

Chris: Fragile.

Dave: Yeah.

[Laughter]

Dave: I’m trying to fix it. I'm working really hard, but it's just -- how do you do it?

Chris: Yeah. I don't know. Docker, I guess. Such things never change.

Dave: I don't know, though. Docker is just constantly like, "Okay. I'll do Docker," and then it's like--

Chris: It's just fragile.

00:02:51

Dave: But my issue, I think, with Docker is I don't feel confident. When I'm typing the commands, I find the commands on the Internet, and I paste them into the machine. But I don't know. I don't have the muscle memory or the confidence with Docker. I need to build it up, and it's coming, but it's just like, "Man, I'm not there yet." You know?

Chris: Yeah. That's true. I did read an article from the NYC Studio fellow. I was in between thoughts on it in that I think his point was that you don't have to fully understand Docker in which to benefit from it.

Dave: Okay.

Chris: Much like you don't have to understand every single piece of technology that you use in which to benefit from it. But it's true that you can't use it at all unless you know CLI stuff and can fuddle your way through a Docker file and stuff. If even that is complicated to you -- and I'm sure you know more than I do. I've never made a Docker file. I just benefit from other people's instructions.

When I said confidently, "Just use Docker," I'm not. [Laughter] I'm not telling you that from a position of deep understanding.

Dave: Well, you know. It all makes sense. But the weird thing about Docker is there is a Docker file and a Docker compose and then a Docker ignore, like don't do the stuff. That all makes sense.

[Laughter] The Docker file is -- I'm going to mess this up -- I think this is kind of like, "Get this server and then run these commands." That's how I understand it. Right?

Then the Docker compose is like, "Okay, when you get this server, put these things on it." Put a little Postgres on there - stuff like that. That's how you add the features to it - or services, you might call them. That's what they call them - exactly - services and volumes.

Anyway, it's a lot to get your head wrapped around. Then when you run NPM, you have to do it in the Docker (or you should) so that the Docker actually gets the updates.

00:05:14

Chris: I'm not sure. They can be really short-lived. A Lambda can be a Docker, meaning that one request can be Dockerized, meaning that there's a little bit of overhead for Docker, but you don't have to think of it as this thing that you spin up and then just leave sitting there running and use for hours or days.

Dave: Mm-hmm.

Chris: It can be running for 15 milliseconds.

Dave: On-demand.

Chris: Yeah.

Dave: Right. Right. Yeah. No. Yeah.

Chris: You know Elad Shecter. I had a blog post from him a couple of months ago on new CSS Reset. Of course, I think people look at how basically famous Eric Meyer got for his and then think, "Well, that was so long ago. Surely, Eric Meyer's reset is old and needs to be rethought." You know?

Dave: Mm-hmm. Right. Right.

Chris: Whatever. Maybe it does. Elad has his, and then I just saw the other day that Josh Comeau, Josh W.--

Dave: Oh, yeah.

Chris: MDX blog that I'm always jealous of, and he's got this big new CSS course. Whatever. Everybody loves Josh.

He's got a new CSS Reset as well, so I'm curious. Is something in the water with CSS Resets?

I find myself fascinated by them and want to look through them and see what the selectors are and see what they're doing to reset things - just out of general interest in CSS. But I don't come at it from a strong desire of, like, "Man, I can't wait to use that whole hog."

Dave: Mm-hmm.

Chris: Or replace what I normally start projects with, which is usually nothing. [Laughter] You know?

Dave: Mm-hmm.

Chris: I do the box-sizing thing, box-sizing, border-box on the star selector. I'll even go so far as the really fancy one where you set it on the pseudo-elements, too. Then you even inherit it. I'm not going to mouth blog that, but I'm sure some people know what I'm talking about. I like that one. That one is pretty important to me.

Although, less and less with Grid and Flexbox. I feel like you don't need border-box so much in the world because you're setting direct widths less, I feel like, and stuff. You're just using those for actional units or just flexing stuff. Then it doesn't kind of matter. Even that, I'm a little not so hot on.

Then the rest of it is kind of like, "I don't know. Just leave it alone." I just find myself just not caring about CSS Resets.

If I'm on a big project, that stuff is so in there already anyway and I cannot -- you're not going to take a ten-year-old project and put a new CSS Reset in it. Why would you sign yourself up for that pain?

Dave: Yeah.

Chris: It's just not -- you know?

Dave: Yeah, because for better or for worse, whether it's normalized or something, everything is kind of hanging off of that original reset.

Chris: Yeah. You replace it. There's going to be edge cases you're going to be sad. But anyway, it's just to say where I'm coming at with resets. Yeah?

00:08:12

Dave: Well, it was funny. I had this weird blockquote style. I was trying to fix it. I was like, "What is going on?" I'm in the reset, and I'm like, "It's getting reset."

Chris: Mm-hmm.

Dave: Then I look. The reset file was never being imported. [Laughter] So, I had a reset file that was never being used, and so I just was like, "Oh, we're not even using a reset? This is kind of novel. What a weird world." But you can also not use a reset. You know?

I think, too, browsers are getting a little bit better and a little bit smarter at their--

Chris: I've seen it hurt people, too. I think it was Discord (or something) the other day. Somebody was like, "Why on Earth is my search input - it doesn't have one of those little Xs in it to X out the search term."

Dave: Mm-hmm.

Chris: It was inexplicably weird, but in CodePen, they just had the normalized button checked, which tosses a copy of normalize on the file. You know? That used to be highly desirable. Maybe less so now, but hey, we still have the feature.

In normalize, which is in the bucket of CSS Resets, even though I realize there's a distinction there, it just nukes that. It goes to all odds to remove the X, which I hate. Why would you do that? The X is the only reason you would use a search input. It's great. [Laughter]

Dave: [Laughter]

Chris: It's a nice feature.

Dave: That's a nice feature. Yeah. What's weird, though, is they changed it and now it's all multicolor. It's blue. It has a bluish tinge to it. It's not just black. It's weird. Anyway--

Chris: Hmm.

Dave: I don't know if accent color fixes it or something. It's like this weird--

Chris: In Chrome, Safari, or Firefox?

Dave: In Chrome. I'm in Chrome. Yeah, it's this weird glyph. I'm like, "Dude, can I fix that or change that?"

Chris: [Laughter]

Dave: I would like to.

00:09:59

Chris: Yeah, so maybe you would want to remove it.

Okay. Yeah, so I just feel like their days of helpfulness are a little limited. Although, that's probably not true. A big beefy project, you should probably chuck it on there. Sure, you get the nice foundation across browsers, and I get it. That's all good.

In Elad's, the big, interesting one was that he leaned on all unset, all:unset, all the CSS property on almost everything, but not everything.

In this interview I did with him, he explains why. There are a couple of things that you kind of want some of the default properties on, so he scopes it, and then rocks the all:unset and then goes display revert, which is interesting, too. All will nuke pretty much everything off of everything except you don't really want that on the display property, so the display he kicks back to normal. You'd think there'd be other properties that you'd want to revert, but it turns out not really, which makes this actually kind of a clever reset, I think.

Then he has some opinionated stuff in there. He goes, image max-width 100%. Yes, actually, yes, that is in every one of my style sheets, but that's in opinionated territory now. It's like that's not a problem across browsers or anything. That's just kind of like now you're venturing into -- it's not just a reset. It's like my little opinionated selection of things that I think should be on all other projects. If that's the case, I've got a whole bunch of them. [Laughter] They're little typography stuff I like to do. I can't even remember the whole list, but I bet I have 20 little things I like to do across projects that are pretty consistent.

To put it in a reset that is intended for the whole world to use, I find that a difficult choice. Do you want all 20 of my opinions or are we scoping this thing to just things that are problematic across browsers or whatever? That's why I thought the reset was interesting because it was -- like Eric Meyer's -- intentionally trying to rip off all styling - forcefully.

Dave: Mm-hmm.

Chris: Normalize took that other approach, like, "No, it does not belong in the style sheet unless there is a difference across browsers. Then we're going to normalize that difference." But if it's just an opinion, it doesn't belong in the style sheet.

Dave: Mm-hmm. Mm-hmm.

00:12:18

Chris: Which I thought was clever. Anyway, then onto Josh's, and Josh's is interesting, too. It digs into the box-sizing thing but doesn't use the inheritance model - notably.

Dave: Mm-hmm.

Chris: Then it has some opinions about typography. It goes for WebKit font smoothing and stuff. That's in that kind of opinionated territory of, "Do you like that?" Do you literally, for sure want that on every single project? I don't, but you know. Fair enough.

Dave: Yeah. That one seems -- I'm surprised we still need that, but I guess we do.

Chris: Yeah. I have seen it, and certain typography situations really do make it better and sometimes worse. That's why il don't globally do it.

Dave: Mm-hmm.

Chris: Then it rocks the overflow wrap on typography elements, but just some.

Dave: Mm-hmm.

Chris: Just headers and P's, but not LIs and not DDs and not--

Dave: I would put it on LIs and DDs, for sure. LIs, DDT, yeah.

Chris: Yeah, and there are even more like blockquote and pre-

Dave: Mm-hmm.

Chris: Well, probably not pre-

Dave: Anywhere somebody could accidentally paste a URL, basically. Right?

Chris: Right. In that case, why not star, I guess? I don't know.

00:13:26

Dave: We had a situation where somebody where they typed -- a client was like, "It's 0.000000001%," trying to drive a point that it's not even -- or maybe they were -- it might have been like it was a billion percent or something, so they just typed 100000000%.

Chris: Busted out.

Dave: It was causing this huge overflow issue.

Chris: Yep. Yep.

Dave: I was just like, "Why did they type this?" But they did, and so anywhere a user can type content, you kind of need this because you don't know. You don't know until it's too late.

Chris: Right. Right. Right. If you just do overflow hidden, some usually fix it, too. Although not always because it depends on if the thing is a Flexbox situation. It might turn its inherit sizes too wide and break layout that way, too. So, overflow isn't going to always help you.

But overflow also is data loss, then. It can hide content in a way that you don't want it to, so tricky. Yeah, overflow wrap is good. It's also there are more properties than just overflow wrap.

Dave: Mm-hmm.

Chris: There are a couple of other ones. You might want to look at the browser support of that and figure it out.

It's not to dig into Josh's. It's actually pretty clever. It's got some cool stuff in it, but all these things are so opinionated.

00:14:47

Dave: Well, here's an opinion. The second rule he has is star margin zero.

Chris: Yeah.

Dave: Nuking margin.

Chris: Baller.

Dave: What are your thoughts? What do you think?

Chris: I used to do that all the time. In fact, that's where the logo for CSS-Tricks came from. That star, I used to start all my demos and projects with star, just like Josh's here, margin zero and padding zero. I did padding because lists often have padding instead of margin to kick them in.

Dave: Mm-hmm.

Chris: So, I kicked the padding, too. It was just kind of nuclear. You know? I don't hate it - you know.

Dave: That's intense. I actually kind of am coming around to it. You know what I don't like? I don't like that paragraphs and headings have all this margin on top by default.

Chris: On top, I hate the top margin thing. Ew. Yeah.

Dave: Like, "What up, dude?!" [Laughter]

Chris: You make a card and you throw an H2 in it and it's pushed down weird from the top because of the weird top margin on it. Now, I'm not anti-top margin all the time forever.

Dave: Sure. Sure. Sure.

Chris: I just think it's weird for a default, maybe.

Dave: Yeah. Why do we do top? Why? That was a bold choice.

Chris: Yeah, and sometimes you don't really notice because of margin collapsing. If there's a header after a P, they kind of suck into each other as well. But I bet the top margin on the header is a little bit more than the bottom margin on a P.

Notice we're saying old words still. I should almost be saying the block margin.

Dave: The block margin.

Chris: The block end margin and the block start margin.

Dave: That's the thing. When the two blocks kiss - or whatever. I don't know. My age-old problem, and I've probably said it a thousand times on this show, is you have the heading. Then you have the paragraph. You're like, "Yes. Perfect. I did it." Then somebody sneaks along.

The next issue -- once you commit that code, somebody posts -- we also need a subtitle next to the heading, and they need to touch. You know?

Chris: Yup.

Dave: Now you have to put that there.

Chris: Yup.

Dave: You're just like, "Turn some burgers!" [Laughter]

Chris: Classic. Yeah.

Dave: Yeah, so you can't fricken' win. Everyone changes their mind.

Chris: No, and I'm not even -- as much as I'm a fan of using CSS features and just rock-n-roll, I almost see why something like Tailwind has a benefit there in that the only margin it has is the margin you gave it from the class. Rather than being like, "Oh, all headers have a bottom margin except when it's H1+.subtitle and then it's different, or I use negative margin to suck it back up," or those kind of conditional things. It's a little bit of misdirection that I don't like. I'm not necessarily advocating utility styles because generally I actually don't like them, but headers are especially annoying in that way. Sometimes they have subtitles and sometimes they don't and sometimes they're in a card and sometimes they don't and sometimes--

Dave: Yeah. Well--

Chris: Sometimes - sometimes - sometimes.

00:17:45

[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by Automattic. I'm so grateful to have Automattic as a sponsor of this show and other things that I've worked on over the years because it's a company that I believe in that writes good software and really helps the world do what they do.

Automattic is the maker of WordPress.com. Of course, the host for your WordPress site. It takes just a second to spin up a new website over there, and I don't think you'll regret it. A great place to spin up a WordPress site and scale it for a very long time, if not forever, right on WordPress.com, especially with their somewhat recently launched ability to add plugins to those sites and get FTP access and get MySQL access to those sites, even though it's hosted right on the WordPress.com cloud. So cool.

If you're self-hosting WordPress, of course, they make Jetpack, which brings all kinds of amazing abilities to your self-hosted WordPress site like a crazy good search tool that offloads search to the cloud, backup tools, and so much more. Security stuff, Jetpack is just great. Use it on all sites.

If you're going to sell something from a website, whether it's WordPress.com or your self-hosted WordPress site, of course, WooCommerce is the way to go there. Super powerful e-commerce software. I use it myself right on CSS-Tricks to sell physical goods as well as digital goods and digital access, too. That all comes from the WooCommerce universe.

Just doing great over there. By all accounts, a great year for them, and we're so grateful for the sponsorship. High-five to another year with Automattic.

[Banjo music stops]

00:19:32

Dave: Okay, so you did this thing on CSS-Tricks -- this is probably a pretty good segue -- about, "What's one thing you can do to your website?" It's kind of an advent sort of thing.

Chris: To make it better. Yes.

Dave: A bunch of people wrote in, "What's one thing you can do to your website to make it better?" There are lots of really good posts.

I've been thinking of mine. Can I mouth blog mine?

Chris: Sure. One thing you can do to make your website better. Dave Rupert, go.

Dave: Write your website in a different way. I think the idea here is -- and maybe it's not your website. Maybe it's some other project. Build it with a different set of tools than you like.

If you hate Tailwind, build it with Tailwind. If you only use Tailwind, build it without Tailwind. I think there needs to be a lot more--

If you hate JavaScript frameworks, build it with a JavaScript framework. If you use only JavaScript frameworks, build it with no frameworks, only vanilla.

I think our world, our development world, or even your website could be better if you explore the alternative, like the opposite of you. There are no huge consequences other than, "Oh, maybe this is a bad website," or something. [Laughter]

I think what would come out of it is more nuanced opinions. I feel like a lot of these blog posts I'm reading (specifically this week) are just like, "That's bad. You're a dummy." I'm just like, "Could we just have a bit more nuance to this?"

Like you said, I don't like utility classes. Rather than saying, "I hate Tailwind," just be like, "I have not been successful with utility classes. When I tried it on this project," blah-blah-blah blah, "I ran into these problems or felt this need." That's a lot better of a conversation than, "Tailwind is stupid." You know?

Chris: Yeah. In a sense, because I think, sometimes, stakeholders and your boss and stuff might expect a little bit more, but you can't roll into a professional meeting and just be like, "Hate it! Bye!" You'll be like, "That's not useful for this meeting," and it's almost like a cause for correction to be like, "Are you serious about working here? Because if you are, you might need to bring a little bit more to the meeting."

Dave: Yeah. We need a little bit more nuance. Your website is a really good place to explore nuance, and you know your website. Maybe it's like cut a branch. I don't know. Just explore writing your own website or some website that you maintain in a totally opposite than you normally do way and just see what that's like. That would be my thing.

Chris: Nice.

Dave: Anyway--

Chris: That's a really nice gesture. If you hate trackers, build a website that's just full of tracking. [Laughter]

Dave: Laura Kalbag.

[Laughter]

Dave: Jeremy Keith.

Chris: Yeah.

Dave: Maybe you guys just need to -- well--

Chris: Have you thought about adding more analytics to your site?

00:22:44

Dave: With that situation, it's probably like build an e-commerce site with somebody who depends on making money through resales, or whatever. How do you convince somebody, "Don't make money on re-tracking, reselling, remarketing, or whatever"? You have to work with somebody who has the opposite opinion.

Chris: Exactly. Then you'll have the nuance to the party. Yeah.

There was a lot of posts along this -- Laura Kalbag's was, "Remove trackers."

Dave: Mm-hmm.

Chris: That was all kinds of great nuance in that. The reason, she started off talking about, she was playing with a theme for a blog. The theme just assumed you'd have a bunch of trackers, tried to help you with those trackers, and just said, "Oh, just put in your API key over here and we'll handle the rest," kind of thing. "Obviously, you're going to want this track, so we're going to make it easier for you to do."

Dave: Yeah.

Chris: Kind of funny.

Dave: No, and that's kind of the sad state we're in. A lot of things just assume it's going to go the bad way.

00:23:58

[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by Backlight, that's backlight.dev. If you do design systems work -- you're hired to do it at a company or your agency was hired to build a design system -- you have to check this out. It's a very impressive piece of technology, totally custom-built for building, working on, deploying, shipping design systems.

Go to their studio and spin up one of the starters. The starters can be like React and Chakra, or Lit and Web Components and Shoelace, or Tailwind and Svelte. It's all kinds. It doesn't really care about your technology. It's just trying to help you build the design system.

You drop into the studio. It's a three-column layout. On the left, you see all of your components, your design tokens, your layouts, and all that. Open them up and see the source that is building those things.

It's a live code editor, so change the code. Work on your design system. Save it. As you're saving it, you can connect it to a repo. It's pushing changes to the design system to branches of that repo. You can change branches, play around, and do what you need to do.

Get it right. Get approval and then ship the thing. You can even send it all the way to NPM as a tagged version. This is an end-to-end tool for design systems.

The layout is so cool. You're looking at the source, but you're also looking at the storybook stories. You're looking at the documentation, the design examples. You're linking it up to Figma. You're seeing them rendered in the browser. This thing has got it all for design systems.

Thanks for the support, Backlight. It's such a cool tool. Check it out.

[Banjo music stops]

00:25:43

Chris: I did publishing. There's some irony to it because Google Analytics is on CSS-Tricks, right? Which is a tracker, you know.

Dave: Mm-hmm.

Chris: It's not like I self-host the JavaScript or use server-side analytics. It's literally third-party JavaScript. Here I am publishing Jeremy Keith's article that's just like, "Literally, don't do it. Treat it like a third-party cookie. Just straight up block it. No third-party JavaScript."

I also run a company that, if you want to put a CodePen embed on your site, we encourage you to put a CodePen script on your site, which is third-party JavaScript. So, I can't. My opinion is different, [laughter] than Jeremy's.

Dave: Well, and I think the core is when people talk about third party, they're not like, "The cool iFrame from CodePen, a site you trust," or maybe they are. Maybe they totally are.

Chris: I think Jeremy would not distinguish. I think he would say even that, don't do it.

Dave: He's a theoretical purist.

[Laughter]

Chris: He walks the walk, I'll say.

Dave: He walks the walk. Yeah, but I think, generally, people are talking about the Facebook pixels, which follow me around the Internet and try to sell me underwear on CNN, or whatever.

Chris: Right.

Dave: I think those things are, you know, dirty. They're gross. They're hideous. And we should get rid of them, but also, too, telling this audience of Web developers who probably care about performance and are watching their Lighthouse scores just tank due to third-party stuff.

Chris: Right.

Dave: We're maybe not the audience. I don't know.

Chris: No, I definitely think there's lots of nuance there. I was considering it, like, what could I do to get down to zero third-party JavaScript? It would actually be a lot. I'm not saying there are a lot of trackers, but there's little stuff like Cloudflare. Because it runs through their DNS, I think it slips in a little JavaScript on mobile that does some special mobile stuff. I'd have to watch that.

Ads, couldn't run them because literally some of them come from BuySellAds. Now, BuySellAds is so trusted as a third-party script that even if you run AdBlock+, the number one adblocker in use on the entire Internet, you still see BuySellAds ads because they are so trusted in that market. Isn't that crazy? That's a big distinguish.

Dave: Yeah. Where does that fit in the argument? I don't hear that nuance. Everyone said these ads are okay enough. Do we not just say yes or are you blocking ads, the BuySellAds on my site, and on CSS-Tricks as well? You know? The nuance gets me. Anyway, I'm on team "let's not be scummy," but how do you know?

00:28:39

Chris: In some ways, it's a moral argument, like if I could argue on Jeremy's side. He says that people did not agree to it. They didn't say, "It's okay to track that I looked at this ad."

But the "I" in that sentence is very important to me because I don't know who looked at that ad. I have no idea, but I do have aggregate information. I do know how many thousand people looked at the ad. That is actually vital to our business model.

Dave: Mm-hmm.

Chris: I actually disagree with knowing if individual people looked at it.

Dave: Yes.

Chris: Or that the data is then used to be fingerprinting data to make a complete profile or something. That I would draw the line at, too. I don't think that's happening. I could be wrong.

Whatever. Google gives away Google Analytics, and that does seem a little suspicious that that data is not used in some kind of global fingerprinting kind of way.

Dave: Yeah. We'll count your page views. Ah... Yeah. [Laughter]

Chris: But it has to be. I don't know, in Google Analytics, anything about any individual user. I don't know. If something nefarious happens beyond that -- and nor do they allow that. It's literally against the terms of service to track identifiable information in Google. That doesn't mean it can't be used in a fingerprinting kind of way, but it does mean that I cannot just look up and see who did what. I have no idea, nor do I want to know - line in the sand.

But then I go into MailChimp, and I need data for our newsletters, like how many people opened it and stuff. I go poking around in the analytics in there. It literally tells me exactly who opened it and who clicked on and what they clicked on (by name if it's in there).

Dave: Yeah.

Chris: I was like, "Wow! Whoops!" I didn't even know that was the default, that it was that invasive. So, I turn it all off. Right, Dave? Just flip it all off.

Dave: Perfect. Good. Good. Good.

Chris: Great. Now it's off. Guess what the first thing that happens is the next week? People that I work with, sponsors, are like, "What's the open rate on this one? I can't see who is clicking on stuff," because you give certain people access to reports or whatever. I'm talking about BuySellAds.

Dave: Yeah. Yeah.

Chris: I'm not implicating them in badness or whatever, but there's data that they put in their reports, which are shared with the people. It's not that Dave clicked on what. It's just kind of like how many -- what was the open rate? Literally, that's the metric that mattered.

Dave: We're going to send out 10,000 of these, 9,000 get opened, and 2,000 get clicks - or something.

Chris: Right.

Dave: That's what they want to know.

Chris: Now we only know how many they got sent to, not the open rate and not the click rate because I turned all that stuff off, which also turns off any personal identifiable click data - or whatever. But immediately, I get flack for it. Not like deep flack because I just said, "Hey. Sorry. You'll never have that data again. I'm going to tell you that it goes out, the CSS-Tricks letter goes out to like 98,000 people - or something. I will never know who clicked what. I will never know even what percentage of people open it. I'll have no idea what people click on, unless we put a click tracker on the individual link."

Dave: Mm-hmm.

Chris: I do allow that as well because it's not personally identifiable. It's just like it got clicked and it increments a number from 37 to 38 - you know?

Dave: Mm-hmm.

Chris: Nuance - ugh - a lot of it but publishing and reading these articles did get me to change some settings and be a little less tracky-tracky. I'd call it a nudge in that direction.

Dave: Well, and I think it's good. Again, I'm not in disagreement. I think I'm in agreement. Then I smash with reality or client requests or whatever. I'm like, ugh, how do you resolve this? You know? It's tough.

Chris: Yeah.

00:32:40

Dave: There are some other good ones, non-privacy related. [Laughter] I liked Eric Bailey's "Test your product on a crappy laptop." I thought that was so good. It's just like, "Hey--"

Chris: I like the title. It really gets to the point. If you didn't even read the article, you got the point. [Laughter]

Dave: Yeah. He introduces this idea of a craptop, which is just a crappy laptop. The craptop has an old battery, or like my son's Chromebook from school that's already five years old and he's supposed to have for ten years.

These craptops are underpowered, not very good, and the fans are humming at, like, 70,000 RPMs. [Laughter] Try your website on that. How does it feel? Is it good? If it's okay, if you feel like it's okay and you're not just sucked into your own optimism bias, that's fine.

I thought it was kind of cool. I don't know. His whole thing was like, "There are 260 workdays a year. That's 260 chances for somebody to be using the craptop for a day. You just pass the craptop around. The craptop has some login credentials. You get to use that today." I thought that was pretty--

Chris: It also feels a little more likely that somebody is going to take him up on that offer and do it. I think it's more prevalent that somebody says, "Well, test on an old phone," which is also doable.

Dave: Mm-hmm.

Chris: But you get less data from it, too, because you don't get the dev tools experience in there. You're not running Lighthouse. It's just to get a feel for it, kind of vibe.

Dave: Mm-hmm.

Chris: Yeah. You know. Whatever. I know there's tooling around this stuff, too. Then I think there was a Discord conversation lately about it that was like, "Sometimes I'm on the opposite end of the spectrum where I have a very nice MacBook. It's not a bad laptop. It's a fine laptop. But I live way out in the country and our Internet often just sucks."

Dave: Mm-hmm. Yeah.

Chris: That can be the possible, too. What does a craptop with killer Internet versus a very nice laptop with kind of bad Internet? Aren't they both kind of interesting scenarios?

Dave: Well, and then there's this whole thing. I don't think he got into it, but there were some posts. It was like, "On these new, brand new MacBook Pro M1X Max," you know, "bitchin' CPUs."

Chris: Yeah.

Dave: "Best CPUs, most magical CPUs we've ever produced here at Apple Cupertino." Well, if you run them on battery, which why would you run a laptop on battery? I don't know. But it'll switch into low power mode, which is like your phone's low power mode.

Chris: Mm-hmm.

Dave: Which basically cuts your CPU in half so that you could get twice the battery.

Chris: Right.

Dave: It's just kind of like, "Oh, surprise! The default of these new devices, the supercomputer that I have on my desk, is to go into craptop mode when it's unplugged." You know?

00:35:38

Chris: Yeah. Interesting. I read an article. I think it was John James Jacoby--

Dave: John Jacob Jingleheimer--

Chris: Oh, I'm sure he's never heard that before. It was demonstratable in Safari on a Mac. You pull that power cord, and it basically just says, "Oh, I'm going to run all your request animation frames at 30 FPS instead of 60."

Dave: 30 FPS!

Chris: Just instantly on battery. It's like a feature of Safari. It's saying, "I'm going to conserve power in this way."

Dave: Isn't that wild? Your smooth butter animations that you were working so hard on, guess what--

Chris: Even if you're at 100% battery.

Dave: Then Chrome, everyone on the Chrome dev rel team is just like, "30 FPS? You loser." [Laughter]

Chris: Yeah. Oh, right.

Dave: You can't go--

Chris: Well, it's weird that it wasn't -- it wasn't like -- you don't know that it did that. It's not communicated particularly well.

Dave: Right. Right. Maybe there's an icon with a rabbit that has a tear in his eyeball or whatever, a turtle. I don't know.

Chris: [Laughter]

Dave: [Laughter] There's probably some icon trying to communicate it's not as fast, guy.

Chris: Oh, my god.

Dave: But who knows what it means. You know?

Chris: Yeah.

Dave: That was my favorite. On the lawnmower we grew up with, there was a turtle and rabbit. [Laughter] Did you have that one?

Chris: Oh, yeah. Hell, yeah. Yeah. It did the job, did it not? Nobody knows.

Dave: Turtle and rabbit. I don't know.

Chris: That was one of the first things Ruby learned: turtle is slow.

Dave: Really? And rabbit is fast?

Chris: Yeah. She just knows that intuitively somehow. Snails also are slow, which was emphasized by we watched some movie called Turbo - or something - with the fast snail.

Dave: Yeah. Yeah.

Chris: Yeah.

Dave: With [indiscernible] Yeah.

00:37:29

Chris: We're not going to go too much longer here, but I wanted to mention that you thought, "Oh, look! I built this website and the first thing a client types into it is 00000000000..." Like, "Oh, come on!" You know? Breaking my crap day one.

There's an Ahmad Shahid article (who is just an MVP CSS blogger this year, for sure - we're hitting all the favs here) published recently called "Defensive CSS," which I think is just great.

Dave: Ooh.

Chris: He does these "how to think about CSS" posts that I'm just all envy all the time because that's what I want to write about CSS. This is what it feels like to work on CSS as a developer, but it's hard to articulate.

Dave: Mm-hmm.

Chris: It's great. It's easy to focus on one thing, like, "Oh, you should use," whatever that line is "overflow break wrap." [Laughter] You can never remember them. They're so hard to remember.

Dave: Yeah. Yeah. Yeah.

Chris: But that's one tiny example of essentially being defensive with your CSS, right? Because a client is going to type the thing and, if you don't do it, it can literally break the layout of the entire website. It could cause your sidebar to drop or any kind of number of weird things. That's one thing.

But how do you think about all those things? How do you think about working in that way where it gets there? And so, it's nice to have a bunch of strategies. Then eventually, kind of flip your brain so that you kind of always work in that way. I think that's the end goal if you're a front-end developer but focused on CSS. That defensive CSS is kind of like your day-to-day strategy.

You're always thinking that way, "What could go wrong with this button? What could go wrong with this card? What could go wrong with this avatar? What could go wrong if there's no content or too much content?" All the possible things that could go wrong.

Then it turns out there are about two dozen strategies for all that stuff. It's a pretty good post in that way.

Dave: That's cool. I mean you kind of run the risk of YAGNI (you ain't going to need it).

Chris: [Laughter]

Dave: But then again, if you've done it a few times and you just keep hitting these weird roadblocks, it's worth doing defensive.

00:39:48

Chris: Yeah. Yeah. Yeah. It reminds me of yet another Jeremy Keith thing. He published an article the other day. It was ostensibly about logical properties and how the more you use something like that, your brain flips.

Dave: Mm-hmm.

Chris: Let's say you were learning Spanish or whatever. You struggle. You struggle. You finally get it. Then you're fluent in it (to some degree). Then you start thinking in it or maybe dreaming in it. You know?

Dave: Mm-hmm.

Chris: That flip. It can be like that with syntax-type things, too. You stop thinking in margin bottom and you start thinking in block end - or whatever.

Dave: Yeah.

Chris: That can switch. Then he was like, "Well, it's a little unfortunate at the moment because if your brain flips that way, there are all kinds of properties that aren't done yet." Not all kinds, but some, like Overflow X. There is no Chrome or Safari version of that in a logical property.

Dave: Oh--

Chris: It should be overflow block.

Dave: What are the situations where, "Oops. Surprise," it doesn't work?

Chris: Yeah. One of them was almost going to be container queries because a container query says @container min-width 300. It's not width. It's inline size. If you're trying to really switch all the way and flip your brain and think in the new CSS, it's not width anymore. It's inline size.

Uh, but I think he was just wrong. I looked at the spec now, and the container queries support inline size, so I think it's not a problem but maybe was a problem for a minute, and they fixed it at the last mile. But it also supports width, too. So, I was a little, like, "I don't know. Maybe we should just switch if we're going to switch." You know?

Dave: Yeah. Yeah.

Chris: Why support both?

Dave: You know I think it's going to get weird here. I'll save my predictions for the next episode, but I think it's going to get weird here in a bit with what works and what doesn't. This is just a good example. Some of the logical properties are out - or whatever - and some aren't. But then I'm trying to think of other situations.

You and I, we stay on top of CSS all the time. But, man, sometimes I don't know when a CSS is out yet, or something like that. I've heard of it, and I know about it, but I actually don't know if it's out or if I can use it.

Chris: Mm-hmm. It is going to get weird. I thought that with -- yeah, I'll say predictions next time, too. But it feels like because there's so much CSS syntactical innovation changing -- cascade layers, container queries, all that type of stuff -- it's starting to be like those things are pretty hard to express in utility classes that maybe there'll be a little bit of a decline in them just because it's like, "My God!" You know?

Dave: Well, and you know somebody made the good point. This was in one of the chat rooms. I don't know if it was the Discord or not.

CSS is so good right now. [Laughter] It's a lot easier to learn. The tools are great. We have actual layout tools. Most stuff is very intelligent and appropriately named.

I think there's a lot of -- I don't know. We're in a good situation with CSS, and it's only going to get better, if not weird for a bit, but it'll get better here as we go.

Chris: Yep. All right, man.

Dave: All right.

Chris: Thanks for the chat. [Laughter]

Dave: Okey-dokey! See you next time. Thanks, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show. Follow us on Twitter, @ShopTalkShow, for tons of tweets a month. And join the Discord over at patreon.com/shoptalkshow. We'd love to have you. Chris, do you have anything else you'd like to say?

Chris: Yeah, it only costs about as much money as you'll get in your stocking because this is the last ShopTalk Show of the year.

Dave: Happy New Year to you!

Chris: Alt lang CSS--

Dave: [Laughter]

Chris: --sign wave -- I don't know what I'm talking about. Bye-bye. ShopTalkShow.com.