Your Questions #17

by .

Doctor treating a patient illustration The clinic is packed this week with your HTML5 ailments! Today, we’ll discuss an HTML5 syntax dilemma, using sections within sections, <link> semantics, describing the contents of a figure, and marking up web app toolbars.

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.

6 Responses on the article “Your Questions #17”

Leon says

Thanks for the article, Richard.

Incidentally, what is the ‘problem’ with using an h1 to head a new section within a section? Isn't that the point of sectioning elements?

Rich Clark says

@Leon, the problem as it stands is essentially two fold. One, Google might (currently) treat multiple h1′s on a page negatively and two, accessibility – screen readers don’t know about sections right now.

Bertil Wennergren says

I have chosen to use the XHTML syntax in my current project to convert my main web site from XHTML 1.1 to HTML5. One reason is that my site is XHTML now, but the main reason is that I often use XSLT to process my pages, and XSLT needs the input to be XML. I think there are many developers that uses XSLT or other XML tools. For us XHTML5 is the right way to go.

Actually I plan to use polyglot HTML5 that can be served either as application/xhtml+xml or as text/html. That can be quite tricky to achieve with XSLT, but it is possible, at least with some postprocessing to fix up empty elements (in my case using PHP – for now, maybe Node.js later…).

Dale Cruse says

Well don’t I look silly for not using the code attribute in my comment.

I was trying to say: Bruce, when you said horzontalrule, I’m sure you meant horizontalrule but your point is well taken.

Adam says

I agree with Bertil Wennergren: well-formed HTML5 (XHTML5?) opens up possibilities.

To that end, I hope work is continued on polyglot validators (e.g., http://html5.validator.nu/ ).

CpILL says

@Rich Clark your two arguments against always using h1 in nested sections could be leveled against all HTML5. In my book, semantics (meaning) is created by use. People started to write clean HTML4 because Google rewarded them for it (i.e. SEO) not because it was “the right thing to do”. People started to layout their pages for screen readers because it became a legal requirement (and possibly because it worked better on small screens).

All this conjecture about the proper use of a tag will not be decided by a standards body or the people who produce it but by the algorithms that use it. Until Google (or some other [major] search engine) come out and say we will use the tags like this to rank your page or a [major] new app comes along that extracts info from tags in certain ways all this is just an academic exercise.

Besides, when has the web ever bowed to a standards body :D

Join the discussion.

Some HTML is ok

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

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