HTML lists are boring. They don’t do a lot, so we don’t actually take into consideration them regardless of how extensively used they’re. And we’re nonetheless capable of do the identical issues we’ve all the time carried out to customise them, like eradicating markers, reversing order, and making customized counters.
There are, nonetheless, a number of “newer” issues — together with risks — to know when utilizing lists. The risks are principally minor, however far more frequent than you would possibly assume. We’ll get to these, plus some new stuff we will do with lists, and even new methods to method outdated options.
To make clear, these are the HTML parts we’re speaking about:
- Ordered lists
<ol> - Unordered lists
<ul> - Description lists
<dl> - Interactive lists
<menu>
Ordered lists, unordered lists, and interactive lists include listing objects (<li>) that are displayed based on what sort of listing we’re coping with. An ordered listing (<ol>) shows numbers subsequent to listing objects. Unordered lists (<ul>) and menu parts (<menu>) shows bullet factors subsequent to listing objects. We name these “listing markers” and so they may even be styled utilizing the ::marker pseudo-element. Description lists use description phrases (<dt>) and outline particulars (<dd>) as a substitute of <li> and don’t have listing markers. They‘re supposed for use to show metadata and glossaries, however I can’t say I’ve ever seen them within the wild.
Let’s begin off with the straightforward stuff — easy methods to appropriately (a minimum of in my view) reset listing types. After that, we’ll check out a few accessibility points earlier than shining a light-weight on the elusive <menu> factor, which you will be stunned to study… is definitely a sort of listing, too!
Resetting listing types
Browsers routinely apply their very own Consumer Agent types to assist with the visible construction of lists proper out of the field. That may be nice! But when we need to begin with a clean slate freed from styling opinions, then we now have to reset these types first.
For instance, we will take away the markers subsequent to listing objects fairly simply. Nothing new right here:
/* Zap all listing markers! */
ol, ul, menu {
list-style: none;
}However fashionable CSS has new methods to assist us goal particular listing situations. Let’s say we need to clear markers from all lists, besides if these lists seem in long-form content material, like an article. If we mix the powers of newer CSS pseudo-class features :the place() and :not(), we will isolate these situations and permit the markers in these circumstances:
/* The place there are lists that aren't articles the place there are lists... */
:the place(ol, ul, menu):not(article :the place(ol, ul, menu)) {
list-style: none;
}Why use :the place() as a substitute of :is()? The specificity of :the place() is all the time zero, whereas :is() takes the specificity of probably the most particular factor in its listing of selectors. So, utilizing :the place() is a much less forceful approach of overriding issues and will be simply overridden itself.
UA types additionally apply padding to area a listing merchandise’s content material from its marker. Once more, that’s a fairly good affordance proper out of the field in some circumstances, but when we’re already eradicating the listing markers like we did above, then we could as nicely wipe out that padding too. That is one other case for :the place():
:the place(ol, ul, menu) {
padding-left: 0; /* or padding-inline-start */
}OK, that’s going to stop marker-less listing objects from showing to drift in area. However we form of tossed out the infant with the bathwater and eliminated the padding in all situations, together with those we beforehand remoted in an <article>. So, now these lists with markers sorta dangle off the sting of the content material field.
Discover that UA types apply an additional 40px to the <menu> factor.
So what we need to do is stop the listing markers from “hanging” exterior the container. We will repair that with the list-style-position property:
Or not… possibly it comes all the way down to stylistic desire?
Newer accessibility considerations with lists
Sadly, there are a few accessibility considerations with regards to lists — even in these extra fashionable instances. One concern is a results of making use of list-style: none; as we did when resetting UA types.
In a nutshell, Safari does not learn ordered and unordered lists styled with list-style: none as precise lists, like when navigating content material with a display reader. In different phrases, eradicating the markers additionally removes the listing’s semantic that means. The fix for this fix it to use an ARIA list role on the list and a listitem role to the list items so display readers will decide them up:
<ol type="list-style: none;" function="listing">
<li function="listItem">...</li>
<li function="listItem">...</li>
<li function="listItem">...</li>
</ol>
<ul type="list-style: none;" function="listing">
<li function="listItem">...</li>
<li function="listItem">...</li>
<li function="listItem">...</li>
</ul>Oddly, Safari considers this to be a feature relatively than a bug. Principally, customers would report that display readers have been asserting too many lists (as a result of builders are inclined to overuse them), so now, solely these with function="listing" are introduced by display readers, which really isn’t that odd in spite of everything. Scott O’Hara has a detailed rundown of the way it all went down.
A second accessibility concern isn’t one in all our personal making (hooray!). So, you understand how you’re supposed so as to add an aria-label to <part> parts with out headings? Effectively, it typically is smart to do the identical with a listing that doesn’t include a heading factor that helps describe the listing.
<!-- This listing is considerably described by the heading -->
<part>
<h2>Grocery listing</h2>
<ol function="listing">
<!-- ... -->
</ol>
</part>
<!-- This listing is described by the aria-label -->
<ol function="listing" aria-label="Grocery listing">
<!-- ... -->
</ol>You completely don’t have to make use of both technique. Utilizing a heading or an ARIA label is simply added context, not a requirement — you’ll want to take a look at your web sites with display readers and do what affords the very best person expertise for the scenario.
In considerably associated information, Eric Bailey wrote up a wonderful piece on why and how he considers aria-label to be a code smell.
OK, so, you’re probably questioning about the entire <menu> parts that I’ve been slipping into the code examples. It’s really tremendous easy; menus are unordered lists besides that they’re meant for interactive objects. They’re even uncovered to the accessibility tree as unordered lists.
Within the early days of the semantic net, I mistakenly believed that menus have been like <nav>s earlier than believing that they have been for context menus (or “toolbars” as the spec says) as a result of that’s what early variations of the HTML spec mentioned. (MDN has an interesting write-up on the entire deprecated stuff associated to <menu> should you’re in any respect .)
Right now, nonetheless, that is the semantic approach to make use of menus:
<menu aria-label="Share article">
<li><button>E mail</button></li>
<li><button>Twitter</button></li>
<li><button>Fb</button></li>
</menu>Personally, I believe there are some good use-cases for <menu>. That final instance reveals a listing of social sharing buttons wrapped up in a labeled <menu> factor, the notable side being that the “Share article” label contributes a big quantity of context that helps describe what the buttons do.
Are menus completely crucial? No. Are they HTML landmarks? Positively not. However they’re there should you take pleasure in fewer <div>s and you’re feeling just like the element may use an aria-label for added context.
The rest?
Sure, there’s additionally the aforementioned <dl> (description listing) factor, nonetheless, MDN doesn’t seem to consider them lists in the identical approach — it’s a listing of teams containing phrases — and I can’t say that I’ve actually seen them in use. In keeping with MDN, they’re supposed for use for metadata, glossaries, and different kinds of key-value pairs. I might simply keep away from them on the grounds that each one display readers announce them otherwise.
However let’s not finish issues on a damaging be aware. Right here’s a listing of tremendous cool issues you are able to do with lists:
