Can we use a different <dl> for each <dt>, <dd> pairs? Will there be any problems with accessibility if we do it? Use-case being to simplify some Component API. For example:
<!-- Can we do this -->
<div class="container">
<dl>
<dt>First Name</dt>
<dd>Jeff</dd>
</dl>
<dl>
<dt>Last Name</dt>
<dd>Bezos</dd>
</dl>
</div>
<!-- instead of this? -->
<div class="container">
<dl>
<dt>First Name</dt>
<dd>Jeff</dd>
<dt>Last Name</dt>
<dd>Bezos</dd>
</dl>
</div>
In this case, it doesn't matter because definition lists suck in general for accessibility purposes. See my (editorial) comment in this answer, How to properly use aria selectors for definition lists in puppeteer
A definition list does not have a "list" role by default so different screen readers interpret them differently. Because of this, whether you have separate <dl>s or not won't have a huge impact.
"Real" lists, <ul> and <ol>, do make a difference. If you have a group of things that are related and are contained in one list, then it should only be one <ul> rather than a series of <ul>s. A screen reader conveys metadata information about lists such as the number of elements in the list. You get that information "for free" with your eyes if you're sighted. You can generally tell how many items are in a list (if it's not too long) whereas a screen reader user doesn't have that "seeing" option so the screen reader can tell them it's a list with 5 items, but only if it's a single <ul> with 5 <li> elements.
Related
In my HTML, I have a description list which I had to split up for presentational purposes.
Let's assume the following HTML:
<div class="styling-1">
<dl id="list-1">
<dt>Item 1</dt>
<dd>Description 1</dd>
<dt>Item 2</dt>
<dd>Description 2</dd>
</dl>
</div>
<div class="styling-2">
<dl id="list-2">
<dt>Item 3</dt>
<dd>Description 3</dd>
<dt>Item 4</dt>
<dd>Description 4</dd>
</dl>
</div>
EDIT: Side note for clarification: I cannot use a CSS grid, column layout, ... to take one semantic list and adjust the distribution of its items. The lists are required to be kept separate in HTML.
Now macOS' VoiceOver naturally announces this as two description lists. This is not a deal breaker, but since they are — semantically — a single list, it would be better to have them announced as one.
Hence my question: Does WAI-ARIA (or any other declarative tool) offer a way to tell assistive technology that list-2 is a continuation of list-1?
Now macOS' VoiceOver naturally announces this as two description lists. This is not a deal breaker, but since they are — semantically — a single list, it would be better to have them announced as one.
You're approaching the problem the wrong way round IMHO. The display of your document shouldn't dictate its semantic.
If both lists should be in one single list then do that and find a way to "separate" them on the screen.
According to MDN, it's ok to wrap <dt>, <dd> pairs in <div>:
WHATWG HTML allows wrapping each name-value group in a element in a element. This can be useful when using microdata, or when global attributes apply to a whole group, or for styling purposes.
<dl>
<div>
<dt>Name</dt>
<dd>Godzilla</dd>
</div>
<div>
<dt>Born</dt>
<dd>1952</dd>
</div>
<div>
<dt>Birthplace</dt>
<dd>Japan</dd>
</div>
<div>
<dt>Color</dt>
<dd>Green</dd>
</div>
</dl>
So you should be able to "break" this single list into two:
<dl>
<div>
<dt>Name</dt>
<dd>Godzilla</dd>
</div>
<div>
<dt>Born</dt>
<dd>1952</dd>
</div>
<div class="new-column">
<dt>Birthplace</dt>
<dd>Japan</dd>
</div>
<div>
<dt>Color</dt>
<dd>Green</dd>
</div>
</dl>
I have a global navigation for my site which is in the header of all pages. I have marked it up using the <nav> tag.
I also have a navigation present on many individual pages that only apply to that page. So if its a long article, the page navigation lets you paginate sections. This too has been marked up using the <nav> tag.
All pages also have a footer which is almost identical to one at the bottom of StackOverflow's page. There are headings to group navigation links together, some copyright information, and anything else that's interesting.
I don't think its appropriate to also markup the footer's navigation within a <nav> tag because its not intended to be the main navigation for the page or any page. SO have used a table with <th> tags to wrap the headings (and the links are rows underneath) e.g:
<tr>
<th> TECHNOLOGY </th>
</tr>
<tr>
<td>
<ol>
<li>Stack Overflow</li>
<li>Server Fault</li>
<li>Super User</li>
</ol>
</td>
</tr>
With HTML5, I understand that description lists <dl> can be used for name-value pairs. So would the following be allowed/appropriate:
<dl>
<dt> TECHNOLOGY </dt>
<dd> Stack Overflow </dd>
<dd> Server Fault </dd>
<dd> Super User </dd>
</dl>
I can't think of a better way of doing it personally (without using nav + lists), but I also don't want to markup stuff incorrectly (i.e. causing poor semantic value).
If a HTML5 expert could shed some light that would be great.
UPDATE: I've had to make a judgement call and decided that a definition list is still the most semantically appropriate thing to use. Its just my personal judgement because just using a list is meaningless.
According to the official HTML 5 Spec on the <nav> element (emphasis by me):
Not all groups of links on a page need to be in a nav element — the
element is primarily intended for sections that consist of major
navigation blocks. In particular, it is common for footers to have a
short list of links to various pages of a site, such as the terms of
service, the home page, and a copyright page. The footer element alone
is sufficient for such cases; while a nav element can be used in such
cases, it is usually unnecessary.
I think using a <dl> in your case would not be semantically correct, since that element is reserved for association lists, pairing a name/term and a value.
You said it yourself that the footer menu you have is almost identical to Stack Overflow, so if you inspect the code of their menu it is constructed with an ordered list (<ol>).
Personally, I like to use unordered lists for navigation in most cases, and to get a header in your nav, I would suggest a construct like this:
<ul id="footer-menu">
<li>
<strong>TECHNOLOGY</strong>
<ul>
<li>Stack Overflow</li>
<li>Server Fault</li>
</ul>
</li>
</ul>
In this way, each list-item of the "footer-menu" list can be a menu with a heading. Semantically, it is a list of link lists. I made a super-basic fiddle for you to illustrate how it would work: http://jsfiddle.net/psnb6tb9/
I think you have to decide if you want to use heading elements (and sectioning content elements), or not. Both ways are possible. It mostly depends on whether you want the footer content to become part of the document outline.
If yes, your footer would contain a section (possibly multiple, depending on your footer content), with several section as children, e.g.:
<footer>
<section>
<!-- you may use a heading element here, e.g.,
<h1>Sister sites</h1>
-->
<section>
<h1>Technology</h1>
<ul>
<li>Stack Overflow</li>
<li>Server Fault</li>
</ul>
</section>
<section>
<h1>Life / Arts</h1>
<ul>
<li>Photography</li>
<li>Science Fiction & Fantasy</li>
</ul>
</section>
</section>
</footer>
This might especially make sense if the list of sister sites is complex/long, and relevant for your users.
If not, your footer would not contain any heading or sectioning content elements. The dl element seems to be appropriate in this case, e.g.:
<footer>
<dl>
<dt>Technology</dt>
<dd>Stack Overflow</dd>
<dd>Server Fault</dd>
<dt>Life / Arts</dt>
<dd>Photography</dd>
<dd>Science Fiction & Fantasy</dd>
</dl>
</footer>
This might especially make sense if the list of sister sites is not really relevant or important for most of your users (I’d guess Stack Exchange’s footer falls into this category).
However, this is not really suitable if your footer would contain additional "sections" (in which case you probably should use sectioning content elements, i.e., section).
A middle ground would be to use a section/heading only for the whole list of sister sites, not for its sub-sections, e.g.:
<footer>
<section>
<h1>Sister sites</h1>
<dl>
<dt>Technology</dt>
<dd>Stack Overflow</dd>
<dd>Server Fault</dd>
<dt>Life / Arts</dt>
<dd>Photography</dd>
<dd>Science Fiction & Fantasy</dd>
</dl>
</section>
</footer>
This might especially make sense if the sister site list is relevant, but the categorization of these sister sites is not that important.
I would like to use semantic mark-up to emphasise each items importance or priority.
Here is an example of what i mean.
<ul itemscope itemtype="http://schema.org/ItemList">
<h2 itemprop="name">Wish List</h2><br>
<li itemprop="itemListElement">Google glass</li>
<li itemprop="itemListElement">Galaxy S4</li>
<li itemprop="itemListElement">MacBook Pro</li>
</ul>
I was contemplating using heading tags but I am not sure if this is the correct use. e.g
<ul itemscope itemtype="http://schema.org/ItemList">
<li itemprop="itemListElement"><h6>Least Important</h6></li>
<li itemprop="itemListElement"><h1>Most Important</h1></li>
</ul>
I'm just looking for a little advice on whether there is a CORRECT way of doing this? possibly microdata, microformats or RDFa?
You shouldn’t use headings that way. Heading content is important, yes, but that doesn’t mean that important content should be a heading. Your first example is invalid (a list may only contain li elements), your second example messes with the document outline.
The strong element represents "strong importance for its contents". You increase the importance by using several strong elements for the same content:
The relative level of importance of a piece of content is given by its number of ancestor strong elements; each strong element increases the importance of its contents.
The HTML5 spec also has an example for such usage:
<p>
<strong>Warning.</strong> This dungeon is dangerous.
<strong>Avoid the ducks.</strong> Take any gold you find.
<strong><strong>Do not take any of the diamonds</strong>,
they are explosive and <strong>will destroy anything within
ten meters.</strong></strong> You have been warned.
</p>
(note that <strong>Do not take any of the diamonds</strong> is nested in another strong element)
So this is the correct way in HTML5.
Regarding your example: If you have a wishlist that is sorted from least to most important (or the other way around), you should use ol rather than ul, as the order is meaningful and important. So your wishlist could look like:
<ol reversed>
<li><!-- least important item --></li>
<li><!-- another not-soo-very important one --></li>
<li><strong><!-- important --></strong></li>
<li><strong><!-- more important than the previous one, but not that much of a difference --></strong></li>
<li><strong><strong><!-- most important item --></strong></strong></li>
</ol>
(If it’s not sorted in this way, go with ul and use the strong elements accordingly.)
Now, you could enhance this with RDFa or Microdata, of course. Therefore you’d need an appropriate vocabulary. I don’t know any. Maybe you could make use of some sort of rating vocabulary? You could give each item a score/rating, like how much you want to have it.
Theoretical example in Turtle:
myWishlistItems:1 ex:hasImportance 0.9
myWishlistItems:2 ex:hasImportance 0.85
myWishlistItems:3 ex:hasImportance 0.7
myWishlistItems:4 ex:hasImportance 0.7
myWishlistItems:5 ex:hasImportance 0.7
myWishlistItems:6 ex:hasImportance 0.2
Alternative: state the semantics in the content, e.g. group the levels of importance.
You could use a dl, e.g.:
<section>
<h1>My wishlist</h1>
<dl>
<dt>MUST HAVE!</dt>
<dd>…</dd>
<dd>…</dd>
<dt>Would be very cool</dt>
<dd>…</dd>
<dd>…</dd>
<dt>I like that, sometimes</dt>
<dd>…</dd>
<dd>…</dd>
</dl>
</section>
or an ol with section elements, so you can use grouping headings, e.g.:
<section>
<h1>My wishlist</h1>
<ol>
<li>
<section>
<h2>MUST HAVE!</h2>
<ul>
<li>…</li>
<li>…</li>
</ul>
</section>
</li>
<li>
<section>
<h2>Would be very cool</h2>
<ul>
<li>…</li>
<li>…</li>
</ul>
</section>
</li>
<li>
<section>
<h2>I like that, sometimes</h2>
<ul>
<li>…</li>
<li>…</li>
</ul>
</section>
</li>
</ol>
</section>
If you want a scale with several levels of priority, there's no way to do that in html. Using headings would clutter the outline, in a way that's clearly "un-semantic". It's likely not worth trying to express in RDF either. What would consume it? Perhaps you have more details in mind, that would shed more light on this...
Since there's no way to express it in HTML elements or attributes, the data would not be accessible to all readers. You know how to style items with a spectrum of colors, but screen-readers wouldn't read those colors aloud.
You might simplify this to an ordered list - items in order of priority. Or two levels of importance, where a few critical items are highlighted using <strong>.
(If you take the HTML5 spec literally, you can nest <strong> multiple times for higher levels of priority. But it's unlikely to be supported for your use case. Not in current screen-readers, and not in the browser default stylesheet. So I wouldn't consider this a legitimate use).
Let's say you had something like a TV show listing, where you had a show title, and a show description. You want the listing to be accessible for people with disabilities as well.
Would it make more sense to use a definition list:
<dl>
<dt>...title...</dt><dd>...description...</dd>
...
</dl>
Or an unordered list with headings?
<ul>
<li><h3>...title...</h3><p>...description...</p></li>
...
</ul>
Which makes more semantic sense and will respond better to screen readers? (knowing that they can both be styled the same way)
If you are using HTML 4.01, you shouldn't use dl as it's defined as "definition list" (and your example does not consist of terms and their definitions). If you are using HTML5, the use of dl is fine, because the definition of dl changed.
Using headings inside of li might be a bit problematic regarding the document outline. The scope of a heading would include the start of the next li: <li><!--scope start--><h3>title</h3><p>description</p></li><li><!--scope end--><h3>…. By using section (resp. article), this could be avoided.
So, for HTML5, I think the following ways are possible:
dl
<dl>
<dt>Title1</dt>
<dd>Description1</dd>
<dt>Title2</dt>
<dd>Description2</dd>
</dl>
That would be my favorite, if you only want to provide title and description for each show (if not, see the last example).
ul + section
<ul>
<li>
<section>
<h1>Title1</h1>
<p>Description1</p>
</section>
</li>
<li>
<section>
<h1>Title2</h1>
<p>Description2</p>
</section>
</li>
</ul>
I don't like that very much. The list isn't adding much here, so why not omit it? (see next example)
headings only
<section>
<h1>Title1</h1>
<p>Description1</p>
</section>
<section>
<h1>Title2</h1>
<p>Description2</p>
</section>
Instead of section the article element might be possible, too.
You could also omit section (or article) and use headings only (in the case of section it wouldn't change the meaning); in that case you'd need to apply the correct heading level.
headings + dl
If you want to provide additional metadata (maybe in the future), I'd go with the following markup:
<section>
<h1>Title1</h1>
<dl>
<dt>Description</dt>
<dd>…</dd>
<dt>Rating</dt>
<dd>…</dd>
<dt>Time</dt>
<dd>…</dd>
<dt>Length</dt>
<dd>…</dd>
</dl>
</section>
I prefer the former. First, it seems to make more sense to me just based on the content.
But that's me. I think the markup should reflect the document structure, and since (as you say) the CSS can style it either way, why not make the markup reflect the content? A list containing items that contain a header for a title, followed by a description seems a bit of overkill to me.
But, hey. You know what they say about opinions.
In this case using a Definition list makes much more sense. Aside from this though, is it really necessary to use a list at all? It may make more sense just to use your Heading tags appropriately on the page wit a tag (x= 2-6) and have everything apply under the header of that. TV Shows in specific it may not make sense to use a "List" to display them with definitions or anything else. Again, they can be styled however, so i'm only worried about sematics with this.
Hope this helps
Zach
This is a question I have been struggling with for a while. What is the proper way to mark up name/value pairs?
I'm fond of the <dl> element, but it presents a problem: There is no way to separate one pair from another - they have no unique container. Visually, the code lacks definition. Semantically, though, I think this is the correct markup.
<dl>
<dt>Name</dt>
<dd>Value</dd>
<dt>Name</dt>
<dd>Value</dd>
</dl>
In the above code, it is difficult to properly offset the pairs visually, both in code and rendered. If I wanted to, for instance, but a border around each pair, that would be a problem.
We may point to tables. It could be argued that name-value pairs are tabular data. That seems incorrect to me, but I see the argument. However, the HTML does not differentiate the name from the value, except in position, or with the addition of class names.
<table>
<tr>
<td>Name</td>
<td>Value</td>
</tr>
<tr>
<td>Name</td>
<td>Value</td>
</tr>
</table>
This makes much more sense from a visual standpoint, both in code and in CSS. Styling the aforementioned border is trivial. However, as mentioned above, the semantics are fuzzy at best.
Thoughts, comments, questions?
Edit/Update
Perhaps this was something I should have explicitly mentioned in relation to structure, but a definition list also has the problem of not semantically grouping the pairs. The ordering and implicit border between a dd and a dt is easily understood, but they still feel slightly off to me.
Thanks for this interesting question. There are few more things to consider here.
What is a pair? Two elements together. So we need a tag for this.
Let's say it is pair tag.
<pair></pair>
The pair contains the key, and the corresponding value:
<pair><key>keyname</key><value>value</value></pair>
Then, we need to list the pairs:
<pairlist>
<pair><key>keyname</key><value>value</value></pair>
<pair><key>keyname</key><value>value</value></pair>
</pairlist>
The next thing to consider, is the display of the pairs.
The usual layout is the tabular one:
key value
key value
and the optional separator, which is usually colon:
key : value
key : value
The colons can be easily added via CSS, but this certainly won't work in IE.
Case described above is the ideal one. But there is no valid HTML markup to fit in this easily.
To sum up:
dl is semantically closest, for simple cases of key and value, but is hard to apply visual styles
(eg. to display the pairs inline or to add red border to just hovered pair). The case which fits most for dl is glossary. But this is not the case we discuss.
The only alternative I can see in this case is to use table, like this:
<table summary="This are the key and value pairs">
<caption>Some notes about semantics</caption>
<thead class="aural if not needed">
<tr><th scope="col">keys</th><th scope="col">values</th></tr>
</thead>
<tbody class="group1">
<tr><th scope="row">key1</th><td>value1</td></tr>
<tr><th scope="row">key2</th><td>value2</td></tr>
</tbody>
<tbody class="group2">
<tr><th scope="row">key3</th><td>value3</td></tr>
<tr><th scope="row">key4</th><td>value4</td></tr>
</tbody>
</table>
One more:
<ul>
<li><strong>key</strong> value</li>
<li><strong>key</strong> value</li>
</ul>
or:
<ul>
<li><b>key</b> value</li>
<li><b>key</b> value</li>
</ul>
or, when the keys may be linked:
<ul>
<li>key1 value</li>
<li>key1 value</li>
</ul>
The key and value pairs are usually stored in database, and those usually store tabular data,
so the table would fit best IMHO.
What do you think?
Following the specification (and further details) provided by Alexandr Antonov: use dl, dt, dd, and optionally div.
A combination of dl, dt, and dd is semantically fine for key-value pairs:
<dl>
<dt>Key1</dt>
<dd>Value1</dd>
<dt>Key2</dt>
<dd>Value2</dd>
</dl>
For easier styling or parsing, divs can be used as children of dl to group the key-value pairs (and makes dt and dd be grandchildren of dl):
dl { display: table; }
dl > div { display: table-row; }
dl > div > dt, dl > div > dd { display: table-cell; border: 1px solid black; padding: 0.25em; }
dl > div > dt { font-weight: bold; }
<dl>
<div>
<dt>Key1</dt>
<dd>Value1</dd>
</div>
<div>
<dt>Key2</dt>
<dd>Value2</dd>
</div>
</dl>
XHTML 2 introduces the ability to group terms and definitions using the di element
<!-- Do not us this code! -->
<dl>
<di>
<dt>Name</dt>
<dd>John</dd>
</di>
<di>
<dt>Age</dt>
<dd>25</dd>
</di>
</dl>
X/HTML 5 vs XHTML 2 > Enhancement To Definitions Lists
Unfortunately though, XHTML 2 is dead and HTML5 doesn't have di element
So, you can combine ul > li with dl > dt + dd :
<ul>
<li>
<dl>
<dt>Name</dt>
<dd>John</dd>
</dl>
</li>
<li>
<dl>
<dt>Age</dt>
<dd>25</dd>
</dl>
</li>
</ul>
I think a definition list is probably a bad idea. Semantically, they are used for definitions. Other key-value lists will often differ from definition titles and descriptions.
A table is one way to go, but what about an unordered list?
<ul>
<li class="key-value-pair">
<span class="key">foo</span>
<span class="value">bar</span>
</li>
</ul>
dl {
display: grid;
grid-template-columns: auto auto;
}
dd {
margin: 0
}
<dl>
<dt>key</dt>
<dd>value</dd>
<dt>key</dt>
<dd>value</dd>
</dl>
I used <dl> <dt> <dd> and styled them with grid
This is not my preferred solution, but it is a clever abuse of the semantic element:
Use a new <dl> per <dt>/<dd> pair:
<div class="terms">
<dl><dt>Name 1</dt><dd>Value 1</dd></dl>
<dl><dt>Name 2</dt><dd>Value 2</dd></dl>
</div>
An example with css floats and red border on hover:
dt:after { content:":"; }
dt, dd { float: left; }
dd { margin-left: 5px }
dl { float: left; margin-left: 20px; border: 1px dashed transparent; }
dl:hover { border-color: red; }
<div class="terms">
<dl>
<dt>Name 1</dt>
<dd>Value 1</dd>
</dl><!-- etc -->
<dl><dt>Name 2</dt><dd>Value 2</dd></dl>
<dl><dt>Name 3</dt><dd>Value 3</dd></dl>
<dl><dt>Name 4</dt><dd>Value 4</dd></dl>
<dl><dt>Name 5</dt><dd>Value 5</dd></dl>
<dl><dt>Name 6</dt><dd>Value 6</dd></dl>
</div>
it is difficult to properly offset the pairs visually, both in code and rendered. If I wanted to, for instance, but a border around each pair, that would be a problem.
Others before me have dealt (quite well I think) with the problem of providing visual definition in code. Which leaves the problem of rendering and CSS. This can be done quite effectively in most cases. The biggest exception is placing a border around each set of dt/dds, which is admittedly extremely tricky - perhaps impossible to style reliably.
You could do:
dt,dd{ border:solid; }
dt{ margin:10px 0 0 0; border-width:1px 1px 0 1px; }
dd{ margin:0 0 10px 0; border-width:0 1px 1px 1px; padding:0 0 0 10px; }
dd::before{ content:'→ '; }
Which works for key-value PAIRS, but presents problems if you have multiple dds within one "set" like:
<dt>Key1</dt>
<dd>Val1.1</dd>
<dd>Val1.2</dd>
<dt>Key2</dt>
<dd>Val2.1</dd>
<dd>Val2.2</dd>
However, border-styling limitations aside, doing anything else to associate sets (backgrounds, numbering, etc.) is quite possible with CSS. There's a nice overview here: http://www.maxdesign.com.au/articles/definition/
Another point I think is worth noting, if you're looking to optimally style definition-lists to provide visual separation - CSS's automatic-numbering features (counter-increment and counter-reset) can come in quite handy: http://www.w3.org/TR/CSS2/generate.html#counters
Of course, you could just use HTML Custom elements. ( spec )They're completely valid HTML5.
Unfortunately, browser support isn't that great, but if rarely do we care about such pedestrian things as browser support when we're dealing with semantics. :-)
One such way you could represent it:
After registering your brand new fancy element like so:
var XKey = document.registerElement('x-key');
document.body.appendChild(new XKey());
You write markup like so:
<ul>
<li>
<x-key>Name</x-key>
Value
</li>
</ul>
The only condition that HTML Custom elements have are that they need a dash in them. Of course, you can now be super creative... if you're building an auto parts warehouse, with lists of parts and serial numbers:
<ul>
<li>
<auto-part>
<serial-number>AQ12345</serial-number>
<short-description>lorem ipsum dolor...</short-description>
<list-price>14</list-price>
</auto-part>
</li>
</ul>
You can't get much more semantic than that!
However, there IS a chance I have gone too far into semantic-shangri-la-la (a real place) and might be tempted to scale it back to something a little more generic:
<ul>
<li class='auto-part' data-serial-number="AQ12345">
<p class='short-description'>lorem ipsum dolor...</p>
<p class='list-price'>14</p>
</li>
</ul>
Or perhaps this ( if I needed to style and show the key visually )
<ul>
<li class='auto-part'>
<x-key>AQ12345<//x-key>
<p class='short-description'>lorem ipsum dolor...</p>
<p class='list-price'>14</p>
</li>
</ul>
Hmm. dt/dd sound best for this and it is possible to offset them visually, although I do agree it's more difficult than for a table.
As for source code readability, how about putting them into one line?
<dl>
<dt>Name</dt> <dd>Value</dd>
<dt>Name</dt> <dd>Value</dd>
</dl>
I agree it's not 100% perfect, but seeing as you can use space characters for indentation:
<dl>
<dt>Property with a looooooooooong name</dt> <dd>Value</dd>
<dt>Property with a shrt name</dt> <dd>Value</dd>
</dl>
it might be the nicest way.
Except for the <dl> element, you've pretty much summed up all the options of HTML: limited ones.
However you're not lost, there is one option left: using a markup language that can be translated to HTML. A very good option is Markdown.
Using a table extension that some markdown engines provide, you can have code like this:
| Table header 1 | Table header 2 |
-----------------------------------
| some key | some value |
| another key | another value |
This means that you need a build step to translate the Markdown to HTML of course.
This way you get meaningful markup (table for tabular data) and maintainable code.
How about just placing a blank line between each pair?
This requires no special handling for long values.
<dl>
<dt>Name</dt>
<dd>Value</dd>
<dt>Name</dt>
<dd>Value</dd>
<dt>Name</dt>
<dd>Value</dd>
</dl>
What about using lists?
Ordered:
<ol>
<li title="key" value="index">value</li>
…
</ol>
Or use <ul> for an unordered list, and skip the value="index" bit.
The line from spec:
Name-value groups may be terms and definitions, metadata topics and values, questions and answers, or any other groups of name-value data.
I assume use of elements <dl>, <dt> and <dd>.
I do like Unicron's idea of putting them all on one line, but another option would be to indent the value below the definition name:
<dl>
<dt>Name</dt>
<dd>Value</dd>
<dt>Name</dt>
<dd>Value</dd>
</dl>
This way might be a little easier on the eye in ridiculously long definitions (although if you're using ridiculously wrong definitions then perhaps a definition list isn't what you really want after all).
As for the rendering on screen, a fat bottom margin applied to the dd is plenty visual separation.