Transcript

[Banjo music]

MANTRA: Just Build Websites!

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

Chris Coyier: Fantastic. Thanks for having me, Dave. Love the show.

Dave: And, Chris, it wouldn't be a January in ShopTalk land without our special friend Jen Simmons.

[Laughter]

Dave: Hey, Jen. How are you?

Jen Simmons: Hello! [Laughter] Is it a January thing?

Dave: Jenuary. We call it Jenuary officially here.

[Laughter]

Jen: Oh, Jenuary.

Dave: No, I was like, "Do we talk to Jen every January?" I think we do, but I don't know for sure. I haven't looked through the archives.

Chris: Unplanned, let's say. But it's great to have you on because you're at Apple now. Kind of a big deal.

Jen: Yeah.

Chris: Not exactly easy to get you Apple people, so thanks for taking the time.

Jen: I'm happy, thrilled to be here.

Chris: Wonderful. You're just a long-time champion for the Web all over the place, so I'm sure we're going to end up getting into all kinds of Web platform features. That's our plan anyway in what's going on all around the Web and then specifically at WebKit and Safari because that's your expertise.

Great. Here's the plan, everybody. We're going to end up talking about Interop because Jen is involved in that and it's just an amazing thing that exists in the Web. Then we're going to end up talking about Safari releases, especially the big December release that kind of just happened because it was a big one and maybe you should know about it. Then generally about other things WebKit is doing and leading the charge in a number of ways.

Let's start with that Interop stuff. They're like calendar year projects, right?

Jen: Yes.

Chris: Straight up 2023 just wrapped.

00:02:04

Jen: Yeah. Really, it's launched, I think, the last couple of years towards the end of January, so I guess it's sort of the beginning of February to the end of January project. But yeah, it goes by calendar year.

Chris: Yeah. Right on.

Jen: We're wrapping up Interop 2023 and Interop 2024, it hasn't been announced yet but it will be at some point soon.

Chris: Yeah, that's cool. We have no idea what it is. It will be... I just can't wait. You know? I'm tapping my fingers together being like, "What's it going to be?"

Somehow, this eluded me until now. The list isn't like four. The list is like 20, right? At least that's what it looks like for Interop 2023. The list is thick.

Jen: Yeah, Interop 2023 ended up being a lot of things. There are 26 focus areas, I think. But if you actually dig into what's inside of each of these focus areas, some of them actually have quite a few things in them, and they may look sort of simple on the label, the outer label, but they're not simple. There are the Web components. There are four major things in there. Or color. I don't even know how many features are in that color bucket.

Chris: Right.

Jen: There actually turned out to be quite a lot of work, quite a lot of tests in 2023 Interop, yeah.

Chris: It's hard to know where it started. Well, it's not hard to know where it started. You can see there's a chart, and the chart goes up.

Jen: Yeah.

Chris: The higher the number, the more interoperable it is. So, I would hope that everybody involved popped a bottle of champagne or something. It worked pretty good.

00:03:38

Jen: I know it's very... These are the best scores so far with passing 99%, 97%, 97% for the three major browsers. And overall, interop is at 95% for the tests that are in this year.

That's one of the things that got added. There's a dashboard. For folks who maybe don't know, Interop is a project that's kind of hosted under the umbrella of Web platform tests but could potentially include other automated testing platforms besides the Web platform tests basically saying, "Hey, how does the Web become the Web, or how does Web technology become Web technology?"

Well, oh, it's by the Web standards process. So, people who make browsers, who care about browsers, who care about Web technology, people who have been involved with the Web for a long time or maybe they make websites, get together and figure out what the future is going to be. They write down exactly how a new Web technology is supposed to work in a highly detailed, technical document called a Web standard.

There's consensus, right? If there's not consensus yet, then it's not a Web standard yet. Or if it's something that one company does on their own, well, of course, they can do that, but that's not a Web standard.

Interop really is about Web standards, the things that have Web standards. Then it's really just a big scoreboard looking at how is everybody doing on the automated tests that exist.

Now, of course, not everything is testable. Also, the platform on which the tests are run is only desktop and it's running... like, virtually it's running older versions of operating systems. There are all these details (if you get into the details) where you're like, "Oh, that's not perfect. But okay, it's not perfect, so it's good enough."

It's basically running all of these tests for all of these different Web technologies that were chosen for Interop 2023. Then it's saying, "What percentage of the tests do you pass?"

Yeah, if you look at the dashboard, there's a button that you can click. You can switch from looking at the stable, what's labeled stable, which basically means the browsers that are in the hands of everyday customers right now, everyday people, or experimental, which means the browsers that are coming in the future. You can look at Chrome versus Chrome Dev or Firefox versus Firefox Nightly or Safari versus Safari Technology Preview.

Chris: What are they; two, three months behind, maybe? Right?

Jen: Yeah. It depends. Well, you know. Sometimes things can sit in a preview browser for a while. It depends. But yeah.

Chris: Okay.

Dave: Like :has() was in Firefox behind a flag for like 12 years [laughter] or something, it feels like.

Jen: Well, for most of the year. Right, so there was a long time where certain things had landed in Chrome Dev behind a flag, but I guess, for Chrome, the flags get flipped when the tests are run. Although for Safari Technology Preview, the flags are not being flipped.

Chris: Oh...

00:06:35

Jen: It's complicated. But what is cool is that, for Interop 2023, we added a fourth column called the Interop Column, which is like, "Well, how many of these tests pass in all three engines?" Then there's a fourth line, this green line.

Chris: Mm-hmm.

Jen: Which in some ways is the one that matters the most, right? If you look at the stable green line at the beginning of the year, 48.7% of the tests that were selected passed in all the browsers. Now, if you look at the end of the year, stable, 95%. So, it went from 48% to 95% improvement.

Dave: Wow. Incredible.

Chris: Yeah, so that's the power of this project is that these things become usable. Then the fallout -- correct me if I'm wrong but feels like is true -- is that just everyday developers like us will make choices to use these things based on their interoperability. I can't go a day without hearing a developer make a thumbs up or thumbs down decision about, "Oh, I'm not going to use OKLCH. That's not supported well enough." You know?

Jen: Yeah.

Chris: It's like, "Okay. You made that choice. That's cool. You've got to do what's right for you." But if they were to look at the data and say, "Oh, it's supported across all the big three, three versions back, sure, I'm happy to use it." That moves the needle on the actual usage of these new features.

Jen: Yeah. I think some of the intention with the new features is to help because a lot of this may be all three engines were going to implement in 2023 anyway, or maybe they were going to... maybe somebody might have done it in the beginning of 2024 but they did it at the end of 2023 instead. Right?

There's a little bit of a "Hey, maybe these things happened when they wouldn't have happened." But I think some of the power with Interop is less about the new things and more about the things that have been around for a while.

Chris: Hmm...

00:08:41

Jen: Like border image is a good example where border-image has been supported in all browsers for a long time. It's basically a way (in CSS) where you can say--

Chris: Yeah. Good luck explaining border image. Yeah, image set is a little different. [Laughter]

Jen: Maybe not. Let me switch. I'm going to switch. [Laughter] Yeah.

Chris: Yeah. [Laughter] Switch.

Jen: Image set is another one, right? Image set isn't on the list but it's in there. It's tucked into one of these areas.

Image set, for instance, if you want to write in your CSS, you want to write background image, but rather than writing one background image, it became one, like, "Oh, I have to pick JPEG or PNG because that's the one image format that's supported in all browsers." Image set gives you a way (a lot like other parts of Web technology) where you can say, "Oh, I actually have three images here. If you know what JPEG XL is, please use that file. If you know what AVIF is, you can use that file. But if you don't know what either one of those are, you could use a JPEG instead." Right?

Chris: Right. It's responsive images for CSS.

Jen: Yeah. That property has been around for many years, but there were little, tiny bits and pieces missing or it was a little bit buggy or it had 80% but that last 20% was the thing that you actually need.

I think there are properties or values or features on the Web where, over the years (for those of us... for any of you who have been making websites for years), you probably have this scar tissue that's built up [laughter] where you tried to use this five years ago but it was really buggy, so you never tried it again. You tried to do this three years ago, but you realized it was only half-baked in one of the browser engines, so you shied away from it for the last three years. Or you tried this other thing ten years ago but it was completely broken, and so you just put it out of your mind.

It's like, "Wait! We should go back and fix those things so that those really good ideas that shipped 5, 10, 15 years ago have now the kind of quality that's expected when anything new ships today," which was different 10, 15 years ago.

Those Web standards were not nearly as technical, nearly as detailed, in the beginning. If you read the CSS 1 spec, or even when it was a CSS 2.1 spec, there was a lot of technical detail missing from it. It was actually impossible for browsers to do things exactly the same as each other because nobody was really sure what that was.

The CSS Working Group spent a really long time with the CSS 2.2 specification. They went back, and they basically rewrote all of CSS and made it incredibly detailed so that every browser could be the same and we could reach interoperability.

In some ways, the Interop project is like, "Oh, wait! Actually, no one has thought about whatever obscure thing that nobody has thought about for years. Let's put that into Interop in the next year, and we'll get everybody working on the same thing. We'll get everybody fixing--"

One of the things, for example, this year is that form controls didn't have support for vertical writing modes. So, you couldn't have a vertical input field.

Chris: Really?!

Jen: You couldn't have a vertical whatever. Yeah.

Chris: Wow.

Jen: Because when forms were built, horizontal writing mode was the only writing mode the Web had. So, it was like, "Hey, we need to circle back around and fix this," so we did. Now you can create vertical forms, vertical writing modes in forms.

Chris: Wow.

Dave: That's cool.

00:12:04

[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by Jam. That's jam.dev. Awesome URL. Go to jam.dev/shop.

A really clever bug reporting tool, and it's for internally on teams. Imagine you're in Slack with a fellow developer and they send you a thing like, "Oh, on the item page, that's broken," or something.

I'm super guilty of sending this to people I work with. Just thinking in my head, like, "Well, just go to the item page and look. Then you'll see the error, too, if you're on my branch or you've pulled master or whatever."

But maybe they don't see it. That's not enough information.

What if it was effortless to still be that lazy but also give that other developer all the information they could need to make sure that they can reproduce that bug because it's just as easy as taking a screenshot. If you see the bug and it's visual in some way, which that's my job in the world, you drag a screenshot over it in the browser. Then you can optionally annotate it, like point at it or write something if you need to or whatever. But you don't even have to do that.

But virtue of you having done it in the browser, you get all this additional information, like all the console output is there. If there's an error in the console, which is highly likely in a JavaScript application, they'll see that without you having to remember to screenshot that or copy and paste it or whatever, and the network requests, and all the information about the browser that you are in at the moment, and version, and on what operating system and device and all that stuff.

Reproduction steps. You can add comments to it, too. But what you have to do is just take a screenshot quick and be like, "This is a bug." Effortlessly small. What a clever product. Then that becomes the bug report.

Check it all out at jam.dev/shop. I love it!

[Banjo music stops]

00:14:04

Chris: Looking through the 2024 list -- I don't know how far we want to jump ahead -- it feels like there's new stuff and, like you said, there's some older stuff, too. There's stuff in there that's like I haven't thought of that in a minute.

Then maybe in between, too. There's the ATTR (the attribute function) in CSS. Who has thought of that in a million years?

Dave: Me. Me.

Chris: Yeah. [Laughter]

[Laughter]

Chris: I know that the reason it's in there is because it's about extending its functionality rather than just fixing bugs. But it's still a pretty old-school thing to be in there, and that's cool. Maybe it'll make the list. We'll see.

Jen: Yeah. Some of the things are old things that were specified a long time ago but haven't actually been implemented by anybody. And other things are things that have brand-new specs. And other things are things that, yeah, they're either implemented or they're unevenly implemented but they need work. In some way, they need work.

Chris: While I was thinking about this, I get this email from an old conference organizer guy. He's like, "Oh, I'm doing a website for my school and there's something--" Part of the Web app where you have to set an emergency contact for the students or something.

He's like, "Is there some way I can just open up my contacts and just pick it and then it'll prefill all the fields in there from my contact?"

I'm like, "Well, there is but..." it's like Chrome on Android only - or something like that. You're like, "Oh, that's too bad."

It made me want to vote for it for Interop, but it's not even on there because somebody like me who just had it top of mind would have had to have submitted a ticket for it and stuff. Whatever. I'm not going to cry about it, but if I think of it next year, I'm going to write up a little ticket for it. Why not?

Jen: Yeah. Well, people should. All year, this year, while you're working on things, if you run to cross a Web technology that you think, "Gosh, this is still, even in 2024, really buggy and it's frustrating because it works differently in different browsers. Not just that it's missing from a browser but that it's in all the browsers but still there seems to be something wrong with it," write down some notes and then, next fall, there will be an open call for proposals.

Anybody is welcome to submit a proposal. You just submit it by creating a GitHub issue on the right, GitHub repository.

Chris: Yeah.

Jen: Putting in a lot of information, right? We need some details about does it really have a spec. It's not a place for new ideas. It's a place for, "Hey, let's take the automated test for this thing that already exists and let's put them on the scoreboard.

Chris: Yeah, exactly. I think I mentioned that before the show.

Jen: Yeah.

Chris: I saw you chiming in a bunch. It took that to make me understand this fully. But this is absolutely not the place to propose new Web platform features.

Jen: Right.

Chris: There are places for that. Interop is not one of them. Interop requires at least an existing spec, if not a good one.

00:16:58

Jen: Well, and it requires consensus. It requires for it to not only be a spec but for it to be a real Web standard at a certain level of maturity. So, if it is a thing where there's still a big debate about it where there's not really agreement, like you might notice that CSS nesting is not in Interop 2023 where, if you think back to the timing of it, you might thing, "Well, why not? It should have been." But it wasn't. The spec was still under hot debate a year ago, and so it couldn't be part of Interop 2023 because it's not for brand-new, half-baked things.

It's for standards, where the Web standard is half-baked. It's for things where... It's so hard to explain, too.

Dave: It's like existing things, right?

Jen: Yeah.

Dave: It's not speculative things. It's existing things. I see it as a shared roadmap. You can, of course, have your own internal roadmap, but a shared roadmap. There's something very powerful about three browsers here -- four browsers, I guess, if we count Edge -- coming together and saying, "Generally, we're working on this stuff, the same stuff."

It's really powerful. It just gives me a lot of confidence as a developer that I'd be able to use something in the future.

Jen: Yeah.

Chris: Yeah.

Dave: I can ship it today and it's probably going to show up within six months. :has() is a great example. It was like, "Well, I could just do it [laughter] and it's probably going to show up." That feels really good.

Jen: Yeah.

Chris: That's the best is the feeling about this all because it's like if this didn't exist, we would just be like... I don't know. It'd feel like we'd have to just complain or something to get interop stuff fixed or... I don't know what it was.

You just kind of assume that it's going to get better over time. But maybe it will, maybe it won't.

Dave: Yeah.

Chris: But it's nice, and it's nice to see how thick the list is. I don't know how much behind the scenes you know. Do you think the list will be as beefy this year as it was in 2023?

00:19:11

Jen: I mean, yeah, it is Microsoft as well, right? I was saying before (in at least the 2023 dashboard), there are three big numbers for the three major engines. Although, that may change.

But Edge, Microsoft, is definitely involved. Also, Boku and Igalia. So, it's really six companies that make browsers because all six of those companies, they're working on three engines but there are six companies working on three engines.

There are also many other people who work on those engines as well. There are many, many more companies than just those six. But those are the six that are involved in Interop.

Yeah, it is about those six teams coming together and saying, "These are the things that we think are most important to strive for interoperability on: driving down bugs, improving implementations, making sure that these new things that we're already working on are implemented interoperably from day one."

I do think that there is a way in which too many things is counterproductive, which may seem weird. Why not just put every Web standard ever into Interop? It's like, "Well, that's why there are Web standards." Literally, the whole point of them being Web standards is because we're starving for interoperability. But given the reality of what it means to run an engineering team and set priorities and have many, many, many considerations that you're trying to balance, I think the real power for Interop is when it's honed, when it's focused.

There is a way in which... :has() is awesome. It's passing 100% of tests. Some of these others are not passing 100% of tests.

It's like, "Well, do you want to take your engineering team off of building a new feature that everybody is talking about that's not part of Interop that everybody wants, or fixing something else which may be not part of Interop but needs attention in this particular browser that that team is working on, or do you want them to try to get the 97.8% score to a 98.5% score in order to get--?"

There's a way in which the gamification of this dashboard can become too disruptive. I think there's a balance there.

Chris: Yeah.

Jen: It has to be focused. If there were 50 things--

Chris: It's not really a project if you said, "How about Interop 2024 is everything?!"

Jen: Yeah.

Chris: You can't. There's no focus there. Anyway, what are your votes? I'm sure you have favorites.

00:21:40

Jen: Yeah. There are all kinds of good things. I think some of the ones that stand out to me, though, so the other thing that Interop does is have what are called investigation projects, which is just homework for the team that runs the Interop project to do stuff so that next year--

One of the investigation projects this year... sorry, last year in 2023... was to figure out how to test on a mobile operating system so that we can test not just desktop browsers but test the mobile browsers as well. That got... I don't know. There's a percent. They got 70% done, so they're not done yet. We don't have that infrastructure yet, but they're working on it.

One of the other projects last year was, "Hey, you know what? We need accessibility tests. We need more tests for accessibility features." And so, those got written. I think, in fact, some folks at Apple were driving that project, some of our accessibility team really working hard to write a whole pile of tests that never existed before.

Web platform tests are not just good for interop. They're the tests that many browser engineers use when building every feature. There are 1.8 million Web platform tests and interop is 400 of them or something. I made that number up, but it's a tiny, tiny fraction.

Having accessibility tests in the Web platform is already... Web platform tests are already really good and important. But also, it'd be cool for those to be part of Interop.

The other thing, one of the things that has stood out to me and I've thought about this past year because, across 2023, we worked really hard on our implementation of display contents to get it the kind of accessibility it needs to be safe to use. We're almost all the way there. You can use it on almost every single element ever except I know the last work to land was around tables. I don't know why you would even apply display contents to a table element.

Chris: I kind of get it because if you're trying to do the thing where it's a table at desktop but it's not table-y on mobile, you have all these layers to fight through on your way up from a cell. If you just wipe them out with display contents, there's less work to do - or something.

Jen: That's true. That is true. We fixed that in Safari 17.0 back in September, but I think buttons, I think we still have buttons left to fix.

Chris: I think this is awesome. I totally agree with you on this being so important. I got worried this year because there was some developer sentiment that went around about display contents because some things were fixed, which is good. It's good to see forward. Some things regressed, and that there was sentiment that was like, "I won't trust it ever. Not only will I not use it not. I will never trust it ever again because of these regressions." That is dangerous.

If developer sentiment towards the Web starts getting like, "Even though it's 100% good to use, I don't trust to use it," I feel like there's something guttery dangerous about developer sentiment heading in that direction.

Jen: Yeah.

Chris: To tackle this one wholly and just wipe it out and have it be perfectly workable is important to do.

Jen: Yeah. Yeah.

00:25:03

Dave: I'm on team fix any of these accessibility things. It's that thing where it's just enough outside of your day-to-day that you either aren't up to date on everything or it's that thing where it's like in one screen reader something behaves weird. I know that's maybe not the focus, but if there was just a consistent API across a consistent browser baseline because it's always in - whatever - Firefox, in Jaws that doesn't do this and Chrome on this it does this. That's just too much for me to deal with. [Laughter] Any sort of ironing those wrinkles would be--

Chris: Isn't there some implied accessibility, too, that Web platform features tend to be more accessible than whatever alternative way you would have implemented it? I think of something like anchor positioning or something where you've got to use a bunch of JavaScript and it's error-prone and blah-blah-blah. But if you just use the browser one, chances are it will be done better. The chances are a lot higher it'll be done better. Even though that's not an accessibility feature that you would normally think of, it has accessibility implications.

Jen: Yeah. That's the promise, right?

Chris: Yeah.

00:26:21

Jen: That's what's so interesting about the search element, the new... It's just so fun to be like, "Oh, my gosh. I need to write about a brand new HTML element? When was the last time we had a brand new HTML element?" when we shipped search in September in Safari 10.2. Because a search element, in some ways, is like, "What does it do? It doesn't do much." Well, it automatically applies the correct ARIA role to your search element.

And that's the promise of the Web is that if you use the correct HTML at the correct moments, then you as a developer don't have to really think about ARIA or accessibility. It's going to just work.

Chris: I always liked that ARIA rule where it's like you should try to not use ARIA roles. That's better. And so, if you're going to give people that advice, well, the right HTML element better exist then.

Jen: Right. It was almost like someone came across it and was like, "Oh, wait a minute. Uh... This is a situation where people have to know to apply an ARIA role or else it's broken. We can't have that. We need to... No. No. We're making a new element."

Chris: I watched a video on it, and they were like, "You don't need to use the form tag anymore. You just use the search tag." I was like, "Oh, no!"

You'd have one of those, like, "Just let people be wrong on the Internet. It's okay."

[Laughter]

Dave: Oh, boy.

Jen: Yeah.

Dave: Patience of Christ.

[Laughter]

Dave: Give me strength.

00:27:42

Chris: Yes. So, lots of votes. I did this thing where I tallied up the popular vote; not to influence anything. I just thought it was interesting to see how many emojis were on all these things.

The JPEG XL somehow just has four times as many votes as any other one, so we'll see if that actually influences things and makes the list or not. I do think it's cool. I don't know that I would even make it top ten. Performance is great and all, but that's just a personal feeling.

Jen: The cool thing about JPEG XL, and this is the thing where I worry a little bit. I want to make sure that the whole new world, all the new generation of Web developers and such, kind of get the message of progressive enhancement. So many people have been singing that song for so many years where it's okay if JPEG XL is only in one browser. You can still use it. It's still awesome. You can still give the users who are using Safari that benefit, and other browsers can load other formatted images. They can load the AVIF, or another browser can load the original JPEG, that image source, like, use the picture, use a source element.

Meanwhile, one of the interesting things about JPEG XL is that you can take your existing JPEG files on your server, and you can just recompress them all. They'll probably be, on average, 20% smaller than they were before without losing any quality. Then you can just change the robots that serve up your content to your website and get it to add a list for your JXL files, keep the JPEG files in there as well, and a little bit of server-side effort, and all your images are 20% smaller. That's huge.

Chris: Right. The bang for the buck here is a lot of bang, a little buck.

Jen: Yeah.

Chris: It is worth it. That is a good point.

Jen: I think, if you had the original image, and you compress it into JPEG for those folks who need it, and you also compress it into JXL for folks who have a browser that supports JPEG XL, then it could be 60% smaller, like less than half the size.

Chris: Really?! Wait. One more time on that. How does that work?

00:30:03

Jen: If you take the original image file and you compress a regular JPEG and you compress a JPEG XL file, you put them side by side, you get the same quality, the same everything. The JPEG XL file, on average, would be 60% smaller than the JPEG.

Chris: Rather than taking one that's already been compressed and recompressing it?

Jen: Yeah. Yeah, yeah.

Chris: Okay. Wow!

Jen: Yeah, yeah.

Chris: If you did the smart thing and kept all your originals, you're going to be in good shape.

Jen: Right. If you have all your originals, which... I mean you know. But going forward, if you... This, I think, especially because a lot of folks use some kind of service to be a CDN.

Chris: Right.

Jen: And the people who make content are just uploading a giant original file, and then there are magical robots in the cloud that compress all the files into multiple formats.

Chris: I make it a mandate at CodePen when we make our weekly email that goes out. There are ten 600x600 graphics. I'm almost like, "Don't run it through your local thing first. Just upload it to our cloud thing exactly as you got it."

Jen: Yeah.

Chris: Because we have a machine that compresses them and they'll get smarter over time. That's exactly why is because the closer you have to the original, the more future benefit you're going to get.

Jen: Yeah.

Chris: I didn't know that about JPEG XL, though. That's wild, 60%.

Jen: Sixty, yes, 60% smaller. AVIF is also a fantastic format. There are times... I think it's good that the Web has multiple formats because then you can kind of figure out which one is the--

If you hand-bespoke creating images, you can figure out which one is the best for that situation. If you are setting up a system to go through images, then people can spend a lot of time figuring out how they want to configure that system and they've got options. It's not like we have to pick only one format to be the king. No, we're going to have multiple formats. It's good that way.

Chris: Right. Cloudinary famously has F-auto. It doesn't say FAVIF. Their promise as a company is, "We will pick the one that is the best for you," and then make that their responsibility, which is cool.

00:31:59

Jen: Yeah, so JPEG XL has the benefit of JPEG, which is that it can progressively load. If it's a slow connection, you can see the image as it's coming in.

Chris: Do you think that's important? I'm not criticizing it. I just am like, "How--?" That's opposed to blurry of the whole thing and then it kind of sharpening over time. Isn't that the alternative?

Jen: Oh, I thought the alternative was just it appears? You get nothing, nothing, nothing, and then it's there. But you know what? Maybe I'm wrong. Maybe I should go find out.

Chris: I don't know either. I'm not trying to... I don't know.

Jen: I think we're spoiled living in a world of very fast Internet connections because they just pop in.

Chris: Right.

Jen: But for any of us who remember being on dial-up modems, it really made a difference to have progressively loaded images.

Chris: It did.

Jen: And the whole world is not--

Chris: Yeah. I think I preferred then the line-by-line. It was more exciting.

[Laughter]

Dave: Just one line, one line, one line.

Chris: Yeah.

Dave: Yeah.

Jen: Sometimes people make a giant image and turn that into a movie experience, like, "Welcome to my website. Watch this image load for the next ten seconds."

Chris: Yeah. [Laughter]

Jen: [Laughter]

Chris: Oh, yeah.

Jen: The '90s.

Chris: You could make it very dramatic.

Jen: Yeah. I guess there's a debate to be had there, some research to find out when you're working on a particular project. What kind of difference would that make for the market that you actually have?

Chris: I wanted to... I have my own list of votes, but it's making me almost self-conscious about it because my tendency is to vote for new and exciting things, even though I just told the whole story about the contact picker API and stuff, and I might vote for that. I think, months ago, when I was thinking of my list, I was like, "View transitions." My whole list was just new stuff--

Jen: Yeah.

Chris: --because they were top of mind kind of things. I might have to reevaluate that, not that it will have any influence. But I still really like Interop. It's a cool project.

Jen: Well, and there are 91 proposals, so... spoiler alert. We're not going to pick anywhere near 91. [Laughter]

Chris: No.

Jen: it's going to be a small subset.

Chris: They're not what you think, too. When you get down into the five votes category, you're like, "What even is that? I don't even know what that is." [Laughter]

Jen: Yeah.

Chris: I'm sure they're extremely important to some people and not so much to the general.

Dave: Well, and you can't do it on a pure popularity contest because a Japanese language feature is not going to be as popular as view transitions just because the number of people that speak Japanese globally and vote on a little GitHub issue is very small compared to the number of people who use view transitions or want it.

Jen: Yeah. Yeah, you can't run an English language survey to find out how people like CJK and then not run it in Chinese, Japanese, or Korean.

Chris: Yeah. Fair enough.

Dave: Yeah. There might be some bias in the whole system.

Chris: A little bit. Good point.

Dave: Yeah. Yeah. [Laughter]

Jen: Yeah, and some of these, you know, might not get chosen because they might have gained interoperability between when they were proposed in August or September and then by the time the decisions got made later. You look at the test results, and you're like, "Oh, this doesn't need to be in here anymore. This is already done."

Chris: Well, stay tuned for the results. I'm sure it will be all over the news. We'll mention it when the things come out. Again, it's not overnight all those things are fixed. Then we just get to watch the dashboard over the year and such. But it'll be cool to see.

We should move over. One of the things we wanted to talk about was WebKit release velocity and Safari 17.1 and 17.2 and all that.

Developers be developers, there was definitely a time where, once IE has been wiped from our minds. You hardly ever hear about IE anymore. The interim joke was Safari is the new IE. I'm sure you heard that many times internally and externally.

Jen: Oh, did I? [Laughter]

[Laughter]

Chris: That was out there, though. I feel like it's starting to go away. You wanted to make sure that that wasn't true, you and everybody else over there, I'm sure. I think you've done it because I don't really hear that anymore.

00:36:12

Jen: It's so good to hear that. We've certainly been listening to everything everyone said. I remember. I think both of you wrote blog posts at a time when there were a lot of blog posts coming out (as well as, of course, a lot of tweets). And this is when Twitter still existed.

I think it was the summer of 2021, maybe, when Safari 15.0 was in beta and people were disappointed that there weren't more features being announced. There were lists made of saying, "This is what we need and here's why."

I remember your blog post, Dave, especially. You articulated the idea yourself that, "Hey, I don't want to just complain. I want to actually put together a list of why. This is what I need. Here's why I need it. Here's the situation. This is the kind of website I'm trying to build. And this is the problem that's getting caused by not having the support."

There was a lot of communication coming in from many, many different people, and that does move the needle. People wonder now, like, "What happened?" It's like, "Well, you told us what you needed and we were listening. Now we did it."

We really went, especially across 2023. We wanted to burn down as much of that list as we possibly could and make sure because we want the websites and the Web apps that everybody is making to work really well in Safari. We want people who use Safari to go to the websites they want to go to and have a great experience. For us to help you do that, that's what we want to be doing.

Chris: The frustration might have been compounded by, like, "Oh, it doesn't have this stuff and we're used to the yearly release cycle." The fact that it doesn't have it now means that, at best, we're going to get it a year from now.

Jen: Yeah.

Chris: That was a bummer, too. Those expectations were changed as well because, what it is now, three months, two months? I don't even know. Sometimes it's even faster than that, isn't it?

00:38:16

Jen: Yeah, I would love people to really get it that Safari comes out at least seven times a year. That decimal point and the number after the decimal point matters, so it's number 16.0, 16.1, 16.2, 16.3. I think we went to 16.6 and then 17.0 was the next version of Safari, so that's seven versions of Safari 16 that came out.

Chris: The big number tends to go with the operating system still, right?

Jen: Yeah. The big number tends to go with... At least the last couple of years, it's tended to go with, "Hey, there's a big, new operating system coming out. We've got MacOS Sonoma in iOS 17, and there are new features like...."

Chris: The doc thing was big - or whatever.

Jen: Yeah, right. There are a lot of new features for everyday people to talk about. And so, those tend to come out when the big number changes, I guess, is how you could think about it. But actually, Safari was coming out more than once a year before that.

I think you're right that people didn't know it and their perception was that "Hey, Safari 12, 13, 14, 15, that's it. There are no other times." But the truth is that Safari 12.1, 10.1, 11.1, 12.1, 13.1, 14.1 were actually really big releases, and sometimes there'd be more Web technology in something like Safari 12.1 than there was necessarily in Safari 12. But because of the way it was numbered, those just kind of got lost, I guess.

We've also put a lot of effort into making sure that we've got comprehensive release notes where everything, every single solitary thing, every feature, every bug fix that is relevant to Web developers is documented, which before I think it was more like, "Hey, let's hit all the highlights of the new features because they're awesome," and there wasn't a lot of trying to make a list of every bug fix ever. [Laughter]

00:40:21

Dave: That's been the biggest improvement for me because it was a lot of mental effort and cognitive load to figure out, okay, what's Safari got in this one? These docs, the release notes, I'm subscribed to my RSS reader of choice. I get them. I can slowly go through them. It's amazing. it's incredible. I think this last one you said was a very huge one [laughter], a very huge release.

Jen: Yeah.

Dave: There are all these features that are here. Yeah, I just spent a lot of energy. In fact, my post two years ago, I had to look it up, but it was--

Chris: We do. Look at your list, Dave. Is the whole thing knocked off or no?

Dave: Mostly. Well, my biggest thing was there's stuff, like old Safari stuff, and I think a lot of that is gone, like old WebKit prefixes. Then there was stuff, so stuff I do just for Safari, stuff like Safari doesn't have, and I think that's gotten way better. Then stuff like Safari has but I didn't know that and now I need to reprogram my brain that Safari has this.

Jen: Yeah.

Dave: I think the communication has gotten way better than it was because I wasn't having to piece it together myself. It's now just in a very well-formatted blog post, and that's huge.

Chris: With embedded Pens from CodePen.

Dave: With embedded Pens.

Jen: Yeah.

[Laughter]

Dave: That little twist is huge. Yeah, visual. Visual, right? If somebody just write, "Fixed :has()," or whatever, I'm like, "I don't care." But when there's a demo that goes with it, that's huge.

00:42:00

Jen: Yeah. Well, and I think it became apparent that there were also things that Safari definitely had that people don't know about, and that was causing some of the frustration.

I remember, for a while there, getting asked pretty regularly why we hadn't shipped WebP yet, and I was like, "We shipped it two years ago." What's going on that we literally shipped WebP two years and yet people are coming quite spicy complaining about not having WebP.

It was like, okay, well, let's... And we realized, oh, a lot of the data on, "Can I use an MDN BCD (browser compatibility data)?" is not accurate. Those projects are... Especially, "Can I use this?" run by volunteers, right?

We're like, okay, well, what can we do to make sure that that data is more accurate? We've put a lot of effort into helping make sure that if someone... If a developer wants to know and you go to caniuse.com and you look something up, the results are coming from two different places: one is the Can I Use data and one is the MDN BCD data.

There's still, especially the MDN BCD data, because it's so huge, it goes into so much detail, there are still a lot of things that are inaccurate. But we're just working on drilling that down to where we can get it as close to perfect as possible because it makes sense. You want to know if something is supported. You look it up. It says it's not supported. You believe it. [Laughter] You don't actually go build your own test, unit test, and then run the unit test.

Chris: Yeah, rarely.

Jen: And then double check.

Chris: I feel like, in my prime, I used to. But now I'm too tired.

[Laughter]

Dave: You had 20 Pens that you just riffled through. Yeah. Yeah.

Jen: Yeah, but there are two really... well, maybe... There are a couple of different places people can go if they want to stay up on what's going on.

One of them is every time a new beta comes out, there are comprehensive release notes that go with that beta. Then across the period of the beta, things are going to change. There might be a feature that we put in the beta but actually needs a little bit more polish, so it gets removed. Or there are new things that hadn't landed in the first beta but they landed in the second or third beta - or whatever. They get added.

Then when that version of Safari ships, those release notes are updated with any changes that need to be made and published as the sort of final official release notes. Those all live on developer.apple.com. If you just search for Safari 17.2 release notes, you'll probably find a link to get to the right page on developer.apple.com.

If you want to go back in time, you can see release notes. I think they go all the way back to like Safari 12.

Then the other place, you were describing this, which is at webkit.org. We put out a big article every time there is a new release of Safari, especially for the fall release and for the December release and the spring release - at least in the last year. It was the March release, the June announcement for the beta of the fall release, and then the fall release in that September. Then that December release in 2023.

00:45:04

Chris: Let's just do it. It'll make great radio.

Jen: [Laughter]

Chris: The latest release, it starts with exclusive accordions, which is so bizarre to me. That seems like everybody... That just came out of nowhere to me. All the browsers are like, "We have this thing now you can make an accordion by putting the name attribute on the details." [Laughter]

Jen: [Laughter]

Chris: Then only one can be open at a time. We're all like, "Wow! Okay." Pretty cool. It solves a pattern that we'd use JavaScript for, so rock-n-roll. It was a good lead because it was kind of surprising.

Jen: Yeah.

Chris: Like, "Here's a present."

Jen: Yeah.

Chris: Just kind of cool. One-time codes, which is the attribute that says this is going to be one of those things where you get a text with 8371, and it's got to go in there, like having the semantics to put that in there. So, theoretically, browsers....

Jen: Yeah, or an email. On Apple devices now, if you get an email with a one-time code and the website is built properly, it will fit, automatically just fill that code in for you and move you on.

Chris: It'll just slide right in there like it does on iOS?

Jen: Yes. You don't have to go to your email and open your email and all that stuff. You can just... Yeah.

Chris: Juicy. That's nice that it does it on desktop, too. For people that don't do daily driver Safari, I have a cool app called Message Decoder that does it in any app.

Jen: It's worked in Safari for a long time. But this thing in 17.2 added it for WKWebView, which means it gets added for other apps, other apps that use WKWebView to display Web technology.

Chris: All right. Nesting came out, too. Not just all nesting, but the final - the final nesting.

Jen: It shipped. Nesting shipped in Safari 16.5, but this is the update to nesting to get rid of the requirement to have an ampersand before an element selector and that kind of stuff. It made it easier to use.

Chris: Yeah, love it. Just yesterday, I saw some pushback that said, "Just nesting is bad, but if it had BEM, then I would like it," like the style where you smash them together, which is the stupid one thing it can't do where you can't put an ampersand and no space and have it just concatenate the names. Anyway, I was like, "I disagree."

Dave: Send them to me, dude. I'm going to... No. Send them my way.

Chris: It's the worst.

Dave: I'm going to literally--

Chris: I couldn't disagree more.

Dave: --bully them on the Internet. Jeez Louise.

Chris: [Laughter] Anyway, excellent job with that. I know you're involved with nesting and the final result there is tremendous, I think.

Jen: Yeah.

00:47:31

Chris: A bunch of new units that I'll need to read about and don't want to embarrass myself on the radio about because I've never heard of them before.

Jen: Oh, and they're cool! There are cool units. Yeah, there are root-level units.

You know the difference between M and REM, right?

Chris: Yeah. Yeah.

Dave: Mm-hmm. Mm-hmm.

Jen: That little bar ... level. There's now the cap unit, the X unit, the IC unit, and the CH unit also have root-level units now. Cap is like the cap height. X is the X height, which are things that again because of a lack of interoperability, because "I think this might be dodgy. I'm scared to use it," these things have been around for many, many years but people don't use them. But actually, you could do some gorgeous typography by setting - I don't know - your line height to be an increment of your cap unit or something. I don't know.

There's a CH unit, which is the width or the height of the zero character of the font depth. IC unit is for CJK (Chinese, Japanese, and Korean). IEU graphic character, the IEU graphic is the I and character is the C if you want to measure out, which especially is important in CJK typography (especially in Japanese where people want everything to be exactly the right width and exactly the right number of characters and stuff). Those units give you access to all of that, and you can set root-level units to that now, too.

That was way too long of an explanation, but I get excited about the typography units.

Chris: No, it's cool. Units are unreplicatable, so I'm excited about that, too. It's no something that you could do some other way and it's just handy.

Jen: Yeah.

Chris: You just can't have this data. It's the only place this data exists.

Jen: Well, and by themselves, they don't really... "Okay. Whatever. I can make a root character unit. I don't care."

But if you start to think about what you would do with it, and then you start realizing the line height unit, which came out earlier in the year--

Chris: That one, I love that.

Jen: --and the root line height unit, now you can start making some vertical rhythm and some gorgeous... Make your margins around your image be the same distance as your line heights, those distances between your lines.

Dave: Are you saying padding bottom one REM is just faking it? [Laughter]

Jen: Yeah.

Chris: No, Dave.

Jen: Yeah.

Chris: I need that.

Dave: It kind of is. Yeah.

Chris: What if you downloaded a font off of, like, DaFont, like cowboy bleeding bebop or something? Is that going to have the right--? Is it going to have--? Where does cap come from? There's something distrustful in my brain, like, "Does this font even expose that data?"

00:49:57

Jen: Well, yeah. No, you're right because there are data tables that fonts are supposed to have and fill out with all the right metrics. But humans, they're very uneven, so a higher quality font will have all of those metrics filled out properly and a lower quality font often won't.

Chris: Will not.

Jen: But then you start to get into, well, what are some solutions to that? That's just to get into the future of what was called letting trim becoming textbox trim and textbox edge. Textbox edge is super interesting. There's some discussion happening right now about how to solve because line height actually has a bunch of extra space above and below the ink of the characters. What's that doing there? You can't really make gorgeous rhythms if you have all that extra janky white space all over and you don't know how big that it. It's different sizes for different fonts.

There are some things coming in the future that we're implementing in Safari Technology Preview and helping work on the specs for.

Chris: I think that is on the Interop list. Trim, one of the trims is.

Jen: Hmm... That it might have gotten proposed for '24? Yeah.

Chris: Yeah. But maybe it's not ready yet.

Jen: There's still spec work going on around it, which is why we haven't shipped it yet, especially around... Textbox trim makes sense because you can trim off. But textbox edge is still kind of--

Chris: Yeah. I've never even heard of that one. I'll have to just wait.

Dave: Yeah. It's like the rag on the side, or the inline, kind of - or something.

Jen: Well, I think about it like this. You know what box sizing border box does?

Chris: Mm-hmm.

Dave: Mm-hmm.

Jen: In that it switches you into a ... box sizing model where box-sizing content-box is the actual default, so you have to do it on every document. I feel like textbox edge is going to be the next box sizing border box.

Chris: Oh, really? Juicy.

Jen: Actually, it's going to switch the line layout model from the original one, which totally made sense but also has problems, into a brand new line box layout model.

Dave: Ooh... That's good.

Chris: That is good.

Dave: Looking forward to it.

Chris: There's some new motion stuff like linear, which allows you to... I don't know. I can't mouth blog it but put a whole bunch of numbers in of how something should ease, which I feel like is a horrible name because it's not linear.

Jen: Yeah.

Chris: Yeah, anyway.

00:52:09

Jen: What happened here is that motion path became part of Interop 2023.

Chris: Hmm...

Jen: And so, different browsers were completing their implementations and, along the way, were like, "Is this really what we want?" And so, the spec got revised and a whole bunch of stuff changed. This here in Safari 17.2 is us implementing because we had actually already... We thought we were done, but then the spec got better, so then this is us updating to the latest version of the spec.

Motion path was kind of not implemented everywhere (two or three years ago - or whatever). Then it was. I think, maybe... I'd have to look up ... to get the data. But because it became part of Interop, now it's in a much, much, much better place in all the browsers.

Chris: Yeah, that's awesome. It looks like masks got un-prefixed. That's kick-ass. That was really holding on for a while there.

Jen: Yeah.

Chris: But that's nice. It looks like it's fancier, too. A little extra stuff you can do with masking.

Jen: Yeah. I think we were the first browser to un-prefix it, and hopefully, everybody else will get it all done, too.

Chris: There's some cool irony there where other browsers sometimes implement the WebKit prefix.

Jen: Yeah.

Chris: But we'll still have to prefix... You'll have to use the WebKit prefix for Firefox. [Laughter] That's real weird. How did we get there? But it's kind of the last one, so if it's a weird ending to prefixes, that's cool.

Jen: Yeah. I mean we don't do that anymore. Now we use feature flags.

Chris: Yeah.

Jen: This problem is going away.

Chris: Better. Better world. Okay. Anyway, that was... This blog post just keeps going and going.

Jen: Yeah.

Dave: CSS got a round function, which is incredible.

Chris: Oh, yeah. We're all about that.

Jen: I love it.

Chris: It's so cool.

Jen: I love round so much.

Dave: I just think it's... I think I literally read a tweet, like, "CSS is not a programming language because it doesn't have a round function," or something. I literally saw that, and then [laughter], shortly, round comes out, and I'm like, "Hey, uh... I guess it's officially a programming language. You can round things. So, there you go."

Jen: I made a demo with round, the round function, basically saying it's a responsive column where it's totally fluid, except I want it to round off to the nearest five REMs or the nearest ten characters or something. You could say, "Hey, be a fluid box." If I grab the side of the browser and move it back and forth, you're going to get bigger and smaller and bigger and smaller. Except, rather than clicking through every single solitary pixel on the screen, I want you to jump to the nearest tenth character, so you can be 50 characters wide, you can be 60 characters wide, you can be 70 characters wide, et cetera. But you can't be 55.2 characters wide.

Dave: Oh, that's really good. Wow.

Jen: Then I just sat there and thought about that for a week. I was like, "What would we have made of that back ten years ago when we were all at An Event Apart watching people talk about responsive Web design on stage debating responsive fluid versus adaptive, like fixed jumping from one fixed size to another fixed size and be like, "Well, you could do this thing in between where it's fluid except it's not completely fluid. It jumps."

Chris: Yeah. What was the name for that? Adaptive or something.

Dave: Adaptive.

Chris: Yeah.

Dave: Yeah.

Jen: Yeah.

Dave: And it's like squishy but not. I like it. If you want to keep... or you have designers who only want certain size columns--

Jen: Yeah.

Dave: ...columns, it's pretty cool.

Chris: Yeah. That word didn't... It kind of caught on but not as much as the others. But it just kind of got morphed into, like, people still do it. You just don't call it that.

Jen: Yeah.

00:55:34

Chris: Yeah, I was thinking of gaming where now, with round, you can do things that are -- I don't know. Think of a game where you're building a farm or something and you're dragging. I'm going to build the cow barn right here. You have this opportunity to say, "Only allow it to put it on this."

Jen: Oh, yeah.

Chris: Anything that's grid-based, round is going to be awesome for.

Jen: Snap to a specific location.

Chris: You don't have to drag stuff pixel by pixel. Yeah, right there is the only place.

Jen: Yeah.

Dave: Yeah. There's some cool stuff on the JavaScript front. Import attributes are going to be useful.

Chris: JSON.

Dave: Width type JSON.

Chris: Yay!

Dave: That's going to be cool. Anyway, this is really cool. We could read the blog post, I guess.

[Laughter]

Dave: Or do a dramatic reading. We'll hire Jeremy Keith to do that. No, this is just an incredible set of features here.

Chris: I know you're excited, Dave, to talk about this pushing first thing because we only have five minutes left. Can we talk about some of that?

Jen: Yeah.

00:56:38

Dave: Well, so, yeah. The one thing that opened my eyes in one of the blog posts was input type=checkbox switch.

Jen: Yes.

Dave: I was like, "What's this?"

Jen: Yes.

Dave: It's to turn your input checkboxes into those little cool toggle switches, right?

Jen: Yep. That's the other thing that you can find at webkit.org. I really do hope that people go to that website and read the blogs because we put a lot of time into these release blog posts to teach because I don't want to assume that anybody knows anything. I want to teach you what this is so that you at least know enough to know what it is. Then you can go learn more about how to use it.

There's also Safari Technology Preview release notes. So, every time Safari Technology Preview comes out, which you might have noticed lately in the last year or so, tends to be every two weeks, like every other week. Maybe not. We may skip a week for a holiday or something. But basically, every other week.

Yeah, switch control showed up in Safari Technology Preview recently where you write input type=checkbox, just like normal so that there's a good fallback. This is how HTML works. You need a fallback for browsers that don't have support.

Then you just add a switch attribute. And so, for browsers that do have support, the switch attribute makes checkbox go away and it turns it into a switch.

On WebKit, in WebKit on Safari platforms or, I'm sorry, on Apple platforms (iOS, iPad OS, MacOS, Envision OS soon), it will, by default, look like that operating system's default checkbox.

Chris: Oh, really?

Jen: It'll look like the checkboxes. Yeah.

Chris: I didn't realize that. I thought you were just like, "Okay. It has some default look, but you have to do all the work to make it fancy."

Jen: No, you don't have to do any work. But there are two pseudo-elements. So, if you want to customize it, there are two pseudo-elements you can change the little circle thing that you drag back and forth, or you can change... There are all sorts of possibilities so that you can custom style it if you want to custom style it.

Chris: I really like that. You just get the really nice little toggle back and forth thing just by putting the word "switch" on a checkbox?

Jen: Yep.

Chris: That's tremendous.

Jen: And there's a demo. I should find it. But there's a demo that my colleague at Apple made that is really kind of gorgeous and shows all these different checkboxes.

Chris: I saw one that's got a moon and sun one and stuff.

Jen: Yeah.

Chris: Yeah. Yeah.

Jen: Yeah. Yeah, the moon and sun one. Right. I think I must have posted them on Mastodon or something where, yeah, you could really do a lot with the styling.

00:59:12

Chris: The pseudos are not weird. What is it, thumb and track? Maybe you already said it. I don't know. That's pretty logical, right? The thumb is the little thing that moves and the track is the little place where it moves within. Those are nice names: switch, thumb, track. Boom.

Jen: Yeah.

Dave: Boom. My dumb brain gets it.

Chris: Yeah.

[Laughter]

Chris: It's like, try to remember all the ones for the scroll bars. There's track and thumb, but they're not as simple as that.

Jen: Well, and we wanted to do it because we were getting a lot of requests to be able to put those kinds of switch controls on Web-based content, and we wanted it to be easy because, of course, one of the... I've certainly gone to CodePen many times searching for other people's examples of switch controls to figure out how to put a display.

Chris: Sorry our search sucks. [Laughter]

Jen: What is it? Appearance none on a checkbox.

Dave: Yeah. Yeah.

Jen: And then build the checkbox yourself from scratch with a whole bunch of very complicated CSS. That's too hard. That's a hack. We shouldn't have to work that hard.

Chris: Well, it's a hack because not everybody did it that way. Some people would kick it off the screen entirely and then rebuild it with a label because the label has that--

Jen: Oh...

Chris: Which was bad, and then we kind of got accessibility advice that some people, like on an iPad, for example, you might move your finger over the screen, and there'll be a tactile feeling when you find a form control. If you did it that label way, you didn't get that. It was a minor accessibility problem in doing it that way.

That's why it's like, "Don't hack it! Just use the regular thing!"

Jen: Yeah.

Chris: Or you just set opacity zero, maybe, on the checkbox because that was enough to make it disappear and then place crap over it. But there was a time when setting the width and height on it, it would be limited. You couldn't say width 100 pixels. It just would ignore you. It'd be like, "Oh, 18 is as far as it goes," or something. You go, Ack!"

Jen: Yeah. There is a lot of work to be done to figure out how to make all of the form controls more styleable. That's something we've been talking about a lot as well is how can we--? What's a good system to make them easier?

But meanwhile, here's a new one: switch control. It also can be done vertically. If you switch... I think it actually, in Safari Technology Preview 186, which came out yesterday, we added support for vertical writing modes to the switch control. So, if you want your switches to go up and down, you just switch the vertical writing mode. You switch the writing mode into a vertical writing mode.

Chris: Sweet.

Jen: Build yourself a little soundboard out of switch controls. [Laughter]

Chris: Well, we're coming up... We should mention the content on blocks, too. I think that's really cool. I think there are a lot of us, in our mind, we're like, "Okay. When you need to center something vertically in our left to right writing mode - or whatever - that's always been hard." Then Flexbox and Grid came along, and we're like, "Yeah, it's easy now," and it is. It's tremendously easy. But you've got to use Flexbox or Grid, right?

Jen: Right.

Chris: No. Not anymore.

01:02:07

Jen: No. Line content on blocks would mean any block format in content, which includes float. So, one of the things is you might think, "Well, most of the time it's fine to just toss a Flexbox on a container with one child, and then you can vertically center that one child." No big deal. Sure, except then you can't have a float involved because, if you have some kind of floated content, then Flexbox nukes your float.

Chris: There are side effects.

Jen: This is a situation where, if you needed to continue to have floated content plus vertical centering, you could do so.

Chris: Delicious. That's great.

Jen: Yeah. People have been advocating for this for a really long time, so we were really happy to get it done.

Chris: Line content center on a block level element. Just any old div on the block. That's so cool. Apparently, it was just spec'd that way all along, right?

Jen: Yeah. You need to have space to align it in. So, if you are in a float context and you toss it on a headline but the headline, the height of the headline is the content itself, you're not going to see any effect. But if you put a 50 viewport height on something so that there's some extra white space and then you want to align it in that white space.

Chris: Yeah, exactly, because vertical is always weird that way, right?

Jen: We're assuming horizontal writing mode, of course. You could flip it into horizontal centering in a vertical writing mode.

Chris: Indeed.

01:03:35

Jen: Yeah, masonry, we continue to work on masonry. There are debates happening in the CSS Working Group. In fact, we'd love to end up getting some feedback from designers and developers to hear how are you going to use masonry. What would you like? There's some debate.

Chris: Is it stilled locked into Grid?

Jen: Yeah.

Chris: I didn't mind it in Grid, but I think there were some people that really didn't like that it was part of Grid.

Jen: That's part of the thing. That's part of what needs to get decided so that we can ship it. It's in Safari Technology Preview. People can use it today. Try it out.

Yeah, I really like having it in Grid because if you study graphic design and you study grid systems and the place of grid systems in the history of art and publishing and whatever across humanity, it was very, very common for grids to really be about columns. Priests handwriting religious texts, copying them from one to another - or whatever - they were making these columns and then making those columns be the same size as each other. That's kind of where some of this comes from.

It was in some ways the modernists in the middle of the 20th century who came along and said, "Hey, we should line things up across the page as well. We should make rows, and we should have white space, and everything should be a two-dimensional grid."

And so, CSS Grid really is the dominant layout system for the Web. Finally, we got a layout system. Yay. But it sort of insists that you have a grid that works in both dimensions.

But adding masonry, you could say, "No, I really wanted to find columns. Then I want to have some packing going on and not have things lined up in rows."

Of course, the layout that became famous -- I think people think of Pinterest when they think of that layout -- is one of the layouts you can do to lay out a whole bunch of images or such. That layout has even-sized columns, maybe 12 even columns that become 6 even columns because 3 even columns - or something.

But if we make it part of Grid, which is how it's spec'd right now and that's how we've implemented it in Safari Technology Preview, then you can make your columns be different sizes from each other. They don't have to be the same size. You could have the one on the left be really big and the one on the right be smaller.

You could use it to lay out... I've seen some examples when we've had some conversations at Apple where you could lay out a giant footer of navigation using masonry. Maybe you've got a bunch of images that are all the same size as each other, but you do want to lay them out kind of like a brick wall. You don't want them to be laid out in a grid Hollywood Squares style. There are definitely all sorts of use cases I think that are different than that classic.

Chris: I'm with you. Don't throw out the baby with the bathwater. We still want the columns. We just want it ragged one direction, kind of.

01:06:25

Jen: Yeah. By making it part of Grid, it would be the direction that's not masonry. You would have all the power of Grid, so you could use min-max. You could use min-content, max-content, min-max, FR units. You could use all of those things.

Where I think the proposal is around, no, it should be display grid gives you a grid and display masonry gives you masonry layout. That would be like you just get the Pinterest layout. And the columns are all the same size as each other. They're not any different.

Chris: Yeah.

Dave: Boo.

Jen: You don't get any of that power. And it's like, well, I think that's overly simplistic. I think that limits it.

Let's give it all that power. Well, if we still make it separate (display grid, display masonry), and you've got all of these... Then, okay, let's add min-max to masonry. Let's add. Well, then you've basically replicated Grid, and you have Grid in two places. You have code in the engine that's identical that's different. That's not going to work.

Over ten years, if you keep evolving Grid, are you going to keep updating masonry? If you want to change masonry, are you going to update...? It just feels like we'll end up with two different things that are so similar to each other and not the same.

Anyway, I'm starting to babble because I'm passionate about it. But these are things that we're working on. That's the debate in the working group is to figure out how exactly it should work.

Dave: I'm excited for what happens. Yeah.

Chris: Yeah. Yeah. It's interesting to hear stuff like that because you're like it felt further along. I don't know. Maybe it's just my brain, but I feel like once you see it once, like it was in Firefox for a while.

Jen: Yeah.

Chris: Maybe it still is. But the path... That doesn't mean anymore that that's its destiny. It was being tried out.

Jen: Yeah. It landed in June of 2020 behind a flag in Firefox.

Chris: Yeah, so a while. [Laughter]

Jen: Yeah. Yeah, and I don't think it's been updated as the spec has been evolving. And it's been in Safari Technology Preview (on, by default) for I think at least a year. I don't remember exactly when it landed, but it's been a while. Maybe a little bit less than a year.

And it's mature. It's ready to go. It's just these sort of fundamental philosophical questions that need to be answered by the working group.

Chris: Yeah, like if you're going to spec it, do it right.

Jen: Yeah.

Chris: Heck yeah.

Dave: Very cool, Jen. Thank you so much. It's cool to see the progress on Interop, the great success there. Excited about Interop 2024 here, and it's cool to see Safari updating regularly, and even paving the way, leading on new features.

Jen: Yeah.

Dave: It's welcome change to the old browser ecosystem, so really appreciate that. I think we'll have to wrap it up here just purely based on time.

Jen: Yeah.

Dave: But for people who aren't following you and giving you money, how can they do that?

Jen: I'm [email protected] on Mastodon. I am still on what's now called X as Jen Simmons, but I rarely open up X. Mastodon is really the place to find me.

We really do... I mean it when I say input from people who make websites has impact, and especially a longer blog post explanation or bug report. File bug reports.

You want to give me money? File bug reports. There's my answer. [Laughter]

Dave: [Laughter]

Jen: If you have requests, you can go to bugs.webkit.org and file requests or bug reports there. If you find a lack of interoperability or something, do file bug reports. You can ping me on Mastodon and tell me about it to make sure that it gets seen.

Go to webkit.org and find out all the news on what's happening with Safari and WebKit and things that are coming in the future in Safari Technology Preview, things that have already arrived in Safari.

Dave: It's a top-tier subscription in my feed reader, so appreciate that. All right, we'll wrap it up here. Thanks again, Jen, for coming on the show.

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 Mastodon. We're there. Then also on front-end.social. Then join us in the D-d-d-d-discord, patreon.com/shoptalkshow.

Chris, do you got anything else you'd like to say?

Chris: Hmm... um... ShopTalkShow.com.