478: Google Changing Titles, jQuery + Chris’ Birthday, Kissing Content, and Word Break Break Word
Google is changing page title in search results, celebrating jQuery + Chris' birthday, content that gets too close and kisses, dealing with website sandwiches, using word break break word, and abuse of alerts on the web.
Guests
Chris Coyier and Dave Rupert
Time Jump Links
Transcript
[Banjo music]
MANTRA: Just Build Websites!
Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show, a podcast all about front-end Web design and development. I'm Dave Rupert and with me is Chris Coyier. Hey, Chris!
Chris Coyier: Yeah. This is great. You know what happened to me the other day? I did a search for something CSS-related and landed on my own site. Obviously, right? There's just a lot of crap on CSS-Tricks, and that's my second brain.
Dave: I get offended when I don't land on CSS-Tricks. I'll be honest.
Chris: I was looking for backdrop filter. One of the weirdest named CSS properties, isn't it? Who invented the word "backdrop" and why is it different than "background"?
Dave: Right.
Chris: It's just weird.
Dave: And I think it was WebKit. But what's weird is WebKit doesn't have dialog, which also has a ::backdrop.
Chris: Oh...
Dave: What do we do?
Chris: You mean the ::backdrop is the thing that you can target that basically covers the screen?
Dave: Yeah.
Chris: And is a little bit stylable. Like if your brand color is red, you can make the background of your page red when the thing opens.
Dave: That is also a backdrop, yes. Yes.
Chris: Backdrop, okay. I'm sure it has some kind of meaning. It's hard for my brain to remember it because, in the case of the CSS property backdrop filter, all it's doing is filtering -- literally, duh, filtering -- the background.
Dave: Yeah.
Chris: So, why can't it be background filter?
Dave: Yeah, I don't know. But maybe it's this invisible layer just above the background. Maybe that's what backdrop means.
Chris: Yeah, right, because the connection with dialog is interesting there. Good call. Good call.
Dave: I wonder. I wonder. No, I agree. It's a hard one because it doesn't auto-complete. I'm like, "Background filter... where is it? Where's background filter?" you know? I never remember it's backdrop filter.
Chris: So, I Google it "backdrop filter." You know there's MDN's and then our post. We have an almanac post on it and other blog posts on it. Cool.
I notice that the title in the SERP, which is Google's Search Engine Results Page--
Dave: Mm-hmm. Mm-hmm.
Chris: You know that's just the term for that, like the results page of Google. I see that the title of it -- and this is true if you do it right now -- the title of the page is "backdrop-filter: blur(5px) - CSS-Tricks". I was like, that's so interesting. Why does it have an example of usage of backdrop filter in the title? That's not the page title. That's not the H1 that's on the page.
Dave: What?!
Chris: It's neither one of those things. I'm like, that's weird. Why would it choose that?
Dave: I'm seeing it. It's the big Google link, and it says "backdrop-filter: blur(5px)" and you don't even have blur(5px) on the page.
Chris: Yeah, not really. There is one that's buried in a Pen on the page. If you really start digging around in there -- and my coworker Jeff discovered that -- there is an H1 that has a similar title like that, but it's two iframes deep because it's in a CodePen embed and then it's in the preview of the embed, which is two iframes deep. So, it's like, "Whoa!"
Google does index iframes, so it's really dug in there, but it's a cross-origin iframe, and so that seems extra weird.
Anyway, I get confused by this, but I'm like, the first thing I thought of was that we actually add some metadata usage examples like that to the page because there's just certain context on the page where we want to show you, like an example usage of it.
Dave: Yeah. Yeah.
Chris: I know that's complicated, but we have this mini card pattern.
Dave: Okay.
Chris: The mini card pattern, we drop that on there.
Dave: Okay.
Chris: I was like, "Oh, it's probably that," but then I'm like, "But we don't output that anywhere on the normal page. That's only used in weird circumstances, so how would Google know about that?"
I get confused. I basically write it up as a little Twitter thread, and just be like, "I don't know what's going on. I have no idea."
One response from that is, "That's not surprising at all. Google has been rewriting titles in SERPs forever." For like ten years, apparently, they've been doing this type of thing. But it was new to me.
I'm like, "I don't control that anymore?" I always thought that it mattered what you put as the title of your page because--
Dave: That's what you got indexed on. That's the whole thing. That's SEO, right?
Chris: Yeah.
Dave: I'm confused. Right?
Chris: Yeah, you'd think that's important because that's what shows up there and it matters. Also, the title shows up in the tab of the browser, so that matters, too. But that's always funky because it feels like you get ten characters, because most people's browser tabs are so narrow. Even at their widest, they're not that wide. So, not as useful up there.
The main reason you have good titles is because of Google. And so, I did finally get an answer to this just today.
Dave: Oh, really? Fascinating.
Chris: Google is just saying. They posted two days ago (August 24th) an update to how we generate webpage titles, and it basically just says, "We reserve the right to just change your titles, and we're going to use information on your page to do it: H1s, title. We're going to just--
Dave: Three iframes deep. [Laughter]
Chris: They don't say machine learning, but they're machine learning it up, you know.
Dave: This is a blockbuster expose, Chris.
Chris: [Laughter]
Dave: It's pulling one line of CSS five levels deep for your page title. That is--
Chris: Yeah, how does it know? It's magic stuff.
Dave: It's like Google copilot in your blog post title because it's like, "Oh, you typed backdrop filter. You probably meant blurify px."
Chris: Yeah. Right. When I look at this result, I don't hate it. I kind of like that it intelligently came up with something. But I'm like, "You better be really sure."
Dave: Because if I write a "Barak Obama is bad" piece and I mean one thing and then somebody is like, "Barak Obama is badass." Does it change it to that? You know what I mean?
Chris: Yeah, right. It can really affect meaning and stuff. Now, with technological stuff like this maybe it's not. But of course, they're not doing this just for tech sites. They're doing this for the entire Internet.
Dave: Yeah.
Chris: So, they better be really sure. Then it's weird. That's the part that I don't like. Do I have any say anymore?
What's interesting is SERPs are not the Web. There's no spec. Google wholly owns this. They can do literally whatever they want. But it does feel like then we're extra pee-ons in this world. We just have no say.
Dave: Yeah.
Chris: No say.
Dave: All control you had, your whole -- that 80 hours you spent fine-tuning your Yoast SEO is just out the window. I don't know, man.
Chris: I think they would tell you that it still matters. They would say, "Oh, well, of course, it's still a huge indicator of what the title ends up being." I think, in my case, the title ends up being a variation of what's already there. It's not saying it doesn't matter, but it is saying you don't have control.
Dave: Man, that is revolutionary. I am going to invoice them because I just spent a bunch of time writing out, like, integrating a whole SEO thing on this client site, so guess what, you're getting invoiced for 65 templates times one hour. There you go.
Chris: [Chuckles]
Dave: $4.8 million, I think is my hourly rate, so there you go.
Chris: Hmm.
Dave: Man.
Chris: Well, just something to be aware of, folks.
It's my birthday today. Today, as we record.
Dave: Hey! Happy birthday! I didn't know that. Hey, congratulations.
Chris: Ah, thanks.
Dave: You made it, another trip around the sun.
Chris: Uh-huh. Uh-huh. It happens to -- I bring it up because there was a nice Sara Soueidan tweet today. She found somebody watching a video, and it turned out they liked jQuery. The person in the video felt the need to apologize for their liking of jQuery.
Dave: Mm-hmm.
Chris: She's like, "Oh, that's sad." Then there was Henri Helvetica's post that was like, "Well, what an interesting thing to tweet today, the 15 year birthday of the 1.0 release of jQuery." So, apparently, I share a birthday with jQuery as well, which I'm totally cool with.
Dave: What?! Dude. Destiny.
Chris: [Laughter]
Dave: That is just beautiful.
Chris: jQuery changed my life, I'll say. It was my intro to JavaScript, for sure. There was a book I read by Karl Swedberg, I think, that laid it out pretty well how jQuery works.
At the time, I felt pretty confident in my CSS skills, and I was like, their "Find something, do something" mantra, I was like, "I know how to find something, so all I really need to learn is how to do something. The APIs of jQuery were like, "Add class. Hide. Show."
Dave: Mm-hmm.
Chris: Attr, you know, I was like, "Oh, dang. I get it. I totally get it."
Dave: Yeah.
Chris: There was a lot to learn, but that was transformative for me. Then, at that time, there started to be all kinds of posts on CSS-Tricks about jQuery because now it's part of my arsenal.
Dave: Mm-hmm. Mm-hmm.
Chris: I'd say that it changed everything. In that same way, I know React people like to say, "It's just JavaScript," which in some kind of weird way it kind of is. The functions you write in jQuery are kind of less laden in proprietary stuff. I don't know if that's quite fair, but at least it's a saying that gets thrown around a lot.
jQuery really was just JavaScript, too. So, as you were learning jQuery, there were plenty of moments that you had to reach outside of jQuery to do JavaScript things. By virtue of it, a lot of people learned JavaScript.
Dave: Well, and what's cool is with Sizzle, the Sizzle selector engine in jQuery, your knowledge of CSS instantly made you more powerful at JavaScript and, I would even say, it still does. [Laughter] But that's just me.
Chris: Yeah.
Dave: Because you're like, "Oh, I just use a CSS selector to select this thing. I didn't have to do document-get-element by whatever ancient nametag or whatever crap."
Chris: Right.
Dave: You could just write dollar get the thing. Then you learned, "Oh, there's a weird thing about WordPress. It does not like the dollar sign." Then you had to figure out why that was, and you learned hide, show.
Chris: Yeah.
Dave: Then there was animate.
Chris: Right.
Dave: It was cool.
Chris: Do they still bundle Sizzle with jQuery? It's kind of like, "Why?" you know. Isn't querySelectorAll just Sizzle?
Dave: I think it's maybe still Sizzle because maybe there are some weird things it did.
Chris: Right.
Dave: Like sum-y things. But you know what's cool. It's like loop through an array of elements and find only children that have the class in progress, or something like that. That's something I did recently.
Chris: Mm-hmm.
Dave: Guess what. CSS does that really good. [Laughter]
Chris: Yeah.
Dave: You just say whatever, like items.in-progress, and it'll just get you the only ones. It actually could save you a lot of JavaScript if you're good at CSS selector foo.
Chris: Yeah. I remember having to internalize (and then teach once in a while) that concept of implicit iteration.
Dave: Mm-hmm.
Chris: Where if you have that in progress class that you just mention and then you do .attr (or whatever) and change some attribute that you didn't have to write a loop.
Dave: Mm-hmm. Yeah.
Chris: It just did that.
Dave: Yeah.
Chris: You just had to know that it would find everything on the page and do that. That was cool. [Laughter] That's a nice--
Dave: Yeah.
Chris: That's a nice little thing. Or you could loop over and manually do it, but it was kind of like, "Why?" You know? You've got the syntactic sugar. Just use it.
Dave: It's powerful.
Chris: It is.
Dave: Every day, man, I'll query selector something. It's a little harder in Vue. I don't know how it is in React, but you have to wait until the components mounted, right?
Chris: Yeah.
Dave: That's like the trick because, before it's mounted, it has no idea what's going on.
Chris: In Vue, you have to do that once in a while?
Dave: Yeah.
Chris: You have to literally query selector after? Yeah?
Dave: Yeah, it has refs, which I think are the same as React refs.
Chris: That's what I was going to say. You just use ref.
Dave: Then it shows up eventually, or whatever. Yeah. No, and that's cool. I get that. But then--
Chris: You could grab stuff from an API or something (actual HTML). Then it wouldn't know--
Dave: Yeah, like something, "A component is over," or something. I guess you'd still want to use ref there. Every once in a while, you just have to query selector.
Chris: Right.
Dave: Does the content the user put in have an iframe or is it just a div soup?
Chris: Sure. Right.
Dave: That's where they can write their own HTML. I know that's kind of risky, too, using dangerously set inner HTML or VHTML in Vue. But guess what - it happens sometimes. [Laughter]
Chris: Yeah.
Dave: If you ever use a WYSIWYG, it happens. [Laughter]
Chris: Right. I wonder now that jQuery is so old and we're in this weird apologetic--
We should move on after this, too. Sorry to the people that don't give a crap about jQuery.
You're not reaching for it now. You made your little bookshelf. You weren't like, "You know what? jQuery is fine for this because it's just manipulating on the page." You didn't reach for it, Dave. You reached for Petite Vue.
Dave: Mm-hmm.
Chris: A lot of people are reaching for Alpine. Is that better?
Dave: I think so because I could have done it in jQuery.
Chris: Sure could have.
Dave: But it would have been a lot of -- the only thing I could have done is add a data attribute to everything. That's fine. I could do that. Then I'd have to go, "Okay, query selector everything. Hide everything. Then only show the ones where data attribute equals this," you know, on click or something like that. I could do that, but then I have -- I guess there'd be like ten buttons. That's fine. But if you want to support keyboard events, oh, no.
It starts piling up on what I was doing, and I don't want click soup. I want reactivity, I guess would be the way to put it. I want a variable to be set up on a parent and the rest of the content figures out what to do after that. That's what I did.
Chris: Yeah. That -- yeah.
Dave: There's a subtle difference between -- like, you can fake reactivity with click soup, I guess. You could click a thing, and then you can spit out a page. It's a lot easier if it's actually reactive.
Some practical work experience, I worked for a popular pizza shack themed pizza company once, [laughter] and I built this thing out in jQuery. It's like 600 lines of jQuery for their pizza builder thing, and it works.
Chris: Production?
Dave: In production, yeah. I think it's maybe Angular now. But it was like, man, this is, like, okay but it's brutal. Right? This is so much because a pizza is basically an infinitely configurable product. That's what you need to understand about pizzas before you get into the pizza website-making business, right?
Chris: Right.
Dave: You can have up to 16 toppings total.
Chris: Per side.
Dave: Or ten on the left side and ten on the right side or--
Chris: Right.
Dave: and then no cheese is also an option, and stuff like that.
Chris: Yeah.
Dave: It was brutal to code out, and I just was like, "Is this easier in Vue," one day, and I wrote it in Vue in a CodePen. It was 40 lines of Vue.
Chris: Hmm.
Dave: You know what I mean?
Chris: Yeah.
Dave: Versus 600 lines of jQuery.
Chris: Right. What I didn't like about jQuery is that, first, you write a bunch of HTML and CSS and get it styled all right. Then the implication is there that you're pretending that it's fine without JavaScript, but you know it isn't. It's not fine.
Dave: Mm-hmm.
Chris: The pizza builder does not work without it. So, you're saying, "Oh, it's separation of concerns," but it's not.
Dave: Mm-hmm.
Chris: It's just separation of files arbitrarily.
Dave: Yeah. What you don't have, you don't have a JSON at the end of it. Maybe you do. Maybe you code it, but you don't. You have a bunch of divs that now look correct. You know what I mean?
Chris: Yeah.
Dave: You don't have an object or a model that you've been manipulating that you can then hand somewhere else, typically.
Chris: Yeah, then you have to remake the model at the end. Yeah.
Dave: Right.
Chris: You could say, sure. Is it possible to build this as a big ass form with select elements and stuff; then you submit it and then the server-side has equal code on the back-end that processes all that stuff, returns an error to a different URL that then says you have 11 toppings on the left side, so that's an error? Yeah, but we just don't do that anymore. It's just not practical. You don't want to write our applications twice.
Dave: Yeah. Well, and it would be so much easier. Well, there is a validator on one side. They're a billion-dollar pizza company, so they have to do that. [Laughter] Sorry. They're going to do that.
Chris: Yeah.
Dave: But it would be easier if we're not just kind of -- less like click a button and praying it goes across the wire correctly or through a bunch of testing or blood, sweat, and tears making sure it all works. That's just it. You just try to make sure it all works.
Well, that's where I'd say I think Petite Vue is very compelling just because of reactivity. That ability to have a UI that reacts to a little bit of state, that's awesome, and that's what Vue, that's what React does.
Chris: Yeah.
Dave: But Vue (Petite Vue, specifically) does it without ever NPM installing a thing, so it's so great.
Chris: Let's say, on this beautiful pizza builder, there are two buttons next to each other.
Dave: Mm-hmm. Yep.
Chris: I don't know what they are. It doesn't matter.
Dave: Quantity.
Chris: One of them has to have a space between that and the next button.
Dave: Yep.
Chris: By default, they don't because there's no user agent style sheet for margin on buttons.
Dave: Button plus button, yeah.
Chris: Yeah, so what are you reaching for? Do you select the first of the two buttons and apply some kind of margin to the side of that first one? Do you Flexbox it and use gap? Do you use grid to use gap?
Dave: I am on the gap train, flex gap train, man. Then if those two buttons kiss, they kiss, and that's an old browser problem now. New browsers, they don't kiss. It's beautiful.
Chris: Interesting. Okay. Okay.
Dave: Old browsers, they just give a little smooch. It's not the end of the world with two buttons kissing.
Chris: Yeah.
Dave: Whatever. It happens.
Chris: Yeah, the gap thing. I remember Adam Argyle said the days of even margin are limited because of how powerful gap is, and I've seen it. I just saw it yesterday. I saw a little demo that was real clever. It was just two blocks on two divs on top of each other. To just kick them out a little bit, what the developer reached for was display grid gap ten pixels rather than select the first one and kick a margin on the bottom of it.
The problem with that is you're either selecting the first one and adding the bottom on it or you're applying it to all of them, selecting the last one, and removing it. It's been a classic CSS problem whereas gap, you don't have to worry about it. It's just the gap in between them. Very nice.
Dave: Yeah. We (literally yesterday) had a client come and say, "Hey, I really like this component you built with three columns of content side-by-side." And they were like, "But it would be cool if I could control the gap on it."
Chris: [Laughter] No can do.
Dave: It was just like, you know, but totally, and it's like we already have classes for small, medium, large, or whatever. And so, we can just make the CMS say (with a button) it's small, medium, or large on that block. That's all we did.
I think, in Tailwind nomenclature, it'd be gap one, gap two, gap three, or whatever - however you want to do that. Or you could have dash add a gap colon ten px. You know? You could maybe even just, sure, write how big of a gap you want. [Laughter]
Chris: You like that the responsibility is the parent, not the child, too? Does that feel good?
Dave: I do.
Chris: Yeah.
Dave: I think it's -- I feel, anywhere, child content should not have to worry about its margin and spacing. There are situations where it will happen but, ideally, if it's at the meta big block level, it shouldn't have to care where it lives on the page.
Chris: Mm-hmm.
Dave: Inside the component, maybe, yeah, it does have to care. But outside the component, maybe it doesn't.
Then all these things, if it's just gap, right, the ability to make the Gmail style cozy, compact sort of vibes for modifiers for components is so easy.
Chris: Mm-hmm.
Dave: I mean it's one line of code, right?
Chris: Yeah.
Dave: You're setting a variable to just say, "Okay. All the gaps on this one are tiny," so there you go.
[Banjo music starts]
Chris: This episode of ShopTalk Show is brought to you in part by Retool for startups, so Retool (retool.com): remarkably good tooling for building admin tools, internal tools, and stuff.
Retool for startups is a special program that they're offering, so this is what they say. After working with thousands of startups, they've noticed that technical founders spend a ton of time building internal tools -- been there -- which means less time on the core product. So, we built Retool for startups, a program that gives early-stage founders free access to a lot of the software they need for building great, internal tooling.
The goal is to make it ten times faster to build admin panels, crud apps, and dashboards that most early-stage teams need, so they bundled together. It's a free year of access to Retool and then $160,000 of discounts for tools like AWS, MongoDB, Brack, Segment - you know, really popular tooling for building any kind of Web software, really.
Use your Retool credits to build tools that join product and billing data together into a single customer view, tools that convert manual workflows into fully-featured apps for your team, tools that help non-technical teammates read and write to the database, and so much more.
It's retool.com/startup. That'll get you to the form to apply for this. There's some criteria for it, like you're less than five years old and things like that. [Laughter] Not you as a person. The company. You have to be over five years old as a person, I'm pretty sure.
Check out the site. Apply. Join Webinars. All that stuff. Retool.com/startups.
[Banjo music stops]
Chris: I kind of failed in my segue because what I was hoping to sort of talk about is, like, so you need some space on the side of something. And I agree; Flexbox gap is sweet and that's definitely the way to go because then it will be right if you add four buttons, too, and all that. It's like future thinking.
Let's see. How can I think of another example then? Let's say there's H4, and it says sauce. [Laughter]
Dave: Yeah.
Chris: Then there's a plus button, and you're going to put it inside the same header - or something - because they should just be on the same line. It's going to end up in Flexbox again, isn't it?
Dave: Flexbox.
Chris: Dang-it. Yeah. [Laughter]
Dave: I call that. We have a -- I call it "action header," is what I call it. [Laughter] I have action tables and action header in my--
Chris: Okay, so let's say, though, that the plus button is pushed away from the word "sauce" all the way to the other side. What's your go-to technique? Do you do the auto-margin of sorts or do you do a space between?
Dave: I think my action header -- oh, I would do a gap there, too, I think.
Chris: But you can't force a gap to be like a pushing gap.
Dave: Yeah, but it's like whatever -- angle bracket first child or first of type -- whatever the right one is there. [Laughter]
Chris: Hmm. Okay.
Dave: You do flex grow one, so that'll always explode.
Chris: Oh...
Dave: Then you're little button over there.
Chris: And then a gap.
Dave: And then a gap.
Chris: Oh, so that's a third way. You get the spacing by forcing the first one to be as wide as possible.
Dave: Yeah.
Chris: Which works if there's no background on it or something.
Dave: Yeah.
Chris: But I usually avoid that just because I don't actually want you to be bigger. I actually want you to just have space. [Laughter]
Dave: Yeah.
Chris: It's philosophical at that point, almost, so there are three ways to do it. One of them is to take the children and add the space between in it - whatever that is.
Dave: Mm-hmm. Yeah, space between.
Chris: A line item or justify content space between, or something.
Dave: Yep.
Chris: That'll push them apart. Or you can select one or the other of them and do inline margin.
Dave: Yeah.
Chris: You could say -- on the first one you could say, "Margin right auto." On the second one, you could say, "Margin left auto." Either will work or both will work.
That's where I was trying to go with this. Let's say you chose that technique, or somebody else did, or something, and you were rolling with it. Would you write "margin right auto" or would you write "margin inline end auto"?
Dave: Hmm.
Chris: Logical property.
Dave: I'm not there yet.
Chris: Are you ready?
Dave: I'm not there yet.
Chris: You're not there? Interesting.
Dave: But I want to be.
Chris: That's more supported than fricken' Flexbox gap is, is the irony.
Dave: That's true. [Laughter] Yeah, that's true. I would like to be there because there's a lot of power. If you work on any enterprise stuff, the first thing you're going to have to do is build the Hebrew or Arabic version of the website, and those are LTR or, sorry RTL languages.
And so, you immediately hit this situation where all your margin rights and all your margin lefts didn't work - don't work anymore. Like everything is wrong and you can build -- and I've done this before, before all these things existed -- built a big damn pre-parser that flips all your margins and positions to right.
Chris: Sure.
Dave: You basically build a fake positioner utility or mix-ins in Sass or something like that.
Chris: Yeah.
Dave: And that's okay. That works but, man.
Chris: Certainly not as clean as inline properties. Let's say I convinced you, and you were like, "Okay. I'm going to do it." And you ship it, and it's fine because you're already depending on the gap, so who cares if this works or not.
Dave: Mm-hmm.
Chris: It would just kiss, right?
Dave: Mm-hmm.
Chris: Now you have one logical property. [Laughter]
Dave: I've got one in there.
Chris: In your whole app.
Dave: Yeah, I landed it. Yep.
Chris: How do you feel about that, because that's where I'm at? I'm starting to use these things and ship them to production because I'm like, "Eh, whatever," you know? But it's got to be 10% or less of all of the properties in the whole app. Is that groat? Does it deserve a refactor to just switch or, no, that's a waste of time refactor?
Dave: I wonder if it's a sprint and just see how many components you can get over to logical in one go, you know?
Chris: Yeah.
Dave: If that's the direction you want to go, that's the direction CSS is going, maybe you should just do it. You should just commit to it. You can maybe even linter against that, but I don't know. Here's a fourth heat. Can I put a fourth heat on the fire?
Chris: Yeah.
Dave: A little razzle-dazzle, diner's hotdogs or whatever drive-ins. You could do flex align-self flex end.
Chris: Oh! That's right. That's a fifth one, isn't it?
Dave: You could do another and that would be maybe the way I would want to do that particular situation because you're saying, "Place yourself at the end."
Chris: Being really specific.
Dave: You're not saying, "Margin yourself to the end."
Chris: That's true.
Dave: For me, that's maybe how I'd want to do that because, yeah, margins and the utility of margins is going down and down and down, honestly.
Chris: You know the problem with the margin too is that, yeah, it's a gap unless they happen to kiss.
Dave: Mm-hmm.
Chris: Then you need a margin on the other one or something because you already have auto on one, so you can't use that one. You've got to use the other one to make sure they don't kiss, or put some padding on it, or whatever. I wonder if gap works in that situation. Can you add a gap and an auto margin, and then the gap will prevent the kissing? Probably.
Dave: Hmm. I think so. Probably because a lot of times you use margin inside grid, and it's just like, "I don't care." [Laughter]
Chris: Yeah.
Dave: I mean you wrote that, but I don't care. You know?
Chris: Yeah. There are some funny circumstances where margin and padding are just irrelevantly different. It's a good segue, though. It's weird how many times we've said the word "kissing" in this podcast. That's got to be a record.
Dave: It's a new -- we need some saxophone, Chris.
[romantic saxophone music]
Dave: ShopTalk After Dark.
[Laughter]
Chris: [Humming music]
Dave: [Humming music]
Chris: [Laughter]
Dave: Any time we talk about elements kissing, one of us has to do the sax. Okay.
Chris: Oh, that would be great.
Dave: new ShopTalk rule. All right.
Chris: So, there are logical properties. Margin block end makes perfect sense to me. It's the block direction, which is (in our world) usually top and bottom.
Dave: Mm-hmm.
Chris: So, block end means margin bottom for like a right to left language -- or left to right - sorry.
Dave: Mm-hmm.
Chris: Fine, but it's funny how many of these properties, there's fallout, for lack of a better word, for everything else. There's inset and inset means top, bottom, left, and right. What about top? What if you just want to set top? What is that? Oh, it's inset block start, so there are a lot more words than top, but it makes more sense.
Dave: Mm-hmm.
Chris: They have fallout there. Then there's just other stuff, too. For example, I was working on scroll snapping. That's nice, right?
Dave: Mm-hmm.
Chris: I feel like it's almost underused at this point. I saw Scott Jehl put together a little table that had sticky--
Dave: Columns?
Chris: Yeah.
Dave: Okay.
Chris: Then he just threw scroll snaps on the columns and the rows.
Dave: Beautiful.
Chris: I was like, "Oh, nice." It's just like a little add-on to the table that was nice.
Dave: Yeah.
Chris: So, okay, there's that. But there are circumstances when you want to adjust scroll snapping's position, and there's no scroll X position adjust.
Dave: Offset.
Chris: Yeah. There's no offsets for it, which is weird, I think. But it's because -- it turns out there is, actually, because it's this more generic property that's used for scrolling anyway, not just scroll snapping, which is clever. I like that this exists.
There's a property called scroll padding and scroll margin. Those are great because I used to have this pretty popular post on CSS-Tricks that was like, "Let's say you have a fixed position header and then you use a jump link, like you jump to hash conclusion or something, and the page jumps down to that point. The fixed position header can just cover it, so you need to push down the page (somehow) so that it doesn't do that because otherwise, that's a very bad UX. Like, what's happening? The fixed position header is covering this thing.
We used to do all kinds of crazy tricks. We used to have a pseudo-element that's positioned taller than it.
Dave: Oh, yeah. I'm still doing crazy tricks. There's a way around it?
Chris: You just do scroll padding 100 pixels or something. Just as tall as the fixed position.
Dave: Oh, I hate this. Holy crap. Really?
Chris: Just do it, scroll padding, and it doesn't actually add padding. It just says when the element is scrolled to, then just have that extra space on the top.
Dave: On the body or is that anywhere?
Chris: No, it's on the element itself, so you put it on the H2 or whatever it is.
Dave: Yeah, yeah, yeah, yeah, yeah, yeah. Okay. Okay.
Chris: Yeah, but there's scroll margin and there's scroll padding, so that's why I thought of it because I don't think it actually matters that much in this case which one you use since it's just some space on top of the thing.
Dave: Yeah. Yeah, it's a number. Yeah.
Chris: Yeah, but then logical properties, I think, you don't have a choice here. If you want to add scroll padding to one direction, you have to use, so it's scroll margin inline start.
Dave: Oh, okay.
Chris: If you need left offset to your scroll snapping or something. And I had to do it the other day because I have scroll snapping. Imagine the CSS-Tricks interface after the top card, like on the homepage. There's a little thing that says, "Popular articles this month," or something like that. Then you can swipe through them, and they have scroll snapping on them, which kicks in at certain breakpoints.
But the way I just designed a little border around the edges of one of them (because I wanted to have this cool gradient effect), I just made a pseudo-element that sits behind the thing so it has a cool, gradient border. But that means that that pseudo-element is not really part of the box model. So, the scroll snapping kicked in. It snapped. It cut off one of the border because it doesn't know about the pseudo-element. That's just an absolutely positioned out-of-flow thing, and it cut off this left border, so I had to use scroll margin inline start of the width of that border to nudge it back over a little bit. I was like, "Oh, man. This is starting to get a little brain screwy, all this."
Dave: It's almost like any time -- well, yeah. If you do that thing. It's almost like any time you use padding, though, or margin, because you never want it to zip to the top of the heading, like if you do the anchor heading thing. You want the heading to ... a little love, right?
Chris: Oh, I totally agree.
Dave: It's almost like any time you specify padding or margin on any component, you'd almost want to also do scroll padding as well, right?
Chris: It's kind of a good point. Yeah. Yeah. Could you have a universal UA--?
Dave: Could you just do start scroll...?
Chris: Yeah.
Dave: Look at us.
Chris: Yeah.
Dave: Jinx.
Chris: Yeah.
Dave: Personal. [Laughter]
Chris: I think you'd maybe regret it as a universal selector only because then every single time you try to do scroll snapping anywhere, it's going to affect that.
Dave: Yeah.
Chris: But having H1, H2, H3, H4, H5, H6 scroll padding block start ten pixels or something.
Dave: Even 1M or 1REM would be huge, right?
Chris: One REM. Yeah, it just would look a little classier, I think.
Dave: Yeah. Huh.
Chris: Yeah. Not bad.
Dave: Oh, yeah.
Chris: We just changed the Internet.
Chris Enns: This episode is brought to you in part by me, your ShopTalk Show editor Chris Enns. Rather than me telling you all about what I do and how I can save you time editing your podcast, I thought I'd let my clients talk about the thing they most enjoy being able to do since they hired me to edit their podcast.
[Film leader blip]
Male: I notice that there's sound effect to start and a soundbite from my guest, so we'll pause for that. Three. Two. One.
Chris: This is going to be a tough one for you, Chris Enns. Sorry about that. Do what you can.
[Film leader blip]
Dave: Okay, I'm going to dive into Web components. I just think it's -- [dog barking] That's a good sign. [Dog barking] We'll let that pass, and we'll edit this out.
[Film leader blip]
Female: Good luck, Chris. Aren't ya' glad I'm back?
[Film leader blip]
Female: Clap-on, Chris.
Male: Chris is who edits the podcast. Yeah, it goes really poorly.
Male: This always goes perfectly. We've never messed this up.
[Film leader blip]
Chris: It's just the way it is, but you sound good, Dave. I wouldn't worry about it too much. Plus, we have the masterful Chris Enns on audio engineering.
Dave: I flew him down from Canada to sit by me. Oh, and a mixer. [Laughter] He's working on a mixer, live, right now.
[Film leader blip]
Male: And... Oh, man. Chris, just erase that last part. [Laughter]
[Film leader blip]
Male: You know Chris edits this thing too, right?
Male: He does.
Male: He's got a heavy hand with his edits. He makes us sound really smart.
[Film leader blip]
Male: Chris, let me just find this word.
[Film leader blip]
Female: Sorry, Chris.
Male: Yes.
Female: Chris is our editor.
Female: Whenever we're just frustrated with something, we just blame Chris for it.
Female: [Laughter]
Male: Perfect.
Female: Just like our imaginary friend.
Male: Imaginary. Yeah, blame Chris. That's good.
Female: [Laughter]
Female: I'm so sorry, Chris. We love you. [Laughter]
[Film leader blip]
Male: Chris, we're going to now have to make this [laughter] an explicit episode.
[Film leader blip]
Male: Chris, have fun with this episode. Ha-ha-ha. [Laughter]
Male: [Laughter] Yes.
[Film leader blip]
Male: Chris is so good at editing that [laughter] it just doesn't make sense for me to do it. Yeah, we'll just send it to him.
[Film leader blip]
Male: No worries. This is totally normal. I keep Chris, my audio editor, super-super busy. He makes us all sound very intelligent, so we have nothing to worry about here.
[Film leader blip]
Female: Our editor will figure it out.
[Film leader blip]
Female: I would tell Christopher Enns, [laughter] our sound guy, to take this out.
[Film leader blip]
Male: Nope. That's not the way it works.
David: [Laughter]
Male: Um... Chris, will you go back to David and edit that part out? I'm going to start over.
David: [Laughter]
[Film leader blip]
Male: Am I pink or you pink?
Male: Yeah.
Male: Oh.
Male: You're pink. [Laughter]
Male: [Explicit] I totally [explicit] that all up, didn't I?
Male: [Laughter]
Male: It doesn't matter. That's why we have Chris.
Male: My bad. Chris, sorry about that.
Male: Yup.
[Film leader blip]
Male: Sorry. You'll have to cut this out, Chris.
[Film leader blip]
Male: Delete everything we just said, Chris.
[Film leader blip]
Male: I just told Chris we'd edit Jason out, but I'm going to go again.
[Film leader blip]
Male: Thanks, Chris. You're cool. Bye!
[Film leader blip]
Chris Enns: So, whether you've got a weekly show that you want help with or you want to do a ten-episode run of an idea you've got, get in touch with me, [email protected].
Dave: Would you ever--? Here's the deal.
Chris: Would you ever--?
Dave: [Laughter] This is a good - whatever. Okay. Your page, right, is a content sandwich. You've got the bun is the navigation at the top and the footer is the bottom bun.
Chris: Yep. Mm-hmm.
Dave: You've got the meat in the middle, right?
Chris: Yep.
Dave: Some pickles sliding out everywhere in the form of cards. Cards are always pickles.
Chris: [Laughter] Yep. Website sandwich.
Dave: [Laughter] They're delicious, but the ruin a sandwich. Yeah, so you've got your content sandwich.
Chris: They ruin a sandwich.
Dave: It falls apart. Integrity issues, right?
Chris: Okay.
Dave: Anyway, you have your website sandwich, and you have the meats all stacked up.
Chris: Yep.
Dave: Or tofu, falafel, whatever you want to do.
Chris: Mm-hmm.
Dave: Would you ever scroll snap on those sections?
Chris: Oh, yeah.
Dave: Almost like when you slide through the side, it's like a PowerPoint.
Chris: Sure.
Dave: Would you just universally apply that, maybe?
Chris: To your cards, yeah. Why not?
Dave: Like in your big section tiers of your website.
Chris: Well, even wider than that? Yeah, maybe.
Dave: Yeah. You would?
Chris: It's pretty chill these days. It used to not be chill. You know?
Dave: Yeah. Yeah. Yeah.
Chris: Browsers used to really kind of forcefully snap to it. Then a lot of times people put a polyfill on and the polyfill was really janky. You know? Like if you're 51% of the way through the next element, it'll just grab your scroll and go [barf] and grab it to the top. You know?
Dave: Yank it down. Yeah.
Chris: That's bad, but I find -- and this is Chrome, Safari, Firefox -- that it's chill. You know?
Dave: Mm-hmm.
Chris: Like if you're close, it'll grab it and kind of pull it up. It's like they kind of got the UX of it right, finally.
Dave: Okay.
Chris: And so, I think kind of liberally sprinkling it out to stuff--
Dave: It might have some cool effects.
Chris: --start to feel good. Yeah.
Dave: Yeah. Nah. I actually tried to use it multiple times and I did not have success.
Chris: Mm-hmm.
Dave: But on the latest project, I finally was like, "Okay, I'm using it here," because I have a little horizontal slider that was asked for and I want it to make sure it snaps. The trick was, you put scroll snap on the parent and then, on the child you put scroll snap--
Chris: Start or something.
Dave: --position mandatory X or whatever. Yeah.
Chris: It's changed a bunch, too.
Dave: Yeah.
Chris: I think, in the end, it's easier, but that definitely went through some very major syntax changes.
Dave: Yeah.
Chris: If you're doing it now, make sure you somehow seek out the best.
Dave: Scroll snap align start, so that's what I put.
Chris: Mm-hmm. You used to have to tell it how wide the thing is. You used to have to be like, "Oh, these cards are 300 pixels wide," so you have to give it that information, and that's dead.
Dave: Right.
Chris: I don't think you have to do that.
Dave: Thank God because that was a pain in the butt. [Laughter] But yeah, scroll snap type on the parent, and I did X mandatory or inline mandatory, I guess. And then scroll behavior smooth. You want it to be smooth, right?
Chris: I don't even think you need that.
Dave: Yeah, because I had WebKit overflowing scroll touch, and I don't think I need that anymore.
Chris: You do -- oh, really? I thought you do need that one.
Dave: No, you don't need that one.
Chris: Oh, my god. You don't need that one anymore?
Dave: That was deprecated in Safari 10.3 or some crap. No one told me, but it is.
But then on the children, the child, you need the snappable object. You need scroll snap align start.
Chris: Yeah and start. See. That's a logical world. Pretty cool. I think what's moving the needle on these is that it works in the desktop browsers, too, which, like it or not, we tend to develop websites in desktop browsers. When it just didn't work at all and desktop browsers were kind of like, "Eh," you know?
Dave: Right, right, right.
Chris: It was less fun to develop them, but now it's kind of easier.
Dave: Yeah. I think -- so, we have that secret Paravel repo that has a bunch of components kind of rebuilt in it that we just kind of reference and copy/paste from project to project to project. I think I may -- and I may have an opportunity here -- just go through and update this and get it all modern, up to snuff, and put it all--
Chris: Oh, yeah, logical properties, scroll snapping--
Dave: Logical properties.
Chris: Scroll padding.
Dave: Flex gaps.
Chris: There you go.
Dave: All the scroll stuff. Wouldn't it be cool? I was even thinking, wouldn't it be cool -- wouldn't it be cool if you could get a "can I use" linter in the browser, like in your CSS file? I use this inline linter plugin that'll put a little comment out to the side in VS Code like, "Hey, you don't--" or, like, "This has an error on line 3. Style Lint hates this," or whatever.
Chris: Yeah.
Dave: Wouldn't it be cool if "can I use" would go "Hey, you just typed WebKit overflow touch."
Chris: Yeah.
Dave: You don't need that anymore. Wouldn't that be cool?
Chris: [Laughter] Yeah.
Dave: If there was a "can I use" linter.
Chris: Like a warning.
Dave: Yeah, like, "You wrote this. You wrote gap or flex gap," but this would be hard to detect, but like, "You wrote gap in a Flexbox. That's actually not supported in every browser," or something. It just gave you, "This doesn't work in IE." That would be kind of cool. [Laughter] Just little hints, like little hints in your browser or your editor as you're writing. I think that'd be a cool idea.
Chris: Yeah. Yeah. I think dev tools has toyed with that a little bit, like giving you messages in dev tools.
Dave: And maybe you set your threshold, like I only care about 80% or the last 2 browsers or whatever. Maybe your browser.json controls this, but you could just be like, "I don't care about IE 11, so just tell me every property I don't need for IE 11." I don't know.
Chris: Yeah. Yeah, I know you're thinking mostly of Safari. [Laughter]
Dave: Safari. Safari is one, but even if you type -- yeah, I guess it's back to Safari. But it's like if I use some property, like what's the new one? Accent color, right? Which is super cool. If I used accent color, could it tell me this is only supported in Chrome or only 20% of browsers support this, or something like that?
Chris: Yeah. Then it's interesting to think where is the tool, though? At first, you're like, "Oh, it'd be a website." Then we're like, "Well, what if it's in dev tools?" Then it's like, "Well, what if it's in VS Code?" or whatever.
Dave: Yeah, well, that's where I'd like it.
Chris: Yeah. It's interesting to think where the train goes.
Dave: I don't know. I don't know. It wouldn't have to hit the "can I use" API every single minute, but maybe it could - I don't know - download a list, a support list every once in a while, periodically, or something, and keep a cache or something.
Oh, I just use break word, right? Word break, break word. [Laughter] Dumbest named property.
Chris: Oh, my god. That's -- you're going to break your brain because there are like 15 of them that are similar.
Dave: Break all. Yeah. It's "word break, break word" is what you want, but I was like, "Oh, no. Can I even use this?" I was just pouring sweat. I need it to fix. The client was typing in the number Google, where it's like one hundred zeros on a one, you know. Of course, it's breaking the content layout. It's breaking the whole grid, and I was like, "I need that word not to do that," or else the whole layout is trashed, right?
I just was like, "I will set it. I'll put it on break word," and that worked. And it's generally good support, but I would have liked to know that as I was authoring without having to go Google this one property. You know, "Could I just do break word?"
Chris: Hmm.
Dave: Like accent user, accent color - zero percent. Break word--
Chris: Yeah, it's in this different category, though--
Dave: --99%. [Laughter]
Chris: --because it's new and the trajectory is that it's going to become more supported.
Dave: Mm-hmm.
Chris: That's just something that we're used to, as Web developers. That's normal and okay and correct and the correct trajectory of things.
It's reminding me of this; Jeremy Keith chimed in on the alert confirm deprecation stuff, which is a little kind of ongoing hot drama that is not over. [Laughter]
Dave: Oh, no!
Chris: Well, you know, it's just kind of wait and see at this point, but we'll see.
Dave: Yeah.
Chris: But he writes, "The onus is not on Web developers to keep track of older features in danger of being deprecated. That's on browser makers. I sincerely hope we're not expected to consult a site called canistilluse.com."
Dave: Mm-hmm.
Chris: Which is great. Then Jim Nielsen, I think, actually made that site.
[Laughter]
Chris: So, you can go check out canistilluse.com.
Dave: Is it just a graveyard? It's a graveyard of alert. [Laughter]
Chris: One -- [Laughter]
Dave: Oh, Jim. This is good.
Chris: There's one thing on it. It's just the alert API.
Dave: Just one thing. It's great.
Chris: R.I.P. But it's a good point, you know. It's like that would suck if all of a sudden we're constantly on our toes because features that we use on production websites can get ripped out from under our feet. That would suck in our day-to-day work, but it's even worse for historical Web. There are lots of sites -- definitely most sites on the internet -- that are not worked on anymore. They're just there.
Dave: Yeah. There was a smidge of hubris in the, like, "Well, people have to go update." It's like, "Buddy, I don't even have the FTP credentials for that thing."
[Laughter]
Dave: It's gone. You know?
Chris: Right.
Dave: No one knows them. We're in--
Chris: It's better for the Internet for every tutorial to be updated to use async/await instead of alert, or something. You're like, "Async/await and what?"
Dave: Dialog? Uh... nope.
Chris: Yeah.
Dave: Psych!
Chris: Anyway, they reached out to talk to me about it, and I'm just remembering just now that I have to do that. But it's kind of like, do I want to? Because I feel like to take that meeting means I've got to prepare. I've got to have my arguments together. I want to tell them what I really think. And it's like that type of work for me (like it is for you, Dave), I charge bucks for that.
Dave: Well, I do it all for free. [Laughter]
Chris: And now I'm giving it to Google.
Dave: [Laughter] Yeah, they should pay. I don't know. I do it for free in Open UI and Web Component Group, but you know it's--
Chris: Yeah, if it helps the Web, that's cool, but I don't know.
Dave: Yeah. I've decided that's my open-source contribution, but yeah. It's like CodePen. You have to do an investigation, right? You have to see how many Pens would be affected by this to come up with some datapoint that's like why this is kind of bad news for you or "Cruise your email. Look, we've got 800 reports. That alert didn't work," or something. Like, "This caught everyone by surprise." It's just kind of a bummer, and it's already costed you money in support tickets.
Chris: Yeah.
Dave: And digging that up and stuff like that.
Chris: There's one. To me, this comes down -- like, I hate to be too reductive. I don't want to be reductive. This is complicated, but there is a beacon of this alert drama that annoys me and has just not been answered at all (in my opinion), which is, if the biggest problem here is abuse because a child iframe can pop up an alert and it looks like the parent did it, it looks like any other page did it, the iframe could be kicked off the page or one pixel by one pixel, and it can still do that. It'll make an alert, and it looks like the parent page did it. Then don't do that. Make the alert UI have to be confined within direct of the iframe.
Dave: Yeah.
Chris: A) That makes more sense anyway because, when you're working on a CodePen or whatever, don't you want to see the alert in the preview? Doesn't that make sense?
Dave: Mm-hmm.
Chris: If that solves the whole thing, then what are we doing here?!
Dave: Right. Well, and I guess because it stops the main thread of the whole app, so an invisible iframe could still stop the main thread, but--
Chris: Does it?
Dave: --maybe it doesn't stop the main thread.
Chris: But aren't browser tabs -- they are different threads. Web workers are different threads.
Dave: They're different threads.
Chris: So, why isn't iframe the same thread as the main thread? Is it?
Dave: I don't know. I think it is, but--
Chris: Oh, you think it is.
Dave: Yeah.
Chris: I always thought it wasn't. Okay, well, then that does come up the works there, doesn't it?
Dave: But I agree. It's just like -- I don't know. It just seems like it should -- yeah. I don't know. They've messed it up or maybe they need to delete it, but maybe there's a way that you could do it, like third-party iframe, and it would show up in the third-party, you know, inside the iframe or whatever. Iframeable alert or something like that. I don't know.
Chris: Yeah. I mean it's almost worst to not. Like it changes the whole thing. If it stops the main thread and so there's a one pixel by one pixel iframe that has an alert in it that you cannot close because you can't see the alert and it has paused the main thread, that's worse.
Dave: Yeah. There are so many situations where you'd want to do that or where an embeddable thing, you want that to take care of it like Ticketmaster or Eventbrite or something, inside my frame. If they - whatever - tried to DDoS the system, I want it to throw an alert that's like, "Hey, you can't do that," or something. There are situations where I want it to work.
Chris: Right.
Dave: It's not just CodePen that's affected. There are probably a dozen--
Chris: No, and that's why when I take the meeting, I can't -- I don't even -- I'm not even interested in talking about it from that perspective. Not really.
I'm going to, of course, secretly make sure that those interests are there somewhere, but I don't want to be like, "The Web is CodePen," because that's what got us into this mess was one actor pretending like they're the only needs that matter.
Dave: Or maybe if a deprecation is going to happen, maybe they need to reach out to popular CSS blogs and popular code blogs, JavaScript podcasts and say, "Hey, this is being deprecated. We could pay you to talk about that," or whatever.
Chris: Yeah. Sure.
Dave: I may be paying this to myself.
Chris: Or at least just ask.
Dave: Just write the dang article.
Chris: Right.
Dave: Just say, "Hey. Heads up, everybody. This is important."
Chris: [Laughter] At least just run it by Rich Harris. If you're trying to avoid--
Dave: I mean, if we could all funnel all decisions through Rich Harris, I think the Web would be all fixed up.
Chris: Yep.
Dave: No presh -- no pressure. All right. Well, hey. We should probably wrap this one up, huh? Unless you've got anything else.
Chris: Sure. That's fine. Yeah.
Dave: All right. 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 Twitter, @ShopTalkShow, for tons of tweets a month. And join us over on the D-d-d-d-discord, patreon.com/shoptalkshow. We'd love to have you in there. It's a romping good, fun time. Chris, do you have anything else you'd like to say?
Chris: ShopTalkShow.com.