Hot New and Under-Utilized Browser APIs

Welcome to syntax today. We got a show for you on hot new and underutilized a browser APIs. This has been one that we've been sort of keeping a list of what's new in CSS, JavaScript, whatnot. And then Scott went to Amsterdam a couple weeks ago and did a awesome talk with tons of really cool demos on starting style, allow discrete, scroll snap, calc size, pop over dialogue, view transitions, all kinds of really neat stuff. And when I talk to people about this type of stuff, often a lot of people say, I had no idea that was a thing. It feels like I think everything we're talking about today is just CSS. Right?

Yeah. Well, CSS ESLint there is JavaScript involved and HTML. JavaScript. Yeah. You're right. It's the full gamut here. Yeah.

Alright. Well, I'm pretty excited about it. Scott has some really cool demos. So tune in on YouTube or Spotify if you wanna see the Deno, but, otherwise, the audio will do just fine.

My name is Wes, developer from Canada. How are you doing today, Scott? Hey. I'm doing super good. If, you are utilizing any new APIs that you haven't used before, potentially with JavaScript, you wanna make sure that you have your error exception handling and tracking service onto the fullest ESLint. So that way, when you inevitably mess something up with one of these APIs or perhaps you're using an API that isn't supported in a browser, storing an error for somebody, you can be on top of it. And to do that, you'll want to use a service like the incredible Sentry, s entry.i0forward/ syntax. Sign up and get 2 months for free. And this show is presented by Sentry.

Yeah. Actually, Wes hold on. I'm not I'm not done the ad read yet.

Century is a a really good example of these APIs because we're gonna talk about the Node. Right? And there's a method called Scott show model. And if that method is not in a browser, you're gonna get something in your century that says, hey.

Dot show Node is not a you cannot call this method on this, on this object because it doesn't exist. Right? And you'll be able to go into Century. You'll be able to see a breakdown of what browsers are throwing that error, and then you can make a decision of if you wanna polyfill that for those specific browsers.

Yes. Yeah. Absolutely. And that that is you might not even know that your users don't have

those APIs. The type of things that pops up on. Oh, man. It's it's not supported on this, like, weird Android that I've never heard of before. You know? Like, oh, that's that's a bit bizarre that that that popped up, or this is really popular device in

London, Ontario that people are using. So Yeah. And you know what? It that that goes along really well with the contents of this episode because, we'll be talking about what percentage of users and which browsers these things are supported in. And you will see that some of these, you can be used today with a polyfill or gracefully falling back, progressively enhancing.

That way, you can utilize some of these techniques and still actually, have support for that. I'll have a link to the talk I did in Amsterdam. If you wanna see the whole talk, it is in the show notes. It's on YouTube. And, also, I have a website, tolyn.skiforward/demos, also in the show notes that will have links to many demos of things that we're talking about. Maybe not directly, but, you can see examples of of a lot of these things in action.

And what's cool about these demos is you wanna load them up in Chrome to get full support. All of the demos on this page are loaded just HTML, CSS, and JavaScript. So there's no framework at all, running these demos. It's just HTML, CSS, and JavaScript.

No polyfills or anything runs in Chrome. So with the latest APIs, you'll be able to see how cool some of them are in action.

So with all that said, I think a good place to start, is with one of my new favorite CSS APIs, which is at starting style, which is an at rule in CSS.

And starting style is one of these really cool APIs that you might not have necessarily considered that you need, but it allows you to essentially assign CSS for something before it comes into the DOM. Okay. So I'm gonna show you an example here, and you will see some other APIs we're talking about. But as you can see here, we have this starting style right here.

And what this is doing, like I said, is it's applying a style right before the thing enters the DOM. It it has the style when it enters the DOM, and then you can apply another style to it afterwards. If we've ever used an animation library, like, even how Angular did animations or how React has done animations for a long time, a lot of what they're doing is they have a class on something, right when it enters the DOM, and then they remove that class, and it triggers a transition. Right? A CSS transition.

And so this is really doing that without JavaScript. You're you're applying your style before it enters the DOM. It enters the DOM. That style changes, and then it transitions.

So in this particular example that I'm showing you here, this is a pop Vercel, and this uses no JavaScript at all to create a slide over mobile nav menu that works entirely without JavaScript.

But a lot of that is being done because we're able to give it a starting style. Before this thing is in the DOM, it has a starting style. It's translated off screen.

Then when it's on screen, it translates 0, and it slides over. It it's not even just in the DOM or not because the element can be in the DOM already, but it's it's the ability to like, if you have an element in the DOM, but it's it's hidden or it's it's off screen and you wanna show it, often going from hidden to, like, display none to display block or whatever. You'll have to add, like you'll have to have a 2 step. Like Scott says, you'll have to add a class of opening, and then a split second later, you add a class of open. And what that allows you to do is you can set, like, opacity 0 on opening, and then you can set opacity 1 on open. And that allows you to first show it by going from display none to display block, and then you do the 2nd hop, which is from opacity 0 to opacity 1. This gets rid of all of that annoying multiple class by allowing you just to have a a starting style, which is just before you add this class, apply these CSS properties to it so that when I when you do add the class, you can transition from whatever it had.

Yeah. And so you might be wondering, can I use this? Well, it's available to 72% of users, so not quite yet. It's this is when it's good to know that it's coming out. I think this one is gonna be useful in a lot of situations that we're typically using JavaScript for.

But the good news is it is in Safari right now in the technology preview, so that means it will be in the next version of Safari.

And it's also in Firefox already behind the flag. So if you're wondering, like, you know, when when's this thing dropping? This is one of those ones that, you know, it could drop next week, and you wouldn't be that surprised. Right? Given that we have a new major version of, macOS coming out and, you know, Firefox seems to be releasing pretty well once they have things behind the flag.

Yeah. We should say Firefox does not currently support the animating from display none, which is kinda like one of the best use cases of it. Not the only use case, obviously, but one of the the major ones. So, hopefully, they add that pretty soon. Yes. And then the other thing I wanna say about this is, like, what happens if if it if you don't have it. Right? Like, often, we can polyfill it. I don't really think you can polyfill or, like, transpile this because it's at a lower level. The browser needs to sort of understand how it works. So the worst that will happen here is that you won't have your animation. Right? Like, I have Yeah. I'm using it for my checkout Node so that it it swoops in from the top and then swoops out from from the out on its way out. And there are some browsers that like like I said, Firefox, it's not going to work, but I'm okay with that. Why? Because it just shows. You know? It's not like it's broken. It's just a less of a experience for those users.

Yeah. Truth. And when you said that it doesn't work with display, none, transitioning, that's where this next one comes into play here, which in my mind, this property is well, it's it's actually a value, not a property. In my mind, this value and property combination is kind of like a a tag team with Yeah. Starting style. Because as you'll see, actually, even back to that example that I was just looking at with the mobile nav, this one I'm talking about is transition behavior allow discrete.

And what this allows you to do is essentially transition things that you couldn't transition before, like display none, overlay.

And what this does is it basically chooses when that display none to display whatever toggle happens.

So let's say we want to animate something in that is display none to display block.

For if you have allowed discreet on your transition like this, you can see that what will happen is that display, none will be removed immediately Wes on the transition away from it, that display block will be removed after the given amount of seconds in your transition.

So, therefore, the animation can complete before the display none has been applied.

So allow TypeScript is one of these things with combined starting style will allow you to build things that you could never even think about building without JavaScript in terms of how we animate.

These are these are this this tag team, this,

double trouble here, this terrible 2, these 2 are are going to really rock how we write CSS and JavaScript, I think. It's it's so good because, like we said in the last one, you don't have to add that 2nd class because if you have something that is being transitioned from opacity 0 to a100, but you also have display none to block on there, you you sort of ruin it because the way that the browser handles it is halfway through the animation. It will move it from display none to display block. What this does is it, allow discrete will turn it from display none to display block immediately so that you can do your your animation. That's also where the the starting style comes in really handy. It's it's a little bit of a funky syntax, trying to do the 2 together, but I don't know. It's it's what we have. Once I understood, I was pretty pretty happy with it. Yeah. Check out the dialogue example

that I have. This works with the HTML dialogue element to do a fully transition.

Works with your escape key and everything, just very minimal JavaScript.

If you wanna see the API for this, because what you can simply do is when you're applying your transition, you can use a shorthand for this. So you don't have to use transition behavior allowed discrete in your CSS. What you can do is when you write your transition property, you could have a a value like display 0.3 seconds allow discreet in the shorthand. And then that's going to simply cause this to work. And then later on, you can use the starting style again to give it the starting style. You can give it its open style, and then you can give it its natural state style. So all 3 of those combined, you can get this really fantastic animating Node with no JavaScript essentially other than triggering the model itself.

Next one we have is calc size, and, this one is pretty exciting because it's something that we were able to do in jQuery forever, and this now allows us to do to do animation to height of auto. So, again, if you have a, let's say, a div that's 500 pixels high and you want to transition it to however however wide it should be or however high it should be, you'll know that you cannot animate between a fixed value, which is 500 pixels, and an auto value or an intrinsic size, which is auto. But now you can. So calc dash size, you can pass it one of the, I think, 4 or 5 different intrinsic keywords, auto, min content, max content, fit content, stretch, or contain. Those are all keywords that you can use to size an element in CSS, and they're actually really handy. Sometimes you think, like, oh, I need to use, like, a span or an inline element.

The width and height of those keywords is is really handy.

So by putting a calc size auto on it, it'll allow you to transition it down. I've Scott's showing a demo of that right now.

You can also do calculations on them, which is kind of cool. So you can say calc size auto, but you can then the 2nd argument of calc size will be just a regular calc function, which you can use to you can multiply it. You can add, like, ESLint height. If you have a variable of, like like, gutter size 50 p x Yeah. You could, like, say, like, give me the full size plus the gutter size on it. And that's really nice because now you don't have to go into JavaScript, measure the element, and then throw that into CSS to do your calculation. You can simply just say, give me the

size of this actual element. So can we use calc size wise?

Yes. No.

So calc sizes actually, I made a mistake in that video.

I said that the browsers have said they will support it. Their Chrome has done what's called intent to ship, meaning that they've implemented in Sanity and they are intending to ship it. It is currently still in draft stage. It's going through the regular draft stage. This is not just something that Chrome came up with and and put it in the browser.

And then we now need to wait for Safari and Firefox just to also, implement it. But I'd imagine that we will start to see it soon. It's another one of those annoying things where you can't really polyfill it unless you have a ton of JavaScript or do, like, implement it a second time, which is, in my opinion, probably not worth it.

One thing I could not figure out how to do with calc size and allow discrete and starting style is transition from auto to auto. Mhmm. Meaning that when like, let's say you have, like, a div with 5 items in it and then you add a 6th, the div will will jump in size because you increase the size. How do you how could you transition that? And I thought, like, oh, you could have a starting style of calc size auto, which is the before the element has been added, and then you have a another style, which is after the element has been added, and it's just auto to auto. Right? But at least right now, maybe it's not totally implemented.

That's not possible. But I think that would be really cool. Imagine that your all of your elements could just JS could animate themselves as they jump in size.

It's it would be the dream. And if you combine that with even, like, view transitions API, you could get, like, the magic transitions from React framer, framer react, whatever. Framer motion. That's what it was. Yeah. Yeah. You could get some cool stuff like that going with very little effort.

Could you do it with view transition? Maybe. Oh, we're gonna get to view transition. So maybe maybe that's a solution now.

Yeah. View transitions, there's a lot of interesting things you could do there to do that kind of thing because, view transitions API, when we talk about it, you'll see it's it's it's both simple and very flexible, and it it's one of my new favorite APIs just simply because the amount of things you can do with it. But before we talk about view transitions API, let's talk about scroll snap, which is available to 94% of users. So everybody's got this thing.

And scroll snap, you might be thinking, okay. That's that's cool Scott snap. I've I've heard about it, but you can do a lot with scroll snap. And one of my favorite things about scroll snap is that you can create, like, an Instagram style swiper extremely easily, and it works effortlessly on mobile. You Node? Like, a lot of the JavaScript kind of gesture based things can sometimes feel either laggy or the the JavaScript doesn't always feel smooth, but this feels as smooth as using, like, an Instagram style swiper on the web. And to do something like what you're seeing here, just a basic swiper, it's really as simple as having the properties here on the container to say, scroll snap type, which is you're gonna be snapping on the x the x plane.

And then, likewise, on the snap on the item that's being snapped like the slide, the scroll snap align. So where you want it to snap to, you want it to snap to the start of this particular item. And then in my case, I just made the container the same size as the individual slide, and then you have a swiper.

But what's, I think, underlooked about the scroll snap API is that you can use JavaScript with it. So in this example that you if you're watching on YouTube, you can see I have, like, an Instagram style swiper that shows an indicator on which slide you're actually on. And this is using very little JavaScript. We're just checking the pnpm, and we're running this on scroll. So we're listening for scroll on the container, but the JavaScript is only adding a class to these individual indicators for what index is currently active. So you can check out that demo, but you can take it another step further and actually control this, scrolling itself using the event listener, the scroll event listener, and you can build a real slideshow using HomeWorks. Wondering how you're doing that. I was just gonna ask. Sorry. Go ahead. Yeah. So it's pretty amazing. In this in this 3rd demo here, I have the indicators being shown, but I also have the, buttons to be able to choose a swiper. But the best thing about any of this is that you can just continue to swipe it like you would, and it works fully mobile, but always will show the indicator or will always work correctly.

And the amount of JavaScript for doing this, it's it's not nonexistent, but it's less than, you know, it's less than yeah. It's less about 40 lines of JavaScript here. And some of that is updating the indicator. I have button visibility, so I'm toggling and showing and hiding the buttons that you're clicking to, advance and the advance. Actually, at one point, Wes, I had this demo with an infinite slideshow where it would re reset and loop, but it got a little tricky when you're swiping it like that.

Oh, yeah. Yeah. When you get to the end. I've built so many sliders in my day.

It's so frustrating. But this is really cool because you're just measuring how wide a slide is, and then you're measuring how wide everything JS, and you're just, like, dividing it, figuring out how many spots there is?

Yes. Yeah. It's a really simple math.

You could see active in that amazing. Like, if you remember the the those, like, slideshow plug ins warp, like, thousands and thousands of lines of code to make work. And you just did 1 in,

what, 30 Forty lines. Yeah. It's a 40 lines of code, all things considered. Yeah. And and not only this is even necessary. I'm sure this could be optimized further. But, yeah, it's it's really pretty neat. And so I do think that gets totally underrated when people think about scroll snap. They're like, alright. You use it for what? Like, vertical snapping or you use it for a a a swiper or whatever. But, yeah, you can combine it with JavaScript. And even further than that is, Adam Argyle just has this really he had a a tweet the other day talking about new APIs for the scroll snap, And this is gonna make what I did even there a lot easier because there's gonna be a bunch of new additions.

So you'd have the ability to work better with scroll to, which is what we're we're using, in addition to, like, new events, like snap change or snap changing in new properties.

So

Oh. Yeah. Snap self. Almost like Snap last. Snap first.

Like, this is remember we were talking a couple episodes ago how he there's no, like, swipe events. You know? Yeah.

This is that. And you know what? I also I just tried on your demo is the dom method scroll into view, and the whole thing just worked. Like, I just I selected an element on the page, and I called Scott scroll into view on it. And it just

went Vercel all of your indicators and everything updated. There was no keeping state or any of that. It all just updated. Framework. Wow. HTML, CSS, and JavaScript folks. And I think that's, like, really important because if you can do it with HTML, CSS, and JavaScript that easily, then you can imagine how much easier it's gonna be in your framework. But not only that, I think when we're evaluating, like, what plug ins and what libraries we're using, and one of them writes their slideshow in a 40 line implementation with no dependencies, and another one has this giant mess of dependencies.

And, you know, it's totally obfuscated behind 8 different libraries.

Which 1 are you gonna pick? I'm gonna pick the one that utilizes the the browser APIs and does it in a more simple fashion. And I I think that's something that we can get away from occasionally about like, when we're picking dependencies, we're often picking those libraries based on what they can do for us, but not necessarily the internals of those libraries. So for me, personally, I I'm gonna start to look at which ones are utilizing more browser APIs, especially ones that are so widely supported like scroll snap.

Next 1 we have here is view transitions. I'm gonna let you take this one because I know you've been working hard, and I'm very curious to see if this is going to fix my,

auto to auto thing. I don't know if it will. I mean, there there's some interesting things about the view transitions API. I'm certainly not a pro at it, but you can see, even see on my site, this uses the view transitions API to do a lot of things. So you can see when I select a blog post, we get all this transitioning where everything kind of goes into its place.

Another version of that would be, like, if I select a tag. Watch this when I change the tag, how they swap out from the Node. That's using view transitions because all I'm doing is applying a view transition to this and giving it some CSS to control that animation.

And even the page fade that's happening is using view transitions.

So every bit of animation that you see on this app or in this site is using the view transitions API and sometimes in very different ways.

So let's take a look at some demos.

And, what's neat about this stuff is that you can use the view transitions API with many of the other APIs that we're talking about. Like, for instance, the mobile map example that I I showed you before that had no JavaScript. This is a mobile map that's being done with the pop over API and view transitions.

It might look choppy on your screen because of how we're streaming on recording, but I can assure you it's 60 FPS.

And all this is the the way that you're handling this view transition, Wes, is simply by wrapping the show or hide pop over method. So we have a pop over. We're showing and hiding it with a dot show pop over or a dot hide pop over.

And we're wrapping that in a document dot start view transition.

So that in itself is telling the DOM to do a view transition with this item.

Now the special sauce, the reason why it's able to slide over and do all that is because of the view transition name.

So on the pop over itself, I'm giving it a view transition name, which is slide.

I can then reference that transition with view transition old and view transition new, and then you pass in the the transition name. And then from there, I have an actual key frame Node slide as well. Now let me show you just how amazing this example is because this CSS here is all this animation is doing. And what's so cool about this is people often overcomplicate key frames in Yeah. CSS. But you can do this where I can say from translate 100 v I. V I is the same as VW Wes it's viewport width.

VI is viewport inline.

This has the same support. So, viewport inline means just 1, in this particular example, 100% of the inline dimension. So key frames from translate 100 v I. Now you don't even have to do 0% to 100%.

You don't have to do from to. All you have to do is from 100 v I, and then it will automatically know that the to state is just its default, which is what? Yeah. 0. So it goes from 100 v I to 0, causing it to slide in. But the transition, oftentimes, people will write 2 different transitions, slide in, slide out. Node. You can just do 1 transition for slide in, do the other transition, and reverse it.

So with very minimal JavaScript in CSS, you're able to use the view transitions API. So as this thing enters the DOM, it is doing this view transition, and that that's pretty incredible that that can work that easily. So view transitions by default, though, if you were to say start view transition like this, Wes, and you didn't have this bit of CSS in here, You didn't have the view transition name. By default, without giving it any CSS whatsoever, it just fades in. So by default, you get a nice little faded transition no matter what without having to do really anything. And, in fact, here's a good example of that. Here's a details element, which is an accordion. And all I'm doing is starting the view transition while I'm telling it details JS open, true or false. And there's no CSS on this, and you get this fade in. So automatically fades in, which is pretty nice that that's the default. Right?

That's. So this API really can be used in, like, 3 spots. Right? Because we've talked about it in the past, and we're using on the syntax website when you have, like, a single page app and you go from page to page. Or you can also use it on, like, 1 HTML page to a totally different HTML page.

But then you can also which is what you're showing here, you can use it with simply just hiding and showing elements on the page. You simply just have to start a transition before you actually

show the element or hide the element. Yeah. Anytime you're calling a browser API that's going to show or hide the element, whatever Yeah. You just wrap that in a Scott view transition, and it just handles the rest. By default, makes it fade. If you wanna have it more complex, you write your own CSS transition. And there's even a third part to this, like, what we're doing, like you mentioned on the the syntax Sanity, where, like, this bit where 1 item transitions into the next bit.

This is being done with, like you're basically giving these an identifier.

This has a unique identifier, and this has a unique identifier.

And those are the same unique identifier on this page. So that way, it knows that when I click this, it knows to fade up into there. So, likewise, if I click this one, it will travel the full distance to get there. And, likewise, this has the same as this one right here. And so I'll show you the code for that because this is the actual site. And that's being done once again with view transition name. However, this time, view transition name isn't applying to, like, an actual key frame transition like we were doing in the last Node. But I'm setting it to a CSS variable named transition name. So here, I'm saying any h one through h six or paragraph tag, if it has the transition name property. Assign that to a v transition name.

And then just on my item, I'm giving it a unique identifier that tracks that specific page. So so in this case, I'm saying the post title and then the slug of the post.

So because of that, if I use post title, the slug of the post anywhere on the site, it will always know to transition 1 from another to another.

Now these things have to be unique, and you can't have multiple of them on the same page at the same time. Otherwise, it's it's going to get confused. Right? But it works really well. And and, likewise, like I I said, I've been doing this for everything. You can always do, like, post excerpt slug. Anything that's a unique identifier works, or even on our tags.

Post tags, tag name, slug. Then it'll transition each individual tag to where it needs to go, And this is not using any CSS to do this beyond the view transition Node, and it's not using any JavaScript beyond wrapping the whole site in a view transition, which is what we're doing on our our main layout page.

The HTML has to be exactly the same. Is that why it has like, you can't, like, you can't change the contents

of the HTML? No. The the contents can absolutely change. Yeah. The contents can change. And then we'll just do an interpolation between the 2. It'll, like, fade

between the 2. Then why can't you just, like, on that h one, why can't you just say, like, podcast title?

Because specifically, because if we were to head back to here, let's say the listing page, this is a podcast title. This is a podcast title. This is a podcast title. But we want this to transition to that. Yeah.

Oh, okay. I see. I see. But if there were only 1 on 1 page I see. I see. Yes. Yeah. Most likely going from a list to a single page,

so you need to do that. Okay. That's correct. Yeah. Yeah. And and the way we're doing this and this is Svelte code, but it's, you know, you'll be able to find your framework of choice on how to do this. We're essentially just saying, hey. When the page navigates, if view transitions exist, then we're going to just start the view transition, resolve, and then await navigation complete. That's it. This is it. And all that will do is wrap each of your your route changes inside of a start view transition.

So it it can be as simple as that, but this is view transitions for single page applications.

As in this works specifically for SPA based JavaScript framework apps right there. But view transitions let me look this up. View transitions, API, multiple page app JS actually it's not a pipe dream at this point. Let's say if you were transitioning from 1 HTML file to another HTML file without JavaScript. Right? Well, I mean, without a a JavaScript based router, like a JavaScript framework doing the page updating, You'll soon be able to actually run view transitions as well. The cross document view transitions for multi page applications, have this link in the show notes if you wanna dive into this one more. This one is not super I mean, it's it's in Chrome, but, you know, who knows when the support's coming elsewhere.

And it's a little bit more maybe not more intense, but it's a little bit less turnkey than I think just wrapping your whole site in a view transition.

But to me, this one right here will unlock a lot of things for people who don't wanna have necessarily a JavaScript framework controlling their whole application.

And they're able to get, like, native app feeling app transitions moving from 1 full HTML file load to another full HTML profile. That's great because, like,

so many apps are like, you have to sort of buy into that stuff at a very early level of your application if you wanna do, like, transitions.

And now that is no longer the case.

Yeah. And and you since you have the full control over the animation with key frames, by all means, you don't have to do a simple transition that is, you know, 100% to 0%, like what we had with that ESLint, for example.

You can do mammoth animations. You have key frames. You can you can have the whole site zoom out, move over here, move down here, and then zoom back in with a new page. Right? I mean, it's it's pretty wild, the amount of stuff you can do with just key frames alone. Right? So the view transitions API in my mind is, like, really one of the holy grail APIs for for me in terms of being able to really animate our pages. And the best part about the view transitions API is that even though only 72% of users currently have it, the fallback is super easy JS in it just doesn't animate. That's it. You can progressively enhance without any sort of effort whatsoever.

Firefox users, you're still gonna get the page just loading like normal. And then Chrome and soon Safari users, they're gonna get the zoom zoom zoom. They're gonna get all that cool animation stuff.

Yeah. Plus, you like, this is, I think, the most value on mobile, and it's supported both on Android and Bos. So Yes, sir. Start using it. Yeah. Start using it for sure. We we shipped the syntax site with Vue transitions API in March of

no. No. When did we ship this syntax? I don't even remember when we shipped it this Friday. A year ago.

Yeah. So, like, October 2023, we shipped that thing.

So, yeah, you can ship it too.

Let's talk about the popover API, which is something that we've shown a couple of times here already. And the popover is really neat because, it's a really simple API.

In fact, you can use the basics of popover just to have a basic popover like this.

Like, I'm showing you on screen, it's just a menu that pops up. That little menu that pops up simply by having a popover target property on the button that is equal to the ID of an item that has the popover attribute on it. And with that, with no JavaScript CSS or whatsoever, it it's either hidden Wes it has the pop over. You click the pop over target button, and the pop over shows up.

My favorite thing about these APIs is that what we're always talking about with things like accessibility.

Like, why do I have to do so many of the accessibility things myself? This automatically traps your focus. So if I hit tab, I'm instantly already And I don't have to program any of that, which, again, do it for me. I don't wanna And I don't have to program any of that, which, again, do it for me. I don't wanna do it.

It's it's so good. Like, you just made a menu open and close without a click event, without any CSS. You know? Like, it's simple No JavaScript. Yeah. Do you remember the days when we would we would show the, like, checkbox hack? You know? The checkbox hack. Click events in JavaScript with the checkbox hack. Yes. No longer like, this is this is totally accessible. Like, this is such a huge primitive to have in the browser for building off of, and I think a lot of people need to know about this so they don't reach just for another div and button.

Yes. And in addition to what I did before, can also get a little bit more granular with it.

For instance, you can target a pop over target action, and that means you can explicitly tell without JavaScript, with just HTML, what you warp it to do. So pop over target action show, I have on a show button. And then I also have a button inside of the pop over with a pop over target action hide. And then so you can run show or hide, or you can trigger the popover itself to toggle it.

Oh, and then you can pick it up in CSS with the open attribute. Is that true?

Yes. Yeah. The, let me even we'll we'll get into that in a second, actually. Okay. It's popover and then the attribute or the it's a pseudo selector of colon popover hyphen open. That is the determining that you can style off of.

Okay.

So one interesting thing about popover that you may have noticed or if you're watching on video is that it's just kind of in the middle. It just kind of sits on top of everything. Right? It has, like, an inside of 0, I believe, or inside of something, auto, whatever.

The problem with popover and what we'll see when we talk about modals and dialogue is that it puts the item on the top layer, which is a newer API that kind of is the next generation z index in a way where it it it sets it on top of everything. You could think of it as, like, the reason why people use portals in React. Right? They wanna they wanna take it out of the document flow and put it above everything else. And so popover does that. It puts it on this top layer. The big problem with that is that JS you'll you'll notice if we if we come here, if I wanted this pop over to be immediately underneath the button, you might think, alright. I know that, position relative on the container, position absolute, and then give it some values on the item. The problem is is top layer does not exist inside of the current document flow. So it's it's an entirely its own part of the document.

So wrapping the container in relative won't make the pop over itself position relatively to the item.

And you can actually can see in Chrome in the dev tools Wes something's on the top layer, it looks like this Wes it says top layer here. And then if you scroll down in the DOM, there's, like, a whole separate section for the top layers.

And that's pretty neat. So if you want to get something to pin where you typically use position relative, you do have to use the new anchor API or JavaScript. I'll show you first with the anchor API because it is smoother.

So here we go. We click this, and you can see it's pinned to the bottom of the menu.

This is using a new API that is influx still, so this one's quite a ways off. You can't use this quite yet. But you give it an anchor name, and I give it a name. So it's a a kind of interesting syntax where I say an anchor name and then a name JS hyphen hyphen, let's say, menu.

And then from there, in the pop over itself, I can say, I want to anchor the top of my pop over, and I want to anchor it with the anchor function to the button, the name of the thing I just gave to the bottom of that, or I want to anchor the left to Yeah. With the anchor function menu left. And that's how you use the anchor API to this basic extent. Now the anchor API goes much, much deeper than that. But, you know, if you if Node little bit about this before, and it is moving forward. The other browsers are implementing. Safari had a number of changes they wanted changed about the way the API functions.

So we're not getting anchor soon, but in the meantime, here's an example I'll show you in my demos using straight up JavaScript to do the same thing.

And this is actually pretty simple because what we're doing is we're measuring the target position with the get bounding client rec'd, and then we're updating the position of the pop over to match that position. And then we're updating that position on, resize, on scroll, all that stuff so that way it stays pinned when you're scrolling. Yeah. Most of the time, if you have a menu and you click pop if you click the menu, it's not like you're opening the menu and scrolling a whole bunch. Usually, people click it and then do something, and then it closes. Right?

Do you know if the anchor API will also fix the tooltip issue where I want it to go on top if there's room. Yes. But if not, it'll go on the bottom. Or, like, the tooltip goes to the right, but if the element's at the very right of the screen, then go to the left. Yes. In fact, there is. I don't have the syntax handy, but it does fix that because you can specify,

like, if there is space, put it here. If there's not space, put it here. You can specify, like, ideal placement of this based on the the positioning. So, yeah, it does solve that.

But, again, I don't have any demos for that just yet. Just because I know the anchor API overall is under it it it's I don't think it's necessarily in flux anymore, but it's They haven't really anchored it just yet. Yeah. It hasn't been fully anchored. That's so so good, Wes. Here's another thing before we get off of, popover JS that it is available for just about everybody today. 86% of users have it. That feels like probably not enough to just say YOLO, but it is available in every major browser. So in the latest versions of all the browsers, you have popover. If that's your clientele, go nuts. That said, we use on syntax the polyfill, and this supports way back. The polyfill's pretty easy to just dump in there, use the pop over API.

You have to add a couple of additional CSS classes because it does some of this with classes.

But for the most part, the polyfill is super easy to implement. And I highly recommend next time you're building a little menu or anything, use the popover API because it couldn't be more simple in in regards to just even, like, the basics of how we're using this thing. Like I showed you before, I was able to get an entire mobile menu, like a straight up mobile ESLint over menu with just that pop over API.

Next up, we have dialogue, which I went deep on the dialogue doing my checkout in the last couple months. And, I'm curious the, like, difference between popover and dialogue, or that's something that I was always, like, kinda going back and forth between the 2.

Yes. But it it seems like and maybe you can tell me.

Popover is a more modern, API, which allows you to open and close them with just HTML.

Whereas dialogue is more something for, like, modals or not it's not not just for modals, but it it's more,

overlayed. What what do you have a more succinct way to put that? Yeah. I wouldn't necessarily say it's a more modern one. It maybe gives you popover gives you more more control. Dialog does a little bit more for you in some in some context. What's interesting about this is the whole show versus show modal Yes. Methods because I've seen discussion where people are like, why does show even exist? Should we even remove show at this point and just have dialogue before Node. Right? Show modal as being Yeah. The way to use dialogue.

Because I personally would probably use pop over over show to do many of those things a a 100% of the time just because of the API.

Where modal really shines or or dialogue with modal is that it does a couple of things. One, when you do a modal, it puts it on the top layer like pop over based instead of, I believe show doesn't put it on the top layer, but I could be wrong about that. I I think the probably the most important one is that it you cannot focus anything on the page, which is a huge accessibility win. You don't have to disable all the other inputs. You can't tab to an input that's behind the modal. You know, that was always a huge pain when you pop something up, but the the screen reader or the the keyboard focus was still behind the modal. This will just neutralize, inert, the entire body so that you can,

actually, I don't know. I think you can still scroll. Yeah. Is that true? Well You can scroll. I can figure this out immediately because I have an example. Here's a page. You can scroll. Yes. You can scroll, but you can focus. Interact. Click on focus, anything like that on the rest of the page. Yeah. It also gives you a great backdrop pseudo selector so that way you can style this this backdrop nice and easily. It makes it so that if you hit the escape key, it closes just like pop over. But the inert thing is really great and the focus capture. You'll see that I have a form inside of my Node. And when I trigger my model, it automatically focuses on that input in the model without JavaScript, which is great because you just get to go right in. Again, keyboard, action right away. You can even close a model with the form using the method type dialogue.

Or was it the method, it's method type?

It's a action, which is Yes. That's what I'm

dialogue. Yes. I was looking for that word.

Yeah. Which is because there's get post and now dialogue. That was in one of our stumps. Didn't we do that in our live show stump? Yeah. Which is you can close it with with HTML, but you cannot open it with HTML, which is is very odd.

Yeah. That is odd to me. I I always found that to be weird, and I still do.

And who knows if that will stay like that forever? I wonder if the popover API will influence that. Shown popover JS in our future maybe? Yeah. But here's the deal with the the reason why you use dialogue is if you need a modal. A modal is something that pops up. It captures your attention, and you can't do anything else until that modal is closed. That's why you use a modal Wes a popover is like a menu pops up or navigation pops up. You could do that same CSS slide in navigation that I showed with a, a dialogue as well if you wanted it to be considered to be a, like, fully takeover.

In fact, I even made a let's see. I think this yeah. Yeah. Here, check this out. This is done with dialogue. So a dialogue could be used for the classic mobile slide up menu, like a drawer. Like, you you're on your phone. You click new GitHub issue. This thing slides up. This is built with a dialogue. Again, this is taking over the page entirely.

Nothing can happen until I finish this dialogue.

I wanna talk real quick about some issues I had with the CSS top layer.

So Scott explained that top layer is a new concept in the browser, which is it literally puts it on top of everything. It takes it out of the flow of the document and and puts it on the top layer so that any any other element sort of goes behind it. And I had an issue with PayPal and Stripe because PayPal and Stripe have sometimes they will do a three d secure checkout where they embed, like, your bank's thing, and you have to, like, type in a code that it emails you or or any number of of reasons. And the PayPal does that as well. Sometimes if it can't open a new window, to sign in to your PayPal, it will just embed an iframe right there. And both PayPal and Stripe put those in an overlay, and then they put a z index of, like, 2,000,000, 680,000, whatever the, like, max z index is allowable so that it goes over top of everything on your page. But you know what is the final boss of the max z index in the world? Top layer. So I ran into an issue where people were needing to sign in with their credit cards 3 secure, very popular in Europe, and it was going behind my checkout.

I was so frustrated, and both Stripe and PayPal don't have a way to listen for when those dialogs open.

So I had no way to know when it was open. So I had to, like, write this crazy listener script that would listen for when something was added to the page that looked like a a three d secure, and then I had to close my dialogue and to show theirs, which is really frustrating. So I have I opened issues both on PayPal and Stripe's SDK. And if anyone is listening and you work on a third party library, move your pop up things to dialogues as soon as possible. Because, even if the browsers don't support it, it's just a it's just a div then.

But if anyone is using a dialogue on on their website, it's go you're not gonna be able to put it over top. There's nothing you can do.

You can't even, like, switch their div to show modally because it has to be a literally dialogue element.

Yeah. Yeah. That it's it's an interesting API and one that I think may even change once you, get into some of the the, you know, the crazier things when you have multiple top layers and stuff like that.

Let's do the last Node here, which is details, which, details is not a new element. It's it's actually kind of I don't know. When I did my talk, I was like, I don't think I should have details in this talk.

And then I was on my flight over, and there was a FAQ on Delta's online plane Wi Fi sign up, and they weren't using details. And that's fine. You don't have to use details, but details is a JavaScript less accordion. In fact, you can do just really basic accordions with details. They function like this. By default, they don't animate.

Animating the Sanity here, the little triangle, is actually kind of hard.

To do that, you need to, do a display none on the marker and the Wes kit details marker, and you need a list style none on the summary, and then you can add your own with a before and animate that. So animating the little caret is no fun, and animating a details overall is no fun even with starting style. Like, check this out, Wes. This is this example, for all intents and purposes, should work. Right? We're using a loud, discreet, and starting style. This thing works 1 out of every 10 times. Like, it works the 1st time, and then you close it, it doesn't work. Next time, it doesn't work. Who knows why? I asked Adam about this, and I don't know what the deal is there because that that should work. The way I animate this and this is a nice animation. This JS with a few transitions API so you get a fade. Or if you want that classic, slide, you can do a web animations API to do that slide. And this example, that I'm showing in in the video is actually cancelable and stuff like that. So this uses the Wes animations API to just show and hide this. It's pretty simple. It's just using Scott animate, and you are animating the height, which is how you can animate height auto today with JavaScript with no libraries using browser APIs.

So you don't always need even, like, while we wait for these things in CSS, you can reach for things like the Wes Animations API instead of necessarily reaching for a library if you have one off things here or there instead of bringing those whole package of animations.

This JavaScript here looks a little intense, but it's, again, it's like 50 lines. You wrap it into a component. Next thing you know, you have an animated accordion you can use everywhere. Super smooth, 60 FPS, uses request animation frame, and all that stuff. Either way, dialogue is a really great API that just straight up not enough people use. Again, it works well with your keyboard, and just overall is something. If you're building any Sanity kind of accordion, consider using a instead of dialogue, consider using a details element.

I have a question for you, Wes.

Yes. Here's a quiz. Let me actually, I'll do a multiple choice on this quiz because I don't think you'll get it straight up. So the details element, aka the accordion element.

When was it added to Chrome? Was it 2010, 2011, 2014, or 2000 and sixteen? 2011.

2011. So it has been in Chrome since version Wes.

Version 12, it was added to Chrome. It was in Safari in version 6.

So, folks, it's been here forever. You should be able to use this. There's no reason not to. Beautiful. Well, that is it's amazing how much is just being added to

the platform right now and having them all together, especially, like, once anchor lands,

man. Oh, yes. Anchor, starting styles, allow discrete, calculate, size auto. All those things,

give them now. I want them. Yeah. Yeah. They're all It almost feels like you need to, like like, this is a lot to learn. You know? Like, even if you know CSS, I think, like, this is a whole bunch of new stuff, and I think it's a new way to sort of tackle a lot of your UI. So I think all of these things are probably worth building something in right now because either today or in the next 6, 12 months, I think you're gonna be able to start using these in your apps.

Yeah. Yeah. And in fact, I I that was the whole premise of my talk was here's all of these things, and I'm giving it a a a check it out, a try it, or a ship it Scott. So you can see, like, like, which of the one of these I say you can ship today, you should try it today, or you should just be aware that it exists. And for the most part, a lot of these are you can try all of them today. Anchor, just kinda know it exists, and and some of these other ones. But by all means, any of the ones that we said you can ship today whether a polyfill or without or there's a nice fallback, then ship that stuff because it's it's a it's a huge plus. And a lot of times, people are using their their JavaScript framework to handle all this stuff, and you just don't have to. So, yeah, that's all I got. Yeah. I'm excited to see, like, all of the component libraries start to roll out with this. I'm pretty sure the

Wes Awesome shoelace guys are using all these APIs, and, like, the next generation of component libraries are going to

natively use all of these things. Yeah. Imagine shipping something like that without having any additional JavaScript come in in your component.

Dan, gotta love that. Just ship less and less and less. Cool. Well, let's get into the part of the show that we're calling sick picks, where we pick things that we like. We think they are sick. We think they are interesting.

And I'm going to have a sick pick, which is a Twitter account, but also a I think it's like a let's see what their actual service is, because I believe they have a service. Yeah. They have a suite of revolutionary products for mobile app development, which I I don't necessarily care about. What I what I care about is this Twitter account is really interesting Wes all they do is they analyze native apps, and they discuss what APIs and what packages they're using. So they'll break down real native apps and be like, okay.

So and so is using Sentry to track their bugs. This app what was the Node the other day? It was, like, something ridiculous. They were like, this is the largest app we've seen for, like we don't know why. And it was, man, it was something really ridiculous. And the the app was like a a gigabit and a gigabyte in size. And then we're like, why the why the hell would this be a gigabyte in size for this app? But, yeah, you can see who's using what.

For instance, Sunno AI or Suno, whatever you call it, is using RevenueCat, Firebase, Clerk. These are all things that you may have heard of. So you can see what tools and what resources real apps are using out in the world. I always love it when they ping Sentry and say so and so is using Sentry. So pretty neat. Awesome. I'm going to sick pick a TV show, which is not something I often will do.

But we had Tim Newkins on from Next. Js, and he sick picked just, like, Apple TV in general. And I was like, Apple TV. I usually I always default to, like, Apple stuff not being very good. So I I never gave Apple TV, like, the the time of day. So I took a look at it, and I was like, oh, there's actually some decent ones on here. So we subscribed for a month.

I think you you gave me that tip many years ago where it's like, just subscribe to, like Oh, yeah. To one of these services for a couple months. Watch the stuff and then ditch it and then do another one. So we were watching we watched hacks. Have you ever seen this? And, unfortunately, it's not about hacking, but it's about I've heard of it. Comedian, who or 2 comedians, 1 older, 1 younger, who I'm not doing it justice, but it's a very good show. If somebody who likes I like Seinfeld. I like it's an HBO show, so it kinda has that whole vibe to it. Fantastic. I usually don't like TV shows, especially for very long running ones, And Hacks was fantastic. All, I think, 3 seasons so Yarn, been a big fan of it. Okay. Kaitlyn Olson's in it from, Always Sunny. Oh, yes. Yes. Yeah. She's the daughter of it, which I thought that was really good.

Big fan. As soon as you said that, I'm like, I don't know. But my wife and I just got finished watching The Bear season 3. You watched The Bear? We haven't finished season 3. In fact,

just yesterday, Courtney was telling her sister and, her husband that, like Yeah. She's out. She watched, like we watched up until, like, you know, maybe episode 6 of season 3. And and just, like, the the

intensity is, like, really killing. Artsy. That's the that happens every now and then. Like, the 1st 2 seasons of the bear, fantastic. Amazing. One of my favorite shows ever. Season 3, they went so artsy and, like, not that that's a bad thing, but it just wasn't enjoyable to watch. You know? And, every now and then, like, t you can tell that, like, people work on TV shows just wanna, like, express themselves, But, like, I just want the the regular funny TV show, please. You know? Like, go do a side project if you need that type of thing. So that was kind of a bummer. But they had lots of, like, people join for, like, a single episode, and my wife kept being like, that's this person. That's that person. Who's that? And she had to, like, pause and figure it out. Like, I don't know who anybody is. I just wanna see the funny people on the on the TV.

Yeah. I you know what? I I am kind of the opposite where I wanted to be already, and those episodes are just kinda like vignettes and, like, weird little,

like, snippets and whatever. I gotta say back in time. You know? Like, it's like, when what when was this filmed? Trying to figure it out.

I know that I know that people don't like that, and Courtney does not like that either.

There's something about the hipster in me that likes that a whole lot, especially if other people are not liking it. I'm like, oh, yeah. This is where it gets good. But no. I I I hear you. I think that the tension isn't for me or just, like, the intensity of it all. It just builds and builds and builds. Yeah. Stressful.

Yeah. For sure.

Cool. Shameless plugs. I'm gonna shamelessly plug the Syntax YouTube account. I just released a long form tutorial.

My first one in quite a bit, in fact, since since, Vercel up tutorials became Syntax.

I I just recorded this long tutorial on Yeah. It it's called local first from scratch, and we're building a the basis of, like, an invoice app, but we don't actually build that much of the app. The important stuff is is that we're working with local data entirely. So if you're curious about local first, we build an app that works completely offline.

All the data is stored locally in your browser, so you own all the data yourself. It auto saves. So whenever you type into an input, it saves automatically the date to the database without penalty because you're not doing network requests.

And, you can export the data to JSON at the end of the day. So if you are interested in something like that, a fully offline local data application, check it out. We build it in about 41 minutes. So it's pretty sick. Beautiful. Alright. Thanks everybody, for tuning in. We will catch you later.

Peace.