I’ve been watching the development of the new specification with interest because it could result in a much more usable markup language for web developers. The best bit about the new specification is that instead of just trying to patch up flaws in its predecessors, the specification is keeping the good bits and ditching the old bits nobody cares about whilst formalising the concept of web application frameworks using established APIs (as opposed to vendor specific).

The problem with plugins

Although CSS support has gradually become more uniform across browsers, creating designs that break away from the rectangular box mould is challenging – surprising when you consider the maturity of the Internet technologies that drive the sites we all use.

Most of the more-interesting parts of the Internet are dependant upon the client browser using plugin technologies to achieve a greater degree of user engagement. Vendors have made the client plugins free to download and install but that doesn’t change the fact that propriertary technologies are required to achieve what isn’t specified within existing markup standards. Of course, though the vendors of the more successful and pervasive plugins provide the client plugins for free, they charge a considerable amount for the authoring tools to create content for the plugins.

Farewell SGML

One of the first things that caught my attention about the new specification was the decoupling of HTML 5 from its root language; SGML. This makes sense when you consider that browsers don’t use an SGML parser to render web-pages. It’s only validators that do that – and even then, not all of them do.

HTML5 will (apparently) require that documents are served as either text/html or application/xml but not both. This does make sense when you consider how different the structure of a HTML document is when compared to a well-formed XML document. Either way, one think I won’t miss is the DOCTYPE line at the start of each web document.

The text/html model will be preferable to many, especially seeing that it doen’t force the strict well-formedness rules of XHTML 1.0 upon the structure.

Javascript

Many websites use Javascript to dynamically generate web-content. HTML 5 introduces some stricter rules as to how this should function. Two that particularly caught my eye were:

• If Javascript generates HTML content that includes elements, the closing tags for those elements must be escaped. This is because the data for the element starts immediately after the opening tag and ends at the first closing tag that is encountered. I’ve tried to show this in the code below – the closing tag for the bold element has been escaped so that the closing tag for the script element is processed first.

<script type=”text/javascript”>

document.write(”<b>This is bold text<\/b>”);

</script>

• When writing event code for HTML elements, figuring out how to nest quotes within quotes was a nightmare. Now coders will be required to use HTML entity codes instead. This means that instead of this :

<input type=”button” onclick=”alert(’Hello World’);” />

it will be :

<input type=”button” onclick=”alert(&quot;Hello World&quot;);” />

Support for multi-lingual indexing

There will be support for linking translations of web-pages by using the link element and a language specifier – presumably this will enable the browser to display the page appropriate for the user rather than pages having to have specific anchor links to different pages.

Is that it?

This post barely even scrapes the surface of the new HTML 5 specification.

There are some very interesting multimedia extensions that will permit the embedding of video and sound within pages without additional plugins and the humble HTML tables will be receiving a fair amount of attention too.

The best part of the new specification is that some of it has already been implemented in newer browsers. Internet Explorer 8 and Firefox 3.5 have both introduced support for various parts of the new draft.

Whilst it might be fun to play with the shiny new toys, unless you know the majority of your site’s users are going to be using a supporting browser, HTML 5 probably isn’t ready for the masses yet.

The station is called ETN and they broadcast two streams at various bandwidths; ETN1 (Trance) and ETN2 (Progressive).

Here’s the hi-fi (256kbps) MP3 stream addresses:

ETN1 (Trance) : http://www.etn.fm/playlists/etn1beta.m3u

ETN2 (Progressive) : http://www.etn.fm/playlists/etn2beta.m3u

They also have streams for other streaming clients (like WMP and Real). If you insist on being a slave to such commercial beasties, you’ll need to get the stream addresses from ETN’s Tune In page.

They only start broadcasting at 10am (their time) which is GMT-4 (that’s 1400 to us in the UK).

I highly recommend the freeware Internet radio player called Screamer to listen to them. You can get that from here : http://www.screamer-radio.com/

Happy listening trance/progressive fans! :-)

It does a number of tests by applying MooTools, JQuery, Prototype, YUI and Dojo to an HTML document and reports the total times of each library at the end.

Just out of curiosity I applied the test using Firefox 3 and IE6 (my employer’s browser of choice).

Take a look at the results:

The difference in the times is staggering! Firefox out-performs by at least 200% (and way more for some of the frameworks).

Here’s the kicker

Because many companies continue to use IE6 as their corporate browser (largely because their standard disk images use the default browser that comes with XP SP1) serious web developers are forced support IE6 to at least a minimal degree.

I don’t like IE6 – for personal projects such as this site, my support for IE6 really is a token gesture (but I still endeavour to make the site visible in IE6). Sadly for commercial projects when as wider range of browsers need to be supported to keep a client happy, a web-developer ignores IE6 at their peril.

Even the edit window in Wordpress doesn’t resize gracefully in IE6. Half of what I’m editing is hiddent behind other div containers and I don’t blame Wordpress for that. IE6 stinks.

According to W3School’s browser usage statistics, 14% of their visitors were using IE6 in May 2009. IE6 is like a bad cough that just won’t go away and I blame narrow-minded and lazy IT departments for its perpetuation. Get with the times, you Luddites.