borderline semantics
As modern-day web developers, we eat, breath and sleep semantics. When adapting designs to html, making our documents as semantic as possible is one of our main priorities (the other being structuring). Lucky for us, html is not too complex and most elements have a clear semantic meaning. Even the generic ones, like div and span elements, have a clear purpose. But work with html long enough and you'll definitely run into some borderline cases.
clear-cut semantics
html is really not all that difficult to understand. It has a limited set of elements and most of these are clearly defined. The difference between a list, paragraph or heading is easy to explain to others just starting out, so semantically they are pretty sound. Only a few marginal cases exist (like the address element) where you could argue about the logic behind the meaning of a certain element.
Apart from those elements, there are a few others which are more open for discussion. The table element is probably the most notorious one, mainly because it just isn't that simple to explain the meaning of tabular data in an unambiguous way. Another famous one is the expansion of the use of lists, where at one point people actually started to wonder whether an article wasn't just a list of paragraphs.
These are just a few examples of cases where the semantic value of an element isn't as clear as it could be. But there's also a different kind of semantic issues, which I usually refer to as borderline semantics.
borderline semantics
If you've worked with html for long enough, you'll know that even the elements that at first seemed easiest to understand can bear some unforeseen ambiguities in them. Take for example a simple list. One of the most basic html elements, used to mark up a summation of items. But what about a list with only one element? Can you still call that a list? A similar question can be voiced about tables and paragraphs. Can we use the table element for a typical data view (one column of headings and one column of information) and how about using the paragraph element for a single line of text?
I think most of us can go on gut feeling when a problem like this arises, but gut feeling is never a good explanation when someone asks you about the "why" of things. So I sat down and tried to come up with a good method of how to tackle questions like this. The answer, as is often the case, was quite simple.
The key of this problem lies in attaining a broader view of things. There's nothing wrong with a list only containing one item if the list has the ability to actually contain more items. Take for example a related links component underneath an article. If you define the block to only contain one link, at all times, you shouldn't be using a list. If, on the other hand, you define the component to be able to contain multiple links, you need to use a list, even if there are articles where only one related link is given. Just look at what a component can become, rather that its current state. The semantic value of the element should only change when there's a functional change of the component.
what is and what will be
The semantic value of an element should not be determined by its current state, but should be seen as part of the broader behavior of the component it belongs too. There's nothing wrong with a list having only one item, but if that is all it can ever have, it's simply not a list and it's better to use a div element. Thinking like this eliminates quite a few of the nastier semantic issues I've been having, and it's also easy to explain to others.