John Beales

Last year when I was working on the redesign of BonzoBox I used HTML5 for the first time. The specification is being developed by two groups, and consists of a bunch of different modules, each with a different level of readiness, and the actual specifications, (yes, both of them!), are meant more for people who build web browsers than people who build websites. This led to some confusion. While I eventually wrapped my head around HTML5 I never felt that I had as good a grasp of the language as I would have liked to, so when I heard about Introducing HTML5 I added it to my to-read list. I finally had a chance to read it a couple of weeks ago.

Introducing HTML5 is the overview that I was looking for when I first started learning about HTML5. While I wish I had found it then, (although it wasn’t published at that point), and I learned a lot from it now. One thing that I had completely missed in my self-directed HTML5 studies was the outlining module, (if you’ve missed it too it dictates how an outline of an HTML5 document would be created, which allows you to figure out how important each element is in relation to each other element on the page). I also learned about some new elements that I hadn’t yet stumbled across, (like <mark>), and learned more about HTML5 form elements than I already knew, (although I was fairly familiar with those from the 24ways article).

There’s a chapter about the <canvas> element in Introducing HTML5. I was scared of the canvas element but the canvas chapter changed me from afraid to excited. It’s not so hard as it looks to work with and there’s a lot of really cool stuff that can be done with it. It’ll be fun to play with when I get a chance.

There’s also a chapter about using HTML5 apps offline. It’s possible to tell the browser to cache most, even all, of a website or webapp so that it’s completely usable offline. This cache seems to be a lot stickier than the normal browser cache and I wonder if it would be possible to also use it to drastically speed up online apps. This could lead to some real pain when updating websites, but if it’s planned well enough it might work really well.

Finally, websockets look great. They look fast, to the point that maybe we could make some stuff lightning fast on the web. Unfortunately a security problem was discovered in the websockets protocol so it was disabled in Firefox 4 and the latest Opera, and apparently Google Chrome is set to disable it if any attacks are carried out. I really hope that the security issues will be ironed out quickly so there can be wide adoption of websockets. I’m having problems finding out what the current status is of the security issue, I can’t find any articles more recent than those from December, so if anyone knows what’s going on please post a link.

I learned a lot from Introducing HTML5, and I’m excited to redesign a website, (or a few), using it, plus some CSS3, (I’ll be reading up on that soon).

Want to read it yourself? Get it from one of these places and I’ll receive a small kickback:

Amazon.com (USA) Amazon.ca (Canada) Amazon.co.uk (UK)

I’m working on a project now were we’ve decided to go with as pure HTML5 as posible, and it’s a breath of fresh air. Things work more or less how they should, and Internet Explorer is even playing along, with a little help. Getting started was a bit of a trick, though, as it can be hard to find information on how HTML5 works without diving into specification documents, which is never fun, or easy, (if you don’t want to read the story, skip straight to the resources).

I hadn’t been following the development of HTML5 with more than a passing interest. I figured that when it was ready, then I would start using it. I also understood that there were different parts that may reach completion at different times, and was keeping my eye open for some sort of “completion” signal. 2009′s 24 Ways was that signal for me. There were several articles on using HTML5 features along with their CSS3 counterparts, and enough evidence that browser support is there to start my investigation.

Here’s the deal: Basic HTML5 support is pretty good in webkit-based browsers, alright, (read usable), in Gecko, and kind of lacking in Internet Explorer. However, if you can rely on Javascript being present, (which I can in my project), there’s an HTML5 Shiv Javascript by Remy Sharp that makes it so that you can style HTML5 in Internet Explorer. Add it using a conditional comment and you’re good to go.

So, we have useable cross-browser support, but where do we turn to learn about which tags are in, which are out, the correct doctype and mime-type, and all that? We could read the specification, (and we will have to read a bit, at least), but it would be nice if there was an introduction to HTML5 somewhere. It turns out that Robert Nyman has written an Introduction to HTML5. It’s detailed enough to get you started, but not so detailed that you get lost, (like the spec), and if you’re looking to be convinced of the value of HTML5, check out HTML5: Tool of Satan, or Yule of Santa?, Have a Field Day with HTML5 Forms, and Breaking out the Edges of the Browser from 24 Ways 2009.

Once you dive a little deeper you’ll find that there are elements of HTML5 that you need more in-depth information for, so it’s time to turn to the spec. However, there are 2 groups, (W3C and WHATWG), working on HTML5, and therefore 2 spec documents, (fun!). Fortunately, the two groups have the same editor, so they’re more or less working on the same thing. I find the WHATWG HTML5 document easier to read, but if you prefer the W3C version, go nuts.

Finally, the whole content-type debate that’s been going on for what seems like centuries is still a mess. In HTML5 you’re supposed to include a Document Type Definition and there should be no namespaces on the HTML element if you’re serving as text/html, and you’re supposed to serve in application/xhtml+xml if you want to use namespaces, or force XML validation, or anything like that. The problem is that Internet Explorer really doesn’t like application/xhtml+xml, (it shows the raw XML document), so if you need a namespace for some reason, (for example, you want to use Facebook Connect on the site), you can’t serve valid markup.

So, that’s it. HTML5 has arrived, or at least parts of it. If you can rely on Javascript being present, or rely on IE users not using your web app, you can go ahead and start using it. Here’s a quick recap of the resources:

• Introduction to HTML5 by Robert Nyman
• HTML5 Shiv Script by Remy Sharp
• HTML5 Spec from WHATWG and the W3C
• From 24 Ways 2009:
  • HTML5: Tool of Satan, or Yule of Santa?
  • Have a Field Day with HTML5 Forms
  • Breaking Out the Edges of the Browser, (also by Remy Sharp)

Today I am announcing the release of MyMap Explorer for Google Maps. This small javascript allows you to embed a map created using Gooogle Maps’ My Maps feature into any web page with more information and flexibility than Google’s iFrame embed code.

Back in November, Heri asked for a relatively simple way to integrate his Technology Map of Montreal into Montréal Tech Watch, and MyMap Explorer is the result, (see it live on the Technology Map of Montréal), It takes the KML description of a map from Google Maps and adds it to a map created using the Google Maps API. It also provides an alphabetized, clickable list of the points on the map so that your users don’t have to click on each marker to find the location that they are looking for.

The KML is loaded live from Google Maps so if you make a change to your map on Google Maps it will be shown in all embedded versions of your map as well. This script has no dependencies, other than Javascript and a Google Maps API key. Just insert it into a web page where you want to see your map and it appears!

I have some features that I still plan on adding, but want to get the basic script out there and into use. I’ve released the code on Google Code under an MIT license so you are all free to use MyMap Explorer, and contribute if you feel up to it.

The demo is here.

Have you ever created new clean XHTML template, applied it to a CMS with years of back content, and discovered that the years of legacy HTML looks terrible?  Because you’re using a new XHTML doctype many, if not all, of the presentational attributes in the old HTML no longer work, however, CSS can be used to fix this.

You may say that the whole point of building a new template with XHTML & CSS is so that we won’t have any of the old <p align="right"> in our code, and you are right, but in situations when there can be thousands of pages of content it is often not practical to re-code them all using CSS, that’s where the attribute selectors come in.

Here is a very basic stylesheet that will help get you started:
img[align="right"], table[align="right"] {float:right;}
img[align="left"], table[align="left"] {float:left;}
img[align="center"], table[align="center"] {display:block;margin-left:auto;margin-right:auto;}

p[align="center"] {text-align:center;}
p[align="left"] {text-align:left;}
p[align="right"] {text-align:right;}

table[border="2"], table[border="2"] td {border:1px solid #000;}
table[border="1"], table[border="1"] td {border:1px solid #000;}
table[border="0"], table[border="0"] td {border:0;}

Although it would be nice to have one master stylesheet that we could drop in to a document and automatically have the old HTML look great, I believe that stylesheet would have to be extremely large, so I recommend using a base set of styles, (like the one above), and adding any extra styles to it that may be needed, (for example, img[border="5"] {border:5px solid #000} would not be needed every time).

What about browser compatibility? I’ve tested in FireFox 3, Safari 3, Internet Explorer 7, and Internet Explorer 6, and, if I remember correctly, Opera 9.  The only browser that didn’t render the styles as I would have liked to see them was IE6, which is no surprise, but also has a rapidly diminishing market share.

If you are looking for a way to keep your legacy HTML from looking terrible that doesn’t involve recoding it all, this may be the way for you to go.