572: Text Sqwunch Property, Figma Developer Mode, Stripe Elements
Dave reports back from the Figma Conference, how to build a better developer to designer bridge, do clients really want to update their website, using Stripe in 2023, permissions and sharing, and are you feeling overwhelmed by CSS in 2023?
Guests
Chris Coyier and Dave Rupert
Time Jump Links
- 00:22 Dave goes to Figma Conference
- 03:59 Figma Developer mode
- 09:13 Building a better developer - designer bridge
- 16:04 Front end testing with Storybook
- 21:15 Sponsor: Notion
- 22:58 Grape.js
- 25:32 Do you really want to be able to update your own website?
- 28:01 Using Stripe Elements
- 37:06 Have a share link to invite coworkers as a path to revenue
- 42:20 Permissions and onboarding
- 48:35 Header bar with an input list
- 57:58 Do we need more CSS?
Links
- Config 2023 | Figma’s Annual Conference
- Figma
- Visual Studio Code Toolkit | Figma Community
- Luro | Expand your design system to your entire product development process
- Storybook: Frontend workshop for UI development
- Makeswift — the visual builder for Next.js
- Webflow: Create a custom website | No-code website builder
- How to test UIs with Storybook
- GrapesJS
- Stripe Checkout | Stripe Documentation
- Stripe Elements: Embeddable UI components to build pixel perfect payments experiences
- Appcues | Product adoption made easy
- Mindf*ck: Cambridge Analytica and the Plot to Break America a book by Christopher Wylie
- SkwunchText Experiment: inject spans and use :has() to count chars
- Watch Out for Layout Shifts with ‘ch’ Units – Cloud Four
Transcript
[Banjo music]
MANTRA: Just Build Websites!
Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show. I'm Dave--in the hotel--Rupert. With me is Chris--in the office--Coyier. Hey, Chris. How are you doing today?
Chris Coyier: Doing very good. I'm admiring your dedication to this show. You know that we never miss a show around here on ShopTalk Show.
Dave: Never.
Chris: Although, I say that-- [Laughter]
Dave: Miss. Shows.
Chris: [Laughter]
Dave: Until July 2023, when we take them all off.
[Laughter]
Chris: No. We don't. Yeah, we might. We'll give you a heads-up if we do. If you're a long-time listener. You know, Monday morning, this show is waiting for you.
Dave: Chris did his job. It's out.
Chris: Part of that reason is because Dave put a microphone in his fricken' luggage and hauled his butt to San Francisco this week. Dave, this is probably going to be... It might be a week or maybe two, even, after this conference is over.
But Figma, the famous design software, widely beloved, is throwing a conference. I don't know if it's the first of its kind, but it feels like a lot of hoopla over this one.
Dave: Yeah. They've done a few Figma Configs before. And Figma does smaller events throughout the year. But this is kind of like their big one.
Chris: Yeah.
Dave: I'd have to look at the timeline, but this might be the first one after the whole Adobe sort of stuff, so I don't know.
Chris: Yeah, which is still unresolved, isn't it?
Dave: Yeah. I'm not going to speak, but I think that's in limbo - as far as I know.
Chris: I wonder if they'll address it at the conference. That seems juicy. It seems like something I would avoid. We're here to talk about this software, not drama.
Dave: Yeah. If it was resolved, Chris Enns, here you go. If the merger happened, we say, "And the merger happened, and that's great."
Chris: [Laughter]
Dave: If it's not resolved, we say, "And we don't know yet what's going on." So--
Chris: Yeah. Good luck. Or just air all three of those. That's fine.
Dave: Little if statement in the middle of the podcast, right?
[Laughter]
Dave: Just a little if statement, conditional audio (brought to you by Lemon Productions).
Chris: Well, what's funny is there's that, but it's like, this is a big conference. I wouldn't be surprised if there were other interesting news. Perhaps even more interesting because who owns this piece of software, I have to admit, isn't the most interesting thing in the world to me. I'm a little bit nerdier than that, and I just want to know what kind of cool features are coming or if they're entering some new hemisphere of stuff they do for me or something. Is it for developers?
Dave: That's why I'm invited. That's why they brought me out for a developer perspective because I'd heard this stat and learned this stat, like, 33% (or something) of people who use Figma are developers.
Chris: A third. Yeah.
Dave: That checks out at my company. [Laughter]
Chris: Right.
Dave: But that's actually pretty surprising. So, when you hop into Figma (as a developer), what's your experience, Chris? Is it...?
Chris: I don't...
Dave: "Man, this is a lot," right? I guess your design brain probably kicks in, huh?
Chris: Yeah. I'm unclassifiable as a human being, unfortunately, because as much as I write code and feel like a developer, I just play one on TV. I'm mostly a designer. I'm not looking for... I'm not like, "Oh, my God! I need the hex code for the button! I need help! Hopefully, there's a developer drawer that helps me find the hex code!"
It's like, no, I'm pretty comfortable getting my own hex code. Thank you. I probably invented the system that delivered that hex code.
Dave: I've been working with Figma for the last year-ish-plus. A year real seriously. Even though I use it and am building on the API and stuff like that, I find it pretty opaque to use, like to get the hex or the token or whatever. You have to go up to the top little bar and click the right thing and then get the thing.
Chris: Mm-hmm.
Dave: What they do now, it's going to be like a developer mode. It's basically like you click a toggle.
Chris: Oh...
Dave: And you get only the information you care about. You're not even in edit mode, per se. Designers (or whoever) can mark things as ready for development.
Chris: Really?! All right. Now I feel bad about what I was saying about, like, "Oh, my God. Give me a developer drawer." But if I was looking at a document, and that's all I cared about at the moment, I'm sure I would toggle that on.
Dave: Yeah, and then it's kind of like when you're clicking around. It's going to try to get you to the component, like reveal the component you're clicking on and view all that stuff, like the basic styles and stuff like that.
Chris: Okay.
Dave: But it gets cooler because there are these things you can do like plugins. Figma has a whole plugin deal.
Chris: Right. Yeah. I'm impressed by them. Yeah. I want to apply some, like, Paravel's famous grungy look.
Dave: Yeah. Yeah.
Chris: Not on everything, but you guys like it. There's a grunge plugin that's like, "Oh, yeah? How much grunge?" You slide the slider. Then it does all the magical, behind-the-scenes stuff to make grunge happen in Figma, which is otherwise not a built-in feature of Figma.
Dave: You can add plugins now, and there's even, in this dev mode thing, kind of like this link out to Jira task to code the component or refactor it or whatever.
Chris: Uh-huh.
Dave: You get a little bit of a paper trail in that component, so that's one cool thing. Where it gets super cool is you have this dev mode, right? It's just the component you care about, the component you're operating on. You can mark the view as ready for develop, so you don't have to surf through your designer's file, which is terrible. [Laughter]
I'm just going to throw my coworkers under the bus. They name their... It's like sheets or whatever they call it.
Chris: Yeah, layer one.
Dave: It's like layer one, V2, V3, V5 final. You know? They're doing the Photoshop thing in the sidebar, just not in the files, but it's in the sidebar 100%. There's like July 10th, July 3rd, July 2nd. You know?
Chris: Ooh...
Dave: Anyway. You can just mark one as ready for develop, like this is the one. This is the canonical one we're all looking at.
Chris: Okay.
Dave: That's pretty cool. But what gets even cooler is there's now a VS Code extension.
Chris: Whoa!
Dave: If you are operating in your code editor, you never have to go to Figma. You just open the VS Code extension and you have all the information you need, all the Jira tickets. If you set all this up, the storybooks, the component, the Figma stuff, and so all that stuff is in your code editor. That's pretty cool for me from a "cutting out the middleman" perspective. [Laughter]
I can just go find the component. Just tell me where it is. It's sort of the thing I'm looking for as a developer, and so that's, I think, what's pretty cool about their solution.
Chris: Yeah. I like it. I wish I saw the demo. Not that you didn't do an excellent job showing me. I just can't. Now I'm like, "Oh, what does the sidebar look like? What does the ... look like? What does...?"
Dave: A hint of green, which is, of course, a little code bracket, of course. But it's more simplified, and it's more like a drill-down to the component that you want, and it'll suggest some styles. But you can also throw in another plugin like Anima, or something like that, that does very sophisticated code translating.
Jake Alba has this, like, basically spit out your component as a Web component, React component.
Chris: No...
Dave: Yeah. Svelte. He's a polymathy guy. [Laughter]
Chris: Yeah.
Dave: But is that going to work in production? Dave Rupert probably says no.
Chris: Well, it's a kicker-offer, though.
Dave: Kicker-offer. I think it's kind of like people at least opening the door. And if your component wants to build that pipeline, you could - theoretically. You could build the Figma to website pipeline.
Chris: Yeah.
Dave: I just think reality kind of hits and there are a lot of... You think of a query layer or something, a list blog posts or something. You don't want to write your query layer and your biz logic and all that weird stuff you do, date formatting. You don't want to really do that in Figma, per se. That's my take. But who knows? People might. Maybe this is the beginning of something or at least tying together the code and design intent. I think that's a big deal.
Chris: Yeah. Huh.
Dave: Like, "Here's what we designed," and then [fart] here's what it looks like in code. [Laughter] You know?
Chris: Right. That's always been such a hard thing to pull off. Have you seen it? I feel like Framer dipped their toes for a minute. Maybe they still do to some degree. I don't know.
It's a design tool. I want all the affordances of a design tool. Yet, I want automatic code production from it.
Of the tools that do okay at that, in my mind it's like a one-way street. It's like, "Okay. Yeah. Great. This looks and acts perfect from a design perspective. Good job." But now I need to put my GraphQL in there and my muse states and my fancies because it's a thing that needs to live in a Web app that does actual stuff.
Dave: Right. Yeah, yeah.
Chris: Now, as soon as that stuff is in there, you're not going back. It doesn't remain editable (as far as I can tell).
Dave: Yeah. Yeah, I feel like there needs... We need a better designer-developer bridge, if that makes sense, or people build their own is probably the best way to say it. It has varying degrees of success. [Laughter]
You've probably heard horror stories. We had one question last week. It was like, "My designer is kind of awful," and we had to be like, "Maybe get another job," I think was our answer.
[laughter]
Chris: Yeah!
Dave: Or talk to your boss.
Chris: Oh, I remember that. Yeah. Yeah.
Dave: When that design-developer bridge is rough, I think tools having a way to do it (like by default) is pretty cool. It gives you the baseline experience for designer to developer bridging that gap.
Chris: Right.
Dave: Then there's the developer to production gap. Then there's also the business wants to make money, so we're just going to inject ads everywhere. We're just spackling gaps, I think is what development is.
Chris: Yeah. interesting. Yeah. Okay. Well, it's good. I'm glad you're there. Especially, it does seem like there's some Luro connections. It feels kind of important that you are there, now that I think about it.
Dave: Oh, it's... I mean from a Luro standpoint, it's interesting. Not to be a commercial for Luro here, but we kind of sensed or thought that Figma would be kind of into this design-developer, tightening up that loop, thing.
Chris: Right. This is proof of that.
Dave: We do that to some degree, but we actually kind of more care about how it gets to production and is it successful. Is your design system successful in production? Are the things you're learning sticking around? Do you just lose all your knowledge about the hero unit or the checkout flow the second somebody quits? That's sort of the stuff we care about is the knowledge permanence and even just the adoption of the design system.
Chris: Indeed. I love that.
Dave: That's kind of our--
Chris: You mentioned Storybook for a minute. That's a very big name in our industry, right? Or it has become because it's kind of like build components and then document them - sort of. But what's kind of cool about it is it doesn't infest your component, right? You make a Storybook component kind of next to the actual component that you use, and it mounts and controls that component.
Crucially, you rip Storybook out, it doesn't matter, right? It's not connected to your actual component.
Dave: Yeah. Yeah.
Chris: I'm bringing that up for a reason because I saw it. While I was at Render, at the last thing I was at, I talked to a couple of fellows who are building this thing called Make Swift. It might be worth a look, although it's React only and Next.js only. So, pretty specific in what it does.
It solved that gap -- speaking of gaps, I guess -- that I tried to outlay before, which is that idea that a design tool produces a component in a tool like React (or whatever) - even a Web component. Then you go mess with it yourself. Now you've broken the connection to that design tool because the design tools now can't deal with all your extra stuff or you risk it getting written over or something.
Dave: Mm-hmm.
Chris: They made this tool like Storybook, or at least it seems to me, where you put another component right next to your real component that says, "This is going to make it work with our tool."
What their tool is, it's like the closest... I wonder if they would hate this comparison. I'm sure they're aware of it, though. It was like Web Flow.
Dave: Mm-hmm.
Chris: It's a little drag and drop. It's trying to replicate basically what CSS and HTML can do, essentially, but not have you actually write CSS or HTML. It's like Web Flow, only the components aren't just any components. They're your components that you built.
Dave: Hmm... Nice. Yeah.
Chris: It pieces them together and puts the props in there and stuff. Then you literally deploy it. It's like, "Here's my design system. Here's the components that are wired up to work with your thing." Then you build the site and deploy it.
It's pretty cool. But I like that idea of how it's kind of solved the... You can do whatever you want with your actual components. You can put your GraphQL and whatnot in there and your state machines and your inline CSS and whatever you want to do with the components. It doesn't care what you do. But you can still use them in this other context thanks to this additional file that kind of mounts it.
Dave: No. That's cool. I wonder, too. Is this more a marketing site? Is this more of a product site or e-commerce?
Chris: Right.
Dave: I think, like--
Chris: Marketing.
Dave: Well, yeah. The big examples are kind of that, right? Like the card component and stuff like that.
Chris: Yeah.
Chris: Not necessarily marketing, but what I like about that is you are turning... If you build with a system like this or if you have a really good designer-developer bridge, and you figure out the way to get Figma to spit out live code, you're kind of enabling people to do things in a no-code kind of way and where they might be more comfortable.
Chris: Right.
Dave: Not everyone wants to be a full-time developer, and we should probably celebrate that we don't have to do everything all the time. I think that's cool.
I was going to say I do like Storybook. I like the story format. I like the idea, "Hey, here's a story. Run my component through this scenario. Try this out."
Storybook has actually gotten into this front-end testing. Have you seen any of that stuff? You can basically almost write... If you were writing a Jest test for a component, it might be better to run a Storybook interaction test - or whatever. Like, "Click this."
Chris: Mm-hmm.
Dave: "Expect this alert, or expect this modal to show up," or whatever. As opposed to doing that in Jest, Puppeteer, or something like that.
Chris: I'm that ignorant. Does Storybook run tests? Is that a thing it does?
Dave: Yeah. Yeah.
Chris: Really?!
Dave: It is a new sort of thing it can do.
Chris: Wow!
Dave: Yeah.
Chris: Oh, yeah. How to test UIs with Storybook. Oh, gees. That's smart. Huh. Well, there you go.
Dave: We don't have Storybook, ironically. We support Storybook, but we don't have one.
Chris: No, we don't use it either.
Dave: It's mostly... The tricky thing about Storybook -- and I think they would agree -- is this thing where you have to spin up another server to run it. It doesn't just run in your project. You have to spin up another server to run it.
Chris: Right. We would just put it in our startup flow that starts every other million things we have to do. We have kind of a special admin area. We'd probably slot it into that.
My problem is, would it be worth it for our small team? I don't... There's just no... Nobody is asking for it. Nobody is begging for it.
Dave: Yeah.
Chris: I think there's probably a minimum-size team where it kind of does what it needs to do. It's not that I don't like it conceptually. I just don't think I would get value out of it, like, immediately.
Dave: I like it, but I worry. We could put it in our turbo repo and spin up a whole thing. It'd be pretty easy, to be honest.
But I worry about, like, if the stories get out of date - or whatever. Then it's one more thing to maintain for me right this minute. But I've thought about maybe I should move some of my component tests over that way and just let Storybook do it.
Chris: Yeah.
Dave: That is kind of always being worked on then.
Chris: I feel a little silly, actually. I'm glad we do this show because it makes me think about things from a different perspective sometimes.
Just in the last couple of days, I spun up (in a Next.js site, by the way) a special URL that's just for... I just wanted a quick, little UI just for visualizing some components. These components are going to be used in the real site, but I just needed a quick, little UI to look at them all together and on demand. I'm like, "Oh, crap. I just made a bad Storybook, didn't I?"
Dave: [Laughter] You invented Storybook.
Chris: Damn it!
Dave: It's okay. Every developer does this at one point in their life. [Laughter]
Chris: I wasn't even thinking about it. I was just like, "Oh, I'll just make a route quick," because it takes one second to call a folder admin and put a page in there and drop some components in there.
Dave: Components with props. Yeah.
Chris: Yeah. The technical debt there is pretty fricken low, so I don't know that I for sure regret it.
Dave: But then it's like, "Okay. Cool. Now we need to add a route or a Webpack rule that says, 'Don't compile this folder,' and then..."
Chris: Yeah. But then there's stuff in the opposite direction. Of course, I have this page that's rendering these components, and I have five use state calls at the top that's like, "Okay. Render this with this prop and without this prop. And with this other prop and without this prop."
That's what I mean, a bad Storybook, because I invented my own little props control machine on it.
Dave: Yeah. Right. Right.
Chris: Which I'm sure that's the part that's a little maybe--
Dave: Yeah.
Chris: Okay. Anyway, yeah, Storybook is cool. Make swift. Check it out. I was impressed by their team and the demo. It's a really neat thing that they're doing, I think.
Figma, congrats to them on doing some pretty fancy developer-focused stuff. I think that's smart to understand who the people are using your thing and make stuff for those people. That's what I like here.
Dave: It's a platform, right? It has an API. You can write to it. You can write plugins. You can make weird things.
I heard about some designers who just had this one tasks where, just hypothetical, like exporting assets or something. You'd have to click the file. You'd have to scroll down to the thing. You'd have to click to export and do that. New Figma dev mode fixes the assets thing, too, and you can get it right in your VS Code.
These people wrote a plugin that just bundles the assets for them. It's stuff like that, almost in your VS Code, you write plugins to make your life better in VS Code. You can do that in Figma. You can do that in FigJam. If there's one thing your team always does to kick off a project or something like that, you could just, boom, use this plugin. That's kind of interesting.
[Banjo music starts]
Chris: This episode of ShopTalk Show is brought to you by Notion. That's notion.com/shoptalk. Use that URL, of course, notion.com/shoptalk.
Today, I'm excited to share that they just launched Notion Projects, which includes new, powerful ways to manage projects and leverage the power of their built-in AI features, too. Notion Projects combines project management with your docs, your knowledge base, and AI so you can stop jumping between tools and stop paying too much for those tools, too. Notion is so great.
I wanted to mention one tiny, little thing that I just love about Notion. It's a small feature, but I wonder if it will be compelling to you, too.
It's like this block-based editor. You write a paragraph or put an image there or a block of code or some bullet lists or a toggleable element. The things that you build these documents from is very loose and powerful, and you can kind of do whatever you want in there.
But a paragraph, for example, turns out to be a block, so you can kind of copy and paste it around or just drag it around and stuff. It's a nice way to build documents.
Let's say you have one, and you're like, "Ooh, this is actually some good insight," from, say, a meeting document, which is one of the ways I use Notion. You can copy it, and then you go over to, like, "Oh, I'm going to do a project management card, and we were talking about this problem," so it's become now a card that you're going to manage. I'm going to paste to that paragraph because it was insightful and useful to this task.
You can paste or you can paste and sync, which means that the meeting notes and that thing, it's kind of like the same block. They stay in sync with each other, which is just so clever. I just love that feature. Now, if you update one, it updates the other one, too, so that you don't get this information drift. It's such a nice thing.
While you're managing projects, of course, if you need to get a little kick-starter in your thinking about that task, use their AI tools and prompt them to fill out some stuff. It can really help your brain get going - so nice.
Again, that's notion.com/shoptalk. Use that URL, notion.com/shoptalk.
[Banjo music stops]
Dave: I was going to throw out, there's this thing called Grape.js. Have you heard of Grape.js?
Chris: No!
Dave: It's basically a WYSIWYG. You just had my brain going.
Chris: Uh-huh.
Dave: It's like a Web flow, open-source Web flow, basically.
Chris: Right. Yeah, this is a lot like Make Swift. Oh, my gosh. Although, it looks like you don't bring your own components. It's like, "I would like to add columns." Okay, here are some columns.
Dave: Yeah. I don't know what the underpinnings are here. But it would be cool if it was your own. I don't see why it couldn't be.
Chris: Perhaps, or if you could mount them into the sidebar or something. Oh, that's wild.
I remember the early days of looking at Web flow and being like, "This is so complicated. It's amazing that you did this." - all of a sudden. I'm sure they would look at this and be like, "Ha-ha. This is child's play compared to what we do," or something. But it looks pretty robust at first glance.
Dave: Oh, no, it's just interesting. It's just an interesting route you can go.
But you know what would make all this easier? Web components. Then you wouldn't have to worry about React bundling and things like that. You'd just have a Web component.
Chris: That's true. That's true. Oh, my gosh. I kind of like this. Although, it's just me just talking about my weird little life. I'm not often in a situation where I'm like, "I'm trying to avoid (or provide to someone who doesn't code) a no-code experience." I like code. I want to write code. I want to write CSS. I want to piece together my own component. That's fine for me. In fact, I prefer it.
When I look at this, I'm like, "It's actually really cool." I want to build that tool. I don't need to use it. [Laughter]
Dave: Sure. Yeah, yeah. It's like, "I want to write code. But I also just want to write the code that lets other people not write code. That sounds like fun, too."
Chris: I wonder which audience is bigger. Is there more need for this no-code type of stuff out there, or is there more need for developer-focused tools? I don't know. Maybe it's not the size, but how much competition you have.
Dave: Yeah. Yeah, I don't know. We have the age-old thing where we would always provide no-code tools because the client was big on this has to be no-code. We have to be able to edit every single line of text because of a bad experience where they had to pay per edit. We're like, okay, we'll build you a Web flow.
Guess what happens. They never update their website and they call us to update their website.
Chris: Yeah, it wasn't necessary to begin with.
Dave: Yeah. It's almost... Maybe building no-code for people is not the solution. Maybe they just need to discover that themselves. But people also want quality products, so that's the other part.
Chris: Indeed.
Dave: I think there's a business. We built Web flows for a couple few people.
Chris: Was the point of that you chose Web flow because you wanted to hand it off and say, "Hey, look, now you can edit it"?
Dave: Yeah. Yeah. Then there's always this thing of, like, people don't like to have extra jobs, it turns out. [Laughter]
Chris: Hmm...
Dave: When you're like, "Hey, office employee, it's your job now to update the website," sometimes they're like, "Oh, boy. I don't like that." [Laughter] Anyway, you could...
Chris: Yeah.
Dave: You know. It's kind of like no-code is a dream because you can maintain it for zero dollars with your current employees. But it's also...
Chris: Yeah.
Dave: It's also a thing where somebody has to do it. Will they? I don't know. Question mark.
Chris: I built it for myself in the past, built this, like, I know I need to maintain 15 landing pages. I think I would still do this today. I'm going to do it with the WordPress block editor because I think that's actually a better experience building and maintaining it, even for myself.
Dave: Yeah.
Chris: Yeah. I shouldn't say that I only ever custom-code it, but it's filled with my own crap. You know? Fancy extra CSS and whatever. It's still essentially me building a thing from scratch.
All right. Well, that's cool. You know what I'm thinking about--thinking about what companies that build design and development tools for us and the clever things they do--has me thinking about Stripe because some stuff I'm doing lately is around billing. There are a couple of things that Stripe provides that I've never used before that I'm just starting to use now that I think are like, "Holy crap! Good job!" [Laughter]
I guess I knew that it existed but didn't know that I should be using it, I guess. Two things: One is called Stripe Checkout.
Dave: Mm-hmm.
Chris: Stripe Checkout is kind of like a hosted cart and checkout.
Dave: Yeah.
Chris: You could, for example, send somebody. Say, "Oh, you want to buy this baseball hat?" Just, boom, you send somebody there, and you don't have to build the checkout page or the cart page or anything. You've told it that it's a baseball hat and how much it costs, and they handle the whole rest of the flow.
Dave: Yeah.
Chris: That's amazing how little work you have to do for that. That's cool, but you could do that with PayPal, too. You can always send somebody, like make a little PayPal button or something.
Dave: Yeah. Right.
Chris: It's still nice, and it's like, "Good job. Thanks for handling all this payment stuff for me." I also think it's nice because you can also probably have it adjust an existing subscription and stuff, for example. It really does take some technical debt off your plate.
But okay. Then there's that crucial thing where it's like a lot of people reach for Stripe to begin with because they have these great APIs. Right?
Dave: Right.
Chris: I don't want to send somebody with a PayPal button away from my site. I think it would be a better experience if you never left my site. You checked out right on my site.
Dave: Yeah.
Chris: That's a UX decision that people make. I make it. I like that.
I want you to upgrade, and I want a tiny little contextual modal to come up. I want it to feel very chill. I want to accept credit cards and give you good feedback while you're filling out that form. I want you to be successful. Then I want that modal to close. Now you are on a higher plan. That's the experience I'm trying to build.
Stripe supports that, too, in this thing that they call Stripe Elements. This isn't new stuff, I don't think. They probably have had this for forever.
Dave: Yeah. It's been out for a couple of years now, or a couple of API versions. Yeah.
Chris: I bet when we build our original payment stuff that it didn't exist.
Dave: Yeah.
Chris: We were on our own to make our own payment forms and then hit their API. Get data back. We were on our own building this stuff.
I would rip all that out. I'm in the process of doing it, actually, and just use Stripe Elements instead.
Now, of course, us using React, it's one of the benefits of using a framework like React is that they ship componentry in React and probably nothing else. I don't think I saw any Vue in there or anything.
Dave: We're using it, actually. We just built a payment system.
Chris: Did you use Stripe Elements?
Dave: Yeah, so using the--
Chris: In Vue?
Dave: Yes, but it's not their elements. Maybe it's the... I don't remember the words for this. [Laughter] This is on me.
Chris: Stripe Checkout. It looks like there's... No, no, that's okay. It looks like there are examples of Stripe Checkout with Vue, so maybe it's third-party.
Dave: It's through the Stripe.js thing, so it'll inject it on the page - or whatever.
Chris: Uh-huh.
Dave: The payment element, specifically. And so, what's cool about this or what I find is A) they've done all the UX research on what makes a successful credit card. That's how they make their money.
Chris: Well, that's the thing, dude. You get this... They're incentivized to make this checkout awesome instead of me who will do it and then not touch it for two years.
Dave: Right. And so, it works with standard American credit cards. It'll dynamically add fields or whatever if it needs it - or whatever.
Chris: Oh, and not to mention payment methods and have amazing error checking automatically instead of you writing a fricken' RegEx to test your credit card number to make sure it's in the right format. Ugh!
Dave: Yeah. Don't want to do that.
Chris: Forget that.
Dave: It will support that weird bank from the Netherlands that only does bank-to-bank transfers. [Laughter]
Chris: Apple Pay, Google Pay, bank transfers. Oh, dude.
Dave: Yeah, there are plugins for all that stuff. Anyway, it's very cool. Yeah, it's a very cool sort of--
Chris: I was looking at it. This and the documentation is great. And I really like how, as they do this little walkthrough, they're like, "Here's what you should do first. Set up a little route on your site that you can hit, and it has access to your private key. Then the front-end will have access to your public key," so you can get that setup working already.
You're like, "Okay, okay, I'll do that." Then the back-end makes a little request over to Stripe. They have back-end libraries in everything: Ruby, Python, Go, anything, JavaScript, Node.
And so, it's really easy to set up, and they give you the code to do it. So, you've got that going.
It creates what they call a payment intent. And it responds will all kinds of useful stuff including this client token you need. You pass the client token to the little form that's about to checkout. Now it's ready to use, and you can actually check out with it.
You're like, "Oh, you sneaky devils. You made me essentially integrate this thing in a complete way," just to kind of see the UI. They really want you to get that little client secret before you are even really looking at the UI. But it's so easy to do that it's so tempting to do it.
Now I'm like, "Oh, man. I basically just did the work." I have now a working version of Stripe Elements that I could just ship.
Of course, there's going to be a little bit more polishing up and getting used to it. But then you're kind of in the fun part.
In my world, you call this payment elements function, and it's dynamically determining the payment methods that are possible on your machine at the moment.
Dave: Mm-hmm.
Chris: It's like, "Ooh, I'm in Chrome. It's showing me Google Pay." But if I go to Safari, it'll show me Apple Pay. Like, "Oh, gees. That's fricken' great! Good job!" [Laughter] You know?
Dave: Yeah. That's cool.
Chris: Yeah and doing all the error checking. Really nice. Then it gives you this little options object in JavaScript. You're like, "What can I do with this?"
It's like, "Oh, I see. You have eight or so themes, so I can control it."
"Oh, you don't like the themes or you want to customize them? Here are the eight most common things you want to change." A big one is font family.
Dave: Mm-hmm.
Chris: You want it to be the same font as your website, so you just set the font family. It's like, "Wow, that went a long way to looking in there." Then my CSS brain takes over, and they do all this theming via just custom properties. So, they allow you to set a slew of custom properties.
I was just sitting there making sure it matches out design system perfectly. I'm like, "Aww... I love this! Good job!" You know? And it just had me thinking of what companies can do to just help their customers, in the best possible way, do what they need to do.
You're talking about Figma and helping developers do what they need to do. This is another example of, I think, just knocking it out of the park.
Dave: Well, and it makes you want to use it again. Right?
Chris: Yeah.
Dave: And they probably have some data. We're not always setting up payment systems every day. Maybe some people are. The next job you go to, you're probably going to say Stripe because you had such a good experience.
They're incentivized to make that a good experience. I don't know, man. I feel like you could make a business just making things better as opposed to just making new stuff all the time. You're just like, "Hey, we made it easier to do the thing you liked to do or needed to do," and that's huge.
Chris: Yeah.
Dave: Kudos to them. They're a good company. They also have grips of cash to handle all these problems in a really good way.
[Laughter]
Dave: So, hey.
Chris: Yeah. Yeah.
Dave: Secret path to revenue: Be a company that collects people's revenue.
Chris: Right. The other one I think is crucial to them is have a blue link that says "share" in the upper right corner. You can open it, and you can type in somebody's (who works with you) email address into it, and it will invite them to look at this very useful document with you. That's what they called network effects in software, and it gets the whole company using it.
Then when everybody is using it and says, "Oh, how much is a team account again?" it literally doesn't matter because everybody needs to use this thing, so you could charge whatever the hell you want for it.
Dave: No, that's a good one. That one is hard to code for me, the security model on, like, "If you have this secret link." You know?
Chris: [Laughter]
Dave: It's not a secret anymore. You know?
Chris: Yeah.
Dave: That's hard.
Chris: It's the money model, though. Yeah. No, I'm not saying that every app in the world. We've talked about this before, but I think it's fricken' huge. We're working on it now. No huge surprise there, probably. But it has required a different way of thinking about permissions, for sure.
I wouldn't go so far to say I regret doing it the way we did first. You need to have a learning experience.
Dave: No. I think your obfuscated URL structure works, still.
Chris: Yeah.
Dave: But when it's a Google Docs level secrets, there I'm just like, "Are we sure this is secret?"
[Laughter]
Dave: We're just transmitting, letting them transmit.
Chris: I think their model is a little better, though, honestly.
Dave: Yeah. It auths through a Google account.
Chris: Yeah. It's real. We'll probably have both. But I wonder if you'll even remember. At one point, the CodePen URLs to private things were just one big, long string. Now, if you go -- I don't know, a year, at least, since we made this change -- you'll see the original private URL, slash, and then a big, long string so that if you un-private it, that big, long thing just goes away. But it otherwise behaves exactly the same.
The idea is that we're starting to think in tokens more. That additional big, long string is actually a token, and the token is what puts you in the correct permissions role to see it.
Dave: In the viewing power. Right. Okay.
Chris: Right. If you don't have that token, then you don't get that permission. Then you can't see it if the Pen is private or whatever. That's a lot cleaner. It's required a little extra... Maybe argue it's a slightly less clean URL, but I think it's fine. It's just a slash in there. Who cares?
Dave: Oh, no. It's actually good for me when, like, "Oh, yeah, it's not private anymore. I don't have to go dig for another." You're not redirecting.
Chris: Yeah and there's just been proof lately that it doesn't matter. Have you looked at the URL for Notion? Any page on Notion, anyone at all that you're on, the URL is a mess. [Laughter] It's what I would get from my old-school experience, just a horrible-looking URL. They're just UUIDs. But does anybody care? No. Absolutely not.
Dave: [Laughter] Notion defaulted my link URL to its... Yeah, so it's so much garbage. But when I publish something - or whatever - the URL that they give me is accessible louse.
Chris: [Laughter]
Dave: I'm like, "I'll take it. Sure. I'll embrace that."
Chris: Yeah. You mean the .site URLs if you make them public? Yeah.
Dave: Yeah.
Chris: Right.
Dave: Accessible louse.
[Laughter]
Dave: It's good. I'll take it.
Chris: Yeah, that's funny. That's funny. I bet they do that for caching.
Dave: Yeah.
Chris: You've got to have a unique subdomain.
Dave: Yeah. I can't even find one that's published, but whatever. One day.
Chris: Yeah. I mostly mean just your URLs internally. I think that's more and more common that you see stuff like UUIDs in URLs because maybe partially because browsers have started hiding URLs more and more.
Dave: Mm-hmm.
Chris: It's starting to matter less if your URL is really nice and clean-looking.
Dave: I'm seeing a lot of English slug slash or dash actual computer slug or computer UUID.
Chris: Oh, right. Yeah.
Dave: Then there's some RegEx that just takes the URL and splices it and then fetches the record it needs. It's very obvious to me what they're doing, but it's very... You know.
Chris: Hmm...
Dave: It makes people feel like they have a cool URL.
Chris: That's good way of doing it. The bad way is that there's a string in there that doesn't matter. That you could put accessible louse right in the middle of the URL. But it's only the UUID at the end that matters. Then you have that duplicate content issue and stuff. I think that's sloppy.
Dave: Yeah. I agree.
Chris: I don't even know how we got into that, but permissions models, pretty good if you can pull it off.
Dave: Permissions models are hard, man. I feel like you could have a whole department at your work that just figures that out.
Chris: Yeah.
Dave: And onboarding flows. Those are two whole departments, in my brain.
Chris: Oh, my gosh. Yeah, we use this thing called Appcues at CodePen, too, that shows little popups and stuff. Hopefully, it's not too annoying, but we've been using a little bit more recently, especially for customers. Like, "You've been on a free account for seven years. I'm going to send you a special popup that reminds you that we have pro plans." Sorry, but that's what we're going to do.
The default way that you link up Appcues is to a third-party JavaScript, like Stripe Elements is similar. You might need to link up some of their JavaScript to make it work. But Appcues is not... It's just for showing these popup things. And I'm thinking of it because of onboarding.
Dave: Mm-hmm.
Chris: We have some of our onboarding tours are powered by it. Some people block it like an ad blocker - or whatever.
Dave: Yeah, right.
Chris: It just looks like third-party whatever. We've recently started. It's a feature that they actually support is just like, "Oh, you can just CNAME that if you want and have it be like appcues.codepen.io - or something." Then it's not generally just instantly blocked. You can block it if you want. It's still got a unique URL, but I didn't like that it was, by default, blocked. Sorry if that's offensive to some people, but we started kind of pseudo-proxying it because it's part of our fricken' onboarding flow. I don't want you to sign up for CodePen and then not see the onboarding because your dumb ad blocker blocked it.
Dave: I wish you could... This will never happen. I wish there was a way to be like, "I am not a bad guy." Literally, if I'm scraping your data and doing all that, I apologize because I literally didn't know I was doing it. That sounds negligent, but I'm not doing anything with it. I'm not doing anything criminally intentful.
Chris: Right. I promise. If I wanted to sell your email address, I don't know anybody that would buy it. [Laughter]
Dave: Well, I say that, but I just read this book. Are you ready?
Chris: Yeah.
Dave: It's called... You're going to have to bleep this out. It's called Mindf*ck, by Christopher Wylie. He worked for Cambridge Analytica.
Chris: Oh, right.
Dave: It's a really interesting story. He worked for the Obama campaign. Then he worked for Lib Dems in the UK. Then worked for a military DOD contract - or whatever. Then fighting jihadists and stuff like that.
Chris: So, is the guy--? Is he feeling bad that he did all that?
Dave: I mean you always take the bag, and then you feel bad. Right?
[Laughter]
Chris: Then you write a book and take another bag.
Dave: Yeah, you get two bags. That's how you get... It's the old two-bag trick.
[Laughter]
Dave: Yeah, he basically whistle blew about it and spoke to Congress and stuff like that. It was a really... I mean it was an effort where this machine... He built this behavioral analytic machine.
It could predict people's behaviors, and it figured out how it could nudge people's behaviors based on certain, you know, "Do you shop at Whole Foods and you have an AT&T phone?" or something. It could figure out, "Well, cool. Then I can maybe make you vote in the next election," or whatever.
The technology, that model basically has impacted Obama's win. It impacted Trump's win. It impacted Brexit's win, like the leave EU stuff.
All to say is it works, I guess. But they did some underhanded things, and it was generally just motivating people to vote until it got into the hands of people who were a little less... had less of a moral compass, and they were more about, "Let's make as much money as possible, and then let's explode the world," or Steve Bannon style, flood the field with shit. Literally Steve Bannon, actually. [Laughter]
Chris: Hmm...
Dave: Anyway, just cause chaos and get people mad at each other, and then they won't vote because they're just mad or think that their vote doesn't count. Anyway, it's really interesting.
Chris: Yeah.
Dave: All to say, maybe collecting data is bad. [Laughter]
Chris: Dang it! It all comes around.
Dave: Well, I'll say no. Collecting data isn't bad. Selling the data is bad.
Chris: Right.
Dave: It's funny because they were just like, "We just would walk up to phone companies," wherever, like Brazil, "and just say, 'Can we just have your customers' data?' and they would be like, 'Yeah.'"
Chris: Oh, my God.
Dave: They were just like, "Well, that was easy."
Chris: [Laughter] Hopefully, those days are coming to a close. Yeah, needless to say, if I was asked for data, I would not provide it.
Dave: Yeah. No, I wouldn't even... I would just groan because that would be another thing I'd have to do is figure out how to....
Chris: Oh, yeah, that's funny. Not going to provide it to you because I don't want to. Because I'm fricken' busy matching korok buddies to each other.
Dave: Yeah. Yeah, that's a lot of work and interrupts my Zelda gameplay negatively, so probably not.
Chris: Yeah. You know what I was doing the other day? This is the last... I just have it on my list here because it annoyed me about half an hour ago. I guess we've been recording longer than that, but shortly before recording.
I had this header bar. There's an input element in it. Imagine input with a data list so that a dropdown comes down.
Dave: Yeah. Yeah.
Chris: Right?
Dave: Auto-complete kind of thing.
Chris: Yeah and I was like, "Oh, you know what? I want..." but the thing that pops out is a custom component. It's not the browser default. But I don't... Well, we'll see what you think about this.
The custom component is as big as the input that it came from is in. But I'm like, ah, sometimes the results are pretty long, so I actually want to... When there's enough room on its parent component, I'm just going to force the width wider so it looks good. But if there's not room, don't do that.
I was like, "Ah, container query. I'm going to container query it up, baby." I'm going to have the container that I care about is actually a couple of parents up, actually. I think it's going to be part of the whole header kind of area, which at the moment is the same size as the browser window. But it wouldn't have to be. If there was a sidebar opened up, maybe it would squish that area.
I'm just trying to think future-friendly here. I'm going to make that header component a container. But just putting... So, container is the property in CSS. A lot of times you just say, "Container inline size," or you say, "Container name / inline size," and you name it because naming is nice. If you're trying to be really specific later when you actually write the container query, you can reference the name. If you don't do that, you just get the next container, the next one that it finds.
Dave: Yeah, which cannot be good.
Chris: It can be weird.
Dave: Yeah.
Chris: Right.
Dave: I've actually ran into that, just in my experiments.
Chris: Right.
Dave: I was like, "Why are you 100 pixels wide?" [Laughter]
Chris: Yeah.
Dave: Oh... You ... that guy.
Chris: You might as well be specific. If your brain is thinking specifically about which container, then just name it. Then you won't have the problem.
But as soon as I put it on there, it cut off the dropdown of the results because that component is only 100 pixels tall or so. Container, boom, hidden overflow.
Dave: Oh, really?!
Chris: Just having the container property on it, because of the inline size of it, immediately overflow hidden, essentially. I don't know if it's treated the same as overflow, but I was like, "Well, that's out."
Dave: Yeah.
Chris: I was like, "Oh, crap! I haven't seen such a bad side effect yet from container queries," but that's kind of a bad one. A lot of times you're thinking about cards and, usually, you want the overflow hidden-ness on a card layout. You're like, "I don't want nothing to pop out of this." But when it comes to additional UI, which will come up with the anchor popups or the popup proposal and all that.
Dave: That's what I was going for. You'd have to pop open your Chrome Canary, but you could try the pop-over attribute.
Chris: Oh. And see if it promotes it a little higher. Ooh... That would do it.
Dave: Because I would put it on a top layer, not on your header layer.
Chris: That is a good idea.
Dave: Maybe that is enough to divorce it from the height constraint. I thought inline size was literally the inline size. But now that it constrains the--
Chris: Vertical size, the block size.
Dave: The vertical, that's interesting to me, too.
Chris: Yeah, because we've never had directionally hidden overflow. You can say overflow X hidden overflow Y visible, but it does not honor that.
Dave: Yeah.
Chris: That's not a thing.
Dave: I was trying to use container size, which is the height and width. It was collapsing.
Chris: Container size is a property that means both height and width?
Dave: I believe so.
Chris: Oh, wow.
Dave: Let me see. Container size... I was reading. This is why you never read docs because it'll tell you stuff that you can use, and then it doesn't actually work in a browser, sort of. It just didn't work how I expected.
Chris: Yeah. Yeah.
Dave: It collapsed the whole thing, and it was just like, "Oh, I think I have to... It only works if you specify a height and a width on something."
Chris: Oh, I see.
Dave: Or it only works on something that has a height, like a canvas or something like that. Anyway, it didn't work was the TLDR.
[Laughter]
Dave: I was working very hard, and it didn't work.
Chris: It reminds you of the inset property. That's a forgotten one a little bit. But if you need a rectangle or something inside another one, instead of going, like, "Top ten, right ten, left ten, bottom ten," or the logical property version of those, you can just say, "Inset ten," and it sets all four of them. I love that. That's wonderful. [Laughter]
Dave: Robin Rendle and a few other people were talking on the Mastodon, and we were just talking about sometimes you have a blog post, right? Sometimes you have a title that's two words, like, "Fit Text," or something like that. Right?
Chris: Right. Yeah, yeah.
Dave: Sometimes you have a title that's ten words.
Chris: Mm-hmm.
Dave: Let me just go to my blog real quick. "Lessons from Soviet Russia on Deploying Small Nuclear Generators." Okay? [Laughter]
Chris: Pretty long. Yeah.
Dave: Yeah. Yeah, I've done longer.
Chris: Right.
Dave: I kind of want my title to only always be about two lines, so I kind of actually want, the longer my title gets, the font size to shrink. Does that make sense?
Chris: Hm... Based on the size of its content? Yeah.
Dave: Yeah.
Chris: What would you call that? What's the one that you can trim, line trim, but it's similar? You could say, "I want this content to just be two lines long." You could say, "I want this headline to just be two lines long. Adjust font size as you will."
Dave: Yeah. Yeah and so I wish... Does that property exist? No, it doesn't.
Chris: No.
Dave: Okay. I was like, maybe that solves the problem, Chris. [Laughter] But I was just kind of like, "Oh, it'd be cool if I could do this."
You can do it in JavaScript. You can be like, text content length.
Chris: Yeah. A PHP version of that in WordPress back in the day. It would count the letters in PHP and apply a class, like long headline.
Dave: A class or CSS var or something like that, right?
Chris: Sure. I wonder if you could write a height query on it.
Dave: Yeah.
Chris: And then set the size smaller. But that would be cyclical, wouldn't it? It's like, "If the headline is too tall, then make it smaller."
Dave: That's what I was trying to do, and it was very mad at me. I think it was bailing out. But I wrote one that was... Here, I can post it or maybe I'll put it in the show notes here. I wrote one that was--
Chris: Sqwunch Text?
Dave: We're calling it Sqwunch. Yeah. I think that was Ethan Marcott.
Chris: That's wonderful.
Dave: Sqwunching. We're sqwunching text but trying to get it to sqwunch up.
Chris: Oh, gosh. You had to be very JavaScript about it, it looks like.
Dave: Well, I injected a span for every single character in there. Then I used :has(), CSS :has() to control, like count the spans.
Chris: Oh...
Dave: Then sqwunch it.
Chris: :has() Nth of type of on the span. Yeah, you could use Lettering.js for this, too, I suppose. Yeah.
Dave: I wouldn't, but you could. [Laughter]
Chris: What's the Steven Shaw one?
Dave: Splitting.js.
Chris: Split. Yeah.
Dave: Yeah, you could do that.
Chris: I like the :has() span Nth of type. It's like... What'd we use to call that back even before :has() existed? A quantity query, I think they were called.
Dave: Yeah, quantity query. Yeah.
Chris: This is kind of like a really basic quantity query. That's clever.
Dave: Yeah.
Chris: It sucks that you have to count the spans.
Dave: It would be cool... CSS wish list: It would be cool if I could sqwunch things, I had a text sqwunch property.
[Laughter]
Chris: Sqwunching property.
Dave: I want a text sqwunch property and value could be... I don't know. Maybe I give it three or four values or something. I don't know. Or clamp or something could work out like that.
Chris: Yeah. I don't know. CSS has never messed with the content so much.
Dave: Yeah.
Chris: Would it have been nice to have a contains and then an arbitrary word or something so you could--?
Dave: Cars 15, or something.
Chris: Yeah, exactly. They've never messed with that. This seems similar.
Dave: Mm-hmm. Yeah.
Chris: Although, I don't know. I think that's some hard rule or anything. This is a good use case. This is the perfect Pen that can start a conversation about this.
Dave: Yeah. So, anyway, sqwunching. If somebody finds a really simple way to sqwunch text with three different values.
Chris: Everybody, put it on your 2024 wish lists.
Dave: Text sqwunch, let's put it in the CSS quiz, surveys coming out.
Chris: Uh-huh.
Dave: Text sqwunch. [Laughter]
Chris: Yeah. I wish I was at CSS Day. It seems like they talked about a lot of interesting to-come stuff with the vibe of, like, "If you think what we've gotten recently in CSS is a big deal, just wait," kind of vibe. I'm like, "Really?!" I can't even think of more stuff, really. [Laughter]
I was like, "Slow down! Gees!"
Dave: Yeah. Well, no, I feel like we could do a whole show on that. Is CSS going too fast, like too hard?
Chris: Yeah. There's starting to be a little bit of pushback.
Dave: I don't know. Um... I am actually in the "heck, no." It was neglected for a decade, so let's do what we can.
Chris: Right. What's your least--? Can you name something that you just hate in CSS? I don't know that I can, really. There's probably stuff I don't use that much, but it's not like there's some feature where I'm like, "Ooh, shit the bed on that one, CSS."
Dave: No. I think one common thing that comes up is all the units. There's something like 58 different CSS units - or something like that.
Chris: Hmm...
Dave: I don't know. But we all kind of know.
Chris: Right, and which one do you use? I feel like that would still be a very popular article if somebody wrote a really good, "How should you size your text?" something - whatever.
Dave: Yeah.
Chris: And be like, "You could use these 18 units," and it'd be like, "Too many! That's too many."
Dave: Yeah. We should probably just... I don't know. Somebody, draw a line in the sand and be like, "These ones are okay and these are not." [Laughter]
Chris: Yeah!
Dave: Here's my line.
Chris: I think that's what my brain did. I was like, "Oh, rem is fine. I'm just going to only use that ever."
Dave: Yeah.
Chris: To this day, that's all I use. I think it's because it doesn't make anybody mad and it works just fine for me.
Dave: Yeah.
Chris: I don't know. I certainly don't use CH.
Dave: I'll use CH sometimes. But it doesn't really mean anything. You know what I mean? That's what's kind of weird about it. It's the size of an M - or whatever. It's like, "Oh."
Chris: Right. Then there was just a Cloudflare article. Did you see that one? It was probably from Tyler (or somebody smart over there), who was like, "Oh, we used it, but then when fout happens, your CH changes, too. If you used CH for anything else, it will immediately change, like when the new font comes in.
Dave: Because they're metric-based.
Chris: They were setting the height of a hero image in CH, and it caused a bad -- what do they call it -- CLS.
Dave: Yeah.
Chris: It was like, "Oh, see!" Right there I'm like, "Nope! Forget it."
Dave: Yeah. No. Yeah.
Chris: [Laughter]
Dave: Can't have that. No, I think they did some work on that. I read that article, but they did some work. I feel like there was one that kind of surprised them, too. It wasn't responsive or something like that. Was that CH?
Ack! I'm saying it wrong. But I feel like there was one. Somebody was like, "Hey, if you use this, it's not actually responsive anymore," or something. It was kind of a surprise - or something. Anyway, I can't remember. It wasn't CH.
Yeah, I think it would be cool to round up all these known issues with each element or each unit, and then draw a line in the sand, like, "Don't use inches. Don't use centimeters," or whatever. We're just not using those.
Chris: I don't know what even feels good anymore. I don't use pixels, and I don't, generally. I think we do for border-radius and stuff that you want to be pretty specific about. But even that, I occasionally regret when I see somebody's cool demo that uses V-min or something for border-radius. I'm like, "Oh, that looks awesome."
Dave: Yeah. Yeah.
Chris: But pixels are just so meaningless in my brain now that we've gone through so many iterations of pixel density and stuff that it is now firmly an absolutely arbitrary number. It doesn't mean anything.
Dave: For me, it's the number. It's the unit I use when I'm being lazy, when I know I just don't want to figure out what I'm actually dealing with. I'm just like, "Eight. Done." So, anyway.
Chris: All right, man. Well, thanks for taking all the time in your fricken' hotel room to hang out. I hope you end up having weird conversations in a hotel bar later.
Dave: I will do my best.
Chris: Say some stuff you half regret and wake up a little dehydrated. [Laughter]
Dave: I can do that. I'm fully capable of doing that.
Chris: Oh, good.
Dave: I have the tools to do that. [Laughter]
Chris: Yeah. Wake up to some Hilton eggs.
Dave: Ooh, yeah.
Chris: Yeah. [Laughter]
Dave: They've got a continental breakfast, I hear. So, hey.
Chris: Darn right.
Dave: [Laughter] Better have a waffle maker. I bet it's the... I think it's the kind of hotel where you pay $20 for a waffle.
Chris: Yeah.
Dave: It's not the--
Chris: I see. I see. It's not the Roadside.
Dave: Yeah. Not the Roadside.
Chris: Motel 6 waffles.
Dave: Uh... Anyway.
Chris: I miss that sometimes, though, man. I'll tell you. When we went to Hawaii and I was at the Aulani Resort, very fancy, I was like, "Where is the Motel 6 coffee, dude?" You had to buy coffee in the morning, and I was incensed about it.
Dave: Oh... There's no--
Chris: I was like, "How's the business model for this not include a fricken' coffee in the morning?"
Dave: We should have gone to the Hampton Inn, honey."
Chris: Yeah. [Laughter] Yeah.
Dave: Yeah. There's something about a Hampton. I tell you what. Everything is covered in Fruit Loops and it's wonderful.
[Laughter]
Dave: Ten-day old croissant with some Fruit Loops in it.
Chris: Yeah.
Dave: You could get that....
Chris: I want my Fruit Loops sqwunched down into the cushion somewhere.
Dave: Hmm... For sure. Sqwunching... All right, hey, we're going to wrap this up. Thank you, 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 the socials. I think, yeah, anyway, and then, yeah, join us in the D-d-d-d-discord, patreon.com/shoptalkshow. Chris, do you got anything else you'd like to say?
Chris: Oh... ShopTalkShow.com.