SimpleQuiz › Part XV: Conclusion

For the first time, the last SimpleQuiz had over 100 comments. Wow. And once again, “lists” prove that they are the most easily debated when talking about semantic markup.

Not because it was the first comment — but because it was the first comment to suggest a method that many others agreed with, the free T-shirt goes to compuwhiz7, with this comment:

For example, you could have done this:

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

Many agreed that using <hn>s and paragraphs would be a nice way of showing the relationship between the step title and step description, while still using an ordered list. Another variation that seemed popular was the nesting of a single definition list within each list item:

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

While it may seem a bit weird to have a series of one-item lists — I’m never one to argue that a list can’t contain just one item.

If I could afford it, T-shirts would’ve also been handed out to (among others) Tantek, for his organized analysis that I could’ve copied verbatim as the conclusion — and also to Chris Schreib (1,2,3) for perhaps the longest comment in the history of long comments :-).

Thanks to all that commented on this one, and for (as usual) providing a fascinating discussion.

All SimpleQuiz questions and conclusions can also be viewed on one page.


  1. Tom Werner says:

    And thank YOU for organizing these little jousts of the mind. It makes us all think, and for that, the web is a better place.

  2. compuwhiz7 says:

    First of all, thanks a lot to Dan for the shirt, and, most importantly, for hosting these supremely fascinating “jousts of the mind,” as Tom put it. They really help me, for one, understand the novel endeavor into which I have entered, naïvete intact. :)
    Second of all, I now am going to take the liberty of changing my opinion. I’m not quite sure as to how people interpreted my alternate markup suggestion, but in a nutshell, I think that I was hasty in concluding that that scenario was invalid. Because, as many said, the items in question are neither definition terms nor definitions, it makes more sense to revert to a standard list and simply use headings and paragraphs, as I unwittingly suggested.
    So I suppose that some of SimpleBit’s readers had a beet understanding of my own comment than I did!

  3. compuwhiz7 says:

    Ergh… in above comment, it should be “better understanding,” not “beet understanding.” D’oh!

  4. Hass says:

    “I’m never one to argue that a list can contain just one item.”
    How about if Merriam-Webster and I do? “1 a : a simple series of words or numerals (as the names of persons or objects)”. Note: “series”, “words”, “numerals”, “names”, “persons”, “objects”. A guest list is a list of guests. Ever heard of a list of guest?
    Semantic-”1 : of or relating to meaning in language”. I’ll argue that we can’t have meaning in markup if we don’t have meaning in our language to begin with! Please don’t recommend one-item lists.

  5. Bo says:

    “How about if Merriam-Webster and I do?”
    I think you miss the point we are not speaking English here we are speaking (x)html, so the dictionary quote is:
    “All lists must contain one or more list elements”.
    From the source Lists.

  6. Exactly, Bo. I was referring to that exact passage of the spec. It makes sense as well — that a list can contain one item. Especially if, in the future, a one item list would expand with more items. If more items are added, the structure is already in place.

  7. Hass says:

    Fair enough- a guest list-in-waiting.

  8. igner says:

    I’ll reiterate the others’ thanks for posing the questions and fostering intelligent (and dare I say civil) discussion of the topics. For a relative newbie, these conversations provide valuable lessons, both from a practical code perspective and from a philosophical perspective.
    Semantically a one-item list is entirely reasonable, but I’m still struggling with the merit of the nested definition lists. If semantic markup is targeted at human readable markup, then the nested definition list adds a level of complexity without any significant added value. If we’re talking machine readable markup, then I can see an argument for the nested definition lists. However, I’m not entirely sure there’s a significant distinction between:
    a) parsing a header / paragraph combination inside a list item
    b) parsing a defition list nested inside a list item.
    In fact, I’d be inclined to think that the latter would require added effort to parse, creating more opportunity for error.
    I may certainly be wrong on this point; I make no claims to be anywhere near an expert on any of these topics. I’m also not looking to stir up another 100+ posts, but if someone can clarify for me whether there’s a real-world motivation for the nested dl’s (such as an existing parsing or transformation engine), please email me–I’d love to know about it.

  9. Thank you above all, Mr Cederholm. I don’t know how you manage to post strictly interesting stuff (as far as I’m concerned), but I know you’ve been the only one to perform this lately. This site just rules.

  10. jason says:

    Hey Dan. What gives? No more free t-shirt contest and the posts around here drop off the radar!

  11. Hemebond says:

    Hmm. Recent experiments raised this very issue for me. I ended up using the nested definition lists, but I’m not happy about it. DL’s don’t really appeal to me because there’s no container for each group. There needs too be a way to name sub/nested lists. Does the standard accept anything but li within a list?

  12. Will Boucher says:

    Thank you all for another round of thought provoking comments. It seems the main thing all can agree on is that communication is always a hostage of language. Any language, no matter how well thought out will always have a certain amount of ambiguity. Prefect communication of ideas and the undrlying relationships between them is a holy grail. We hopefully move closer to that goal. I doubt that will ever find one method that successfully works in all situations. We live, we learn, we play stacking the blocks in different ways until we find the best method that we can at present to meet a specific need.
    For my two cents I do think that the modified version of C using the header n and paragraph elements was the cleanest way of marking up the steps.
    That’s just my opinion, I may be wrong.

  13. Adam van den Hoven says:

    I realized I’m late with this suggestion but Steve Smith almost jumped to a conclusion that seems would work for the general case.
    I came to this conclusion because I solve problems like these the way I do algebra (which I loved “back in the day”), I find the most general solution first then apply it back to the specific problem.
    This quiz gets a lot more complex if each step has a sequence of sub steps, something that makes a whole lot of sense. Any relatively complex process is likely to do this.
    In XHTML 2 li elements have (PCDATA | Flow)* for the content model. As we all know, Flow is the aggregation of Inline, Block and Heading elements.
    None of this is new.
    What is new is that Heading has 7 elements, one more than in all the previous incarnations of HTML. h is a valid flow element. Although the text describes h only in terms of the section element (in a way that I believe ruins semantics) there should be nothing stoping us from using it in most useful manner namely

      <h>This is a step</h>
        <h>This is a substep</h>

    Now we have a structure that adequately describes all our semantics. It should be valid XHTML 2, of course its still a working draft so that might change.
    Actually, I hope it does change in the following way. The current doc makes section elements no better than div tags (with slightly better semantics) and the example they give is totally wrong headed to my way of thinking.
    What I would like to see is h removed from Heading and a certain number of elements (li, section, form all come to mind at this point) that permit an initial h element followed by (PCDATA | Flow)*. But that’s an argument for a different topic. ;)