CSS Between the Pages

I'm at 295 GitHub repositories.

I don't know if you've got more come and share them all with me, but Yeah, thanks for great introduction Again, my name is Phil Nash.

That's me all over the internet.

I am surprised unsurprisingly Phil Nash everywhere and Sonar it's where I work.

I'm a developer advocate there, and we are the home of Sonarqube, Sonarcloud, Sonarlint.

All tools that will help you write better, cleaner code.

Different parts live in different parts of your, build process or your pipeline or whatever.

But, we, all we want to do is help you write better code, help you write clean code.

If you want to talk to me about that, I'd absolutely love to, to hear about it.

So cool.

Let's get onto, the view transitions API.

That is what I mean by CSS between the pages.

It's a very exciting, very new thing that I'm just absolutely delighted to see.

And I'm gonna, there's kind of two sides to it.

We need to, talk about it in two different ways.

And so we have single page application transitions and then multi page application transitions.

I'm never a fan of the phrase multi page application because it just means 'website' It helps as a trade off to our now slightly more default SPA kind of attitude.

So if you're doing single page transitions, you might write a bit of code like this.

You have some HTML on the page, and then in your JavaScript down the bottom, we grab our element, and then to do a transition, we maybe have some new HTML element.

However you produce your DOM, it doesn't matter.

But in this very simple example, we might have some new HTML.

We grab the filters of the first element and we apply them, then we change the HTML behind it, and then we play those filters, right?

And the filters look like this.

That's proj id dx image transform.

Microsoft.

Blinds, blinds is my favorite.

And it looks, it ends up looking like this, right?

This is Internet Explorer 8.

Doing a blinds transition on a piece of HTML.

Isn't it glorious?

Turns out we've just invented something that, and this is Internet Explorer 8, because I couldn't find myself an older VM, it turns out this came back in Internet Explorer 5.5, so we are just reinventing new stuff again.

And the good news is they also did multi page application transitions with a meta tag, if you have the HTTP equiv, of page enter, and you could use page exits in order to do on the way in or the way out.

And then the content is just another filter kind of thing.

So that's it.

Internet Explorer invented the web.

We, owe our lives to it.

Thank you very much.

I'm done.

I feel bad because Ben did an I'm done joke at the start.

And now I can't rewrite your slides halfway through somebody else's talk.

The View Transitions API.

It's a wonderful new piece of technology.

That perhaps, works a little better than Internet Explorer's version.

That was never adopted by anybody else, funnily enough.

Even though it wasn't the worst API in the world.

Taking a piece of CSS, applying it, and then, and doing stuff afterwards is cool.

But no, we have a different way of going about this now.

And it does still split up into that SPA, MPA thing.

That's not a, lie, not a joke, not part of it.

But first I want to talk about why.

Why we want this.

Why we need this, why we have to consider, view transitions as a, thing that we might need on the web.

I think for a lot of the time, we have invented many JavaScript things, many different ways to write a lot of code to avoid this.

To avoid a slight flash of white between seeing content on one page and the next page.

And I understand that, it's slightly jarring every time you go between web pa web pages.

Which is you know, it's, just been built into the platform since forever and anybody who's working on it forever understands and deals with it, or, magics up a new, framework, to avoid this, and handle things like, handle navigation, handle, page loading, having data loading, all that kind of in JavaScript.

We've done an awful lot of work to avoid flashes of white, by taking over things that the browser does and doing it for it.

It's about understanding and dealing with state.

Everything comes down to state in the end, in the web.

And and what we're trying to do is control that state.

We want to control and understand that state so that we have the ability to change certain things on a page without changing others.

And that has been a goal of our user experiences, for a long time.

We managed this a little bit, like it's, we have been able to build transitions between pages when we are in control of everything, when we're using all of our JavaScript.

But it turns out it is a bit of a pain, right?

The idea of a view transition, where you transition one thing, to another, actually requires the state of both things to be live on the page at one time, in order to maybe fade between it or, move one off while another one comes on.

And that's actually a pain, that's hard.

When you, render a component in React and then you render a new one, it doesn't hold both things in memory at one time in order to move between things, it, it, it swaps it out and you have the new stuff.

And you have to try and do other things to move around that.

And controlling that state is a pain, and so we get a new API in the browser to make it easier.

That's the idea.

And so let's see it in action.

I have a terrible website.

I did not spend a lot of time building this website.

And this is a single page application, these links don't go anywhere, they just replace stuff on the page.

It looks this in the back end.

We have this content here in my JavaScript.

And, and when I click a button, we've called the update document thing, which takes the old HTML, saves it, puts the new HTML into an HTML.

Lovely.

And we get this.

We have a single page application, so the header and the footer aren't changing and that's nice, but, it's just a jarring, switch between the two.

And so when we call on update the document to use the, view transitions API, we merely add, document dot start view transition.

We hand it a function that it can call to do the, to update the document.

And then when that is done doing it, it's finished with the document.

If we do that and refresh the page, now we get a crossfade.

We've done one little line.

We've changed some HTML.

And it went from snapping between things to crossfading.

Nice.

That's a good start.

I like that.

I like the fact that it was only one line.

And there are ways to handle that inside frameworks, quite easily, there's documentation on this.

And so that's it.

It's this one kind of simple line of document.

StartViewTransition.

Of course, being the DOM, being, JavaScript, we can also listen to events to see when a transition starts and ends and look after other things about it.

But this is basically the crux of the entire, JavaScript side of it.

When we're in a single page application, this is what we need to know.

And this is what it does under the hood.

This is the brilliant part.

We haven't actually had to hold on to both bits of state, both bits of HTML at the same time.

We are still, switching it.

But when we call on StartViewTransition, the first thing the browser does is take a snapshot, basically a screen grab of what we can see on screen right now.

It then applies the effect and takes a snapshot of that rendered and then transitions between the two.

And what it does with those snapshots is render a bunch of, pseudo elements that look like this.

We get a view transition pseudo element that sits around the whole lot, isolates itself and puts on self on top of the page.

We get a view transition group, which contains the lot.

We get a view transition image pair, which is a parent to both the next bits, the view transition old and the view transition new.

These two are then sibling elements, sibling pseudo elements, although the view transition new, because it's afterwards, sits on top of the old one.

But they are siblings, so we can move them around with z index and things like that.

And we basically, you start that view transition, and, it, yeah, makes a whole bunch of layers.

Lots of fun layers for you.

And like I said, yeah, the old version is underneath.

The new one's on top and we, and we just carry on.

Now we could do things, to make this a bit nicer, right?

We have this kind of fading back and forth.

And I think a crossfade is such a lovely default for this.

It's really nice, but we can control this as well.

And the control all comes in CSS.

That's the title and CSS between the pages.

So what I might do is, produce myself some animations in CSS, in this particular case, I want the content to fade in and up onto the page.

That's just my idea, I'm not a designer, I need somebody else involved to actually do the animations.

If you saw Matt's talk yesterday, but we have a fade up and a slide, up and down.

And so what I'm going to do is, uncomment this a little bit, which applies those animations to our new pseudo elements.

And now, the old one is going to, fade out and side up.

And the new one is going to fade in and slide up from below.

So now if we refresh that page, I've broken it.

It looks horrible.

I made a white flash.

I'm sorry.

The entire page, is now like fading away and up and then fading in and up from the bottom.

And that doesn't look great.

And so we need this ability to take parts of our page and control them independently from maybe the rest of the page.

And we can do that, also in CSS, by naming it.

All we have to do is name parts of the page, and in this case I'm going to take the header and the footer, give them a view transition name, and that will independently set them up with a whole bunch of other layers, much the same as the entire page.

And because they're not going to go through the same, they're not applying this CSS, they're applying the default, the crossfade, it ends up looking like this now.

Now, our whole page is doing that fade up and in, but header and footer are independent layers.

They're not doing that.

So that's quite nice.

I think it looks quite pretty.

I like it.

And so that's it.

When you give something a name, we then create a new view transition group for that, which has the name in the, ah, that's the same.

That has the name, in the, in the brackets part there, in this case header.

We create a whole new layer, which sits, parallel to the rest of the page.

And this is quite good actually, because if you do this to multiple parts of the page, they all during the transition phase, sit next to each other, so you can, you don't have to worry about trying to escape elements from, their containers.

They are not contained whilst they're in this view transition stage.

It's nice.

Actually even better.

And it doesn't show it in my demo just then.

But if that header offers it needed to move somewhere, then, then the browser will also do its best to morph it into that position.

And we'll see a bit of that, a bit later.

It's important to call out, the debugging is important in these things, especially because we're between kind of page actions and things like that.

But the nice thing is that because we are just dealing with the, animations API, it's just CSS animations, then the little animations, thing in the, in DevTools is available to us.

And so I can actually just pause it immediately, slow it down to 25 percent and it's paused.

So if I hit that right now, the animation itself is loaded here, which is cool.

And then we can play with it.

Ooh, look at that.

So it's just the same as any CSS animations.

And if you have experience with that, you already know how to play around with things, and then I can just wind it all the way back.

Play it quarter speed.

Nope, it's not playing.

Fine.

It is playing, just really, slowly.

No, there it is.

Play at a tenth speed.

Real slow version.

So we can actually, dig right into the animation and see what's happening between the page.

I think that's very useful.

Some other important things that we need to know about this, we can, if you have an element that you've named and it's, it comes either it's not existing on the page and arrives on the page or the other way it was on the page and there's no kind of named element that it's, that will be on the next page, that we can handle that separately, using the only child pseudo class, this allows us to do like an entrance animation or an exit animation, on that either on the new element or the new transition secondly, now we're playing with moving stuff about as we move between pages, as we move between parts of the application, we need to handle the accessibility side of things.

And do not forget your media query for prefersReduceMotion.

If a user has requested, to reduce the motion or not have as much animations.

The, the biggest, like the hammer on that is just turn them all off, turn all animations off, or you could do a quicker and more subtle thing, is reducing motion, not no motion.

Don't forget that.

Absolutely important.

And there's plenty more I could tell you about this, but actually it's all very well written, on, on the Chrome, developer blog, in a, in an article by Jake Archibald, which tells you a whole bunch of useful things, lots of good examples, and I fully recommend reading, Smooth and Simple Transitions with the View Transitions API by Jake.

It's a great article, goes into such a lot of depth.

Shows you a bunch of stuff that you can do with it.

Because I want to get into the other side of things.

Okay, there's browser support, fine.

It's in Chromium things.

That's, that's your Chrome, that's your Edge, Opera.

Actually, I think it is in Samsung Internet.

I didn't think that for a while, but I think Can I Use has been lying to me.

I just don't have a Samsung to try it with.

But this is, according to Can I Use, 65 percent of the web.

You can go and do this right now, today.

You can simplify your view transitions in your, in your single page applications by implementing this now.

And I think that's very cool.

But for those places that don't support it, it is of course a progressive enhancement as well.

If we don't have access to the startViewTransition function, then we simply do what we were doing before.

We go back to either having it snap or trying to control that transition yourself.

If it does exist, then use the API.

Brilliant.

I love progressive enhancement.

I love fitting things in, to make it better for people who do get it, who do have access to that in their browser.

And like I say, 65 percent is most.

But let's switch things up a bit, and talk about the multi page application side of things.

Because I think this is the really important part of this.

We've been doing transitioning between single page application stuff for a long time, we know what we're doing there.

And whilst this makes it easier and gives us a platform primitive to which to do and using the platform has been a bit of a theme of what we've, what we've been talking about in this session.

It does seem a bit old.

So multi page application transitions, my favorite part, it comes with a warning, of course, that this remains experimental.

If you want to play around with this right now, you do have to open up, I've been dealing with this in Chrome.

You do have to open up your Chrome flags, and find the view transition section and check viewTransition API for navigations.

That is going to turn on a whole world of view transitions for your multi page applications, and it's wonderful.

And it's even better, like progressive enhancement by checking for the existence of a function and using it if it's there is one thing, but progressive enhancement by simply adding a meta tag to the page is a whole other thing.

It's so easy.

If you add the meta tag view transition with a content same origin, which is the only thing it can be right now, it will trigger this in your application.

There is work being done on cross origin stuff, but, for right now, as long as you're on the same origin, same domain, this is gonna work for you.

So let's see that in action.

I have a second So this is the, version of this site, which merely has, two pages and it goes back and forth.

If you look very carefully at the, URL bar, you can see that is changing between MPA and MPA2.

We're not doing anything, but if we open up our layout and uncomment our meta tag.

It's just a meta tag.

We get our transition.

It's amazing.

And because this is the same page, it's using the same CSS, we've actually, got the transition that we made at the start of the, in the previous demo.

And yeah, this is, going across.

This is cross navigation, yet it's happening exactly the same as our single page version was working.

Oh, that's doing it still at 25%.

With just a meta tag and a bit of CSS.

And so it turns out there's actually not a lot more I can tell you about how to use it for multi page applications, because that meta tag is the equivalent of writing startViewTransition, and everything else I already said, counts for it.

The page, the browser, will, load, it will take a snapshot of the page as it is, whilst it's loading the next page in the background, it renders the next page in the background, it takes a screenshot of that, and then it will transition between the two of them.

And it's amazing.

We don't have to worry about any JavaScript in this whatsoever.

And I think this is the future of some parts of web development.

I hope I can take you along with me on this, because we need support to get it from this experimental mode up into browsers and up into what we can use day to day.

It's the future of web development because, as I said earlier, we've spent a lot of time putting a lot of effort into our JavaScript frameworks that stop us from having to reload pages and see a flash of light in the middle.

And now we no longer have to do that with just the simple addition of a meta tag.

It takes me, it makes me think about the difference between a website and a web application.

This is, I'm sure, a debate that has happened many times in many places, many bars after work or over coffee in the morning.

But what a website and web application is, and what's the difference where they lie on a spectrum?

My kind of take on this recently, as I've been thinking about this, has been the website is really good at having content and URLs that address that content.

We navigate through it and we change URLs and we, are allowed to address those different parts, of an, of a site that way, whereas a web application doesn't necessarily adhere to that idea of a URL as a resource, that kind of thing.

We've seen some great examples of web applications, over the course of this, conference, in, in examples that have appeared, on slides over the last two days.

Alex's Pagez is definitely an application, right?

It's, a thing where you're loading it up and you're actually working with, content that's inside the page.

We've seen that Photoshop is a web application right now, a hundred percent not a website.

There's no URL for, the layer, that you are currently dealing with or anything like that.

And there doesn't need to be.

But the problem is.

I think for a long time we've defined this difference between websites and web applications by the amount of technology we used to produce the final result.

And if you are using, Angular or Vue or React or, something like that, you've built yourself a web application, even if it turned out that it's a shop or a blog or a news site or, any content based, thing.

Because of the technology, it became a web application, but because of that technology, it also became more brittle.

It became, the risk, the whim of JavaScript and what something going wrong can do can leave you with a blank page with nothing to see.

And that's, that's a bad thing, right?

Like HTML and CSS are some of the most resilient parts of the web itself.

And the idea of, the principle of least power is that using the technology with the least amount of power to achieve the goal you need leaves things to be more resilient, more useful, more usable much of the time as well.

And so what I think this, what I think view transitions can do, give us the, it gives us the ability to build the experiences, the lovely experiences that we can do as we move between different parts of an application, to a website, as we move between different URLs, we can now build, those transitions, to work well for us and we can reduce the amount of JavaScript, reduce the amount of stuff we do, we, we have to build in order to make a website and we can just change the, the section on the dial, the section on that spectrum between website and web application, where we choose to, put in a lot of JavaScript to do that for us.

And so that's what I think View Transitions can do for us and we can build the most exciting transitions we want to.

It turns out I, I had quite a lot of fun with this talk, when I, firstly, when I realized Internet Explorer did this already, but then I realized I wanted to go and build some of the transitions that it could do itself.

I think this says demo.

Yeah, there we go.

And so I've started building myself a set of unnecessary cross page view transitions that you can, you can build.

This is, hasn't been published yet, but it'll come out soon.

And, Blinds is absolutely my favorite.

So a little bit of CSS and, and we can build our own blind transition between two pages.

This is actually based on a, on an example from Artur Bien's fancy reveal animations, that he wrote about, earlier in the year and taught me a bunch about different parts of CSS that are available to us now, bits of, CSS Houdini kind of leaking into this with, defining a property so that we can, define an animation over that property.

And then, and then repeating linear gradients that shrink so that we get our, our blind section.

But there's more fun things we can do with this.

I, had some fun by sliding things out.

That's merely translating stuff from one side of the page to the other, or sliding things up.

Cross wipe need more of that, I think on the web.

I haven't managed to build myself a star wipe yet, but, I'm getting to it.

Although this spiraly one is very nice.

I think animate a iconic gradient over the, over the top of a whole webpage.

Amazing.

And then, I like this in circle one as well, CSS clip path, an underused thing that, perhaps we should abuse for this.

And what was the final one?

Oh, just scaling in.

Woo.

Like that.

But there's other demos out there.

These ones are not, I haven't, built myself, but I really like and wanted to include.

This is just a photo gallery version.

I believe under the hood, it's using Astro, to power these transitions between different pages.

And I think it's absolutely beautiful.

And secondly, this one actually came up on a slide yesterday, I think, from Steve's talk on new things in CSS, the, Astro Music Library, in which this is all, multi page application that can actually, it doesn't matter what the music is, but if we start playing that, then that actually continues to play, the bottom of the page, whilst you then navigate around other parts.

Now I will say, this is Astro being a little bit sneaky, because it turns out, this is a single page application.

It just pretends it's not.

Under the hood it's actually using something similar to Turbo, Turbolinks or Pjax, the idea of the JavaScript taking over, loading the entire HTML from the server and then replacing it on the page, and using view transitions in the page to change that.

And because of Astro's island architecture, You can take that player at the bottom and set it outside of that, update.

And so technically they cheated and made a, a multi, a single page app, but I think it's cool.

And it does still act as if it's a multi page app.

You can see the URL changing as you do indeed, navigate the page.

And so I think that's cool.

And then of course, because I don't like myself and I wanted to make things harder, it turned out this entire slideshow is also of course, a multi page application, it's actually built in Eleventy and it just has a bunch of URLs.

The amount of JavaScript that goes into this page.

Is, this, it just allows me to, grab a couple of links off the page.

And when I hit the, clicker or the keypad, keyboard, it allows me to change from one page to another.

And so I think the fact that entire presentation is powered by 13 lines of JavaScript, I think's cool.

So let's bring it back up.

So ultimately, I just want you to think about, one thing as you go away from this.

Two things.

View transitions: very cool.

Have a play with them.

But secondly, think about making the right choice when you come to build a website or web application.

What's the amount of technology you need for this?

The amount of JavaScript you need to achieve what you want to get out of this?

And if it is just a nice user experience as you navigate the site, then the future is view transitions.

If you are dealing with more state and more things, then sure, we can reach for the JavaScript, but, view transitions will help you there as well.

But, URLs and multi page applications are cool and will be cool again.

So make those right choices.

Think about that as you go through this.

Yeah, my name is Phil Nash.

I'm a developer advocate at Sonar.

It's an absolute pleasure to, to chat with you about this.

Please let's talk about view transitions as we go to lunch now.

And, and tell me everything you want to find out about it.

I'm going to share these slides, cause they're just a website.

They'll be online later and I will share the link out later, but otherwise, thank you so much.