HTML5 Doctor » footer

Your Questions Answered #10

Richard Clark — Fri, 09 Jul 2010 12:45:00 +0000

The clinic is getting busy with more HTML5 ailments. This week, we’ll cover using sections within a footer, vs. Flash security, why HTML5 elements are treated as inline, using offline with storage, and marking up block quotes.

Footer with sections

Tommie asked:

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

Thanks!

You could use a

within

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

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

Cheers, Rich

vs. Flash (security and copyright)

John asked:

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

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

Thanks for any input.

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

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

Cheers, Rich

HTML5 tags inline?

Tami asked:

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

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

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

Thanks, Bruce.

Offline + Storage

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

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

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

Thanks in advance for any help you can provide.

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

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

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

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

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

Hope that helps a bit, Remy

Correct markup with blockquote

Phil asked:

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

In HTML5 that requirement seems to have been relaxed, as the following element validates successfully:
This is a blockquote.
The HTML5 spec uses the p element in the usage examples, but does not mention whether it is required.

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

Great question. As I expected, this validates:



blockquote test
Tiger tiger burning bright

We double-checked with the WHATWG mailing list and confirmed that

can contain ‘flow’ content (i.e., text, paragraphs, etc.).

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

Bruce

Got a question for us?

That wraps up this round of questions! If you’ve got a query about the HTML5 spec or how to implement it, you can get in touch with us and we’ll do our best to help.

Share and Save:

Your Questions Answered #10 originally appeared on HTML5 Doctor on July 9, 2010.

Your Questions Answered #8

Richard Clark — Wed, 05 May 2010 13:00:55 +0000

We’re back with more of your questions (and our answers) about HTML5. In this article, we’ll discuss using a

at the top of your markup, how to skip to certain parts of a video, styling form elements and attributes, and more.

HTML5
on top

David asked:

Hi!

I wonder if it possible to put the footer on top such as www.perfectfools.com with HTML5 and still make the HTML validate.

Thanks a lot and best regards!

David

HTML elements should always describe their content, so if you think that

is most suitable for your content, then you’re absolutely entitled to use it. Despite its name,

’s position is in no way restricted — visually or ordinally — within a document.

Cheers, Rich

Skip to certain parts of a video file

John Paul asked:

Hello

supposing I have a very long video file in an accompanying video element, without using the controls, how do I skip to certain time stages through the API? Much as one would on a DVD menu, for example.

Apologies if this has been asked already.

JP

You can achieve this using JavaScript and data attributes. Check out these articles from Bruce Lawson and Patrick Lauke from Opera. They’ve used data attributes to add subtitles, but you could just as easily use the attributes to jump to specific parts of a video.

For example, set data-start and data-end attributes on your element. You can then use JavaScript to read the attribute values, set the current position of the video using the currentTime attribute, start playing the video via the play() method, and even stop playing the video by listening for the timeupdate event and stopping the video with pause() once it’s reached a specified time. See the spec for the HTMLMediaElement object for more details.

Cheers, Rich

In addition to this, the recent addition of the track element will make this more easily achievable. We will cover the track element in more detail soon.

s within navigation links

Benjamin asked:

Hey,

I’m currently doing up the new version of my website, and decided to do it in HTML5.

One area I’m confused about is whether or not for navigation links I should be using a h1 or h2 element.

For example:
    
        Actions
    
    
        Sitemap
        Login
        Search
        Enquire
    
Should those span.title elements be wrapped in a h2? My thoughts on why this would be required is for an outline, as navigation should appear in the outline right?

Thanks a bunch.

In theory, yes, navigation should appear in the outline. I personally don’t think it should require a heading, and I know there have been requests to the developers of the outline algorithm to make

show as a ‘Navigation’ element rather than ‘untitled section’.

If you want to use a heading within your

element, using an

would be fine. You don’t really need the

element in there too. The outline would be calculated correctly without it. With current browser implementations, however, I don’t think it would make much difference if you used an

.

You don’t need the elements in the

s. They aren’t required in the outline unless they’re providing a table of contents for the document.

I hope that answers your question. We plan to write an article regarding outlining soon.

Cheers, Rich

Styling supported HTML5 form elements and attributes

Mike asked:

First off, I wanted to say I really appreciate the service this site is doing. I have found this site to be a very valuable resource and is always the first place I look when I have a question about implementing HTML5.

How do I style/edit/change the UI generated feedback for the new HTML5 form elements and attributes. For example, In Opera, is there a standard CSS notation to style the error message so that it doesn’t necessarily show up under the field in red? Where in the DOM is it inserted? Is the message for a required field customizable? Finally, is this information specified in the HTML5 spec or are the implementation details left up to the browsers?

There is currently no way to use CSS to style error messages. As the HTML5 spec isn’t finished yet, it’s a bit early to start specifying new CSS.

The HTML5 spec defines no UI requirements regarding how browsers should display messages.

You can override a browser’s default behaviour with JavaScript. I’m not a scripter, but I reckon you would need to attach an event handler to the error event and have the handler cancel the default action and show a custom error message. I think that as long as you call evt.preventDefault() within the event handler, it should prevent showing the default error message. Then you can add an element into the DOM and style it as you wish, with the default error handling as a fallback for those without JavaScript. If anyone gives this a go and gets it working, we’d be very interested to see the results.

Ta, Bruce

Section headers

Tibor asked:

Hi. I would like to know, how to use section’s headers. Is this code correct?
	header 1


	header 2
or I have to use header element inside every aside, article, section etc.
	
    	header 1
	


	
    	header 2
	
Tibor

Your first example is correct. You only need

to group items within a header. If the header contains only a single

–
element, you don’t need to wrap it in a
.

Thanks, 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.

Related Posts:

Your Questions Answered #5

Your Questions Answered #7

Your Questions Answered #4

Video: the track element and webM codec

Your Questions Answered 9

Share and Save:

Your Questions Answered #8 originally appeared on HTML5 Doctor on May 5, 2010.

The Footer Element Update

Jack Osborne — Tue, 29 Sep 2009 13:00:30 +0000

Update

When I wrote the previous version of this article a few months ago, I knew, as I’m sure many of you also knew, that this element in particular would be subject to change as the HTML 5 spec neared it’s completion. The problem was simple, the footer element just didn’t feel 'complete', it just didn’t offer the same flexibility as other elements. Now that’s changed.

In summary, the content model for the footer element has been changed to allow sectioning content like header or like nav. In fact it now works in very much the same way as the header element. However, it’s important to note that footer isn’t sectioning content and doesn’t introduce a new section.

If you’ve been working on a site and have incorporated a wonderful new footer with everything that it now allows please feel free to post a link in the comments to show other readers just what you can get away with.

Below is an updated copy of the original article.

Old Article

For some time now we’ve become accustomed to seeing

at the bottom of web pages but with the introduction of HTML 5 it’s time to say goodbye. With the addition of the new

element we now have more scope and flexibility.

According to the spec

The footer element represents a footer for its nearest ancestor sectioning content or sectioning root element. A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like.

Lets get started

Before we get stuck into dissecting the new element, let’s lay the foundations for the article and cover the basics. As we’ve already mentioned above, most people would have laid out the footer as follows


  
     copyright
     sitemap
     contact
     to top

However with the creation of HTML5 this is no longer the case. As you may already know, there is now no longer the need for the

element for many elements. In our case, when referring to the footer, the appropriate markup would be


  
     copyright
     sitemap
     contact
     to top

As I mentioned in the first paragraph, originally the

element was only utilised once within our pages but with the introduction of the new element, this no longer needs to be the case. The

element can now be used multiple times and to display all the extra information.

Using the footer element

An important point to note is that you are not restricted to use one

element per site, you can use multiple footers, each of which will then become the

for that section of the document. You could therefore have a

for a

or an

Section


   Section content appears here.
   
   Footer information for section.

Article


   Article content appears here.
   
   Footer information for article.

To see an example of the

September HTML5 spec changes

Remy Sharp — Thu, 17 Sep 2009 12:00:20 +0000

September being one month before the HTML5 spec goes to last call in October, there’s been a few significant changes to the HTML5 spec that we wanted to briefly share with our patients.

Clarification over `section` and `article`

The spec has been clarified to help authors correctly choose between when to use section and when to use article, and Bruce’s section post has also been updated.

`footer` now works like `header`

This was a big one and causing confusing to people coming to HTML5 for the first time. Originally you couldn’t include a nav element inside a footer, or a section.

Now the spec has been changed to match the header element.

`details` and `figure` saved

Instead of using legend, which didn’t work, Jeremy suggested (although slightly tongue in cheek) to use dt for the title and dd for the body. Ian Hickson agreed, and it’s in

Example:


 
 
Exhibit B. The Rough Copy trailer.

`aside` has better examples

The documentation has been updated to specify better examples of how the aside element can be used.

Better examples help us authors understand how it can be used.

Dropped Elements

The following elements have been dropped from the HTML5 spec (though bb and datagrid were some time ago, and datagrid has been postponed rather than dropped entirely):

dialog
bb
datagrid

Ch-ch-changes

We’ll be posting in more detail about some of these changes, and as further changes come out of the editing process we’ll no doubt keep you all up to date, either via our Twitter account (which you should follow) or feel free to let us know too!

Share and Save:

September HTML5 spec changes originally appeared on HTML5 Doctor on September 17, 2009.

Designing a blog with html5

Bruce Lawson — Tue, 30 Jun 2009 14:00:21 +0000

Much of HTML 5’s feature set involves JavaScript APIs that make it easier to develop interactive web pages but there are a slew of new elements that allow you extra semantics in your conventional Web 1.0 pages. In order to investigate these, let’s look at marking up a blog.

Firstly what we’ll do is use the header, footer, and nav elements to mark up the broad structure of the page. We’ll make the blog comments form much smarter by using the new data types and built-in validation available in HTML 5-aware browsers.

Then we’ll do some work on the guts of the page, using HTML 5’s article elements to better mark up blog posts and comments and show how to use the section elements to better structure accessible hierarchical headings on sites that are CMS-driven. As blogs are chronologically ordered, we’ll see what HTML 5 offers us for representing dates and times.

So take the phone of the hook, and make a cup of tea and we’ll get started.

Setting the DOCTYPE

HTML 5, when used as plain HTML rather than its XHTML 5 sibling doesn’t need a DOCTYPE. But all browsers do, otherwise they go into Quirksmode, which you don’t want: the collision of HTML 5 and Quirksmode is like matter and anti-matter meeting, and will cause a negative reality inversion that will make your underwear catch fire.

You’ve been warned, so at the top of your document, you need the line .

Some sites “use” HTML 5, when in actual fact all they’ve done is take their existing code and change the DOCTYPE. That’s fine and dandy if you’ve been using valid, semantic code as HTML 5 is very similar to valid HTML 4.01. Eric Meyer mentions small differences like “not permitting a value attribute on an image submit”, and there are a few differences between the languages, summarised in the document HTML 5 differences from HTML 4.

However, I don’t want simply to rebadge my existing code, but to use some of the new structural elements now.

Using some new structural elements

My blog – like millions of others – has a header denoted by

, a footer

, some articles (wrapped by an area called “content”,

) and some navigation (wrapped up in an area called “sidebar”

). Most sites on the Web have similar constructs, although depending on your choice they might be called "branding" or "info" or "menu", or you might use the equivalent words in your own language.

Although these all have very different functions within the page, they use the same generic div in the markup. as HTML 4 has no other way to code them. HTML 5 has new elements for distinguishing these logical areas: header, nav, footer and friends. (There’s more on this in an artice by Lachlan Hunt on A List Apart: A Preview of HTML 5.)

The overall aim is to replace this structure:

with this:

It’s a simple matter to change the HTML divs into the new elements. The only difficulty I had was deciding which element to use to mark up my sidebar, as it also includes a search field and “colophon” information as well as site-wide navigation. I decided against the aside element, as the spec says it “represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content”, but it’s nevertheless content rather than navigation. So I decided to go for the nav element as the closest fit.

I’ve wrapped the main content in a section element (previously I’d kept it as a div). section is defined in the spec

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

Please note: I no longer recommend wrapping the whole content area in a section element, and suggest that you use a div element. Read more about using section appropriately.

In this case, the “generic document section” is that of main content. I’ve retained an id so that a skip links feature will work, although I hope that in the future, assistive technology will offer an automatic way for people to go to the first section or article.

My fellow HTML 5 doctor, Remy Sharp, also notes that if you retain the div, Internet Explorer without JavaScript would style the div, but none of the other content, making the site very hard to read.

New form attributes

As well as the main structural item on the page, I’ve added some new attributes on input elements in the comments form.

HTML 5 was designed to reflect what developers actually do rather than to reflect a philosophical purity, and that’s very clearly manifested in the new attributes which mean the browser takes up much of the work currently done by developers re-inventing validation routines in JavaScript. (Extending forms functionality was how the HTML 5 spec began).

So I amended the email input field in the comments to be input type="email" which means that when the user submits the form, an HTML 5-aware browser will use built-in validation routines to check that it’s in the correct format, without any JavaScript. Check it out in the current version of Opera, as that the only full implementation at the time of writing (June 2009), and note that it also adds a “mail” icon in the input field as a cue to the user.

There are similar input validation routines triggered by some of the new input types, such as url (which I use on the field that asks for the user’s web address), number and pattern which compares the input with an arbitrary regular expression.

Another good example is input type="date", which pops up a calendar widget/ date picker when the user focusses on the input field. You can test the date picker, or here’s a screenshot from Opera 9.6:

A very useful new attribute I used on both input fields for commenter’s name and email address, and the comment textarea was type="required" which generates a message on submission if the fields are left blank. Each different localisation of a browser would need to have a different message, and it’s not (so far) customisable by the developer.

The good thing with all this new form fabulousness is it’s all formed around new attributes on an exisiting element, so people using older browsers just see a plain old input field.

A note on screenreaders and HTML 5

I hope screenreaders are ready for these new interactions; I asked the html 5 group to formally invite screenreader vendors to participate in the specification; to my knowledge, none have done so.

Laying out the new elements

It’s not too hard to layout the new elements. In all the non-IE browsers, you can lay out anything using CSS – even a nonsense element. One gotcha is that that the current crop of browsers have no “knowledge” of these elements, although support is improving all the time.

All browsers have default settings for the elements they “know about”—how much padding, margin they element gets, does it display as a block or inline?. (Here’s a sample default stylesheet.) Unless over-ridden by CSS, these defaults apply. But the browsers don’t know about header, nav and the like, so have no defaults to apply to them.

I got terrible rendering oddities until I explicitly told the browsers

header, footer, nav, article {display:block;}

IE layout

There’s one gotcha about styling HTML 5 pages in IE: it doesn’t work. You can force it to quite easily with a JavaScript hack document.createElement('element name'). (Lachlan Hunt gets to the bottom of why IE needs this.)

For your convenience, Remy Sharp has written an HTML 5 enabling script which I use in the header to conjure all the missing elements into existence all at once.

But let’s be clear: this won’t work if your IE user doesn’t have JavaScript turned on. How much of that’s a big deal that is for you to decide. Pragmatically, it seems to me that the sites that will benefit the most from HTML 5’s new “Ajax”-style features, such as drag-and-drop, are the sites that currently have no hope of working without JavaScript.

Firefox 2 and Camino 1 layout

Firefox 2 and Camino 1 both use Gecko 1.9 which has a bug and so gets grumpy if you don’t serve the page as XHTML. (Go figure; that’s almost enough to trigger a negative reality inversion and you know how bad that can be). However, Firefox and Camino users upgrade frequently so Firefox is in version 3, while Camino 2 beta is out, so the problem will soon cease to exist. (Read more at How to get HTML5 working in IE and Firefox 22 by Remy Sharp.)

What’s the point of those new structural elements?

Well, they add semantics to the page. The browser now knows which area of your site is the header or the footer because there are header and footer elements, whereas div might be called “branding” and “legal”, or even “en-tete” and “pied-de-page” or “kopfzeile” and “fusszeile“.

But so what?

Robin Berjon expressed it beautifully in a comment on A List Apart:

Pretty much everyone in the Web community agrees that “semantics are yummy, and will get you cookies”, and that’s probably true. But once you start digging a little bit further, it becomes clear that very few people can actually articulate a reason why. So before we all go another round on this, I have to ask: what’s it you wanna do with them darn semantics?

The general answer is “to repurpose content”. That’s fine on the surface, but you quickly reach a point where you have to ask “repurpose to what?” … I think HTML should add only elements that either expose functionality that would be pretty much meaningless otherwise (e.g. canvas) or that provide semantics that help repurpose for Web browsing uses.

In my view, there are a couple of things I want to do with those semantics. The first is for search engine use; it’s easy to imagine Messrs Google or Yahoo! giving lower weighting to content in footer elements, or extra weight to content in the header. The second reason is to make the site navigable for people with disabilities. People with learning difficulties might instruct their browser always to put the articles before the navigation, for example. User agents might very well have a keyboard shortcut which jumped straight to the nav for example, or jumped straight past the navigation, in a programmatic implementation of “skip links“.

Which brings me to…

Further refining the HTML 5 structure

The blog home page

An interesting thing about a blog homepage is that there are generally the last 5 or so posts, each with a heading, a "body" and data about the post (time, who wrote it, how many comments etc.) and usually a link to another page that has the full blog post (if the homepage just showed an excerpt) and its comments.

HTML 5 has an article element which I use to wrap each story:

The article element represents a section of a page that consists of a composition that forms an independent part of a document, page, or site. This could be a forum post, a magazine or newspaper article, a Web log entry, a user-submitted comment, or any other independent item of content.

Let’s look in more detail at the guts of how I mark up each blogpost.

Anatomy of a blog post

The wrapper is no longer a generic div but an article. Within that is a header, comprising a heading (the title of the blogpost) and then the time of publication, marked up using the time element.

Then there are the pearls of wit and wisdom that consitute each of my posts, marked up as paragraphs, blockquotes etc., and is pulled unchanged out of the database. Following that is data about the blog post (category, how many comments) marked up as a footer and, in the case of pages that show a single blogpost, there are comments expressing undying admiration and love. Finally, there may be navigation from one article to the next.

Data about the article

Following the content there is some “metadata” about the post: what category it’s in, how many comments there are. I’ve marked this up as footer. I previously used aside which “represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content” but decided that it was too much of a stretch; data about a post is intimately related.

footer is a much better fit: “A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like.” I was initially thrown off-course by the presentational name of the element; my use here isn’t at the bottom of the page, or even at the bottom of the article, but it certainly seems to fit the bill – it’s information about its section, containing author name, links to related documents (comments) and the like. There’s no reason that you can’t have more than one footer on page; the spec’s description says "the footer element represents a footer for the section it applies to" and a page may have any number of sections. The spec also says "Footers don’t necessarily have to appear at the end of a section, though they usually do."

Comments

I’ve marked up comments as articles, too, as the spec says that an article could be “a user-submitted comment”, but nested these inside the parent article. The spec says

When article elements are nested, the inner article elements represent articles that are in principle related to the contents of the outer article. For instance, a Web log entry on a site that accepts user-submitted comments could represent the comments as article elements nested within the article element for the Web log entry.

These are headed with the date and the time of the comment and name of its author—if you want, you can wrap these in a header, too, but to me it seems like markup for the sake of it.

Times and dates

Most blogs, news sites and the like provide dates of article publication.

Microformats people, the most vocal advocates of marking up dates and times, believe that computer-formatted dates are best for people: their wiki says “the ISO8601 YYYY-MM-DD format for dates is the best choice that is the most accurately readable for the most people worldwide, and thus the most accessible as well”. I don’t agree (and neither do candidates in my vox pop of non-geeks, my wife, brother and parents).

I do agree with the microformats people that hidden metadata is not as good as visible, human-readable data and therefore elected not to use the pubdate attribute of article.

Therefore I’ve used the HTML 5 time element to give a machine parsable date to computers, while giving people a human-readable date. Blog posts get the date, while comments get the date and time.

The spec is quite hard to understand, in my opinion, but the format you use is 2004-02-28T15:19:21+00:00, where T separates the date and the time, and the + (or a -) is the offset from UTC. Dates on their own don’t need a timezone; full datetimes do. Oddly, the spec suggests that if you use a time without a date, you don’t need a timezone either.

There’s considerable controversy over the time element at the moment. Recently one of the inner circle, Henri Sivonen, wrote that it’s for marking up future events only and not for timestamping blogs or news items: “The expected use cases of hCalendar are mainly transferring future event entries from a Web page into an application like iCal." This seems very silly to me; if there is a time element, why not allow me to mark up any time or date?

The spec for time does not mention the future event-only restriction: "The time element represents a precise date and/or a time in the proleptic Gregorian calendar" and gives three examples, two of which are about the past and none of which are "future events". Although the spec doesn’t (currently) limit use of the element, it does limit format to precise dates in "the proleptic Gregorian calendar". This means I can mark up an archive page for "all blog posts today" using time, but not "all July 2008 posts" as that’s not a full YYYY-MM-DD date. Neither can you mark up precise, but ancient dates, so the date of Julius Ceasar’s assassination, 15 March 44 BC is not compatible.

I don’t expect this to be resolved. If you think as I do, feel free to mail the Working Group to express your feeling!

Hopefully, this brief article (geddit?) has given you a quick overview of how to use some of the new semantic elements. Let me know what you think!

Share and Save:

Designing a blog with html5 originally appeared on HTML5 Doctor on June 30, 2009.

The footer element

Jack Osborne — Mon, 29 Jun 2009 15:00:13 +0000

For some time now we’ve become accustomed to seeing

at the bottom of web pages but with the introduction of HTML 5 it’s time to say goodbye. With the addition of the new

element we now have more scope and flexibility.

According to the spec

The footer element represents the footer for the section it applies to. A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like.

Lets get started


  
     copyright
     sitemap
     contact
     to top

However with the creation of HTML 5 this is no longer the case. As you may already know, there is now no longer the need for the

element for many elements. In our case, when referring to the footer, the appropriate markup would be


  
     copyright
     sitemap
     contact
     to top

As I mentioned in the first paragraph, originally the

element was only utilised once within our pages but with the introduction of the new element, this no longer needs to be the case. The

element can now be used multiple times and to display all the extra information.

Using the footer element

An important point to note is that you are not restricted to use one

element per site, you can use multiple footers, each of which will then become the

for that section of the document. You could therefore have

Section


   Section content appears here.
   
   Footer information for section.

Article


   Article content appears here.
   
   Footer information for article.

To see an example of the