Way back in 2011, jQuery mobile introduced the web to page-change animations. Clicking on a link would make your high-tech Nokia display a cool page-flip as you navigated from one page of a website to another. Just like an app!!!!

A decade-and-a-half later, and CSS has caught up (mostly). No more JavaScript, just spec-compliant CSS. Well, as long as you're using Chrome or Safari. Here's a quick quick MVP which will add some fancy animations as people browse your website.

Every page which wants animations has to "opt in". That means you need this:

@view-transition {
    navigation: auto;
}

Next, you'll probably want to define some animations. Here are two I use:

@keyframes slide-in {
    from {
        translate: 100vw 0;
    }
}

@keyframes fade-out {
    to {
        opacity: 0;
    }
}

Any standard CSS animation will work. Get creative!

Which elements do you want to animate? I'm just going to do the whole page.

html {
    view-transition-name: page;
}

If you have a fancy app-like site, you might only want to animate specific parts of it.

While the page is transitioning, you can have something in the background to prevent things looking odd.

::view-transition {
    background: black;
}

That's optional, but rather useful.

Next, we have to assign the animations to specific events. Here, I have the old page fade out and the new page slide in.

::view-transition-old(page) {
    animation-name: fade-out;
    animation-duration: 1s;
}

::view-transition-new(page) {
    animation-name: slide-in;
    animation-duration: 1s;
}

You can set the duration to whatever makes sense for your page and animation style.

Finally, and this is important, some people find animations painful or discombobulating. Make sure the animations are turned off for those who don't like them.

@media (prefers-reduced-motion: reduce) {
    ::view-transition-group(page) {
        animation-duration: 0s;
    }
}

And that's it! A couple of dozen lines of CSS and you've got started with view transitions.

For more information, you can see the Chrome Devs' demo page, or take a read of the MDN documentation. There's also a full spec document if you like that sort of thing.

Right, I'm off to create some delightful animations!

If you're on a desktop, you might notice that hovering your mouse over it displays the destination somewhere on your screen. If you're a geek, you could view the source-code of a page.

Can we improve the experience for users? Here's an attempt.

Try hovering your cursor over this link to a popular website.

This is what it should look like:

Here's how it works.

Cursor Styles

CSS allows us to change the icon displayed by a cursor. There are dozens of built-in icons, but you can also supply your own image file.

#link {
   cursor: url("/path/to/image.png"), auto;
}

Anything hovering over that link will get that .png as its cursor. Nifty!

Favicons

Most websites have a Favicon - it is a little image that you see in your browser bar, or when you save a website to your favourites. It is usually found at /favicon.ico - but can be in a variety of places.

There are dozens of free and paid services which let you quickly grab a favicon from any site.

The one I tend to use is DuckDuckGo's service. It takes any domain name, like Google.com, and returns an icon. It looks like this https://icons.duckduckgo.com/ip9/google.com.ico

Putting it all together

You can put the CSS anywhere - including inline with your links:

<a
  href="https://google.com/"
  style='cursor:url("https://icons.duckduckgo.com/ip9/google.com.ico"), auto;'
>Visit this website</a>!

Is this a good idea?

Well… maybe? If you have lots of links to various destinations and don't want to clutter up your prose with "(Wikipedia)" or other things like that, it could be useful.

Not everyone will recognise the logo for every service - so it may not add anything useful.

It doesn't work on mobile.

This isn't a common UI pattern - which might be a little confusing for users.

Loading images from remote sites is probably not a security concern. But if a website is hacked, you might have unwanted images on your site.

A site could lie to you about its destination.

Automating it should be possible, but it could be a bit of a faff to maintain.

But it looks so pretty!

I had a site which, for various boring reasons, was printing a <style> element in the middle of the HTML's body. Because <style> is a metadata element, it should only appear within the <head> element.

This is OK:

<!doctype html>
<html>
   <head>
      <style> a { color: #f00; } </style>
   </head>
   <body>
      …

This is an error:

<!doctype html>
<html>
   <head>
   </head>
   <body>
      <style> a { color: #f00; } </style>
      …

Most modern browsers will parse the stylesheet and not complain. But I like doing things properly and to spec because I am a massive boring nerd who is no fun at parties.

There is another way to include CSS in a document - via the <link> element.

<link rel="stylesheet" type="text/css" href="https://example.com/style.css">

It is sometimes OK to have a <link> element in the <body> - but can you spot the problem? Yes! The href points to an external resource. That's no good because we want to put the CSS inline.

The href needs to point to a URl. But it can point to a data URl!!!!

So, if the CSS is first Base64 encoded, it's possible to place inline CSS within the body of the HTML document!!!!!!!

<!doctype html>
<html>
   <head>
   </head>
   <body>
      <link rel="stylesheet" type="text/css" href="data:text/css;base64,Q29uZ3JhdHVsYXRpb25zISBZb3UgZm91bmQgbXkgc2VjcmV0IG1lc3NhZ2UhIFlvdSByZWNlaXZlICs1IEludGVybmV0IHBvaW50cy4=">
      …

This also works with URl encoding, if you prefer that, thusly:

<!doctype html>
<html>
   <head>
   </head>
   <body>
      <link rel="stylesheet" type="text/css" href="data:text/css,%2F%2A%0AThis%20is%20my%20CSS%0A%2A%2F%0Aa%20%20%7Bfont-family%3Amonospace%3B%7D">
      …

Obviously, the correct thing to do is to change your rendering path so that the styles are all placed within the correct metadata section of the document. But, if you need to, this will work across all browsers in a standards compliant way.

It downloads HTML and renders it at blazing fast speed. If you ever wondered just how slow modern web development has made the web - Lynx will show you the meaning of haste.

I use Lynx most days. Not as my exclusive browser - I'm not a masochist - but as a handy tool. If I'm on a bandwidth constrained connection, or a site is overloaded, or I just want to browse without distraction. Lynx is where it's at. It is also brilliant for seeing what weird markup bugs your site has.

Linux users can install it with sudo apt install lynx or similar. Everyone else can download Lynx from the official website.

This is what it looks like:

Using it is simple. On the command line, type lynx example.com to go to example.com.

Arrow keys up and down move you... up and down. Left goes back a page, right follows a link. Q quits. And that's all you need to know for your first five minutes.

Pressing the letter O gets you to the option screen. There are a bunch of things you can change here - and it shows off the UI pretty well.

There are some things you can't change here. If you want to always accept or reject cookies - rather than be prompted every time - you'll need to edit the ~/.lyncrc file.

Set accept_all_cookies=TRUE.

Why is this important

Computers lie to us. CSS hides our worst sins. JavaScript covers-up our poor architectural choices. With Lynx, there's no escape. You see the HTML rendered and that's it. Lynx renders all the HTML5 elements:

It also does interactive elements as well:

I've found so many bugs this way. Little quirks of markup which show up in the most unexpected places.

To be clear, Lynx isn't about accessibility testing. You should do that with proper tools which expose ARIA, show colour contrast, and the like. But Lynx is a good first pass at seeing how the text renders and flows, whether images have alt text, and if the general structure is easy to navigate.

Take some time to use it on your favourite sites today.

Using the API

You can't.

The Twitter search API only goes back 7 days. This whole idea would be much easier if I had access to the Premium API.

But! The Twitter website has no such restrictions.

Advanced Search

Twitter's Advanced Search allows you to pick specific dates to search for. Here's the string which shows my username's Tweets on Christmas day 2015: search?q=from:edent (until:2015-12-26 since:2015-12-25)

So how do we embed Twitter's site on our page?

iFrames!

Nope!

Twitter's X-Frame-Options Policy doesn't allow embedding. Oh well. Guess we have to give up.

HA!

Busting makes me feel good

Using the X-Frame Bypass Web Component is a real-life cheat-code.

X-Frame-Bypass is a Web Component, specifically a Customized Built-in Element, which extends an IFrame to bypass the X-Frame-Options: deny/sameorigin response header. Normally such headers prevent embedding a web page in an <iframe> element, but X-Frame-Bypass is using a CORS proxy to allow this.

It's dead simple to use. Stick this in your <head>

<script type="module" src="https://unpkg.com/x-frame-bypass"></script>

Done.

Stick it all together.

I wrote some horrible code to shove a dozen iFrames on a page. Ta-da!

The frames each point to the mobile version of the Twitter site - that provides a single column layout. The X-Frame Bypass doesn't send a User Agent Header - which is lucky because it forces Twitter to serve up a legacy version of the site.

It only loads 20 Tweets per day - so you'll need to click through if you were particularly loquacious that day.

I can't be bothered to release this as a proper site. But if you want to - go ahead!

Progressive mode is useful because it can quickly load a low resolution preview of an image, and then gradually improve its quality.

WebP, by contrast, just loads up the full image line by line. That's can be annoying on a slow connection.

What if we could change that? Here's a quick-and-dirty hack. This is a 5472x3080 image which has been compressed down to "zero" quality on WebP and resized to 640x360. It is less than 5KB.

The original image is 400 KB as a WebP and 1.6MB as a JPG.

There are lots of techniques to load low-res images before the main image loads.

We're going old-skool. Basic HTML + CSS.

<img
    width=5472
    height=3080
    alt="Close up of a Raspberry Pi circuit board."
    style="background-image: url('Small.webp');"
    src=Big.webp
>

This sets the background of the image to the low-resolution, low quality version. As the high-resolution image loads, it gradually replaces the image in the background.

There are a few more refinements we could make to this:

<img
    width=5472
    height=3080
    alt="Close up of a Raspberry Pi circuit board."
    style="background-color: #0f0;
           background-image: url('Small.webp');"
    loading="lazy"
    src=Big.webp
/>

This sets the background-color to the dominant colour of the image. That way, even before the background image has loaded, you get something to fill the gap. Because we've set loading="lazy" the massive image won't be downloaded until the img scrolls into view.

We can even go a step further. Let's reduce the image down to a thumbnail of 160x90. That takes us down to a ludicrously small 564 Bytes.

Which makes it small enough to stick directly in the HTML once we encode it in Base64:

background-image: url("data:image/webp;base64,UklGRiwCAABXRUJQVlA4ICACAACQEwCdASqgAFoAP/3+/3+/vLYyPv+8A/A/iWYIkCfrS2sOTiSUArLU15JWpmwHGTJDQ+i/y0UfRMWET8I422NGGsABPAdIKWnTFvlfPnla/wC0DPVYABJxuECkmqWUZwViSm1vqzvPgAnG+vioXrwz0V3Zx+c/znFFJvKBpH5SceJwmAUi8+8SRjzQvyc/qv3DKe3KfEYnXA+5aEBypmacRUvrvgAA+OUzEDYgEioYgJQRm/l9OIIl60M80PJW00cW6fX1fNpB/L4udWsUF5v6gOR6fB//5/0zuirXi2Z2GoqpVh3aeUDEdVThFtQOZStD/ulvCFO54uEqPVZlD63ukgBgt5Q5KA15Nse9lu4E+4XliSgao9azVod9zUr/XELtUpd2CLSyImxIXq3rRNGthLv0jePmYvlqijrhFxgMsdVer/GmM0C6xEyTC53yBQ+aGJlg/iqxrU5uwNjGNi3Or75QpJVdWW0lEyZlOsIiRsCZ+jTXsDMmgzkB4uaiiQASLl4TIYpK587PmaLb29WRF3hxpAtjR4TPDHne3iY6aBfYZhvMo1N41AMMKe7BLZg3w8LCQ2RHRHnkhgYsdtLL2jSFFpP8JgVtwLZ/KtKa6P7VaHm7aY7aT0UWyEwXPnUbZwo5a4yuK1H+P7YJqLj8yjuKSJZACY6z+6RgRxeoSyytYvQiopOOlc4f1Mdoy2WgfE3HR6Ap5jJiPryYLQAA")

Of course, you don't have to go down to quite this extreme level - choose some settings which make sense for you and your media.

To summarise:

1. Scale the image down
2. Reduce its quality
3. Set it as the background to the img element

Endnote

I wasn't involved with the development of WebP - but it seems bizarre to me that it doesn't contain a "thumbnail mode". On that ½ MB photo, adding a couple of KB doesn't seem like a huge overhead.

Similarly, the experimental AVIF also lacks progressive / thumbnail support.

Anyone know what the reason is?

I use the WordPress Broken Link Checker plugin. It periodically monitors the links on my site and lets me know which ones are dead. It also offers to link to Wayback Machine snapshots of the page.

It doesn't always work, of course. Sometimes the page will have been taken over by spammers, and the snapshot reflects that.

This isn't some SEO gambit. I believe that the web works best when users can seamlessly surf between sites. Forcing them to search for information is user-hostile.

What I'm trying to achieve

When a visitor clicks on a link, they should get (in order of preference):

1. The original page
2. An archive.org view of the page
   1. Ideally the most recent snapshot
   2. If the recent snapshot doesn't contain the correct content, a snapshot of the page around the time the link was made
   3. A snapshot of the site's homepage around the time the link was made
3. A replacement page. For example, Topsy used to show who had Tweeted about your page. Apple killed Topsy - so now I point to Twitter's search results for a URl.
4. If there is no archive, and no replacement, and the link contains useful semantic information - leave it broken.
5. Remove the link.

Some links are from people leaving comments, and setting their comments. Is it useful for future web historians to know that Blogger Profile 1234 commented on my blog and your blog?

Some links are only temporarily dead (for tax reasons?) - so I tend to leave them broken.

The Internet Archive say that "If you see something, save something". So, going forward, I'll submit every link out from my blog to the Archive. I'm hoping to find a plugin to automate that - any ideas?

I'm tentatively calling this "International No Javascript UseR Experience Day" or INJURED for short.

A few weeks ago, a reader of my blog complained that all they saw was a blank screen. As Liz Conlan pointed out, my CSS was making the whole page invisible. My WordPress theme has a feature which renders the page blank until all the extra fonts etc have properly loaded - then it makes the page visible. That's a neat little hack to stop the page jumping around as it loads - but it fails utterly when the user doesn't have JavaScript.

Why Do This?

Firstly, let's ask how many people browse the web without JS.

According to this recent post by the UK Government's web team, approximately 1.1% of their visitors don't or can't use JavaScript.

That's a small fraction of visitors - but not an insignificant number of people to piss off if you run a major website.

Secondly, why don't people use JavaScript? There are a variety of reasons, most of which seem to fall into the following categories:

• Security. Why run untrusted code on your computer if not strictly necessary?
• Speed. On slower machines, or those with limited bandwidth, JavaScript can cause a page to render slowly.
• Privacy. JavaScript is often used to track users.
• Accessibility. Not all users have perfect vision or dexterity - JavaScript can be an annoyance, assuming their accessible browser supports it at all.
• Incompatible browser. As well as specialised browsers, many people still run outdated versions of popular web browsers.
• Network interference. Some ISPs and corporate networks will automatically degrade or disable JavaScript.

So, we have a bunch of customers / users who either can't or won't use JavaScript. Should we ignore them?

How The Other Half Live

I think it's important to see how our technology works when presented in less-than-ideal circumstances. If an astronaut on the ISS wants to load your website on their IE6 box running over slow link with huge ping times, what's their experience going to be?

I quite often use Lynx to browse the web. It's a text only browser with very few bells and whistles. Here's how it looks when trying to use Twitter. I use Lynx for 4 main reasons:

1. How does my layout work for those who use Text-To-Speech to browse the web? It's not perfect, but I can see how easy it is to navigate, whether I've used alt/title tags for images correctly.
2. When on a painfully slow connection. We've all be stuck somewhere with Internet speeds barely better than dial-up, right? With Lynx I'm not loading MBs of JS, CSS, images, Flash objects, HTML5 video. Just the information I want.
3. What does a search engine see? When a spider comes crawling, how much semantic meaning do they derive from my markup?
4. Does basic functionality work for the lowest common denominator.

It's amazing how quick the web when you're ignoring everything other than the HTML! Moreso, it's incredible how even some simple sites won't work without JavaScript.

I'm not proposing that we go back to a text-only existence, nor that we all disable JavaScript permanently. Merely that - once in a while - we experience the web without our favourite toy. Do our sites break catastrophically? Is there a more accessible way we can provide a feature?

I'm not proposing to make a website, logo, or define a specific day. I'd just like you to turn off JavaScript for a day and see if anything odd happens.