Recently the W3C branded a selection of their emerging standards as 'HTML5'. It didn't go down so well with some purists… probably because under the new 'HTML5' brand sit various technologies that aren't, well, HTML5.

While it's been argued that all they've done is jump on the bandwagon and officially back the term, I'd counter that, in doing so, they've taken 'HTML5' and made it the new 'Web2.0' – it's a term everyone can get excited about, a common language that allows developers, designers, planners and clients to embrace emerging web standards – they've made standards sexy.

So, why stop with HTML, SVG and CSS? Other standards could be re-branded and given the Web2.0 HTML5 treatment. A couple of (oversimplified) examples:

Multimodal Architecture and Interfaces

Multimodal Architecture and Interfaces helps define the 'right' in 'do it right the first time'. Wouldn't it be nice if your apps were available on your desktop, your phone, your tablet, your fridge or whatever comes next?

Navigation Timing

Navigation Timing is really quite niche in comparison; it deals with how you make your web-technology based applications feel super-slick.

Really Simple Syndication

That's right, RSS could be sexy again. It's most definitely not dying – although, traditional RSS Readers may be, which is what I suspect this post was getting at. RSS encapsulates standards that have freed us from the shackles of traditional web-based content consumption. If every piece of content on the web was served with a standardised XML feed alongside it, we wouldn't have to rely on proprietary APIs and scraping; the world would be a far more connected place.

Don't stop there

There are dozens more… please, someone go make them fashionable so I never again have to cringe when someone asks me which emerging web technologies I'm most enthused about – transience and me just don't get on, and I have no real desire feign excitement about the latest bullshit web service to come out of Silicon Valley.

Generally I shy away from posting things on the Internet that I feel are already out there; obvious; or widely adopted by the community, but it would seem some of us are yet to notice the huge number of gorgeous fonts that have become available for use on our sites, negating the need for hacks such as sIFR or Cufón.

@font-face has been around for a while (oddly enough, thanks to the Internet Explorer team) but it wasn't until fairly recently–when some clever people worked with the foundries to figure out a way of licensing these fonts–that the majority of browser vendors started to support it, and hosting services sprang up from the fertile Interweb soil.

There is a huge amount of information available on the subject - I'll just point you in the right direction…

So, how does this all work?

Find out the basics over at css3.info then delve into more detailed browser support information at webfonts.info.

Hosted font services

• Familiar families, desktop licensing: http://webfonts.fonts.com/
• http://fontdeck.com/
• http://kernest.com/
• http://typekit.com/
• http://code.google.com/webfonts

Download and host your own fonts

• http://www.fontsquirrel.com/
• http://www.theleagueofmoveabletype.com/

Off you go, make the Interwebs pretty…

There was a time that the Internet was a lot less pretty than it is today. In part, this was due to the absence of modern JavaScript libraries that allow developers to make shiny things move elegantly around our web pages. This was the age of Dynamic HTML; DHTML ushered in the era of all things 'whoosh' that didn't rely on third party browser plug-ins.

Since then, there have been many new varieties of whoosh; they've had myriad names and been implemented in some pretty creative ways, but they all relied on the same user input. So when I got my hands on a completely new type of input–with the recent iOS 4.2 update–I had to have a play.

Note: Not interested in code? Jump to the slideshow on Phenotypic and tilt your iOS 4.2 device.

I must admit, as a web developer I never really expected to encounter 3D space as a mathematical construct, let alone all those formulae I was assured–in school–would one day be of some use to me.

Thankfully the w3c have kept it pretty simple and have recommended browser vendors give us nice interfaces to bridge the gap between real-world notions of device orientation and pure maths, so that the following…

window.ondevicemotion = function(event) {
  ax = event.accelerationIncludingGravity.x;
}

… effectively tells us a device is moving on the x-axis, which direction it's going and how fast it's moving.

Mix this with a little window.onorientationchange to detect which way up your device is and you know which actual axis the user is–most likely–perceiving as the x-axis. Oh, and it's worth remembering that a user's perception of left and right is also relative to the device's orientation; adjust as you see fit.

window.onorientationchange = function {
  if (orientation == 0) {
    deviceOrientation = 'portrait';
    scrollDirection = 'right';
  } else if (orientation == 180) { 
    deviceOrientation = 'portrait';
    scrollDirection = 'left';
  } else if (orientation == -90) { 
    deviceOrientation = 'landscape';
    scrollDirection = 'right';
  } else if (orientation == 90) { 
    deviceOrientation = 'landscape';
    scrollDirection = 'left';
  }
}

window.ondevicemotion = function(event) {
  if(deviceOrientation=='portrait') {
    scrollAcceleration = event.accelerationIncludingGravity.x;
  } else {
    scrollAcceleration = event.accelerationIncludingGravity.y;
}

If you're lucky enough to have such a device, load up Phenotypic and get tilting, or have a read of the w3c draft spec and create something with a bit more whoosh.

I cringe when I hear web developers cursing the name of Bill Gates for his part to play in the browser everyone loves to hate – Internet Explorer 6. The reason is fairly simple: For the most part, an IE6 'bug' is the manifestation of poor code.

This is best demonstrated by having a look at a common cause of layout issues that plague IE6 users – sub-pixel calculations on the DOM.

Let's set the scene: you have a parent node, its font size is 16px, this element has a child, it's 12.785em wide.

12.785*16 = 204.56

Convention dictates that anything greater than point five is rounded up to the nearest whole number and we can hardly expect our browsers to render .56 of a pixel, so the child is 205px wide, right? Afraid not. Browser developers clearly didn't attend the same school as I did. They take my careful calculations and carelessly throw away the .56; the resulting element is 204px wide.

But all is not lost, the clever chaps at Mozilla have come up with their own way of handling sub-pixel precision. Take the example above, add two further child elements with the same width as the first, check the result in Internet Explorer, Safari or Opera and you'll end up with three elements that are 204px wide (that's 612px… I know, stick with me here). View the same page in Firefox and you'll see a 205px element followed by a 204px element followed by another 205px element... that's some pretty crazy normalisation right there.

This is just a tiny example of the sort of stuff that's going on in your favourite rendering engine, but one important fact remains: each page load is consistent, and therefore predictable. Take a close look at your calculations and make sure your CSS is as predictable and consistent as your browser, the list below is a good place to start:

• Don't use 62.5% on your body, you're just creating unreconcilable rounding inconsistencies,
• Do your calculations before you start coding, don't just jump in swapping pixels for EMs,
• Try to keep your font sizes to whole-pixel equivalents,
• Think first, code later.

I'm all for lovingly crafted API libraries and detailed technical docs, but sometimes I just want a simple answer; a snippet - something to practice my CMD+C skills on.

It would seem the Posterous community currently aren't too hot on simplicity, so here are a few lines of code that'll give you a nice array of Posterous posts for a given site name.

function get_posterous($sitename) {
    $ch = curl_init(); 
    $method = 'http://posterous.com/api/readposts?hostname=';
    curl_setopt($ch, CURLOPT_URL, $method.$sitename);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
    $data = simplexml_load_string(curl_exec($ch)); curl_close($ch);
    foreach ($data->post as $post) {
      $i++; 
      $posts[$i]['timestamp'] = strtotime( (string) $post->date);
      $posts[$i]['title'] = (string) $post->title;
      $posts[$i]['url'] = (string) $post->url;
      $posts[$i]['body'] = (string) $post->body;
    }        
    return ($posts)?$posts:false;
}

It's not pretty–nor extensible–and it doesn't follow any form of programming convention, but it will give you this…

array(2) {
  [1]=> array(4) {
            ["timestamp"]=> 1290512640
            ["title"]=> "Posterous API"
            ["url"] => "http://post.ly/1ElvU"
            ["body"]=> "The HTML content of your post"
        }
  [2]=> array(4) {
            ["timestamp"]=> 1290512640
            ["title"]=> "Another post"
            ["url"] => "http://post.ly/1ElvUd"
            ["body"]=> "The HTML content of this post"
        }
}

…and sometimes that's all you need.