SimpleQuiz › Part XV: Numbered List Pairs

compuwhiz7

I’d pick B, because it reflects the relationship between the title and the description, and separates them accordingly.

For example, you could have done this:


<ol>
  <li>
    <h2>
      First Step Title
    </h2>
    <p>
      First step description goes here.
    </p>
  </li>
</ol>


(You could have used h3 or any other, too.) The trouble with that is that it doesn’t really convey the relationship nearly as well.

So I choose B. :D

Nick Finck → www.digital-web.com

Semantically speaking, I believe B is the truest form. However I find myself doing things similar to A. The issue of separate styling, as you suggested in bold, is a bit more complicated. You could use a browser-specific hack such as first-line, but the more universal approach is to use spans. What a cluster f#@k, eh?

Keith → www.7nights.com/asterisk/

I think this one is a bit tricky. I think it depends on which, given a particular situation, is more important — an ordered list, or a title and definition pair.

You could go with A or C based on the want to go with an ordered list, or you could go with the definition list option of B if you wanted to have that relationship between the title and definition.

I think it depends on what your list actually is.

So…I would go with either A (as I prefer it a bit to C) or B depending on wether or not the description was actually a definition or not.

Ben → www.blowery.org/

Of those options, I would go with C. I think it communicates the intent of the list best while still letting you style the list in a fairly safe manner.

I really like the look of option B, but I don’t think you’re really going for a term / definition relationship with a list of steps. It feels more like an ordered list to me.

Option A just seems ghetto with that line break in there. :)

If I had another option, I would take C and put the step title into an h4, possibly with a “stepTitle” class though that’s not strictly necessary with selectors.

pjm → www.flashesofpanic.com

I’d choose “b”, but without the numbers; then I’d use a CSS-2 auto-number to put the numbers in the dt containers, so I could shuffle the list without manually re-numbering.

Then I’d get disgusted that only one browser would show my numbers, and go back to hand-numbering them.

Eric → www.arkitrave.com/log

There is no right answer.

It is a difficult question because any markup language has the task of anticipating every possible combination of needs the user will have, and none can do it perfectly.

I don’t like “A”. Breaks are weird, and don’t convey any relationship between the two parts of the dialogue - which is really most equivalent to a term and a definition.

“B” is great, because it the scenario you’ve described is really a definition list, and the code allows for a relationship of descriptor-description. However, the numbering thing throws a wrench into the equation. Numbering like “B” is not only non-semantic and ugly, it is totally inconvenient moving into the future, where every number would have to be changed to accommodate one insertion at the start of the list. That is why ordered lists were invented. The UA should do the numbering.

For these reasons I have to cast my vote for “C”. While some of the beauty of the definition list relationship is lost, a relationship is still described between the two parts - list item and descriptive paragraph. The numbering is automatic, which is much easier code to maintain.

I am an almost obsessive proponent of definition lists, but this is one place I just don’t think it works. The numbering issue trumps the dl for me.

Ben H → www.neuronwave.com

I would use option C. It degrades nicely and styling is fairly straightforward. But them I’m only starting with CSS.

Bruce

I’d go for:

<ol>
  <li>
    <strong>'Heading'</strong>
    <p>Description</p>
  </li>
  <li>
    <strong>'Heading'</strong>
    <p>Description</p>
  </li>
</ol>

Obviously, strong is an inline element but that doesn’t bother me too much. If it bothers you, my second choice would be a <h[1-6]>.

Steve Smith → www.orderedlist.com

For a short list, it would be easy to edit the numbering, but in a long list, adding or deleting an entry in the middle would be a nightmare. I’d combine the definition list with the ordered list like this:


<ol>
  <li>
    <dl>
      <dt>First Step Title</dt>
      <dd>First Step Definition</dd>
    </dl>
  </li>
  <li>
    <dl>
      <dt>Second Step Title</dt>
      <dd>Second Step Definition</dd>
    </dl>
  </li>
</ol>


It might be a little heavy on the code side, but to do it correctly with easy updating, I would recomend it.

Nicolas Hoizey → www.gasteroprod.com/

What about this one :


<ol>
  <li>
    <dl>
      <dt>First Step Title</dt>
      <dd>First step description goes here.</dd>
    </dl>
  </li>
  <li>
    <dl>
      <dt>Second Step Title</dt>
      <dd>Second step description goes here.</dd>
    </dl>
  </li>
</ol>


Not as simple as the others, but it has the advantage on the B solution to allow you to change the order without renumbering…

Steve Smith → www.orderedlist.com

Nice thinking, Nicolas.

Nicolas Hoizey → www.gasteroprod.com/

Arf, I had problems to make it look as intended during almost 10 minutes (why does <pre> not work?), and then Steve posted before me … ;)

Thomas Baekdal → www.baekdal.com

Option B (without doubt)

- and I would include the numbers

BTW: You could do this (it is supported by most browsers, but not standard-compliant)

<ol>
<li>
<dt>First Step Title</dt>
<dd>First step description goes here.</dd>
</li>
<li>
<dt>Second Step Title</dt>
<dd>Second step description goes here.</dd>
</li>
</ol>


Notice: Similar to Steve and Nicolas examples - although the browsers will render it without the numbering - so you add code without with getting a result. Leaving out the DL part will fix this (breaking the standards while doing so).

web → www.ericwebster.net

I’m with Nick and Steve on this one and at first glance I thought that’s what B was.

It establishes a relationship between the steps (the OL) and then defines the data inside the list well too.

Only questionable practice is the use of a DL for one DT .. But I can have a list of one thing.

Thomas Baekdal → www.baekdal.com

hmmm… Come to think of it. I would go with this:


<ol>
<li>
<h1>First Step Title</h1>
<p>First step description goes here.</p>
</li>
<li>
<h1>Second Step Title</h1>
<p>Second step description goes here.</p>
</li>
</ol>


And it validates XHTML strict

Rimantas → rimantas.com/

Tough one. B looks the best at the first sight, but then…
It all depends how do you look on this, and you can have at least those looks:
a) list of steps,
b) step title - step content pairs
c) mix of both.

I don’t like A - BR’s and no P’s — no good.
C is a better variation, but still version suggested by compuwhiz7 is better - if you have title, use Hx for it. I can really imagine doing this for real project.

On SimpleQuiz I always try to imagine, how this will look without any CSS applied, only default rendering.
In that case compuwhiz7 solution looks the best. He states the problem too - not as pronounced relationship as in B, but still - you have your title and your step description in the same LI, that’s not bad.

Having to choose from not modified versions I’d go with B. All - A,B,C are flawed by not using Hx for titles, so B does the best job in unstyled version - step descriptions would be intended to the right, and titles would stand out.

Versions by Steve and Nicolas are tempting too, but those are too verbose and no header tags again…

Thus - modified C or B if modification is not allowed.

jason stanfill → www.jasonstanfill.com

at first glance I would go with b because it properly conveys the relationship between the title and description, but long term (thinking about maintaining such a beast) the numbers lead me to think the previously suggested “modified c” (putting the title in an h tag) is the way to go.

Chriztian Steinmeier → steinmeier.dk

I’ll take C, mainly because of the T-shirt but probably also because of lack of an option using heading tags for the… erm… headings. :-)

Andrew → www.mooncalf.me.uk

I think before you make any decisions on markup, you have to decide what your priorities are when displaying the list.

Is your primary intention [1] to display a numerically ordered selection of items, which happen to be terms and definitions? Or are you [2] trying to convey some sort of title/explanation arrangement, which you would also like to be in some sort of defined order?

If the case is [1], then I guess something like A would be the most appropriate. If [2], then B would be the better option.

However, I think I’d have to go with Steve and Nicolas if you wanted to have both properly combined. Although the code is a little bloated compared to the other options, it does correctly define a numerically ordered list of terms and definitions.

Andrew Dupont → www.dailytexanonline.com

I like using dls a lot, but in situations where auto-numbering is essential, they’re just not worth it.

So let’s look at option C, which I use sometimes. There are two issues:

(a) Is the markup semantic? Yes — the meaning behind the markup is clear (arguably moreso than in a dl.)

(b) Is it easily style-able? Yes, since you can target li and the li p separately. (That’s the advantage it has over option A.)

Nonetheless, I like Thomas’s comment about using headings. The goal here is to have at least one block element inside that li; that way you don’t need a line break. So this option is just as plausible as option C.

Plus, if you use your headers correctly, the outline of the document degrades nicely for Googlebot, screen readers, and the like. (I love looking at the outline of my document with the semantic data extractor.) Googlebot pays attention to headers, and since the “title” of each item in the list acts as a summary of the text that follows, I’d want to convey that enhanced importance by using a header tag.

So I’d recommend using a modified option C, using either an hX or an hX and a p within the li.

Thomas Baekdal → www.baekdal.com

Andrew, I cannot take credit for the “headings” idea - it is a variation of compuwhiz7’s example.

Xian → xian.mintchaos.com

I mostly agree with Bruce. Except I don’t think the descriptions need separate paragraph tags. The <strong> tags can simply get display:blocked.

That said. When doing this in a hurry I useually just throw in the <br />s.

<li> <strong>'Heading'</strong> Description </li> <li> <strong>'Heading'</strong> Description </li> </ol>

If I had multi paragraph descriptions then I’d go for tags for the headings and <p> tags for the description paragraphs.

Jack Brewster → www.maxgeek.com

In theory, I like Steve/Nicolas’ suggestion, but as pure, unstyled HTML, IE renders it poorly by not putting the <dt> on the first line of the <li> (checked in IE6/5.5/5/4) and looks like this:

1.
  First step title
    First step description
2.
  Second step title
    Second step description

Amusingly, IE6 (but not the earlier versions) also drops the first line number but not the blank line. I’m pretty sure that’s a reported bug, but can’t think of a reference at the moment.

Of course, Moz renders this nicely, as does Firebird/fox and Opera. And since no one uses IE, maybe this isn’t a big deal. ;)

As for the recommendations to use <h#>, I don’t care for it because it doesn’t necessarily convey a relationship. Also, if you’re concerned about properly nested headings within your document, you could have maintenance issues later (i.e. need to change all the <h3> to <h2>, etc.).

I like C. I think it meets the goals of auto numbering and showing a relationship (all in one <li>). The code is also easy to maintain.

Xian → xian.mintchaos.com

*sigh*

Sorry about that mess. There was a ‘pre’ around all that. I even checked with the preview.

sgb

I’m new here, go easy on me. I would have to go with C.

If you’re dealing with a numbered list (as many have pointed out) you’ll want to use the structure that describes a numbered list.

In this situation the title is really an extension of the numbering. This implies that each description paragraph is a child of a list item:


<ol>
<li>
First Step Title
<p>First step description goes here.</p>
</li>
<li>
Second Step Title
<p>Second step description goes here.</p>
</li>
</ol>


“X Step Title” takes on the styling of the LI itself while the paragraph gets it’s own special “child” styling.

This minimizes markup and adequately describes the relationship between the paragraph and its title.

Joe Kaczmarek → JoeK.com/

I’m with Steve and Nick (a DL inside the LI).

Structurally, it is an ordered list, with each list item consisting of a definition title and a definition description. So the code should represent that.

Andrew Dupont → www.dailytexanonline.com

Andrew, I cannot take credit for the “headings” idea - it is a variation of compuwhiz7’s example.

Yeah, I noticed that right after I posted. Typical.

Kjell Olsen

I don’t understand why you would use something convulsed like a <dl> to show a list with titles and following paragraphs - as was mentioned earlier, why not just use a header and paragraph within the list item?

<ol>
<li><hn>title</hn>
    <p>description</p>
    </li>
</ol>

This is perfectly valid xhtml, and fits displays the topic title and information about that topic about as concretely as possible is html. How many of you would howl unsemantic if you saw each and every title on a page marked up with a <strong> tag?

Aaron Egaas → www.digitalphlame.com

I agree with the guys that said that <hx>’s and <p>’s should be used inside the <li>’s. Semantics don’t hold a candle to readability for me, and I can visualize headings and <p> tags easy in my head, while <dt>’s and <dl>’s get a bit unwieldy.

So I guess I chose D.

zinckiwi → www.zinckiwi.com

You’re all wrong.

<table border="0" cellspacing="0" cellpadding="0">
  <tr>
    <td>1.</td>
    <td>&nbsp;</td>
    <td><b>First Step Title</b></td>
  </tr>
  <tr>
    <td colspan="2"></td>
    <td>First step description goes here.</td>
  </tr>
  <tr>
    <td>2.</td>
    <td>&nbsp;</td>
    <td><b>Second Step Title</b></td>
  </tr>
  <tr>
    <td colspan="2"></td>
    <td>Second step description goes here.</td>
  </tr>
</table>


Micah → msittig.wubi.org/

It warms my heart to see so many people choosing the markup-heavy Steve/Nick solution. To a high degree I’m OK with the header-paragraph answer, but the relation between the title and text is nailed unambiguously by the definition list.

If this was a vote, though, and I realize it’s not, mine would go to zinckiwi because it’s the only entry that left me in stitches. Hey, it looks good to me.

Anne → annevankesteren.nl/

B. With the numbering part in CSS, since it I think it is presentation in this case. (And of course, this is more like a “perfect answer”, not an answer you cna rely on, since only Opera support CSS generated content that good.)

Tanny O'Haley → tanny.ica.com

I’m going to agree with sgb (25) and go with C.

“In this situation the title is really an extension of the numbering. This implies that each description paragraph is a child of a list item:”

Tommy → autisticcuckoo.net/

C, with the titles marked up as headings.

The main objective seems to be the order of the steps, so an <ol> would be reasonable. A heading (<h[1-6]>) is definitely related to the paragraphs that follow.

Nesting a <dl> inside each <li> means that the title is the definition of the description. Some screen readers will announce “equals” between the title and the description. If that makes sense to your one-item definition list, you’re OK. :)

Greg

I think the best for semantic and simplicity is B with CSS counter but what about :



First Step Title
First step description goes here.


Second Step Title
Second step description goes here.




Greg

Sorry :-[ it may be more readable like this :
<ol>
<li>First Step Title
<ul><li>First step description goes here.</li></ul>
</li>

<li>Second Step Title
<ul><li>Second step description goes here.</li></ul>
</li>
</ol>

Conspi → www.conspi.com

I personnaly prefer clean html markup and don’t like to add <Hn> or <p> into <ol> and <li> tags.

Modifying the Zebra tables script from ALA, i created a JavaScript which auto numbers <dl> <dt> 's as if they were <ol> <li>'s.

I don’t know if this is semanticaly correct, as i add a Javascript Function to simulate a tag with another one, but the source code remains really VERY clear:


<dl>
  <dt>First Step Title</dt>
  <dd>First Step description goes here.</dd>
  <dt>Second Step Title</dt>
  <dd>Second Step description goes here.</dd>
</dl>


The Javascript adds an incrementing number in front of each <dt> and a bit of CSS makes the appearance goes like this:


1. First Step Title
   First Step description goes here.

2. Second Step Title
   Second Step description goes here.


As my english and explanation are not perfect, i think an example will be much more easier for everyone :)

Neil

What I have done in the past is the following:

First Step Title First step description goes here. Second Step Title Second step description goes here.

And then in the stylesheet, simply set the li class “2” without a list bullet and set the appropriate margins so that it appears directly underneath the first line.

The only problems I have experienced with this was in Firefox where I had to set the margin from the left of the page slightly more than it would need in crappy IE.

François Briatte → phnk.com

A is obviously a dashed off job.

I guess B is perfect as far as semantics are concerned.

But then C is what I’d do by instinct.

Dave Meehan → www.orificeworld.com

Steve and Nick are closest in practical terms. There is a correct way, but unfortunately neither IE or Gecko browsers render it the way it was intended (they both get the numbering wrong). The solution should be (css then markup):-

dt {
display: list-item;
list-style-position: outside;
list-style-type: decimal;
font-weight: bold;
padding: 0;
}

dd {
margin: 0 0 1em 0;
}

dl {
margin-left: 2em;
}

<dl>
<dt>First step title</dt>
<dd>First step description goes here</dd>
<dt>Second step title</dt>
<dd>Second step description goes here</dd>
</dl>

If you try it with LI inside an OL, and use P as the definition block, both IE and gecko render correctly (although that markup would be incorrect).

This implies that both browsers have special treatments for the LI element, other than that implied through the CSS.

If anyone can come up with a browser hack to make that work, they deserve the free t-shirt!

Andrew Krespanis → mindlesslemming.au.ms

Excellent Quiz as allways!
As soon as I read the post I ran off and typed up the “Steve/Nicolas” method, only to go throught the comments and find that I’d missed the boat by a long shot…Maybe next time ;)

Ronald van der Wijden

Well, just for a chance at the T-shirt then:
My vote is for C, adjusted for the header option:

<ol>
<li>
<hx>First title<hx>
<p>First decription</p>
</li>
<li>
<hx>Second title</hx>
<p>Second description</p>
</li>
</ol>

This would for me be the sematically most logical option, and not too code-heavy. And, plenty of CSS handles to style to perfection. The header level should be chosen in accordance with their relation to the rest of the document.
Alternatively, for small portions of description text, the p’s could be left out altogether, which would make the styling dependent on the li’s.

Tantek → tantek.com/log/

Interesting discussion. Rather than simply picking the best among a set of alternatives, it is perhaps more important to understand how good or bad each alternative is. My summary (which reiterates what a number of folks have said):

(A) is bad / very-old-style markup due to the use of BRs to separate semantic chunks. Tags as separators went out of style (no pun intended) in the mid 1990s, as the need to actually contain/bracket content with tags became clear with CSS and DOM trees etc.

(B) is bad on two fronts. First, it abuses DL/DT/DD markup, because titles aren’t terms. Second it fails to capture the ordered semantic of the steps, since there is no significance to the order of term/definition pairs in a definition list.

(C) doesn’t contain any semantic abuses, but is semantically weak, in that the titles themselves are not marked up at all — they’re dangling chunks of text next to whole paragraphs.

So in answer to the original question, none of the above.

Some of the previous answers contained their own suggested alternatives which are worth some analysis.

compuwhiz7 posed the possibility of using heading tags (e.g. H2) to markup the titles as an extension to alternative (C). This improvement addresses the semantic weakness of the original (C) and is thus a reasonable alternative.

His point that it doesn’t really convey the relationship nearly as well is mistaken, as the markup pattern of a heading followed by related paragraphs is both well understood, and commonplace. Placing that pattern inside a list item certainly doesn’t reduce its effectiveness.

Bruce suggests using a STRONG element instead of a heading element. This is semantic abuse akin to [b]ed and [br]eakfast markup, since the strong element in this case would simply be used to mimic the bold styling of the title.

Several folks suggested nesting a DL inside each LI which has some initial appeal because it explicitly marks up each semantic chunk separately, captures the ordering semantic, and relates the title to the description. In my opinion this is still an abuse of DL/DT/DD though, as again, the titles aren’t really terms whose definitions are being provided.

Greg suggests using a nested list with a single list item for the description. The critique of this seems fairly self-evident. Does it make sense as a one item list? What about the description makes it list-item-like? Yes it is possible to use too many lists and list-items.

—Tantek

Lukasz → www.dwarfscorner.com/

I am not a designer, just a dilettante and my opinnion here is probably also dillettant one. Nevertheless, I vote for the B method as really fits structurally: an algorithm that one describes is divided into steps; these steps does not necessarily have to be numbered as the sequence can be reflected by order of titles.

Moreover, only B does not mix up two different styles of presenting the content; A uses dummy br and C has p included within a list - I don’t like it. B remains coherent and clean.

Kris → www.cinnamon.nl/

I’m going to play a bit on this one. Enough semantics and relations here, i hope. You be the judge.


<table summary="">
<tr>
<th id="item1" rowspan="2">1.</th>
<th id="title1">title 1</th>
</tr>
<tr>
<td headers="item1 title1">paragraph 2</td>
</tr>
<tr>
<th id="item2" rowspan="2">2.</th>
<th id="title2">title 2</th>
</tr>
<tr>
<td headers="item2 title2">paragraph 2</td>
</tr>
</table>


Working example here.

Kris → www.cinnamon.nl/

paragraph 2
Small typo. See the example where it shows as intended.

Richard@Home → richardathome.no-ip.com

Whenever I’m faced with a semantic markup issue. I say out loud what I’m trying to do:

“Create an *orderded list* of *paragraph blocks* with *headings* for each block.”

It HAS to be:

[ol] *ordered list*
[li]
[hn]Title[/hn] *headings*
[p]Paragraph[/p] *paragraph blocks*
[/li]
[li]
[hn]Title[/hn]
[p]Paragraph[/p]
[/li]
[/ol]

dl’s are probably the most over abused html element. While its valuable tool, I see it cropping up all over the place - usualy with a load of extra crud to make it behave like something else.

Lea de Groot → viking.org.au/blog/

Is there anything wrong with:
<ol>
<li>
<dl>
<dt>First Step Title </dt>
<dd>First step description goes here.</dd>
</dl>
</li>
<li>
<dl>
<dt>Second Step Title </dt>
<dd>Second step description goes here.</dd>
</dl>
</li>
</ol>
I realise that this isnt defining a relationship between the steps of the list, but… was there one in the first place?

I think it does all comes back to the nature of the content, and my suggestion really is a bit anal :)

Greg

About Tantek analysis : Allways very instructive to read you :-)

Maybe I won’t win a pretty T-Shirt, but I’ve allready won a good (X)HTML semantic lesson.

Aaron Gustafson → www.alistapart.com/authors/aarongustafson/

Good question. My 2¢:

B seems like the logical answer, but with 1 slight modification. I would remove the numbering and use the CSS content property to assign the numbers (using counter-increment).

From a page management view, this makes the most sense. You can change the order and add new items easily and the code is more compact. True, it isn’t supported everywhere yet, but we can dream.

Brian C.

A doesn’t give you any semantic value other than the ordered list.

B and C are both good choices - which one you choose depends on your semantic focus: an ordered list of things, or a list of definitions.

The nicer of the two would be C, since you can derive order if need be.

Jason Lotito → www.phpcomplete.com

B, for very specific and justifiable reasons.

At first glance, you see that it’s an ordered list with definitions. However, what you also need to look into is that it’s simply an ordered list. The 1, 2, or 3 portion of the terms are not really important. The list is ordered; that is what is important.

So let’s apply another type of ordered list, an alphabetical list. So if you have a list like so:

Cat
A feline, usually a pet.
Dog
A canine, usually a pet.
Fish
An aquatic animal
Tiger
A feline, not usually kept as a pet.


Here we have a list. This list is ordered, as it’s alphabetized. Does this mean we use a OL? No, we us a definition list like so:


<dl>
<dt>Cat</dt>
<dd>A feline, usually a pet.</dd>
<dt>Dog</dt>
<dd>A canine, usually a pet.</dd>
<dt>Fish</dt>
<dd>An aquatic animal.</dd>
<dt>Tiger</dt>
<dd>A feline, not usually kept as a pet.</dd>
</dl>


Now, very few people would have a problem with this list. And this list is no different then the list that is presented in the question. The only real difference is that the first list is ordered by something other the the orders of letters, and that this ordering is displayed with a number.

Aaron Gustafson’s previous post (#50) gives us the most appropriate way to add this, with the caveat that it’s not really supported everywhere yet.

A short term solution would simply be to include the numbers in the actual DT, as B does.

igner

It seems as though there’s really only one semantically correct answer to the problem as worded:

“The goal: to present a numbered list, with each list item containing a bold title, followed by a description on the next line.”

That could be re-written as:

“The goal: a numbered list of descriptions, each with a bold header.”

That sounds a lot like

<ol>
 <li>
  <h1>item one title</h1>
  <p>item one description</p>
 </li>
 <li>
  <h1>item two title</h1>
  <p>item two description</p>
 </li>
</ul>

A head has an implicit relationship to what follows. Take a look at item 15a in Merriam-Webster’s definition of HEAD:
“15 a (1) : a word or series of words often in larger letters placed at the beginning of a passage or at the top of a page in order to introduce or categorize”

I’m by no means an expert on markup or CSS (though I’m learning, thanks to discussions like these), but I thought I could add some clarification as to WHY the proposed solution “D” is the proper solution for the question as posed.
Just remember, when looking for a semantic solution, it’s important to look at the sematics of the question or problem.

igner

Minor typo in my example, it should have been </ol> not </ul> to close the list.

Jason - semantically, definition implies a specificity of description that is not necessarily conveyed by either the question or the example. The way I see the question posed, the content could just as easily be

Article 1 Title
Abstract
Article 2 Title
Abstract
Article 3 Title
Abstract


In my book, that is not a situation where, semantically, a definition list would apply. (Stylistically, perhaps, but I think same results be achieved with an ordered or unordered list, and be semantically correct.)

Jim Pettit → imustconfess.com

I’m getting a splitting headache; you’re all getting a little carried away with your fancy-schmancy CSS stuff. I’m going to agree with Kris and say that tables were invented for a reason; I’d use the following, and never have a problem in any browser. I say, screw readability, useability, and maintainability.


<table border="0" cellspacing="1" style="border-collapse: collapse" bordercolor="#111111" width="100%" id="AutoNumber1">

<tr>

<td width="3%" rowspan="2" valign="top"><font face="Tahoma" size="2">1.</font></td>

<td width="97%"><font face="Tahoma" size="2"><b>First Step Title</b></font></td>

</tr>

<tr>

<td width="97%"><font face="Tahoma" size="2">First step description goes here.</font></td>

</tr>

<tr>

<td width="3%" rowspan="2" valign="top"><font face="Tahoma" size="2">2.</font></td>

<td width="97%"><font face="Tahoma" size="2"><b>Second Step Title</b></font></td>

</tr>

<tr>

<td width="97%"><font face="Tahoma" size="2">Second step description goes here.</font></td>

</tr>

</table>


Kidding, actually. (No, really, I am.)

A lot of great commentary here (some of it by people who seem to know what they’re talking about). While I don’t consider my own sorry, inexperienced self to be in that esteemed group, I’d opt for ‘B’. I realize the numbering could be a hassle, but probably not: after all, a static list wouldn’t change (because it’s, you know, static), and a dynamic list — say, one generated on the fly from a database query — could have the numbers slugged in at run-time. Clean, simple, concise, and happily lacking any of the mix-and-match mumbo-jumbo found in options ‘A’ and ‘C’.

mark → www.neue.co.uk

how about
1.   title

     answer

2.   title

     answer

LOL!

mark

jason → www.jasonspage.net/

How bout


<ol>

  <li>First Step Title

<pre>First step description title goes here.</pre></li>

  <li>Second Step Title

<pre>Second step description title goes here.</pre></li>

</ol>



Works just fine without a lot of hassle.

Darrel → darrelaustin.com

Well, I have to post SOMETHING for the chance to get a t-shirt, eh?

I guess my answer is, yes, I love to “ruminate about the subtleties of hand-crafted markup” too, but the more I do so, the more I realize that HTML is just overly simplistic and that there is never a right answer and even rarely a ‘better’ answer.

The ideal solution, of course, would be for us to have access to more list types for just this type of thing.

Several have mentioned using the header tag example. I think my gut reaction would have been that, but I’ve also stumbled on a problem recently along those lines.

I’ve been building a control that will generate a list/table and insert it into a larger ‘chunk’ of content. I started off using h* tags, but then realized I had no way of knowing what level of h* this particular list/table would appear under.

So, I could end up with items in the lists with headers larger than the parent content’s header.

In the end, I decided to use h6 tags. I kept them headers still, but low enough in the heirarchy that they shouldn’t cause too semantic issues.

I do like this idea, as well

Paul Kilroy

Here here… I agree with Tantek’s analysis. Why did it take 43 comments for someone to point out that dl is a *definition* list and these are not definitions. Where are all the acronym v. abbr people? I agree a modified C is the way to go.

Eric

C. More often than not, C is the answer on multiple choice.

Anonymous

He he, what a great discussion :)

Thomas A. Edison one said: “Hell, there are no rules here - we’re trying to accomplish something.”. So in his spirit I would like to suggest this:


<?xml version="1.0" encoding="ISO-8859-1"?>

  <steps>

    <item>

      <title>First Step Title</title>

      <description>First step title</description>

    </item>

    <item>

      <title>Second Step Title</title>

      <description>Second step title</description>

    </item>

  </steps>




and the XLS part


<?xml version="1.0"?>

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/TR/REC-html40">

<xsl:output method="html" indent="yes"/>

<xsl:template match="/">

<html>

<head>

<title><xsl:value-of select="descript/title"/></title>

<style type="text/css">

body { font-family: verdana; font-size: 0.8em; }

li { margin-top: 10px; font-weight: bold; }

p { margin: 0px; font-weight: normal; }

</style>

</head>

<body>

<ol>

<xsl:apply-templates />

</ol>

</body>

</html>

</xsl:template>



<xsl:template match="steps/item/title">

<li><xsl:apply-templates/></li>

</xsl:template>



<xsl:template match="steps/item/description">

<p><xsl:apply-templates/></p>

</xsl:template>



</xsl:stylesheet>




→ Working example (tested in IE 6.0 only)

Thomas Baekdal → www.baekdal.com

He he, what a great discussion :)

Thomas A. Edison one said: “Hell, there are no rules here - we’re trying to accomplish something.”. So in his spirit I would like to suggest this:


<?xml version="1.0" encoding="ISO-8859-1"?>

  <steps>

    <item>

      <title>First Step Title</title>

      <description>First step title</description>

    </item>

    <item>

      <title>Second Step Title</title>

      <description>Second step title</description>

    </item>

  </steps>




and the XLS part


<?xml version="1.0"?>

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/TR/REC-html40">

<xsl:output method="html" indent="yes"/>

<xsl:template match="/">

<html>

<head>

<title><xsl:value-of select="descript/title"/></title>

<style type="text/css">

body { font-family: verdana; font-size: 0.8em; }

li { margin-top: 10px; font-weight: bold; }

p { margin: 0px; font-weight: normal; }

</style>

</head>

<body>

<ol>

<xsl:apply-templates />

</ol>

</body>

</html>

</xsl:template>



<xsl:template match="steps/item/title">

<li><xsl:apply-templates/></li>

</xsl:template>



<xsl:template match="steps/item/description">

<p><xsl:apply-templates/></p>

</xsl:template>



</xsl:stylesheet>




→ Working example (tested in IE 6.0 only)

Thomas Baekdal → www.baekdal.com

Huh? Sorry for the double-post ?!?!?

Dave Meehan → www.orificeworld.com

I don’t see how that is not a definition list. If step 1 is ‘mix the dough’ and the description describes how long for, ‘mix the dough’ is a term, and the text is its ‘definition’.

DL’s are not just designed for scholarly use.

Shawn Oster

I vote for the modified C, where you wrap the title in a <hn> tag.

In doing CSS I realize what it really stands for is “Compromise between Style and Semantics” and as others have noticed that is exactly what this method gives you, a wide range of ways to style it, semantically accurate and with some reusability to boot if someone comes across your markup and wants something similar that doesn’t exactly fit the definition list semantic.

Of course I also like it because this is what I’m currently doing on our corporate site <smile/>.

Thomas Baekdal → www.baekdal.com

Revised version (works in Mozilla browsers too - Except Safari for some strange reason)

Joseph Lindsay → www.josephlindsay.com

I’d say that Steve and Nicholas’s is the best ‘working’ example (comments 9 and 10). I agree with Tantek’s comments about the abuse of dl/dt/dd, as I don’t think that is strictly correct to consider that something is a definition ‘list’ when it is only 1 term/definition long. However, I do consider that each item heading is a defined term and its description could be considered its definition. Dave’s method (comment 40) is also good. Perhaps someone should lobby w3c to have an ‘ordered definition list’ tag included in their next standard?

taestell

Sorry if this has been already mentioned, I just skimmed after comment #25 or so…

The W3C says that <dl>’s are not just for definition lists. They can be used for a lot of things, like scripts (speaker’s name in <dt>, dialogue in <dd>), itineraries (as seen on Dunstan’s Blog), or any title-and-content pair. An interesting use of them can be seen here, where the <dt> is used to hold a song’s name, and the <dd> is used to hold track information. I use them for non-definition uses all the time.

Eric → www.arkitrave.com/log

Just because we can add content with CSS (in the future, in some browsers) doesn’t mean it is philosophically any better than, say, tables for layout. If the numbers are important to the list, they should be in the XHTML. It isn’t the province of CSS to add content; CSS should style. The numbers are not style, they are germane to the list itself, and shouldn’t require the CSS to understand.

Eric → www.arkitrave.com/log

Yes, taestell.

The problem with all the bickering over definition lists is that the w3c screwed the pooch in their naming. They were shortsighted, and didn’t look at the broader use for the semantic idea of a descriptor and a description. The element should have been named something other than definition list, as there are many uses for this type of relationship that are not strictly definitions.

Anonymous

Thomas - but does your XML/XSL solution degrade into something meaningful? Even without styling the DL and OL options are comprehensible.

I, too, looked at the description of DLs at W3 and saw the description of the DL usage that taestell so kindly pointed out. I also came the the same conclusion that Eric did regarding the pooch and the naming of DLs (not that I can come up with a better name).

That being said, I still think that using DLs in this particular case makes for unnecessary difficulty / complexity, in that it requires either manual numbering of the list elements, or transformation of data returned dynamically. An ordered list has neither of those limitations.

Eric → www.arkitrave.com/log

As did I, 5:03. I was just defending definition list usage anyway, because I generally like them, but in this case it gets ugly, and I still go for C, acknowledging the possible need for extraneous header markup to indicate a greater level of importance for the first half of the pair. If the numbers are important, use an ordered list, and go from there to make it work for ease of code and as much semantic purity as possible.

Rimantas → rimantas.com/

Yes, there’is an issue about “puriness”
of dl/dt (and w3c position was not very stable on this issue, AFAIK).
I still insist on not foregeting how solution looks without any CSS applied.
That makes Cmodified the winner, and B the second (or the first, if there is no
C modified). Headings will be distinc enough in those cases even without CSS.

Lenny Domnitser → bloglenny.blogspot.com/

I would have to go with B because it clearly indicates a title. In fact, one would consider not using the ol element at all due to its poor structure.

Chris Schreib

Dan, I think you chose a great example, specifically because it points out the problem I (and I’m sure many others) have been having, but the terms you chose may be a little misleading and certainly require closer scrutiny.

If I understand the example correctly, what you have is a list of steps that comprise some sort of procedure. The fact that they are numbered tells me that they must be followed in a certain order and therefore must be marked up as an ordered list.

If my assumption is correct than we must dismiss option B. Like some others, I also like the fact that a definition list allows for easy name-value pairing, but it seems that the ordered nature of the steps demands that we use an ordered list for our “parent” element. Semantically, what we have is an ordered list of steps — not a list of name-value pairs.

As a side note, to debunk an earlier argument, CSS and Javascript cannot be used to add ordered numerals in this case. If the numbers were there merely for presentation, adding them via CSS might be justified, but this is clearly not the case with this example. The reason we cannot use CSS to add numerals in this example is because doing so would be using CSS to define the structure of the document. CSS should only be used in the presentation layer and should not be necessary in the structure layer. To further belabor this point, imagine what a user without CSS enabled would see. He/she would most likely see a list of name-value pairs and may not come to the conclusion that the steps must be followed in a specific order. The same point can be made about Javascript and the behavioral layer versus the structural layer. In order for our information to reach the audience as intended, we cannot rely on the presentation or behavior layer to manipulate the structure to suit our needs. We must rely on robust and semantically structured markup to convey our meaning.

While option A is closer than option B, using the line break to separate different information is obviously not the best idea, as it fails to denote any relationship between the Step Title and the Step Description.

This leads me to the problem I’m having with this example. I’m afraid the problem, lies in the use of the terms “title” and “description”. At first glance, this would seem to imply a relationship that calls for a definition list, but lets think outside of the box for a moment and try to truly understand the nature of the elements we have to work with.

First, lets see what these elements represent. The element is used for a definition term or, more generally, as a name or label; while the element is used for a definition description or as a value. Whatever words you choose, we essentially have a term and a description. Similarly, the <hn> element is used as a section heading; while the <p> element is used for a paragraph. The relationship here might seem obvious, but consider the following: is a heading a description of the following paragraphs or are the paragraphs a description of the heading?

The conclusion I have come to is that the difference between these two structures is that the combined use of the <hn> and <p> elements denotes a symmetrical relationship whereas the use of the <dt> and <dd> elements denotes an asymetrical relationship. The <dd> element specifically describes the <dt> element, whereas the <hn> element and <p> element describe or relate to each other. This isn’t exactly clear looking at the quiz example, but if you examine the w3c examples, you’ll notice that the <dt> cannot be used to inversely describe the <dd>. For example, “a clever programmer” inversely is not necessarily a hacker. This is just an example, but I hope the point is obvious by now.

In my own opinion a definition list seems most appropiate when the <dt> element contains one or two words. This is a conclusion I’ve recently come to and I believe it is one that is worthy of closer analysis.

Therefore, looking back to the quiz example, lets examine the relationship between the “title” and “description”. I believe what we really have here is a symmetrical relationship. If we indeed have an ordered process, each step may contain a short title, or heading, and a lengthy description, or paragraph. In any procedure I can think of, these two elements are interchangeable: you could remove either the description or title and the meaning of the list item would still be apparent, though perhaps not as descriptive.

Looking at it another way: what if the example read:


1. First Step Title
First Step description goes here.
First Step description goes here.
First Step description goes here.



2. Second Step Title
Second Step description goes here.
Second Step description goes here.
Second Step description goes here.


where the descriptions continued ad nauseum. Each successive description might get further away from describing the Step Title, but they still fall under the “umbrella” of the Step Title. To me it seems obvious that the relationship between the Title and the Description is a symmetrical relationship, and should therefore be marked up as a <hn> follwed by <p> tags.

As I see it, what we really have here is an ordered list (<ol>) comprised of various titles (<hn>) and descriptive paragraphs (<p>). If we believe my (many) assumptions are true, then option C is the closest to semantically correct markup, but the titles really should be wrapped with <hn> tags, in order to preserve their true relationship to the following description.

I apologize for leaving such a lengthy comment, but I was actually having this exact problem at the moment. I came to SimpleBits to seek inspiration and have found exactly that. Thank you for indulging me, and I my apologize once again.

Felipe

I would choose B because it has the less forced formatting. Both A and C indents the Titles and Descriptions. I don’t like this very much, because it will be harder to get the correct format you are looking for. Also, in my taste, I don’t like the title indented in the same place of the descriptions. Picking up option B would be a natural selection for me, as it won’t force the indents.. But, of coruse, that doesn’t mean that you can’t indent the option B like A and C

Tanny O'Haley → tanny.ica.com

Chris #75. You gave a lucid and clear definition of the problem. Your lengthy comment is welcomed and appreciated.

Thank you

Micah → msittig.wubi.org/

Regarding appeals to the “natural formatting” of X/HTML tags:

Every browser (even lynx) has an internal default stylesheet, usually modeled on the W3C recommendation. This means that even “unstyled” X/HTML is pre-formatted according to a certain set of style rules that are, according to the W3C standards, “informative, not normative”. I interpret the W3C’s position to be that the basis for decisions about markup should be solely semantic value, insofar as CSS is able to generate the desired look (a nod to the oft’ abused and overused pragmatic perspective). As an extreme example, a browser could theoretically render CSS-less X/HTML as 1em mono text, with no margins, padding or line breaks, and it would still be 100% standards-compliant and semantically correct.

benry → benry.net

B. Clear, simple, degrades nicely also.

Niko Sams

Actually Steve/Nicolas should work, but the markup is too complicated and has too many tags for such a “simple” problem.

Conspis Markup with

<dl>
<dt>First Step Title</dt>
<dd>First Step description goes here.</dd>
<dt>Second Step Title</dt>
<dd>Second Step description goes here.</dd>
</dl>

looks much better there, but javascript for such a problem would be an overkill.

it would be great if for Conspis solution a

display: list-item;
list-style-type: decimal;

would work

but it always displays a “0”

ok, and to the other solutions, B would be clear and simple, yes, but it has the number in the text which is very bad imho.

A won’t work because you can’t style the first line(?) or am i wrong about that

so C would be it, or my solution would be like that:

<dl>
<dt>First Step Title</dt>
<dd>First step description goes here.<dd>
</dl>


Jonathan Stanley → lambcutlet.org/

I’d go with none of the above and use something like:


<ol>
  <li>
    <dl>
      <dt>First Step Title</dt>
      <dd>First step description goes here.</dd>
    </dl>
  </li>
  <li>
    <dl>
      <dt>Second Step Title</dt>
      <dd>Second step description goes here.</dd>
    </dl>
  </li>
</ol>

Or alternatively use inline XML, by switching namespaces, eg:


  <simple:process>
    <simple:step>
      <simple:title>First Step Title</simple:title>
      <simple:description>First step description goes here.</simple:description>
    </simple:step>
    <simple:step>
      <simple:title>Second Step Title</simple:title>
      <simple:description>Second step description goes here.</simple:description>
    </simple:step>
  </simple:process>

… having added xmlns:simple="http://www.simplebits.com/xmlns/simple/" to <html>

… then relevant CSS for:


simple\:process (foo: bar}, simple\:step (foo: bar}, simple\:title (foo: bar} & simple\:description (foo: bar}

as required.

No idea why spacing is being screwed halfway through my post… entitizing the colons made no difference… :(

thomas → gendes.elivy.com

Well, B seems like the best answer at a glance, however you explicitly stated that you wanted the heading to be bold, presentation which a does not automatically convey. It can be made bold through the use of CSS, but since semantics is our discussion here, I don’t believe that B is our best choice.

In fact, none of the examples which you have prompted actually convey the meaning of the “First Step Title”, as you have so aptly called it. There is no doubt in my mind that this calls for a tag. Therefore, with semantics in mind, here is my proposed solution to this question:


<ol>

  <li>

    <h3>First Step Title</h3>

    <p>First step explained here.</p>

  </li>

  <li>

    <h3>Second Step Title</h3>

    <p>Second step explained here.</p>

    <p>And a little bit more here.</p>

  </li>

</ol>


Thomas Baekdal → www.baekdal.com

[Ed. - in reference to a comment that has since been edited]

Thomas, A trick is too use “SimplePost”

Although I would like to suggest to Dan, that you somehow add it’s functionality to this commenting system - so that anything between <code> and </code> is “simpleposted” automatically.

tysontune → ramshacklehumanity.com

From the choices given I’d pick B. However, I agree with some who have posted before that a combination of heading tags and paragraph descriptions would be most correct.

B falls shourt becasue the items may not be in a word/definition or item/description format. The might be queston/answera/answerb/answerc or somehting else even.

Thomas Baekdal → www.baekdal.com

Err… A couple of you guys seem to imply that a <dl> list can only have one term with one definition.

But this is not so. A definition list can hold any number of terms and/or definitions.

Example (from w3.org):

<dl>

   <dt>Center</dt>

   <dt>Centre</dt>

   <dd> A point equidistant from all points on the

    surface of a sphere.</dd>

   <dd> In some field sports, the player who holds

    the middle position on the field, court,

    or forward line.</dd>

</dl>



Chris Schreib

The more I think about this question the more obvious the answer becomes. To everybody that didn’t read my first comment or thinks B is a possible option, please read this comment.

The question is “Which of the following methods would you choose for marking up a numbered list of titles and descriptions?” The goal is to present a numbered list with a bold title and a description. The way to achieve this goal is to write robust and semantically correct markup and then style it with CSS. The first thing that must happen is to write proper markup and then anybody and their mom can style it later. All your CSS tricks of adding ordered numerals and tricking out the font weight and size is simply an afterthought.

Good design is not about font weights and margins, its about communication; and on the web, good communication starts with good markup. As a designer you must first understand the ideas you are working with and how they relate to each other.

From the given example, we can see that we are working with steps in a procedure and from the way they are numbered, they most likely must be followed in a specific order. Therefore, we have an ordered list of steps. Is this really a difficult concept? The correct answer must involve an ordered list. The next question is how do we communicate the relationship between the title and description.

The question here is not, “how do we make the title bold?” If we have properly described (and marked up) our information, then styling it with CSS later will be a breeze. Notice how the question doesn’t ask about CSS styles? Thats because the question isn’t about presentation, its about how we should semantically separate different ideas. The key to communicating our ideas lies in our ability, as designers, to separate ideas — not in our ability to play with fonts and colors. Fonts, colors, etc. are the methods available to us to separate ideas and communicate clearly. So anybody that thinks this question involves CSS or Javascript is severely misguided.

Back to the question: how do we communicate the relationship between the title and description? I suppose this is the only possible grey area of the question, although, for me, it is hardly a question at all.

To anybody that thinks we should use a nested definition list, I must ask you a question: do you ever use <hn> and <p> tags at all? After all, what are those tags anyway? Just a bunch of titles and descriptions? Why not use definition lists for everything?

All information is titles and descriptions.

Definition lists are for name-value pairings. As someone pointed out, you can use more than one term and description, but they are still name-value pairs. That is it.

At first, I thought using the terms “title” and “description” made the question more difficult, because most people would assume to use a definition list, but now I see that those terms are what make the answer so obvious. A “title” belongs in a <hn> tag. That is what the tag is for. A heading is the “title” of a section, and that is precisely what we have. A step is just a section of the overall procedure.

Understanding that a step is just a section of the procedure, it is obvious that we should use a <hn> tag for the title. Now that we know that, we see that the descriptions that follow the heading are simply descriptive paragraphs and should be marked up accordingly.

To me, it is obvious that our list should be marked up

<ol>
<li>
<hn>First Step Title</hn>
<p>First step description goes here.</p></li>
<li>
<hn>Second Step Title</hn>
<p>Second step description goes here.</p></li>
</ol>

This semantically describes each piece of information and the relationship between them. We have a list of ordered steps that each have a title and descriptive paragraph(s). Assuming most user agents will automatically number the ordered list and bold the heading, we shouldn’t even have to use any CSS to style them to achieve the goal of having a numbered list with a bold title. Of couse, as someone just pointed out that is relying on the user agent to make the presentation decisions for the user, but I would argue that is precisely what accessibility is — allowing the user to absorb the information in the form that he/she understands best.

Sorry again for the long rant, but I can’t see how there is any question as to how this should be marked up. And thanks for such a great question Dan. By accident or not, you managed to bring up some very important questions about the relationship of pieces of information.

matthew

This is the first time I’ve ever thought about anything semantic (I didn’t know the <dl> tags existed until I came here, so forgive my insanity (and awkward punctuation) while I argue for unmodified C.

I know the stated goal is to make a numbered list of pieces of text with titles and descriptions, but for the specific case of a “list of instructions” the most important relationship is that between the steps and the list numbers. Adding <hn> tags around the steps does strengthen the relationship between the them and the rest of the text, but it divorces them from the list by giving everything equal importance (see Chris’s earlier comment on the symmetric relationship between headings and paragraphs.)

It might be splitting hairs, but I see it as the difference between “a list of steps (with added descriptions)” and “a list of (steps and descriptions.)”

A list of instructions should be able to stand on it’s own without any descriptions. I guess it goes back to the chapter on multi-paragraph list items - you wouldn’t mark up a list of steps like this:
<h2>Directions:</h2>
<ol>
<li><h3>Mix ingredients.</h3></li>
<li><h3>Bake.</h3></li>
</ol>
since in this case it is clear that the steps on their own are the list items, and nothing else. Why should the markup change if a description is added?

It depends, though. In a case like
3. Add three whole eggs (shells included).
Eggshells are crunchy!
I am tempted to use unmodified C, since the instruction is entirely contained within the title, and the following paragraph is just a side note. Unmodified C best shows this relationship by directly associating the title and the list, and separating the desciption from this. <p> tags might not be the best way to sematically represent this separation, but I can’t think of any alternatives at this time.

But when the instruction is too complicated and the paragraph is a necessary part of the explanation, modified C is definitely the most semantically correct choice. The list becomes “a list of steps (which happen to be pieces of text with titles and descriptions,)” so the heading and paragraph together form the list item.

I’m curious though, how would one mark up the case where half of the items have descriptions and half do not? Modified C would add unnecessary (in my opinion) <hn> tags around the stand-alone elements (they aren’t really headers if they don’t have anything to head, are they?), while unmodified C might not show a strong enough relationship between a step that requires explanation and the explanation itself. I’d suggest combining the two, but you’d then have three different ways of marking up the same thing (depending on whether a step stands alone, contains an unnecessary description, or contains a necessary explanation.)

I think I’d choose modified C in this case, for the sake of consistency.

Chris Schreib

Matthew, what we have in the given exmaple is a list of steps comprised of a title and a description. The reason the unmodified option C should not be used is because it doesn’t describe the relationship between the title and the description. Not wrapping the title in a <hn> tag separates the title from the following paragraph, but it doesn’t describe the relationship between the title and the paragraph.

Think of it this way: without wrapping the title in a <hn> tag, what we would have is a list of steps that contain some generic text and a paragraph. It is part of the list step, but I’m not really sure how it relates to the paragraph that follows it. How does the reader know that this generic text is the title of the step? It might seem obvious when we look at the list, but think of all the things that won’t be looking at the list, such as users with impaired vision and search engines. To properly understand the information contained within each step, we must use markup that reflects the relationship between the various pieces of information.

Although it is not the given example, if I was marking up this list and a step did not contain a description, I would still wrap the title in a <hn> tag, because it is still essentially a title. It is still the title of the step. I don’t see why every title has to have a description following it. It just means that it is the title of the step and that it is self-explanatory and therefore does not require any description.

What I often do when validating my pages is to turn on the outline mode. This shows me the outline of a page, so I can see the flow of information and how headings relate to each other. That way I keep all my <h3> elements under the proper <h2> element, and so on. It is definitely a very useful feature.

The only logical reason I can think of not to wrap the titles in <hn> tags is if you choose to see the description as merely a side note — an added pleasure. In that case, the titles aren’t really titles, they are just the list steps with accompanying descriptive text. In this case, I might consider marking the list up as follows:


<ol>
  <li>
    Step</li>
  <li>
    <hn>Step</hn>
    <p>Step description</p></li>
</ol>


With the following style rules:


li { font-weight : bold; }
hn {}
p { font-weight : normal; }


This would separate the descriptive paragraphs from the list steps.

I must confess that I just pulled that out of my ass, and if someone wants to argue with it, I’d enjoy reading someone else’s thoughts on the subject.

matthew

Well, I actually expected more vehement disagreement than that. I can find very little in that comment that I don’t agree with.

It may go against convention (I honestly don’t know), but I think that when marking up a list one must always keep in mind what items are to be contained within the list - those items and no others should be the ones within the <li> tags. The question clearly asks us to mark up “a numbered list of titles and descriptions” so there’s no ambiguity. Modified C is the best way to go.

But to make a more general “numbered list of steps” one needs to work out what constitutes a “step.” In the eggshell example, the instruction to add the eggs to the mix is part of the step, so it shouldn’t be marked up as anything other than <li>, while the statement that shells are crunchy is not part of the step, but some side-note to it, and should be marked up accordingly.

Also, in this case I’d argue that the text isn’t as closely related as a paragraph, as the side-notes don’t really describe the step. I would not describe it as “generic text with an accompanying paragraph” though, but as “a list item containing a sub-paragraph.”

On the other hand, modified C would be used when the entire paragraph was part of the step. Even after this paragraph is marked up with <hn> and <p> tags, the paragraph as a whole remains within nothing but the <li> tags.

With regard to the “steps without descriptions” question, I again have to agree with your response. It makes more semantic sense to have each list item have the same components, even if some of them do not appear in every item. That is the reason I chose modified C for that task, as continuity between the list elements (and the relationship between headings in the outline view) is more important than making each one semantically correct for its own individual case.

Steve Smith → www.orderedlist.com

In response to Chris:

To anybody that thinks we should use a nested definition list, I must ask you a question: do you ever use <hn> and <p> tags at all?

The <hn> tag is a heading tag. It is not required to be the ‘Title’ of the below subsection. Narrowing it’s scope to be used only for titles would limit it’s usage.

More importantly, the <p> tag is simply that… a paragraph. It does not denote a descriptor, a list item, or anything else. It simply seperates paragraphs. Idealy, in my solution above, if you had multiple paragraphs in the <dd> tag, one should mark those up with paragraph tags. This does not mean that those paragraphs are descriptors of the <dd>, they are merely paragraphs within it.

Sematics are all about accuracy, and unfortunately, a lot of people are leaning away from proper semantics to avoid “heavy code.” In my opinion (and it is only my opinion) the XHTML should be semantically correct, even if it becomes less human-readable. After all, nobody except people like us care to ‘View Source.’ If the XHTML is marked up validly and semantically correct, it makes for accurate content and easy styling.

</soapbox>

hartmurmur

I have debated (with myself) on what to do in these cases as I just marked up a 550 page handbook for the gypsum industry.

I used the ‘A’ method above.

This comment isn’t worth anything. I’m just happy to be #91.

hartmurmur

Oh, and Steve Smith #90, (can’t be from the Carolina Panthers because he’s #89), I couldn’t validate your soapbox comment….parse error. Could you try again? :)

Steve Smith → www.orderedlist.com

How ironic… an invalid comment about semantics. Lets try this:

<soapbox />

Anonymous

Steve - take a look at the definition of “heading”:

head·ing n.

1. The title, subtitle, or topic that stands at the top or beginning, as of a paragraph, letter, or chapter.

A heading is a title. Yes, one could use <hn> to highlight text without relation to the content that follows (i.e. not as a title, but as part of the flow), but that would not be a semantically correct use of <hn>.

If by “accuracy” you mean “meaning”, then yes, you’re correct on the subject of semantics. I made the mistake this morning of looking for an accurate definition of semantic markup. I say mistake, mainly because I found no singular definition (somewhat ironic since the subject is semantics); however, I did find a variety of opinions on what it “should” mean.

A lot of the discussion seems to center on preserving a “relationship” between the list item and the copy that follows. Is there not an implicit relationship purely as a result of the document flow? Does not a paragraph relate to the preceding paragraph, barring some other textual element (such as a heading or title) indicating such a break? Assuming that to be the case, is there any argument about the following as a solution:


<ol>
  <li>Item One Header</li>
    <p>Item One Description</p>
  <li>Item Two Header</li>
    <p>Item Two Description</p>
</ol>


Based on simple tests of the 4 browsers I have on my local machine (IE 6, Firefox, Opera 7.23, and the venerable NN4.74), the paragraph inherits the indentation of the list. And from what I can see there’s nothing in the spec that forbids such a structure.

igner

d’oh…hate it when i do that - the above post is mine. for some reason if i check the preview then hit back, the comment’s preserved, but my info isn’t.

sorry.

Dave → www.brandedthoughts.co.uk

XHTML 2 and CSS 2 are both currently progressing towards resolving this issue.

The problem (as mentioned by someone else) of using <h2> or <h3> in your list is that you might move the list somewhere else, where suddenly the <hX> tags need to be <h[X+1]> (e.g. <h2> becomes <h3>).

Plans for changing <hX> tags to just <h> in XHTML 2 would solve this problem and make the solution C (modified with headings) far more appropriate.

Simply using a <dl> list is the best option. And the numbering (if essential) would be done with CSS using CSS 2 automatic numbering.

The choice between these two options is up to the designer, who has to make the decision whether the number or the relationship is more important (even though the relationships are themselves arguable).

XHTML 2 <h> would require the page to be split up with <section> tags too - which would bulk up the code even further.

My personal favourite is the CSS 2 method :)

Steve Smith → www.orderedlist.com

I’ll agree that my previous post was worded a little incorrectly. What I was trying to get at was that a <hn> tag and a <p> tag together do not signify as strong a relationship as a <dt> tag and a <dd> tag. A heading and a paragraph together would signify that the content is related, but not necessarily that the paragraph is a description or definition of the heading. I believe in this context that a definition list is a more accurate representation of the connection between t