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 websites and Web design. I'm Dave Rupert and with me is Chris Coyier. Hey, Chris.

Chris Coyier: That's me. Lovely day for a ShopTalk Show, I'd say. We have a very special guest. I believe the guest who has been on ShopTalk Show more than anybody else, so probably needs no introduction, but I will introduce her anyway. It is the wonderful Jen Simmons. Hi, Jen. How ya doin'?

Jen Simmons: Hello.

Chris: Hey. And the last time you were on the show probably was pre-Apple, and now there's, as you said, been a whole pandemic. There's been some big personal and professional changes, one of which is that you are now at Apple.

Jen: Yeah. I'm a Web technology evangelist on the WebKit team, along with the Safari team, which has been pretty fantastic, actually. I'm really having a great time there. Yeah.

Chris: I feel that coming off you, your energy. Perhaps not so coincidentally after you being there, it feels like a different Safari, a different WebKit because of, in a sense the velocity of shipping new stuff, which lines up pretty nicely with the velocity by which Web standards, front-end Web browser stuff, is evolving. There's just a lot happening, and Safari is keeping up and leading it in some cases. That's pretty sweet to see for us Web developers.

00:01:46

Jen: Yeah. I'm so glad to hear that because we've been working really hard. There have been seven releases since Safari 15.0 came out. That's what we want everybody--

That's the effect we want to be having is that there's just a lot of new stuff coming out. It's coming out in Safari as well as other browsers.

Chris: Yeah. decoupled releases. Is that fair to say that Safari releases kind of roll out independently of the OS, which I'm not sure how new that is, but it feels significant.

Jen: Well, the change is that we changed the way that releases are being numbered. You'll see this second -- the first digit after the decimal point is now changing each time Safari comes out. It's Safari 15.1, 15.2, 15.3, 15.4--

Chris: Yeah.

Jen: All the way up to 15.6 this year. Then 16.0 is coming out this fall, so that's the biggest change, which really makes it much more possible for everyone to have a lot more visibility into what's going into each one of those releases of Safari.

For instance, you can go to caniuse.com, and the data there is more accurate. There are blog posts and release notes coming out every time there's a new version of Safari, this sort of tenth-of-a-decimal-place version numbering.

Chris: Yeah. It certainly makes it easier to talk about, doesn't it? Like, "Ooh, what's in 15.3?"

Jen: Right. Or, like, "Oh, look. 15.5 and 15.6, there were some cool things that shipped." Yeah, it's good.

Chris: Yeah. I mean even for a podcast it's nice, so thanks. [Laughter]

We have a whole table of contents here that I'm not going to share with you upfront because there's a lot to get through. That's the point, though, of this show. We're going to roll through some of the stuff that you may or may not know about what's landed and coming in Safari, and there's a lot of it. So, we're going to roll with the breadth over depth on this stuff kind of on purpose for the show, as we planned, to just show you, "Oh, my God. All that is in Safari now? That's great."

The bulk of it is in CSS land - near and dear to our hearts and listeners of this show, I'm sure. We're going to start in CSS land a bit. Why don't we start with just a massive one? that's that Safari is shipping container queries.

00:04:03

Jen: Yeah. Container queries were the number one most requested thing in CSS for the last several years.

Chris: Ever. Yeah.

Jen: Yeah, so it's right now in Safari's 16 beta. You can try it out. Grab yourself a copy of the beta software or download Safari 16 beta itself, alone, and try out container queries.

It's coming. I know it's also been implemented in Chrome. I think it's still behind an experimental flag, so you could try it out there.

Container queries, the thing (for anyone who doesn't know what's been requested for so long) is that you can -- you know media queries give you the ability to write conditional CSS that happens or doesn't happen based on the width or height or whatever, but mostly the width of the viewport.

Chris: Yeah.

Jen: Like the window. But container queries gives you the chance to query a container instead of the whole entire viewport, so you can write a single component and put it in many different places. Just that layout code for that component can sort of morph around or typography or whatever (color, even) can change based on the size of the container that something is inside of.

Chris: Which is huge, right? There's always been that disconnect between, like, yeah, but this little component. The styling decisions I want to make aren't necessarily attached to how wide or whatever else the browser window is.

Jen: Right.

Chris: It could be in a really narrow column even though the screen is super wide. That's been so annoying for so long that it's like, heck yeah. We can finally do this. It's so cool to see that ship. Just outstanding.

00:05:42

Jen: Yeah, and one of the things that maybe folks aren't expecting is that you actually have to point to the container, so none of the browsers are going to magically know that this particular element is the widget or the component, you know, the edge of the component and that this particular element or div or a side or whatever is the sidebar by which you want it to measure from.

You have to be specific about that. You have to say, okay, well, the container that I want it to measure, I'm going to put a container class on it, so .container. Then on the .container, you'll say something like container type inline size, which is kind of like the width in most writing modes. And you can name it.

Chris: It's kind of like a prerequisite to make it work, right?

Jen: Yeah, so you have to point at the container by telling it what kind of container you want, and also, if you'd like to give it a name, you can give it a name, which can be really handy. Then you use the @container rule, and you can write some conditional code - a lot like before.

If you want to use the name, you can put it there and be like, @container foobar with greater than 450 pixels.

Chris: Yeah.

Jen: Then you can write your code for your component and such underneath that. So, it's a little bit different than all the proposals that have been floating around for years is that you do have to actually point at a container. It's going to be super powerful and really helpful.

Mostly, folks have asked me, like, "What kind of difference does this make to everyday people who use the Web?" It's like, hmm... uh... nothing. I don't know.

Really, it's a developer convenience. It means you get to write much more compact and efficient code and reuse that code in many, many, many more places, which means you'll free up some development time to go work on something else or to be more consistent in your code. The site will probably be better for it. But really, the heart of why it's exciting is because it makes it easier for front-end developers to write their CSS.

Chris: That's a good point. It's a developer-facing thing.

Dave: Well, I just feel like people don't understand. It's like the Thanos snap for every front-end bug ever.

[Laughter]

Dave: Because just so many problems come from, like, okay, but when I'm here and then, oh, wait, this page has a sidebar. Okay, now it's different.

Jen: Yeah.

Dave: This fixes so much. Thanks for all the work. I know hundreds of people have been involved, but just the work on this has been amazing to see and so I'm very happy. This is a long-wanted feature.

00:08:10

Jen: Yeah, and my hope is always, hey, if you do get fewer bugs, especially layout bugs, and you have some time freed up, you could be more creative. You could do something different. You don't have to do the same layout that everybody else has been doing for the last ten years.

You could do something really amazing now that something amazing isn't hair-pulling out hard to do. It's like, oh, it's actually not that hard to do.

Dave: Well, and we always had the viewport, right? Like @media and querying the viewport. But that was always kind of a dumb proxy for what you actually meant, and now we can kind of - I don't know - expressive. We can say what we mean.

When the container, when the parent of this thing is this big, do this thing. That's--

Chris: You'll actually do it. I think that's what's interesting is that there was interesting JavaScript-y ways to get that done. Everybody was like, "Yeah, that would work in JavaScript," and nobody did it because it just--

Jen: Well, because JavaScript for layout is always slow.

Chris: Yeah, it's not ideal. I'm sure there were interesting ways you could do it. Besides, because of how popular JavaScript frameworks are, that was mitigated in some way because layout didn't happen until the JavaScript executed anyway, so you could avoid some jankiness, and still, nobody did it.

Dave: Well, it's like I'm going to solve my UI bug by introducing 10,000 JavaScript bugs. No thanks.

Jen: Right. [Laughter]

Dave: Yeah.

Chris: [Laughter] Right. People are going to do it.

Jen: Well, and what's exciting -- I mean I think what's really exciting is that right now we're getting some very mature tools. I should say some very powerful tools to make CSS more mature, to sort of up the ante on how powerful of a programming language it is so that you can use CSS for things where CSS is the appropriate tool and you don't have to go and use JavaScript in order to get the kind of power that you need.

In fact, several of the things that we have on this list that you were referring to, Chris, like the first set, I feel like this year is really a year where there's a group of things that once we finally wrap our heads around them and use them constantly and we kind of look back - whatever - eight years from now on the code that we used to write, a radical departure into how you architect your CSS code.

Container queries is part of it. Then cascade layers and :has, which we can talk about next, are part of it. Then in the future, we may be getting scoping and nesting. I feel like when you put all of those things together, it's like, "Oh, we're going to -- yeah, we're going to totally change the way that we structure our code and the way that we--"

Chris: Yeah. It's going to look a lot different, but don't you think it'll be more understandable? It's like power. It's a kind of power that ends up making things simpler and more understandable. It's not power at the cost of it also being more complicated.

00:10:58

Jen: Right. It doesn't make it more complicated, but it does make it different. But I think the mental model that you can express in your code is a more advanced mental model, which will make it easier than the alternative, which is using a more basic mental model expressed in the code but needing to do something advanced, so then it starts to get kind of a little bit spaghetti-o's like you don't know what's going on inside your code.

Chris: [Laughter]

Jen: It's hard to read. [laughter]

Yeah, you can make much more readable and code that actually makes sense. But in order to get there, we have to learn these new concepts, and people are going to have to invest some time in rethinking, like, "Oh, yeah. You know I used to always think about it in that other way. But now this new way. Yeah, yeah, I'm going to start. I'm going to start using the new way because it clearly maps more closely to what we need and it's clearly better."

But yeah, it's a change.

Chris: Yeah.

Jen: Like responsive Web design was in the first place, right? Responsive Web design came along to replace fixed-width design. That was a big change. I feel like now there's another big change.

Again, it doesn't really have necessarily a lot of impact on users, but it does totally impact architecture and developers of CSS.

Chris: Yeah. Yeah. Those things are related - in my opinion, anyway. I know people--

Ultimately, what users experience is what we're trying to build for, but DX matters - personally.

I would say -- yeah, go ahead, Dave.

00:12:23

Dave: I think it's hard to say what it's going to do for users, but I think we can already kind of predict. If it's easier to express more different layouts and creative coding, then that should happen. I think about writing grids. It was kind of hard to write a responsive grid, so you got four columns. Sorry. That's all I can do. [Laughter] I'm doing four columns, and they break to one at 800 pixels.

Now we have CSS Grid, and columns are effortless, right? Now we can just -- that's another thing Jen did [laughter] or had her hand in.

Chris: [Laughter]

Dave: But you know, doing grid is massively efficient and I can just sprinkle them wherever I want. And it's amazing.

Jen: Yeah.

Dave: I feel like now we've solved a big piece with layout, and now we're solving and even now the micro pieces be better inside the layout they're in.

Jen: Yeah.

Dave: I think it's going to be cool.

Jen: Yeah. Faster and fewer bugs is always amazing for users. Sorry. I don't mean to deny that isn't -- yeah, yeah, yeah.

Dave: No, I mean I was looking at a grid system I'd made. We used to ship 20K of CSS just for a grid.

Jen: Oh, yeah. Right.

Dave: Just for a 12-column or 8-column, 3-column grid. Now none, zero, I mean one line, like eight kilobytes for a grid. Not even kilobytes; eight bytes.

00:13:54

Jen: Let's talk about cascade layers.

Dave: Yes. Let's go, because I don't understand.

Chris: Can I do one thing real quick? I want to make sure when people are listening to this, there's always that risk that people are like, "Ugh! It's a podcast, but they're talking about these future things that I'll never be able to use." That really hangs on for a while.

I will say that Safari 16, you said fall. I mean I know you can't be quoted on the time or whatever. That's fine. But we're getting it, and it's coming in 16, and you can already play with it in shipping Safari now, so it's not a pipedream.

Chrome is a similar story. It's going to drop sometime in August, I think, theoretically, when their version of it drops. But, yet we don't hear anything from Firefox, so you'll have to decide how important that is to you.

But I will say container queries specifically is polyfillable, at least most of it is. I have a little side project that's using it now and it works fine. It's a really decent little polyfill. So, it is one of those features that it's like you can put this in your toolbelt. It's real.

Dave: And progressively enhanceable. They get the mobile layout if they don't -- [laughter]. You know? You can do that too.

Jen: It's good to hear that the polyfill works and is fast enough and all that stuff.

Chris: Yeah, it does. Yeah, it's fine. I mean there is -- yeah. Let's not dwell on too many details. I'd rather have people know that things are possible now and being in the two biggest browsers is a big deal.

You wanted to drag us towards cascade layers, which is absolutely fascinating. Part of this backstory that I would love to hear more from you about is that part of it came from a response to CSS in JS, this whole phenomenon that happened of people wanting to bring their styling into JavaScript, which is, of course, there's lots to say about. I did not realize that its origin came from that, conversations around that.

00:15:41

Jen: Yeah. I mean I remember. It feels like a long time ago now, but it really was just a few years before the pandemic. I remember going to a lot of conferences, and this idea of, "Oh, CSS is so terrible, and I hate it. Let's just put everything in JavaScript. Let's try to get rid of--" It just felt like people were trying to destroy CSS by using JavaScript instead. That's probably not accurate, but I remember I personally--

Personally, I was just a little bit worried about it. Then I realized, well, there must be a good reason that folks are so grumpy and so frustrated. There must be good reason that they're bringing out big hammers to try to do something. I wondered how much it was because folks were struggling with the cascade.

I was talking to Miriam Suzanne about this pretty depth (now, maybe three or four years ago), and she had some really good insights about, like, "Well, if you are using a JavaScript framework to create all these components and the components are all loading in random order, no wonder you're frustrated with the CSS cascade," because the cascade is completely dependent on the order of the styles in order to have the effect that you want to have. We were talking, talking, talking, and she had this insight into, well, there's this thing in CSS (from the very, very beginning) called origins where the user agent styles are in one origin, like the default styling that any browser has. The user styles, which we kind of don't think about or talk about at all today, but there used to be, back in the day, browsers had a way where the user could write their own styles and stick them in the browser, and the browser would use that styling to override the UA styles.

Then author styles -- author being the W3C's word for people who write the code for websites, front-end developers, webmasters, Web developers, whatever we've called ourselves--

Chris: Yeah ... masters.

Jen: And that the author styles would always override the user styles, and the user styles always override the user agent styles. It doesn't matter how specific or not specific any of that code is. That someone who is writing the browser style sheet could -- I mean nobody has, but the could -- use an incredibly hot, like very specific, powerful selector with multiple IDs and a whole bunch of classes - or whatever. And that doesn't matter because even the weakest author style is always going to beat the most powerful user style.

Chris: This is the fascinating moment to me is that this has always been true. We just never really thought about it in this way.

In my mind, I was always like, "Yeah, there's user agent styles, but they're really weak, but they're only really weak for two reasons. One, they get loaded first. Two, even if you peek in there, the selectors that people used are super, super light.

Jen: Right.

Chris: But it's actually not -- that's not why they're weak.

Jen: Right.

Chris: They're weak because they're on this secretly weak layer.

00:18:37

Jen: Right. I didn't know this either and so then important -- because we all sort of knew that as front-end developers. Okay, if you're trying to write some CSS and it's not applying, and you aren't quite sure why, and then you realize it's because the selector that you're writing is weaker than some other selector and you need to override that other selector.

Chris: Yeah.

Jen: But either you don't have the ability or you don't have time or you just don't feel like detangling all your code, you just throw important at it because then it's just going to beat the other one. I just thought, well, important beats--

I had a very basic understanding of how this works. But the truth is that important styles are in a series of layers that are in the opposite, that happen in the opposite order of the non-important styles. Important author styles beat important regular author styles, but important user styles beat all of the author styles, important and not important. And important UA styles -- so, if somebody writes an important UA style selector -- which I don't know if anybody ever has, but if you open up a UA style sheet and if there was an important selector in there, it would beat everything else completely.

And so, that idea, that sort of -- Miriam and I were talking one day, and it was like -- she was like, "We could give the ability to authors to create their own layers, their own origins (using the older terminology)."

Chris: Mm-hmm.

Jen: It was like, "Yes! That would be fantastic." So, we talked about it. I presented at the CSS working group. She joined the CSS working group and, two years later, it shipped in all the browsers.

Dave: Wow.

Chris: That's nuts. Man, there's a lot to unpack there. I'm curious, though, what the--

I don't know. Here's a simple story is that when you're writing -- you're tasked to make some changes to a website, like you're applying a theme to it or something. One approach to it (assuming that you can just use this new technology) is that you put your new stuff in some highest possible level layer. Then the CSS that you write in there, you get to totally wipe away the idea of specificity in your mind because whatever selector you use to grab onto something, it just automatically wins because it's the highest layer.

I don't know if that's the story you want to tell here, but that is appealing to me a little bit.

00:21:01

Jen: No. That's one of the use cases that we pitched to the CSS working group was, "You know what a team could use this for is to sweep all the older stuff into a junk drawer and then override it with their new, beautiful design system or organized CSS or their new rules," whatever it is, like, their new organization.

Chris: Mm-hmm.

Jen: Because you know you want to get rid of the old technical debt, but do you really have a big enough team and the time to just refactor everything? That doesn't come along very often. It's like, well, you could just sweep all that stuff (no matter what the specificity is) into its own layer and make it, yeah, a weaker layer and then start clean with a better architected set of styles.

Chris: Oh, nice. I'm glad. That's cool.

Jen: Another use case would be, say you're using a CSS framework. There are a bunch of popular ones. Bootstrap, of course, is one of them. There are many.

Often, or over the last decade or whatever, frameworks like that have worked hard to use very weak, specified CSS, and then your custom styles for your website have to be stronger. But in this kind of world with cascade layers, it's like, "Well, the folks who created that framework could use whatever kind of selectors they want to. Then your team (building a website) could put that framework into a layer and make that layer kind of weak. Then you could write all kinds of overrides and put them into a layer that's stronger. You wouldn't have to worry about the specificity of those two things because you know which style is which.

Chris: Fascinating! It changes "best practices" in some way.

Jen: Yeah.

Chris: If you were writing a CSS framework today, you wouldn't go too heavy with the selectors knowing that there's a decent chance that somebody has to match or beat your selector, so you're just being nice. You don't have to be nice anymore - theoretically - if the world grasps onto this in the way they could.

Jen: Yeah. And you can nest layers inside of layers, so if somebody is building a third-party framework, tool, library, or whatever and they want to use layers while they're making that framework, they can. Then a website can have layers, and it can pull the entire framework into a single layer.

Chris: Wow.

Jen: But inside of that framework is a whole bunch of layers. You don't have to worry about whatever. Yeah, it's really powerful.

Chris: Can we paint one more picture, the one of--? Let's say this takes hold, because it remains to be seen. It's going to ship, but how will it change how people really write code remains to be seen.

Do you have a picture in your mind (a little bit) of what a greenfield project embracing layers to their most beneficial sense might be like? How would you set up a group of layers that you think is pretty smart?

Jen: The quick examples I've made (in talking about this) have been things like, "Well, you might have some kind of a reset layer where you've got--

Folks used to always use a reset style sheet, but maybe it's not really about having simple styles. Maybe it's some sort of a base.

When I used to build a lot of websites on this particular content management system, base styles was sort of a concept that was used often. It was like your basic headline styling, paragraph styling, that kind of stuff, into some kind of a reset or base layer, and then you could have a design system that maybe has a lot of coverage but not 100% coverage. Then you could have a layer for -- I don't know. Maybe you've got a lot of media elements or a lot of specific, certain kind of content, so you want to write styles for that bucket of content. But you don't really want to worry about--

Maybe that's being handled by a different team, so they could put their stuff in a certain layer. Maybe if you've got--

Maybe you've got a whole bunch of overrides and a whole bunch of one-offs, a bunch of, like, "Sorry, but got to do this." You could stick that into a layer.

Chris: Yeah.

00:25:01

Jen: Then I should say that unlayered styles -- so, what happens to the styles that you don't put into a layer -- they are the most powerful.

Chris: Right.

Jen: That will affect perhaps what you do because anything that's outside of a layer is going to be the most powerful, except unless you put important on things because, again, important will flip the order of the layers. So, important in your base layer is going to be more powerful than anything else. Well, except for the--

Now I'm confusing myself, but if you had layer A, B, and C, and then you put important on all of them, the importance, the specificity would be C, B, and A, right?

Dave: Okay.

Chris: Right.

Jen: Unlayered is sandwiched in the middle. Yeah, your important, all your important layers are more powerful than your important unlayered styles. Yes.

Chris: [Laughter] I almost think it makes more of a case of not using important because the mental model is actually worse now, I think. [Laughter] Everything else is better, but I hate important.

Jen: Also, you could almost think of it as, like, you know all the times you've had to use important? Well, instead of using important, you could just take the styles and put them into another layer.

Chris: Use a layer. Yeah.

Dave: A layer called important.

[Laughter]

Jen: Although, I wonder if that word is excluded from being an official name. Maybe not. I can't remember.

Chris: Oh... Hmm... It might be.

Dave: Because that makes it double more powerful. [Laughter]

Jen: Maybe it's not. I have to--

Chris: It could because this always blew my mind is that it's not bang important. The bang matters, but it doesn't matter how many spaces are between the bang and the word important.

Jen: Yeah.

Chris: I always thought they had to be next to each other, but they do not.

Jen: Oh... I don't know.

Chris: Okay. Well, that's amazing. I do really like that. I'm hoping that the best practice -- I shouldn't say hoping because I could just be wrong, but it seems like if you're going to use layers, you should layer everything. Leaving stuff outside of a layer to just be super strong feels like you've made a powerful layer but I feel like that's asking for trouble. I think you should layer everything.

00:27:06

Dave: What happens if I create a layer called "about page" or something and I never specify where that shows up? What happens to those styles? Do they just never show up?

Jen: Well, no. The order in which the layers are defined is the order in which they are, like, what's more powerful or less powerful. You can use this single line to "initialize" the layers, but that's probably not even the right word.

If you just say, "@layer base design system Dave's stuff," it overrides. We apologize for it, right? Then that's the order. But you don't have to do that. You could instead just open, and say, "@layer base open bracket," and then you just write some code, and then you write some more code, and then you write some more code.

Just like everything else in the style sheet, at first I was forgetting, like, "Wait. Is the first one listed most important or the last one listed more important?" It's like, "No, no, no. It's the same as any other styles."

If I write stuff at the top of my style sheet, and then I write stuff at the bottom of my style sheet, the stuff at the bottom is going to override the stuff at the top.

Chris: The bottom wins. Yeah.

Jen: So, it's the same.

Dave: Okay. Source order still is the same, unless I go through and I say, "No, actually, make my layers go this order." Then any unlayered styles are at the top or, basically, the most important.

Chris: Yeah. The win.

Dave: They win. Okay.

Jen: Yeah. Yeah, yeah.

Dave: I feel like that's a good ruleset I can wrap my head around. I've been struggling, like, "How can I use this?" You know.

Chris: I would try to lint. I would be specific about it, not that I get to be the champion of best practices, but I would use the one-liner where you say which is which.

Jen: Yeah.

Chris: That feels way better to me.

00:28:51

Jen: I think it's a little easier to keep track of as a human being. I do think -- I mean, so best practices, I hope people maybe write 3, 4, 6 layers for a project and not 100, 200, 700 layers. Right?

Dave: Mm-hmm.

Jen: We did have a little conversation about, like, are people going to try to make a separate layer for every component? Is that going to be a thing?

Dave: Yeah. Maybe.

Chris: Yeah, don't do that.

Jen: Oh, please.

Dave: Yeah.

Jen: But also, I think it's another example of what's the best practice. I don't know. Let's get a time machine out and ask ourselves three years from now because I think there's a way in which maybe start using it on some projects and see but realize that we're going to learn along the way. Hopefully, some folks will write some really great articles and some blog posts about it and say, "You know what? I tried this, but I ran into these problems, and I did it this way, and it seemed to work much better for my team," because it really is about organizing the human beings. It's just another new tool.

Just like a design system is not really about the code. It's more about helping the humans stay organized when a whole bunch of different people are working on the code. I think this is similar, so it's really a tool for your team and team communication and team organization. And so, I think we need some case studies and some real-world stories about what worked and didn't work for a particular team.

Chris: We have got a bunch of stuff to get through, so maybe we can increase the pace a little bit, but this next one is so juicy is the :has selector. Unbelievable. We talked about it with Eric and Jeffrey a little bit, so we've already kind of recently talked about this one but talk about a powerful new feature already shipping in Safari. Wonderful.

You know it's thought of as the parent selector. Although, there are plenty of people being like, "Don't call it a parent selector," only because you are selecting the parent when conditionally it has some other thing going on anywhere in the DOM below it. But then once you have the parent, you can drill back down into the DOM, which is mind-blowing. [Laughter] So, yeah, :has is great.

00:31:01

Jen: I've been making some demos lately for it, as I'm writing an article. It's not out yet, so check it out, webkit.org. At some point, I'll be publishing this article. I've got five or six different demos in it.

You know it's kind of mind-blowing, especially when you start using it with pseudo-classes on forms. There are just so many use cases where, in the past, maybe you'd reach for JavaScript.

Dave: Oh, my God. Like form has error or invalid or something?

Jen: Yes, form has invalid.

Dave: Oh, my gosh! [Laughter] It's like, show the P-tag next to it. Oh, my God.

Jen: Yes.

Chris: Hmm.

Jen: Like change the color of the label. You can change the color of the label.

Dave: Oh, wow.

Jen: Even add a before or after with an X or a checkmark, right?

Chris: A label. Nice.

Jen: Without :has, you can change the color of the border on the element, the actual input, but you can't do anything else.

Chris: Yeah, you couldn't go backwards in the DOM to get the label, assuming that's where the label is.

Jen: Right. Now you can. You totally can.

Chris: Right.

Jen: You can do things like put a toggle on your website for dark mode, and the toggle doesn't have to be on the root of the DOM tree. It can be anywhere in the DOM tree, and you can just use :has to climb up the DOM tree and create a dark mode styling that then goes back all the way down the DOM tree - anyplace in the whole tree.

You can use, like Jeremy Keith, for instance, for years has had a theme picker on his website. It's like a select many where you can drop down and choose and switch to a different, totally different layout. Instead of using JavaScript for that, you can use :has for that. Use a select menu. You don't even need to hook it up to any kind of backend. You just have a select menu, and you use :has to capture which state that menu is in. Then completely apply different styles based on the state of that.

Chris: Yeah, that's just amazing.

Jen: It's mind-blowing.

Chris: It went so far as our Discord, Andrew in the Discord, was speculating that :has could be picked up by even a JavaScript framework that manages state and state could be expressed (almost any kind of state could be expressed) across the entire DOM using :has, which is, I know, a little mind-twisty or something. You know it's nice when technology that offers state management can use something browser native to express it, and I wouldn't doubt that we see that.

00:33:18

Jen: Yeah, so I encourage people, episode 520, ShopTalk Show, listen to Eric and Jeffrey talk to the two of you about :has. Also, there's starting to be some really great articles and demos out there.

It's a good example, so I was writing these form element demos with a whole bunch of different :has. By the time you get, like, form:has something that is focused (focus visible space) so that it's sort of an and (input, not :has), it started to be a very powerful selector, and it started to run into problems with being able to override which thing I wanted to override.

Chris: Hmm...

Jen: I was like, "Oh, no! Am I going to have to reach for important? Layers! I don't need important."

Even though it's a fairly simple demo, I put all my code in four layers because I needed to sort out what would override what.

Chris: Oh, wow.

Jen: Without worrying about this massive specificity that was getting created by these, like using multiple pseudo-classes with :has.

Chris: Right. Then if we had nesting too (which may or may not ship in the next year or something, but it looks like it's got some movement) that will unlock some organizational concepts.

Jen: Yeah. The two other organizational things, like nesting. If anybody has used Sass, I think that's one of the main remaining use cases that people still really like Sass for is because you can kind of nest your selectors. You know nest code instead of each other.

It's very clear that it'd be great for that to come to CSS. There is a discussion right now about whether or not it's -- like, what the syntax should be. There's a bit of a hot debate about it. Some folks want to use a greater than sign. Some folks want to use an ampersand. Some folks want to use @nest repeatedly over and over through the whole thing.

Chris: Right.

Jen: Some people just want to use extra brackets. There's actually an article over on developer.chrome.com. I'll put the link in your show notes. Help pick a new syntax for CSS nesting.

Chris: Yeah, that was fun. It's fun to think about because it's like we'll probably get one of them, so you might as well have your say now.

Jen: Yeah.

Chris: Of course, the main response is like, "Why can't it just be exactly like Sass or less?" And there are reasons why it can't be.

Jen: Yeah.

Chris: So, it's like, "Wipe that from your mind. It's got to be one of these."

Jen: Yeah. Yeah. Yeah, so it's not going to ship in any browser until the working group figures out what the syntax should be because, you know, we don't want to try to change the syntax after we've shipped it. We tried that with Flexbox, and we learned the hard way that that's not a good idea.

No one can ship it until all the syntax gets figured out, so who knows how long that will take. Sometimes it goes quick and sometimes it takes years. People chiming in can help make that go quicker.

Then, yeah, scoping. Scoping would be -- you know there are a lot of ideas about scoping that have been kicked around for years. That word means many different things to many different people. But the thing that's being discussed right now is for the cascade specification level six where cascade layers is in level five of the cascade spec.

Dave: Oh, Jen. I think we're all familiar with the difference between five and six.

Jen: [Laughter]

Dave: [Laughter] No, I'm just kidding.

Chris: [Laughter]

00:36:21

Jen: It would basically give you a way to kind of create a donut in your selector. Let's say you have a component and it's called zebra. You've got a zebra class on it, and you've got zebra H1, you know, paragraph styles. Then you have, like, it's inside of a bigger component and your bigger component is alligator. You have a .alligator H2 style in paragraph styles.

But the way it is right now that when you write the .alligator H2 styles, it's going to actually also apply to any H2s that are inside the zebra component. If you want to override that, you can override it. But there's no way to not apply the styles to the zebra H2 because it's inside the DOM for the alligator.

Chris: [Groans]

Jen: This would give you a chance to be like, "I'd like to go from .alligator to .zebra, and then stop."

Chris: Then stop?

Dave: Golly. I love it.

Jen: Don't keep going with your cascading.

Chris: I'm not sure if my brain can deal with that.

Jen: I know.

Chris: It's so weird.

Jen: It's so cool.

Chris: I can get it for the Markdown component, like, "Oh, there's a chunk of Markdown in here. Don't let anything else mess with it. Donut out that little part," because it's....

Jen: It just gives another option because right now you can override, but you have to override. This would give you a way to define a component where it doesn't, where you can start the styles cascading through and then you can stop them someplace.

Dave: You know I think when that talk of scoping came out, people were like, "I already have scoping. I have BEM." You know? It's like, well, BEM can't do that.

Jen: Right. You can do .z and .a, and use some kind of BEM thing, but you're still cascading through. Yeah. Yeah. It's totally different than whatever.

Also, a little bit back to cascade layers. I feel like we've had this rule for 15 years that you can only use classes. Don't ever use IDs. You always have to use a separate class for each little thing you want to do. Like, "Oh, this color has a class, and then this font has a class, and then this size has a class," and so if you want to style that H2, you apply three separate classes: one for color, one for font family, and one for size. That's how you must do it. Must do best practices always, always.

It's like that's not -- that has nothing to do with CSS. That has to do with dealing with humans and overriding and organizational desires that are very real, a la 2008. Now that we have these more powerful tools (like cascade layers and, perhaps in the future, like scoping), I hope we reassess and reevaluate whether or not those ideas are really good ideas anymore, whether we need those ideas, because you can manage.

Those ideas, we're in an attempt to manage something that needed to be managed, and now we have other ways to manage those same things. Maybe we want to let go of that whole, like, "You must only use classes," and a whole bunch of separate ones and stuff.

Chris: I bet we will.

Dave: That feels like the biggest fundamental shift because it's kind of funny how, like, "Oh, CSS is broken. Oh, it's a fail." You know?

Jen: Right.

Chris: And for decades, that's been the marketing. It's like, "Oh, well, if we just add these few little bits of organization, it actually becomes super more powerful and you don't even need all those little weird tricks we did."

Jen: Yeah. Yeah.

Dave: It just goes away. The problem just goes away.

Jen: Yeah. It's like floating everything and putting percent weights on everything. There was a good reason we did it, but let's not do it anymore because we have way better tools now. We'll see.

Speaking of, let's talk about Subgrid.

00:40:02

Chris: Let's do that. Let's definitely hit on these layout things because I think they're the most fun part of CSS, before we can jump into some HTML and some other interesting Safari things.

I see Subgrid is dropping in 16. We've talked about Subgrid a lot of times. It's just incredibly welcome that that will be shipping in 16.

Jen: Yeah.

Chris: It means that an element that's a part of a grid can inherit the grid lines from the parent grid, which means that you can line up stuff internally on a grid with the parent grid, and that just makes sense.

Jen: Yeah.

Chris: Thank you. Yeah.

Jen: It falls back really well, so definitely start using Grid and definitely start using Subgrid. Even though it's not quite in every browser yet, it will be eventually. In the meanwhile, it falls back beautifully, so yeah.

Chris: Mm-hmm.

Jen: It's awesome.

Chris: Subgrid is great. It'll make a lot of people happy, including me. I think it's the right -- you know it completes the power of Grid, in a way.

Also, I didn't even really realize that you couldn't do this, but it will be dropping in 16 Safari, is animating the grid, which I guess we're not talking about, like, "Ooh, I can change the Grid Layout and the elements will fly to their new positions," or anything like that.

Jen: Right.

Chris: We're talking about the fact that you can -- if you're setting up grid template columns, and then you want to change those (say in a container query), that if they have a transition on them, they'll animate.

Jen: Yeah. Yeah. Yeah, you can't animate the items for reasons that are sad but true. But you can animate the definition of grid template rows and grid template columns.

Michelle Barker made a good, really cool demo that I was looking at recently where she used :has and grid animations together.

Chris: Nice. Right.

Jen: So that when you hover over a particular -- like she had these four cards, like four 2x2 grid. When you hovered over one of the items, that item would get bigger and the other three would get smaller. She accomplished that by making that first row, you know, made the row that you're hovering over and the column you're hovering over get bigger so that one item would get bigger and the other two would get smaller.

Chris: Right. When you see that, you're like, "Oh, yeah. Obviously, we need that." [Laughter]

Jen: Yeah, it's like a way to animate the size of content by animating the grid that they live inside of.

Chris: Yeah, so if you didn't know you couldn't do that before, well, good because now when you reach for it, it will work like you expect it to work, because it's a number. It's like you better be able to animate a number.

Jen: Yeah.

Chris: Yeah, what's related to it?

Jen: Yeah, animate it from 1FR to 2FR from 200 pixels to 400 pixels - or whatever.

Chris: Right, exactly.

00:42:41

Jen: Yeah, and then another animation thing is the CSS offset path, which also is known by the name of the spec, which is motion path. But the properties are called offset, so I tend to call it offset path.

You can define a path with offset path, and then you can have the thing that's being animated, so a box or an arrow or something that gets animated, move. Instead of going in a straight line, which is what we've had up until now.

Chris: A curve.

Jen: Yeah, it can go in a curve, or it can go in some kind of whatever. You can define--

Chris: A star shape or whatever, right?

Jen: Yeah. You can define the shape.

Dave: Ooh... I don't know how I feel about this non-rectangular arrow of CSS.

[Laughter]

Dave: I don't know.

Chris: I made a demo. I still love this. I'm putting it in a recent talk where a modal comes in. But rather than it just sliding in from the one of the edges or at a straight line or from above or whatever, it comes in on a bit of a chill curve.

Jen: Curve?

Chris: It just goes woosh in, and it's such a satisfying, interesting thing. I don't know. I feel like that's going to be part of the surprise and delight toolkit for a minute (once it's available everywhere).

Jen: Yeah. It'll be in Safari 16, and there are other parts of the motion. There are other offset paths or offset properties to make -- maybe your thing is an arrow and you want it to sort of turn, like rotate a bit in space as it's going down the line. Or you want it to go quickly at first and then slow down further along the line. There are all sorts of details that you can finesse with that. Yeah.

Chris: If you don't mind, if I could move us along because there are so many interesting things to talk about, I do want to mention color specifically because I've heard some wonderful things from Jen about the fact that Safari is now supporting P3 color and it's wider color gamut has really opened up your design ability and thinking about color on the Web because of how much many more colors you can support. It's nice to know that that's coming to Safari. In fact, maybe Safari was even first with P3, I think.

00:44:45

Jen: Yeah, P3 color landed in Safari in 2016.

Chris: Hmm.

Jen: We've just been adding it to more and more parts of everything. Now, in Safari 15.4 (last March) it landed inside of Canvas in Safari as well.

Chris: Oh, I see.

Jen: Not just Safari, but all WebKit processes in WebKit.

Chris: All the little nuance. Right. Like, oh, sure, you can use it as a color in CSS, but it doesn't necessarily mean it's absolutely available everywhere else.

Jen: Yeah, or it was a color, like it supported the photos, I think. But it took a while. There are also these color functions. I think people just aren't aware because they've been so well supported inside of WebKit for quite a few years. But because they weren't in other browsers, or because people hadn't really talked about them much yet, there wasn't a lot of awareness.

But now, this is the year to really become aware of this stuff. There's this color function, and you can tell it which color space you want it to use. Then you can put all your numbers.

Instead of being like RGB and HLS, we would have ended up with a whole bunch of those. So, it just is like color paren, and then you can write RGB or you can write whatever you want. Right there, you can say, "Display P3," and then you can use the numbers like 00 or 0.12 or whatever the number are to specify the color that you want to use.

Chris: Right. It's opening up some doors to manipulating the colors too, which is pretty juicy.

Jen: Yeah, and I had never used P3 color before, but I remember -- you know I always have a bit of a personal insecurity about being, like, "Am I a good Web designer or not?" I'm sitting here trying to make this look good. It still looks bad. It still looks really bad. Keep going. It still looks really bad.

When I started trying out P3 color, making some demos, I was like, "Oh! This is the secret way to make your stuff look really good," because I was picking background colors and such. I was picking things that were intentionally in the part of the color space for P3 color that you cannot represent with the more traditional RGB color, and suddenly, everything looked really gorgeous. I was like, "Oh... This is amazing."

Chris: It makes me sad that the part that was sliced away of available colors (in the past) were all the good ones. [Laughter]

Jen: Right? [Laughter] Right. Right. Yeah, so it's cool. There's support for color palettes in Safari 15.4. You can have a color font. But instead of just only using the colors that were defined by the person who made the font, you can write CSS that will change the colors that are inside that color font, or you can switch.

The person who made the font can actually make multiple palettes, and you can tell it, "Oh, use this palette instead of that palette." There's really powerful stuff. Yeah.

I know we've got to go fast because we're taking way too much time, but the new viewport units back up in layout are really, really kind of awesome. Folks, I know, for a long time, especially, have been frustrated with VH on mobile devices because all of the browsers on all of the mobile devices, when you scroll, the size of the viewport changes. And so, VH was always defined to be kind of whatever was the longest possible length. But there are plenty of use cases where actually what you want is the shortest possible length, or what you really want is for it to change, the value to change as the viewport changes height.

Now we have a unit for all of those things. You can use LVH if you want the long one and SVH if you want the short one, and DVH if you want the dynamic one. You can also do those as widths. You can also do those as referring to the block dimension or the inline dimension.

There are a lot of new units, but especially on mobile, especially that height unit.

Chris: It feels like a repair thing to me, like so happy that they're there. Ideally, this is what is shipped originally because they're just better in all ways.

Jen: I'm not sure that mobile browsers did this when the CSS working group defined viewport units. I think viewport units were sort of--

Chris: Oh, like they just didn't have the opportunity to even deal with it?

Jen: Yeah, it's like the working group didn't think about this because I'm not sure that this was a thing. I don't know. I'd have to go look it up and find out the timing of it, but it's like another example of, okay, the CSS working group thought that the simpler solution was going to solve all the use cases. It turned out it didn't, so it took a while for the CSS working group to figure out what they wanted to do instead. Then once they figured that out then, yeah, it shipped in Safari 15.4, and is shipping in other browsers too.

Chris: Yeah. I would think, within a few years, we're just going to see everybody using these new ones, but probably mostly the dynamic ones because of safety.

Jen: I think it depends. It depends on what you're doing, I think, because that was part of the argument about, like, well, what should we do? It's like, "Well, here's a reason why VH should mean this." It's like, "No, no, no. It should mean this for this good reason." It's like, "No, no, no. It should mean this other thing for this good reason."

We finally -- I think the working group was finally like, "Actually, those are all good reasons. We should make three things."

Chris: [Laughter]

Jen: [Laughter] Let's not argue any more about use cases. Let's just go ahead and make all three.

Chris: [Laughter] Yeah. That's a tough call, though. That's why I don't envy that work.

00:49:39

Jen: Well, now people are like, "Why are there so many new units?" There's SV min, SV max, LV min, LV max, DV min, DV max, VB, VI, SVI, SVB, LVI.

Chris: Holy crap.

Jen: Right. It was like, well, um... because you wanted more units. [Laughter] There are good reasons for all of them, but yeah, it's always trying to find the happy medium that we do solve the real problems but without making the whole thing too complicated. Yeah.

Chris: Indeed.

Jen: Anyway, a good solution that's been needed for a while.

Chris: There's lots more. Maybe we can publish some things that we don't necessarily use our voices to talk about and just make in the show notes just so that you know because - I don't know. I just wish everybody could see the same document I'm looking at because there are so many interesting things. But for the spirit of making the show its normal length, can we talk about HTML a little bit? I'm just particularly excited about pretty much everything on this list, starting with the dialog element. Literally, I don't know, angle bracket dialog angle bracket. It's a real thing.

00:50:40

Jen: Yup, a real thing. The folks writing the specifications figured out everything that needed to be figured out in order to make dialog be fully accessible, which was really what the holdup was for such a long time.

Dialog, basically, you know, any time you go to a website and you click a button or something, and you get this kind of overlay that shows up. Maybe it's a content management system, and you're looking at the content. You click the edit button, and this sort of editing interface appears. That editing interface covers up the website. You can see it.

You can see the website kind of in the background behind a translucent overlay. But then the thing that you're interacting with is then that editing interface. There's an accessibility concern there because focus and access to the DOM tree needs to really be captured inside of that CMS editing interface, and the page, the webpage content that's behind the dialog needs to get inerted. It needs to become inert.

Chris: Intertitized. [Laughter]

Jen: It needs to go away from the accessibility tree. So, that--

Chris: It's like you went to a different website (for a minute).

Jen: Yeah, it's kind of like you went to a different webpage, except you didn't go to a different webpage.

Chris: Right.

Jen: That whole state management as far as how is that going to interact with screen readers or keyboards or tabbing or all of the different considerations when you're really thinking about all of the ways that all of the humans interact with the Web. That had to be captured. That's the great thing about dialog. Instead of using a div and a bunch of JavaScript to kind of create this yourself, but also, "Oh, gosh. Yeah, we didn't think about the stuff."

Just use dialog. Use a dialog element. Put all of the things that you want to show up inside of that modal in that dialog element. Then the things that are outside that modal or outside that dialog element, and you get all of that interaction for free because it's HTML and it will behave properly.

Chris: Mm-hmm.

Jen: Then the backdrop pseudo-class gives you the opportunity to style that kind of translucent overlay that's behind the dialog.

Chris: What's behind it, right.

Jen: The modal pseudo-class gives you a chance to address the dialog element when it's in its open state, once it's been opened. Yeah, so that's all -- it shipped in Safari 15.4. Modal shipped in Safari 15.6. I believe dialog and backdrop also shipped in Firefox recently. Either is about to or did this past year because they were also waiting for accessibility to get figured out.

Chris: Right.

Jen: Yeah.

Chris: I'm glad that it is, and it seems like the amazing hoops that had to be jumped through to make this stuff work the best possible way in the past can just go away. This is going to save many thousands of lines of code for websites.

Jen: Yeah.

Chris: Very exciting that that exists. It also makes me think of when you should and shouldn't use it. But yeah, go ahead, Dave. Yeah.

00:53:33

Dave: Oh, well, and if I'm not mistaken, one of the accessibility problems was the keyboard-trapping stuff. That was hard to do, and I think that's -- if I recall correctly, that's solved now.

Jen: Yeah.

Dave: Once that dialog is open, you can't get back to the main page. That changes everything because now you can just put a dialog wherever you want on the page. [Laughter] You had to kind of always chuck it at the bottom of the page. You know?

Jen: Hmm...

Dave: Maybe you still want to do that, but now you can just be like, "Hey, guess what. It's there."

Chris: Oh, that's true. It doesn't matter where it is in the DOM because it just is in the middle - or whatever. [Laughter]

Dave: Yeah. Yeah. It's just kind of like, "Hey, look. It's easier now. Just do it. Do it this way."

Chris: That's nice.

Jen: Yeah, and then the inert attribute is not for using with dialog, but it does something similar for all the times when you're not using a dialog but you need something to be inert. The demo that we were making, for example, is of a carousel where that centerpiece of content, maybe it's got a form on it or it's got some links, and you want people to interact with or tab into that centerpiece of content. But there's a sort of previous content and next content that you can see on the sides. Maybe it's dimmed out a little bit in one form or fashion, but it's still visible, but you don't want people to tab into it.

Chris: Oh...

Jen: You don't want people to be able to click on the form.

Chris: Right.

Jen: Or accidentally click a link or something, so you can put inert. Using JavaScript, put in an inert attribute on that, the card or whatever, that's kind of the before and the after cards. Once there's an inert attribute on it, then it behaves much like the content that does behind a dialog. It's just like inert. It doesn't -- you can't access it. You can just see it.

Chris: Well, that's so -- it feels like it was made just for CodePen. If you're logged into CodePen and browsing through grids, you'll see that there's a big right arrow where you can click it and it'll slide new cards into place. We actually render out the cards after it, you know, off to the right because we want it to be really smooth and have them already preloaded when you do click that arrow.

Jen: Right.

Chris: But they're not inert right now. You know?

Jen: Oh...

Chris: Because they're in the DOM, you can tab over to them, which is not super-duper ideal.

Jen: Yeah. Toss inert on them, and then they'll stop capturing, you know, trapping people.

Chris: I think you can't tab to them because we put some elaborate code into place to prevent you from doing that. But now it'll just be one HTML attribute.

Jen: Yeah.

Chris: Pretty nice.

Dave: A prop on an element. Beautiful.

Chris: Yeah.

Jen: Yeah. Yeah.

00:56:15

Chris: Wonderful. HTML, a couple of little mini ones. Lazy loading for images, pretty cool.

Dave: Awesome!

Chris: Just speaking of one attribute on an HTML element making a big difference. Loading equals lazy.

Jen: Yeah, that shipped last March in 15.4.

Chris: Then AVIF, pretty cool.

Dave: Huge.

Chris: That's pretty good. Yeah.

Jen: Yeah. Images.

Dave: Or small, I guess, because....

Jen: AVIF support in Safari 16. People are really excited about that.

Chris: Pretty nice stuff. Think of all that. We can barely -- we're packing stuff into it that have all shipped in basically less than a year.

Jen: I know.

Chris: Pretty huge.

Jen: There's so much. There's so much. Yeah, like Web inspector extensions now starting this fall. Folks who make your favorite extensions for developer tools can make them for Safari as well.

Two years ago, we announced support for Web extensions. Last year, we announced support for Web extensions on iOS and iPad OS. Then--

Chris: Web extensions meaning like the little icons in the upper right of your browser that do stuff.

Jen: Yes.

Chris: That's cool in Safari, and supported in a way that, by some miracle, all the browsers agreed to use the same format for those, which blows my mind a little.

Jen: Yeah. It's one of those. Way back in the day, part of the reason it was so hard to make websites and you had to make a separate website for IE and for Netscape is because browsers hadn't yet agreed to implement Web technology like HTML identically across browsers. Then the Web standards movement came along, and everything became standardized. Now it's very, very important that all of the browser engineers in the world always and only ship things that have been standardized in Web standards in order to maintain that interoperability between browsers.

That same kind of movement and switch-a-roo over to standardization is happening right now with Web extensions. In the past, each browser had their own way that people could make add-ons or plug-ins or extensions (or whatever they were called) for that particular browser. Now, yeah, it's one of the things that the folks on my team have been helping really make happen is getting, spinning up a standard organization. And so, all the APIs are documented on MDN now, and more and more browsers are supporting more and more of those APIs every year and making it so that folks, anybody--

In fact, extensions are made out of HTML, CSS, and JavaScript, so people who know Web development, you can make an extension. If you're interested in making them for Safari, we have a template inside XCode, so you don't have to know all of the things about how to start. You can start from a template, which gives you -- it's just like a starter kit for a project and creates all the files that you need and creates all the connections between those files. It makes it far easier. Then it's just mostly JavaScript with HTML and CSS.

Chris: Yeah, that's nice.

Jen: If you already have an extension, we have a script, and it can just take your existing project for Edge, Chrome, or Firefox and translate it over into an XCode project and get you started. The way things are packaged for each browser is slightly different, but the guts underneath, the actual code that's running each extension, is the same.

Chris: It can be a super big deal. Obviously, we know browsers care about their amount of usage and stuff. If a browser said, "Oh..." there's some extension that's crucial to your day-to-day workflow, it's just got to work. If you're like, "I can't use a browser that doesn't have 1Password in it," so--

00:59:41

Jen: Then it means that teams that are making -- some of the people's favorite extensions are for Angular or React or Vue.

Chris: Yeah. These are Web inspector extensions, which is different.

Jen: Web inspector, yeah, or developer tools extensions. Now those will hopefully let the creators of your favorite developer tools extension know that you would love to see it in Safari, and they'll put them out in the fall for Safari.

Chris: ...tools, please.

Jen: Yeah. Yeah. Exactly. Instead of a team having to create completely separate projects for each browser. Basically, it's the same project, and they can publish it and distribute it to all the browsers. Yeah.

Chris: Huge.

Jen: Yeah.

Chris: Huge. Huge. Huge. Speaking of huge, this is one I marked on our document that I just definitely wanted to fit in there, in a way, is the whole passkeys thing, which was a big deal. It was made out of WWDC, which rightfully so. Pretty cool. The idea is literally removing passwords from websites. Not overnight, but the technology is here now to make this happen, and what?! [Laughter]

01:00:45

Jen: Yeah. It's really amazing because there's so much that's wrong with passwords. Right? People can trick you. They can phish folks and trick people into giving them their passwords. People keep reusing their passwords across accounts, and they're using passwords that are too simple. They're easy to crack, and they get stolen sometimes.

Folks used to store passwords on websites in plain text files. At least now they're salted and hashed. But still, they can be leaked or cracked.

Passkeys are just a way better replacement that will just make it impossible to phish and impossible to make simple ones that are easy to guess. Impossible to be guessed, just like--

Chris: And they're different across every single thing, right?

Jen: Yeah. They're different for everything, and so it uses autofill and face ID and touch ID for iOS and iPad OS and Mac OS.

Chris: There's a bit of a biometric wall here, like you have to be using something with a biometric thing. But if you are--

Jen: When you go to a website using a device that supports passkeys, and that website supports passkeys, you'll basically just click a button to log in or click into the username field. If you're on iOS or Mac OS, it will autofill your username for you, and then it will automatically just look at your face or ask you for your fingerprint and log you in.

It's amazing when you look at the demos. In the show notes, I'll put some links to some videos where people can watch how it actually works. It's so, so simple. It's just like, "Oh, I'd like to log in. Oh, I'm logged in. Thanks. Cool."

Chris: [Laughter]

Jen: The site knows it's you. It's definitely you. Yeah. Pretty amazing.

Chris: I had to do this ridiculous thing. I just ordered this today where I have a Mac studio, a desktop computer. I don't have -- because you can't use the face ID. I mean no desktop can. I don't even think Mac laptops can do face ID yet. Right? That's not a thing. You have to use your fingerprint thing if you're using a laptop.

Jen: Yeah, fingerprints on the keyboard, and so there are. Apple has keyboards with fingerprint sensors on them.

Chris: Exactly. But for my fingers, I need the ergonomic keyboard that Apple doesn't make, so I bought one anyway. This is so stupid, but I just had to do it because it was bugging me. That I can Velcro under my desk.

Jen: Yeah.

Chris: So that I can use the biometric thing, but I don't actually want to use that keyboard. I just want the little fingerprint thing.

Jen: Right. Yeah.

Chris: Which I know is a little ridiculous, but I'm ready now for passkeys because I have Velcroed a keyboard under my desk. [Laughter]

01:03:23

Jen: Awesome. Yeah, so folks who run websites, maybe something like - I don't know - CodePen has logins, right? Web authen is your friend. The Web authentication standard is the standard that is going to handle the whole authentication side, the website side in order to do passkeys.

What's happening, anybody listening who has used Git maybe with, say, GitHub, GitBucket, or any kind of service like that, in order to--

In order to github.com, it's sort of a traditional login. But when I'm sitting here and I want to push a commit or pull a commit or clone a new repo, I'm not actually going through the github.com website. I'm going through an authentication system that checks it to see whether or not my computer is authorized to have access to that repo and to push and pull and such.

And so, you set that up by using a private-public key pair, right? You open up a terminal. You type in some commands. You create a key. You go over to your text file. You've got to find the right text file and copy out the public. Make sure you've got the public -- you know, the private key, got the public key. Go over to github.com. Find the right page for the settings and paste in your public key.

Setting all that up takes some -- you know I remember the first time. I had to have a friend help me figure out how to do that because it's not necessarily that easy. It's a little daunting, right?

By the time you do it a whole bunch of times, then you're like, "Okay, I got this down." But even then, often you're looking it up again.

But once that's set up, any time I want to push or pull to my repo, it's super secure and super easy to do. I don't have to type in a password. I don't have to do anything. It's just that this computer knows it's me because what's happening is my computer will ping that server and say, "Hey, let me in." The server says, "Hmm... Are you? Okay, I've got a public key here for you. Uh... Can you solve this puzzle?" It makes this challenge, this puzzle that if someone stole the puzzle along the way, nobody could do anything with it. It's not insecure, that puzzle.

That challenge then goes back to my device, and the device says, "Oh, yeah. Yeah. I get it. I'll use my private key and this public key and this puzzle, and I'll put together an answer to this challenge." Then my device sends the answer to that challenge back up to the server, and the server goes, "Ah, that's correct. You've solved the challenge, so you must be you. You can come on in."

It's that technology. It's just without all the hard parts. But there's a key. There's a public key and a private key. The private key is on your device, and the public key is on the server that you're communicating with.

If you're using iPad OS, iOS, Mac OS -- it's iPad OS and iOS 16, Mac OS Ventura, all of those passkeys are going to be through iCloud Keychain. It's all going to be synced, so I can create a passkey on one device, and it's just going to automatically be on all of my other devices.

I can share a passkey, or I can give someone else a passkey through AirDrop.

Chris: Oh, that's wild.

01:06:54

Jen: Also, there are ways -- because this is all through the FIDO Alliance. Google, Microsoft, and Apple--

Chris: Again, these are open standards, not necessarily just an Apple thing, which is pretty cool. Yeah.

Jen: Open standards. No. Right, even the word passkey, it's a common noun that anyone can use. It's a new word.

Dave: Oh, I love that.

Jen: Yeah, it's like the word password. It's not owned. It's not a brand name. It's a common noun.

Dave: I genuinely thought that was Apple branding. [Laughter] So, congratulations. But I love it because it reframes this thing. It's a new thing. it's a new way to log in.

Even if I want to log into GitHub on my kid's iPad for some reason (my iPad is out of battery or something), I can just log in, and it can even just say, "Oh, if you want to scan this QR code and login from your phone (or something like that). I saw some demos that kind of had that feature.

Jen: Yeah.

Dave: My identity is tied to my phone, which knows I'm Dave Rupert and I have this GitHub account. You can kind of just log in anywhere. It's just as easy as a two-factor auth text, but it kind of jukes all of that noise. You know?

Jen: Yeah.

Dave: I'll never get any texts ever again if this rolls out everywhere because I'll be fully authenticated everywhere.

Jen: Yeah. It's more secure than a lot of the other authentication methods that we've been using, and it's way easier to use, both at the same time, which is pretty amazing.

Chris: Yeah, it's weird that one technology is all better all the time. [Laughter]

Jen: Yeah, like I have a phone. I have passkeys. I've signed into six dozen different websites with different passkeys, and I need to log in and don't have a computer.

Maybe I'm in college, and I go to my school library. I go to login, but I need to get into codepen.io, or I need to get into whatever website I want, you know, some store website. I can, yeah, bring up on screen this QR code and then use my phone to authenticate, connect, use the camera on my phone to look at that QR code, let my phone know what's going on. The phone will authenticate me and say, "Yeah, yeah. We've got a copy of that passkey right here. I know who that is. Yep. Yep. You should let her in."

Chris: Yeah, that's nice.

Jen: Boom, you're in. Yeah. The Web authen spec, it's very well supported already in all the browsers because it's the same spec that's been used for hardware authentication devices like YubiKey (for several years now). It's an extension of that system, the credential management APIs and stuff. So, it's been a many year process of building upon thing on top of thing.

For iOS, iPad OS, and Mac OS, iCloud Keychain is really central to the experience and making it work across devices and be so easy for all of our users. That's been many years building, you know, years of experience figuring out how to make passwords work and be very secure and to sync everywhere, so it's pretty exciting.

Chris: It just seems like it's the start, so here's hoping for--

What I want to see is this, first of all, get integrated in lots of places. But then knowing that there's this biometric requirement that the hardware and that everything around that gets better too, because it seems like that's kind of a part of it.

Jen: Yeah. Yeah, and now is the time for folks who are sys admins or do have a login on your website to figure out how to start adding support. Like you said, it will be a transition. You can start to offer to your current users the chance to switch over from using a password to using a passkey. As new users come, if you'd like, you can offer them a choice. You don't have to only offer one thing or the other. In fact, many websites right now have multiple different ways to log in. Passkeys can be a new way to log in.

It's our hope that, over time, it will just be so easy to use and so secure that make people feel really safe and happy about the security that more and more folks will say, "Yeah. Yeah. No, I want the passkey. That's way easier than having to manage a password."

01:11:09

Dave: Well, and I think it's important to say, "My website is not storing somebody's face." [Laughter]

Jen: No.

Dave: I'm just asking the device, "Hey, is this Dave Rupert?" The device is just like, "Yeah, totally, it is." [Laughter]

Jen: Yeah. The website is storing the public key. In fact, that's it. In fact, that means that the website, if you are in charge of the security of some Web servers, you're going to want to get as many of your users as possible off of your current login system into passkeys because--

Dave: Risk mitigation. Instant, right?

Jen: Totally. Yeah. Why is someone going to try to crack your server and hack in and steal your public keys? They can't do anything with all those public keys. Yeah, fantastic. Yeah.

Dave: Wonderful. I think this is revolutionary. I'm excited. I know it was like Edge, old Edge had a version of this that was tied to Windows Hello or something. But it was very, like, I don't know if it's ready for primetime. But I feel like now it's like, okay, this is it. Let's revolutionize logging in. This is wonderful.

Jen: Yeah. In fact, you can go over to the FIDO Alliance website. I'll put a link in your show notes as well for the page that they have about what they call -- about passkeys, which is also known by the nerdier name multidevice FIDO credentials. There are some videos there of them explaining in a lot of detail exactly what's going on with the technology because there are really two specs. There's the Web auth spec, which is what Web developers need to know about. But then there is this other spec that I think is the CTAP2 spec, or something. I forgot to look it up before the show.

It handles the standardization of all of what's going on with the devices and the operating systems, which we Web developers don't really need to understand at all. But there's a standard for that as well. Like, how does this work in all the complicated security folks kind of way?

Yeah. We're all very, very serious about making this pretty fantastic. Completely easy to use for users. And far more secure than anything that we have today.

Chris: I'm very excited about that. We're going to have to leave it at that.

Jen: I know.

Chris: Thinking about the exciting future.

Dave: Yep. We're unfortunately out of time to talk about all the fun stuff in Safari. [Laughter] Jen, thank you for coming on. For people who aren't following you and giving you money, how can they do that?

Jen: Yeah, so one, webkit.org is a fantastic place to learn more. There are articles for each version of Safari that's come out this year. The Safari 15.4 article and the Safari 16 article especially have a ton more information about what's happened.

There's also talks from WWDC. There's an entire talk on what's new in WebKit and Safari where we go through all the things that we just went through and even more (in 40 minutes) because we went really fast in that session.

There's a session on Web Push, Meet Web Push for Safari, which we didn't even have time to talk about. It's coming in Safari 16.

There's also a whole session on passkeys with a lot more detail about how to implement passkeys on your website or your app.

Yeah, on Twitter, @jensimmons. WebKit also has a Twitter account. @webkit is the name of that Twitter account. Bugs.webkit.org is a really good place to go.

This is the one ask I would have of people is if you find a bug that you really think is something that's wrong with WebKit, something in our HTML, CSS, JavaScript implementations, Web API implementations, or there's something that's missing that you would like to have that's out there, go to bugs.webkit.org to file an issue about that technology. Especially what's really helpful is use cases. If there's something that's missing and you would like us to implement it, tell a little story about what it is that you're trying to do and why that's important to your project. Maybe even what you're having to do since you don't have it. It makes your website slower or whatever, tell us the story of why this is important to you. Also, if you have ideas about or bugs, problems with Web Inspector, that's the place to go.

If you have feedback that you'd like to give us about the interface of Safari, like tab groups or bookmarks or other things about Safari itself, bugs or comments or feature requests, you can go to feedbackassistant.apple.com to file issues about the Safari interface itself.

Dave: Awesome. Well, thank you so much, Jen, for coming on. Thank you, dear listener, for downloading this on 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 for tens of tweets a month. And join us in the D-d-d-d-discord, patreon.com/shoptalkshow. Chris, do you got anything else you'd like to say?

Chris: ShopTalkShow.com.