Some great ideas for view transitionts in here! Also:
If you look at any of the examples on a browser that does not support them, the pages still function just fine. The transitions are an extra that’s layered on top if and when your browser supports them. Another concrete example of progressive enhancement in practice.
This is a terrific talk by Jack on how to deal with the tooling involved in modern front-end development:
- Maintaining control,
- Dependency awareness,
- Lean on browser primitives,
- Have an exit strategy.
I must admit, when Jake told me he was leaving Google, I got very worried about the future of the View Transitions API.
To recap: Chrome shipped support for the API, but only for single page apps. That had me worried:
If the View Transitions API works across page navigations, it could be the single best thing to happen to the web in years.
If the View Transitions API only works for single page apps, it could be the single worst thing to happen to the web in years.
Well, the multi-page version still hasn’t yet shipped in Chrome stable, but it is available in Chrome Canary behind a flag, so it looks like it’s almost here!
Robin took the words out of my mouth:
Anyway, even this cynical jerk is excited about this thing.
Are you the kind of person who flips feature flags on in nightly builds to test new APIs?
Me neither.
But I made an exception for the View Transitions API. So did Dave:
I think the most telling predictor for the success of the multi-page View Transitions API – compared to all other proposals and solutions that have come before it – is that I actually implemented this one. Despite animations being my bread and butter for many years, I couldn’t be arsed to even try any of the previous generation of tools.
Dave’s post is an excellent step-by-step introduction to using view transitions on your website. To recap:
Enable these two flags in Chrome Canary:
chrome://flags#view-transition
chrome://flags#view-transition-on-navigation
Then add this meta element to the head of your website:
<meta name="view-transition" content="same-origin">
You could stop there. If you navigate around your site, you’ll see that the navigations now fade in and out nicely from one page to another.
But the real power comes with transitioning page elements. Basically, you want to say “this element on this page should morph into that element on that page.” And when I say morph, I mean morph. As Dave puts it:
Behind the scenes the browser is rasterizing (read: making an image of) the before and after states of the DOM elements you’re transitioning. The browser figures out the differences between those two snapshots and tweens between them similar to Apple Keynote’s “Magic Morph” feature, the liquid metal T-1000 from Terminator 2: Judgement Day, or the 1980s cartoon series Turbo Teen.
If those references are lost on you, how about the popular kids book series Animorphs?
Some classic examples would be:
I’ve added view transitions to The Session. Where I’ve got index pages with lists of titles, each title morphs into the heading on the next page.
Again, Dave’s post was really useful here. Each transition needs a unique name, so I used Dave’s trick of naming each transition with the ID of the individual item being linked to.
In the recordings section, for example, there might be a link like this on the index page:
<a href="/recordings/7812" style="view-transition-name: recording-7812">The Banks Of The Moy</a>
Which, if you click on it, takes you to the page with this heading:
<h1><span style="view-transition-name: recording-7812">The Banks Of The Moy</span></h1>
Why the span? Well, like Dave, I noticed some weird tweening happening between block and inline elements. Dave solved the problem with width: fit-content on the block-level element. I just stuck in an extra inline element.
Anyway, the important thing is that the name of the view transition matches: recording-7812.
I also added a view transition to pages that have maps. The position of the map might change from page to page. Now there’s a nice little animation as you move from one page with a map to another page with a map.
That’s all good, but I found myself wishing that I could just have those enhancements. Every single navigation on the site was triggering a fade in and out—the default animation. I wondered if there was a way to switch off the default fading.
There is! That default animation is happening on a view transition named root. You can get rid of it with this snippet of CSS:
::view-transition-image-pair(root) {
isolation: auto;
}
::view-transition-old(root),
::view-transition-new(root) {
animation: none;
mix-blend-mode: normal;
display: block;
}
Voila! Now only the view transitions that you name yourself will get applied.
You can adjust the timing, the easing, and the animation properites of your view transitions. Personally, I was happy with the default morph.
In fact, that’s one of the things I like about this API. It’s another good example of declarative design. I say what I want to happen, but I don’t need to specify the details. I’ll let the browser figure all that out.
That’s what’s got me so excited about this API. Yes, it’s powerful. But just as important, it’s got a very low barrier to entry.
Chris has gathered a bunch of examples together in his post Early Days Examples of View Transitions. Have a look around to get some ideas.
If you like what you see, I highly encourage you to add view transitions to your website now.
“But wait,” I hear you cry, “this isn’t supported in any public-facing browser yet!”
To which, I respond “So what?” It’s a perfect example of progressive enhancement. Adding one meta element and a smidgen of CSS will do absolutely no harm to your website. And while no-one will see your lovely view transitions yet, once browsers do start shipping with support for the API, your site will automatically get better.
Your website will be enhanced. Progressively.
Update: Simon Pieters quite rightly warns against adding view transitions to live sites before the API is done:
in general, using features before they ship in a browser isn’t a great idea since it can poison the feature with legacy content that might break when the feature is enabled. This has happened several times and renames or so were needed.
Good point. I must temper my excitement with pragmatism. Let me amend my advice:
I highly encourage you to experiment with view transitions on your website now.
The thinking behind the minimal JavaScript framework, Strawberry:
Even without specialized syntax, you can do a lot of what the usual frontend framework does—with similar conciseness—just by using
ProxyandWebComponents.
I did an episode of the Clearleft podcast on innovation a while back:
Everyone wants to be innovative …but no one wants to take risks.
The word innovation is often bandied about in an unquestioned positive way. But if we acknowledge that innovation is—by definition—risky, then the exhortations sound less positive.
“We provide innovative solutions for businesses!” becomes “We provide risky solutions for businesses!”
I was reminded of this when I saw the website for the Podcast Standards Project. The original text on the website described the project as:
…a grassroots coalition working to establish modern, open standards, to enable innovation in the podcast industry.
I pushed back on that wording (partly because I’ve seen the word “innovation” used as a smoke screen for user-hostile practices like tracking and surveillance). The wording has since changed to:
…a grassroots coalition dedicated to creating standards and practices that improve the open podcasting ecosystem for both listeners and creators.
That’s better. It’s more precise.
Am I nitpicking? Only if you think that “innovation” and “improvement” are synonyms. I don’t think they are.
Innovation implies change. Improvement implies positive change.
Not all change is positive. Not all innovation is positive.
Innovation goes hand in hand with disruption. Again, disruption involves change. But not necessarily positive change.
Think about the antonyms of change and disruption: stasis and stability. Those words don’t sound very exciting, but in some arenas they’re exactly what you should be aiming for; arenas like infrastructure or standards.
Not to get all pace layers-y here, but it seems to me that every endeavour has a sweet spot for innovation. For some projects, too little innovation is bad. For others, too much innovation is worse.
The trick is knowing which kind of project you’re working on.
(As a side note, I think some people use the word innovation to describe the generative, divergent phase of a design project: “how might we come up with innovative new approaches?” But we already have a word to describe the practice of generating novel and interesting ideas. That word isn’t innovation. It’s creativity.)
After nearly two decades of fighting for this vision of the internet, the people who believed in federation feel like they’re finally going to win. The change they imagine still requires a lot of user education — and a lot of work to make this stuff work for users. But the fundamental shift, from platforms to protocols, appears to have momentum in a way it never has before.
I woke up today to a very annoying new bug in Firefox. The browser shits the bed in an unpredictable fashion when rounding up single pixel line widths in SVG. That’s quite a problem on The Session where all the sheet music is rendered in SVG. Those thin lines in sheet music are kind of important.
Browser bugs like these are very frustrating. There’s nothing you can do from your side other than filing a bug. The locus of control is very much with the developers of the browser.
Still, the occasional regression in a browser is a price I’m willing to pay for a plurality of rendering engines. Call me old-fashioned but I still value the ecological impact of browser diversity.
That said, I understand the argument for converging on a single rendering engine. I don’t agree with it but I understand it. It’s like this…
Back in the bad old days of the original browser wars, the browser companies just made shit up. That made life a misery for web developers. The Web Standards Project knocked some heads together. Netscape and Microsoft would agree to support standards.
So that’s where the bar was set: browsers agreed to work to the same standards, but competed by having different rendering engines.
There’s an argument to be made for raising that bar: browsers agree to work to the same standards, and have the same shared rendering engine, but compete by innovating in all other areas—the browser chrome, personalisation, privacy, and so on.
Like I said, I understand the argument. I just don’t agree with it.
One reason for zeroing in a single rendering engine is that it’s just too damned hard to create or maintain an entirely different rendering engine now that web standards are incredibly powerful and complex. Only a very large company with very deep pockets can hope to be a rendering engine player. Google. Apple. Heck, even Microsoft threw in the towel and abandoned their rendering engine in favour of Blink and V8.
And yet. Andreas Kling recently wrote about the Ladybird browser. How we’re building a browser when it’s supposed to be impossible:
The ECMAScript, HTML, and CSS specifications today are (for the most part) stellar technical documents whose algorithms can be implemented with considerably less effort and guesswork than in the past.
I’ll be watching that project with interest. Not because I plan to use the brower. I’d just like to see some evidence against the complexity argument.
Meanwhile most other browser projects are building on the raised bar of a shared browser engine. Blisk, Brave, and Arc all use Chromium under the hood.
Arc is the most interesting one. Built by the wonderfully named Browser Company of New York, it’s attempting to inject some fresh thinking into everything outside of the rendering engine.
Experiments like Arc feel like they could have more in common with tools-for-thought software like Obsidian and Roam Research. Those tools build knowledge graphs of connected nodes. A kind of hypertext of ideas. But we’ve already got hypertext tools we use every day: web browsers. It’s just that they don’t do much with the accumulated knowledge of our web browsing. Our browsing history is a boring reverse chronological list instead of a cool-looking knowledge graph or timeline.
For inspiration we can go all the way back to Vannevar Bush’s genuinely seminal 1945 article, As We May Think. Bush imagined device, the Memex, was a direct inspiration on Douglas Engelbart, Ted Nelson, and Tim Berners-Lee.
The article describes a kind of hypertext machine that worked with microfilm. Thanks to Tim Berners-Lee’s World Wide Web, we now have a global digital hypertext system that we access every day through our browsers.
But the article also described the idea of “associative trails”:
Wholly new forms of encyclopedias will appear, ready made with a mesh of associative trails running through them, ready to be dropped into the memex and there amplified.
Our browsing histories are a kind of associative trail. They’re as unique as fingerprints. Even if everyone in the world started on the same URL, our browsing histories would quickly diverge.
Bush imagined that these associative trails could be shared:
The lawyer has at his touch the associated opinions and decisions of his whole experience, and of the experience of friends and authorities.
Heck, making a useful browsing history could be a real skill:
There is a new profession of trail blazers, those who find delight in the task of establishing useful trails through the enormous mass of the common record.
Taking something personal and making it public isn’t a new idea. It was what drove the wave of web 2.0 startups. Before Flickr, your photos were private. Before Delicous, your bookmarks were private. Before Last.fm, what music you were listening to was private.
I’m not saying that we should all make our browsing histories public. That would be a security nightmare. But I am saying there’s a lot of untapped potential in our browsing histories.
Let’s say we keep our browsing histories private, but make better use of them.
From what I’ve seen of large language model tools, the people getting most use of out of them are training them on a specific corpus. Like, “take this book and then answer my questions about the characters and plot” or “take this codebase and then answer my questions about the code.” If you treat these chatbots as calculators for words they can be useful for some tasks.
Large language model tools are getting smaller and more portable. It’s not hard to imagine one getting bundled into a web browser. It feeds on your browsing history. The bigger your browsing history, the more useful it can be.
Except, y’know, for the times when it just make shit up.
Vannevar Bush didn’t predict a Memex that would hallucinate bits of microfilm that didn’t exist.
I’ve already add the search element to thesession.org, but while browser support is still rolling out, I’m being extra verbose:
<search role="search">
...
</search>Brought to you by the department of redunancy department.
I’ll remove the ARIA role once browsers are all on board. As Scott says:
Please be aware that this element landing in the HTML spec today does not mean it is available in browsers today. Issues have been filed to implement the search element in the major browsers, including the necessary accessibility mappings. Keep this in mind before you get all super excited and willy nilly add this new element to your pages.
A new organisation with the stated goal of keeping podcasting open.
Their first specification is a consolidation of what already exists. That’s good. We don’t want a 927 situation.
My only worry is that many of the companies behind this initiative are focused on metrics and monetization—I hope they don’t attempt to standardise tracking and surveillance in podcasts.
The Podcast Standards Project, a grassroots coalition working to establish modern, open standards, to enable innovation in the podcast industry.
Define “innovation”.
Temporal standards bodies.
Check out the demo that Rich has put together to go with Amelia’s proposed syntax.
Artificial Intelligence sounds much more impressive than Artificial Guessing in a slide deck.
Robin picks up on my framing.
Instead of brainstorming, discussing, iterating, closely inspecting a product to understand it and figure out what to show on a page, well, we can just let the machines figure it out for us! This big guessing machine can do our homework and we can all pack up and go to the beach.
We use metaphors all the time. To quote George Lakoff, we live by them.
We use analogies some of the time. They’re particularly useful when we’re wrapping our heads around something new. By comparing something novel to something familiar, we can make a shortcut to comprehension, or at least, categorisation.
But we need a certain amount of vigilance when it comes to analogies. Just because something is like something else doesn’t mean it’s the same.
With that in mind, here are some ways that people are describing generative machine learning tools. Large language models are like…
I agree with the reasoning here—a new display value would be ideal.
- Don’t wrap too much of your identity in a tool.
- Every tool will eventually fade.
- Flexibility is a valuable skill
- Changing tools does not mean starting over.
I agree with pretty much every word of this article.
Perhaps most problematic of all is the effect that contemporary developer experience has on educational programs (be they traditional classes, bootcamps, workshops, or anything in between). Such a rapidly expanding and ever changing technological ecosystem necessarily means that curricula struggle to keep up, and that the fundamentals of web development (e.g. HTML, CSS, HTTP, browser APIs…) are often glossed over in favor of getting students into the technologies more likely to land them jobs (like React and its many pals). This leads to an outpouring of early career developers who may speak confidently about things like React hooks or Redux state reducers, but who also lack any concept about the nature of HTML semantics or the most basic accessibility considerations. To be clear, I’m not throwing shade at those developers — they have been failed by an industry obsessed with the new and shiny at the expense of foundational practices and end user experiences.
And so, I ask: what exactly are we buying when we are sold ‘developer experience’ today? Who is benefiting from it? And if it is indeed something many of us aren’t too excited about (to put it kindly), how can we change it for the better?
I agree with pretty much every word of this article.
We were told writing apps with an HTML-first, SSR-first, progressively enhanced mindset, using our preferred language/tech stack of choice, was outdated and bad for users.
That was a lie.
We were told writing apps completely using frontend-y JavaScript would make our lives easier.
That also was a lie.
I agree with pretty much every word of this article.
If you’re top priority is paid employment, right now, React is a great choice for that.
True. But…
If your priority is long-term resilience and maintainability, vanilla JS (probably with a light build process on top of it) is the ideal choice.
It will never become obsolete, or suffer from a breaking version change. It’s fast and performant, results in less code sent over the wire, and generally has a smaller footprint of things to break.
So much ink spilled supposedly explaining what “the web platform” is …when the truth is you can just swap in the “the web” every time that phrase is used here or anywhere else.
Anyway, the gist of this piece is: the web is good, actually.