Your Questions 18

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.

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:

<dl>
<dt>Name:</dt>
<dd>John Smith</dd>
</dl>

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.

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.

E-commerce

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.

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:

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.

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:

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”

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!)

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).

@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.

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.

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.