I've only tried it on a personal project. I do those because I have a fun idea and/or want to try a new language/framework and/or want to remind myself how to use an old one. The first thing it did was to guess correctly what I wanted to do with some data. Which was exciting, but also it wasn't something I do often in that language, so I sort of wanted to remember for myself how to do it. But if it was something I did a lot then I can see how it would be really good to save myself a lot of typing.

The next thing it did was also helpful, except that it had an error on it. It was exactly the sort of error I'd also make, but I'd expected it to know better. Which I know is silly because it's just getting data from people who are also making the same mistake.

After that its guesses about what I was trying to do were completely wrong and it was just annoying. But I've just been working on JavaScript at the moment. It'll be interesting to see how it does when I come to the CSS.

In summary, I can see how it would be really useful at work, when it has all the context for what you're working on and the languages used. And it's all things you do every day and have a deadline on. But on personal projects the one line autocomplete is probably all I need - after all, I don't have a deadline on personal projects, I'm just enjoying working on them.

Theoretically that's easy to fix - flexbox will sort that right out. However, that then meant that the focus order was wrong.

But that's still an easy fix - you just duplicate one of the elements in the HTML and hide one on mobile and the other on desktop. Except that this is in a CMS and the HTML was being built by it and didn't exist as HTML to change. And there were a load of scripts doing things inside these elements, some of which could well depend on a unique ID or a class only being used once. It was an important page on the site, so if I broke it, things would go very wrong, so I didn't want to touch it.

There will one day be some CSS to tackle this: reading-flow. But at the moment it's only available in Chromium browsers and is also marked as experimental, therefore subject to change and shouldn't be used in production code.

Fortunately, there's a really simple JavaScript solution. What I did at desktop size was to move element B to be before element A. When you look at the resulting HTML it looks like it's always been that way round. And the focus goes through the element on the left, followed by the element on the right.

The solution is before. Or after. Since I only have two elements they effectively do the same thing.

To move element B before element A you use:

a.before(b)

or you can use

b.after(a)

Which is a bit confusing because if you read that from left to right it sounds like you're saying a is before b, or b is after a. But when you try it it's easy to tell you've done it wrong.

The HTML

<div>
  <p>Some text here</p>
  <span></span>
</div>

<button>Toggle active state</button

Some JS to add the transition

const button = document.querySelector('button');
const div = document.querySelector('div');

button.addEventListener('click', function() {
  div.classList.toggle('is-active');
})

The CSS

body {
  display: flex;
  align-items: flex-start;
  gap: 20px;
}

div p {
  margin-bottom: 4px;
}

div span {
  width: 100%;
  height: 4px;
  background: red;
  display: none;
  opacity: 0;
  transition: opacity 1s, display 1s allow-discrete;
}

div.is-active span {
  display: block;
  opacity: 1;

  @starting-style {
    opacity: 0;
  }
}

button {
  padding: 0.5rem 1rem;
}

The transition

A lot of that CSS is the set up, the transition bits we’re interested in are these bits:

div span {
  display: none;
  opacity: 0;
  transition: opacity 1s, display 1s allow-discrete;
}

div.is-active span {
  display: block;
  opacity: 1;

  @starting-style {
    opacity: 0;
  }
}

Most of this is pretty standard. The span starts off with an opacity of 0 and display: none. The transition transitions opacity in 1s. And also display - which works because of the allow-discrete keyword.

And then when the is-active class is applied to the parent div we change it to be an opacity of 1 and display: block.

The thing that actually makes this all work is this bit:

@starting-style {
  opacity: 0;
}

This tells it that it’s starting from an opacity of 0. You’d think it would know that because I told it it had an opacity of 0 when the is-active class is applied. But it needs to know within the is-active class too, so it knows how to transition the opacity in. If you remove this it will transition out, but not in. It’s as if now the is-active class is applied it can no longer see the styles set on the div and you have to let it know what they are.

Codepen decided not to run JS when I set this up, so here’s a JSFiddle link instead.

The HTML

<ul>
  <li><a href="#">One</a></li>
  <li><a href="#">Two</a></li>
  <li><a href="#">Three</a></li>
  <li><a href="#">Four</a></li>
  <li><a href="#">Five</a></li>
  <li><a href="#">Six</a></li>
</ul>

Styling the hover/focus

This is the simplest part - I am making the background of the links pink when they are hovered or focused.

li a:hover,
li a:focus {
  background-color: pink;
}

Styling the first element

Also, simple.

li:first-of-type a {
  background-color: pink;
}

Styling the siblings

If we just make the hover/focus pink and the first element pink when we aren’t hovering/focusing then the first element is pink which is what we want. But then it keeps being pink even when we’re hovering/focusing on something else. What we need to do is to unstyle the siblings when one is being hovered/focused.

li:has(~ li a:hover) a,
li:has(~ li a:focus) a {
  background-color: unset;
}

This is saying that if an li has a sibling with an a that is being hovered/focused, then style this a.

Downside

There is a downside to this. If you hover over an element, come off it so you’re not hovering on anything, then hover on another element shortly after, then the background jumps to the first one in between, which looks a bit odd.

Final code

Here is the whole code:

The scripting media query checks whether JavaScript is enabled. It has three keywords, although only two of them are useful.

@media (scripting: none) {
    // Javascript is disabled
}

@media (scripting: initial-only) {
    // Javascript is only enabled on page load
}

@media (scripting: enabled) {
    // Javascript is enabled
}

(I know CSS doesn’t use // for comments, but actual comments are grey, which I find a very hard colour to read on a black background).

Interestingly, Tailwind (which was what the project was using) only has the disabled version (with noscript:classHere), which was unhelpful for me. In my case I had a sticky header which shrinks down on scroll. The shrinking can only be done with JavaScript and without shrinking the header is massive. So if JavaScript is disabled we don’t want a sticky header. Which is easier to do in CSS than Tailwind:

@media (scripting: enabled) {
    header {
        position: sticky;
        top: 0;
    }
}

In Tailwind I’d have needed to do:

<header class="sticky top-0 noscript:static">
    Content here
</header>

Problem 1

I went a few rounds with it coming up with suggestion that sounded reasonable, but none of them helped. Although I found that telling it exactly what wasn’t working helped me to establish what the problem actually was.

Sadly, though, it then started giving me code where I couldn’t see what it had changed. When I asked, it told me it had added a function. But that function was already there… At that point it become clear that it wasn’t going to be of any more help and I gave up.

Problem 2

This started similarly, with it coming up with reasonable-sounding explanations and suggestions, none of which solved the problem. And then it started giving me links to CodePens it had created. All of which were empty. When I asked it apologised and gave me a new link. Which was also empty. It did also give me all the code that would be in the CodePen, so it didn’t matter too much.

But since we weren’t solving the problem I asked it where it had got its answers from. It initially refused to give me any links until I persisted. And then it gave me StackOverflow links to completely different problems in completely different languages…

When I called it on that it told me what to search for on StackOverflow (and how to search StackOverflow). They were reasonable search strings, even if they didn’t lead to to anything I hadn’t already come across.

Conclusion

If I was merely judging it on those two interactions then I’d say it was completely useless. Plus every time it gives an answer it started by telling me I was right which got grating after a while. But I already knew it did that sort of thing and can’t be turned off. I also hate that it shows you its answer one line at a time, but I’d already asked it about that and it also can’t be turned off.

So it’s annoying, but I’m not totally giving up on it. I have heard from people that it can be good for giving you starter code that you can improve on. And there may be less complex problems that it will be better at finding answers for.

I also only tried ChatGPT - it may be that some of the others are less annoying and/or more useful.

Same for all browsers

Most keyboard controls are the same in all browsers.

When select is closed:

Enter: does nothing
Space: opens select
Tab: goes to next tabbable element
Shift + tab: goes to previous tabbable element
Down arrow: opens select
Up arrow: opens select
Any letter key: selects first/next option that starts with that letter

When select is open:

Enter: selects focused option and closes select
Escape: closes select
Down arrow: focuses next option
Up arrow: focuses previous option
Home: focuses option at top of list
End: focuses option at bottom of list
Any letter key: selects first/next option that starts with that letter

Different in different browsers

I tested in Firefox, Chrome, Safari and Opera, all on a Mac. Although a Mac has different keyboard shortcuts to Windows and Linux, navigating a website doesn’t seem to be any different on a Mac.

When select is closed

Escape
Firefox: goes to next tabbable element
The rest: does nothing

Page down
Firefox: selects option one page down
The rest: does nothing

Page up
Firefox: selects option one page up
The rest: does nothing

Home
Firefox: selects option at top of list
The rest: does nothing

End
Firefox: selects option at bottom of list
The rest: does nothing

When select is open

Space
Firefox: does nothing
The rest: selects focused option and closes select

Tab
Firefox: selects focused option and closes select
The rest: selects random option

Shift + tab
Firefox: selects focused option and closes select
The rest: selects random option

Page down
Firefox: focuses option one page down
The rest: focuses option at bottom of list

Page up
Firefox: focuses option one page up
The rest: focuses option at top of list

I started at https://www.w3.org/WAI/ARIA/apg/patterns/switch/. This site is really useful for telling you how custom components should behave and what things you need to make sure to include. And it has examples.

I went with the checkbox example, since the one I had to create had an on and an off state. In my case, the design had labels on either side of the toggle and the on one would show when the toggle was on and the off one when the toggle was off.

HTML

My HTML ended up like this:

<label>
  <span class="sr-only">What this toggle is for</span>
  <span aria-hidden="true" class="off">Off</span>
  <input type="checkbox" role="switch" checked class="checkbox">
  <span class="toggle">
    <span class="toggle-button"></span>
  </span>
  <span aria-hidden="true" class="on">On</span>
</label>

All of the content is inside the label, so the whole thing is clickable. As with any input we need a label. The design doesn’t include one, so we need to include a span with the label and hide it from sighted users.

The checkbox is doing the actual work and the .toggle and .toggle-button make up the actual toggle. In the design I had the checkbox should be on by default, hence why the HTML includes the checked attribute.

Then there’s the on/off texts, which are hidden from screen readers. This is because the screen reader will announce whether the checkbox is on or off. The toggle is really only an interesting way to show a checkbox to sighted users.

CSS

For the layout, I used a grid to put the elements all next to each other and add some code to change the opacity of the on/off texts based on the checkbox’s state.

label {
  position: relative;
  display: inline-grid;
  grid-template-columns: repeat(3, auto);
  align-items: center;
  gap: .5rem;
}

.off {
  opacity: 1;
  transition: opacity 250ms ease;
}

.on {
  opacity: 0;
  transition: opacity 250ms ease;
}

.checkbox:checked ~ .on {
  opacity: 1;
}

.off:has( ~ .checkbox:checked) {
  opacity: 0;
}

:has is useful here as a previous sibling selector. Although if it didn’t exist, we could just put the off text after the checkbox in the HTML and re-order the elements. Usually that would be a terrible idea, but in this case, they’re only there for sighted users and aren’t selectable, so it’s not going to make much difference.

And then there’s the toggle itself. I remembered last year hearing a talk from Sara Soueidan about hiding the default checkbox when you’re styling your own. Handily she also has a blog post about it at https://www.sarasoueidan.com/blog/inclusively-hiding-and-styling-checkboxes-and-radio-buttons/.

The important part of this post is that on Android you can explore a page by touch and feel interactive elements. Which means we can’t hide the checkbox by making it tiny or moving it off the page.

What we are doing instead is making the checkbox and toggle the same size and putting the toggle on top of the checkbox (and also adding some styling to make it look pretty).

:root {
  --toggle-width: 52px;
  --toggle-height: 30px;
  --toggle-button-width: 26px;
}

.checkbox {
  position: absolute;
  width: var(--toggle-width);
  height: var(--toggle-height);
  opacity: 0;
  grid-column-start: 2;
}

.toggle {
  display: block;
  position: relative;
  width: var(--toggle-width);
  height: var(--toggle-height);
  border-radius: 30px;
  padding: 0.125rem;
  background-color: lightgrey;
  cursor: pointer;  
}

.toggle-button {
  display: block;
  position: relative;
  top: 2px;
  left: 2px;
  width: var(--toggle-button-width);
  aspect-ratio: 1;
  border-radius: 50%;
  background: white;
  transition: left 250ms ease;
}

.checkbox:focus-visible + .toggle {
  outline: 2px solid black;
  outline-offset: 2px;
}

Using custom properties makes sure that the checkbox and toggle are the same size. And because this is in a grid we can make sure that the absolutely positioned checkbox is in the same grid column as the checkbox.

Although the checkbox is turned on by default, the CSS defaults to the checkbox being turned off. All we have left is to move the toggle button over the right and change the toggle’s colour when the checkbox is checked:

.checkbox:checked + .toggle {
  background-color: red;
}

.checkbox:checked + .toggle > .toggle-button {
  left: calc(var(--toggle-button-width) - 2px);
}

Final result

And it ends up looking like a standard toggle:

I spent January looking for jobs. There was a surge in the number posted in comparison to December, and I had to do take-home tests, which took up time.

In March I started a new job and in June I got made redundant from it. It’s a familiar tale, but it’s reading other people’s stories about getting made redundant that make me realise just how lucky I got to be starting a new job a month later.

It was one of the few jobs I heard back from, and the only one who offered me an interview. Fortunately they offered me the job and it was one that I wanted.

What it’s meant that any public activity has felt like it’s all about getting a job and not about me getting to have fun. Which is annoying because there’s a side project I’d really like to do that would actually be useful to me. I’m hoping to do it in 2025!

In a year’s time I’d also like to still be employed with the same company, but I don’t have 100% control over that (and if someone offered me a 6 figure salary to play with bunnies/kittens/read books all day I wouldn’t say no).

If you have a button on the page then by default its type is button.

But if that button is inside a form then by default its type is submit.

It makes sense. A button outside of a form with a type of submit wouldn’t make sense: what would it submit? Same with reset. So it makes sense that the only thing the button can do is to be a button. But if you have a form the most likely thing that button will do is to submit the form (the second most likely is to reset the form).

So if your form contains a button that doesn’t submit or reset the form (as I had recently), it needs to be of type button.

The thing is, CSS isn’t easy. You can’t just bung something in and hope for the best. I’ve seen that this year in CMS plugins that you pay for that have terrible CSS.

There are a lot of floats going on, which feels outdated. Who uses floats for layouts these days? There also doesn’t feel like a lot of testing going on. It might look ok, but then fail when you resize the browser. They’ve written it assuming that the size of the browser on load is the size it will always be. But on a mobile or tablet you might turn it round. On a computer you might maximise your browser window - or make it smaller.

That’s the thing with working on the front end: users could do anything. It’s our job to anticipate that and test for it. Front end developers are useful after all!

The Windows computers had the first four versions of Netscape Navigator on them (the big browser at the time). I used them to see what websites worked in each of them. From what I remember, most things worked in the last three and hardly anything worked in the first one. Frames certainly didn’t and that was the big trend of the time.

At the time I had no idea it was the sort of thing you could get a job in. And now I get paid to do that sort of thing.

It still works - on the occasion that I ignore the breaks or don't turn it on I regret it. Although I only work 25 minutes in every 30 minutes, I get more done. And it's really useful if I'm doing a task that's boring or I don't like as I can tell myself I only have to do it for 25 minutes.

However, that 25 minutes is sometimes too short. And although 5 minutes is short enough that I can pick back up where I left off, it's not long enough to do anything much apart from wait for the end of the break. Although I've sometimes used them to do boring tasks around the house, like cleaning, where it then becomes 'how much can I do in 5 minutes', thus making the task more interesting.

I tried a 52/17 and found the 52 minutes of working was better, but the 17 minutes was then too long and I scratching about for things to do during that break.

So I looked around for alternatives and discovered the Flowtime technique. The basic idea (or at least what I took from it) is that you work until you come to a natural pause and then you take a break. The length of your break depends on how long you've been working since the last break and how long you need to feel refreshed.

The Pomodoro technique has many apps and websites, but because Flowtime is more wishy-washy, it doesn't have any. Instead I use a tracker designed for tracking how long you work, so I can see how long it's been since my last break. And towards the end of the day I can see how many time I've actually done, so I can work out when to finish.

And it's working out well. It helps that I work from home, so it's relatively easy to find something to do during the break. Or nothing if that's what I need to do to recharge. I don't end up ignoring my Pomodoro breaks because I just need to finish something I'm in the middle of that will take two minutes. And it feels natural to have a pause after I've finished a task and before I start the next one.

This is inspired by me walking into a room to find my parents and nephew trying to do an A to Z of cars.

A accessibility

What a lot of people forget, but I think is just as important as responsiveness.

B block

Perpendicular to the writing direction.

C calc

Doing calculations in CSS. Very handy.

D display

block, inline, inline-block, flex, inline-flex, grid, inline-grid, none, etc

E :empty

A useful pseudo-class for styling elements with no children. As long as they don't have any white space within them.

F flexbox

When I first started CSS I learnt by looking at the Inspector and playing with things. And then I copied someone who did their layouts with floats. And it was so hard to position things. Learning about flexbox made all the difference.

G grid

What still feels to me like flexbox's more complicated and more powerful sibling.

H height

How much space something takes up horizontally.

I inline

The writing direction. Really useful for centering, where you can use margin-inline: auto.

J justify

In Flexbox Zombies, you use your justify laser to target zombies in the direction you're firing.

K @keyframes

Animation steps.

L line-height

Can make text look totally unreadable if it's too big or too small.

M margin

Space around an element that doesn't make the element bigger.

N none

Useful to stop displaying something or removing borders.

O object-fit

Although it seems like this has been around forever, I came across something a while back that was relatively. It included some JavaScript someone had written to cope with object-fit being new and not working in all browsers yet.

P padding

Spacing around the element that makes the element bigger. Negative padding is not a thing like negative margin is.

Q queries

Media queries and container queries, used for responsive design and accessibility.

R responsiveness

Important for making sure your site fits on all screens. Seems pretty basic, but there are plenty of sites which don't fit properly at some sizes.

S specificity

This becomes a pain when trying to override styles from a third party. Although recently I have seen some CMS plugins using :where, which helps a lot.

T text

Sometimes used for font styling. And sometimes you use font. Except if you want to change the colour of the text, in which case it's neither.

U units

The most used of these are %, px, em and rem. Also fr in grids and s and ms in transitions and animations.

V visibility

Interesting, the opposite of visible is hidden. Which is not what you'd logically think it would be.

W width

How much space something takes up horizontally.

X overflow-x

A bit of a cheat for x, but there's nothing beginning with x. This controls the horizontal overflow. x is also used with Tailwind where eg mx is the horizontal margin.

Y overflow-y

As with x, this controls the vertical overflow. And y is generally to denote vertical in Tailwind.

Z z-index

The highest/lowest z-index you can use is (-)2,147,483,647. Or infinity will give you the same thing. But typing a load of 9s and then wondering why it isn't working is a much simpler method.

aria-live to the rescue!

I hadn't used aria-live, but I knew it was used to read out something on the page that had been added. Its default state is off, then there's polite and assertive. polite means it'll finish whatever it's reading, then read out the next section. assertive will stop whatever it's doing and read it straightaway.

In my project, once you click the button it takes some time to fade the current section out and fade in the new one in. And the button doesn't take that long to read out, so in this project, polite and assertive effectively do the same thing. Although I used polite since that makes the most sense.

And then I found the trouble. It read the text, skipped the image and read the text on the button. Not necessarily in that order, even though that's the order they are on the page.

The thing with aria-live is that this isn't usually used to read out the whole contents of a page. It read it out in the order it received it, which depends on the browser and the computer and what else you might be doing.

It also is a problem that it doesn't tell you a button is a button.

So it turned out that aria-live was not the solution I thought it was.

JS to the rescue

But what you can do is add focus to the new section. That's easy to do in JS with section.focus(). Then it just starts reading from where the focus is. You can put the focus on anything, it doesn't need to be something focusable with the keyboard.

The downside to this approach is if you've used the keyboard to click the button, the new section will have the browser's default outline. Since it's no use on this occasion, it's fine to just remove the outline from the section (but not from everything!).

Initial set up

<div class="spotlight"></div>

html,
body {
  height: 100%;
  margin: 0;
}

body {
  position: relative;
  width: 100%;
  height: 100%;
  background-color: black;
}

This gives us a black background that fills the screen. The .spotlight div will be a circle that reveals the background.

The spotlight

.spotlight {
  position: absolute;
  inset: 0;
  background-image: linear-gradient(to bottom right, 
    red, orange, yellow, green, blue, indigo, violet,
    red, orange, yellow, green, blue, indigo, violet);
  clip-path: circle(5% at 50% 50%);
}

I've positioned the spotlight absolutely so we can move it with the mouse. It fills the screen and I've added a rainbow background gradient, since it's June and Pride month. It's not one where every colour perfectly blends into another, and there's some pink between the violet and red. But since we'll only get to see a little of it at a time, it doesn't matter.

The clip-path creates a small circle in the middle of the screen. Anything outside of it is hidden, so we only see the background inside that small circle.

Moving the spotlight

To move the spotlight, all we need to do is to update the clip-path circle position. The easiest way to do that is to use custom properties:

.spotlight {
  --left-circle: 50%;
  --top-circle: 50%;
  position: absolute;
  inset: 0;
  background-image: linear-gradient(to bottom right, 
    red, orange, yellow, green, blue, indigo, violet,
    red, orange, yellow, green, blue, indigo, violet);
  clip-path: circle(5% at var(--left-circle) var(--top-circle));
}

Then we can use the mousemove event listener to detect where the mouse is:

const spotlight = document.querySelector('.spotlight');

spotlight.addEventListener('mousemove', e => {
  spotlight.style.setProperty('--left-circle', e.clientX + 'px');
  spotlight.style.setProperty('--top-circle', e.clientY + 'px');
});

clientX and clientY will get us the horizontal and vertical mouse position, where (0, 0) is the top left. This means that if you move the mouse to the very top left of the screen the clip-path becomes clip-path: circle(5% at 0 0);

All you have to do is to move your mouse around you can see different parts of the background in the circle.

Adding some blur

The edge of the circle being less sharp would make it look better. A little more like a spotlight, which has a lot of light in the centre and less at the edges. However, adding blur to the edge is a little complicated when you have a clip-path.

If you didn't have a clip-path, then a box-shadow would do it. However, our .spotlight fills the screen, so we won't be able to see a shadow. A drop-shadow doesn't help because it has the same problem.

The solution is to add a drop-shadow to the element, but then have another inside it with the clip-path and background:

.spotlight {
  --left-circle: 50%;
  --top-circle: 50%;
  position: absolute;
  inset: 0;
  filter: drop-shadow(0 0 20px rgba(255, 255, 255, .75));

  &::before {
    content: '';
    position: absolute;
    inset: 0;
    background-image: linear-gradient(to bottom right, red, orange, yellow, green, blue, indigo, violet, red, orange, yellow, green, blue, indigo, violet);
    clip-path: circle(5% at var(--left-circle) var(--top-circle));
  }
}

And there you have a white blur around the circle.

Final code

Here is the final code:

Converting font-size

Here we want to use rems. This function is from https://dev.to/rekomat/comment/1ib3b:

// From https://dev.to/rekomat/comment/1ib3b
@function pxToRem($pxValue) {
  @return math.div($pxValue, 16px) * 1rem;
}

This is literally doing the same calculation as we do on the calculator: font-size divided by 16px and then written in rems. If your base font size has been set to 10px (for example) then you'd need to change the 16px in the function to be 10px.

You can use this function to convert anything from px to rem, not just font-sizes.

Converting line-height

Here we do exactly the same as on the calculator to get a ratio:

@function convertLineHeight($fontSize, $lineHeight) {
  @return math.div($lineHeight, $fontSize);
}

Converting letter-spacing

And again it's the same calculator calculation and expressed in ems:

@function convertLetterSpacing($fontSize, $letterSpacing) {
  @return math.div($letterSpacing, $fontSize) * 1em;
}

Using the functions

To use those three functions we'd do this:

p {
  font-size: pxToRem(24px);
  line-height: convertLineHeight(24px, 30px);
  letter-spacing: convertLetterSpacing(24px, -0.48px);
}

Which is fine, but we have to give all three of them the font-size. We can use a mixin to make this more efficient:

@mixin textUtils($fontSize, $lineHeight: 1, $letterSpacing: 0) {
  font-size: pxToRem($fontSize);
  @if $lineHeight != 1 {
    line-height: convertLineHeight($fontSize, $lineHeight);
  }
  @if $letterSpacing != 0 {
    letter-spacing: convertLetterSpacing($fontSize, $letterSpacing);
  }
}

p {
  @include textUtils(24px, 30px, -0.48px);
  //@include textUtils(24px, 30px);
  //@include textUtils(24px);
}

This mixin is set up so it needs the font-size, but it doesn't matter if you don't give it the letter-spacing, because that could be 0. And just in case, it also works if you don't give it the line-height.

Last week's Doctor Who Dot and Bubble was a case in point. The main character spends her time in a literal social media bubble. It goes around her head so she can't see the real world. In the background are rectangles with various people in. In the foreground are rectangles of whoever she's talking to.

That all sounds fine right? Now what if I tell you the background images constantly move around the bubble. From the perspective of the person looking at them, the background moves from one side of your vision to the other. Constantly. At a constant speed.

If you have a vestibular problem that is probably the worst Doctor Who episode to attempt to watch. Every time we saw that background moving I was distracted thinking about people who had to give up on the episode because it made them too ill.

And if that existed in real life, surely the constantly moving background would make you feel travel sick? The minute you turn it off you wouldn't be able to walk in a straight line. And if you tried standing up you'd end up leaning to one side.

There are warnings on TV before episodes, like for flashing images for example. But no one warns for a lot of motion. They should, though. Accessibility should apply to TV. I'd like to be able to turn off motion on my TV and watch the version where the background rectangles stay where they are. Then I could concentrate on the episode itself. And maybe I'd have enjoyed it more.

It sounds complicated, the code is a bit complicated, but it's not once you understand how it's doing it.

The setup

All you need is an element that you're drawing the border around, and a way to start the border drawing. I've drawn the border around an image and a paragraph in the past, but for this demo I'm doing it around a div. I've added a background colour to the div and some padding on it so the border isn't touching it. I've added the border when you scroll to it in the past, but for this demo it adds the border when you click the button.

<button>Add border</button>
<div></div>

:root {
  --border-colour: black;  
  --border-thickness: 5px;
  --padding: 8px;
  --border-transition-time: 0ms;
}

@media screen and (prefers-reduced-motion: no-preference) { 
  :root {
    --border-transition-time: 250ms;
  }
}

div {
  position: relative;
  width: 200px;
  height: 100px;
  top: 50px;
  left: 50px;
  background-color: pink;
  padding: var(--padding);
}

Here I've added some custom properties because we're going to be using those values multiple times. And I've just moved the div away from the edge a bit so it's easier to see. The only line of the div code you need on your element is the position: relative, everything is is just for this demo.

I've also added a reduce motion media query. This way, if anyone has reduced motion turned on they won't see the border animating. Instead the whole thing will just appear.

const button = document.querySelector('button');
const div = document.querySelector('div');

button.addEventListener('click', function() {
  div.classList.add('border');
});

Then there's a bit of JavaScript to add a class to the border when the button is clicked. We'll use that class to show the border.

The border set up

To do this we're going to use pseudo-elements. One will be the top and right border, the other will be the bottom and left border. Our animation is going to go from the top left, across, down, across and back up to the top left.

div::before,
div::after {
  content: '';
  position: absolute;
  width: 0;
  height: 0;
  z-index: -1;
}

div::before {
  top: calc(var(--padding) * -1 - var(--border-thickness));
  left: calc(var(--padding) * -1);
  border-top: 0px solid var(--border-colour);
  border-right: 0px solid var(--border-colour);
}

div::after {
  right: calc(var(--padding) * -1);
  bottom: calc(var(--padding) * -1 - var(--border-thickness));
  border-bottom: 0px solid var(--border-colour);
  border-left: 0px solid var(--border-colour);
}

There's a lot going on here, so let's go through it.

Both sets of borders start off with no width or height, so we can't see them. And a z-index of -1 so if you have text or anything you can interact with in there, the pseudo-elements won't be on top of it.

Both pseudo-elements contain a border - because otherwise they've cover the whole of the div. For now, those borders are 0px in width, as otherwise you'd see squares in the top left and bottom right corners: even though they have no width and height, the border is still visible.

There's also some positioning going on. Since I have padding around the div, I want the borders to be at the edge of that padding, so I have moved them accordingly. Otherwise the elements will ignore the padding and sit at the edge of the background.

Adding the border

When the class of border is added, all we have to do is to set the size and border-width of both pseudo-elements:

div.border::before,
div.border::after {
  width: calc(100% + var(--padding) * 2);
  height: calc(100% + var(--padding) * 2 + var(--border-thickness));
  border-width: var(--border-thickness);
}

Of course this just adds the border instantly. We also need to transition them so we can see them animate:

div::before {
  /* ... */
  transition:
    width var(--border-transition-time) linear,
    height var(--border-transition-time) linear var(--border-transition-time);
}

div::after {
  /* ... */
  transition:
    width var(--border-transition-time) linear calc(var(--border-transition-time) * 2),
    height var(--border-transition-time) linear calc(var(--border-transition-time) * 3),
    border-width 0s linear calc(var(--border-transition-time) * 2);
}

These are a bit lengthy, so let's go through them.

First we want to see the border going across the top. So we transition the width of the before pseudo-element in --border-transition-time.

Then we want to see the border going down the right side. So we transition the height of the before pseudo-element in --border-transition-time. Except we don't want it to start until it's finished the top border. So we add a delay of --border-transition-time.

After that we want to see the border going along the bottom. Since we want that to wait until we've done the top and right, we need to delay for twice --border-transition-time.

Finally we want the border going up the left, so now we need to wait for three times --border-transition-time.

And we also need to delay the border-width changing from 0px to --border-thickness otherwise as soon as the top border starts animating we see a square of the after pseudo-elements border.

You can always change these times and delays to make the border animation less linear (as well as changing the transition timing function). You just need to be careful to keep track of what is happening when so nothing happens sooner or later than you want it to.

The finished code

Here is the final code: