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 cialis made in the usa 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.