There are two somewhat major gotchas in the way Firefox 3.x handled HTML5. The first is easily fixed with a few lines of CSS. The second can only really be fixed if you rewrite some of your HTML.

Block vs. Inline

When Firefox first introduced support for new HTML5 elements, all of those new elements were treated as inline. Therefore, if you want Firefox 3.5.x to treat your new HTML5 elements the same way newer versions of Firefox, Chrome, Safari, Opera and even IE (IE7 & 8 require an HTML5 script like HTML5 Shim/Shiv to add support), you need to include a little bit of reset CSS.

Thankfully, the HTML5 Doctor has provided us with a nice HTML5 branch of Eric Meyer’s reset stylesheet that includes a line that explicitly declares which HTML5 elements should be treated as block-level (hat-tip to Keri Henare for pointing me to that reset stylesheet).

If you, like me, use a separate reset stylesheet (I tend to include the Yahoo! User Interface reset CSS in all of my projects), you can still just copy the necessary code from the HTML5 Doctor sheet and paste it in at the top of your custom stylesheet.

I’ve included that specific block of code below, but I would still recommend visiting the HTML5 Doctor article to keep up with any changes or additional information you might need.

article,aside,details,figcaption,figure,
footer,header,hgroup,menu,nav,section {
    display:block;
}

Anchors Aweigh

The second major issue is quite a bit more frustrating. One of the great new features introduced in HTML5 is the ability to wrap block-level elements and even multiple elements in a single anchor tag. For instance, you can now do something like:

<a href="http://google.com/">
<p>This is a paragraph</p>
<p><img src="http://example.com/img.jpg"/></p>
<p>More text below the image</p>
</a>

Unfortunately, when Firefox 3.x sees code written like that, it tries to “fix” it. The DOM (document object model) then gets all messed up, and your elements end up all over the screen (or they don’t show up at all), instead of being arranged the way you would expect.

Sadly, at this time, the only solution I see is to stick with only using anchor tags inside of your block-level elements; not wrapping them around multiple block elements.

Thoughts?

Of course, I didn’t even begin to touch on all of the CSS3 (which, despite what the buzz around the Web might lead you to believe, is not HTML5) features and functions that are missing from Firefox; but for the most part, that falls into the category of graceful degradation.

Do you have better solutions? Are you at all worried about making your site work in Firefox 3.5 or 3.6? Are there other serious issues I might have missed? Let me know.

As a sidenote, if you (like me) don’t have access to a copy of Firefox 3.x on your computer anymore, you can still grab one from OldVersion. The instructions I posted back in April 2007 explaining how to install multiple copies of Firefox still work just fine, if you need to install 3.x alongside the newest version(s).

Related posts:

1. Use HTML5 Elements in Today’s Browsers
2. Captions in HTML5
3. What Is HTML5?

While articles, asides, headers, footers, etc. are a fantastic way to introduce semantics into your page designs, there are a few elements and attributes that might not do quite what you’d expect.

Details & Summary

To begin with, let’s take a look at the <details> and <summary> elements. From my understanding of the new spec, the <details> element is supposed to include information about the page or article (such as author information, copyright, etc.). The <summary> element is supposed to be the really important information from that <details> umbrella.

What you might not know, however, is that some browsers (namely Chrome) handle the <details> and <summary> elements differently than other browsers currently do. I’m honestly not sure which browser implementation is correct, but they are pretty drastically different.

When a <details> element is used, Chrome automatically collapses its contents, adds an arrow next to it and adds an onclick handler to it so that the full content of the <details> element are shown only when clicked. If you include a <summary> tag inside the <details> element, that <summary> information will be the only text initially shown.

Any styles applied to the <details> element are essentially ignored by Chrome.

Form Handling

Another gotcha to watch out for is the way modern browsers handle forms. At this point, I believe Chrome, Safari, Firefox and Opera have all implemented ways to handle “required” elements in forms. In each of those browsers, if any form element has the “required” attribute, the browser will refuse to allow the user to submit the form until each of those elements has a value.

There are two issues I’ve experienced with these implementations.

First of all, each browser uses a completely different style of warning messages. There is no way (at least, as of yet) to style those warning messages. Last time I checked, the messages in Opera and Firefox were fairly attractive, but the messages in Chrome were incredibly ugly (sometimes the bubble in which the warning message appears doesn’t even stretch to the width of the message).

Another issue is that the implementation of these attributes is still being tested. There are minor (sometimes inconsistent) bugs in each of the browsers. A few months ago, when I was using the required attribute on a form, I found that some of the browsers had a lot of trouble recognizing when a radio button or select element had a value. No matter what value was chosen for those elements, the browser continued to stop the submission of the form, indicating that they were required.

Conclusion

The bottom line is, HTML5 brings with it some great possibilities; but it is still a very volatile technology. If you are going to use HTML5 for your projects, it might be a good idea to check on them fairly regularly to make sure that they still look the way you initially designed them. Of course, that said, even if you use XHTML1 or HTML4 with CSS2; the constant evolution of browsers might warrant a regular check on your pages anyway.

Related posts:

1. What Is HTML5?
2. Captions in HTML5
3. Use HTML5 Elements in Today’s Browsers

More than two years ago, Opera added support for the projection media mode in CSS. Whenever the browser is expanded to full screen mode, it activates the projection media, allowing you to apply a completely different stylesheet to the full screen page than you have in other settings.

To take things a step further, if you include page-break instructions within the projection style sheet, Opera will treat each page as a separate screen, allowing you to use the Page Up and Page Down buttons on your keyboard to navigate from screen to screen.

With these features, you can actually use Opera to display a presentation built entirely with HTML and CSS (that’s right, no JavaScript and no Flash is necessary). Because you can build the presentation with HTML, you can make it more robust than a PowerPoint presentation, and it is infinitely more flexible and portable (after all, even if someone doesn’t have Opera on their computer, they can still view the contents of your presentation without any proprietary software).

To make things really flexible, I would recommend creating one style sheet for the screen that will style your presentation as a nice Web page for all browsers; creating an extended style sheet for the projection media that splits each slide into a separate page; and creating one more style sheet for print so that visitors (and you) can print out a nice, clean version of the presentation’s contents (of course, if you’re feeling really froggy, you could also create a mobile style sheet). Personally, I set mine up so that the “Notes” for each slide appear below each slide’s content when viewed in a normal window, and then have the notes hidden when viewed in Opera Show (along with some nice styling, obviously).

On a related note, don’t forget that the latest version of Opera supports almost as much of the CSS3 spec as Webkit, and that Opera supports SVG images; so you can do some really nice things with your slides.

Related posts:

1. Opera 10 Released
2. Applying CSS
3. Opera 9.5 Available

For the most part, the <article> element is supposed to denote a block of information that can stand on its own (essentially, the main content of the page or post). When developing a blog template. The spec currently describes the <article> element with the following verbiage:

The article element represents a self-contained composition in a document, page, application, or site and that is, in principle, independently distributable or reusable, e.g. in syndication.

In my mind, it seems like only the page content (or the article content) would qualify under most circumstances to stand on its own without the context of any other element on the page.

However, there is another application for the <article> element that might not be quite so obvious: comments. That’s right, comments and replies are supposed to be wrapped in their own <article> tags. Although I can’t envision too many comments or replies that would be able to stand on their own without the context of the surrounding content. However, that’s what the spec implies right now.

The one major difference, though, is that comments and replies are supposed to be <article> elements nested inside of a higher-level <article> element. Any time an <article> is nested inside of another <article>, the inner element will be considered to be a reply or comment on the outer element.

Therefore, when marking up the structure of a Web page — especially a blog article — you would most likely use nested <article> elements. The outermost <article> element would wrap the entire content area (the title, the content of the post, plus all comments and meta information about the post). Then, each individual comment on the post would be wrapped inside of another <article> tag. If someone replies to a comment, that reply would occur inside of that comment’s <article> element, wrapped in its own <article> tag. The mark-up for a blog post with one comment and one reply to that comment, might look something like:

<article>
	<hgroup>
    	<h1>Title of Post</h1>
        <h2>Subtitle of post</h2>
    </hgroup>
    <p>This is some content for the post.</p>
    <section class="comments">
    	<h1>Discussion:</h1>
        <article>
        	<h1>Comment title</h1>
            <p>This is a comment on the article.</p>
            <article>
            	<h1>Re: Comment title</h1>
                <p>This is a reply to the comment above.</p>
            </article>
        </article>
    </section>
</article>

Related posts:

1. A Look Into HTML5 and CSS3
2. Some HTML5 “Features” You Might Not Expect
3. Use HTML5 Elements in Today’s Browsers

But, what are these semantic elements? Are they really anything new? Will they change the structure of your document at all? The simple answer is “no”. The new elements, for the most part, just make your documents easier to parse and understand (for machines and for people using assistive technology). Very few of the new elements are really all that new; they’re just the same old elements with new names for new purposes.

Let’s take a look at some of the new elements. To start, we have the following:

• header
• footer
• aside
• section
• article
• nav
• hgroup
• output*

Basically, each of the elements mentioned above is nothing more than a specialized <div> tag (or possibly a <span> tag, though, I believe these are all block elements by default). With the exception of the <output> tag, they don’t really serve any different purpose, nor do they have any different attributes than a normal div. However, they will be invaluable in providing semantic data for the document.

The <output> tag is a little different, in that it actually does have some new attributes, and has a very specific purpose. It is basically the equivalent of the empty <div> many application developers used to act as a container for information returned from an AJAX request; but, when used properly, it may actually return information in HTML5 documents without any server interaction (calculations between two inputs, etc.).

Next, we have another list of elements:

• details and summary
• figure and figcaption

Essentially, these two pairs of tags are nothing more than fancy fieldset and legend tags. However, as far as I know, browsers will not render them quite the same way fieldsets and legends have been traditionally rendered.

The details and summary tags help express some information about the website or document currently being viewed (copyright information, etc.). You must use the summary tag as the first child of the details element; otherwise your document will not validate properly.

The figure and figcaption tags do not have the same restrictions. The figcaption element can be used anywhere within the figure element; but the concept remains the same. The figcaption is intended to act as a “legend” for the figure container.

So, then, what is truly different about HTML5?

To begin with, we do have a few new elements that are very different from anything we’ve seen in previous iterations of HTML.

• audio, video and source
• canvas
• ruby, rp and rt (for East Asian characters)

HTML5 also includes some additional tags that are meant specifically for semantic purposes and, by default, do not make any difference in the appearance of the document. These are similar to the classic <b>, <i>, <strong>, <em>, <del>, etc. tags, but offer even more detailed information about the text. Many of them actually have their own attributes that help machines determine exactly what the text infers. Some of these are:

• mark
• time
• meter

Document Outlines

In addition, the outlines of HTML5 documents will eventually be interpreted differently than previous versions of HTML documents. Rather than attempting to imply an outline based on the levels of headings within the document (something marked with an <h1> at the top is a top-level item, an <h2> marks the beginning of a second-level item, etc.).

However, HTML5 documents are expected to have more explicit outline definitions. The <section> and <article> tags are intended to separate the items within the outline. In fact, every new block level element (<header>, <section>, <article>, <footer>, etc.) is supposed to start with an <h1> heading. If a <section> or <article> is nested within another <section> or <article>, the outer element will be considered a top-level item in the outline, while the inner item will be a second-level item in the outline.

If you plan to use any headings that should be left out of the outline (subtitles, for example), you should use the <hgroup> tag to bind them together. So, if you have an article with the title of “What is HTML5?” and a subtitle of “A short guide to the new HTML5 elements“, you would use the following code to keep the subtitle from showing up as the second level of the outline:

<hgroup>
<h1>What is HTML5?</h1>
<h2>A short guide to the new HTML5 elements</h2>
</hgroup>

Further Reading

If you are interested in reading more about HTML5, you can check out the current list of elements allowed in HTML5 over at the W3C (though, please keep in mind that the list is somewhat in flux, and is actually being discussed in two completely separate working groups).

If you’re interested in actually learning how to use the new elements, you can take the SitePoint “HTML5 Live” course with John Allsopp. Be aware that this course is not intended for complete beginners. The course expects that students already have a good HTML foundation, and really only explores how the new elements differ from existing HTML elements. Also (at least, when I took the course – as part of the first group to take the course), it was put together as a live course; so John does make some mistakes and misstatements throughout. If you’re expecting a perfectly edited, top-of-the-line, professional course, you should look for local training in your area. However, for less than $10, I don’t see any reason not to at least try the course. I thoroughly enjoyed it, and got a lot of fantastic information out of it.

Related posts:

1. Use HTML5 Elements in Today’s Browsers
2. Captions in HTML5
3. Firefox and HTML5

Essentially, the <figure> and <figcaption> tags work together in almost exactly the same way the <fieldset> and <legend> tags work together. However, the <figure> and <figcaption> tags do not have any default styles applied to them (<fieldset> generally has a default inset border around it, and <legend> normally has a negative top margin applied).

The <figcaption> tag is a block-level element, and is treated as such in IE9, Firefox 4 and all recent versions of Chrome and Safari. Because it is an HTML5 element, it is not supported (without a JavaScript work-around like the HTML5 Shiv) in Internet Explorer 8 or earlier. Also, in Firefox 3.x, the <figcaption> element is treated as an inline element rather than block.

You can read more about the <figure> and <figcaption> elements and see some examples on HTML Doctor’s website.

Related posts:

1. What Is HTML5?
2. Use HTML5 Elements in Today’s Browsers
3. Firefox and HTML5

Here’s an overview of what the instructor notes you will learn during the course:

• Discover what’s new in HTML5, CSS3, and JavaScript for mobile development
• Build your own Twitter App with these technologies
• Create apps that detect the orientation of mobile devices
• Use geolocation and maps in a location-based app
• Enable mobile users to use your app offline
• Use HTML5 web forms to create an address book app
• Create drawings and animation with JavaScript and HTML5′s canvas element
• Use HTML5′s audio and video elements to build a movie trailer app

You should have some basic knowledge of CSS and HTML for the course. They also recommend that you are on a Mac but you can participate if you use a PC or Linux.

Related posts:

1. Use HTML5 Elements in Today’s Browsers
2. Captions in HTML5
3. Nokia Offers Free User Experience Evaluation for Mobile Apps

In order to create an icon for use on those devices, you should start with a 114×114 canvas. Apparently the iPod Touch and older iPhones use an icon size around 57×57, the iPad uses a slightly larger resolution and the new iPhone 4 devices use 114×114. Using the 114×114 resolution allows the icon to look great on iPhone 4 devices, and has little impact on the quality of the icon on older devices.

Then, add the icon and save it as a PNG file. By default, any transparent areas within the PNG will be black when displayed on the iDevice screen (since I don’t have a device capable of utilizing custom wallpapers, I can’t explicitly say whether the transparent areas are actually transparent of if they are just black). If you don’t want the background of your icon to be black, you will need to fill it with a solid color.

Also, by default, the iDevices will add the glossy, 3D effect overlaid on the icon. I know it’s possible to override that in some way, but I don’t know how. If you have some insight into this, please share it in the comments.

Finally, when you’re ready to implement the icon, save it as a PNG, upload it to your Web server and add the following code to the head of your Web pages:

<link rel="apple-touch-icon" href="/path/to/icon.png" />

Once you’ve added that code, you can open your website on your iDevice and use the bookmark menu to add it to your home screen. Then, on your home screen, you’ll see the new icon you created.

Related posts:

1. Creating a Favicon for Your Website
2. Surfing The Web On Mobile Devices
3. Web Development for the iPhone

All you need to do is add an extra “boolean attribute” to the element, and you can then style them with CSS in almost all of the browsers currently being used.

Instead of simply using something like:

<header>This is my HTML5 header</header>

<section>This is an HTML5 section</section>

and then trying to style them with something like:

section { display: block; }

header { display: block; }

You would, instead, use code like:

<header header="true">This is my HTML5 header</header>

<section section="true">This is my HTML5 section</section>

and the following CSS:

[header] { display: block; }

[section] { display: block; }

I honestly don’t know why it works, but I have tested it in IE7, IE8, Chrome and Firefox, and all four browsers seemed to handle this code without any trouble.

Oddly, though, when I tried to do the same thing with the new HTML5 <footer> element, it didn’t seem to work. It’s entirely possible that I had a typo in my code or something (let me know if you try it and get it to work), but I couldn’t figure out what the issue was.

Related posts:

1. What Is HTML5?
2. Firefox and HTML5
3. Captions in HTML5

1. You can link to the video on YouTube and specify the minute and second at which you want the video to start playing.
2. You can embed the video and specify the second at which you would like the video to start playing.

Linking to YouTube

To link to the video on YouTube and specify a starting point, you need to add a URL hash at the end of the link with the minutes and seconds specified. The link might look something like:

http://www.youtube.com/watch?v=EWhalXA7z2I#t=02m55s

The link above will lead to the 2:55 mark in that particular video. All you need to do is add “#t=” to the end of the URL, then specify the minutes in two digits, followed by the letter “m” (for minutes), followed by the seconds (two digits), followed by the letter “s” (for seconds).

Unfortunately, at this time, this feature seems to be a little spotty and unreliable, especially when trying to watch the video with YouTube’s HTML5 player. However, it can be a pretty handy little tip for the right situations.

You can try it out in your own browser and see if it works for you.

Starting an Embedded Video at a Specific Point

To embed a video and have it start playing at a specific point in the video, you need to take a slightly different approach, but it’s still just as simple. Instead of using the URL hash with minutes and seconds specified, you will simply add a “start” parameter to the end of the embed URL and provide the starting point in seconds. Therefore, if I were to embed the video shown above, I would use code similar to the following:

<object width="640" height="385">
<param name="movie" value="http://www.youtube.com/v/EWhalXA7z2I&hl=en_US&fs=1&start=175"></param>
<param name="allowFullScreen" value="true"></param>
<param name="allowscriptaccess" value="always"></param>
<embed src="http://www.youtube.com/v/EWhalXA7z2I&hl=en_US&fs=1&start=175" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed>
</object>

Notice the &start=175 at the end of the param name="movie" URL and the end of the embed source URL. That tells YouTube to start playing the video at the 175 second mark (which is 2 minutes and 55 seconds for those with poor math skills).

The embedded video should then act something like the following video (if WordPress doesn’t butcher my embed code):

Credits

I found these two tips in the following locations. Thanks to those authors for providing this information.

• Link to a specific part of a YouTube video – Matt Cutts’ Blog
• YouTube Allows You to Start Playing Embed Video at Specific Start Time – My Digital Life

As you can see from the date stamps on both blog entries, neither of these are new YouTube features, but I suspect they will still be new to many of us users.

Related posts:

1. Free YouTube to iPod Converter
2. Embed YouTube Videos With Valid Code
3. My endless eBay love