Your Questions 18

by .

The clinic is getting busy with more HTML5 ailments. This week, we’ll discuss name-value pairs, e-commerce with HTML5, lightboxes and modal windows, why we need new elements, and optional subtitles.

Doctor treating a patient illustration

Name-value pairs in HTML

Eric asked:

I work on a lot of HR applications where we need to present data on employees. I’ve never been entirely clear on the best way to mark this up. For example:

Name: John Smith
Organization Code: 12345
Date of Birth: 1/1/1900

I’ve been tempted to use <dl>‘s setting the “key” in a <dt> and the “value” inside the <dd>. For example:

  <dd>John Smith</dd>

but I’m pretty sure that doesn’t mesh well with the actual intended use of the definition list. I feel like there ought to be someway to semantically relate the key to the value. Simply using just a span + class value doesn’t seem ideal. Suggestions?

In HTML5, the specification of <dl> has been widened so that it’s now an association list:

The dl element represents an association list consisting of zero or more name-value groups (a description list). Each group must consist of one or more names (dt elements) followed by one or more values (dd elements). Within a single dl element, there should not be more than one dt element for each name.

Name-value groups may be terms and definitions, metadata topics and values, questions and answers, or any other groups of name-value data.

You can read more in our article on the <dl> element.

So you can use a <dl> there, but I’d probably use a <table>. And I’d definitely use the <time> element for the DOB.

Cheers, Bruce.


Tom asked:

I’ve read “Introducing HTML 5” and a fair few articles on the web, yet I have yet to come across anything that explains how to best take advantage of HTML 5 when displaying items in a shop category? It seems the new elements are designed for feeds such as blog posts or news.

Let me answer your question with another question: Could you not, hypothetically, list shop products in a feed? Wouldn’t this make them similar to blog posts? In fact, they are very similar semantically as standalone entries within a larger system. From this, you can deduce that a shop product could be marked up in the same manner as a blog entry, or forum post, or feed item. In that case, <article> will commonly be an appropriate choice to wrap up your product.

An <article> is a self-contained discrete item. So a product could be wrapped in an <article> element (assuming that’s what you mean by “shop category”). There’s considerable discussion of that in our first Simplequiz.

To fully understand what HTML5 is trying to achieve, you have to think a little abstractly. But once you get used to that way of thinking, picking the right elements will be a breeze! Have a look at our Sectioning Element flowchart for more info.

Thanks, Mike.

Lightboxes and modal windows

James asked:

What do you think the proper markup for lightboxes and modal dialog boxes (collectively, “popups”) would be? It’s important that the element be able to contain a <header> and <footer>. I don’t like <aside> or <figure> because the popup isn’t ancillary to the content; rather, it replaces or supplants the focus. I would opt for a <section>, but your flowchart indicates that they should have headings, which not all popups will. I’d love to hear your thoughts.

IMO the actual element depends on the contents. <figure> might be appropriate, as might <details> or <form> for a login form, and <aside> could also work. <section> doesn’t always need a heading, just usually.

There was a bug filed to adopt a modal attribute — e.g., <section modal> — which would automatically make this happen. Also see showModalDialog().

I know that Hixie wants this, but it’s probably for HTMLnext rather than HTML5: there’s enough to implement already! In an interview I did with him last year, I asked:

Bruce: What’s your fave feature that didn’t get into HTML 5 that you’d put into HTML 6?

Hixie: In-window modal dialogs or dialog box — the kind of prompt you get when the computer asks you a question and won’t let you do anything else until you answer the question. For instance, the window that comes up when you say “Save As…” is usually a modal dialog. Right now people fake it with divs and complicated styles and script. It would be neat to just be able to say “make this section a modal dialog”. Like showModalDialog(), but within the page instead of opening a new window with a new page. I’d add it to HTML 5, but there are so many new features already that we need to wait for the browsers to catch up.

Full interview available at

Thanks, Bruce

Why do we need these new elements?

James asked:

Doctor, doctor!

I, like many, get very excited over all of the new ‘features’ that HTML5 brings including Video and Canvas.

What I can’t get my head around, is all of these new elements? I understand why <footer> <nav> <header> <section> have been introduced — to match what would typically common uses for divs, but I’m interested in knowing what usefulness this brings and when we will see the ‘positive results’ of the use of these new elements.

For example, when screen-scraping a page I can imagine a screenreader would find it useful to be able to identify, through element name, what part of the page is being read… is this the sole reason for these new elements (not saying that’s a bad thing!) and are any screen readers out there making use of this already that we can see? Are there other advantages?

Many thanks, James

Like you said, a screenreader is one beneficiary of the new elements, but a screenreader, at its core, is just a machine. Other machines can also take advantage of what HTML5 has to offer, from search engines to feed readers. While implementations are sparse at the moment, it’s up to people like you, me, my fellow doctors, and every other person taking an interest in HTML5 to do cool things with these new additions.

So when will see “positive results”? When we all pull our fingers out and get cracking! Spread the word ;)

Regards, Mike

Optional subtitle

Björn asked:

Hi doc,

Is it ok to have an empty h2 tag or does it always have to contain text? I ask this question because some of my pages use a subtitle (h2) and others don’t need a subtitle.

If not allowed, this would have weird consequences: the semantic meaning of an h3 tag on a page with an h2 subtitle atop would have the same hierarchical and semantic meaning as a h2 tag on a page without a subtitle, not to mention the CSS styling complications this would bring.

I’d say you shouldn’t have an empty <h2> (with a few obscure exceptions, like a placeholder that’ll be filled by JavaScript), but it’s no problem because there’s a new HTML5 element that’ll solve your dilemma — <hgroup>. You can read a detailed write up in our <hgroup> article, but in essence, when you’ve got a title and a subtitle next to each other, wrapping them with <hgroup> prevents the subtitle from getting in the document outline:

    <h2>Section title</h2>

It also means you can style the subtitle <h2> differently from following <h2> elements, for example:

h2 {font-size: 1.75em;}
hgroup h2 {font-size: 1.125em;}

Finally, if you’re using HTML5’s sectioning elements (<article>, <section>, <nav>, <aside>) and making sure that each title has a corresponding sectioning element wrapper (with the exception of subtitles inside <hgroup>), then you can use whatever heading levels you like and you’ll still get the correct hierarchical outline. It’s still best to make (and stick to) a logical visual hierarchy, from most to least important.

peace – Oli

Got a question for us?

That wraps up this round of questions. If you’ve got a query about the HTML5 spec or how to implement it, you can get in touch with us and we’ll do our best to help.

14 Responses on the article “Your Questions 18”

  • Ian says:

    Good stuff, as always, but with the last question it’s worth pointing out that <hgroup> is currently under review and may be removed from the spec (God/Dawkins knows it was already but was put back in!)

  • Ric says:

    Eric could also use Microformats hCard or some other form of meta data.

  • For some additional information on modal dialogs, or dialogs in general, in html5 you can take a look at the change proposal at

  • Simon says:

    Yeah, native modal dialogs would be quite nice. As-is, modality tends to be done with hacks like invisible or tinted divs to block mouse access to the rest of the screen, but they don’t usually cope very well with keyboard commands (tabbing, access keys, etc).

  • So you can use a <dl> there, but I’d probably use a <table>.

    I thought tables were supposed to be used when both headers (from column and row) are needed to make sense of the data:

    The table element represents a table; that is, data with more than one dimension

    Imho, name/value pairs do not seem to fit in that category. Unless I misunderstand what data with more than one dimension means.

  • Michael Updegraff says:

    RE: Name Value Pairs in HTML

    If using a table would you use the th element as the name, and td be the value? This very situation came up at work today.

  • Jamie Stewart says:

    @Michael – Personally I would only use tables if it requires multiple values associated with your headings. For a list of headings, each accompanied by a singular value I would always go for definition/description list.

  • Michael Updegraff says:

    @Jamie – thank you, that’s a good rule of thumb.

  • Lars Gunther says:

    Just a reminder that hgroup is being questioned and that there is a propsal to change it and another to drop it completely.

    And that today there is no browser or a single popular toool in existence that actually honors the element, thus using hgroup today won’t do anything of real value.

    In summary hgroup is not implemented today and might be dropped from the spec. A recommendation should be to keep an eye on the element and if it is kept and starts to get implemented, then it may be used.

  • Benjamin Knight says:

    I’m very intrigued by the question “Why do we need these new elements?”

    Simply put, it’s a very valid question, and I think most of us developers operate under the notion that we should use HTML5’s new elements just because we know it’s right and we understand its potential. It’s sort of an imagined payback. We imagine the Google bot and screenreaders crawling our sites and gobbling up our yummy semantic code. I guess HTML5 outliners can give us at least a little bit of a sense of accomplishment. Also, let’s be honest, HTML5 is cool and I think for a lot of us that’s reason enough to use it without really questioning why we do.

    For me anyway, the best parts of HTML5 are the APIs that come with it, those seem to be the things with the biggest immediate paybacks. The “best way to mark something up” is a fun game to play but I don’t think you’ll ever see a huge return for spending 20 minutes playing it.

  • Emma says:

    I’d say you shouldn’t have an empty (with a few obscure exceptions, like a placeholder that’ll be filled by JavaScript)…

    I’d say there should never be empty elements on a page. If you’re going to be filling with JS then inject the markup at the same time.

  • Bruce Lawson says:

    Benjamin Knight said,

    “The “best way to mark something up” is a fun game to play but I don’t think you’ll ever see a huge return for spending 20 minutes playing it.”

    I disagree. Marking things up correctly has a relevance on your search engine placement (at least according to Google) and makes your site more accessible to people with disabilities.

  • Prateek says:

    Hey, I have been googling for 2 weeks but couldn’t find an alternative for fancy box as I have to use it in my app. Is there any option in html5 that will work on my android device.

  • S Ghosh says:

    Very good article. Thank you and keep posting.
    – S Ghosh
    What Is HTML5

  • Join the discussion.

    Some HTML is ok

    You can use these tags:
    <a href="" title="">
    <abbr title="">
    <blockquote cite="">
    <del datetime="">
    <q cite="">

    You can also use <code>, and remember to use &lt; and &gt; for brackets.