HTML lists are boring. They don’t do a lot, so we don’t actually take into consideration them regardless of how broadly used they’re. And we’re nonetheless capable of do the identical issues we’ve at all times accomplished to customise them, like eradicating markers, reversing order, and making customized counters.
There are, nevertheless, just a few “newer” issues — together with risks — to know when utilizing lists. The hazards are principally minor, however far more frequent than you would possibly suppose. We’ll get to these, plus some new stuff we will do with lists, and even new methods to strategy outdated options.
To make clear, these are the HTML components we’re speaking about:
- Ordered lists
<ol> - Unordered lists
<ul> - Description lists
<dl> - Interactive lists
<menu>
Ordered lists, unordered lists, and interactive lists comprise listing objects (<li>) that are displayed in response to what sort of listing we’re coping with. An ordered listing (<ol>) shows numbers subsequent to listing objects. Unordered lists (<ul>) and menu components (<menu>) shows bullet factors subsequent to listing objects. We name these “listing markers” and they will even be styled utilizing the ::marker pseudo-element. Description lists use description phrases (<dt>) and outline particulars (<dd>) as an alternative 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 — find out how to accurately (at the least in my view) reset listing types. After that, we’ll check out a few accessibility points earlier than shining a lightweight 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 Person 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 trendy CSS has new methods to assist us goal particular listing cases. 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 cases 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 an alternative of :is()? The specificity of :the place() is at all times zero, whereas :is() takes the specificity of essentially the most particular factor in its listing of selectors. So, utilizing :the place() is a much less forceful approach of overriding issues and could be simply overridden itself.
UA types additionally apply padding to house a listing merchandise’s content material from its marker. Once more, that’s a reasonably 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 might as properly 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 house. However we kind of tossed out the infant with the bathwater and eliminated the padding in all cases, together with those we beforehand remoted in an <article>. So, now these lists with markers sorta cling 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… perhaps it comes right down to stylistic desire?
Newer accessibility considerations with lists
Sadly, there are a few accessibility considerations on the subject of lists — even in these extra trendy instances. One concern is a results of making use of list-style: none; as we did when resetting UA types.
In a nutshell, Safari doesn’t learn ordered and unordered lists styled with list-style: none as precise lists, like when navigating content material with a display screen reader. In different phrases, eradicating the markers additionally removes the listing’s semantic which means. The repair for this repair it to use an ARIA listing function on the listing and a listitem function to the listing objects so display screen readers will decide them up:
<ol model="list-style: none;" function="listing">
<li function="listItem">...</li>
<li function="listItem">...</li>
<li function="listItem">...</li>
</ol>
<ul model="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 function relatively than a bug. Principally, customers would report that display screen readers had been saying too many lists (as a result of builders are likely to overuse them), so now, solely these with function="listing" are introduced by display screen 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 speculated to add an aria-label to <part> components with out headings? Effectively, it generally is smart to do the identical with a listing that doesn’t comprise 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 methodology. Utilizing a heading or an ARIA label is simply added context, not a requirement — make sure to take a look at your web sites with display screen readers and do what provides one of the best consumer expertise for the scenario.
In considerably associated information, Eric Bailey wrote up a wonderful piece on why and the way he considers aria-label to be a code scent.
OK, so, you’re doubtless questioning about all the <menu> components 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 had been like <nav>s earlier than believing that they had been for context menus (or “toolbars” as the spec says) as a result of that’s what early variations of the HTML spec stated. (MDN has an fascinating write-up on all the deprecated stuff associated to <menu> in case you’re in any respect .)
At the moment, nevertheless, 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 feel 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 major 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 in case you take pleasure in fewer <div>s and you’re feeling just like the element might use an aria-label for added context.
The rest?
Sure, there’s additionally the aforementioned <dl> (description listing) factor, nevertheless, MDN doesn’t appear to think about 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 sorts of key-value pairs. I’d simply keep away from them on the grounds that every one display screen readers announce them otherwise.
However let’s not finish issues on a unfavourable notice. Right here’s a listing of tremendous cool issues you are able to do with lists:
