Your Questions #15

by .

Doctor treating a patient illustration The clinic is busy as ever with more HTML5 ills. This week, we’ll cover marking up Wikipedia infoboxes, anchors in <hgroup>, <figure> for avatars, header(s), and how to use <code> and <pre>.

Wikipedia Infoboxes

Andrés asked:

Hello. I want to ask how I can code some stuff based on Wikipedia infoboxes with HTML5, which most of the time uses tables. I think that all of these can be surrounded by a figure tag, but I’m not sure about the subtleties.

Reference page:!_%28album%29. It has a main infobox that:

  • Has a heading
  • Has a thumbnail image
  • Has 3 sections each separated by a faux table heading:
    • One that has a table with two columns, one with keys and other with labels, which I believe that can be done better with definition list but not sure if table is suited too
    • One that has a list of links of magazines that have reviewed the disc. I believe it is fine as is coded but still
    • One with a “chronology”, which is like a navigation menu in a table with the previous, current (no link) and next installment. Not idea if there’s an ideal way to markup it

There’s a 2nd infobox that feature a long list of links of related contents divided by some kind of table headings. I suppose it may better done by lists but there’s may be another approach. The 3rd infobox repeats the chronology noted above.

It’s a blessing and curse of HTML that there is often more than one correct answer. This is even more true with HTML5. Let’s look at the Help! album page:

  • Is the infobox essential to understanding? If yes, use <figure>; if no, use <aside> (inside <article>). If this data is just a summary of information already in the article, <aside> would be appropriate. If it contains unduplicated data, I prefer <figure>. I don’t think <table> is the best container element for the infobox.
  • For the “studio album” details section, either <dl> or <table> would be appropriate.
  • “Professional reviews” and “chronology” both look like lists, although either could also be a table.
  • I actually find the chronology formatting quite strange, as it’ll only work well for 1–3 items. Assuming this would be used for a full chronology, an ordered list would be more suitable. I guess that this is only to list the previous and next albums (a partial chronology). I don’t think it’s suitable for <nav> as the Beatles released more than three albums (but might be if all albums were listed). It’d be good to use rel="previous" and rel="next" attributes on these links.
  • The blue background titles would be best represented by <h1><h6> titles, ideally titling each <section>.
  • I’m guessing the second infobox you refer to is the large table of links at the bottom of the page. This seems appropriate as a series of inline lists (ordered by time or alphabetically) in a table.

    I’m also guessing the third infobox you refer to is the “US Release” one that uses the same template as the first. The first infobox notes apply here too.

    Peace — Oli

No anchor elements allowed in <hgroup> elements

Daniel asked:

Consider the following code:

<a href="/">
  <h2>Sub Title</h2>

When using to validate my page, it says that this is invalid “Error: Element a not allowed as child of element hgroup in this context.”

I know that this validator is in beta (at least I think so), so maybe it’s wrong, but would you tell me if this is really valid or invalid? If it is invalid, would putting the anchor tags inside the heading tags fix it (despite having to use more markup :(

This example is in fact invalid. Only <h1><h6> elements can be a child of <hgroup>.

You can get around it using block-level links like so (but bear in mind some browsers have trouble with block-level links):

<a href="/">
  <h2>Sub Title</h2>

Hope that helps.


Using <figure> and <figcaption> as the avatar/id in a blog comment

BigAB asked:

Would this be a proper use of the figure and figcaption tags: representing the common case of avatar/username on comments (or forum entries) as a figure? Example:

<article class="comment">
   <h4>Comment on <a href="/the-blog-article">The Blog Article</a></h4>
       <img class="avatar" src="/my-avatar" />
       <figcaption><a rel="nofollow" href="http://my-website.exp">My Name</a></figcaption>
   <p>I am commenting on our blog article. This is my comment. I have much to comment on and am doing so in this comment.</p>
   <p>Thank you for letting me comment here.  I think it good that we can comment.  Feel free to comment on my comment.</p>

Doesn’t feel right to me. The spec says this:

“The figure element represents some flow content, optionally with a caption, that is self-contained and is typically referenced as a single unit from the main flow of the document.

The element can thus be used to annotate illustrations, diagrams, photos, code listings, etc, that are referred to from the main content of the document, but that could, without affecting the flow of the document, be moved away from that primary content, e.g. to the side of the page, to dedicated pages, or to an appendix.”

By “referred to”, I understand that to be “See figure 9”, but your example doesn’t do that. Personally, I’d just write:

<a href="#"><img alt="Bob's homepage">Bob Smith</a>

Cheers, Bruce

HTML5 Header

Josh asked:

I have read up a lot on the header element, and nesting numbered headers inside the hgroup element, and so forth. I’ve put a lot of the things I’ve seen on into practice on my own site, but was wondering if I can actually put the numbered header anywhere in the header, instead of having the numbered header (eg, h1-h6) first.

I was also wondering if putting links inside an h1-h6 itself would actually damage either page rank or usability. I mean, I don’t imagine how it would, but I like to be very careful, almost too careful with how I do things. I do auto-validations of all my markup constantly, and do manual validation once in a while. So, I’m a little OCD when it comes to items such as the header. Of course, putting the a element around the header itself may not hurt either – but like I said, I love to be careful.

Plus, great work on the site and the organization, folks! Some friends and myself make some articles on topics such as CSS and XHTML, more-recently HTML5, and it’s refreshing to come here to see a view from some real experts!

Thanks for your e-mail.

  • <h1><h6> elements can go anywhere inside <header>, although we advise you to mark up your content first before thinking about CSS, so your page makes sense even without CSS.
  • If you have more than one <h1><h6> as children of a <header>, wrap them in <hgroup>. If there’s nothing else in the <header>, just use the <hgroup> and not the <header>.
  • If you only have one <h1><h6> and no other heading content, you don’t need either <hgroup> or <header>, although they might still be useful for a CMS template (where more stuff might be inserted) or as CSS hooks.
  • Links inside <h1><h6> don’t affect page ranking or usability in isolation (but might affect usability if, for example, the link is to the current page).
  • You can use block-level links around a <header> or <hgroup>, but test and be careful of Firefox’s vomit bug.

Finally, while we applaud your studious approach to coding, do keep in mind that HTML is quite forgiving :-) As long as you validate occasionally and follow the spec, you’ll be fine. The web stack is a deep rabbit hole to go down, so while it’s great to do the best you possibly can, we also prescribe going outside once in a while ;-)

Peace — Oli

<code> vs <pre>

Daniel asked:

Dear HTML5doctors,

How should I markup code example correctly? I have some that are inline inside my text, I think that’s code then, but others are multi lined. I need them to be white-spaced correctly as they would get them with pre, but isn’t that semantically wrong?

Or do I put <code> inside <pre>? <pre> inside <code>? Or is <pre> to <code> as <b> is to <strong>?

Many thanks

For inline code, just use <code>...</code>, a phrasing (inline) element. For multi-line code, use <pre><code>...</code></pre>. <pre> is a flow (block-level) element. Finally, the entities &lt; and &gt; map to < and >, which you’ll need to escape inside any HTML code snippets (although you only really need to do the first one).

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.

8 Responses on the article “Your Questions #15”

  • Ian P says:

    Hi, helpful collection of questions and answers, thanks.

    In the first example where you’re giving a details for an album: I’m still unsure if we should be using dl to define things by giving them values as opposed to defining what the things being defined actually mean.

    I’m sorry if that make absolutely no sense at all. I’m struggling to think of a better way to ask this.

  • Jose Pedro says:

    I always saw <pre> elements as block level equivalent of the <code> element. Isn’t

    <pre> ... </pre>

    enough for marking large code snippets? Even further having into account that all whitespace is properly parsed. The only reason I can see to use <code> inside <pre> is for marking up each line accordingly (with CSS).

  • The spec is clear about the nature of the <pre> element and the fact that it isn’t inherently related to <code> (and its relatives) which convey additional semantics:

    The pre element represents a block of preformatted text, in which structure is represented by typographic conventions rather than by elements.

    To represent a block of computer code, the pre element can be used with a code element; to represent a block of computer output the pre element can be used with a samp element. Similarly, the kbd element can be used within a pre element to indicate text that the user is to enter.

    For an appropriate use of <pre> that is completely unrelated to computer-related code, consider a poem where the poet has chosen to indent every second line by one space, and every third line by two spaces. The rules of HTML rendering dictate that such spaces should be collapsed into a single space, thereby destroying the effect the poet was seeking to create. Wrapping each line in a non-smeantic element and using CSS to create the indentation would not be appropriate, as the indentation is (in the rarefied mental plane that poets inhabit) not merely visual formatting, but an inherent part of the semantics of the work as a whole. I humbly suggest that only <pre> would do in such circumstances.

  • Lars Gunther says:

    Just a quick note about hgroup. There is still much discussion about the element on the HTML5 WG mailing list. It might be changed, removed or substituted. It’s a bit early to us it for anything but experiments.

  • Maybe it’s time to simply drop nesting restrictions. I don’t see where they could come in handy, and most of the time they simply prove too restrictive making them counter-productive. There isn’t any sane reason why a heading in an hgroup tag couldn’t be linked.The block level link is only a 50% solution as you can’t choose what heading to link (or provide separate links for each heading).

    Are there any cases where restrictive nesting of html elements is useful?

  • Chris says:

    I don’t like using <pre> for code blocks. It’s just a presentational element and has no semantic meaning. It’s like using <tt> for fixed fonts. It should be a <code> with css formatting.

  • Bruce Lawson says:

    But, Chris,if you don’t use <pre>, relying on CSS alone, the whitespace isn’t preserved if you view the page in a no-CSS browser (or one that doesn’t understand that rule).

    And that’s bad, because whitespace has meaning, eg in code or poetry or ASCII art.

  • Chris says:

    Valid point, Bruce. Didn’t think of that.

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