The New Defaults of the Modern Web

I will start with a really short and fast retrospective on my career because right now I'm doing documentation and dev stuff for Storyblok. But more than a decade ago, I was working for marketing agencies on a lot of different types of websites. Some of them were landing pages. Actually my first project was the Microsoft Windows 8 launch landing page, and that's how you can tell that I'm really old.

Also brand guidelines, promotional and movie sites. Some of these movies were really well known, I can't mention right now, but after the talk you can come and ask me. And probably my favorite ones were social initiative programs. These sites were super different visually and on design, but on the variables they were actually quite similar. We were doing the same thing over and over again.

These experiences were really scrolling immersive sites. You would get full height panels. When you scroll, you would get these indicators because you could never see below the fold that there was more content to be explored. So we always had these kind of helping CTAs. We would have scroll snapping, so you would never see this every time you tried to scroll. We would stop that, hijack, and show you the next panel. And then when the panel became visible, we would run some animation, even some videos and WebGL scenes. This was not the only thing that these sites had in common.

And they were also full of hacks. We were actually like twisting the arm of all the browsers. We were trying to do stuff that wasn't actually possible with the native web. And the code was really hard to maintain because of these hacks were accumulating over and over again. We were adding a bunch of code. Remember these sites had like really heavy assets, images, videos. So on top of that, a lot of code. Super. And it took a lot on a mobile network to actually see the sites. And even after you loaded everything, the performance was actually quite bad because it was full of hacks. And I kept reflecting a lot how much CSS on the web APIs have improved on the past five years maybe. And how much I would have loved to have like the new CSS, but like 10 years ago. So this talk is about this feeling of the new defaults of the modern web that would allow me to build these sites in a better way.

Super fast because this is a lightning talk and I don't have a lot of time. That's my name. That's what I do. That's where I live. That's my face. And that's me on BlueSky and that's my blog.

Let's cut to the chase. First problem. We wanted full height panels on each section. In desktop, of course, it's like super easy. But the problem were mobile, actually. Mobile, you have this kind of like browser UI elements that would get into the way that would modify the height of the viewport.

And sometimes these UI elements would cover important information. Some of them were like this CTAs to scroll. And so this was not a detail that we could overlook. So we found out that our users on mobile will like rest their thumb on the screen while waiting. I think that everybody does that.

So we created this hack where on touch start we would recalculate the height of all the panes and then we would actually remove the event listener. The problem is that the user might not do that. We think that they might do that. But they might actually rotate, scroll. So we had to do that for all the events, which was not cool. And I didn't like it. I need to be honest.

It worked. But it didn't feel right. So yeah, that is now one line of CSS. It's just that. If you don't know that unit, that's like dvh. That's dynamic viewport height. And that unit adapts when somebody with something actually this kind of UI elements from the browsers actually cover part of the viewport. And that’s cool. That's not hacking. That's dynamic viewport units. That's the name of the API.

Scroll animation. We have this kind of CTAs that you would click or tap and the next panel would scroll. Of course, there's no native option for that 10 years ago. So what we would do is that we would access to the offset top of the next pane that we wanted to show. We would get a scroll container and we would, with a library, animate the scroll top property of this container. Issues. So every time you access this kind of properties like offset top, you would trigger a layout recalculation on the browser. Not cool. And also, animating scroll top is not GPU accelerated, so the performance was actually quite bad. Right now, super simple. You can just use a scroll interview to the balance. Actually super old API.

It's present in Internet Explorer. But the main difference is that now we have scroll behavior on CSS, which is with one line on the scroll container, you get this done. And that is a scroll behavior. Next thing. Scroll snapping. The thing that I mentioned that would never happen in these projects is this kind of like half of one panel and the other half in one panel, we would block you every time that you wanted to scroll. And the way that we did that was, guess, a hack. We would detect when you were trying to scroll. We would prevent default, so actually not scroll what happened, but we will still get the coordinates of that event. And we would calculate the direction of that. Which is a current pane, call a function, and we would animate that pane out, and the next one in. Yeah. Again, not cool, because I can tell you that the main thing was not performance here, maybe, but breaking the browser native scrolling inertia didn't feel right in UX. Some sites even do that today. I don't know. So, not cool. The solution? Scroll snap as a CSS API. Two lines. Basically, you set the type on the container, and then the align one on the pane. And you got it done. That's just no JavaScript. This is probably my favorite CSS API. So, so powerful in just two lines. It's amazing. Scrolling interception. I told you that we wanted to animate some stuff every time that a new panel comes in. So, yeah, no native option ten years ago. So, when we wanted to intercept that panel, we needed to listen to scroll, and every time that you scroll, we would get the offset top again, and we would get the current pane given that position. And after that position, we run some animations, and after that animations, we need to clean stuff up. This is because performance was such a problem that we would remove some assets, stop some animations on other panes that were not active, and yeah.

It still didn't work, honestly. And you had some panels off screen, like, I don't know, running some WebGL or some videos. It was actually quite tricky. And right now you have the intersection of server API, and that's super simple, because you just check if the panel is intersecting, you run the animations, and for a super easy performance gain, you can just unobserve the target. Cool.

Intersection of server. This is actually quite old. So, person in old browsers. We have animations. As I told you, every time that we intercepted one of these panels, we wanted to animate pretty much everything that was inside it, because we were really into motion design. And specifically, we were doing complex animation flows. So we wanted promise-based animations. We didn't have that. There were actually great animation libraries. There was GreenSock, which was one of my favorites at the time. But it had no promises. It was all callbacks, and it was actually quite hard when you needed to animate, I don't know, more than seven elements, and these animations were actually quite convoluted.

For animations, yeah, we created our own promise wrapper for GreenSock, which added a lot of code on top of the other code that we had. So we didn't like it, and right now you have an animate function for each HTML element. You just grab the HTML element, call .animate, pass an array of transforms that you want to do, and the most interesting thing is that this returns an animation object, and that animation object has a finished promise. You can await and await and await and await, and that's actually a promise all for if you want concurrent animations. It's super cool. It's just one line. Amazing. Web animation API. And the last thing that I'm going to talk about today is view transitions. You might have heard of it, because it's actually quite new. It's only on Chrome and Chromium. But the main thing is that just for this thing, we had to use a framework. I'm not against frameworks, but these projects were not hard to build because of the web application feature, but because of these hacks.

But then on top of that, we had to actually use a framework just to use this transition and animate the page when they were swapping and revealing, and right now you have a view transition API available for you. So that's quite cool, and the result is actually a web like this, just fully animated, super controlled scrolling. You can see how the elements flush in. Super nice. You can see it feels natural, because this is actually the browser scroll inertia. I'm not hijacking anything here. This is not a video or nothing. This is actually an application. It exists. You can scan that QR code and just write that web URL, and also the code is available on GitHub.

You can also scan that QR code and get the code. Actually super simple, literally like 20, I don't know, 30 lines of code for both CSS and JavaScript. And that's it.

Thank you so much. Thank you.