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.

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.

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.

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 webstandards.org.

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:

<article>
  <hgroup>
    <h1>Title</h1>
    <h2>Subtitle</h2>
  </hgroup>
  <p>...</p>
  <section>
    <h2>Section title</h2>
    <p>...</p>
  </section>
</article>

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.

HTML5 syntax dilemma

Manuel asked:

In theory, HTML5 syntax is very lazy but, in fact, when you write a HTML5 page you follow some conventions that originate in the XHTML era: lowercase code, double-quoted attribute values, properly closed elements, proper element nesting. While this practice is rational and admirable, some people take a further step towards a XHTML-style syntax: they don’t use attribute minimization and do terminate empty elements. Of course this further step is not necessary to write clear HTML5 code, but could be fostered if you look at the following points:

1. it makes [it] easier to upgrade legacy XHTML code (which represents the bulk of the web even if it’s generally served as text-html) to HTML5 (it’s just a matter of doctype change)
2. it makes [an] easier the shift to HTML5 for web developers, since they are generally used to write XHTML
3. it could set a coding standard in the field

What do you think about it?

I disagree. I think there’s nothing lazy about HTML5 syntax. You could say that it’s lazy that in HTML we write <hr> rather than <horzontalrule>, but the fact is, it’s a specified part of the language.

Furthermore, “legacy XHTML” code does not represent the bulk of the Web; 61% of the Web is HTML4 according to the Opera MAMA study in 2008.

But it doesn’t matter. You say tom-ay-toes, I say to-mah-toes; you like XHTML syntax, I like HTML syntax. They’re all the same to a browser, if served as text/html.

Cheers, Bruce

Sections within sections

Corey asked:

Don’t know if this has been asked before or not, as I couldn’t find anything to tell me otherwise. I read through the article and section information and understand more or less how they function, but I’m wondering if there is a case to be made about having a section within a section. Your article doesn’t really touch on whether this is appropriate or not.

The reason I ask is because I have a page that is broken into different parts (introduction, description, requirements, etc) that are all part of the same overall article. Now if I wanted to break down say, the requirements section into sub-sections (technical, stylistic, semantic, etc) would it be all right to wrap those sub sections in a section tag (that is within a section itself), assuming I put the correct header on it?

Thanks a bunch,

Yes, you certainly can nest <section>s — in fact, that’s pretty much exactly what <section> is for! If you look at the source of some of our more recent articles — e.g., this article or our microformats article — you’ll notice how we’ve split the article into sections.

In theory, using nested sections means that we’ll be able to do away with <h2>–<h6>, since a new heading level is implied with each nested section. In practice, however, it’s not as simple as that, so we suggest sticking with the usual <h1>–<h6> heading structure even if you decide to nest sections.

For your example, this code would be entirely appropriate:

<article>
  <h1>Article name</h1>
  <p>...</p>
  <section>
    <h2>Introduction</h2>
    <p>...</p>
  </section>
  <section>
    <h2>Description</h2>
    <p>...</p>
      <section>
        <h3>Technical</h3>
        <p>...</p>
      </section>
      <section>
        <h3>Stylistic</h3>
        <p>...</p>
      </section>
  </section>
  <section>
    <h2>Requirements</h2>
    <p>...</p>
  </section>
</article>

Each part of the <article> is wrapped in a <section>. The one exception might be the introduction, unless you are explicitly declaring a heading with it. You don’t always need a <header> element if it would only contain a single <h1>–<h6> element. In that case, the heading on it’s own will be fine. Bruce has a good post on the difference between articles and sections.

Hope that helps, Rich

Since we’re being semantic…

Rob asked:

HTML5 is working towards being more semantic, but I don’t think the <link/> tag is semantic at all…especially for stylesheets! Has anyone ever suggested changing the specification for the <style> tag to have an ‘src’ attribute that would point to the CSS file? Current:

<link rel="stylesheet" href="style.css" />

Suggestion:

<style src="style.css"></style>

I think most implementors would say that the current way works well enough. Breaking backwards compatibility for the sake of theoretical purity was where XHTML 2 was heading before it was finally curtailed. HTML5 takes stock of where we are, warts and all, and builds on that. (I feel your pain: I always want <img> to be <image>.)

Cheers, Bruce

Describing the content of <figure>

Sverri asked:

A lot of things can be presented as figures (everything from a simple quote to an information-dense canvas). The first thing that came to my mind was using e.g. a “type” attribute. For example:

<figure type="code css">
  <figcaption>Styling p tags</figcaption>
  <code>p { margin-bottom: 1em }</code>
</figure>

That would be a dead simple way of succinctly telling user agents, search engines, etc. what kind of content they can expect to find in the figure. However, since this is not valid HTML5 (as far as I know) how would you recommend describing the contents of a figure, so as to make it more accessible to non-human agents?

Thank you.

Bruce replied:

What would be the purpose of doing so? For example, it’s easy for a non-human agent to see that your example contains code, or that:

<figure>
  <video>...</video>
  <figcaption>...</figcaption>
</figure>

contains video, or that:

<figure>
  <img />
  <figcaption>...</figcaption>
</figure>

contains an image. So I’m not sure of the use case for a type attribute.

Sverri then responded:

The way I think about this is that figures are images of sorts, or embedded content. A “type” attribute (or perhaps a more aptly named “of” attribute) would be the equivalent of the “alt” attribute of img. It is extra information, and as such would not always be needed, but sometimes it can be an important part in how you present the content.

As for use cases:

• Aiding search engines better understand the content
• Browsers can use such information to make browsing the internet richer

I realize that you can use some other way of describing the content, such as titles, itemscopes or other ways of adding metadata. A dedicated, but optional, attribute for this would not be such a bad idea in my opinion.

To sum up, I suppose what I am getting at is that content in a figure is not always so well defined on its own. A snippet of code, for example, is given more meaning if it is in a context, such as “css”, “algorithm” or “while loop”.

I hope I am being clear enough in what I am saying.

Bruce followed up once more:

You are clear. There have been many such discussions during the development of HTML5 (and preceding versions of HTML). For example, why not have a <name> element for marking up people’s names, analogous to <time>? Why not have <geo> or <place> or <location>?

The use cases you describe (aiding search engines and browsers) are equally applicable.

But it comes down to two factors:

First, HTML is not a specialised language. It’s a generalised language, and there are some cases that can’t be marked up with the existing crop of elements. (There are already over a hundred.)

Second is that minting new elements and attributes isn’t “free”. It’s more for authors to remember (and get wrong), it bloats parsers in browsers, and it makes regression testing harder. So if a new addition to the language doesn’t solve a very common problem, it isn’t added to the language.

As you said, microdata/microformats/RDFa can be used to extend the language for specialised cases.

Thanks, Bruce

Web app buttons and toolbars: anchors, buttons, or commands?

Christian asked:

If you’re creating a toolbar for a web app, or perhaps even a “Share this page” widget, should one use anchors, buttons or commands?

A toolbar should be HTML5 <menu> with nested <command>s, but browser support is zilch. I’d use a list of buttons, personally. I think <button> is the right element to perform tasks that might need an “undo”, like “Tweet This” or “Delete Document”.

Bruce

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.

Separation of formatting and content

Graham asked:

When I first started learning html and CSS I was constantly told not to use b or i tags as the idea was to completely separate formatting from content. Is this now not the case?

In HTML 4 (and XHTML 1.x), the elements <b> and <i> (plus some others) were presentational — they only had visual meaning. This doesn’t work so well for blind users, for example.

In HTML5, presentational elements have either been cut or, as in the case of <b> and <i>, given semantic meanings to make them media-independent. You can find out more here: The <i>, <b>, <em>, and <strong> elements and The <small> and <hr> elements.

So to directly answer your question, in HTML5, <b> and <i> are now content (semantic), not formatting (presentational).

peace – Oli

Custom elements

Eric asked:

It is possible to use custom elements in HTML5 to be more semantic; however, is it ill-advised? For example:

<footer id="page-footer">
<copyright>Copyright ©...</copyright>
</footer>

Umm, no, HTML5 doesn’t allow “custom elements”. While browsers will try to recover gracefully if you do this, making stuff up is definitely ill-advised — something like <copyright> will have no meaning for browsers and could lead to problems in IE.

If you want an element for a copyright statement or other short legalese, there’s already a perfectly good one in <small>.

If you can’t find a more semantically appropriate element, use <span> for phrasing (inline) content, <p> for a block of phrasing content, or <div> for flow (block-level) content, and add a class name that indicates the semantics — e.g. <span class="lorem">Lorem ipsum</span>.

Hope that helps!

peace – Oli

Marking up social links

A reader asked:

Could a list of share icons (twitter, facebook, etc) be considered a candidate for use of the nav element? and do links in a nav element have to be into the same domain name”?

<nav> is for navigation around your content. On my personal site, I have a link to my Flickr photostream marked up in the same container as links to my own contact page, etc. I think the link to Flickr is conceptually no different to navigation within my personal site: it’s all my content. If my photos were on my own domain (as they used to be), I wouldn’t hesitate to include them in <nav>, and I wouldn’t hesitate to include this same content within <nav> today.

A list of share icons isn’t <nav> for two separate reasons.

First, they aren’t meant to take you somewhere else. They’re designed to perform an action of tweeting/”liking” a link to a page.

Second, and most importantly, they’re not navigation around your content. As the spec says “Not all groups of links on a page need to be in a nav element — only sections that consist of major navigation blocks are appropriate for the nav element.”

As a list of share icons is tangential to your content, I’d probably use the <aside> element: “The aside element represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content. Such sections are often represented as sidebars in printed typography”. For more details, check out our <aside> revisited article.

Social links are the kind of thing that could be cut from a feed reader without diminishing the value of the content. As an additional note, remember that you can also place an <aside> at the end of an article, like a footer. In spite of its name, <aside> doesn’t have to be a sidebar.

Thanks, Bruce and Mike

Sections with no visible titles

Francesco asked:

I have some divs, in a page, that semantically would make more sense as sections as there are natural headings for them, but they’re not written *inside* them, they’re outside. There are tabs to switch the visibility of these sections, and the tab navigation is on their left… so the actual title is only there, and not repeated inside of the sections. But besides that they really are sections… they even had “class=section” in the old version.

What would the best solution be? Put an h1 in there with display:none? It would make the outline correct, but it looks like a hack.

You should reorganise your markup to ensure the headings are within the section. Then you can use some CSS positioning trickery to move them into place. Don’t use display:none, though, as that’s invisible to everyone, including assistive technologies like screen readers.

Cheers, Rich

HTML5 <canvas> and the DOM

Elango asked:

Is it possible to get the elements i have drawn into the canvas using some API. Say for eg i draw 2 circle and 2 lines is that possible for me to get these information from Canvas by using DOM API’s

No. Think of a canvas like a canvas you would physically paint on. If you paint a red stroke and then paint over that in blue, you can’t get back to the original red stroke. The canvas API works the same way: once your pixels are committed, you can’t go back.

You want SVG (or try out Raphaël).

Cheers, Remy

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.

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: http://en.wikipedia.org/wiki/Help!_%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:

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

When using http://html5.validator.nu/ 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="/">
<hgroup>
  <h1>Title</h1>
  <h2>Sub Title</h2>
</hgroup>
</a>

Hope that helps.

Rich

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>
   <figure>
       <img class="avatar" src="/my-avatar" />
       <figcaption><a rel="nofollow" href="http://my-website.exp">My Name</a></figcaption>
   </figure>
   <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>
</article>

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 HTML5Doctor.com 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.

Aside question

Lukasz asked:

I wonder if such use of aside tag inside section would be correct:

<section id="about">
  <h1>about me</h1>
  <p>blablabla</p>
  <aside>
    <h2>you can also find me on:</h2>
    <ul>
      <li><a href="#">twitter</a></li>
      ...
    </ul>
  </aside>
</section>

Thanks in advance for any help and keep up the good work!

Hard to give definitive advice without seeing the whole page, but it seems fine to me. See Mike’s article on <aside>.

In general, use <aside> for a section of a page that consists of content that is tangentially related to but separate from the surrounding content. In print, this would be a sidebar, pull-quote, or footnote. On a weblog article, this could be article metadata in the margin or the comments section.

If your social network links are main content, then <aside> isn’t the element (maybe <section>, maybe <nav>). If they’re just related content (i.e., they could be omitted when showing this page in a feed reader), then <aside> is a good choice.

peace – Oli

Blogging services

Patrick asked:

Do you have any suggestions to people implementing HTML5 on blogging services like Tumblr? The last time I checked, there are problems making HTML5 blogs on these sites:

• Tumblr – inserted iframe breaks HTML5 conformance
• Posterous – no Javascript allowed at the moment (according to their doc)
• Blogger – it doesn’t preserve my HTML5 DOCTYPE

Are there blogging services that don’t mess with the HTML5 markup?

I used to use Tumblr, and you can use HTML5 in your templates. But any new HTML5 elements (e.g., <section>) in your articles get munged, even using the “Raw HTML” setting. Unfortunately, I think that managed blogging services will probably be a little slow to adopt HTML5 (= fix the HTML5 errors they/their tools have), and you’ll have to use your own CMS for that level of control.

You can of course build your own theme for something like WordPress, and a little birdie did tell me that the latest version of WordPress has some HTML5 in its default template, so this might carry over into their hosted service. If you can’t wait and don’t have a server, remember that HTML5 is a sliding scale — I was using <div class="section"> with Tumblr for a while.

peace – Oli

Link stylesheet

Steve asked:

Hello, can we get rid of type=”text/css” when declaring a link rel=”stylesheet”?

Thank you and long live the web.

You certainly can do that. Same with including JavaScript:

<link rel="stylesheet" media="screen, projection" href="http://html5doctor.com/css/style.css">
<script src="http://html5doctor.com/js/html5.js"></script>

Thanks, Tom

ID attribute validation

Andrés asked:

Does the id attribute allows to begin with a number or a hyphen, unlike previous specs? Is there any set of character that aren’t allowed, besides space character?

There are three rules for the value of the ID attribute:

1. It must be at least one character long,
2. it must contain no space characters, and
3. it must be unique within the page.

So a hyphen would be valid as an ID value. It validates too. However, you may run into legacy stuff that hasn’t been updated yet (HTML Tidy, WYSIWYG plugins for a CMS, etc), so I’d advise testing within your workflow and in a browser (no idea if IE would barf on that, and it wouldn’t surprise me if it did).

peace – Oli

I’m so confused – article, header, footer, nav?

Benjamin asked:

Hey Doctor(s), I’m so confused right now.

I’ve been trying to implement HTML5 for my new blog and CMS, but having difficulties trying to figure out where advanced content should go. All the demonstrations and examples about HTML5 are over-simplified and just don’t include any real world information. For example, an article typically includes (in no particular order):

• Article
  • Title
  • Tagline
  • Tags
  • Avatar
  • Content
  • Links to child articles (eg. download, docs, demo)
    • Link Title
    • Link Avatar
    • Link Author Name
  • Links to recommended articles (related content)
    • Link Title
    • Link Avatar
    • Link Author Name
  • Article Author Details
    • Author Name
    • Author Avatar
  • Article Details
    • Published Date
    • Modified Date
  • Share Buttons

So all in all, way more complicated than the typical:

• Article
  • Article Title
  • Article Content

So say for example, where should all the stuff in the complicated (real-world) example go? Should the avatar go in the header, the article, or the footer? Or maybe even a details element? Should the navigation links to other articles be like: nav > ul > li > article > header > a > h1 With the a containing the link, and the h1 containing the article header? Should the post details (despite we want them display perhaps underneath the title, and before the content) be in a details element? And should that be within the header element or be below the header element? Should they use for example:

<dl>
  <dt class="published">Published At:</dt>
  <dd class="published">...</dd>
</dl>

or:

<ul>
  <li class="published">
    <label>Published At:</label>
    <span>...</span>
  </li>
</ul>

or something else? The second example seems to remove the duplication of the css class, but seems to add more complications though. Should those tag and article links in nav elements be inside the header? Or footer? Or just article? How many footers and headers can be in article?

I’m soo confused. Any help would be greatly appreciated? Perhaps the best help out there would be a detailed HTML5 example of the real-world article structure I posted above.

OK now, take a deeeep breath and relax. There, feeling a little better?

That’s a mammoth e-mail, so here are some basics to get you started:

• Start with a basic page before attempting something complex — don’t jump in the deep end.
• Look at websites in HTML5 Gallery and check their code.
• Look at the code for this site. Granted, it’s not perfect, but it’s pretty good, and we have a lot of the content you list.
• Use the most appropriate element for each piece of content, even if it’s not one of the new ones. (Hopefully it ends up being what you used before.) Perhaps our handy flowchart might help for that.

Some more specific answers:

“Should the navigation links to other articles be like: nav > ul > li > article > header > a > h1 With the a containing the link, and the h1 containing the article header?” The title of an article is not the same as an article, so it’d be wrong to use <article> or <header> here. I assume you didn’t use <h1> in navigation lists before, right?

“Should the post details (despite we want them display perhaps underneath the title, and before the content) be in a details element?” Possibly, if you wanted that interaction, but likely not as you probably want them visible all the time. See what the spec says about <details>. Decide on the semantics of each piece of content first. Worry about styling later.

“And should that be within the header element or be below the header element?” Header or footer seem like good places to put them. <label> is a caption for a form control, not an element to use whenever you need to label something.

I recommend you start with your HTML4 or XHTML1 knowledge and build on it. HTML5 is an evolution, not a revolution. In fact, I’d recommend you start out making a site in HTML4 with the HTML5 doctype (and validate it as HTML5), then change bits over time as you read each article on HTML5 Doctor and learn more

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.

Server-side validation

Brian asked:

We currently use PHP-Tidy to validate the HTML mark-up of content regions of our site. Our content regions have images that represent modules in our system that get translated into code for things like processing video, forms, etc. I’ve been making the move to upgrade these modules to use new HTML5 elements, but I’m finding that Tidy is stripping out these elements and I’m doing a lot of dancing around these issues right now. Are you aware of any server-side processing scripts that have been updated to work with HTML5 and perhaps with ARIA support as well?

The current contender is html5lib. The PHP version is v0.1, so YMMV.

It seems that HTML5 support won’t be coming to Tidy anytime soon.

Good luck! Peace – Oli

Immutable image with <canvas>

Mike asked:

We do have a medical app and we want to use <canvas> to let docs draw over a still picture. The only thing I cannot do is keep the picture unchanged when they use an “eraser” (basically a white pen). I haven’t found any example on the web so may be it’s impossible. It seems that the background image either part of the canvas of a div containing the canvas becomes part of the canvas itself. If it’s possible what’s the secret? Thanks

This is possible in a variety of ways. Here’s a quick demonstration of one of the solutions. Open the demo up in Firefox 3.6 or later, drop an image in the box, draw over it, and click the “Drawn image as PNG” button to retrieve what you drew (without the background image).

Here’s what’s happening: the canvas is sitting inside of a <div> containing my still image, but I’m drawing on the nested <canvas> (I think you had it the other way around, which was causing your problems).

Hope that helps, Remy

Retrieving objects from <canvas>

DJ asked:

I wanted to know if there is any way in which the drawn objects say rectangle, circle, line, … within canvas can be identified based on the selection at later point in time (after they are drawn).

If there are no direct APIs how could we achieve it. Do we have to store the co-ordinates of each of the created object within and do the object identification based on mouse cursor? Thanks

Unfortunately, there’s no way to retrieve these objects unless you write your own system to handle it. There’s no native support for this in <canvas>.

It sounds like you actually need to use SVG, which will allow to you to hook event listeners and query the DOM tree that’s created. If you need some convincing that SVG is the right tool for the job, have a look at the Raphaël JavaScript Library. It uses SVG exclusively and is able to create some very impressive drawings and animations.

Cheers, Remy

Custom tags

Mike asked:

So by using some JavaScript I can insert unfamiliar tags into IE, and using CSS I can format them. My question is why stop with HTML5 tags like section and nav? What are the pros and cons of custom tags like <content>, <story>, <comment>, <blog> or even <mike>, <was>, <here>?

Custom elements go against having a standard like HTML5. Standards map out the set of elements, attributes, and APIs that the browsers need to implement so web developers can use them, and they provide those developers with a common approach to marking up a web page.

If custom elements were allowed, we would have an infinite number of ways to mark up content, many of which would share a common goal but require different implementations. As an example, here is a number of different elements I can dream up for some primary content: <article>, <blog>, <entry>, <post>, <page>, <main>, <primary>, <content>, <document>, <doc>, <blogpost>, <publication>, <thenameofthearticlewithnospacesorpunctuation>, <item>, <block>, <blob>, <text>, <txt>, and <paper>. Many of them are bad ideas, but hopefully you see my point. This doesn’t even account for the more predictable <contentone>, <contenttwo>, <articlefifty> that would likely also be used.

This sort of markup would make HTML a nightmare to maintain. A developer coming into an existing site would have to learn which elements have been used and what their purpose is. And it’s not just painful for developers. Browser vendors would have to find ways to parse these elements and define how they should be used. Is this element supposed to be block-level? Is it interactive? Should it impact the document outline? And what about search engines? How do they know that <myobscureelement> defines the most important content on the page, the content that should really be indexed?

Standards narrow the possibilities and ensure developers, browsers, and machines (search engines and the like) are all speaking the same language. Many people spend a great deal of time debating the specification, trying to reach consensus on which proposals should be standardized and how they should be implemented.

So stick to the standards! They exist for everyone’s benefit. As browsers continue to implement the specification correctly (even IE is catching up), our jobs will be made easier and we can spend more time creating really cool things

John Alsopp’s fantastic article Semantics in HTML5 goes into more detail about this issue. You can also see where some of the element names came from by looking at the work Hixie did researching class names in Google’s index.

Regards, Mike

The role attribute, SEO, and <hgroup>

Robson asked:

What about the role attribute? Was it dropped from specification? What will be the “role” of the role attribute in HTML5?

Today, just the home page should have the name of the site into a H1 element. On others pages, the H1 should be used to the title of the articles. How do search engines interpret the HGROUP and multiples HEADER and H1 elements today? How to implement the HGROUP and the HEADER today without impact the SEO? Thanks, guys!

To answer your first three questions, role is in. You can use it belt-and-suspenders style until assistive technology catches up with HTML5. Just be careful: “Authors may use the ARIA role and aria-* attributes on HTML elements, in accordance with the requirements described in the ARIA specifications, except where these conflict with the strong native semantics described below”.

For the second part of your question, that’s not true. You can use more than one <h1> in HTML 4/XHTML 1. It’s not advised to make every heading <h1> in HTML 4/XHTML 1 (because historically some people did that to spam), but it may be appropriate in some cases — e.g., site name and page title. Using two <h1>‘s on a single page has no effect on SEO.

With regard to <hgroup> and <header>, you’re asking the wrong question. Search engines care about high-quality, relevant content. Search engines penalise spamming, but writing markup according to the specification is not spamming. The HTML5 editor works at Google, so they’re well aware of the spec. html5doctor.com has implemented <hgroup> and <header>, and it hasn’t hurt our search engine rankings any

For more, see our articles on the header element and the hgroup element.

You probably don’t want to use <h1> everywhere anyhow, as CSS selectors are not that smart. If you wrap every <h1>-<h6> in a sectioning element (<section>, <article>, <nav>, <aside>), you don’t have to worry about keeping a logical order for your headings. Doing this means you don’t need to overwrite CSS as much. The old style, however, with the requirement to keep a logical order for your headings, still works.

Again, you’re concerned with the wrong thing. Good SEO = good content. Worrying about placement or what search engines think is a waste of time — worry about good content.

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.

HTML5 vs Flash

Yaniv opens the great debate:

Hi, why is it said all the time that HTML 5 is going to replace Flash and in the near future flash will not be used again?

This is over-simplifying.

Historically, Flash has been used especially for games, video, and rich interaction because it wasn’t possible to do these things natively (i.e., without using a plugin). HTML5 introduces <canvas> and a native <video> element, and recently JavaScript libraries like jQuery make it much easier to create rich interaction. An additional benefit of Flash was its ubiquity, but thanks to the iPhone and now iPad, this isn’t true anymore.

I expect the usage of Flash to decrease as browsers support web standards, but Flash will still be used for a while to come. The enormous number of pages using Flash aren’t going to vanish (or change) overnight.

Peace – Oli

Body or div?

Erik asked:

Hi there, I have noticed that several implementations of HTML5 (including this blog), set a width of the body rather than using a wrapping div-tag to create a centered layout.

It somehow feels awkward to set a width of the body, but is that the actual, proper way of doing it? I understand that a wrapping div is non-semantic, but how would one deal with background images etc, if the body has a width set to it? I’m guessing it would work to set background images on the html-tag, as well, though.

If you need a <div> for styling purposes, that’s perfectly fine. You could also achieve the same effect by doing as you suggest and setting a background on the <html> element. For more, take a look at our recent article You can still use <div>.

If you need any help on using <body> as a wrapper, check out Kroc Camen’s How to Centre and Layout Pages Without a Wrapper.

Peace – Oli

Rich text editor

Dave asked:

We use our own bespoke CMS and part of the admin has a Javascript based rich-text editor (ck editor i think)for editing the main content of the pages.

The problem we’ve come across is that I’m building the site in HTML5 and it appears the text editor doesn’t recognise the new HTML5 tags (section, aside, article etc.) Do you know of any text editor that can handle HTML5 as I can’t seem to find anything in terms of Javascript based components or any other alternative. Many Thanks

Generally, JavaScript-based WYSIWYG editors are complete shite (excuse my British . Unfortunately, I don’t think this is gonna change soon because the established players were developed in the bad old days and have the code baggage to prove it. Perhaps with IE9 someone will cut the support anchor on older versions of IE (Safari, etc) and actually do a decent one, but don’t hold your breath

You can customise most editors, however, and possibly even add your own elements. As a start, here’s an article I wrote on hacking FCKEditor into some semblance of shape for MT4.

Beyond that, the editor’s documentation and forums are the place to check.

In addition, migrating to HTML5 is not all-or-nothing. You can get benefits from just the doctype (better validator, more detailed spec). Also, <div> is still a perfectly fine HTML5 element. Should new structural elements overwhelm the editor, you can always do something like <div class="article"> and <div class="nav"> (so-called HTML4.5 . This way you’re not using new elements, but you’re still benefitting from thinking in HTML5 semantics, and should you want to change down the road, you’ll already be half way there.

Peace – Oli

Recommended charset for HTML5

Guy asked:

I have always used ISO-8859-1 as things like £ work better (being UK based)

But I have noticed a strong tendency for UTF-8 when it comes to HTML5. Is there a reason for this? what do you recommend?

Many thanks, Guy

The HTML5 spec says use UTF-8: “Authors are encouraged to use UTF-8”. The reason is UTF-8 is a superset of ISO-8859-1, and can represent many more characters. To get a £ symbol, you can write £ (or £), but with UTF-8, just writing “£” is fine.

In fact, using UTF-8 in HTML5, we only need to escape & and < (and maybe ‘,”, and > depending on context — e.g., alt text). All other UTF-8 characters can be used as-is (e.g., “” not “”). Just look at the source for this paragraph!

Peace – Oli

Mobile doctype

Franceso asked:

Hello guys! I was wondering, since I found no reference at all online… does the HTML5 doctype cause problems on mobile browsers (besides the iPhone/iPod/iPad. I tested it and it works like a charm)?

I don’t mean “advanced” HTML5 properties like video or even article and other semantic tags. Just the simple HTML5 doctype, that causes no problems whatsoever with classic desktop browsers. Because I tried it, and it does seem to cause layout problems on Symbian (the only other browser I could test it).

Any suggestions? Because I do use the video tag in there (to degrade gracefully in all mobile browsers but the iPhone’s, I’d hope), but I hate using that with the classic mobile XHTML doctype declaration. Thanks!

The HTML5 doctype was chosen to be backward compatible with current browsers, and for desktop I think that’s completely true. I doubt many mobile browsers were tested, though. Anything not running Opera Mini or Mobile Webkit is most probably still partying like it’s 1999, and YMMV. I’d recommend testing thoroughly.

By the way, anything that doesn’t support the HTML5 doctype definitely will not support <video>. Hope that helps.

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.

Getting info from a canvas to the server

Stephen asked:

I want to use a canvas element as a layout plan and allow people to move things about and the like but I then want to be able to submit the changed layout to the server so it can be kept not just as a bitmap but as the various current layout of the plan. Is this possible?

You could call canvas.toDataURL() and store this output on the server. (Note that canvas is the DOM node and not the 2D context.) This will store the current state of your canvas, but it’s effectively a bitmap at this point. If you want to store the element for later editing, I’d suggest you use SVG instead. You can achieve the same graphical effect, but you’ll have access to the actual vector data since it’s XML.

Hope that helps,

Remy

Progress or meter?

Pierre asked:

Hello doctor,

I’m beginning with HTML5. I just wonder if I’m using the progress and meter elements correctly. Just imagine a player. Is it correct to use: the progress element to specify a load bar; the meter element to specify the volume set.

Thank you Doctor, have a good day.

<progress> is spot on for a loading bar, yes.

<meter> is read only, however, so it’s not appropriate for a volume control. There are some examples in Tom’s article on <meter>. To create a volume control, you could use one of the new input types specified in HTML5, perhaps <input type="range">.

Cheers,

Rich

Headers

Brad asked:

Having read you can use the header tag within almost any other element, is it fair to say you no longer “design” the header but simply design the elements in each header? How does that work? Would you use header classes?

In the past you define your header with an image or text etc. You can no longer do that if you use multiple headers?

The <header> element should be used if you have any related information within the “header” of that section that needs to be grouped. This means, for example, it isn’t necessary to wrap a lone <h1> in a <header> element. Also remember that the header doesn’t have to appear at the top of a section of page.

Our articles on the <header> element and <hgroup> element explain this some more.

Whether you need to use classes depends on your site.

Ta,

Rich

The placeholder attribute

José asked:

I recall once having seen text inputs that had tips inside them. They didn’t need Javascript in order to manage those tips. Would you consider discussing that a little better? That’d be great! Thanks!

We’re publishing an article on forms shortly, so be sure to look out for it.

Meanwhile, you’re looking for the placeholder attribute. Currently, this is supported only on Webkit browsers, although Mozilla is also working on it. You can use placeholder like this:

<input placeholder="Search" title="Type your search here" ...>

We’ve also written a JavaScript solution using feature detection (i.e., it will check whether the browser supports placeholder and adds support if not). Just add this script to the end of your markup (note that it should be the end since it needs to run once the DOM is ready).

Hope that helps,

Bruce & Remy

HTML5 Minified

Grant asked:

Hello! Big fan of your website. I wanted to know about the so called “HTML Minified” feature that allows you to strip the html, head and body tags from your page.

The W3C Validator Conformance Checker for HTML5 says this is valid, but the Conformance Checker is beta and is supposedly unreliable. I haven’t heard from anywhere else that stripping these tags is a feature.

So is it really a feature? Or just a bug (A BIG one at that) in the experimental validator? I know that it works, but I would like to see any confirmation other than the validator that this is in fact an intended standard before I start using it on my websites. Thanks!

According to the spec, it is now explicitly permitted to omit all kinds of elements tags, including the ones you mention. Browsers are able to deduce the document structure based on context (e.g., some elements are only allowed within a <body> element) and will fix the DOM as they go. In fact, these have always been optional tags in HTML (but not XHTML).

Browsers are so good at this, though, because they’ve had to deal with the pants code out there on the interwebs. Going this route means you’re relying on browser error handling to render your document (although said error handling has admittedly been standardised in HTML5). I personally see it as a more extreme version of quoting element attributes. Of course you don’t have to, but being strict makes errors much easier to find, helps out parsers that may not be as sophisticated as a full-fledged browser (like text editor syntax highlighting), and makes it easier for beginners and veterans alike to learn and use HTML.

In general, machines understand you better when you’re explicit, so I’d advise against omitting these elements.

For more detailed articles on HTML5 minification, check out Remy’s HTML5 Boilerplates and Bruce’s A minimal HTML5 document.

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.

Footer with sections

Tommie asked:

Hi, I’ll get to the point right away. I want to use, lets say 3 section elements inside a footer each floating left and inside each of this sections I have some standard information. Is this the right way to go, or should I put my section elements outside the footer and only put copyright text etc. inside the footer?

Thanks!

You could use a <section> within <footer>. but <footer> is a sectioning root anyway <footer> is flow content and can contain sectioning content. If you want them to appear in the outline within the footer, then it makes perfect sense to do as you suggest.

See more in Jack’s article on the <footer> element. There are also some more examples in the spec.

Cheers, Rich

<canvas> vs. Flash (security and copyright)

John asked:

I’m seeing lots of opinions that the canvas element might free us of the Adobe Flash monopoly, but what mechanisms can we use to protect our works when using straight HTML and JavaScript?

Right now I’m thinking about simple flash games, but I’m sure this is a concern for others wanting to use (free) HTML methods to perform functions now reserved more for flash.

Thanks for any input.

I’m not sure of any security mechanisms that we can use to protect <canvas> content. It isn’t really any different than an image or any other type of resource. Having said that, decompilers can circumvent some of Flash’s security measures as well, so you may not be much worse off using <canvas>.

If we come across anything, we’ll be sure to let you know.

Cheers, Rich

HTML5 tags inline?

Tami asked:

So, I’ve been experimenting with the new HTML5 elements, and one frustration I have is understanding the native display of the new elements, and how it works within the document flow. So far, experimenting with them has shown them to be very unpredictable. At best, they’re kind of behaving like a bastard span. They seem to be behaving like inline elements but that seems like it is wrong. In some cases, setting to display: block gives the expected behavior, but on the footer tag, it’s not interacting with floated elements properly.

So, are these new elements inline or are browsers still just trying to catch up? I tried looking in in the HTML5 working draft spec, but so far I am not understanding the way its written (HTML4′s specs clearly spelled out whether an element was display or inline).

Here’s an article from my personal blog that I wrote a while ago describing why browsers treat HTML5 elements as inline.

Thanks, Bruce.

Offline + Storage

Dear Doctor, I’m trying to work out if HTML5 will be able to do the job that I want. I have a number of documents (PDF, PPT, etc.) that I want to share with people in my team. These documents may change from time to time. Also, the people may not always be connected online.

Would it be possible to “cache” documents in an offline database in the browser so that when they are not connected they can still view them but when they are, they get the latest versions (which also refresh the cache)?

That way I can do a fairly pretty interface for sorting these documents so that they can easily find them.

Thanks in advance for any help you can provide.

You can, but I would strongly encourage you to think carefully about whether it’s worth it.

You can include these “assets” in the manifest, which will make the files available to the offline applications (note that this isn’t storage, just caching, which is what you’re after).

The problem is that when the visitor first hits the page with the manifest — which contains all the PDFs, PPTs, etc. — it will download all of these files. This is the bit that I’d encourage you to consider carefully. To compound that, I believe there’s a 5MB limit on the cache, so you might run into problems if you’re trying to cache more than that.

I’ve not covered offline cache on HTML5 Doctor yet (though it’s on the list), but I have described the process on my 24ways article.

If there are new versions of the cached files, you need to change the contents of the manifest — e.g., include a version number, which will trigger a download of all the assets again. Not ideal, but that’s the current situation.

Hope that helps a bit, Remy

Correct markup with blockquote

Phil asked:

Hi, in HTML 4.0 Strict and XHTML 1.0 Strict, text inside a blockquote element is required to be nested inside another block-level element, e.g. p.

In HTML5 that requirement seems to have been relaxed, as the following element validates successfully:

<blockquote>This is a blockquote.</blockquote>

The HTML5 spec uses the p element in the usage examples, but does not mention whether it is required.

Can you please confirm if this requirement has now been deprecated?

Great question. As I expected, this validates:

<!doctype html>
<meta charset=utf-8>
<title>blockquote test</title>
<blockquote>Tiger tiger burning bright</blockquote>

We double-checked with the WHATWG mailing list and confirmed that <blockquote> can contain ‘flow’ content (i.e., text, paragraphs, etc.).

To summarise, it would be valid not to further mark up content within a <blockquote>, but authors are encouraged to use a <p> (or other more appropriate element).

Bruce

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.