One of the main reasons why developers may not be making the move to HTML5 as yet is the perceived lack of support for legacy browsers. This is actually untrue, and whilst there might be some jiggery pokery required for proper backwards compatibility, it’s still possible.

Of course, by legacy browsers I mean Internet Explorer, as all the other major players update regularly and their users tend to follow suit: browsers such as Firefox, Safari and Opera have supported HTML5 for a while. Some developers may decide to stop supporting IE6, but for some that’s not an option and, at any rate, neither IE7 nor IE8 support HTML5 either. IE9 will, but it runs on Windows Vista and Windows 7 only, so the other versions will still be around for a long time to come, as we have seen with IE6.

So what needs to be done to get HTML5 working in Internet Explorer?

Unknown elements

Well first and foremost, IE won’t render any elements it doesn’t recognise, so it will completely ignore HTML5 structural elements such as header, footer, article, section, and nav, all major parts of a HTML5 site. This can be rectified by telling IE about these elements using JavaScript. The best way to do this is to include the HTML5 shiv script, created by Remy Sharp. This handy script creates all the relevant HTML5 elements which IE will now know about when rendering the page.

One problem with this is that it won’t work for users who have JavaScript turned off. Unfortunately there is no way around this, so a decision has to be made by the developer to either use HTML5 or stay with HTML 4.01.

Styling

Most browsers have internal stylesheets that, amongst other things, apply display:block to block level elements. Whilst some of the newer browsers now do this for the relevant HTML5 elements, some don’t, and this needs to be added for all browsers. Simply adding the following styling will do the trick:

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

Form elements

And what about some of the new elements themselves, such as the new input types - how do these render on legacy browsers?

Fine actually. Since the HTML5 spec was extended in a backwards-compatible way, any input types that aren’t recognised, are simply treated as text and will simple be rendered as so.

Multimedia

As I’ve discussed in the past, the video and audio elements are designed to allow a fall back to Flash, which will work fine on Internet Explorer.

The move to HTML5 will still be a gradual one, and some won’t see nor have the need to use any of the new functionality that it provides, but when they do, they can be (relatively) safe in the knowledge that older browsers will render their sites just fine.

Yesterday the W3C decided to release a logo for HTML5. Nothing wrong with that you might say, and I would agree with you. They have created a badge builder which allows you to specify which specific parts of HTML5 your website uses and enable users to see at a glance (provided they’re familiar with the icons of course) what you have used when building your site.

Great. Splendid.

The W3C has always provided icons in the past to place on your website to indicate validation for the various versions of HTML, XHTML, CSS and others. And although this particular logo doesn’t indicate validity, it is in fact an improvement on it.

But. There’s a problem.

The logo is a general-purpose visual identity for a broad set of open web technologies, including HTML5, CSS, SVG, WOFF, and others

Last year I wrote about the confusion surrounding HTML5 and one of the main points I attempted to drive home was that CSS3 was not part of HTML5. I’m not the only one to underline this, Bruce Lawson says as much, there’s even a website dedicated to it!

But, as I was saying, there’s a problem with this new HTML5 logo from the W3C. If you go to the badge builder, there’s a selection of tick boxes for you to show off what parts of HTML5 your site uses. And one of those options is CSS3/styling.

As I’ve said, CSS3 is not part of HTML5. But the W3C appears to be supporting the fact that it is, thus adding to the confusion and in my eyes bowing down to the marketing types who don’t understand such things. Developers do, and yet the W3C seems to be trying to convince the developers to also shove CSS3 under the HTML5 umbrella.

Sorry W3C, but this developer is not going down that route.

It gets even worse.

The FAQ itself describes the logo as:

a general-purpose visual identity for a broad set of open web technologies, including HTML5, CSS, SVG, WOFF, and others.

which lumps almost everything and anything under the HTML5 name. I despair.

Don’t get me wrong, I will use the HTML5 logo, it’s nice, it can be vertical or horizontal, you can download the images and make your own, with different colours etc, so it’s very flexible and aesthetically pleasing and will fit in with almost any design, should you choose to use it.

But sorry W3C. I’m putting my hands over my ears like a child and am simply not listening. CSS3 is not part of HTML5, and neither are SVG and WOFF for that matter.

One of the most popular features on websites today is a marker pinpointing a location on Google Maps. It’s incredibly easy to add such a map to a website and I’m going to show you how.

I said it was easy, and with the recent release of version 3 of the Google Maps JavaScript API, it’s become even easier. With the previous version of this API, you had to register your map to receive an API key, but that’s now no longer necessary.

Naturally Google provide a comprehensive guide to the Maps API, but I will run through the basics here.

Setting up the Map

First of all you need to include the map API in your web page. This is done by adding the following line in the <head> element of your code:

<script
type="text/javascript"
src="http://maps.google.com/maps/api/js?sensor=false">
</script>

You may notice the sensor parameter, which is set to false. This is a required parameter and should be set to “true” if the application used to determine the user’s location has a sensor device (e.g. a GPS locator). That’s not the case here, so we set it to false as shown.

Naturally, we need to define a map to display, but before we do that we need three things: somewhere on the web page to actually place the map, a default position to use as the map’s centre, and then some options to define the type of map that we require.

Setting up somewhere on the web page to place the map is a simple case of defining a div with a unique id, and some inline styling. So we have:

<div id="map" style="width:600px;
height:600px; margin-top:10px;"></div>

And that’s all we need.

To define a default position we need a latitude and longitude. There are plenty of websites out there that will convert addresses or places into coordinates for you, and I will centre this particular example on the PC Pro offices at latitude 51.515252 and longitude -0.189852. From these values a Google map position is defined by using the following:

var latlngPos = new google.maps.LatLng(51.515252, -0.189852);

We then set up the map options as follows:

var myOptions = {
   zoom: 10,
   center: latlngPos,
   mapTypeId: google.maps.MapTypeId.ROADMAP
};

Where zoom (naturally) indicates the zoom level of the map (you may want to play about with these to get the value that you want), center is set to the latitude/longitude position that we defined, and mapTypeId is set to the type of map that we wish to display initially. The map types are defined by the Google Maps API and are:

• MapTypeId.ROADMAP displays the default road map view
• MapTypeId.SATELLITE displays Google Earth satellite images
• MapTypeId.HYBRID displays a mixture of normal and satellite views
• MapTypeId.TERRAIN displays a physical map based on terrain information

Note: this simply defines the initial map type to display, the user can change it via a dropdown list that appears on the map itself. You can read more about the different map types over at Google should you want to know more.

With these things done, we can now initialise our map as follows:

var map = new google.maps.Map(document.getElementById("map"), myOptions);

This will now cause the map to appear on your web page, contained within the map div (the map itself stays within the boundaries of the div’s dimensions).

Marking the Location

With the map set up, we can now go about defining the marker on the map that we want displayed. Once again we need to define a position for the Google map using latitude and longitude. I’m using the same values as above, as I want to place a marker on the PC Pro offices (it’ll help the staff when they stumble back from their Christmas party).

var markerPos = new google.maps.LatLng(51.515252, -0.189852);

Adding a marker to this location is as simple as:

var marker = new google.maps.Marker({
   position: markerPos,
   map: map,
   title: "PC Pro Offices"
});

(where map is the id of the map div)

As usual I have a simple example so that you can see it in action. (Note: this example also uses some jQuery)

Going further

The Google Map API is very powerful and you can go much further than I have shown here, such as adding pop-up information windows on the map marker.

You can even use the API to convert addresses into latitude/longitude positions and display them on the map. I have included a more advanced example should you want to take a look at it. It’s pretty straightforward and I’ve commented the code in order to make it clearer.

Despite all the hype about HTML5, there are still many people (mainly web developers!) out there who are wondering whether or not they should use it in their next site. The main issues seem to be browser compatibility and the myth that HTML5 won’t be ready for mainstream usage until 2022.

To begin with, let’s bust this myth once and for all. For any specification to be deemed “ready”, it supposedly needs to be fully implemented in two browsers. If this rule was true, CSS2.1 also wouldn’t be “ready”, and do you hear people advising you to hold off on using that? No, and quite rightly so too. And the same should go for HTML5.

As for browser compatibility, the latest versions of browsers such as Firefox, Chrome, Safari and Opera all support various parts of the HTML5 specification, and older versions of these browsers support bits of the spec. The major headache, as always, is Internet Explorer. However, with the upcoming release of Internet Explorer 9, which will support HTML5 features, this is improving. That said, there will of course be many people who remain on older versions of IE and how will they cope with HTML5?

Pretty well, actually, and there are a lot of things you can do to ensure browser compatibility.

New elements

Whilst all of these browsers will happily accept the HTML5 doctype (<!DOCTYPE html>), Internet Explorer doesn’t understand any of the new elements and as such, will completely ignore them. This can be fixed using JavaScript. All you need to do is to add Remy Sharp’s html5shiv script to the head of your document, and IE versions 6 to 8 will know now what to do.

Some of the newer HTML5 elements – for example, input types such as email and url  - default to type text if the browser doesn’t understand them. So there’s no harm using them in your web page as a browser that takes advantage of them will do something funky, whereas a browser that doesn’t understand them will simply treat it as a normal text input field. Similarily input type attributes such as autofocus will simply be ignored by browsers that don’t know what to do with them.

Styling

Now that all browsers understand the elements, how will they look? There are no specific styles built into most of the browsers for these elements and thus they will all default to display:inline whereas some of them, e.g. section, article, head and footer need a default styling of display:block.

This is easily achieved by adding the following default CSS styles into your webpage:
article, aside, figure, footer, header, hgroup, menu, nav,
section { display:block; }

HTML5 Reset

Some developers like to use a CSS reset when starting a website from afresh, and this is usually a good idea as it allows all browsers to start with the same set of rules. There is a HTML5 reset available which you can use which will also automatically include the default styling above.

Modernizr

Modernizr by Paul Irish encompasses all this and also allows you to check browser compatibility for every HTML5 (and CSS3) feature on an individual basis. This can help with providing specific fallbacks for each HTML5 feature. It also adds some of the functionality mentioned above (creation of new elements for IE and default styling) automatically, so if you use Modernizr, you don’t have to add these separately.

Twitter , posterous and Burger King are just three major sites out there currently using Modernizr on their website to check for various HTML5 and CSS3 functionality.

No JavaScript?

Of course most of these are bypassed when a user has turned off JavaScript, especially when using IE. This is an issue, for sure, and is something that the developer will have to decide on themselves. As usual, the <noscript> element can be used to target these users, and different markup and content could be delivered that doesn’t make use of HTML5 elements and features.

Conclusion

There are a whole host of websites out there using HTML5 already and most of them work just fine. There are sites out there dedicated to showcasing websites using HTML5, such as HTML5 Gallery and 101 Best HTML5 Sites. They’re well worth taking a look at to see what others are doing.

Personally I think that there’s nothing to stop you from going out there and using HTML5 today in your websites. It works now and is only improving. So the answer to should you be using HTML5 today is a resounding yes!

Throughout your web browsing careers I’m sure you’ve come across the notion of cookies, pieces of text stored by the browser to be retrieved and used at a later date. These vary from simply remembering your name to welcome you personally next time you visit, to more complicated storage of authentication and shopping-cart contents.

Cookies generally work well but can be fiddly to implement, as they are set to be deleted by default once the browser is closed. If a website owner needs the data to be stored for a longer period, a cookie can be given an expiry date. Again this isn’t as clean as it could be: how far into the future do you set the date, for example? And what happens when a user flushes out their cookies?

HTML5 attempts to clean this up with the introduction of web storage.

Web Storage

Web storage comes in two different types, sessionStorage and localStorage. As might be deduced from the names, sessionStorage is for storing data that’s required for a particular session only, and localStorage is for data that’s to remain indefinitely.

Web storage correctly separates session data from long term data

This does away with the need for expiry dates, and instantly makes it clearer which data is for when and for how long. It also makes it incredibly easy to implement.

The API

As both types are so similiar, they share the same API, which contains the following items and functions:

// The number of items being stored
long length;

// To retrieve the item 'key' from storage
getItem(key);

// To set the item 'key' in storage with 'value'
setItem(key, value);

// To remove the item from storage
removeItem(key);

// To clear the entire storage
clear();

It’s all quite simple and straightforward to use.

Saying Hello

Let’s say you wanted to store a user’s name to welcome them back later. Assuming the existence of a simple HTML5 page consisting of one input field called name and a link that calls the function saveName() it would be defined as follows:

function saveName() {
   var name = document.getElementById('name').value;
   localStorage.setItem('username', name);
}

Each time this page loads, call a new function sayHello() which is defined as:

function sayHello() {
   var userName = localStorage.getItem('username');
   if (userName != null) alert("Hello " + userName + " and welcome back!");
}

This will check for the existence of a username in localStorage, and if it’s there, will welcome the user.

Note that localStorage is used here rather than sessionStorage as we want the name to be displayed next time the user visits the page again, during which time they may have closed the browser, which would clear anything in sessionStorage.

You can see this working for yourself in this very simple “say hello” example. Enter a name, click ’save’, and reload the page.

If you enter a different name in the input field and click ’save’, the existing value will be overwritten. We could also remove the item by calling localStorage.removeItem('name'); which would remove that item only. The entire localStorage could be cleared by calling localStorage.clear();

Session storage

sessionStorage works in the exact same way, except that the data will be automatically cleared once the brower is closed.

You can also store multiple data items in web storage attached to the one key, but you will need to use a JavaScript object and something such as JSON which helps to “stringify” the stored data, thus facilitating its storage.

Browser Support

If you’re used to reading about Internet Explorer’s current inability to support any HTML5 feature, you’re in for a surprise here. Web storage is actually supported by IE8 as well as all the major browsers:

• Firefox 3.5+
• Safari 4.0+
• Chrome 4.0+
• Opera 10.5+
• Internet Explorer 8.0+
• iPhone 2.0+
• Android 2.0+

So basically, you can start using it now!

If you or your company has a Twitter account, chances are you’d like to promote it and display your latest tweets from your website. Since many websites – both personal and increasingly business – are built on blogging software such as WordPress, this is usually achieved via a plugin, of which there are many out there.

But what if you simply want to add your live Twitter feed to a “normal” web page? Twitter itself provides a number of HTML widgets, but in this article I’ll show you how easy it is to achieve with a little bit of JavaScript, CSS, and jQuery.

In case you haven’t come across it before:

What is jQuery?

jQuery is a fast and concise JavaScript Library that simplifies HTML document traversing, event handling, animating, and Ajax interactions for rapid web development. It’s very powerful and makes life a whole lot easier when writing JavaScript. To include jQuery in your webpage, simply add the following within the <head> tags:

<script type="text/javascript" src="http://jqueryjs.google
code.com/files/jquery-1.3.2.min.js"></script>

This uses the version that is hosted on Google Code, which saves you having to download the file.

Twitter API

Twitter itself provides a complicated API to allow access to all sorts of things. A lot of this complication arises around authentication, and necessarily so, but thankfully to simply retrieve a stream of tweets, authentication isn’t required (as long as the user in question hasn’t hidden their tweets).

First of all the API provides many different ways to obtain a user’s statuses. I won’t go into any of them other than the one that I favour, and this is the one that I’ll talk about here: user_timeline.

user_timeline

This returns a number of the most recent statuses posted by the user. It can return the data in different formats: XML, JSON, RSS and Atom. I favour  JSON, a lightweight data-interchange format, so this is the one that I will talk about.

You can use a number of parameters, and a full list of what they can do can be found on the Twitter API description for user_timeline. For now, I will only use a few relevant ones.

Give me the Tweets!

To retrieve the data for a particular Twitter account (I will use pcpro in this example here) you call the following:

$.getJSON("http://twitter.com/statuses/user_timeline.json?
screen_name=pc_pro&count=10&callback=?",
function(tweetdata) {
// do some stuff here
});

This will return the last 10 tweets from the pc_pro account in JSON format in the tweetdata variable. By default, retweeted tweets are not included in this feed, but to include them, add the &include_rts=1 parameter above, and they will be returned.

Of course we now have to make sense of this data, parse it and actually do something with it.

On our HTML page, define a <ul> and give it the id tweet-list. This is where we will hold our tweets. The above code is then extended to do the following:

$.getJSON("http://twitter.com/statuses/user_timeline.json?screen_name=pc_pro&count=1O&callback=?", function(tweetdata) {
var tl = $("#tweet-list");
$.each(tweetdata, function(i,tweet) {
tl.append("<li>“" + tweet.text + "”– " + tweet.created_at + "</li>");
});
});

Some explanations: var tl = $("#tweet-list"); grabs a reference to the <ul> element that we created above. We need this as we will add each tweet to it.

$.each(tweetdata, function(i,tweet) {... is the start of a jQuery loop, in this case iterating through each item in tweetdata and storing it temporarily in tweet. The following line then adds the tweet within an <li> item. The actual text of the tweet is contained within the text data member, and here we put double quotes around it, and the time it was created is contained within the created_at data member.

This will now display the last 10 tweets in list format on the relevant HTML page.

However, if there are links contained in the tweet, they won’t be clickable, and the created date is a bit long and not like the Twitter standard timelines such as “about a minute ago” or “two hours ago”. We can fix this with the following two functions urlToLink(); which we call on tweet.text:

function urlToLink(text) {
var exp = /(\b(https?|ftp|file):\/\/[-A-Z0-9+&@#\/%?=~_|!:,.;]*[-A-Z0-9+&@#\/%=~_|])/ig;
return text.replace(exp,"<a href='$1'>$1</a>");
}

and relTime(); which we call on tweet.created_at:

function relTime(time_value) {
time_value = time_value.replace(/(\+[0-9]{4}\s)/ig,"");
var parsed_date = Date.parse(time_value);
var relative_to = (arguments.length > 1) ? arguments[1] : new Date();
var timeago = parseInt((relative_to.getTime() - parsed_date) / 1000);
if (timeago < 60) return 'less than a minute ago';
else if(timeago < 120) return 'about a minute ago';
else if(timeago < (45*60)) return (parseInt(timeago / 60)).toString() + ' minutes ago';
else if(timeago < (90*60)) return 'about an hour ago';
else if(timeago < (24*60*60)) return 'about ' + (parseInt(timeago / 3600)).toString() + ' hours ago';
else if(timeago < (48*60*60)) return '1 day ago';
else return (parseInt(timeago / 86400)).toString() + ' days ago';
}

So we need to change the above line to the following:

tl.append("<li>“" + urlToLink(tweet.text) + "”– " + relTime(tweet.created_at) + "</li>");

This will be called when the HTML page is loaded (or you can load it some other time, it’s up to you of course) and this is done using jQuery by inserting the code within:

$(document).ready(function() {
// code here
});

which basically calls the code when the entire DOM has been loaded.

End Result

I have put together an example using all the code above, so you can see all this together and working for yourself. Plus you can view the code to see how it’s done. It’s all commented too, probably overly so, in case you get stuck.

You can of course also style the list and its contents with CSS, but I’ll leave that as an exercise for the reader.

*Update*

One of the comments below asked about retrieving the latest statuses from a specific account’s list. I’ve created a quick example that retrieves and displays the latest updates from PC Pro’s ’staff’ Twitter list. You can of course view the source code.

The main difference is the URL in included in the &.getJSON() call which should be:

http://api.twitter.com/1/account-name/lists/list-name/statuses.json?callback=?

where account-name is the name of the account, in this case pc_pro, and list-name is the name of the list, in this case staff.

As with the video element, in the past the only method of embedding audio files into a web page was to use Flash or another third-party plugin. There simply was no other way. With the introduction of the audio element, this has changed.

Browsers and file types

There are currently three different audio file types that are supported, and (of course) the different browsers each support different formats. The table below illustrates this:

Code

So how do we actually go about adding an audio file to a web page? Well it’s quite simple really, especially if you’ve already used the video element.

Instead of using the <video> element we naturally use its brother, the <audio> element. Like the <video> element, we can use the src attribute to directly specify the audio file to play, but, as shown above, it’s more practical to use the <source> element to indicate a number of possible sources in order to cover all most browsers.

The <audio> element

The audio element takes the following attributes:

So you can easily add a WAV audio file to your website by using the following markup:

<audio src="audioFile.wav" autoplay controls></audio>

Of course, as mentioned above, this can limit your browser compatibility and it’s better to provide different audio sources using the <source> element.

The <source> element

The source element can take the following attributes:

Stacking the audio sources

Combining the <audio> and <source> elments together couldn’t be simpler, as the code below shows:

<audio controls autobuffer>
<source src="audioFile.ogg">
<source src="audioFile.mp3">
<source src="audioFile.wav">
Sorry, your browser does not support the audio element
</audio>

The code above should play the specified audio file in all of the browsers mentioned above (except for the current incarnations of Internet Explorer and Android – which will display the message indicating as much. This could be replaced with a Flash fallback of course).

Feel free to test this code for yourself.

Conclusion

So there it is in its simplest form, adding an audio file to a web page. Of course it depends on the browser the page is being viewed in, and, as usual, we’re still waiting for Internet Explorer to catch up (A beta version of IE9 is due out next month).  Nevertheless, it’s still worth using today. Just don’t set your files to autoplay!

But how do you actually go about using it? This article introduces my recommended list of HTML5 resource websites, where a large number of tutorials, experiments, information and examples on using the various bits and pieces of HTML5 can be found.

HTML5 Doctor is a collaboration featuring some of the top advocates of HTML5, notably Bruce Lawson, Remy Sharp, and Rick Clark.  On the site you’ll find articles relating to HTML5, its semantics, and most importantly, how to use it right now. In addition, they also invite users to ask questions which they answer at regular intervals.

Mark Pilgrim’s site (which will eventually appear as a book that can be pre-ordered here) “seeks to elaborate on a hand-picked Selection of features from the HTML5 specification and other fine standards.” Here you will find in-depth articles on varying parts of the HTML5 specification and explanations of their importance.

This site is an  infographic that helps to explain HTML5 in a nutshell. If you’re looking for a quick explanation of what HTML5 is all about, including browser compatibility and the most important additions to the specification, this is the place to go.

A quick pocket guide to the main HTML5 elements and how to use them. Written by Jeremy Keith (author of the recentlry released HTML5 for Web Designers), this is ideal as a quick reference guide on how and when to use new HTML5 elements such as <header>, <hgroup>, <article>, and <section>.

Released by Google, this site is a developer resource site devoted to HTML5 technologies. The site itself is split into four different sections: presentation – which contains an introduction to HTML5 slideshow; playground – which has examples of how to use HTML5 that you can try yourself; tutorials –  which contains links to other HTML5 tutorials; and finally, resources –  which naturally links to other HTML5-related sites.

Written and maintained by Remy Sharp (one of the HTML5 Doctors mentioned above), this site is rich with working demos and examples of HTML5 features. Want to see how websockets can be used for a simple chat client? Or how GeoLocation can find where you are? Or even how drag and drop works? This is the site for you.

And last but not least I include my own site which I use for simple HTML5 related experiments. On this site I aim to show, in as simple a manner as possible, how some of the new HTML5 elements and JavaScript APIs can be implemented right now.

See how others are using HTML5

There are also a number of HTML5 gallery sites out there than showcase some of the HTML5 sites that are out there right now. These are great for seeing how others are currently using HTML5 in the real world.

• HTML5 Gallery
• 101 Best HTML5 Sites
• HTML5 Sites
• HTML5 Websites

In my last blog entry I briefly mentioned CSS3 when talking about the confusion surrounding HTML5. In this post, I’m going to talk about one of the new features of CSS3 and one which will possibly be noticed most by the non-web developer.

Allow me to introduce @font-face.

What does @font-face do?

It allows a web developer to embed a font within a web page and display it to the user. So instead of the bog standard fonts that are normally found on websites, you can now see much fancier and prettier fonts.

A brief history

The @font-face CSS rule was first introduced in the CSS 2.0 specification and then removed in CSS 2.1, before being reintroduced in CSS 3.0. The fact that it existed in CSS 2.0 is important, because it means that even legacy browsers such as Internet Explorer 6 (the bane of many a web developer’s life) support it.

the @font-face rule was first introduced in the CSS 2.0 specification

Issues

As is usual with such things, there are some issues with regards to implementing @font-face. First of all, as is customary in the world of web development, different browsers support different formats. Why these guys can’t seem to agree on the same format for anything is a mystery to me. So this means that a font defined with @font-face needs to be made available in different formats to be usable by each of the major browsers.

Secondly, not all fonts can be used legally in this manner. As @font-face downloads the required font from the server (where the site is hosted) to the user’s personal machine, the font licence needs to allow this free distribution of fonts. Thankfully there are many font developers out there who are now beginning to release their fonts with the required licence.

Using @font-face

So how can you use @font-face to embed an attractive typeface in your website? The answer is very easily.

First of all you need to pick a font, and ensure that it has the required licence. The best place to go for a comprehensive list of such fonts is Font Squirrel. (Incidentally, the site also has a @font-face Kit Generator which allows you to upload fonts, and I highly recommend using it.)

For this demo I have chosen Hattori Hanzo from Font Squirrel and downloaded the font kit. The kit is a ZIP file that will contain a number of files, most of which are the fonts themselves in different formats, which are:

• EOT – the font format used by Microsoft and supported from IE 4+
• TTF – the outline font standard originally developed by Apple and supported by Firefox 3.5+, Opera 10+, Safari 3.1+ and Chrome 4.0.249.4+
• SVG – SVG uses XML to describe 2D graphics and here, font characters, for the iPad and iPhone
• WOFF – is a repackaged version of a TrueType or OpenType font in a compressed form and is supported by Firefox 3.6+, IE9 and Chrome 5+

As shown above, different browsers support different font formats, and the @font-face CSS rule will reflect this. Included with the @font-face kit will be a CSS file which will contain this rule. Let’s take a look at the one that comes with the Hattori Hanzo font. It contains two font rule declarations, one for HattoriHanzoLight and another for HattoriHanzoLightItalic. Both declarations are the same and simply reference different files, so I will only go through the first:

@font-face {
font-family: 'HattoriHanzoLight';
src: url('Hattori_Hanzo-webfont.eot');
src: local('?'), url('Hattori_Hanzo-webfont.woff')
format('woff'), url('Hattori_Hanzo-webfont.ttf')
format('truetype'),
url('Hattori_Hanzo-webfont.svg#webfontwDgCZ3F8')
format('svg');
font-weight: normal;
font-style: normal;
}

The first part of the @font-face declaration indicates the font-family, in this case HattoriHanzoLight. This will be the name that is used throughout the CSS file to indicate that this @font-face declaration is to be used.

Next is the EOT declaration. This needs to be the first src declaration otherwise Internet Explorer won’t find it and will break. As you can see, it simply points at the font file to use.

The third declaration local('?') tells the browser to check the local system for the font first. If the user has already installed it, then that one will be used. Otherwise the declarations that follow it will be downloaded in whatever format the browser understands.

All you need to do to apply this font to any normal CSS declaraion is to assign the appropriate name to the font-family attribute. For example:

p {
font-family: 'HattoriHanzoLight';
font-size: 16px;
font-weight: normal;
}

That’s it really. Quite simple. I have created a demo page for @font-face and Hattori Hanzo Light for you to see the font in action.

Conclusion

For many, @font-face won’t seem like a big deal. And the fact that the different font formats are rendered differently on the various browsers, with varying degrees of success, may dampen the effect that embedding fonts within a webpage may have. I, on the other hand, believe it to be a big step forward in allowing web developers and designers to produce better looking sites and interfaces that will benefit the end user.

There seems to be a lot of confusion lately with regards to what HTML5 actually is. Those in the web development community generally have a good idea of what it entails, if not the nitty-gritty, at least what it may contain. Not so outside of the web development world.

As generally tends to happen, external parties grab hold of these new phrases, half-heartedly look into what they mean, jumble them together and cause a wave of confusion. The latest wave is the lumping together of HTML5 and CSS3 into the general heading of HTML5.

This is misleading.

So what is HTML5 then?

HTML5 is basically an emerging standard that is intending to replace the current versions of HTML (4.01) and XHTML (1.1). It introduces new markup elements and attributes that can be used for describing the structure of a HTML document in a more defined way than is currently available. It also adds the embedding of video files and audio files into a web document.

HTML is the language for describing the structure of web pages

As well as new elements, there are new JavaScript APIs that allow such functionality as drag and drop, local file storage, web SQL, 2D drawing (via the <canvas> element) and file access.

And CSS3?

Like the current version of CSS (2.1), CSS3 allows you to define the presentation of web pages. CSS3 however, introduces a huge variety of new ways to present your designs. It also introduces the idea of “modules” such as box, lists, hyperlinks, background and text. Each module will provide styling control over a certain type of content.

CSS is the language for describing the presentation of web pages, including colors, layout, and fonts

It also introduces new effects such as rounded borders, gradients, and box shadows, all effects that currently require fancy JavaScript or hacky combinations of HTML and CSS in order to achieve them. These will now be available through simple CSS definitions. Of course there are plenty more, this is just one example of the kind of thing that will be available for use.

They’re not the same

See the difference there? HTML is for structure, CSS for presentaion. So in the same way that the current version of HTML (4.01 or XHTML 1.1) is used for structuring a web document, and the current version of CSS (2.1) is used for styling a web document, both HTML5 and CSS3 have the same roles. This hasn’t changed.

They are exclusive of one another. HTML 4.01 can be used with CSS3, HTML5 with CSS 2.1, HTML5 with CSS3, any combination (although the browser needs to support them).

So where has the confusion come from?

The biggest culprit in my eyes is Apple. When they released their HTML5 Demos, people very easily got the wrong end of the stick. This wasn’t done intentionally by Apple, but such is their worldwide appeal and influence, that many people’s first introduction to HTML5 was via Apple’s demos – that, out of seven demos, only two are HTML5 specific.

Don’t get me wrong, I like what Apple have done with these demos (other than forcing you to use Safari in order to view them), and all the demos are coded in HTML5 and use a variety of the new HTML5 elements. What annoys me is the the way they were presented to the public – under the name of HTML5 Showcase. Even the link is misleading. I’m all for promoting HTML5, but it needs to be done properly.

An example of the confusion that reigned (this was prior to the Apple HTML5 demo release) can be seen in The Guardian’s technology blog article A working web version of the solar system – in HTML5, not Flash. It’s been corrected now, thankfully, but it illustrates the confusion that existed then, and largely still exists now.

Conclusion

People need to be educated properly as to what any new emerging technologes actually are and what they are used for. Misleading the public will only lead to problems and misunderstandings as to what can do what and how, causing all sorts of issues between clients and web designers/developers who I’m sure are already dreading being asked: “This design is a bit bland. Can you add some HTML5?”