Site migration from WP to 11ty in progress. Some things may be temporarily broken.
{the} Amy Carney

HTML's output element is pretty amazing. I mean, honestly, HTML is pretty amazing, right? Many elements can just DO things, plus express their own purpose. The output's abilities are no less astounding. Think about. You put in some value, and there they are on the screen. To me, it's like magic.

In this post, I share:

What is the output element?

The MDN (Mozilla Developer Network) defines it as:

The <output> HTML element is a container element into which a site or app can inject the results of a calculation or the outcome of a user action.

Oversimplified? Dynamic information results display here.

It's usually coupled with an input inside a form. A user can enter information into the input field and see a live calculation or result in the output container. The result can happen as data changes or the user activates a submit button. Sometimes the result can come from another source, but it still needs user guidance to receive that result.

Two examples of output in action

Example 1: Markdown Previewer

Someone can enter markdown in an expandable text box and see the HTML-structured content appear in the output container (previewer).

https://codepen.io/digilou/pen/WNzYYNM??editors=1100

Example 2: Multiplication Table

Someone can enter a positive number between 1-12 to create it's multiplication table.

https://codepen.io/digilou/pen/WNzLpWv

Note on accessibility

Considering accessibility is always my main focus in web development, I'd be remiss to ignore that detail when choosing to use the output element.

In their HTML documentation, MDN mentions:

Many browsers implement this element as an aria-live region. Assistive technology will thereby announce the results of UI interactions posted inside it without requiring that focus is switched away from the controls that produce those results.

In both of my examples, an aria-live region may or may not be the right choice. After creating these examples, I had several questions, in which I could only speculate the answers. Fortunately, I found some of my answers through Scott O'Hara's accessibility testing of the output element!

In my first CodePen example, I was torn about using output. Should I even consider changing focus to output? That just feels rude (and evil) while someone is still typing. Should I make output focusable with tabindex=0? Additionally, I learned through Scott's article that headings and lists aren't allowed, so I question if I should abandon output as a solution for my markdown viewer altogether. It seems like I'm just asking to break an accessible experience. To quote Scott, "Concise, simply marked up messages are key for well performing live regions. Think of these restrictions as guardrails to keep your content understandable and accessible!"

In my second scenario, I added a submit button, so the results would appear when the user was ready. I felt that oninput can create a surprising, overwhelming, or frustrating experience if the person hasn't finished typing.

Through my own light and lazy testing, I noticed that announced updates in the previewer weren't consistent between Firefox/VoiceOver/macOS and Safari/VoiceOver/iOS. I could test further, but deeply feel that the implementation of output deserves solid AT (assistive technology) user testing to learn from what they expect and how it affects them. I'd love to see that documented somewhere!

Note on JavaScript

Ok, ok, so I did say at the beginning that HTML is like magic because some elements just DO things. The output element does need some JavaScript (and CSS) to help it along. Often, that JavaScript is inline with the element itself.

To start, you should use the attributes it comes with (for, id, name). In my examples, I started with output's attributes and the form's event handler. After I had those key pieces set up, I started adding additional JavaScript. My second example with the array needed a separate JavaScript function to calculate that.

As a side note, related more to CSS, I was happy to discover how easily I could style the output element.

When should I use output?

Just like any HTML element, output was created for a very specific purpose. It's useful in instances when your user needs to enter information and receive immediate results on that page. A few examples where I think it could be useful:

What motivated me

I learn through building. Videos and blog posts are wonderful resources. But until I can apply the information I've consumed, I can't get that information to stick.

This exploration of output is brought to you in part by freecodecamp and CodeWars. Recently, I've been working through a few front-end projects and JS katas. Those got the wheels in my head turning. My curiosity was peaked and I had to try a couple things.

I don't claim to have made perfect examples of the use of the output element. Not to mention I could spend a lot more time on styling and usability. But I did discover a lot in the process!

I hope my learning encourages you to give this underrated HTML element a try, too. You might just find it's useful in your next project in place of a div.

Resources I read to learn about output