Kau-Boys

How to make a navigation menu more accessible by adding a label

After writing a blog post in the 24 days before Christmas, I took the month of January off to get some new energy and collect some more and other topics to write about. Since I’m currently preparing for an accessibility certification, I want to have some blog posts around these topics. Today, you will get the first one. But I might blog about different topics in between.

Setting a menu label in a Block Theme

When you have a website with only one navigation using the <nav> tag, you are probably safe. Still, it can make sense to have a (good) label for your main navigation menu. But as soon as you have two menus, you must add labels.

Many screen readers have the option to jump to “landmarks” on your site, so a visitor can use this to easily find the navigation menu(s) on your page. But they will usually only here how many items are in each menu, not what the menu is about.

The default navigation menu in Twenty Twenty-Five

When you start a new WordPress project using the default theme Twenty Twenty-Five, your navigation menu will only have the “Sample Page” as an entry, and it would have an aria-label attribute, but it is empty (all other attribute values are replaced with ..., since their content is not important in this code snippet):

<nav class="..." aria-label="" data-wp-interactive="..." data-wp-context="...">

The navigation menu has a name, though. It is simply “Navigation”. When you navigate to “Appearance > Editor > Navigation”, you should see something like this:

Screenshot of the Site Editor with the "Navigation" view opened showing the one "Navigation" with one entry "Sample Page".

When you click on the three dots next to the title, you can easily “Rename” the existing navigation. Let’s rename it to “Main navigation”. If we now refresh the frontend, we see … no change. Even after changing the title, the aria-label is empty.

Solution: change the title by duplicating the menu

I don’t really know why the change of the title does not add any aria-label, but I found a workaround. Instead of using “Rename”, you can use “Duplicate”. This will add a “(Copy)” suffix to the duplicated menu. Now you only have to use this new navigation menu at the position you want to have it. For example, you navigate to “Appearance > Editor > Patterns > Header” then, select the header and click on the navigation block. In the Block settings, you click on the three dots right of “Menu” and then select the new menu you have duplicated and renamed:

Screenshot of the "Navigation" block sidebar settings with the selection of the available menus opened.

If we now save the header with this new menu, and refresh the frontend, we finally have our aria-label:

<nav class="..." aria-label="Main Navigation" ... >

In the dropdown in the screenshot above, you can also see the “Create new Menu” option. If you create a new navigation here, it would get a name like “Navigation 2”. This would automatically be used as the label. But you would have to back to the Site Editor to change the label. It would be nice, if that would also be possible here.

Adding a label to a Classic Theme

If you are still using a Classic Theme, you have to manage the label differently. Even though WordPress supports labels since version 5.5, many themes still don’t use them. Or at least not with the new parameter. This is how the label is added in Twenty Twenty:

<nav aria-label="<?php esc_attr_e( 'Footer', 'twentytwenty' ); ?>" ... >

If you want to change the label here, you would need to edit the file – in a Child Theme. Not really ideal, but still possible. If you develop themes yourself, make sure to use the container_aria_label parameter of the wp_nav_menu() function.

Conclusion

Adding a label to each navigation menu can make a huge difference for the accessibility of your website. When you use a Block Theme, you can do all of that without touching any code directly in the Site Editor. And since I’ve showed you, that the automatic navigation menu names are not really ideal, you might want to check the labels of your website and give them a better label.

Debug submission errors in Contact Form 7

Note: This blog post was first published in German only on 24 January 2016. I’ve only translated it on 29 December 2024, updated some things in text and also created new screenshots. The solution presented in this blog post still works with current versions of Contact Form 7.

This week I received a report of an error on a website related to the very popular contact form plugin Contact Form 7. In this post, I’d like to briefly explain what exactly the error was (so you don’t make it too) and how to better debug errors with the plugin.

Finding the error

Most of the time you only get a message from someone saying something like “I can’t submit forms”. So you first must find out for yourself what exactly is not working with the form. Troubleshooting was not exactly easy, as the plugin does not provide much information about what went wrong in the event of an error. All you get is this message:

Creating a dialog with native HTML

Here it is now, the last advent calendar blog post for 2024. Which also means, that many of you are celebrating Christmas today or tomorrow. So why do you read blog posts on such a day? 😁

The last topic for this edition will be about another HTML element you might not have known before. But you all know and hate cookie popups, right? Well, unless you are into the development of such tools. 😅

The dialog HTML element

When we “want” to create a popup, we would have used some kind of “modal library” in the past. But now, we have a native HTML element for this: the <dialog> element. It has some similarities with details element, I have blogged about four days ago. And if you visited the resources I’ve linked there, you might already have seen the element. This is how you would use it:

<dialog>
	Some Text inside the dialog.
</dialog>

If you put this code into your page, you would see … absolutely nothing. The element is not visible by default. You can add the open attribute to it, just as with the details element and then you would see this:

Chrome with open dev tools showing the properties of the open dialog element, that is centered on the page.

As you can see here, we get more than just a blank element with some text. The dialog has a border, some padding and is centered on the page, using an absolute position and auto margin. This would even mean, that it is displayed above any content that comes after it.

Opening and closing the dialog

A dialog that open by default is not really all that useful. Fortunately, we have some JavaScript functions to make it interactive. So let’s add a button that would open the dialog and a button inside of it, to close it:

Chrome showing an open dialog element. The dev tools are open and at the bottom of the HTML markup tree, a "#top-layer" is shown after the closing html tag. The dialog has a paragraph and an undordered list. The page behind the dialog has an "Open dialog" button and inside the dialog, there is a "Read it" button at the end.

This screenshot shown multiple things at once. First, we have the webpage with an “Open dialog” button. When clicked, it will open the dialog, which has some more HTML content this time. You may also notice, that the background of the website is gray. It is white, but when the dialog is open, there will be an overlay to the page. This can also be seen in the left with the ::backdrop pseudo-element. One last thing to recognize is the #top-layer after the HTML tree on the left. This is a special layer that covers the entire page and helps with accessibility.

When you close on the “Read it” button, the dialog will close. For the two buttons, we need some JavaScript to add this functionality:

const dialog = document.querySelector('dialog');
const openButton = document.querySelector('button#open-dialog');
const closeButton = document.querySelector('button#close-dialog');
openButton.addEventListener('click', () => {
	dialog.showModal();
});
closeButton.addEventListener('click', () => {
	dialog.close();
})

When you use the showModal() function, it does not really matter where the element is placed in the HTML tree. It will always open in the center of the page. If the content does not fit, a scrollbar will appear.

Alternative way to open the dialog

There is a second function to open a dialog. It is simply called show() and would open the dialog “in place” and not as a modal. In this case, it makes a difference where the dialog is placed. It will still show it with “position: absolute” over the content, but not vertically centered anymore. It will appear just where its HTML is placed in the DOM. There will also be no backdrop overlay and no #top-layer, so the behavior has some major differences.

Closing the modal without JavaScript

To open the dialog, you either need some JavaScript with one of the two functions to “show” it. Unless you add the open attribute to it, to have it open by default – I really wonder why the functions are not openModal() and open(), then the element is also using the open attribute.

To close the dialog, however, you might not need JavaScript. You can also have it closing itself, when you have a form inside of it:

<dialog open>
	<form method="dialog">
		Some text in the dialog.
		<button>OK</button>
	</form>
</dialog>

Do you see the special trick with the form? It’s using the value dialog for the method attribute. This will close the dialog, whenever the form is submitted with a button inside of it. So you could even just have an input and it will close on ENTER.

If the dialog was opened with showModal(), this modal can also be closed with the ESC key. So there are different ways to close it without any JavaScript.

Styling the element

The dialog itself can be styled like any other “container”. As shown earlier, it comes with some default border and padding. More interesting is probably the styling of the backdrop. Here is an example styling both:

dialog {
	border-radius: 5px;
	border: 3px solid red;
	top: 30px;

	&::backdrop {
		background: black;
		opacity: 0.7;
	}
}

We are changing the border of the dialog and also change the background of the backdrop. Ah, and by the way, what you see here is no Sass syntax. This is native nested CSS. If you haven’t seen this before, read the previous advent calendar blog post “Nested CSS without preprocessors“. Finally, this is how it would look like:

An open dialog with a changed "background" with lower transparency and a red border with a border-radius. The dev tools are open to show the HTML code and CSS of the dialog element.

Instead of the rgba() value for the background we now use a background-color in combination with an opcatity.

Getting even more out of the element

On the documentation page, you will fine many more examples on how to use forms inside the element, style it, interact with it, etc. But all of that would be too much for this blog post. The CSS-Trick blog post that covers the details element, also has some examples for the dialog element.

Conclusion

I hope I have saved the best topic for today. At least I found this element really fascinating and used it in one project. I might blog about this use-case. But that’s something for next year. This was my final advent calendar blog post and also the last one for this year, keeping my two weeks routine on blogging.

I hope you’ve learned some new things in the advent calendar blog posts, or in the others I have written this year. It was fun, but also a lot more work than I thought it would be. Have some great few days and see you all in 2025! 🎇

An easier dark mode

Four day ago, I wrote about “The prefers-color-scheme media query” and how to use it to create a dark mode for your browser. Today, I’m telling you: you might not even need it. Hm, but how do we get a dark mode then, you might ask? With a single CSS property instead of a media query.

The color-scheme property

All you need to use is one single property to tell the browser which color schemes you have. And this is how you can use it:

:root {
  color-scheme: light dark;
}

That’s it! You don’t need any more than that. Come back tomorrow for another blog post. 😁 Nah, there is more to it. But let’s see what this already does. I’ve created a page with some HTML and no CSS, other than the line above. This is how it looks like in my Chrome browser using a light mode:

Screenshot of some elements in light mode in Chrome: h1, p, fieldset, input, textarea, select and button.

And now we use the switch that I’ve shown you in the blog post “Simulate preferences in the browser” to switch to the dark mode. This is what you would get then:

Screenshot of some elements in dark mode in Chrome: h1, p, fieldset, input, textarea, select and button. The inputs and the buttons now have a background color.

While in the light mode, all elements had a white background, the form elements and the button now have a gray background. The placeholder text of the input however has a too low contrast now.

All of this we “got for free”. Just with a single line of CSS. But this design might not please you, so how can you change it, without using the media query? There are some special “functions” you can use.

The light-dark() function

Let’s take our source code from “The prefers-color-scheme media query” blog post to see how the color-scheme can be used to create a simple dark mode. This was our old code:

button {
	padding: 10px 20px;
	font-size: 2rem;
	background-color: #eee;
	border: 3px solid #333;
	border-radius: 10px;
	color: #333;
}
@media (prefers-color-scheme: dark) {
	button {
		background: #333;
		border-color: #333;
		color: #eee;
	}
}

Now, we take this code, and place every color into the new light-dark() function, that already has a good baseline support. We first set the light color and then the dark color. It is used like this:

button {
	padding: 10px 20px;
	font-size: 2rem;
	background-color: light-dark(#eee, #333);
	border: 3px solid light-dark(#333, #eee);
	border-radius: 10px;
	color: light-dark(#333, #eee);
}

Isn’t that a lot easier to read? When we view the page with a light color scheme preference, this is what we would see:

Chrome with open dev tools focused on a button. In the "Styles", the "light-dark()" function visualizes the two colors.

When you inspect the button, you can see the light-dark() function in the “Styles” and see/change the colors there. Now let’s view the same page with the dark color scheme preference:

Chrome with open dev tools focused on a button. In the "Styles", the "light-dark()" function visualizes the two colors. It simulates the dark mode.

That’s the basic usage of the color-scheme property and the light-dark() function. But the property can have different values.

Switching to a dark mode by default

If you want to use the dark mode as a default for your website and not use a light mode at all, just set the color-scheme like this:

:root {
	color-scheme: dark;
}

If you want to have a light mode by default, do the opposite, and use light as the only value. As soon as you have both values light and dark, the order is not important, you will have the behavior shown above.

Preventing the dark mode

As shown in the “Simulate preferences in the browser” blog post, Chrome has an option for an “Automatic dark mode”. This will use a dark mode, even if the color-scheme is set to light. But you can prevent a dark mode, by adding the only keyword as well:

:root {
	color-scheme: only light;
}

Now the browser will not use a dark mode. And sure enough, you can also use “only dark” to get the opposite.

Setting the property for some elements only

Some website designs have that use “different color schemes” for different element. Like a website that has a dark header, but a light footer. You might want to keep those colors, even if the modes can be switched. Then you can restrict the color-scheme for some elements, but allow both for other parts:

:root {
	color-scheme: light dark;
}
header {
	color-scheme: only dark;
}
.left {
	color-scheme: light;
}
.middle {
	color-scheme: light dark;
}
.right {
	color-scheme: dark;
}
footer {
	color-scheme: only light;
}

In this code snippet, we set both color schemes for the root element, but then change it for specific parts of the page. The header and footer are limited to just one color scheme. In the main section, we have three parts. The left and right only take one scheme, the one in the middle also takes two (we could leave property for the middle one out, as it would inherit the scheme from the root element, but for completeness, I left it here).

I’ve placed our button into each of these sections. Let’s see how this looks in Chrome with the different color scheme simulations:

With “prefers-color-scheme: light”

We can see here that our “color-scheme: dark” on the “.right” container has turned the button inside to the dark color-scheme.

With “prefers-color-scheme: dark”

Switching to dark color scheme, the button in the middle has changed, but the other ones stayed the same. We also have a black background of the main element now, but the background colors of the header and footer stayed the same.

With “Automatic dark mode”

Our header and footer still stay the same. But now also the left button has turned into a dark mode, since this part is not using the “only” keyword. The border color however is darker than in our defined CSS design.

Styling your dark mode even further

Since the light-dark() function can only be used for colors, you may still have to use the prefers-color-scheme media query to change other styles in your dark mode.

If you want to be even more creative, and learn deeply about dark mode option, I can recommend the “Dark Mode in CSS Guide” CSS-Trick blog posts, as well as the two pages on the color-scheme property and on the light-dark() function.

Conclusion

Adding a dark mode to your page and testing it has never been easier than with the methods described in the past blog posts. So maybe in those dark winter days, you can also adapt with the design of your website and try to create some nice dark color scheme.

Get CSS styles using JavaScript

You should usually use each of the basic web technologies for their main purposes: HTML for the markup, CSS for the styles and JavaScript for additional interactivity. But sometimes, those things cross into each other. There might be cases, in which you need to know the current rendered styles of an element. That’s what the topic today is about.

Get the computed styles of an element

The function name for that couldn’t be easier to remember: getComputedStyle(). It’s a function of the window object and gets passed the element we want the styles for:

const body = document.querySelector('body');
const bodyStyles = window.getComputedStyle(body);
const bodyFontSize = bodyStyles.getPropertyValue('font-size');
console.log(bodyFontSize); // 16px

To get a single CSS property, you use the getPropertyValue() function on the CSSStyleDeclaration object (in our case bodyStyles), and tell it what property you want to get.

If you run this code in a completely empty HTML, you will probably get 16px as the body font size, which is the default in most browsers, unless the size was changed in the operating system or browser.

But let’s see, where this can get more interesting. You don’t always have a fixed font width on an element, but might have one that is relative to other elements:

body {
	font-size: 22px;
}
h1 {
	font-size: 1.6em;
}
h1 small {
	font-size: 75%;
}

Now we have a website with a <h1> headline and some <small> element inside of it. What would our resulting font size be? Let’s grab our calculators:

<body> font-size: 22px
<h1> font-size: 22px * 1.6 = 35.2px
<small> inside <h1> font-size: 35.2px * 0.75 = 26.4px

So we should get a font-size of 26,4px for the small text. Let’s see, if that is the case, by also checking it with the dev tools:

Screenshot of Chrome with the opened dev tools. The page has an h1 element with a small inside. This element is selected and the "Computed" styles panel shows "font-size: 26.4px".

Here you can see a full example, with the modified selector. We have selected the <small> element, and Chrome shows us the 26.4px font-size in the “Computed” section. As I wrote after the console.log() call, this is also what we would get from JavaScript. Quite nice, isn’t it?

Getting styles from a pseudo-element

If an element has a pseudo-element, either specifically set or available by default, you can query styles for them. Let’s set some styles for the new ::marker pseudo-element of a list item:

ul li::marker {
	color: red;
}

We can’t just select a pseudo-element using the document.querySelector() method, but you can get the computed styles like this:

const element = document.querySelector('ul li');
const color = window.getComputedStyle(element, '::marker').color;
console.log(color); // rgb(255, 0, 0)

If you try to get styles for “an older pseudo-element” like the ::before pseudo-element, you can also use :before, but you can’t use :marker, as this is a newer pseudo-element, for which the variant with just one colon does not exist.

In this code snippet, I’m not using the getPropertyValue(), as it’s not strictly necessary. You can get most properties directly by their names. I’d recommend taking a look at the CSSStyleDeclaration object documentation of log the object to the console, to inspect the available properties.

What you can also see in this example is that we don’t get the value red, we have used in our CSS. Instead, we get rgb(255, 0, 0) as the computed style. You can find some more information on this in the notes on the documentation page.

Conclusion

You might have some JavaScript code that needs to know the styles of an element. Let it be the size, color, position or other properties that would have an effect on your code. In these cases, the getComputedStyle() is really helpful. WordPress Core is also using it in different place, like in the color-picker to warn about a too low color contrast. That’s a very good example on how to use the function.

Record and replay website interactions for tests

This is the final blog post on the debugging topic for this advent calendar. I reserved something special for the last one. Maybe you have something you have to test on the frontend (or backend) of your page, over and over again, after you have changed something. Let it be filling out a form, clicking through some elements or navigating pages. It can be really tiresome to do that over and over again manually. But if you are using Chrome for your tests, there is a nice built-in tool I’ve learned about from a colleague.

The Chrome Recorder feature

To get to this feature, you have two ways. You can open the panel in a similar way as we have opened the “Rendering” panel. Open the dev tools and click on the three vertical dots, and choose “More tools” and then “Recorder”:

Screenshot on how to open the "More tools > Recorder" settings.

The second way is to use the “Run Command” modal, which you open with “CTRL + SHIFT + P” (or “Command + Shift + P” on a Mac), and then search for “Recorder”. Once the panel is open, click on the blue “Create a new recording” button:

Screenshot of the opened Chrome Recorder panel with a blue "Create new recording" button.

On the next page, Chrome will automatically create a “Recording Name” for your recording with the current date and time, which you can overwrite with a more meaningful title:

Chrome Recorder panel with a changed "Recording Name" before the recording is started.

If you are ready, click on the red button at the button or hit “CTRL + E”. Then do something with the page. In this example, I clicked on the search in the top right, types “advent calendar” into the search field and hit ENTER. After the page reloaded, I clicked the button at the bottom again to stop the recording. You should see something like this then:

If you scroll up, you will find a “Show code” button in the top left. If you click it, you can see the technical file for the recording in different formats:

The most interesting button is the blue “Replay” button. Left of if, you can also select a playback speed. When you click the button, Chrome will show a message “Chrome is being controlled by automated test software”. It will then replay all steps and check each of them. When everything was successful, the vertical line will be green for some seconds:

In the top left of the panel, you can see a dropdown. Here you will find any recording you every did in that Chrome profile. With the buttons next to it, you can import, export and delete them. By exporting them into a JSON file and sending it to some other person, this can be a great way to share the repeatable test steps with others.

You can also expand each step and change the settings of the step. You can find a short video explaining the Recorder a bit more on the Chrome for Developers page.

Conclusion

If you want to repeat some test on a page, but don’t want to manually repeat every click and keystroke manually, the Chrome Recorder is a great tool you can use. It also has an export option, I will probably cover in another blog post. But since this does not fit into our four topics for the 2024 advent calendar, you have to wait until 2025.

I couldn’t find a similar feature in Firefox, but if you know of an extension that offers this in other browsers, please leave a comment.

Accessible accordions with the details HTML element

My second last blog post on the HTML topic in this advent calendar series wants to introduce an element some of you might have used, without even knowing it. But the functionality it offers you, many might have used in a website.

Toggle and accordion elements

When we only have one element that would reveal additional text on the click of a button or text, we often speak about “toggles”. If we have multiple, and only one is open at the same time, we usually refer to them as “accordions”.

In the past, we would have used a JavaScript library for such a functionality, some usual container elements and a button or link. But now, we have an element for this. If we want to have a single toggle, this would be our markup:

<details>
	<summary>Learn more about the details element</summary>
	This is text that would only be shown if the element opened.
	You can also use any other HTML elements here, you don't have
	use plain text only.
</details>

In this example, we don’t wrap our “hidden text” in any element. Most likely you would use a <p> or <div>, but really any content that comes after the <summary> will be hidden, as the element is “closed” by default. And this is how it would look like:

The right pointing arrow is there by default. The shape will look slightly different in different browser. When you click on the arrow or the text, the element will open, and the arrow now points down, indicating the element is open:

A triangle pointing down, with text from the summary element right of it and the rest of the content inside the details element below it.

As mentioned earlier, the element is closed by default, you can open it, by adding on empty open attribute to the element:

<details open>
<!--... -->
</details>

Now, clicking on the <summary> element will close the <details> element. I cannot really think of a use-case where one would use this for a single toggle. Why hide something on a click, that was already visible?

Creating an accordion using multiple “grouped” details elements

The <details> element has only to specific attributes. We’ve already learned about open, the second one is name. If you give multiple <details> elements this attribute with the same value, they will be grouped into an according, where always only one is open at the same time:

<h2>Group one</h2>
<details name="group-one">
	<summary>First element of group one</summary>
	<p>The content of the first element of group one.</p>
</details>
<details name="group-one">
	<summary>Second element of group one</summary>
	<p>The content of the second element of group one.</p>
</details>
<h2>Group two</h2>
<details name="group-two">
	<summary>First element of group two</summary>
	<p>The content of the first element of group two.</p>
</details>
<blockquote>
	<q>Some random quote in between</q>
	<p>Some famous person</p>
</blockquote>
<details name="group-two" open>
	<summary>Second element of group two</summary>
	<ul>
		<li>Item 1</li>
		<li>Item 2</li>
	</ul>
</details>

I’ve chosen a little more complex example here to show multiple things at once. First of all, we have two accordions using the name attributes values of group-one and group-two. This is how that HTML markup would render:

Two details accordion groups with a quote in between elements of the second group, which has an unordered list as the content of the second details element.

In group one, no element has the open attribute, so both of them are closed by default, whereas in group two, the second element has the open attribute and shows its content. In this case, the content is an unordered list, showing, that the element can contain any HTML and not only static text.

In between the first and second element of group two, we also have a blockquote. This should illustrate that you don’t need to have all <details> elements next to each other. You can have content between them.

If you open one of the other elements in the same group, the currently open element closes. If you close the open element as well, all elements are closed now. There is no (native) way to disallow closing all elements.

If you want to allow all elements to be open, just don’t use the name attribute on them. You could also use some JavaScript for an “open all” and “close all” button, that would toggle them. There is even a toggle event, you can register an event listener to. You can find out more about that in the documentation.

Styling the element

The documentation also has some basic styling examples. But is you want to see some more creative ways to style the element, take a look at the CSS-Tricks blog post covering the element.

Conclusion

When you really need to have a toggle/accordion element on your website, I can highly recommend using the native HTML elements. I personally don’t like toggle or accordions. I rather scroll through a longer page, than having to click on all these “toggles”, which also move the page up/down so you need to target the next element to click. That really frustrates me.

If you use WordPress, simply use the “Details” block, which will give you that exact element. You will have a line for the summary, and then a “Paragraph” block for the content, but you can use any block here, even multiple ones or blocks like “Group”, “Columns”, etc. to get really creative.

The prefers-color-scheme media query

Today I want to talk about something, many of you probably like a lot: dark modes! Or more specifically, how to switch the color scheme to dark mode, if visitors prefer it. I do use it for my IDE and for some online services, but for many, I’m still on the light side.

Detecting the dark mode and changing styles

Turning on dark mode is something a user can do in their operating system, in the browser or by clicking a button. Whichever way they choose, your CSS code should use the media query like this:

button {
	padding: 10px 20px;
	font-size: 2rem;
	background-color: #eee;
	border: 3px solid #333;
	border-radius: 10px;
	color: #333;
}
@media (prefers-color-scheme: dark) {
	button {
		background: #333;
		border-color: #333;
		color: #eee;
	}
}

This CSS will expect that you are using a light color scheme by default. If a visitor has set the preference to dark, they will get the alternative colors for the button. This is how a button would look like in light or dark colors:

A button with the text "light colors" on the left, with a light gray brackground-colors and a dark gray text and border-color. A second button on the right with the text "dark colors" and the text in light gray and the background and border in dark gray for a "filled" layout.

By using the same color for background and border, we made the dark version “filled”. You don’t always have to invert/swap all colors. That what some generic plugins do, though. As explained in “Simulate preferences in the browser“, you can easily test those dark mode styles without the need to change the settings in your operating system. Chrome also has an “Automatic dark mode” option, but this would just try to “guess” which colors to use, and we would have a slightly lighter gray for the background and a light gray border:

Two buttons, one labeled "light colors" and one "dark colors". Both have the same colors with a medium gray border, a dark gray background, and a light gray text color.

As you can see, even our defined colors for the dark mode of a button would not apply anymore. Instead, Chrome is displaying any button in this “automatic dark mode”. But I’m also not sure if many people really use this.

Using the light dark mode as the default

Many people design a website with a light mode as the default and then use the media query as shown above to change colors for a dark mode. But if you happen to design a page with a dark mode as the default, that would be a lot of CSS in this media query. What you can do instead: Change colors when a visitor explicitly prefers a light mode. This is how you do it:

button {
	padding: 10px 20px;
	font-size: 2rem;
	background-color: #333;
	border: 3px solid #333;
	border-radius: 10px;
	color: #eee;
}
@media (prefers-color-scheme: light) {
	button {
		background: #eee;
		border-color: #eee;
		color: #333;
	}
}

This code snippet is basically the first one again, with (almost) all colors switched, and with the major different that we now check for light in the prefers-color-scheme media query. The button now looks like this in the default dark mode and in light mode:

Two buttons, the left one with the text "dark colors", and a dark gray background and light gray. The right one with the text "light colors" and a light gray background and dark gray text.

So, depending on your own preference, you can decide which color scheme to use as your website’s default. Adding the other color scheme can make a huge difference in terms of readability and accessibility. Especially when you have a dark mode as a default, please consider offering a light scheme as well.

Conclusion

Adding a dark mode to your CSS was never easier as with this media query. If you want to give users an option to change the mode, a “toggle button” or some user setting can make sense. And for those, another property will come in handy. But this will be the topic for our last blog post in the 2024 advent calendar on CSS.

Tagged Template Literals in JavaScript

In the blog post 8 days ago with the title “Dynamic parameters in JavaScript“, I have shown you how functions with a variable number of parameters work. Today, I want to talk about the “tagged templates” feature in JavaScript, as a form of a function with a variable number of parameters.

Template Literals

Before we head into the topic, let’s talk about template literals first. In old versions of JavaScript, you would have done the following, you place a variable in between some static text:

var name = "Bernhard";
var country = "Finland";
var greet = "Hi, my name is " + name + " and I'm currently in " + country + ".";
console.log(greet);
//Hi, my name is Bernhard and I'm currently in Finland.

With modern JavaScript, you can use a “template literals” to place some variable (or even code) inside your strings that get interpreted:

const name = "Bernhard";
const country = "Finland";
const greet = `Hi, my name is ${name} and I'm currently in ${country}.`;
console.log(greet);
//Hi, my name is Bernhard and I'm currently in Finland.

Using the backticks instead of other quotes, we turn our simple string into a template literal. Isn’t that much easier to read? Ah, and yes. I am currently in Finland, and not in Berlin. On the Åland Islands, to be precise.

Tagged Template Literals

After this short introduction, let’s come to the “tagged” template literals. When you first see them, they might look a bit odd. This is how one example might look like:

const name = "Bernhard";
const country = "Finland";
const greet = makeItBold`Hi, my name is ${name} and I'm currently in ${country}.`;

function makeItBold(strings, ...values) {
	// strings => ['Hello, my name is ', " and I'm currently in ", '.']
	// values => ['Bernhard', 'Finland']

	let result = "";

	// Loop through the strings and values
	for (let i = 0; i < values.length; i++) {
		result += strings[i] + `<b>${values[i]}</b>`;
	}

	// Append the last string (after the last variable)
	result += strings[values.length];

	return result;
}

console.log(greet);
// Hi, my name is <b>Bernhard</b> and I'm currently in <b>Finland</b>.

We define a function (makeItBold) and then we just write the function name before the template literal. In the function, we get the “static strings array” as the first strings parameter and then a dynamic number of parameters for each “variable” (or more precisely the expressions) in the template literal as the second values parameter. We could also write this function like this:

function makeItBold(strings, name, country) {
	// ...
}

But that would not really be flexible, if we swap the variables around or have more/fewer variables in another string.

One thing we can do, to make the function a little shorter, is using some modern JavaScript code handling arrays (written in multiple lines for better readability):

function makeItBold(strings, ...values) {
	return strings.reduce(
		(result, str, i) => result + str + (values[i] ? `<b>${values[i]}</b>` : ""),
		""
	);
}

Those of you familiar with modern JavaScript can probably easily read this, I still have to look twice and read it carefully.

I had hard times finding a good “real life example”, but after coming up with the example above, I found one that might be really useful, and that is not using scalar values, but objects. What do you think about this one?

function schema(strings, ...values) {
	return strings.reduce((result, str, i) => {
		const value = values[i];
		if (value) {
			// Check for specific schema.org types and add relevant markup
			if (value.type === "Person") {
				return (
					result +
					str +
					`<span itemscope itemtype="https://schema.org/Person">
						<span itemprop="name">${value.name}</span>
					</span>`
				);
			} else if (value.type === "Place") {
				return (
					result +
					str +
					`<span itemscope itemtype="https://schema.org/Place">
						<span itemprop="name">${value.name}</span>
					</span>`
				);
			}
		}
		return result + str;
	}, "");
}

// Usage
const name = { type: "Person", name: "Bernhard" };
const country = { type: "Place", name: "Finland" };

const greet = schema`Hello, my name is ${name} and I'm currently in ${country}.`;

console.log(greet);
// Hello, my name is <span itemscope itemtype="https://schema.org/Person"><span itemprop="name">Bernhard</span></span> and I'm currently in <span itemscope itemtype="https://schema.org/Place"><span itemprop="name">Finland</span></span>.

Conclusion

As mentioned, I wasn’t easy finding a good example. One could argue, that you could also just a template literal in many cases and some inline HTML markup. But still this feature is available to you, and you should know how to read code using it.

If you have an example from one of your projects using a tagged template literal, please leave a comment.

Pausing JavaScript with the debugger keyword

This blog post is not going to cover the basic topic on how to debug JavaScript code in your browser. We could probably have a full advent calendar covering all the aspects. But I want to introduce a neat little keyword for your debugging toolbox.

Setting a breakpoint in the browser

When you want to debug some JavaScript code, you probably set some breakpoint in your code at some point. If you have a small JavaScript file that is nicely formatted, it might look like this in Chrome:

Chrome dev tools with a manual breakpoint set the browser stopped on that line.

You would open the dev tools, navigate to the JavaScript file in the “Sources” tab, set a break point and reload the page. Chrome will then stop at the line and you can debug your code.

The issue with compiled JavaScript code

Those of you developing code with React, Vue, etc. and using webpack or similar tools to compile your code, will not have such nicely formatted code that is also easy to read. Let’s throw in our code from above into the compiling workflow from the @wordpress/scripts package and compile it:

npm run build

Now we get a compiled “production” file, and our nicely formatted code is now only a single line in this compiled file:

Chrome dev tools showing a minified JavaScript file.

How do we set a breakpoint now? If you want to set a breakpoint in a “single line JavaScript” file, there is a little feature you can use. Just click on the “{}” icon (“Pretty print”) in the bottom left of the middle column, and you will get something like this, where you can set a breakpoint in the “virtual line”:

Chrome dev tools "pretty printing" the one-line JavaScript file and a manual break point set on a prettified line.

That kind of works. But if you want to debug the console.log() calls at the end of the file, they are still in one line and additionally in a ternary operator.

Using the debugger keyword for a “forced breakpoint”

After this short introduction, we now come to the keyword, I wanted to talk about today. While you develop your code, you can add the debugger keyword to any line of your code, which will force the browser to pause on that line. Let’s use it in the compiled version to debug the “if” portion of the ternary operator. We use a different command now to get the “development version” that would also start a watcher and compile the code as soon as we change something:

npm run start

In our JavaScript code, we also add the debugger keyword like this to the if/else at the end:

if (found) {
    debugger;
    console.log(`there is a 4 in array ${found}'`);
} else {
    console.log("There is no 4 in the array");
}

If we refresh the browser now, it will stop at this keyword in line 17. We don’t have to add a breakpoint here:

Chrome dev tool showing a JavaScript file stopped at the "debugger" keyword.

In the top right you can see “Debugger paused” and the script stopped, just as with a breakpoint set by us manually in this view. We can now continue with our debugging.

Using the debugger keyword in minified files

First of all: you probably shouldn’t do that. If you use the “build” script, you are usually creating files for production, and these should not have a debugger keyword in them. That’s why the minification webpack plugin is removing this keyword. If, for whatever reason, you do want to have the debugger keyword in the compiled files, you need to write a custom webpack.config.js webpack configuration file:

const defaultConfig = require('@wordpress/scripts/config/webpack.config');
const TerserPlugin = require('terser-webpack-plugin');

module.exports = {
    ...defaultConfig,
    optimization: {
        ...defaultConfig.optimization,
        minimize: true,
        minimizer: [
            new TerserPlugin({
                terserOptions: {
                    compress: {
                        drop_debugger: false,
                    },
                },
            }),
        ],
    },
};

If we run npm run build now and refresh the browser, we will see the keyword and the browser stops there:

Chrome dev tool showing a JavaScript file stopped at the "debugger" keyword in a "prettified" minified code.

This would also automatically trigger the “Pretty print” icon in the bottom left and show you the code like above.

Conclusion

It may sometimes be hard to set a breakpoint manually, especially if your JavaScript files get compiled, combined and even minified, and you have no idea where a line you just wrote end up. You can also just set the debugger keyword temporarily, and once the script stopped, set a regular breakpoint, to remove the keyword right away, so you also don’t accidentally publish code with the keyword inside.