Keri Henare - I'm a gamer & web development geek from Auckland, New Zealand

HTML5, I love the idea but I often find myself having issues with the ongoing saga of politics around it. Faruk Ateş recently wrote of The Battlefield of HTML5 (it's a good read if you haven't already) and made one suggestion that I completely support, Modularised HTML5.

As I read Faruk's arguments for modularisation I felt completely in agreement but I was also nagged by a sense of dejavu. Modularised HTML, hadn't we already been here before? XHTML1.1 was basically just a modularisation of XHTML1.0 Strict, which was a reformulation of HTML 4.01 Strict in XML. These specifications are the basis on which HTML5 is built, so who forgot to follow XHTML1.1's great advancement of modularisation? If you would like more information on the argument for the modularisation of HTML5 then read Faruk's article. Of course, I have an additional recommendation to make.

Versioning HTML Modules

A specification is a lot like a piece of software or an API, it changes over time. Pieces get altered, pieces get removed and new bits get added. Versioning allows you to snapshot a point in the specification's development life and assign an identifier to that specific snapshot. Currently HTML5 is one big moving target and both developing with it and implementing it are a pain. Modularisation coupled with Versioning would better allow everybody to explain exactly what they support without slowing down the development of the specification.

I realised the other day that I have quite a few Transformers t-shirts. This won't surprise many that know me because I'm a massive Transformers fan. For those who didn't know, yeah, I just got geekier. I love my Transformers t-shirts and I've decided to wear a different one to work each day this week. I know that I've got at least enough to cover this four day week, so I might even continue on after that.

Tuesday

Here's my most recent Transformers t-shirt (a Christmas 2009 gift from my younger sister) featuring Optimus Prime in all his glory.

It's been a long time since I've given my blog any decent amount of loving. I've often talked about the things that I've wanted to do but my dreams often didn't produce any tangible results. I have created more design concepts for this website than I care to think about and have many gigabytes of hard drive space taken up by concepts in photoshop format. Some concepts even reached the HTML or Wordpress theme stage, but none went live. In terms of development, I've looked reworking and extending Wordpress many times and have even looked at developing a Django-powered version. Nothing came from my redevelopment attempts either. That is, not until today.

I first switched to Wordpress more than four years ago and for a long time it suited my needs perfectly, but times have changed and so have I. Everyday my job requires that I create complicated and elegant solutions to content management (for complicated content, we don't reinvent the wheel), yet my own site has been run on a basic Wordpress install. Every time I've wanted to add functionality, I've done what most people do and installed plugins. But, plugins are still limited in what they can do and (please, nobody take offense) Wordpress plugins aren't always developed to a very high standard. I decided to finally abandon Wordpress.

There were no promises or plans for grandeur. I just started a new symfony project and got down to work. I've tried to reproduce as much of the old site's functionality that I could and I think that I've done quite well. Symfony is such a pleasure to work with and I would never have been able to do this without it. It really is a great rapid-development framework. In order to focus my attention properly, I decided not to redesign at the time of redevelopment. I did make various stylistic improvements but the design largely remains the same.

There's still a lot of work left to do in this initial phase, but I'm happy to now have a platform on which I can begin to evolve this site. Changes will be gradual and incremental but over time there will be plenty of them, that's not a promise, it's a fact.

The age of HTML5 has arrived and it’s time that we should all be using it, however, in your rush for the “next cool thing” please do not brush accessibility aside.

At the start of 2007 Andy Budd wrote a post (yes, I intentionally copied it’s title) looking forward to the future of HTML with some ideas about how it might evolve. At the time, the WHATWG were working on a draft specification that would become HTML5 and eventually be accepted by the W3C. We knew that change was required to keep the aging HTML family alive. Oh how we longed for change.

Finally, two and a half years later, change has arrived and people are starting to use HTML5 in real websites (I quickly converted this very website to HTML5 recently). HTML5 isn’t just something to experiment with and talk about, it’s something that you can use right now, even on client websites.

This is where I should take a minute to quickly dispel two commonly held but incorrect beliefs about HTML5. First, HTML5 does not mean the end of XHTML. HTML5 served as application/xhtml+xml is XHTML and is completely valid. This is why you sometimes see HTML5 referred to as XHTML5 or more commonly, (X)HTML5. Second, you most definitely are allowed to use XML syntax in HTML5 even if you are serving it as text/html. The HTML5 specification allows HTML to use either the SGML syntax as in HTML4.01 or XML syntax as in XHTML1.0. I prefer the later, but the choice is yours.

What is this HTML4.5 thing, anyway? HTML4.5 isn’t a specification (although it wouldn’t hurt to become one); it’s just a subset of HTML5 that is compatible with older browsers. So it is HTML5 and not HTML4 but I thought that HTML5-0.5 sounded kind of silly. While all major browsers seem to have no trouble with the HTML5 doctype, all versions prior to Internet Explorer 8 and Firefox 3 (and therefore Camino 2 & Flock 2) do not support the new HTML5 elements. These browsers combined may represent up to 32.2% (W3Schools browser statistics, July 2009) or a third of web browsing.

There are some techniques that allow you to style the new HTML5 elements in browsers that don’t natively support them, but not they're not so easily implemented. Internet Explorer techniques require the use of JavaScript (up to 5% of users either have JavaScript disabled or it isn’t supported by their browser). Gecko browsers (Firefox et al) require that the page be served with the application/xhtml+xml mime-type, which will cause a page to not display at all if there is even a single validation error.

So what can you use? Basically you can safely use any element that exists in both HTML4.01 and HTML5. For a quick reference, checkout W3School’s HTML5 reference list. I’ll follow this post up with another more detailed post soon. You can also use some of the new HTML5 form input types. All major browsers, if they do no recognise the input type, will default to a text input field. Obviously you aren’t going to get any new UI features, but it can make your JavaScript-based form validation a little cleaner.

HTML4.5, because HTML5 is ready now… just not all of it.

Apache's mod_rewrite has become a friend to web developers throughout the world. It allows you to create tidy, user-readable URLs instead of ugly, meaningless links that often just expose an ID for a database record. A 'Fancy URL' will usually contain a version of the page title which is both human and machine readable as well as being a valid URL segment, this is called a slug.

Fancy URLs allow humans to easily remember locations of content and to better understand the logical layout of your website. They also improve the SEO quality of pages as they can provide search engines with additional keywords about the page.

And example of a fancy URL in action would be http://kerihenare.com/archive/2009/07/23/fancy-urls-and-slugs and the alternative (without mod_rewrite) would be http://kerihenare.com/?p=105. In this example the second URL would definitely be shorter, however it doesn't mean anything to us. The first URL provides us with a content grouping (archive) as well as the date of article and a slugified page title. Slugification is the act of turning a string, such as a page title, into a slug - It's one of those made up industry terms and may not be found in a dictionary.

In some recent development, I put a lot of effort into creating PHP & JavaScript functions that perform slugification. It's very simple code, but really focused on creating rules that allow the slug to be as clean and meaningful as possible. The other day I noticed an example of bad slugs on a well-known website so I've decided to share my rules for a good slug.

A lot of site's use simple slugification, where all non-alphanumerical characters are replaced with a dash. While such a method gets the job done the result isn't always perfect. In simple slugification "Fancy URLs & Slugs" would become fancy-urls---slugs, which is a little ugly and replaces the word & (& = and, which is a word) with a dash loosing meaning and flow. Compare this with our earlier example of fancy-urls-and-slugs and you can clearly see the difference.

My rules for slugification:

1. Convert the string to lowercase
2. Replace all ampersands with 'and'
3. Replace whitespace and underscores with a dash
4. Replace all Remove anything that isn't a dash or an non-alphanumerical characters with a dash
5. Replace all occurrences of more than one dash with a single dash
6. Remove any dashes from the start and the end of the string

Wordpress is quite good in that it does steps 2 and 3 but not the first step some, but not all of the steps, maybe I should suggest the change.

Update: Arg, I shouldn't make blog posts before 9am because I'm still half asleep. After a comment from Matthew Buchanan I've realised that I took some shortcuts in my rules so I have now updated them as per my source code comments. - 25/06/2009