This quiz is certainly one of those grey areas — a comparison that may have some begging that there must be a better way to spend one’s time.
- Figure 1
Still with me? Good. Last December, we sort of touched on this topic, with a question on Multi-Paragraph List Items. But for this question specifically, take a look at Figure 1. The goal: to present a numbered list, with each list item containing a bold title, followed by a description on the next line.
Seems like an ordered list (<ol>) would be the best choice, but how to handle the description on the next line is the head scratcher.
I’ve run into this dilemma several times in the past few months, asking myself which is better. Again, each method may be splitting hairs, but I’m curious what you, the esteemed readers of SimpleBits thinks.
As added incentive, and to reward at least one person that, like me, actually enjoys ruminating about the subtleties of hand-crafted markup — I’m giving away one (1) free official SimpleBits T-shirt, hand-drawn by yours truly at pixeltees. Since there is no correct answer, I’ll be selecting one comment to feature in the Conclusion of this particular quiz. If your comment is chosen (for whatever reason) — you get the free shirt.
Q: Which of the following methods would you choose for marking up a numbered list of titles and descriptions?
-
<ol>
<li>First Step Title<br />
First step description goes here.</li>
<li>Second Step Title<br />
Second step description goes here.</li>
</ol>
-
<dl>
<dt>1. First Step Title</dt>
<dd>First step description goes here.</dd>
<dt>2. Second Step Title</dt>
<dd>Second step description goes here.</dd>
</dl>
-
<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>
Dribbble What are you working on? 
Instapaper Icon design 
Sass For Web Designers Paperback + eBook A Book Apart
CSS3 For Web Designers Paperback + eBook A Book Apart
Bulletproof Web Design Third Edition New Riders 
Handcrafted CSS Book and DVD New Riders 
Web Standards Solutions Special Edition Friends of Ed
110 Comments
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
h3or any other, too.) The trouble with that is that it doesn’t really convey the relationship nearly as well.So I choose B. :D
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?
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.
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.
I’d choose “b”, but without the numbers; then I’d use a CSS-2 auto-number to put the numbers in the
dtcontainers, 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.
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.
I would use option C. It degrades nicely and styling is fairly straightforward. But them I’m only starting with CSS.
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]>.
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.
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…
Nice thinking, Nicolas.
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 … ;)
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).
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.
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
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.
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.
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. :-)
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.
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
liand theli pseparately. (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
hXor anhXand apwithin theli.Andrew, I cannot take credit for the “headings” idea – it is a variation of compuwhiz7′s example.
I mostly agree with Bruce. Except I don’t think the descriptions need separate paragraph tags. The
<strong>tags can simply getdisplay: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.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.
*sigh*
Sorry about that mess. There was a ‘pre’ around all that. I even checked with the preview.
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.
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, 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.
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?
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.
You’re all wrong.
<table border="0" cellspacing="0" cellpadding="0">
<tr>
<td>1.</td>
<td> </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> </td>
<td><b>Second Step Title</b></td>
</tr>
<tr>
<td colspan="2"></td>
<td>Second step description goes here.</td>
</tr>
</table>
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.
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.)
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:”
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. :)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.
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>
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> 'sas 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 :)
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.
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.
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!
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 ;)
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.
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
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
brand C haspincluded within a list – I don’t like it. B remains coherent and clean.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.
paragraph 2
Small typo. See the example where it shows as intended.
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.
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 :)
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.
Good question. My 2¢:
B seems like the logical answer, but with 1 slight modification. I would remove the numbering and use the CSS
contentproperty to assign the numbers (usingcounter-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.
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.
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.
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.
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.)
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’.
how about
1. title
answer
2. title
answer
LOL!
mark
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.
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
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.
C. More often than not, C is the answer on multiple choice.
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)
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)
Huh? Sorry for the double-post ?!?!?
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.
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/>.
Revised version (works in Mozilla browsers too – Except Safari for some strange reason)
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?
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.
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.
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.
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.
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.
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.
I would have to go with B because it clearly indicates a title. In fact, one would consider not using the
olelement at all due to its poor structure.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 theelement 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.
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
Chris #75. You gave a lucid and clear definition of the problem. Your lengthy comment is welcomed and appreciated.
Thank you
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.
B. Clear, simple, degrades nicely also.
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>
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… :(
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>
[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.
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.
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>
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.
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>
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.
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.
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.
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>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.
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? :)
How ironic… an invalid comment about semantics. Lets try this:
<soapbox />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.
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.
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 :)
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 the item’s title and it’s description.I say A
Whatever works for you! Thats my take.
For example, steps in standard-based design:
1. SEMANTIC XHTML
Blah Blah Blah
2. STYLE USING CSS
Blah Blah Blah
3. BEHAVIOR USING JAVASCRIPT
Blah Blah Blah
All of the following may be correct:
[h1]Site title[/h1]
[h2]Standards-based Design[/h2]
[h3]XHTML[/h3]
[p]Blah blah blah[/p]
[h3]CSS[/h3]
[p]Blah blah blah[/p]
[h3]Javascript[/h3]
[p]Blah blah blah[/p]
(if indeed these are subsections. A subsection heading should me marked up as a subsection headind, irrespective of whether it is numbered or not.)
--------------------
[h1]Site title[/h1][h2]Standards-based Design[/h2]
[p]Follow the following order to separate structure, design and behavior.
[ol]
[li][h5]XHTML[/h5]
[p]Blah blah blah[/p][/li]
[li][h5]CSS[/h5]
[p]Blah blah blah[/p][/li]
[li][h5]Javascript[/h5]
[p]Blah blah blah[/p][/li]
[/ol]
(these are not subsections. these are ordered steps. hn are titles. i used h5 for i reserved h3 for subsections)
-------------------
[h1]Site title[/h1][h2]Standards-based Design[/h2]
[p]Follow the following order to separate structure, design and behavior.
[ol]
[li][p][strong]XHTML[/strong][/p]
[p]Blah blah blah[/p][/li]
[li][p][strong]CSS[/strong][/p]
[p]Blah blah blah[/p][/li]
[li][strong]Javascript[/strong]
[p]Blah blah blah[/p][/li]
[/ol]
(ordered steps. strong represents emphasis on the text... styling is immaterial. i'd use this over the second case if i have only a short paragraph to include, not a long description. The last doesn't contain [p] for a reason... including or excluding [p] is still valid.)
-----------------
I don't think dl is appropriate here. Of course ANY paragraph NECESSARILY has a relationship to its heading. That doesn't mean it should be used in all cases. I agree with Tantek's view in this respect.
Table doesn't quite cut it unless its of the form
---------------------
XHTML_|_Blah blah
_CSS__|_Blah blah
__J.S__|_Blah blah
---------------------
though the above isn't necessrily incorrect way of representing some info.
What I’d like to know, Dan, is why you don’t provide more choices. It seems that many here, myself included, find a nested DL within an OL would be the way to go. Perhaps you omitted it for one of the following reasons:
<ol>
<li>
<dl>
<dt>Missed Opportunity</dt>
<dd>You just didn’t think of it.</dd>
</dl>
</li>
<li>
<dl>
<dt>Objection</dt>
<dd>You oppose the use of DLs within OLs</dd>
</dl>
</li>
<li>
<dl>
<dt>Cleverness</dt>
<dd>You think a mix of DLs and an OL would be perfect, but you wanted to see if we could come up with the idea on our own</dd>
</dl>
</li>
</ol>
Well, whatever your reasoning, I’d prefer you including more choices, perhaps with CSS styling included (e.g. using :first-line or not). Regardless, thanks for at least asking the questions.
“What I’d like to know, Dan, is why you don’t provide more choices.”
Well, to keep it simple of course ;-)
The questions are just a starting point for the discussion. I couldn’t possibly list every combination. I should mention that if a possible method isn’t listed, it doesn’t mean I’m opposed to it at all. Just that I know readers will come up with every imaginable scenario, oftentimes much better than I could.
The method I would use is a head tag (
hn) paired with a paragraph (p) tag. For example:<ol>
<li>
<h3>First Step Title</h3>
<p>First step description goes here</p>
</li>
</ol>
With my “document structure” hat on, I argue that this is as simple as the markup can be while still conveying everything important about the logical structure of what is being communicated. Since there are two parts contained within each list item, and each of them has a different purpose, it’s prudent to mark each with the most appropriate tag. The first line acts very much like a section header–giving a quick summary of what is to follow. The explanatory text is an expansion of the first line, just like the paragraphs following a header. A definition list (
dl) doesn’t make sense here, since you’ve shown in your example image that these are “steps.” Like, “1. Locate the CDROM Drive”, which is definitely not a “term.” So marking it up as such would be confusing. Neither is the text that would follow this a “definition.” For example, “The CDROM drive is usually on the front of your computer tower. To open it, press the eject button on the faceplate. Note that the tray that comes out makes a handy cupholder.” That’s not a definition, it’s an explanation or expansion of what was stated in the first line.With my “visual designer” hat on, I notice that this markup allows the following benefits: it automatically numbers the list items so that I can rearrange them without having to manually reorder, and it allows flexible styling via css selectors on four different tags.
With my “accessibility” hat on, I’m happy to see that using the proper level of
hntag (depending on the context of the list within the document) keeps things visually correct for css disabled browsers and provides useful information for users of screen readers.Plus, we get to avoid
<br />tags altogether, which makes us all happy.Thinking semanthically, the best method would be a
dl, dt, ddused inside ali.version ‘A’ uses the ‘br’
version ‘B’ is no list
version ‘C’ uses a paragraph inside a list
If we think of these alternatives, ‘C’ would be definitively the best, but you can of course do something like:
First Step Title
First step description goes here.
Second Step Title
Second step description goes here.
I don’t like A. It has BR’s and no P…
I would go with this:
<ol>
<li>
<h4>First Step Title</h4>
<p>First step description goes here.</p>
</li>
<li>
<h4>Second Step Title</h4>
<p>Second step description goes here.</p>
</li>
</ol>
It is valid XHTML and allows you to easily style the list.
My example, Jim, was more of a joke towards the people who claim to use semantic markup by using a definition list in order to establish the relationship between heading and paragraph.
The best method for this whole issue has been highlighted by many others already: an unordered list with heading and paragraph elements. My example of a table is a way to do it, but it is more complex, inconvenient, limited and probably even less accessible than The Right Way.
That was supposed to be ‘ordered list’, not ‘unordered list’.
Okay I may be naive here but what exactly is wrong with a table?
Syntacticaly is very little different from the heading and paragraph in an ordered list solution. The lack of automatic numbering is the only fault I can see. The Jim Pettit response is just plain silly or is there a prohibition from using CSS with tables that I have missed?
As a few people have mentioned already, the best coding solution will most closely reflect the specific situation. Given our example and the inherent lack of context (that was the idea, I know), there are a number of key questions to be asked:
1. Is the order and hence numbering critical?
2. Are the ‘titles’ actually headings followed by chunks of text?
3. Are the ‘titles’ actually an integral part of the text?
4. Could the example function with ‘titles’ alone, implying the remaining text is supplementary?
Let’s say the example represents the method part of a recipe. In this case the order is critical so we use an OL to mark up the steps. What we use to separate the title from the description then depends on the writing style. Consider this example:
3. Whisk together the sugar and egg whites.
Keep whisking until the mixture stiffens and small peaks will stand on their own.
It would not be unreasonable to use a heading followed by a paragraph here, e.g.
<ol>
<li>
<h3>Whisk together the sugar and egg whites.</h3>
<p>Keep whisking until the mixture stiffens and small peaks will stand on their own.</p>
</il>
…
</ol>
However that’s not really what we have in this case: we have two sentences; the first being much more important so it is emboldened and placed on its own line. The two sentences would also work fine without any additional mark-up, so it would be more accurate to use STRONG for the first sentence, applying display:block to create the line break. You could argue for wrapping the two sentences in a paragraph – I would say that depends on whether there are any multiple paragraph items elsewhere in the list.
#method STRONG {display:block}
<ol id=”method”>
<li>
<strong>Whisk together the sugar and egg whites.</strong>
Keep whisking until the mixture stiffens and small peaks will stand on their own.
</li>
</ol>
If our example is not a recipe but a list of independent options with descriptions then the order is not important so we can discount the OL in favour of a DL. Consider:
1. Download
Download your geocoded addresses into a spreadsheet.
2. Upload
Upload your address book for geocoding.
We have an action followed by an explanation; abstracted this gives us initial term followed by a description:
<dl>
<dt>Download</dt>
<dd>Download your geocoded addresses into a spreadsheet.</dd>
<dt>Upload</dt>
<dt>Upload your address book for geocoding.</dt>
</dl>
In this example, the numbering is not vital, so how you apply it is subjective. In earlier comments others have suggested using CSS generated numbering or JavaScript. In the real world, one would probably just type in the numbers.
So what’s my point? The final solution depends on context and meaning, but more particularly it also depends on writing style.
You could also use this method:
<ol id="headerlist">
<h1 style="display:list-item;">Heading 1</h1>
<p>First Paragraph Text</p>
<h1 style="display:list-item;">Heading 2</h1>
<p>Second Paragraph Text</p>
</ol>
(Of course, using inline styles is not how I would normally implement this, but for example’s sake…)
For those who demand semantically-correct markup…would this count? Why or why not?
This is what I use; at least this method uses dfn, an element nobody uses, yet made it to XHTML 2.
<ul>
<li><dfn>Pro</dfn> <p>It is simple</p></li>
<li><dfn>Con</dfn> <p>I am the only one who proposed it, so it must be wrong</p></li>
</ul>