Ordered and unordered lists have been popping up more often within the blogosphere lately. Through the use of style sheets, we can now tame our lists, rendering them in ways that traverse well beyond the traditional bulleted form so overused by PowerPoint addicts. I’ve been debating with myself whether this is a good or bad thing.
HTML lists have been around for years. And they’ve certainly been used frequently to create standard sets of links. But as we move toward a more semantic web, we’re becoming aware that certain grouped interface elements and conventions could actually be considered lists as well, even though we may not always envision a number or bullet in front of each list item.
Using a styled unordered list has become increasingly popular as a means to render site navigation. This seems acceptable enough if the navigation runs along the left or right side of the interface. After all, this fits nicely with the preconceived notion of what a list is: three or more succinct items, listed one item after another. I start to have trouble with using lists for navigation in scenarios where said navigation runs horizontally across the top of a page, like it does across the top of this site.
By declaring a list item’s display attribute as “inline”, and removing any list markers by setting the list-style-type attribute to “none”, you can effectively create a display of horizontally grouped items as if you had typed out a comma-delimited list of your past responsibilities in the middle of a resumé paragraph. Is that still considered a list? CSS can be used to override almost every default rendering of any HTML element. But with the use of CSS comes the responsibility to ensure the content is still accessible, navigable, and easy to use when style information is ignored or not supported. If CSS is used to style an element beyond the point that it’s still recognizable as that element, perhaps it’s time to question the use of that element?
I’ll admit right away that some of my concerns are rooted in presentation details. And this is the reason for my internal debate. I know structural markup should be kept separate from presentational style. But the choice of HTML element here can actually affect a user’s perception of what the links are, and thus could also influence behavior and expectations.
Unstyled unordered lists are usually rendered as vertical bulleted lists, with each successive item below the previous. As I’ve said, this is fine for left- or right-side navigation. But when a vertical list of links appears at the top of a page, we tend to think of them as “Contents” links which anchor to a point further down on a long page, and not site-wide navigation which reveals top-level architecture. We’ve come to expect site-wide navigation across the top of the page is horizontal in nature, not vertical.
So we can make the styled version of a navigation list fit horizontal expectations. But what about the unstyled versions we leave behind as raw vertical lists? Should navigation intended to be rendered as tab-like in nature be structured differently than a typical bulleted list?
After all that doubt, I’m still willing to give it a try. The navigation here was originally rendered by simple <a> and <strong> tags, divided by hidden pipes, such that it looked something like this without style applied:
Home | Log Archive | Articles | Portfolio | …
It was conveniently constructed to appear like normal horizontal navigation, and even used the strong element to highlight the current page or section. It saved space when viewing in a desktop browser at least 640 pixels wide since it only occupied one normal line of text. But it did look quite ugly as it wrapped on smaller PDA and mobile screens. And the pipes were awkwardly read aloud as “vertical bar” in screen readers, producing something like “link: home vertical bar, link: log archive vertical bar…”. Not very cool either.
As of last night, I’ve decided that maybe navigation is best structured as a list, whether intended to be rendered vertically or horizontally. A group of short navigation items can easily be classified as a list. And I don’t need to limit my preconceptions of lists to vertically-oriented versions. To rationalize, I only need turn back to my original definition of a list:
“three or more succinct items, listed one item after another”
View this page without style using an older browser (v. 4.x or earlier), or using this Toggle CSS style sheets favelet (from Tantek Çelik) to see the raw bulleted list. (Use the favelet again to bring the style sheets back, or just reload the page.) A few minor additions were made to my style sheets — mostly to compensate for normal behavior of the new list. The current styled version contains no visible differences over the previous styled version. Most people would never know the difference. But now screen readers should read the navigation as a clean list without the annoying “vertical bar” announcement, and the wrapping issue on small screens has been addressed.
Some may still disagree that horizontal navigation is a list, citing expansions of the doubts I expressed above. But I’m willing to try small changes. Whether they’re improvements or not? Might still be debatable. But this is the Web, it’s all changeable.
Next on the list to debate internally: Tantek’s consideration (and execution) that a blog is just one big set of nested lists, consisting of “time date ordered sequences”. (He’s been well ahead of all of us in the use of horizontal unordered lists for navigation.) Hmmm. Extra convincing will be necessary if I’m to believe that multiple paragraphs work well when marked up as one gigantic nested list item. Fortunately, he’s still using all the heading elements to help convey typographic hierarchy.
Posted in Web
6 comments (Comments closed)
In my opinion one thing is important (as you already said): for styled version it doesnt really matter if a navigation is a list (meaning ‘can be recognised as…’) or not - user doesnt care if he recognizes the links. But unstyled version have advantages seeing eg. navigation as list (see also SimpleQuiz). So I like using UL for navigation.
What would be interesting for me: What did your ‘internal debate’ about further use of list-items (last paragraf) result in?
Following Tobias thought, what did your ‘internal debate’ result in? I felt that this article was left unfinished in a way because it wasn’t clear what the result was.
Well, I guess it was left dangling, wasn’t it?
I’m still torn over the approach. Tantek is sold on it. I see some benefits and logic to making each entry a list item.
But something in me is uncomfortable with wrapping a <ul> and <li> around everything (or in Tantek’s case, an <ol>). For some reason, it reminds me of the days when we wrapped a table around everything just to control layout.
The benefits of moving each entry to a list item might be more apparent in screen readers and other assitive devices. Screen readers will often encounter a list, and announce how many items are included in the list. This allows the user to decide how to rapidly to move through the list, or maybe even to skip it entirely. If a screen reader allows the user to “jump” from one list item to the next (without the use of traditional name anchors), then I’d see this as a very good thing, and a reason to convert each <div class=”entry”> to a <li>. It would allow a user to skip multiple entries and get to one they hadn’t read.
But it all comes down to the title of this post. Is there a point where lists are simply overused? I don’t know the answer to that one.
I would state emphatically, that no, the blog entries should not be marked up as a huge list. To say that blogs are essentially a list of entries illustrates the giant red herring of ‘markup for structure’, which is that structure is not a clearly definable attribute. You can clearly conceive of a list of entries as a series of paragraphs. Barring any unforeseen and overwhelming benefits that a giant list might afford you, I would get back the reason that pre-5.0 browser development was so cracked to begin with: HTML documents were getting far too complicated and the benefits of the medium were disappearing under a deluge of tables and font tags. As far as I’m concerned, the move towards validated XHTML and CSS has been as much a benefit to web designers and developers in the simplification of web page production as in the structural improvements that are meant to benefit end users. Given a choice between two semantically acceptable ways of marking up some content, I’ll take the one with fewer nested tags any day.
We don’t need to put our blog entries into giant lists, because HTML already provides an excellent outlining method… the use of headings! (h1, h2, etc.) Use of lists would be redundant.
If each blog entry title is put into a heading tag, why couldn’t assistive-technology make a “skip to next heading” or “skip to next heading of the same level” functions? Why water down the effectiveness of lists.
Yes, many blogs could be pure lists, but many are in fact long narratives organized by date. Would you put the text of Lord of the Rings or of The Diary of Anne Frank in a list?
I’m a little late on this one, but something seems to have escaped mention. That is: there seems to be an unchallenged assumption in the “internal debate” here that lists are somehow inherently “vertical”. This is a list, too: one item, another, and another.
I think the ALA “Taming Lists” article does deal with this, i.e. using CSS to semantically structure *inline* lists using ul or ol. So, why is there a view here that ul is “fine” for sidebar navigation lists, but not for horizontal top nav lists? This seems to be an artefact of HTML’s default styling of ul as a vertical, bulleted thing - this in itself is a narrow interpretation of the concept of a “list”, and it seems to have deeply affected our perception of lists on the web (understandably). The great thing about CSS is, it gives us the tools to liberate us from the preconceptions built into default HTML visual rendering (sorry, stating the obvious there a bit!).
I guess the issue comes down to people browsing CSS sites with old browsers, who see what they might have expected as a horizontal top nav as a vertical list. (I assume this isn’t an issue for screen readers: they just read list items out sequentially, and the visual axis aspect has no bearing - a good way of thinking to release from the “vertical = list” assumption.) Again, this is contestable - horizontal main nav *is* a widespread convention, but there are sites with top-level links down the side.
Anyway, I’ll stop there as I guess this is an old debate without much steam in it - just thought this aspect needed to pop its head up here :)
Comments no longer open for this entry.