Latest Entries »

New Culture of HTML5

Is XHTML dead? In July 2009, the XHTML2 working group announced it would be dropping the spec and closing the book on XHTML2. That’s XHTML with a 2. Not XHTML. XHTML is alive and well – it’s just not getting the overhaul that was intended with XHTML2.

If you’re a developer or designer who writes markup, then you’re possibly already using XHTML 1.0 or 1.1, strict, transitional or otherwise. I’d also be willing to bet that if you’re using it, you’re using it to make use of stricter validation rules: lowercase tags, double quoted attributes, self-closing tags (like <br />) and so on – right?

Equally, if you’re that type of designer or developer, you’re probably also not serving it as true XHTML. Quite simply because Internet Explorer doesn’t accept the application/ xhtml+xml mime type at all – which is a requirement for XHTML. T his is old news, though. The new news is that XHTML2 is dead. The idealist recommendation for the web didn’t make it. Possibly because of the lack of backward compatibility, possibly for lots of reasons – the web was hot with discussion on the loss of the spec; the why, who and “whoh!”.

However, there is hope. If you’re the type of person who likes the strict rules of markup design that runs everything carefully through a validator. then you’ll be over the moon to know two things:

1. HTML5 supports all the lowercase, self-closing tags, double quoted attributes – the works. And if you don’t like these things, it supports that too!

2. If you absolutely have to have XHTML in your bag of tricks, XHTML5 will satisfy your thirst.

XHTML5 is quite simply HTML5 + XML, ie all the normal rules of XHTML, like no document.write allowed. For it to be XHTML5, though, you must serve it as application/xml or application/ xhtml+xml (which isn’t currently supported in IE). So HTML5 with lovely XHTML-style markup is the way I’ll be going.

Before we dive into what’s in HTML5 and what we have to do to get it going, though, I want to address the future: 2022. Aside from it being the year Queen Elizabeth II will celebrate her Platinum Jubilee (assuming she’s still kicking around), it’s the date that’s been inappropriately linked with HTML5 in the minds of many in our community.

It’s wrong. In fact, HTML5 is ready to use today. So why the confusion?

In an interview by Tech Republic, Ian Hickson, the editor of the HTML5 working draft, was asked to give a timeline of the HTML5 recommendation. One date should have come out of that interview, but another, much further away did instead: 2022 – the date of the final proposed recommendation, which actually translates to: require at least two browsers to completely pass HTML5 test suites.

Let’s put this in context of another spec that’s taken a very long time: CSS2.1.

CSS2.1 is CSS that I’m certain you’re familiar with. I’m certain you use it day to day, without any thought as to whether it’s a completed spec. Well, it’s been in development for over 10 years, and it has only just become a candidate recommendation (23 April 2009).

Even then, it still doesn’t have two browsers completely supporting it. Only Internet Explorer 8 supports the full CSS2.1 spec.

Did that stop you from using CSS2.1? I suspect not. Will that stop us from using HTML5? It certainly shouldn’t. HTML5 is available and ready to use today.

In fact, the really important HTML5 date is October 2009. This is the last call for the HTML5 working draft. That means that issues with the spec, enhancements, bugs, anything – it all needs to be in and submitted and written into the spec for October (although it can go through reiterations, this is the main deadline).

The Web Hypertext Application Technology Working Group (WHATWG) is completely open for anyone to contribute their ideas and suggestions. You can sign up to the mailing lists. You can communicate directly using IRC. And there’s even a complete log of all the IRC history. It’s all available from
HTML5 in five seconds

So how do you get your markup to validate as HTML5? It’s super easy: you change your DOCTYPE from whatever it is now to this:
<!DOCTYPE html>
That’s it. It doesn’t require anything more than that. Google is doing it already. Check out its homepage, written all in one line:
<!DOCTYPE html><head><title>HTML5 – Google Search</title><script>…
Ironically, Google’s search page and listings don’t validate because of their use of invalid tags – font element for instance – and a number of other errors. But that doesn’t matter, because they can take advantage of the HTML5 parsing rules with that doctype (for example: no type attribute on the script element).

Although that’s all you need for HTML5 to be triggered, there’s a lot more to HTML5 for you to play with. If you want something a little fuller, here’s a typical boilerplate for HTML5, which includes the IE shiv (which I’ll discuss later) and default HTML5 block styles:
<!DOCTYPE html>
<meta charset=utf-8 />
<title>HTML5 complete</title>
<!–[if IE]>
<script src=””></script>
article, aside, figure, footer, header, hgroup, menu, nav, section { display: block; }
<p>Hello World</p>
A note about the style and script elements in HTML5: these both no longer need the type attribute as they default to text/css and text/javascript respectively, which just helps to remove a little more cruft from our markup.
More markup

Way back when we were laying pages out using the table element, we probably weren’t aware of semantics and standards. Nowadays, we’re using divs left right and centre. The situation isn’t terrible, because most of us are using semantic classes and ID naming conventions to describe what the function of the div is. Wouldn’t it just be better if we had a header and footer element instead? HTML5 gives us exactly that.

One of the biggest assets to us authors of HTML5 is the new semantic markup. There’s an arsenal of new elements that has been added to HTML5, and because of the ‘pave the cowpaths’ approach, these can be used by the browsers today (although some might need a little bit of prodding from JavaScript).

Here’s a non-exclusive list of the new HTML5 elements that are available:
1) Block structure

article represents a component of a page that consists of a self-contained composition in a document, page, application, or site and that is intended to be independently distributable or reusable. This could be a forum post, blog post, newspaper article, a user comment, or any other independent item of content.

  • aside is used to represent a section of content that is related to the content around the aside element, eg a pull quote or a sidebar.
  • footer is the footer to a section. This is not restricted to one use at the bottom of the page. You can also use the footer to mark up the footer of a blog post in addition to the footer of the entire document.
  • header represents a group of navigational aids, and is used to construct the document outline. You are also not restricted to using header only once; you could use this to mark up the author’s name and the time of a comment placed on a blog post, for example.
  • nav is used to wrap major navigation blocks, such as table of contents, pagination links and breadcrumbs. Note that the nav element should be used for links that navigate around site, i.e. inappropriate for a list of sponsor links.
  • section is a generic document or application section. However, this isn’t a replacement for the div element. A section is only appropriate if the element’s contents would be listed explicitly in the document’s outline.

2) Inline semantics

  • details is used to include additional info that the user can obtain on demand. An open attribute on the element determines whether its contents can be seen, and it can be toggled by the user or by JavaScript.
  • figure is used to annotate illustrations, photos, listings etc that, if moved away from the primary content, would not affect the flow of the document.
  • mark highlights a run of text, eg to mark the terms the user was searching for.
  • time is intended to encode modern dates and times in a machine-readable way. The datetime attribute on this element gives the machine readable time, whereas the contents is human readable.

3) Interactive elements

The following elements include DOM interface methods that allow them to function correctly. So if the browser hasn’t implemented these elements specifically, they won’t work.

However, they all support fallbacks using nested elements within the tag to degrade down to a working solution.

  • audio and video are both types of media elements. They enable you to embed audio and video directly into the browser without any need for plug-ins. However, where support is lacking in the browser, best practice suggests that you should fall back to Flash plug-ins. You can either let the browser render the chrome for the element, or take control via JavaScript to create a bespoke interface.
  • source is a child element to audio and video. It enables you to specify multiple alternative sources for the media element. For example, Firefox doesn’t support the WAV audio format, so you can specify an alternative source in Ogg Theora format.
  • canvas is a 2D drawing element that can be accessed using JavaScript to render graphics on the fly – for example, for games, graphs or animations.

4) Compatibility

Where the new elements aren’t relying on a new DOM interface to be available to the browser, the element is available to you right now. The media elements audio and video have a new DOM interface, so only those browsers that have specifically implemented these media elements will be able to offer native audio or video.

However, this shouldn’t hold you back from using these elements. If you use the video element and it’s not supported in the browser, its contents will be rendered.

For example, for my video element, I’ll first provide an Ogg Theroa-encoded video, then QuickTime, then finally degrade down to Flash if the video element isn’t supported:
<video height=”640” width=”360”>
<source src=”example.ogg” type=”video/ogg” />
<source src=”” type=”video/quicktime” />
<!– otherwise let the user see flash –>
<object height=”640” width=”360” …>
<param value=”…”></param>
However, there are a couple of browsers that do have trouble seeing the new elements natively. In particular, all versions of Internet Explorer can’t see the elements by default, and as such they can’t be styled without the help of a bit of JavaScript.

Firefox 2 and Camino 1 have a bug in the Gecko rendering engine that causes the DOM to render incorrectly. However, Firefox 2 had its A-grade support dropped last year, and Firefox has a very solid upgrade path (hence why they’ve been dropped from A-grade support in the first place).

Camino has version 2 in beta, but it hasn’t been released just yet (and arguably, it’s not an A-grade browser). However, there are a few ways to fix Firefox 2 and Camino 1 and you can read about them here.
Fixing Internet Explorer

So, Internet Explorer is problematic. What’s new, right? The fix is actually incredibly simple, and if you’re using any of the new DOM APIs or HTML5 JavaScript APIs, the requirement for JavaScript is justified.

Sjoerd Visscher first posted about this solution whereby Internet Explorer is able to style any element so long as you run the following code:
Now myelement can be styled using CSS in Internet Explorer.

We also have an HTML5 shiv to enable all the HTML5 elements for Internet Explorer.

So long as this script is included in the head element, then you’ll be able to style the document correctly:
<!–[if IE]>
<script src=””></script>
If JavaScript isn’t enabled, the document will be displayed as if CSS hadn’t been applied to the document, which (given that we’re used to writing semantic standards-based markup) means all the content is accessible and readable regardless.
Default HTML5 styles

As with any browser, all the default styles for all elements are part of the browser. Since the browsers don’t really know about these new elements by default, we need to give the block elements their initial default styles. This is fixed by including the following CSS in your style sheet:
header, nav, section, article,
figure, aside, footer {
display: block;
But wait: it’s more than just markup. HTML5 is much, much more than just markup changes.

There’s also the Web Forms 2.0 spec in HTML5 which means we don’t have to use JavaScript to do the basic form validation that we’ve all repeated time and time again. You’ve also seen how the audio and video elements can be interactive. They expose a DOM interface that JavaScript can interact with. Included in the HTML5 spec is a host of JavaScript APIs, along with a bunch of JavaScript APIs that used to be in the spec and have since been moved out to their own specs.

New HTML5 JavaScript APIs include:

  • Drag and Drop – native JavaScript dragging, which also works across browser windows. Currently available in IE8, Firefox 3.5 and Safari 4.
  • Inline editing – enabling the user to edit content visibly on the page without an editor; the changes can then be used as the input to a CMS.
  • History API – to support Ajax-based applications and saving states in the history to move back and forth between.
  • Cross-domain messaging – allowing messages to be communicated across different domains. This is available in IE8, Firefox 3.5, Safari 4 and Opera 10.
  • Offline applications – enabling users to continue to use your web application even without a web connection. Available in Safari 4 (and iPhone Safari) and Firefox 3.5.

The specs are changing all the time, leading up to the last call (in October 2009). Some of the other interesting JavaScript APIs include:

  • Local storage – two types of storage, key/ value pair and SQL based to store data associated with your application.
  • Web workers – basically threading for JavaScript.
  • Geolocation – an API to retrieve the latitude and longitude.
  • New selector API – document.querySelectorAll uses CSS syntax to find elements in the DOM.
  • Web sockets – for TCP/IP type socket communication.

HTML5 is here to stay. The semantic elements are ready to be used today, and a decent amount of the JavaScript APIs are available in the latest browsers to be played with and integrated into your cutting edge applications.

Now start playing !!!

The difference between a good web designer and a great one is the ability to know how to take short cuts and save time without compromising the quality of work. Here are 20 top tips and tricks you should be using to give your work that all-important professional edge

1. Planning

When you’re itching to get started, it’s easy to overlook the most obvious step: planning. Whether it’s drawing wireframes and site diagrams in OmniGraffle or Visio, or even on a scrap of paper, you’ll save time by having an overview of your design at the site and page level before you start building. Obvious errors can be detected and solved before it’s too late to go back and it makes explaining your ideas to clients and colleagues a lot simpler than waving your hands in the air.

2. Do it by hand

Although there are some excellent tools around for building web sites, such as Adobe GoLive and Adobe (formerly Macromedia) Dreamweaver, professional code monkeys prefer to code by hand. Are they crazy masochists? Quite possibly.

There’s only one way to learn HTML, and that’s to roll up your sleeves and get your hands dirty with some actual code. But fear not: HTML has one of the easiest learning curves you’ll ever come across and you can create a basic web page with only a couple of lines. Writing code by hand also ensures that you write the leanest code possible, which is the ultimate aim of all HTML geeks.

Don’t throw out that copy of GoLive or Dreamweaver just yet. Both applications have excellent code writing environments, and have useful features, such as collapsable blocks of code and split views so you can code and see the results at the same time. If you want to try the code-only route, then any text editor that can save in the basic .txt format should do, but Mac users might want to check out Bare Bones Software’s BBEdit, and Windows users should give the freeware AceHTML editor from Visicome Media a whirl.

3. Stylesheets: importing vs linking

There are two ways to attach an external stylesheet to your HTML page, and not all browsers understand both methods. This can be used to your advantage to feed one stylesheet to modern browsers and another to Netscape 4.x, which would otherwise choke on more complex CSS.

Cascading stylesheets are designed to flow over each other. The secret is to create a simple stylesheet that works in Netscape 4, with more complex CSS relegated to an additional stylesheet that’s attached using @import, which Netscape 4.x will ignore:

<link rel=”stylesheet” href=”simple. css” type=”text/css” media=”screen”>
<style type=”text/css” media=”screen”> @import url(simple.css); </style>

4. Smarter gradient backgrounds

CSS gives you a lot of control and flexibility over the tiling of background images. And the great thing is that tiled images are not limited to the Body background but can also be applied to any DIV, block level or inline element.

Images that tile conventionally or just along the x or y axis can be set to scroll with the page or remain fixed while the rest of the page scrolls over it. Backgrounds can also be offset. This means that it’s easy to create a vertically graduated background that never repeats no matter how long the page is, using graphics that are only a few kilobytes in size.

Using the following code, the background.png file need only be as tall as the gradient and one pixel wide. This example assumes that the gradient fades into white, but the backgroundcolor attribute could be any value.

body { background-color: white; background-image: url(background.png); background-repeat: repeat-x; }

5. Commenting

When you come back to a site that you designed months ago, there’s nothing worse than trying to figure out what you did and attempting to untangle a spaghetti of code. Do yourself (and anyone else who wants to check out your code) a favour by putting comments in your HTML. Comments might add anything from a few bytes to a kilobyte or two to your page, but the time savings are invaluable.

Commenting also encourages you to keep your code tidy by breaking it into logical chunks. Some coders even use comments to create a table of contents for the page, which is only visible in code view.

Be aware that HTML and CSS use two different kinds of commenting, so you may want to learn the difference.

<!– HTML commenting looks like this and is enclosed within angle brackets and two dashes. The opening tag includes an exclamation mark. –> /* CSS comments are enclosed by a forward slash and an asterisk. */

6. Use simple PHP to build sites

There’s no need to become a PHP expert to start using it in your site. If your server supports PHP, you can quickly and easily use server side includes to build a library of commonly used elements, inserting them into your web page with a simple link. This is great for elements like menus, which can exist as a single instance, and means that if you add a new menu item or change the design, you just need to change the include file, which will then update the whole site.

Includes are simply snippets of HTML code such as a table or unordered list. The page calling the includes should end .php and the includes are inserted using the following simple code:

<?php include(“filename.html”); ?>

7. Set fonts using ems

Designers love specifying type sizes in pixels because it corresponds easily and naturally with what they do in Photoshop. But as a type size specification for the web, pixels have one major disadvantage: they can’t be resized in Internet Explorer. As monitor resolutions increase, it’s not only the visually impaired who may want to increase the font size in your design, so what’s the solution?

The answer is to specify type in ems. If you’re unfamiliar with the unit, an em is roughly the width of a lowercase em in a font, and using a browser’s default internal stylesheet, an em is roughly equivalent to 16 pixels. Set the font size attribute in the body tag to 62.5 per cent like this:

body { font-size: 62.5% }

This makes one em roughly ten pixels (16 x 62.5% = 10). Now you can equate pixel sizes to ems. For example, type that is set in 12 pixels could be expressed as 1.2em; 9 pixels becomes 0.9em and so on. What’s more, both the designer and user are happy.

8. IE Box Model Hack

Sooner or later you’ll come across an important bug in Internet Explorer that incorrectly calculates the width and height of block level items by including padding values within the box’s dimensions, rather than adding it outside the box. This can wreck layouts. The solution is known as the Box Model Hack, which uses another bug in IE to force it to use tags that other browsers ignore. If you have a div validly specified like this:

div {_ width: 100px;_ padding: 5px;_ border: 5px solid #fff;_ }

You’ll end up with a box that’s 120 pixels wide in most browsers, but only 100 pixels wide in IE. The easiest solutions is the box-within-a-box method, which places one div inside another:

div {_ width: 100px;_ }
div .hack {_ padding: 5px;_ border: 5px solid #fff;_ }

This is applied in the following way:
<div class=”hack”>
Your content goes here

9. Space saver

Nobody likes building forms in HTML, especially as browsers insist on adding padding around them for no reason. Simply add the following CSS to your stylesheet:

<form style=”margin-top: 0; margin-bottom: 0;”>

10. Test, test and test again

While Internet Explorer still dominates the browser market by a huge percentage, its lead is being gradually eroded by other browsers such as Firefox and Opera. There are also plenty of people out there still using archaic browsers like pre-Mozilla versions of Netscape.

It’s virtually impossible to design great-looking web sites that work in all browser versions, so it’s best to decide which browsers you’ll support. Mozilla-based browsers, WebKit-based browsers (such as Apple’s Safari), KHTML-based browsers (such as Konqueror), Opera and Internet Explorer versions four and higher are generally considered a safe benchmark. However, you should still be a good net citizen by ensuring that your code degrades gracefully, so that even unsupported browsers can experience your site – even in a limited form (see tip 14).

11. Format fundamentals

In the old days it used to be simple. If the image contained flat colours like a logo, use a GIF. If it was photographic, use a JPEG. There’s also an overlooked third format, PNG (pronounced ‘ping’) that comes in two flavours: an 8-bit version containing 256 colours, like GIFs, and a 24-bit version with alpha channel support allowing for variable transparency.

The bad news is that Internet Explorer doesn’t support PNG’s alpha channels without resorting to a complex hack. However, 8-bit PNGs generally compress much smaller than the equivalent GIF version. Unless you need animation, which PNGs can’t do, PNGs can replace GIFs in most situations, resulting in an overall file size saving.

JPEGs usually create smaller files than 24-bit PNGs, so unless you’re taking advantage of PNG’s alpha channel transparency using the hack (, then JPEGs are still the best format for continuous tone images.

12. The ‘title’ and ‘alt’ attributes

Ensure that all your images make use of the alt and title tags so that screen readers for the visually impaired can correctly parse your page:

<img src=”logo.gif” alt=”logo” title=”logo/” />

13. The correct format for pseudo classes

For text rollover effects, it’s important that the pseudo classes are in the right order, or they won’t work correctly in all browsers. The correct order is:

a:link { color: blue; }
a:visited { color: purple; }
a:hover { color: purple; }
a:active { color: red; }

14. Use semantic mark-up

The idea behind semantic mark-up is to separate the content of your web site from its appearance so that it degrades gracefully. Ideally, if you were to remove the stylesheets, your web site should still work. It might not look pretty, but it means that users with older browsers, will still be able to get meaningful content from your site.

The positioning, styling and a certain amount of interactivity can then be added with stylesheets and CSS-P.

15. Favicons

Favicons are the little 16×16 pixel icons that appear in your favourites lists and the title bars of web sites. They’re quick and easy to add: save a graphic in .ico format (Mac users may want to consider using Graphic Converter as Photoshop doesn’t support this format) and put it in your site’s root folder. It’s as simple as that.

16. Change capitalisation using CSS

If you need something written in capitals, such as a headline, rather than rewriting the copy, let CSS do the donkey work. The following code will transform all text with an h1 attribute into all capitals, regardless of format.

h1 { text-transform: uppercase; }

17. Wrapping text around images

For a quick and dirty way of wrapping text around images, use the image’s align attribute to push it to the left or right. Rather than jump below the image, text should now flow along the edge.

<img src=”image.jpg” align=”left”>

18. Universal character sets

Character sets are an important part of a web page’s definition, but they’re probably the least understood component. Character sets, which are defined in a web page’s invisible head section, tell the browser what method is being used to encode the characters. A charset ISO Latin 1 (also known as ISO 8859-1) will render the code it finds using a basic Western alphabet, but a charset of Shift JIS will attempt to render any characters it finds as Japanese.

With so many competing character sets, problems can occur, especially when using the MS Windows character set (which contains certain characters that may be replaced by a blank space on other operating systems) or when several languages need to appear on a single page.

The answer is to use a single universal character set that’s able to cover most eventualities. Luckily one exists: UTF-8, which is based on Unicode. Unicode is an industry standard that’s designed to enable text and symbols from all languages to be consistently represented and manipulated by computers. UTF- 8 is rapidly becoming the charset definition of choice, and should be included in your web page’s head like this:

<meta http-equiv=”content-type” content=”text/ html;charset=utf-8” />

19. Print styles

When people print web pages, often they’re not interested in your flashy graphics: they just want a simplified version of the page. Using CSS it’s possible to create a separate stylesheet that only affects printed versions of your site, rather than having to create a new HTML page or adapt an existing one. You add a print stylesheet in exactly the same way that you would add a regular stylesheet to your page:

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


<style type=”text/css” media=”print”> @import url(print.css); </style>

This ensures that the CSS will only apply to printed output and not affect how the page looks on screen. With your new printed stylesheet you can ensure you have solid black text on a white background and remove extraneous features to maximise readability.

20. Learn from others

Finally, a quick and simple tip: learn from great sites built by others. Any site’s HTML is easily accessible by viewing a page’s source code. See how others have done things and apply their methods to your own work.