September 2003 Archives

Accessible Image-Tab Rollovers

Posted at 11:40 AM

I recently implemented a new navigation system for Fast Company and thought it’d be useful to document the process.

The Problem

We needed to fit more items into FC’s top navigation. We ran out of room. Previously, this was handled by a simple, styled unordered list. But at a window resolution of 800x600 there wasn’t enough additional horizontal space to add even one more item using the current design.

The Solution

I choose to combine and modify Pixy’s brilliant Fast Rollovers and Stuart Langridge’s accessible image replacement technique to create accessible, Javascript free, image-tab rollovers.

How does it work?

The XHTML: One List to Rule Them All

I wanted to continue to use a simple unordered list for the navigation in the markup. Much has already been said about using lists for navigation, here and elsewhere. They’re compact, lightweight and accessible to text browsers, screenreaders, PDAs, phones, etc.

Here’s what the list looked like originally (I’ve deleted some of the actual items to make it more convenient to demonstrate):

<ul id="nav">
<li><a href="/" class="selected">Home</a></li>
<li><a href="/guides/">Guides</a></li>
<li><a href="/magazine/">Magazine</a></li>
<li><a href="/articles/">Archives</a></li>
</ul>

Nice and simple. Now let’s add a unique id to each li so that we can do some fancy stuff with it (namely, replace the boring text with stylized tabs):

<ul id="nav">
<li id="thome"><a href="/" class="selected">Home</a></li>
<li id="tguides"><a href="/guides/">Guides</a></li>
<li id="tmag"><a href="/magazine/">Magazine</a></li>
<li id="tarchives"><a href="/articles/">Archives</a></li>
</ul>

Now we’re ready to create some tab images.

One Image, 3 States

The essence of Pixy’s Fast Rollovers involves creating one image for each navigation item that includes normal, hover and active states stacked on top of each other. Later, we’ll use CSS to change the background-position to reveal each state at the appropriate time.

Figure 1.1

Figure 1.1 on the right shows an example image that I’ve created and used for Fast Company’s new navigation. Each state is 20px tall with a total image height of 60px. The top 20px is the normal state, the next 20px shows the hover state and final 20px shows the active state (which is also used for the “you are here” effect). There are similar images for each tab we’d like to use.

Using one image for each state allows us to toss out ugly Javascript and instead make use of simple CSS rules for hover effects. This is good. It also eliminates the “flicker” effect that other CSS methods suffer from, where separate on/off images are used. This is good. We also don’t have to pre-load any additional images. Again… this is good.

The CSS: This is Where the Magic Happens

First we’ll set up the rules that all navigation items will need. This will save us from writing duplicate rules for each tab. Then we’ll add a separate rule for each list item id, giving the li it’s own background-image and width — the only two variables that will be different for each tab.

The CSS goes something like this:

#nav {
	margin: 0;
	padding: 0;
	height: 20px;
	list-style: none;
	display: inline;
	overflow: hidden;
	}

#nav li {
	margin: 0; 
	padding: 0;
        list-style: none;
	display: inline;
	}

#nav a {
	float: left;
	padding: 20px 0 0 0;
	overflow: hidden;
	height: 0px !important; 
	height /**/:20px; /* for IE5/Win only */
	}
	
#nav a:hover {
	background-position: 0 -20px;
	}

#nav a:active, #nav a.selected {
	background-position: 0 -40px;
	}

This essentially turns off padding and list styles, makes the list horizontal and hides the text that’s between each hyperlink in the list. Notice the :hover and :active rules. These are generic for every a element within #nav so that we don’t have to repeat those particular rules for each item.

I’ve also assigned a “selected” class to a tab that I wish to highlight permanently, signifying which section of the site you are currently on. This is shared with the :active state.

You may also notice that list-style: none; and display: inline; are repeated in both the #nav and #nav li selectors. This was to keep IE5/Win happy. In a perfect world, declaring this once for #nav would be perfectly sufficient. That’s not the case, of course.

Next, we’ll add the rule for each id and assign it’s background-image and width. Here’s an example:

#thome a  {
	width: 40px;
	background: url(home.gif) top left no-repeat;
	}

There’s a similar declaration for each tab needed.

The Results

Figure 1.2

Figure 1.2 shows the resulting tabs in normal, hover and selected state. To see it all working in action, check out the working example with sourcecode, or better yet, the real-world implementation at fastcompany.com.

Why use it?

• It’s lightweight: Just an unordered list in the markup.
• It’s accessible: Using Stuart’s method, we can insure screenreaders will read the text links.
• No Javascript: We don’t need to pre-load or create multiple images for each state. We also don’t need extra Javascript to control hover effects. Thanks, Pixy.
• It’s stylized: Fitting hypertext into defined areas can be tricky, this allows for using stylized images.

But Wait, the Text Doesn’t Scale!

Following a great suggestion from Doug Bowman, and in response to legibility issues and the inability to resize image text, I went a step further and created second set of tab images with larger text labels. I could then override rules on the exisiting “medium” and “large” alternate stylesheets. The alternate styles are activated using Paul Sowden’s Stylesheet switcher.

An example of the overriden rule looks almost identical to the original, with a new width and image path:

#thome a  {
	width: 46px;
	background: url(guides_lg.gif) top left no-repeat;
	}

Figure 1.3

Figure 1.3 shows the larger tabs as they appear on Fast Company, where you’ll notice that the horizontal spacing is tighter while the vertical size remains the same as the original. But, by adding the ability to increase the size of hypertext as well as the tab images we’ve helped out low vision users, while still working with our certain design constraints. Thanks to Doug for this solution.

Compatibility

Tested and working in Windows: Mozilla, Netscape7, IE5.0+; Mac: Mozilla, Camino, IE5, Safari.

Specifically for Fast Company, I choose to position: absolute the #nav in order to make things line up perfectly, letting the background color of the header area show through underneath. This works fine and dandy — except in Opera7/Win where specifying a width is necessary for absolutely positioned elements (ugh). That’s OK though, we’ll just add the total width of the images (added up) to the #nav:

#nav {
	margin: 0;
	padding: 0;
	height: 20px;
	list-style: none;
	display: inline;
	overflow: hidden;
	width: 201px;
	}

Now we can sleep at night, and Opera fans rejoice.

Special thanks to Paul Maiorana for letting me bounce ideas off of him (repeatedly) at the office.

96 Comments

About the Talking About Semantics

Posted at 11:18 PM

I feel the need to take a time-out and regroup in regards to the SimpleQuiz.

What’s the point in arguing about semantics? XHTML is not a semantic language.

I agree — it may never be a purely semantic language. I sort of wished I had never used the word “semantic” in the questioning of the quizzes. What we’re trying to get at here is whether one method of markup has any benefits over another. That’s it. Call it semantics, call it preferred methods, call it advantages and disadvantages, etc. The bottom line is that talking about this stuff (as mundane and ridiculous as it can get) can be beneficial.

Sure, at times we’re all splitting hairs and to some it may seem like an absolute waste. But, call me crazy, it’s fun talking about the million different ways to markup a list or a form or a heading — and hearing how others may do it differently. I also hope to broaden the questions to handle CSS methods and tricks.

So, the intention is to question the whole idea of semantics, when they’re helpful or when they ain’t — not to preach some “golden way” of writing web pages. I’ll be the last to want to adhere to a single way of marking up XHTML. Sometimes, a tag is a tag is a tag, and instead of worrying about what’s right we should go outside and toss the football around (or kick the football around for all you non-Americans).

Allright. Had to get that off my chest. Now back to work. The next quiz will be on how XHTML files with odd numbered byte sizes are more semantically correct. (Just kidding).

8 Comments

SimpleQuiz › Titles › Conclusion (sort of)

Posted at 11:48 PM

Where do I begin? This one has no obvious answer, and didn’t really intend to. In fact, very few of these questions really intend to have a definitive answer. And the following is my attempt to absorb the illuminating comments (and they are always illuminating) and make some sense of them.

Let’s get right to it. Book titles. Right. The title of a book. Think about seeing a book title in print — in a magazine or another book. A book title is normally set in italics. It’s a visual clue. It’s strictly presentational. Now think about a book title on a web page. We still want that visual clue — italics, but we also want all browsers and devices to know that this is a book title as well.

Moby Dick. I just used i. Is that any good? Well, using i is strictly presentational, it’ll give us the italics we want, which is good. But:

The only real difference is that i’s nomenclature disregards all but visual browsers. (full comment)

When using i, visual browsers will render the book title in italics, but others may not.

Looks like B is out.

But non-visual browsers will recognize em you say? Great! But, do you really want the the title of a book to be emphasized (read faster and/or louder)? Probably not, so A is out — although I’m plenty guilty of using it.

So what about cite? Many dispute the relationship of cite in regards to a book title — if you’re simply stating the title of a book, are you really citing it? I suppose I could go either way on that one. One could argue that you are, in fact, citing the book title even when stating it without following quotations. cite also has the benefit of being rendered in italics in most (?) browsers — by default and without additional CSS rules. How many I could not tell you definitively, and that would be an interesting tidbit of information.

A fourth option would be to create a custom class and attach it to the span tag such as <span class="title">This is a Book Title</span>. But this to me is the same as using i — strictly presentational and if you wanted to be hilariously ridiculous you might point out that it would cost you a few more bytes for the span tag and associated CSS rule. Silly, but…

So the moral of this quiz question is: use one of the four methods and move on. Each of them has their respective advantages and drawbacks. Take those into account in the real world, make a choice and feel good in knowing that you may have some extra information on why you made it.

16 Comments

SimpleQuiz › Part VIII › Titles

Posted at 11:18 PM

With this question (based on a suggestion by Shaun Inman), I’m hoping the discussion touches on a few different things that happen to be going on.

I’ll leave it at that for now, and let you all weigh in.

Q: When marking up a book title or publication, which of the following is the best choice?

1. <p>My upcoming book, <em>SimpleQuiz: Get Down With Markup</em>, will be a bestseller.</p>
2. <p>My upcoming book, <i>SimpleQuiz: Get Down With Markup</i>, will be a bestseller.</p>
3. <p>My upcoming book, <cite>SimpleQuiz: Get Down With Markup</cite>, will be a bestseller.</p>

78 Comments

SimpleQuiz › Order Up › Conclusion

Posted at 9:43 PM

Looking over the comments from the question, it appears that most saw either A or B as semantically equal. Adam Polselli brought up an interesting point though on a possible benefit to choosing option A:

I think that there’s an advantage to using A. If you style your links as “font-weight: normal”, then having the <a> tag inside the <strong> tag would override <strong>’s “bolding.”

Certainly that is something to think about, even when either order would work for you.

Good arguments were presented for either method, with some pointing to whether the link itself needed strong emphasis or just the text contained.

I’ll admit, I’m feeling a little lazy with writing this wrap-up — not because the discussion for this one was any less illuminating, but because there were many, for lack of a better term, thought provoking comments making a case for either order. Just read through these. Class dismissed.

Read all quiz questions and conclusions.

8 Comments

Copy Protection? Boo.

Posted at 8:22 PM

I’ve just purchased The Darkness new album, Permission to Land — it’s a great one, conjuring up rock’s past masters of the late 70s and early 80s. We’re talking Journey, Boston, Foreigner and Loverboy here.

Anyhow, the band is beside the point — this was the first CD I’ve purchased that has some sort of bogus copy protection built into it. Crap. Now I can’t play it on my Mac and I can’t rip it to live on my iPod. Ridiculous. There was no warning on the packaging about it being copy protected. Now I’m not sure of what to do with it. Return it? Then I have no way of listening to the 100% pure rock of the Darkness.

Has anyone else run into this dilemma?

47 Comments

SimpleQuiz › Part VII › Order Up

Posted at 11:41 AM

This quiz focuses on element ordering, and is based on a suggestion from Paul Smith. When hyperlinks are coupled with inline phrase elements (such as strong, em, abbr, etc.) are there any consequences in regards to the ordering?

Q: Which of the following is more semantically correct, and are there advantages to either method?

1. <a href="http://www.simplebits.com/"><strong>The Greatest Web Site Ever</strong></a>
2. <strong><a href="http://www.simplebits.com/">The Greatest Web Site Ever</a></strong>

35 Comments

List-o-matic: It's Just Too Easy Now

Posted at 9:55 AM

Ian Lloyd over at Accessify.com just made creating CSS-based navigation lists incredibly simple.

List-o-matic (not to be confused with it’s excellent inspiration, Listamatic) is a wizard for quickly creating unordered navigation lists, while allowing you to choose from a few different CSS styles, such as my Mini-Tabs and others.

Enter a few link names and URLs, choose a style and … bingo. You have yourself some styled navigation. It doesn’t get any easier than this.

Oh, and YARRR!

13 Comments

SimpleQuiz › Form(atting) › Conclusion

Posted at 10:59 PM

This was a tough one to wrap up. There are probably more acceptable possibilities with this question than with previous questions. A lot of great examples were brought to light regarding label and fieldset elements.

Notable Comments

Simon Willison:

…once I start working with forms I switch my focus from semantics to accessibility and usability.

Excellent point. It’s always good practice to ask yourself whether you’re being semantic for the sake of being semantic. Have I mentioned that I don’t like the actual word “semantic”? I don’t.

Keith:

I don’t really consider a form label and text field a paragraph so that’s out.

This was echoed through the rest of the discussion as well. However, it just might give you better results in the nonstyled version (as opposed to using a div or label or nothing).

And while using nothing might not appeal to you, MikeyC pointed out that it will not validate without a block-level element surrounding the label.

Which brings us to using fieldset, which Dave S. first suggested. The use of fieldset opened the floodgates on a host of great examples, and for simple small forms, fieldset and some CSS applied might be all you really need.

The use of fieldset was also argued a bit, back and forth. On one hand, you could see this as purely a presentational addition, and on the other hand you could quote the W3C:

The FIELDSET element allows authors to group thematically related controls and labels. Grouping controls makes it easier for users to understand their purpose while simultaneously facilitating tabbing navigation for visual user agents and speech navigation for speech-oriented user agents. The proper use of this element makes documents more accessible.

I like the sound of that.

You can’t talk about forms without talking about using table to format them. Paul G.:

… it ensures that labels and inputs maintain a logical visual order and layout when CSS is off

Certainly for larger forms, when you’re dealing with multiple controls, inputs, form fields, drop-downs, etc. — tables still seem like the best way to go. You could argue either way, whether a form is tabular data — but the truth is, styling a large form soley with CSS is not a simple task, and undoubtedly will not degrade nicely.

Summary (my take)

When it comes to marking up forms, I’ll take the following into account:

• When marking up a small form with a few elements, I’ll use fieldset and CSS to style them — taking into account what the unstyled form will look like.
• Tables still are not evil. For large forms, in order to make the form useable and organized, it’s hard to beat the simplicity of a table here. CSS techniques seem to be somewhat complicated in a place where a simple table would work all around.
• In the past, I’ve used p tags to group label and matching input tags. I’m now divided on this method. For simple forms, it will ensure consistent formatting across browsers yet could be argued that it is not a paragraph of text.
• Trying to semantically structure a form makes my head hurt.

See all quiz questions and discussions in chronological order.

11 Comments

SimpleQuiz › Part VI › Form(atting)

Posted at 7:29 PM

Let’s talk forms. A lot my web design headaches are caused while formatting form items. This quiz question comes to us from MikeyC:

Q: When marking up forms, which is more semantically correct when separating form items?

1. <form>
<p><label for="name">Name:</label>
<input type="text" id="name" /></p>
</form>
2. <form>
<div>
<label for="name">Name:</label>
<input type="text" id="name" />
</div>
</form>
3. <form>
<label for="name">Name:</label>
<input type="text" id="name" /><br /><br />
</form>

See all previous quiz questions and wrap-ups.

53 Comments

SimpleQuiz › Site and Page Titles › Conclusion

Posted at 8:59 PM

This question was probably the most vague — and there certainly wasn’t a clear-cut right or wrong answer. But that’s why I like it. I enjoy hearing what others think about the relationship of the title and h1 tags.

Notable Comments

Many agreed that ceejayoz’s example was the best-case scenario, which was most like answer A:

<head>
  <title>Widget Co, Inc. | List of Widgets</title>
</head>

<body>
<div id="logo">
  Widget Co, Inc.
</div>
<h1>List of Widgets</h1>

I think I’m with ceejayoz here, and it’s certainly closest to what I’ve used in the past.

Egor Kloos:

H1 is a heading and isn’t a logo. A logo isn’t a Title and also isn’t a Heading. … A logo or even just a company name is not just a line of text, it is part of a companies assets. Treating it like it is a Title or heading and putting it in a H1 tag is a mistake…

Good points on a logo not being a heading.

Matthew Haughey:

Why put the same exact thing in an H1 on every page, making search engines think it’s the most important thing on the page, when it’s mostly just eye candy?

Search engines weigh h1 heavier than h2. Putting only the company name in there might be a waste.

Michael Z.:

But in terms of your page’s hierarchy, the <title> is like an <h0> that’s applied to the <html> element. Why repeat its content in your <h1>?

I like the h0 metaphor.

Dan R.:

How I would do it today:

<html>
<head>
<title>Page Title | Company Name or SiteName.com</title>
</head>
<body>
<div id="logo">
<p>Company Name, replaced by Logo graphic using FIR (or related technique)</p>
</div>
<h1>Page Title</h1>
<h2>Subheading</h2>
<p>Content</p>
</body>
</html>


A nice, complete example — and I agree with it all.

Summary (my take)

Here’s what I think, after hearing from you highly esteemed readers:

• The title tag should contain the page and site title.
• The logo doesn’t need to be a heading, and may live nicely in a div where it could be replaced with a background graphic using CSS.
• h1 should be the title that most completely describes the document as a whole. This may or may not include the site title (again).

In the past, I have sort of tried to adhere to that. But going forward, this seems to make sense in an ideal world.

13 Comments

SimpleQuiz › Part V: Site and Page Titles

Posted at 11:28 AM

Our first reader-submitted quiz question from Thomas Lackner:

Q: Which is more semantically correct for a corporate web site (that does not require an image-based logo)?

1. <div id="logo">
Widget Co, Inc.
</div>
<h1>List of Widgets</h1>
2. <h1>Widget Co, Inc.</h1>
<h2>List of Widgets</h2>
3. <head>
<title>Widget Co, Inc.</title>
</head>
<body>
<h1>List of Widgets</h1>

This was touched upon in the comments of the first question, but I think it would be interesting to get people’s opinion of what a best case scenario would be for the beginning structure of a document. Obviously, logo graphics play a part in most corporate sites — but we’re strictly talking page structure here. Thanks to Thomas for sending this in.

32 Comments

Bananaphone and New Sidebars

Posted at 2:04 PM

A few days ago I brought a banana with me to work and subsequently forgot that it was in my bag. Later, when I rediscovered it on the way home, I had a funny thought. What if I pretended to talk into the banana like I was on a cell phone while walking through the train station. A real conversation — and something possibly a bit louder than normal, like:

“Yeah… The McDougal file is all sorts of messed up. Smitty from accounting entered some bogus numbers on the DL5 forms… Right… We’re screwed! Listen, I gotta go, I’m about to get on the train…. Right… see you tomorrow.

The key is to make it a legimate conversation without cracking a smile. I didn’t actually try it, of course. I guess you’d have to be there.

New Sidebars

You may have noticed the new color sidebars. Thought I’d add some definition over there. If you liked the minimalism of the old-school sidebar — don’t worry. The third icon under “Switch Theme” will bring you back.

I’m still working out some final kinks, but for the most part things should be normal. I’ve found that longish pre statements cause the sidebar’s background to get stuck in IE6/Win. Longish pre statements seem to cause other problems in general. Maybe I should avoid longish pre statements.

Get ready for the next quiz question, coming soon.

Remembering

Posted at 4:32 PM

One year ago I wrote about seeing the year-old, worn pools of candle wax on my walk to the train every morning. It’s amazing, but they’re still there — 2 years later now. They are even more worn than last year, but still a constant reminder of the sad day and vigils that followed.

SimpleQuiz › When to P › Conclusion

Posted at 11:29 PM

This past question has brought up some rather interesting points. Many readers chimed in on the fact that option B was better (wrapping the content in a p tag) due to nice formatting for un-styled viewers. Others saw it unnecessary, and more saw it fit to strip away that redundant div and style a p directly.

Notable Comments

talon:

I consider div to be the “duct tape” of CSS - no semantic meaning, purely a wrapper for the grouping of block-level elements or for styling itself.

Michael Z.:

… if there’s a chance in a million that your boss will decide next month that there must be second paragraph of fluff in the footer, then go with B.

Now that’s forward thinking.

zlog:

What about <address>?

I hadn’t thought of it, but it’s a nice reminder.

jkottke:

… the responses in this thread are a good illustration of why “lorum ipsum” text should be used in such instances.

Heck yeah, and Ed Sharrer offers us the The Lorem Ipsum Generator.

Billy was the first to get at a major point I was attempting to make with this question:

Put the line of text in a p, set it’s id to “footer”, and get rid of the div.

Ah ha. Exactly. If this is just one line of text, why not add the id directly to the p tag itself? p is a block-level element as well, and div is just a generic one. A good way to trim down that code: Look at what lies directly beneath your div tags. If it’s another block-level element, look into styling that next level — directly.

For instance, if you have a form that is wrapped in a div, it may be possible to get rid of the div and let the form be the block-level element.

Oh, and extra credit goes to Doug Bowman:

I’d say the Charles DeMar he’s referencing has to do with these three words: Better Off Dead.

Right on the money.

Summary

One line of text within a div could be marked up with a paragraph, without one, or tossed out in place of styling the p directly.

Some considerations:

• Think about the future. Will this one paragraph likely turn into two or three? Maybe it’s best to use a div.
• If it’s always going to be one, why not bag the div and add the id to the p tag itself?
• Look into using address for … well, addresses.
• If you choose not to wrap a single line in paragraph tags, will this be ok for un-styled viewers?

See all past quiz questions and wrap-ups in chronological order.

12 Comments

SimpleQuiz › Part IV: When to P

Posted at 10:54 PM

Looking back, we’ve covered a lot of ground with just three questions, haven’t we? I realize I could go on for a dozen more questions about lists — different combinations, ordered lists, etc. I could also ask questions that are either too obvious for most, or delve too far into details for others.

So instead, here’s another topic that could just be splitting hairs again. The set-up: You have a block of text that you’re wrapping in a div (or any block-level element) and it contains just one paragraph or string of text. Note: the text used in the example is arbitrary.

Q: Are each of the following acceptable, and why (or why not)?

1. <div id="footer">
      Copyright 2003 Charles DeMar | This text is arbitratry.
   </div>

2. <div id="footer">
      <p>Copyright 2003 Charles DeMar | This text is arbitratry.</p>
   </div>

Extra Credit: Who is Charles DeMar?

55 Comments

SimpleQuiz › Heading and List › Conclusion

Posted at 3:48 PM

This question was intended to divide the results more so than the first two. While there isn’t much context included with the examples, I think what I got out of the discussion that followed is that either method is good depending on the situation.

Notable Comments

Robbert Broersma:

“I choose A, ‘cause a definition-list consists of a term and a description. “Robots” is not a description of the term “A List of Stuff”.”

While this is true, others defend the use of a definition list for other applications, later in the discussion.

Dave Shea asks:

“…what constitutes a term/definition pairing? Is the term a word, can it be a phrase, can it be an image?”

A good question, and again I think is cleared up somewhat later on.

Anne van Kesteren:

“How about nested lists?”

Nested lists can certainly be useful as well, as an alternative.

Doug Bowman pretty much writes the wrap-up for me here:

“… My answer: ‘C’: depends.”

And after quoting an important sentence from the W3 specification for dl:

Another application of DL, for example, is for marking up dialogues, with each DT naming a speaker, and each DD containing his or her words.

“Clearly, there are uses for definition lists far beyond the traditional term and description.”

Doug goes on to give some good examples of definition lists with multiple descriptions — creating relationships between terms and multiple descriptions. A nice example of using a defintion list for more than just term/description pairs.

Summary

Defining lists with section dividers (I’ll refrain from using the the term “headings” here) has unlimited possibilities. Using the right combination depends heavily on the context. Some things to keep in mind:

• Definition lists can not only be used for strict term/description pairings, but also for grouping separate lists together that are related.
• Since search engines treat heading tags with greater importance, that should factor in your decision on whether or not to use them. (The W3 spec prohibits block-level elements within a dt.)

See all quiz questions and wrap-ups in chronological order.

4 Comments

SimpleQuiz › Part III: Heading and List

Posted at 11:58 AM

This one might divide the answers a bit, and is surely something I’d like to know people’s opinion on. It could, however, be just splitting hairs. Is there really a big difference? Does it really matter or is it six and a half of one, half a baker’s dozen of the other? If so, we’ll move right along to the next question.

Q: Which of the following is more semantically correct?

1. <hn>A List of Stuff</hn>
   <ul>
   <li>Robots</li>
   <li>Monkeys</li>
   <li>Vikings</li>
   <li>KitKats</li>
   </ul>

2. <dl>
   <dt>A List of Stuff</dt>
   <dd>Robots</dd>
   <dd>Monkeys</dd>
   <dd>Vikings</dd>
   <dd>KitKats</dd>
   </dl>

See all quiz questions and wrap-ups collected in order.

43 Comments

SimpleQuiz › A List › Conclusion

Posted at 9:45 PM

This was another easy one — but as expected the discussion got more interesting as additional related questions were asked. The question itself is becoming secondary to the conversation happening alongside.

Notable Comments

Overwhelmingly, it was D all the way. I guess I sort of gave it away, orginally titling it “Part II: Unordered Lists”. We’ve learned some good stuff here though.

web:

Yeah, I’d go with D as well, but to be noted is the lack of KitKats in your list.

Dully noted.

Michael Z.:

There are a few situations where code like A could be used, though. Marking up a poem, for example.

Which prompted others to ask about using pre or br / to markup a poem. Tough to call, and even the W3C uses a poem as an example of both methods.

Folkert:

Did anyone ever fall into the trap of identifying every bit of content on a page as a list, ordered and unordered? I was that close to declaring the bodytext on a page as an inline ordered list.

In fact, Doug Bowman pointed me to Tantek Çelik’s move to using a series of lists to handle most of his weblog’s structure.

Also certainly worth a look again, is Doug’s Overused Lists? article — where he explores the differences between using pipe-delimited vs. an unordered list for navigation. The pipe-delimited method could’ve easily been option E in this quiz question, and may have divided the results a bit.

Michael Z.

I think even one item can constitute a list.

And according to the W3C, this is true.

Paul G.:

You’d have to change the stylesheet and the markup if you wanted to do something as simple as add a border around your list.

Exactly. Using a ul makes it easier to change styles with CSS.

Matt Haughey poses some questions that are far more intriguing than the quiz itself:

When should someone put something in a list instead of using line breaks? How to do screenreaders interpret lists?

To which Patrick H. Lauke responds with perhaps the most insightful information of the discussion:

… yes, they do treat lists differently from normal text broken up by line breaks. JAWS, for instance, announces that it’s an “unordered list with 5 items”. I imagine other screenreaders will provide similar information.

That to me, is a huge reason for using lists when in doubt. And after being asked whether the declaration of how many list items there are would be a hinderance to blind users, Patrick went on to offer this:

… they will know how many links there are (i.e. whether it’s only 5 items or 50), which will influence how they will choose to navigate the site.

I realize I could go on quoting everything else — because there are other great points raised as a result of another seemingly ELEMENTary (sorry) question.

Summary

A simple list of items should most likely be structured with a ul element. Why is the better way?

• D is more easily styled with CSS without having to modify the markup.
• Using a ul to markup lists makes it easier for screenreader users to hear how many items are contained.
• An unordered list may be better represented in a small screen such as a phone or PDA — where unintentional line-wrapping may occurr.

8 Comments