views:

187

answers:

3

Making a search result list (like in Google) is not very hard, if you just need something that works. Now, however, I want to do it with perfection, using the benefits of HTML5 semantics. The goal is to define the defacto way of marking up a search result list that potentially could be used by any future search engine.

For each hit, I want to

  • order them by increasing number
  • display a clickable title
  • show a short summary
  • display additional data like categories, publishing date and file size

My first idea is something like this:

<ol>
  <li>
    <article>
      <header>
        <h1>
          <a href="url-to-the-page.html">
            The Title of the Page
          </a>
        </h1>
      </header>
      <p>A short summary of the page</p>
      <footer>
        <dl>
          <dt>Categories</dt>
          <dd>
            <nav>
               <ul>
                  <li><a href="first-category.html">First category</a></li>
                  <li><a href="second-category.html">Second category</a></li>
                </ul>
            </nav>
          </dd>
          <dt>File size</dt>
          <dd>2 kB</dd>
          <dt>Published</dt>
          <dd>
            <time datetime="2010-07-15T13:15:05-02:00" pubdate>Today</time>
          </dd>
        </dl>
      </footer>
    </article>
  </li>
  <li>
    ...
  </li>
  ...
</ol>

I am not really happy about the <article/> within the <li/>. First, the search result hit is not an article by itself, but just a very short summary of one. Second, I am not even sure you are allowed to put an article within a list.

Maybe the <details/> and <summary/> tags are more suitable than <article/>, but I don't know if I can add a <footer/> inside that?

All suggestions and opinions are welcome! I really want every single detail to be perfect.

A: 

I found a good resource for HTML5 is HTML5Doctor. Check the article archive for practical implementations of the new tags. Not a complete reference mind you, but nice enough to ease into it :)

As shown by the Footer element page, sections can contain footers :)

Psytronic
I have already scanned through those articles, without finding anything relevant. Well, the discussion about the <article> tag has some points, but not enough to answer my question. I understand there is no simple answer, so that's why I want opinions from experienced web developers and markup fetishists.
Johan
+3  A: 

1) I think you should stick with the article element, as

[t]he article element represents a self-contained composition in a document, page, application, or site and that is intended to be independently distributable or reusable [source]

You merely have a list of separate documents, so I think this is fully appropriate. The same is true for the front page of a blog, containing several posts with titles and outlines, each in a separate article element. Besides, if you intend to quote a few sentences of the articles (instead of providing summaries), you could even use blockquote elements, like in the example of a forum post showing the original posts a user is replying to.

2) If you're wondering if it's allowed to include article elements inside a li element, just feed it to the validator. As you can see, it is permitted to do so. Moreover, as the Working Draft says:

Contexts in which this element may be used:

Where flow content is expected.

3) I wouldn't use nav elements for those categories, as those links are not part of the main navigation of the page:

only sections that consist of major navigation blocks are appropriate for the nav element. In particular, it is common for footers to have a short list of links to various pages of a site, such as the terms of service, the home page, and a copyright page. The footer element alone is sufficient for such cases, without a nav element. [source]

4) Do not use the details and/or summary elements, as those are used as part of interactive elements and are not intended for plain documents.

UPDATE: Regarding if it's a good idea to use an (un)ordered list to present search results:

The ul element represents a list of items, where the order of the items is not important — that is, where changing the order would not materially change the meaning of the document. [source]

As a list of search results actually is a list, I think this is the appropriate element to use; however, as it seems to me that the order is important (I expect the best matching result to be on top of the list), I think that you should use an ordered list (ol) instead:

The ol element represents a list of items, where the items have been intentionally ordered, such that changing the order would change the meaning of the document. [source]

Using CSS you can simply hide the numbers.

EDIT: Whoops, I just realized you already use an ol (due to my fatique, I thought you used an ul). I'll leave my ‘update’ as is; after all, it might be useful to someone.

Marcel Korpel
Thank you for those clueful opinions! From that point of view, <article> is a good choice for the summary. You are right about <nav> as well. I know, however, that <li> may contain more or less any tags according to the doctype. My question is more like if it is a good way of using lists.
Johan
A: 

However I think that it's a bit early to be worrying about a html5 search engine, the major problem is that html5 is still in Working Draft, so much can change until it's finally out. Also a plethora of businesses are stuck on IE6 or 7. Which has no html5 support, so you'd still be required to create a non html5 version for those browsers. So until it becomes a W3C's recommended implementation, and 90% people will be on html5 compat browsers, it may be best to put this on the side burner for now. Just my two cents.

But loving the enthusiasm, never loose that! :)

Psytronic
The new tags just add semantics for those who read or parse the DOM. The browsers don't really need having explicit support for most of the tags. IE has it's own way of interpreting unknown tags, but that can be worked around using a simple piece of javascript. Therefore, HTML5 semantics can very much be used today already, and must be so in order to speed up the development. I am a developer of a well known Swedish search engine, and now it is on my table to construct a perfect bleeding edge HTML5 template for a search result page.
Johan