Back to basics: how to code an HTML5 template

Posted on March 28, 2012 by Portsmouth Media in Blog Leave a comment

An article I was reading about photoshop

class=”size-full wp-image-31022 alignleft” title=”html5″ src=”http://netdna.webdesignerdepot.com/uploads/2012/03/html5.jpeg” alt=”" width=”200″ height=”160″ />Markup is a beautiful thing, and it certainly has changed over the years. What was effectively HTML1, has certainly progressed to an amazing semantic markup language, to which we can largely thank the W3C. And, what do ya know, the next thing to thank them for has come about – HTML5.

Unlike previous version of HTML, where the code was mostly a limited structure that was determined by how you made use of the class and ID elements, html5 really attempts to provide much more structure.

All of the layout can be created with semantic tags and elements that determine how you should structure, and, arguably more important, that help you structure each page. This produces code that is much more clean and readable than in previous versions of HTML, and really is something quite amazing. The new tags really require that you think about how you are structuring your page, which let’s be honest – in the end that is a great thing for us web designers and developers alike. id=”more-30851″>

Before understanding the structure of HTML5, and how to create and code an example template to use for your projects you should be aware of how it came about. Be aware though that the current version of HTML5 has not reached a version that the W3C could call final as of yet, but their is quite a lot to learn about and start using in your code right now. Here is what the W3C has to say on this issue:

“Implementors should be aware that this specification is not stable. Implementors who are not taking part in the discussions are likely to find the specification changing out from under them in incompatible ways. Vendors interested in implementing this specification before it eventually reaches the Candidate Recommendation stage should join the aforementioned mailing lists and take part in the href=”http://www.w3.org/html/wg/”>discussions.”

class=”spacer_” />

But, don’t let that scare you. There are always people out there constantly making sure that it doesn’t get changed out from underneath of all of us. So you will certainly be aware if such a drastic change does indeed happen. Back on topic, one of the main questions people have about HTML5 is “<header>, <nav>, <footer>, these tags seem understandable enough but where in the world did the W3C come up with these?” Well, that question is easy enough to answer. It came from you!

It actually came from all of us. In 2005 Google conducted a href=”http://code.google.com/webstats/2005-12/classes.html”>study of over 3 billion websites and found that the most common classes used in common markup were actually what you see there on that page. Footer, menu, title, small, text, content, header, and nav are all among the top of the popularity chart. And essentially that is how the W3C decided on what to use for the new semantic tags for HTML5. Now that we know about that, let’s dive right into what those tags are and the basic fundamental changes in HTML5.

class=”spacer_” />

The doctype

A doctype isn’t particularly an element of the HTML, but it is a deceleration, and one that has become more and more important as time goes on. Using one appropriately can help your browser understand what sort of HTML it is trying to parse so we always want to use the appropriate doctypes. In all honesty, at this current time, you can pretty much just use the HTML5 doctype for everything though – but let’s cover some past ones as well. Here is where we have come as far as simplicity:

HTML2:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0 Level 2//EN">

HTML3:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 3.0//EN">

HTML4:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

HTML5:

<!DOCTYPE html>

Pretty great right? You don’t need to keep a document for copying and pasting in some ridiculously long doctype, or even worse yet, try to remember the ridiculously long doctypes of versions past. For HTML5 you simply have to type <!DOCTYPE html>. Ah, what a relief.

class=”spacer_” />

Other simplifications in HTML5

Before leaving this section, let’s go through some of the other elements that have gotten simpler. The root element has been simplified, to which instead of having to write something like:

<html xmlns=”http://www.w3.org/1999/xhtml”
lang=”en”
xml:lang=”en”>

We can just write:

<html lang=”en”>

The things we need to copy and paste getting smaller and smaller by the minute. For instance, also, In the head element, our character encoding went from things like:

<meta http-equiv=”Content-Type” content=”text/html;>

to the newer version in HTML5:

<meta charset=”UTF-8”>

And lastly, our links have dropped their type attribute. So for instance, this:

<link rel=”stylesheet” href=”style.css” type=”text/css”>

Becomes this:

<link rel=”stylesheet” href=”style.css”>

class=”spacer_” />

So what’s with these new tags?

The “section” tag

The section element is basically any generic section of an HTML document. Most typically though, it is a thematic grouping of content – which can have a heading but doesn’t require one.

A general rule of thumb for using the section heading is only use it if it would be explicitly referenced in the document’s outline. If, in the outline, there was a ‘section’ that you referenced or feel that all the content in one area is a ‘section’ of sorts – then do indeed include the section tag. If you want to use it mainly for styling purposes though, just don’t. Instead, use a <div> tag as you normally would.

class=”spacer_” />

The “nav” tag

The “nav” element represents any section of a page that links to other parts of that page or other pages within the sitemap. Anytime you think of navigation links, you should think “nav tag”.

The nav element is particularly intended for larger navigation blocks. Any large element that links to other sections of the site’s page or other pages of the site. Keep in mind though, a navigation section doesn’t have to be in the form of a list, albeit that is pretty standard. It can be in prose, paragraph tags, or pretty much anything – as long as it was originally suited to be in such tags in the first place.

class=”spacer_” />

The article tag

The article element represents a self-contained composition in a document, page, or any site. The really important thing to keep in mind with article tags is that it is, typically, independently distributable or reusable content is what is usually placed within the tags. It could be a forum post, a magazine or newspaper article, or a blog entry, even comments – as long as it is any independent item of content.

Articles can hold “section”s inside them, “header”s inside them, even “hgroup”s inside them. But do keep in mind when and how you are using this element, as it isn’t quite as commonly used as a <div> tag. So in summation, it isn’t a one-in-all answer for everything, but it does indeed have a lot of uses.

Let’s hop into an example. For instance, let’s say you have a blog post with some comments. You can do that like this in HTML5:

<article>
<header>
<h1>The Blog Entry Title</h1>
<p>12/25/2045</p>
</header>
<p>Blog entry</p>
<p>...</p>
<section>
<h1>Comments</h1>
<article>
<footer>
<p>Posted by: <span>Name of person</span></p>
<p>Time: 15 minutes ago</p>
</footer>
<p>Comment text here
/p>
</article>
<article>
<footer>
<p>Posted by: <span>Name of person</span></p>
<p>Time: 25 minutes ago</p>
</footer>
<p>Another comment here</p>
</article>
</section>
</article>

class=”spacer_” />

The “aside” tag

The aside element represents any section of a page that consists of content that is tangentially related to the content around the aside element. The most important thing to remember with this tag is that although it is content tangentially related to the content around the aside tag, it is typically information or content that is separated in characteristic. You will most often use it in sidebars, as most sidebars are perfect to be entirely wrapped in aside tags. Other uses can include pull quotes, bits of advertising, groups of nav links, or even addresses near the address of a location in question.

To get into more detail though, it is for anytime you feel the need to quite literally take an aside and explain, reference, mention, state, or question something. You can even use an aside element for a larger section of a site, such as a side-bar for Twitter, or Facebook, or random links. You could have it be an aside, then use a header and nav section within it even to help understand what is going on there. You can use it in the footer section of blog posts to reference things about them, or pretty much anywhere it can be perfectly implemented.

class=”spacer_” />

The “hgroup” tag

The hgroup element represents the heading of a section. This element is best used to group a set of h1-h6 elements when the heading has multiple levels, or subheadings – such as exactly the article you are reading. This would be perfect for an hgroup. You can also use it for alternative titles, or tag-lines.

The W3C reminds us:

“For the purposes of document summaries, outlines, and the like, the text of hgroup elements is defined to be the text of the highest ranked h1–h6 element descendant of the hgroup element, if there are any such elements, and the first such element if there are multiple elements with that rank. If there are no such elements, then the text of the hgroup element is the empty string.

class=”spacer_” />

Other uses, for instance, include areas of a blog where you are listing the header and subtitle for your blog post. You can also use it for book titles and descriptions, for listing doctors in your area and their areas of expertise, or even use it to help replicate the functionality of a table. Let’s take a look at such an example now. On a table we’d have:

<hgroup>
<h1>Doctor Name:</h1>
<h3>Randy McDocterson</h3>
<h2>Doctor Specialty</h2>
<h3>Slapping People</h3>
</hgroup>

So there you can clearly see, in the markup, that we have a doctor named Randy McDoctoerson who’s specialty is slapping people. Now, that is a little odd, but hey – it gets the point across.

class=”spacer_” />

The “header” tag

The header tag represents any group of introductory or navigational aids within a site, or sections of a site. So now that the formal definition has been stated, let’s break it down a bit. We all know what a header is, but to be specific it includes various things on the top of most site. These header areas usually include branding sections, call to action items, and perhaps some navigation. Really it can be used any place that you used to write: <div id=”header”> you can now write <header>, and get the same semantic markup structure. It is important to note, that the W3C especially remarks that a header element should contain either a set of H1’s, a sections heading individually (h1-h6), or an hgroup element. Header elements can also be used to wrap a section’s table of contents, a search form, or any relevant logos – such as what we mentioned above. Keep in mind though that the header is not sectioning, as in it isn’t a replacement for an all-in-one div either. Rather, it is just a great semantic element to use for specific situations.

To note: It can be used in any section’s beginning area, as it doesn’t have to be in the top or beginning of your HTML document. But, that is where it is most typically implemented.

class=”spacer_” />

The “footer” tag

The footer element represents a footer for its nearest nested parent section, and typically contains information about its parents section. The footer tag is very similar to the header tag, but for the opposite section of a page. Often times you will see a footer of a page that contains links again that were in the navigation, and perhaps a logo, or other such things – well all of these can now be housed in a <footer> tag. Though a footer is typically used at the end of a website, this tag can represent the end of any section of content (and it doesn’t even have to be at the end of said section to represent it). For instance let’s take a look at this example:

<body>
<footer><a href=”..”>Back to index...</a></footer>
<hgroup>
<h1>Lorem</h1>
<h2>Ipsum</h2>
</hgroup>
<p>Some text here.</p>
<footer><a href=”..”>Back to index...</a></footer>
</body>

class=”spacer_” />

The “address” tag

The address element represents the contact information for its nearest article or body element. I think the example best describes this tag so let’s dive right in.

<address>
 <a href="../People/Raggett/">Dave Raggett</a>,
 <a href="../People/Arnaud/">Arnaud Le Hors</a>,
 contact persons for the <a href="Activity">W3C HTML Activity</a>
</address>

I think that very aptly describes the address tag, but the W3C would also like to note that typically the address element would be included along with other information in a footer element. So, this would work specifically for the email or about.me link at bottoms of websites (near the copyright information particularly). You can house that in an address element like so:

<footer>
 <address>
  For more details, contact
  <a href="mailto:js@example.com">John Smith</a>.
 </address>
 <p><small>© copyright 2038 Example Corp.</small></p>
</footer>

And that just about wraps up all the important elements and new tags for HTML5. Keep in mind though, that wasn’t ALL the tags available, but it was some of the more important ones and particularly the ones we will be working with today.

class=”spacer_” />

HTML5 Template

So now that we have learned about HTML5, let’s get into coding our own template. Let’s start with an average document.

<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>HTML5 Template</title>
</head>
<body>
</body>
</html>

Now let’s add the stylesheet link, just for good practice, even though we may not use it.

<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>HTML5 Template</title>
<link rel="stylesheet" href="style.css">
</head>
<body>
</body>
</html>

Now I think it’d be a good time to start setting up our body element with some structure for us to use on other projects. So with that in mind let’s do:

<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>HTML5 Template</title>
<link rel="stylesheet" href="style.css">
</head>
<body>
<div id="wrapper">
<header>
<hgroup></hgroup>
</header>
<section>
</section>
<footer>
<hgroup>
</hgroup>
<address></address>
</footer>
</body>
</html>

Now, as you can see, we have a bit of a place for our content to go. We have a few designated sections. We have a designated header, footer, and section element within the document – but now let’s add a navigation element as well.

<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>HTML5 Template</title>
<link rel="stylesheet" href="style.css">
</head>
<body>
<div id="wrapper">
<header>
<hgroup>
<h1>HTML5 Template</h1>
<h3>Pretty standard template</h3>
</hgroup>
<nav>
<ul>
<li><a href="#">Home</a></li>
<li><a href="#">About HTML5</a></li>
</ul>
</nav>
</header>
<section>
</section>
<footer>
<hgroup></hgroup>
<address></address>
</footer>
</body>
</html>

And there we go, we have added some navigation with a nice unordered list there in the header section. But, wait a minute. What if you have a nice big footer and want those same navigator elements in the footer as well. Well, let’s add it there also. Except, this time we aren’t going to use the <nav> tag and instead are going to use a div with the class “footer_navigation”. And while we’re at it, let’s go ahead and fill out our footer section with some content.

<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>HTML5 Template</title>
<link rel="stylesheet" href="style.css">
</head>
<body>
<div id="wrapper">
<header>
<hgroup>
<h1>HTML5 Template</h1>
<h3>Pretty standard template</h3>
</hgroup>
<nav>
<ul>
<li><a href="#">Home</a></li>
<li><a href="#">About HTML5</a></li>
</ul>
</nav>
</header>
<section>
</section>
<footer>
<div class="footer_navigation">
<ul>
<li><a href="#">Home</a></li>
<li><a href="#">About HTML5</a></li>
</ul>
</div>
<hgroup>
<h3>By Dain Miller</h3>
<h4>from Madison, WI</h4>
</hgroup>
<address>
<a href="mailto:miller.dain@gmail.com">Email Me</a>
</address>
</footer>
</body>
</html>

Now let’s add in some bits for IE, and other such technicalities.

<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>HTML5 Template</title>
<meta name="description" content="">
<link rel="stylesheet" href="css/style.css">
<!-- IE6-8 support of HTML5 elements --> <!--[if lt IE 9]>
<script src="//html5shim.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->
</head>
<body>
<div id="wrapper">
<header>
<hgroup>
<h1>HTML5 Template</h1>
<h3>Pretty standard template</h3>
</hgroup>
<nav>
<ul>
<li><a href="#">Home</a></li>
<li><a href="#">About HTML5</a></li>
</ul>
</nav>
</header>
<section>
</section>
<footer>
<div class="footer_navigation">
<ul>
<li><a href="#">Home</a></li>
<li><a href="#">About HTML5</a></li>
</ul>
</div>
<hgroup>
<h3>By Dain Miller</h3>
<h4>from Madison, WI</h4>
</hgroup>
<address>
<a href="mailto:miller.dain@gmail.com">Email Me</a>
</address>
</footer>
</body>
</html>

And there we have it: a basic but complete HTML5 template!

class=”spacer_” />

Dain Miller is a freelance web designer and developer based out of Madison Wisconsin. He is mainly focused on building products in the online education space, and he has a passion for responsive design. You can follow him on twitter at href=”http://twitter.com/_dain”>@_dain.

What are your favorite new CSS3 techniques? Or little-used/little-known CSS techniques? Let us know in the comments!

/>
width=”100%” style=”border-top:1px solid #d7d7d7; border-bottom:1px solid #d7d7d7;” height=”20″>
valign=”center”> href=”http://www.mightydeals.com/deal/parallels.html?ref=inwidget”> face=”Arial” size=”3″ color=”#e64f32″>Run Multiple Versions of Windows or Linux on your Mac or PC width=”90″> href=”http://www.mightydeals.com/?ref=inwidget”> /> src=”http://mightydeals.com/web/images/widget-logo.png” height=”40″ width=”90″ border=”0″ /> />

href=”http://www.webdesignerdepot.com/2012/03/back-to-basics-how-to-code-an-html5-template/”>Source

Webdesigner Depot

Polyfilling The HTML5 Gaps With JavaScript

Posted on December 19, 2011 by Portsmouth Media in Blog Leave a comment

An article I was reading about plugins

We all want to use the hot new features being implemented in modern browsers right away, but there's a small problem holding us back: how can we use these great new capabilities whilst ensuring older browsers still render pages and … href=”http://addyosmani.com/blog/polyfilling-the-html5-gaps/”>Continue reading class=”meta-nav”>→
AddyOsmani.com | Articles for developers

HTML5 Semantics

Posted on November 20, 2011 by Portsmouth Media in Blog Leave a comment

An article I was reading about css3

Much of the excitement we’ve seen so far about HTML5 has been for the new APIs: local storage, application cache, Web workers, 2-D drawing and the like. But let’s not overlook that HTML5 brings us 30 new elements to mark up documents and applications, boosting the total number of elements available to us to over 100.

Sexy yet hollow demos aside, even the most JavaScript-astic Web 2.0-alicious application will likely have textual content that needs to be marked up sensibly, so let’s look at some of the new elements to make sure that your next project is as semantic as it is interactive.

To keep this article from turning into a book, we won’t look at each in depth. Instead, this is a taster menu: you can see what’s available, and there are links that I’ve vetted for when you want to learn more.

Along the way, we’ll see that HTML5 semantics are carefully designed to extend the current capabilities of HTML, while always enabling users of older browsers to access the content. We’ll also see that semantic markup is not “nice to have,” but is rather a cornerstone of Web development, because it is what enhances accessibility, searchability, internationalization and interoperability.

A human language like English, with its vocabulary of a million words, can’t express every nuance of thought unambiguously, so with only 100 or so words that we can use in HTML, there will be situations when it’s not clear-cut which element to use for which piece of content. In that case, choose one; be consistent across the site.

Some Presentational Elements Are Gone

Purely presentational elements such as center, font and big are now obsolete. Their role has been perfectly usurped by Cascading Style Sheets. Now, this doesn’t mean you have to rush out and recode all of those ancient pages; HTML5 makes them obsolete for authors, but because HTML5 strives not to break the Web, browsers will still render those cobwebbed legacy pages.

For the same reason, presentational attributes have been removed from current elements; for example, align on img, table, background on body, and bgcolor on table.

The evil frame element is absent in HTML5. Frames caused usability and accessibility nasties. If you get the urge to use them, use an older DOCTYPE so that your pages still validate.

Beyond this short overview, see the W3C’s exhaustive list of removed elements and attributes.

Some Presentational Elements Have Been Redefined To Be Semantic

Not all presentational elements have been taken out and shot. Some have undergone an extensive re-education program and emerged with shiny new semantics. For example, the small element no longer means “use a small font,” although it will display that way in browser style sheets. Now it represents side comments, such as small print:

Small print typically features disclaimers, caveats, legal restrictions, or copyrights. Small print is also sometimes used for attribution, or for satisfying licensing requirements.

Some of the redefinitions feel to me to be a mop-up. While I can get behind <b> for drawing attention to product names, keywords and so forth, without any special emphasis implied, specifying the semantics for marking up ship names (<i>, if you’re so inclined) feels weirdly precise. But I get seasick, and your nautical mileage may vary. With similar niche precision:

The u element [now] represents a span of text with an unarticulated, though explicitly rendered, non-textual annotation, such as labeling the text as being a proper name in Chinese text (a Chinese proper name mark), or labeling the text as being misspelt.

You can read more about changed elements and attributes on the W3C website.

Sexy New Semantics

We all know about video and audio. And canvas is particularly popular at the moment because it allows for 3-D graphics using webGL, so game designers can port their products to the Web. Like good ol’ img, these semantics are embedded content, because they drag in content from another source — either a file, a data URI or JavaScript.

Unlike img, however, they have opening and closing tags, allowing for fallbacks. Therefore, browsers that don’t support the new semantics can be fed some content: an image could be the fallback for a canvas, for example, or a Flash movie could be the fallback for video, a technique called “video for everybody.”

The source and track elements are empty elements (with no closing tags) that are children of video or audio.

The source element gets past the codec Tower of Babel that we have. Each element points to a different source file (WebM, MP4, Ogg Theora), and the browser will play the first one it knows how to deal with:

<audio controls>
  <source src=bieber.ogg type=audio/ogg>
  <source src=bieber.mp3 type=audio/mp3>
    <!-- fallback content: -->
    Download <a href=bieber.ogg>Ogg</a> or <a href=bieber.mp3>MP3</a> formats.
</audio>

In this example, Opera, Firefox and Chrome will download the Ogg version of Master Bieber’s latest toe-tappin’ masterpiece, while Safari and IE will grab the MP3 version. Chrome can play both Ogg and MP3, but browsers will download the first source file that they understand. The fallback content between the opening and closing tags is a link to download the content to the desktop and play it via a separate media player, and it is only shown in browsers that can’t play native multimedia.

For video, you could use an embedded Flash movie hosted on YouTube:

<video controls>
  <source src=best-video-ever.webm type=video/webm>
  <source src=best-video-ever.mp4 type=video/mp4>
    <!-- fallback content: -->
    <iframe width="480" height="360"
      src="http://www.youtube.com/embed/xzMUyqmaqcw?rel=0"
      frameborder="0" allowfullscreen>
    </iframe>
</video>

This way, users of older browsers, such as IE 6-8, will see a YouTube movie (as long as they have the Flash Player), so they will at least be able to see the video, while users with modern browsers will get the full native-video experience. Everyone gets the content, then, which is what your website is there for, after all.

The track element is a newer addition to the HTML5 family and is being implemented by Opera, Chrome and IE at the moment. It points to a subtitle file that contains text and timing information. When implemented, it synchronizes captions with the media file to enable on-demand subtitling and captioning; useful not only for viewers who are hard of hearing, but also for those who do not speak the language used in the audio or video file.

Semantics For Internationalization

Less woo! than the semantics for multimedia and games are the semantics for internationalization. It may surprise the cool kids in Silicon Valley to learn that a worldwide Web of people use languages other than English and even use different writing systems.

Languages such as Arabic and Hebrew are written right to left, unlike European languages, which are written left to right. On pages that use only one writing system, this doesn’t present a problem, but on pages with bi-directional (“bidi”) writing, browsers have to decide where to put punctuation, bullets, numbers and the like. Browsers usually do a pretty good job using the Unicode bidirectional algorithm, but it gets it wrong in some cases, which can seriously dent the comprehensibility of content.

HTML5 gives us a bdi element, which enables authors to override the Unicode bidirectional algorithm and make their text more comprehensible. For a further description of the problem and to see how bdi solves it, see “HTML5’s New bdi Element” by Richard Ishida, the W3C’s internationalization activity lead.

Some languages have scripts that are not alphabetic at all, but that express an idea rather than a sound. Occasionally, an author will have to assist readers with pronunciation for especially rare or awkward characters, usually by providing an alternate script in a small font above the relevant character. In print, this was traditionally done with a very small 5-point font called “ruby,” and HTML5 gives us three new elements for marking up ruby text: ruby, rt and rp.

For more information, see “The HTML5 ruby Element in Words of One Syllable or Less” by Daniel Davis.

Structural Semantics

Most people are aware that HTML5 gives us many new elements to describe parts of a Web page, such as header, footer, nav, section, article, aside and so on. These exist because we Web developers actually wanted such semantics. How did the authors of the HTML5 specification know this? Because in 2005 Google analyzed 1 billion pages to see what authors were using as class names on divs and other elements. More recently, in 2008, Opera MAMA analyzed 3 million URLs to see the top class names and top IDs used in the wild. These analyses revealed that authors wanted to mark up these areas of the page but had no elements to do so, other than the humble and generic div, to which they then added descriptive classes and IDs.

(HTML5 Doctor has many articles about HTML5 semantics, so we won’t bloat this article by going in depth here. Warning: some were written by me.)

The new semantics were built to degrade gracefully. For example, consider what the specification has to say about the new figure element:

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…

This isn’t a new idea. HTML3 proposed a fig element (which never made it into the final HTML 3.2 specification). It looked like this:

<FIG SRC="nicodamus.jpeg">
   <CAPTION>Ground dweller: <I>Nicodamus bicolor</I> builds silk snares</CAPTION>
   <P>A small hairy spider.
   <CREDIT>J. A. L. Cooke/OSF</CREDIT></P>
</FIG>

There’s a big problem with this. In browsers that do not support fig (and none do), the image wouldn’t be displayed because the fig element would be completely ignored. The contents of the credit element would be displayed, because it’s just text. So you’d get a credit with no image on older browsers.

In HTML5, you would code the same example like so:

<figure>
<img src="nicodamus.jpeg">
   <figcaption>
      <p>Ground dweller: <i>Nicodamus bicolor</i> builds silk snares.</p>
      <p>A small hairy spider.
      <small>J. A. L. Cooke/OSF</small&gt</p>
   </figcaption>
</figure>

Unlike the aborted HTML3 syntax, the HTML5 version is backwards-compatible: a browser that doesn’t “know” about the figure element will still show the img and the text inside figcaption (as the HTML3 credit element would similarly display its content). Note that we’re using the redefined small element, instead of minting a new credit element. Remember that “Small print is also sometimes used for attribution.”

HTML5 also gives us a new figcaption element. Originally, the specification’s authors tried to reuse caption, as suggested in HTML3, but there were legacy problems, because caption had previously only been a child of table.

One of the design principles on which HTML5 is based is that new features should degrade gracefully. When they can’t, the language allows for fallback content. It tries to reuse elements rather than mint new ones — but it’s a pragmatic language: when minting something new is necessary, it does so.

Interactive Semantics

The structural elements of HTML5 currently don’t do much in visual browsers, although software that sits on top of browsers (such as screen readers) are starting to use them (see “HTML5, ARIA Roles, and Screen Readers in March 2011“ and “JAWS, IE and Headings in HTML5.”)

Other elements do have a visual effect. The details element, for example, is a groovy interactive element that functions as “a disclosure widget from which the user can obtain additional information or controls.”

Most browsers will implement it as an “expando box”: when the user clicks on some browser-generated icon (such as a triangle or downwards-pointing arrow) or the word “Details” (which can be replaced by the author’s own rubric in a child summary), the element will slide open, revealing its details within. The details could be a full description of an image or graph, a description of a complex table, advanced options for a search form, or just about anything else. This is a common need on the Web today, now made native and obviating the need for custom JavaScript.

Most of us have seen HTML5’s new form semantics. Most of these are attributes of the input element, thereby ensuring graceful degradation to <input type=text> in older browsers. New elements include datalist, output, progress and meter.

Do We Have The Right Semantics?

So, we have many new semantics, but are they the right ones? After all, the Google research on which they were based was conducted in 2005 — quite some time ago! Perhaps the semantics are already somewhat behind the times? Many have noted that they’re document-centric rather than application-centric. Do we need more application-centered semantics, such as a login or share element, or some kind of modal element for modal dialogue boxes?

I don’t know; I’m not an app developer. But at least HTML is a “living standard,” and so these can be added if strong enough use cases are presented to the Working Group.

I think most coders would welcome a new way to embed images that respond to the device’s context. Borrowing from the video element, which displays source video according to what media queries instruct, I can imagine a new element such as picture:

<picture alt="angry pirate">
   <source src=hires.png media="min-width:800px">
   <source src=midres.png media="min-width:480px">
   <source src=lores.png>
      <!-- fallback for browsers without support -->
      <img src=midres.png alt="angry pirate">
</picture>

This would pull in hires.png for widescreen devices, midres.png for devices between 480 and 800 pixels wide, and lores.png for everything else, thereby rendering moot the question that designers currently ask themselves, “Do I make every browser download a high-resolution image and then squash it down for small screens, thus wasting bandwidth, or do I send a low-resolution image to every browser and scale it up for big screens, potentially sacrificing quality?”

Taking a leaf from the other popular semantics we’ve seen, there would be a fallback in the middle — in this case, a conventional img element — so everyone would get the right content.

Sending the right-sized image to devices without wasting bandwidth is one of the knottiest problems in cross-device and responsive design at the moment. Perhaps we’ll see a solution to this in HTML6. At the moment, the best solutions, which include Matt Wilcox’s Adaptive Images and Filament Group’s Responsive Images, require JavaScript and tweaks to the server’s htaccess file. The worst solutions require old-fashioned techniques, such as browser-sniffing, now rebranded as “device detection” but still the same old user-agent string-pattern matching, which is hilariously fragile, not future-proof or scalable, and straight out of the days of “Best viewed in Netscape Navigator at 800 × 600” badges on websites.

When, Where, Who?

A lot of data depends on three pieces of information: when, where and who?

HTML5 Semantics

HTML5 has a time element (which has been a bit of a battleground lately). This enables you to annotate a human-readable date with an unambiguous machine-readable one. It doesn’t matter what goes between the tags, because that’s the content for people to read. So, you could use either of the following:

<time datetime="1982-07-18">The day the woman I love was born</time>

<time datetime="1982-07-18">Priyanka Chopra’s birthday</time>

Whichever you choose, the machine would still know the date you mean because of the datetime attribute, formatted as YYYY-MM-DD. If you wanted to add a time, you could: separate the time from the date with a T, and then put the time in 24-hour format, terminated by a Z, along with any time-zone offset. So, 2011-11-13T20:00Z would be 8:00 pm on 13 November 2011 UTC, while 2011-11-13T23:26.083Z-05.00 would be 23:26 pm and 83 milliseconds in the time zone lying 5 hours before UTC. A Sri Lankan-localised browser could use this information to automatically convert dates into Buddhist calendar. Search engines could use timestamps to help evaluate “freshness”.

It’s perhaps surprising that, even though geo-location is so prevalent now, we don’t have a location element that simply takes three attributes: latitude, longitude and (optionally) altitude. It would be great to be able to write the following:

<location lat=51.502064 long=-0.131981>London SW1A 4WW</location>

The browser would then offer to show you a map or give you directions from the current GPS location or any other location-based service.

(Since I gave the talk that this article is based on, Ian Hickson, the HTML5 editor, said that he expects to add a new element. If I could choose, I’d prefer

, so I could wear a T-shirt with the slogan “I’ve got the time if you’ve got the place“.)

HTML3 had a person element, “used for names of people to allow these to be extracted automatically by indexing programs,” but it was never implemented. In HTML4, the cite element could be used to wrap names of people, but this has been removed in HTML5 — controversially (see “Incite a Riot” by Jeremy Keith). In HTML5, then, we’re left with no way to unambiguously denote a person. People’s names are, however, a hard problem to solve. Whereas times and dates have well-known standardized ISO formats (YYYY-MM-DD and HH:MM:SS.mmm, respectively), and location is always latitude, longitude and altitude, personal names are harder to break down into useful parts: there are Russian patronymics, Indonesian single-word names, multiple family names, and Thai nicknames to consider. (See Richard Ishida’s excellent article “Personal Names Around the World” for more information and discussion.)

The new data element, which replaces time, has a value attribute that passes machine-readable information, but it has no required or implied format, so there is no way for a browser or search engine to know, for example, whether 1936-10-19 is a date, a part number or a postal code.

Microdata

HTML5, like HTML4, is extensible (but not in the oh-so-dirty eXtensibility way of XML formats, so loathed by the Working Group). You can use the tried and tested microformats, which use HTML classes, or the full RDFa specification, which doesn’t validate in HTML4 or HTML5. Because RDFa was considered to be too hard for authors to write (Google has conducted research that finds that authors make 30% more mistakes with RDFa than with other formats), HTML5 specifies microdata, a mechanism for adding common semantics via agreed-upon markup patterns. HTML5 Doctor has more information on HTML5 microdata, and Opera 11.60 supports the Microdata DOM API.

Like microformats and RDFa, the extra semantics added to the markup make sense only if you have a cheat sheet that tells you what each piece means. This means that the data has to point to a vocabulary that tells any crawler how to interpret the lump of data it finds. For microdata, there is the newly established Schema.org, which is “a collection of schemas, i.e. HTML tags, that webmasters can use to mark up their pages in ways recognized by major search providers.”

Do Semantics Matter Anyway?

Now that more and more markup is generated by JavaScript, some people are tempted to think that semantics don’t matter. We see various products marketed as HTML5 which simply make div‘s fly around the screen with JavaScript — simple DHTML techniques unchanged from 10 years ago.

I’ve even seen some Web pages with no markup at all. Some frameworks emit skeletal HTML with empty body tags and inject all the HTML with script. If you’re squirting some minified JavaScript down the wire, with no markup at all, you’re closer to Flash than you are to the Web.

In the same way that 47 minutes is (apparently) too long to to struggle making a CSS layout, at which point you should just give up and use tables, some people suggest that thinking about which element to use is a waste of time. “There are two types of developers: those who argue about div’s not being semantic and those who create epic shit” writes Thomas Fuchs, as if the two activities were mutually exclusive.

A better argument is that no software cares about or consumes semantics anyway, so why bother? This isn’t true (work is underway already to map assistive technologies to new semantics), but even if it were true, it ignores that this is a chicken-and-egg argument. It assumes that no new search engine will ever come to the market and be able to use new elements, or that browsers will never release new versions that can make use of these semantics, asnd that developers will write no new extensions — in short, it assumes that the evolution of the Web is complete.

Semantics do matter. Semantics communicate meaning, and once that is established, machines can do something meaningful with that data, without having to develop and use algorithms to guess. A browser extension might allow a user to jump straight to the nav with a single keystroke. It can do this because it looks for nav rather than having to employ heuristics to find a div with an id or class that would suggest it’s being used as navigation (assuming the author decided to use something sensible like nav, navigation, sidebar, or menu — and a restaurant site with a div called “menu” might be a list of foods rather than other pages…ah, the ambiguity of natural language). A crawler might dynamically assemble articles on a timeline. There are many more possibilities than my meagre imagination can dream up.

The Web is based on simple technologies, mashed up together to bring surprising results — results which have certainly surpassed the inventors’ original intents or expectations. The Web will continue to do so. What makes the Web so great, so flexible and so powerful is the fact that content is in open formats that can be parsed and mashed up in new and surprising ways.

These can happen if the content is marked up for meaning by the author — and if the language has the right markup elements for authors to use as a vocabulary. HTML5 extends our vocabulary. We’ll need more words — and those will come about with HTML6 etc.

If, like me, you believe the Web to be a system that works across browsers, across operating systems, across devices, across languages, that is View-sourcable, hackable, mash-uppable, accessible, indexable, reusable, then we need to ensure that we use the small number of semantic tools at our disposal properly, and we’ll all benefit.

(This article is based on a talk I gave at the Fronteers Conference.)

About the Author

Bruce evangelizes Open Web Standards for Opera. He wrote the book Introducing HTML5 together with Remy Sharp. The book points out the good and bad parts of HTML5 specifications and shows you how to use the language as well as some areas of spec will be discussed theoretically as they’re not yet implemented anywhere. It’s the first full-length book on HTML5 (New Riders, appearing in the 2nd edition).

(al) (il) (vf)

Smashing Magazine Feed

HTML5 And The Document Outlining Algorithm

Posted on August 16, 2011 by Portsmouth Media in Blog Leave a comment

An article I was reading about css3

Advertisement in HTML5 And The Document Outlining Algorithm

in HTML5 And The Document Outlining Algorithm

By now, we all know that we should be using HTML5 to build websites. The discussion now is moving on to how to use HTML5 correctly. One important part of HTML5 that is still not widely understood is sectioning content: section, article, aside and nav. To understand sectioning content, we need to grasp the document outlining algorithm.

Understanding the document outlining algorithm can be a challenge, but the rewards are well worth it. No longer will you agonize over whether to use a section or div element — you will know straight away. Moreover, you will know why these elements are used, and this knowledge of semantics is the biggest benefit of learning how the algorithm works.

HTML5 Logo 512 in HTML5 And The Document Outlining Algorithm

What Is The Document Outlining Algorithm?

The document outlining algorithm is a mechanism for producing outline summaries of Web pages based on how they are marked up. Every Web page has an outline, and checking it is easy using a really simple free online tool, which we’ll cover shortly.

So, let’s start with a sample outline. Imagine you have built a website for a horse breeder, and he wants a page to advertise horses that he is selling. The structure of the page might look something like this:

Horses for sale
1. Mares
  1. Pink Diva
  2. Ring a Rosies
  3. Chelsea’s Fancy
2. Stallions
  1. Korah’s Fury
  2. Sea Pioneer
  3. Brown Biscuit

Figure 1: How a page about horses for sale might be structured.

That’s all it is: a nice, clean, easy-to-follow list of headings, displayed in a hierarchy — much like a table of contents.

To make things even simpler, only two things in your mark-up affect the outline of a Web page:

heading content (h1 to h6 and hgroup),
sectioning content (section, article, aside and nav).

Obviously, the sectioning of content is the new HTML5 way to create outlines. But before we get into that, let’s go back to HTML 101 and review how we should all be using headings.

Creating Outlines With Heading Content

To create a structure for the horses page outlined in figure 1, we could use mark-up like the following:

<div>
   <h1>Horses for sale</h1>

   <h2>Mares</h2>

   <h3>Pink Diva</h3>
   <p>Pink Diva has given birth to three Grand National winners.</p>

   <h3>Ring a Rosies</h3>
   <p>Ring a Rosies has won the Derby three times.</p>

   <h3>Chelsea’s Fancy</h3>
   <p>Chelsea’s Fancy has given birth to three Gold Cup winners.</p>

   <h2>Stallions</h2>

   <h3>Korah’s Fury</h3>
   <p>Korah’s Fury has fathered three champion race horses.</p>

   <h3>Sea Pioneer</h3>
   <p>Sea Pioneer has won The Oaks three times.</p>

   <h3>Brown Biscuit</h3>
   <p>Brown Biscuit has fathered nothing of any note.</p>

   <p>All our horses come with full paperwork and a family tree.</p>
</div>

Figure 2: Our “Horses for sale” page, marked up using headings.

It’s as simple as that. The outline in figure 1 is created by the levels of the headings.

Just so you know that I’m not making this up, you should copy and paste the code above into Geoffrey Sneddon’s excellent outlining tool. Click the big “Outline this” button, et voila!

An outline created with heading content this way is said to consist of implicit, or implied, sections. Each heading creates its own implicit section, and any subsequent heading of a lower level starts another layer, of implicit sub-section, within it.

An implicit section is ended by a heading of the same level or higher. In our example, the “Mares” section is ended by the beginning of the “Stallions” section, and each section that contains details of an individual horse is ended by the beginning of the next one.

Figure 3 below is an example of an implicit section that ends with a heading of the same level. And figure 4 is an implicit section that ends with a heading of a higher level.

<h3>Sea Pioneer</h3><!-- start of implicit section -->
<p>Sea Pioneer has won The Oaks three times.</p>

<h3>Brown Biscuit</h3><!-- This heading starts a new implicit section,
so the previous Sea Pioneer section is closed -->

Figure 3: An implicit section being closed by a heading of the same level

<h3>Chelsea’s Fancy</h3><!-- start of implicit section -->
<p>Chelsea’s Fancy has given birth to 3 Gold Cup winners.</p>

<h2>Stallions</h2><!-- this heading starts a new implicit section
using a higher level heading, so Chelsea’s Fancy is now closed -->

Figure 4: An implicit section being closed by a heading of a higher level.

Creating Outlines With Sectioning Content

Now that we know how heading content works in creating an outline, let’s mark up our horses page using some new HTML5 structural elements:

<div>
   <h6>Horses for sale</h6>

   <section>
      <h1>Mares</h1>

      <article>
         <h1>Pink Diva</h1>
         <p>Pink Diva has given birth to three Grand National winners.</p>
      </article>

      <article>
         <h5>Ring a Rosies</h5>
         <p>Ring a Rosies has won the Derby three times.</p>
      </article>

      <article>
         <h2>Chelsea’s Fancy</h2>
         <p>Chelsea’s Fancy has given birth to three Gold Cup winners.</p>
      </article>
   </section>

   <section>
      <h6>Stallions</h6>

      <article>
         <h3>Korah’s Fury</h3>
         <p>Korah’s Fury has fathered three champion race horses.</p>
      </article>

      <article>
         <h3>Sea Pioneer</h3>
         <p>Sea Pioneer has won The Oaks three times.</p>
      </article>

      <article>
         <h1>Brown Biscuit</h1>
         <p>Brown Biscuit has fathered nothing of any note.</p>
      </article>
   </section>

   <p>All our horses come with full paperwork and a family tree.</p>
</div>

Figure 5: The horses page, marked up with some new HTML5 structural elements.

Now, I know what you’re thinking, but I haven’t taken leave of my senses with these crazy headings. I am making a very important point, which is that the outline is created by the sectioning content, not the headings.

Go ahead and copy and paste that code into the outliner, and you will see that the heading levels have absolutely no effect on the outline where sectioning content is used.

The section, article, aside and nav elements are what create the outline, and this time the sections are called explicit sections.

One of the most talked about features of HTML5 is that multiple h1 elements are allowed, and this is why. It’s not an open invitation to mark up every heading on the page as h1; rather, it’s an acknowledgement that where sectioning content is used, it creates the outline, and that each explicit section has its own heading structure.

The part of the HTML5 spec that deals with headings and sections makes this clear:

Sections may contain headings of any rank, but authors are strongly encouraged to either use only h1 elements, or to use elements of the appropriate rank for the section’s nesting level.

I would strongly advise that until browsers — and, more critically, screen readers — understand that sectioning content introduces a sub-section, using multiple h1 elements is less safe than using a heading structure that reflects the level of each heading in the document, as shown in figure 6 below.

This means that user agents that haven’t implemented the outlining algorithm can use implicit sectioning, and those that have implemented it can effectively ignore the heading levels and use sectioning content to create the outline.

At the time of this writing, no browsers or screen readers have implemented the outlining algorithm, which is why we need third-party testing tools such as the outliner. The latest versions of Chrome and Firefox style h1 elements in nested sections differently, but that is very different from actually implementing the algorithm.

When most user agents finally do support it, using an h1 in every explicit section will be the preferred option. It will allow syndication tools to handle articles without needing to reformat any heading levels in the original content.

   <div>
      <h1>Horses for sale</h1>

      <section>
         <h2>Mares</h2>

         <article>
            <h3>Pink Diva</h3>
            <p>Pink Diva has given birth to three Grand National winners.</p>
         </article>

         <article>
            <h3>Ring a Rosies</h3>
            <p>Ring a Rosies has won the Derby three times.</p>
         </article>

         <article>
            <h3>Chelsea’s Fancy</h3>
            <p>Chelsea’s Fancy has given birth to three Gold Cup winners.</p>
         </article>
      </section>

      <section>
         <h2>Stallions</h2>

         <article>
            <h3>Korah’s Fury</h3>
            <p>Korah’s Fury has fathered three champion race horses.</p>
         </article>

         <article>
            <h3>Sea Pioneer</h3>
            <p>Sea Pioneer has won The Oaks three times.</p>
         </article>

         <article>
            <h3>Brown Biscuit</h3>
            <p>Brown Biscuit has fathered nothing of any note.</p>
         </article>
      </section>

      <p>All our horses come with full paperwork and a family tree.</p>
   </div>

Figure 6: Our horses page, marked up sensibly.

One other point worth noting here is the position of the paragraph “All our horses come with full paperwork and a family tree.” In the example that used headings to create the outline (figure 2), this paragraph is part of the implicit section created by the “Brown Biscuit” heading. Human readers will clearly see that this text applies to the whole document, not just Brown Biscuit.

Sectioning content solves this problem quite easily, moving it back up to the top level, headed by “Horses for sale.”

Mixing It Up

So, what happens when implicit sections and explicit sections are combined? As long as you remember that implicit sections can go inside explicit sections, but not the other way round, you will be fine. For example, the following works well and is perfectly valid:

   <h1>Horses for sale</h1>

   <section>
      <h2>Mares</h2>

      <h3>Pink Diva</h3>
      <p>Pink Diva has given birth to three Grand National winners.</p>

      <h3>Ring a Rosies</h3>
      <p>Ring a Rosies has won the Derby three times.</p>

      <h3>Chelsea’s Fancy</h3>
      <p>Chelsea’s Fancy has given birth to three Gold Cup winners.</p>
   </section>

And it creates a sensible hierarchical outline:

Horses for sale
1. Mares
  1. Pink Diva
  2. Ring a Rosies
  3. Chelsea’s Fancy

Figure 7: Implicit sections created by headings inside an explicit section.

However, if you hope to achieve the same outline by nesting an explicit section inside an implicit section, it won’t work. The sectioning element will simply close the implicit section created by the heading and create a very different outline, as shown below:

   <h1>Horses for sale</h1>

   <h2>Mares</h2>

   <article>
      <h3>Pink Diva</h3>
      <p>Pink Diva has given birth to three Grand National winners.</p>
   </article>

   <article>
      <h3>Ring a Rosies</h3>
      <p>Ring a Rosies has won the Derby three times.</p>
   </article>

   <article>
      <h3>Chelsea’s Fancy</h3>
      <p>Chelsea’s Fancy has given birth to three Gold Cup winners.</p>
   </article>

This would produce the following outline:

Horses for sale
1. Mares
2. Pink Diva
3. Ring a Rosies
4. Chelsea’s Fancy

Figure 8: Explicit sections can’t go inside implicit sections.

There is no way to make the explicit sections created by the article elements become sub-sections of the Mare’s implicit section.

You can use headings to split up the content of sectioning elements, but not the other way round.

Things To Watch Out For

Untitled Sections

Until now we haven’t really looked at nav and aside, but they work exactly the same as section and article. If you have secondary content that is generally related to your website — say, horse-training tips and industry news — you would mark it up as an aside, which creates an explicit section in the document outline. Similarly, major navigation would be marked up as nav, again creating an explicit section.

There is no requirement to use headings for aside and nav, so they can appear in the outline as untitled sections. Go ahead and try the following code in the outliner:

   <nav>
      <ul>
         <li><a href="/">home</a></li>
         <li><a href="/about.html">about us</a></li>
         <li><a href="/horses.html">horses for sale</a></li>
       </ul>
   </nav>

   <h1>Horses for sale</h1>

   <section>
      <h2>Mares</h2>
   </section>

   <section>
      <h2>Stallions</h2>
   </section>

Figure 9: An untitled <nav>.

The nav appears as an untitled section. Now, this generally wouldn’t be a problem and is not considered bad HTML5 code, although in his recent HTML5 Doctor article on outlining, Mike Robinson recommends using headings for all sectioning content in order to increase accessibility.

Untitled section and article elements, on the other hand, are generally to be avoided. In fact, if you’re unsure whether to use a section or article, a good rule of thumb is to see whether the content has a natural, logical heading. If it doesn’t, then you will more than likely be wiser to use a good old div.

Now, the spec doesn’t actually require section elements to have a title. It says:

The section element represents a generic section of a document or application. A section, in this context, is a thematic grouping of content, typically with a heading.

Your interpretation of this probably hinges on your understanding of the word “typically.” I take it to mean that you need a damn good reason not to use headings with section elements. I do not take it to mean that you can ignore it whenever you feel the urge to use a new HTML5 element.

Where the article element is specified, the spec goes even further by showing an example of blog comments marked up as untitled articles, so there are exceptions. However, if you see an untitled section or article in the outline, make sure you have a good reason for not giving it a title.

If you are unsure whether your untitled section is a nav, aside, section or article, a very handy Opera extension will let you know which type of sectioning content you have left untitled. The tool will also let you view the outline without leaving the page, which can be hugely beneficial when you’re debugging sections.

Sectioning Root

The eagle-eyed among you will have noticed that when I said that sectioning content cannot create a sub-section of an implicit section, there was an h1 (“Horses for sale”) not in sectioning content immediately followed by a section (“Mares”), and that the sectioning content did actually create a sub-section of the h1.

The reason for this is sectioning root. As the spec says, sectioning elements create sub-sections of their nearest ancestor sectioning root or sectioning content.

Sectioning content elements are always considered subsections of their nearest ancestor sectioning root or their nearest ancestor element of sectioning content, whichever is nearest, regardless of what implied sections other headings may have created.

The body element is sectioning root. So, if you paste the code from figure 7 into the outliner, the h1 would be the sectioning root heading, and the section element would be a sub-section of the body sectioning root.

The body element is not the only one that acts as sectioning root. There are five others:

blockquote
details
fieldset
figure
td

The status of these elements as sectioning root has two implications. First, each can have its own outline. Secondly, the outline of nested sectioning root does not appear in, nor does it have an effect on, the outline of its parent sectioning root.

In practice, this means that headings inside any of the five sectioning root elements listed above do not affect the outline of the document that they are a part of.

The final thing (you’ll be glad to hear) that I’ll say about sectioning root is that the first heading in the document that is not inside sectioning content is considered to be the document title.

Try the following code in the outliner to see what happens:

<section>
   <h1>this is an h1</h1>
</section>

<h6>this h6 comes first in the source</h6>

<h1>this h1 comes last in the source</h1>

Figure 10: How heading levels at the root level affect the outline.

I won’t try to explain this to you because it will probably only confuse both of us, so I’ll let you play with it in the outliner. Hint: try using different heading levels for the implicit sections to see how the outline is affected; for example, h3 and h4, or two h5s.

Untitled Documents

If no heading is at the root level of the document (i.e. not inside sectioning content), then the document itself will be untitled. This is a pretty serious problem, and it can occur either through carelessness or, paradoxically, by thinking carefully about how sectioning content should be used.

Roger Johansson addresses this issue in his excellent article on document outlines and HTML5 and the follow-up article.

Johansson asks how a proper document outline is supposed to be created for a blog post or other news-type item using HTML5. If you subscribe to the belief that your logo or website name should not be in an h1 element, you could mark up your blog post along the lines of the following:

<body>
   <article>
      <h1>Blog post title</h1>

      <p>Blog post content</p>
   </article>
</body>

The document is untitled. Somewhat reluctantly, Johansson settles on marking up the website’s title in h1 and using another h1 to mark up the article’s title. This is a sensible solution and is backed up by the results of the WebAIM screenreader user survey, in which the majority of respondents stated a preference for two top-level headings in exactly this format.

This same approach is also widely used on static pages that are built with HTML5 structural elements, and it could be very useful indeed for screen reader users. Imagine that you are using a screen reader to find a decent recipe for chicken pie, and you have a handful of recipe websites open for comparison. Being able to quickly find out which website you are on using the shortcut key for headings would be much more useful than seeing only “chicken pie” on each one.

Not too far behind two top-level headings in the screen reader user survey was one top-level heading for the document. This is probably my preferred option in most cases; but as we have already seen, it creates an untitled body, which is undesirable.

In my opinion, there is an easy way around this problem: don’t use article as a wrapper for single-blog posts, news items or static page main content. Remember that article is sectioning content: it creates a sub-section of the document. But in these cases, the document is the content, and the content is the document. Setting aside the name of the element, why would we want to create a sub-section of a document before it has even begun?

Remember, you can still use div!

hgroup

This is the final item in the list of things to watch out for, and it’s very easy to understand. The hgroup element can contain only headings (h1 to h6), and its purpose is to remove all but the highest-level heading it contains from the outline.

It has been and continues to be the subject of controversy, and its inclusion in the specification is by no means a given. However, for now, it does exactly what it says on the tin: it groups headings into one, as far as the outlining algorithm is concerned.

In Conclusion

The logic behind the document outlining algorithm can be hard to grasp, and the spec can sometimes feel like physics: understandable as you’re reading it, but when you try to confirm your understanding, it dissolves and you find yourself re-reading it again and again.

But if you remember the basics — that section, article, aside and nav create sub-sections on Web pages — then you are 90% of the way there. Get used to marking up content with sectioning elements and to checking your pages in the outliner, because the more you practice creating well-outlined documents, the sooner you will grasp the algorithm.

I promise, you will have it cracked after only a handful of times, and you will never look back. And from that moment on, every Web page you create will be structured, semantic, robust, well-outlined content.

Other Resources

“Creating an Outline”
The full W3C specification of the outlining algorithm.
“Document Outlines”
An explanation of the document outlines from the HTML5 Doctor.
“Sectioning content” and “Sectioning root”
The W3C specifications of sectioning content and sectioning root.
“Sections and Outlines of an HTML5 Document”
HTML5 sections and outlines explained on the Mozilla Developer Network. Note that header and footer are not sectioning content.
“HTML5 Sectioning Elements, Headings, and Document Outlines” and “HTML5 Document Outline Revisited”
Roger Johansson’s articles on the issue of sectioning content creating untitled documents.

(al)

Smashing Magazine Feed

HTML5 GeoLocation

Posted on July 28, 2011 by Portsmouth Media in Blog Leave a comment

An article I was reading about jquery

With this tutorial you will understand how to use HTML5 geo location

Advertise here via BSA

Good-Tutorials: Newest Tutorials

Stop obsessing over HTML5 and CSS3

Posted on June 20, 2011 by Portsmouth Media in Blog Leave a comment

An article I was reading about photoshop

href=’http://rss.buysellads.com/click.php?z=1259940&k=75e07a75487088b1694a6868e9c95d21&a=23190&c=172514885′ target=’_blank’> src=’http://rss.buysellads.com/img.php?z=1259940&k=75e07a75487088b1694a6868e9c95d21&a=23190&c=172514885′ border=’0′ alt=” />

href=’http://buysellads.com/buy/sitedetails/pubkey/75e07a75487088b1694a6868e9c95d21/zone/1259940′ target=’_blank’>Advertise here with BSA

href=”http://netdna.webdesignerdepot.com/uploads/2011/04/thumb13.jpg”> class=”alignleft size-full wp-image-23194″ title=”thumb” src=”http://netdna.webdesignerdepot.com/uploads/2011/04/thumb13.jpg” alt=”" width=”200″ height=”160″ />As web designers, we all seem obsessed by HTML5 and CSS3 at the moment. Endless posts, tutorials and discussion about them dominate the blogosphere. But how much are we learning that can be applied today?

Don’t get me wrong. We all need to understand HTML5 and CSS3. And a lot of it can be used today.

My point is that we seem to be spending a disproportionate about of time reading up on the subject when so many other areas deserve our attention.

While others are reading yet another tutorial on CSS animation, why not broaden your horizons by researching subjects that will allow you to offer an even better service to clients?

I’ll share with you five areas that I believe are much neglected and that we need to learn more about. id=”more-23190″>

href=”http://www.paulrhayes.com/2011-02/creating-a-sphere-with-3d-css/”> class=”image-border” src=”http://netdna.webdesignerdepot.com/uploads/stop_obsessing_html5_css3/01.png” alt=”Demo of a 3D sphere created in CSS3″ /> /> Do you really need to know how to create a 3-D sphere in CSS3? (Image: href=”http://www.paulrhayes.com/2011-02/creating-a-sphere-with-3d-css/”>Paul Hayes)

class=”spacer_” />

1. Customer service

“Customer service?!” you cry. “I don’t work at Starbucks!”

If that’s your attitude, think again. Customer service lies at the heart of everything we do as web designers, and yet we rarely think about it, let alone read anything on the subject.

href=”http://www.flickr.com/photos/chicagobart/4275312147/sizes/l/”> src=”http://netdna.webdesignerdepot.com/uploads/stop_obsessing_html5_css3/02.jpeg” alt=”A member of staff working in starbucks.” /> /> You may not work at Starbucks, but customer service is intrinsic to our role as web designers. (Image: href=”http://www.flickr.com/photos/chicagobart/4275312147/sizes/l/”>ChiBart)

We need a good grounding in customer service for a couple of reasons. First, we are in the service business. We like to think that we build stuff, but actually we are offering a service to our clients. We don’t just build websites: we guide clients through an unfamiliar process and provide a lot of advice and support along the way.

Secondly, the majority of websites that we build have a strong element of customer service. We provide a service to end users in the form of either an application or, more often than not, information.

Whether we want to offer a better service to clients or end users, the message is the same: we need to brush up on our customer service skills.

My recommendation is to start by subscribing to a few customer service blogs. href=”http://experiencematters.wordpress.com/”>Customer Experience Matters a good starting point.

class=”spacer_” />

2. Psychology

Understanding of psychology should be woven into every aspect of our job, from sales to project management to user interface design to design aesthetics. Everything we do as web designers should be informed by knowledge of how people think.

Unfortunately, few of us have taken Psychology 101. What we do know we have learned instinctively rather than through any formal training. We design based on gut reaction rather than informed knowledge.

Being able to get inside the heads of others is crucial, whether it’s users or clients. Whoever it is, we have to know our stuff.

href=”http://getmentalnotes.com/resources”> src=”http://netdna.webdesignerdepot.com/uploads/stop_obsessing_html5_css3/03.jpeg” alt=”Stephen Anderson’s psychology resources” /> /> A href=”http://getmentalnotes.com/resources”>great introduction to the field of human psychology, curated by Stephen Anderson. (Image: href=”http://getmentalnotes.com/resources”>Mental Notes)

Thankfully, Stephen Anderson has pulled together a href=”http://getmentalnotes.com/resources”>great set of resources to introduce the field of human psychology. If his extensive list is a little intimidating, I recommend starting with “ href=”http://amzn.to/g4MVhX”>Made to Stick” or “ href=”http://amzn.to/htInHj”>Nudge.” “ href=”http://amzn.to/f6P3MU”>Neuro Web Design” is very good, too.

class=”spacer_” />

3. Context

There was a time when you could make an educated guess at the user’s context. Surfing the web was done at a desktop computer in relative quiet. Unfortunately, despite those days being long gone, many of us still assume that context when designing websites.

The reality is very different. For starters, we rarely have the user’s full attention. They are surrounded by distraction, both offline and on. The computer is now as likely to be in the family room with kids running amok as in a quiet study. While looking at your website, the user is probably also checking email, catching up with friends on Facebook and tweeting.

The problem doesn’t end there. We no longer just surf the web on a desktop computer. There are netbooks, tablets, televisions and mobile devices of all shapes and sizes.

href=”http://www.shutterstock.com/”> src=”http://netdna.webdesignerdepot.com/uploads/stop_obsessing_html5_css3/04.jpeg” alt=”Girl using a mobile phone while on a train.” /> /> We can no longer assume that people access the web from a desktop computer. (Image: href=”http://www.shutterstock.com/”>Shutterstock)

Unfortunately, not a huge amount has been written on the subject, beyond my own href=”http://boagworld.com/usability/content-is-dead-long-live-context/”>rambling thoughts. But I am convinced this will be a defining factor in web design over the coming years.

If we want to continue creating cutting-edge websites, then we need to take context seriously. Ultimately, good web design is more about context and content than HTML5 and CSS3.

class=”spacer_” />

4. Content strategy

How did we ever decide that content was the client’s problem? Why should we expect them to know about writing for the web when we, as self-proclaimed web experts, do not?

Content is the foundation of every website. This includes content in all its forms: images, text, video, audio and functionality.

How a website is built and what it looks like pales in comparison to the content. Still, many of us regard it as the client’s problem.

Clients will be demanding a lot more help to get their content right, and if you don’t offer it, then they will turn to your competitors. I would be willing to bet my company on it.

Don’t get me wrong. You don’t need to become an expert content strategist. As McCoy would say, “Damn it, Jim! I’m a web designer, not a copywriter.” (Okay, he was a doctor, but you get the point.)

But just because you are not a content strategist doesn’t mean you can ignore the basics of writing for the web. You should know what a content audit is, how to make copy more scannable, and what goes into a style guide.

If you can’t answer these (and many other similar questions), then it is time to upgrade your skills. A good starting point is anything by href=”http://24ways.org/authors/rellyannettbaker”>Relly Annett-Baker, or get your hands on Kristina Halvorson’s book href=”http://amzn.to/gvRVFM”>Content Strategy for the Web.

href=”http://contentstrategy.com/”> src=”http://netdna.webdesignerdepot.com/uploads/stop_obsessing_html5_css3/05.jpeg” alt=”contentstrategy.com/” /> /> Kristina Halvorson’s book href=”http://amzn.to/gvRVFM”>Content Strategy for the Web is great for learning the basics of content strategy.

5. Strategy

Things used to be so simple for the average client. They came to you, and you built a website that sold whatever service they were selling. Now we ask them complicated questions about business objectives, success criteria and calls to action. Compounding their worries, they have to think about Facebook, SEO, Twitter, user engagement and endless buzzwords.

In short, the average client is no longer looking for someone to just build a website. They are looking for a consultant to guide them through the confusing online world. They need someone who can look at their business and answer one simple question: how can the web best help them?

The problem is that most web designers are either frustrated artists or code monkeys (okay, maybe that’s a stretch). But we are not business advisers.

href=”http://www.shutterstock.com/”> src=”http://netdna.webdesignerdepot.com/uploads/stop_obsessing_html5_css3/06.jpeg” alt=”Geek Dressed as Business consultant” /> /> How much do we really know? (Image: href=”http://www.shutterstock.com/”>Shutterstock)

We like to think that we know how the web can benefit a business. But we really don’t know that much. We are not schooled in business theory, marketing or economics.

Again, we don’t need to pretend to be something we’re not. But we do need to improve our basic understanding of these topics so that we are at least capable of having a discussion with business folk about how the web can help them.

When was the last time you read an article on direct marketing or corporate restructuring?

class=”spacer_” />

The problem

Herein lies the problem. We are so busy reading HTML5 tutorials and looking at CSS3 demos that we miss these other areas.

We are scared by what we do not know, and so we tether ourselves to subjects that we have a handle on. But as the web becomes more complex, we will need to broaden our horizons.

I am not suggesting that we all become generalists. I am saying that our skill set should be T-shaped. We need broad superficial knowledge of a lot of subjects and then deep insight into one area. The problem is that most of us don’t look beyond that one area of expertise.

If you don’t broaden your outlook, clients will look elsewhere.

class=”spacer_” />

Written exclusive for WDD by Paul Boag. He is the founder of UK Web design agency rel=”nofollow” href=”http://headscape.co.uk/”>Headscape, author of the rel=”nofollow” href=”http://boagworld.com/websiteownersmanual”>Website Owners Manual and host of award-winning Web design podcast rel=”nofollow” href=”http://www.boagworld.com/”>Boagworld.com. He is also rel=”nofollow” href=”http://twitter.com/boagworld/”>addicted to Twitter.

What do you think of these ideas? Are we too obsessed with HTML5 and CSS3 and missing the big picture? Share your thoughts below. />

If you find an exclusive RSS freebie on this feed or on the live WDD website, please use the following code to download it: O1Rs1S

/>
width=”100%” style=”border-top:1px solid #d7d7d7; border-bottom:1px solid #d7d7d7;” height=”20″>
valign=”center”> href=”http://mightydeals.com/deal/fanurio.html?ref=inwidget”> face=”Arial” size=”3″ color=”#e64f32″>Get Fanurio time tracking and billing for freelancers width=”90″> href=”http://www.mightydeals.com/?ref=inwidget”> /> src=”http://mightydeals.com/web/images/widget-logo.png” height=”40″ width=”90″ border=”0″ /> />

href=”http://www.webdesignerdepot.com/2011/06/stop-obsessing-over-html5-and-css3/”>Source