Topic analysis

HTML Lists

This second installment in the “You don’t know HTML” series is going to be all about the ways that we put collections of things together. We’re skipping over the MDN and W3Schools introductory pages and instead we’re going into the kind of stuff you discover after accidentally taking your cousin’s Ritalin right before you open up the W3C specs. Let’s dive deep into lists. I’m assuming you’ve got real-world experience writing HTML and this isn’t your first time searching “How to make a list.” What I’m going to cover are all of the ways you can put collections of content together. So I’m talking about these kinds of lists: And if you didn’t know there were five different kinds of lists in HTML, perfect . That must mean you don’t know HTML ! No need to ask AI for a summary; I’ll just give you the ending up front. Here’s how you’ll decide which kind of list to use: When we think of lists, we don’t usually throw user control fields into the mix. And that’s weird, because we construct our navigations using lists, and those are lists of links that the user…uh…can control. So we tend to have a bias with what we think lists are. But I’m here to bring that to the forefront of your mind: when we’re building forms, sometimes we’re building lists that our users will interact with. When I say “fixed”, I mean that the user can only choose the items from that list. If that’s the case, let’s use select and option Suppose we want a list of languages to talk in: This gives the user exactly one choice to make. But if the user were also multilingual, maybe they’d like to choose more than one. Easy enough with the multiple attribute! The list will display differently. Now all the options will be visible so we can shift or cmd + click the ones we want: So long as you’re doing this with an actual select element and an option , you don’t have to use the aria-multiselectable attribute on a list element with the role="listbox" attribute. Native browser semantics bakes that in for you. What if we wanted to group languages by language-families? We can do that with optgroup which lets us group a list of options together: What if there’s a bunch of options, but for [reasons] we don’t want a user to be able to select a subset of them? Let’s add the disabled attribute to an optgroup : Sometimes we may want a visual break between your groups. If we don’t want to fiddle with CSS, we’re in luck! An is an approved item in a select . Not only does that make our select look a little sharper, we can also use the size attribute to control how many items will be displayed at once — making this useful for especially long lists. We just gotta watch out with size if we’re also using optgroup because those group labels will take up some of that space we were probably hoping for: Let’s suppose we have a control where we want to suggest a list options to a user. This is where we get the datalist involved. Using a datalist is a two-step process because we have to tell the input to use a datalist . We need to watch out for using a value attribute on the of a ! This isn’t a datalist problem but an option problem: The default value for an option is the text it wraps. A value attribute overrides that and then the text acts like a label. This is no big deal for a select list because the user only sees the text. But if we put a value on an in a datalist the user will see the “label” in the list, but when they select it they’ll see the value in the input . It’s a confusing experience. Start typing w in this input and then select “Welsh” to see what I mean: So if we’re going to use a datalist , we need to work with the understanding that the value is what gets inserted — not the label. We tend to think of the datalist as being useful for text options. But that ain’t how it has to work. Suppose we had a calendar widget and we wanted to gently suggest a particular range of weeks in the year. We could do that with a datalist : isn’t limited to stringy values; it works with numbers. Which means we could pair it with a range input and create labeled stops along the range. The only thing we have to watch out for in this approach is that not all browsers are guaranteed to work the same way. In Chrome and friends, we could display these stops with very programmatic and simple CSS. In Firefox…shenanigans are involved. But it starts with the big idea that you can display a datalist : Our programmatic styles which will work in Chrome and friends will involve using the attr() function, casting it to a percent, and some math. For this to work in Firefox, we have to go in a different and more annoying direction. We will need to manually set these as separate rulesets. And we will target a pseudo-element instead. And our math gets weirder. This is not guaranteed to display well on your screen: Any time we have a collection of items that must be read in a particular order, we should use an ordered list. We should not let visual presentation dictate this choice . It’s not about whether the items should have numbers next to them. It’s about whether their sequence matters. These are the kinds of collections that should be an ordered list: And the reason these should be an ordered list is because changing the order of the items would change the meaning of the list . Our bread will bake differently if it’s not in an ordered list! And if we say something is alphabetical, it’d be weird to suggest it could be ordered differently! The great thing about a well-structured ordered list is that we don’t need to see it rendered to follow along . We can read this all on our own without a browser and see what things need to happen: So there’s a reason I’ve really gone hard on stressing that an ordered list is about anything that has a prescribed sequence. And it’s because there are two attributes specifically for an The reversed attribute changes the numbering sequence from ascending to descending. But it doesn’t change the order of the list . This is useful if you’re showing something from “most to least” like…ingredients and quantities: Now, we could add just a little dab o’ JavaScript to this that could make this list truly reversy : What if our banana bread were a series of ordered lists, instead of one mega list? The start attribute is here to help by letting us tell the list where to start the numbering. It’s a useful tool for establishing continuity across our lists. I like to refer to the description list as the “forgotten list” because…well…it is. We spend most of our time trying to fit everything into an ordered list or an unordered list and the whole time description lists have been hanging out in the back corner. In HTML 4, this was called a definition list instead of a description list; its purpose was a bit more narrow as it was meant for only providing definitions. The definition list contained a which was a definition term and then a which was a …definition definition . So the classic usage of yesteryear could’ve been something like this. Take note that true semantic accuracy means we wrap the terms that are being defined in HTML5 came along and decided that this was a description list . So this isn’t just confined to the very narrow use-case of listing definitions. This is what we use any time we have some set of terms and values . Not only that, in HTML5 they realized it was kinda annoying that the spec didn’t allow us to clump the terms and definitions together. So now a is permitted as a non-semantic wrapper to help us clump those terms and definitions together: We should be using a description list for displaying any kind of metadata . If it’s a series of facts and labels, that’s a description list! A user profile belongs in a . And if we don’t like the indented nature, we can fix this with a few lines of CSS: I personally think that one of the best applications for a description list is debugging. If I want to debug a chunk of JSON in a single-page application, I do that with a . I often put a debug.vue template in my single-page apps for showing me a JSON object and of course it uses . But it really isn’t that much code to have a small utility that renders your (least) favorite objects with a description list: We should be using more description lists, y’all. This one is more for the interactive side of the web than the content-rendering side. menu is specifically a list of commands; it exists to be yet another reason not to use . If we had a rich text editor that had some controls for modifying text, that would belong in a menu : The HTML specification says that this is meant to be a toolbar . As you’re making an interactive web page, look around at all of the places where you’ve got buttons for tools . Those probably belong in a menu. So if you were making a lightweight set of controls for a video, that would also belong in a menu : Using menu means you don’t have to add aria-role="menu" to an unordered list. If we don’t want list items to look list-itemy in our navigations then we don’t want that for our menu s, either. You probably want something like this high up in your stylesheet: Quite confusingly, the nav element isn’t merely the linky variety of the menu element. They have different semantics and different permitted content . It’s tempting to think that the differences between the two elements is purely semantics. It isn’t. One is a sectioning element that just so happens to wrap a list most of the time and the other is a listing element that’ll only ever wrap list items. And Menu and nav are not mutually exclusive choices. A menu could go in a nav , but a nav could never go in a menu . We’ve got four lists and a wannabe (nav) that have pretty well-defined semantics. But now we’ve finally made it to the junk drawer: the unordered list. The “well if you need to put your crap somewhere you might as well put it here,” list. The catchall for all your other listy needs. In the time long ago when HTML wasn’t as concerned about semantics, the only difference between ordered and unordered lists was the visual aspect: do you get numbers or bullets? But we don’t live in that time any more. Now we care about accessibility and screen readers and search engine optimization. So we ignore the visual aspect and focus on the meaning . It’s not about what lil’ auto-generated characters are added to the list item. It’s about whether the order of the items matters. So a list of band members should be an unordered list: As should a list of bands: Well… we should know more . We’ve talked about the five different kinds of lists: And we’ve learned some cool things we can do with our lists At the very least, we can say that we know what we don’t know about HTML lists.