I've just put my Voices That Matter presentation online (PDF, 600K); and I've also published it on Slideshare.

This presentation overlaps with my recent Yahoo! one for about 40%, and it's somewhat more basic. (Still, it was the most advanced JavaScript presentation at the conference.)

By the way, the good people at Yahoo! have already published the video of my presentation; including a complete transcript (it's odd to read through it).

As I said during my VTM presentation, the Yahoo! one contains the solution to the focus/blur event delegation thing, as well as some information on events in the mobile browsers.

The slides of my Google presentation are now online (PDF, 841K).

This presentation, too, has been taped and will be published online. I'll let you know when that happens.

I also caved in to Jon Boutelle's peer pressure and now publish my slideshows on Slideshare.net; including this one.

continue reading

The slides of my Yahoo! presentation on JavaScript Events are online (PDF, 1.7M).

The presentation has been taped and will eventually be published online; I'll let you know when that happens.

continue reading

As I said before, I’m currently working for Vodafone on mobile browser compatibility and W3C Widgets. I’ve discussed some mobile browser problems, and you can look over my shoulder while I’m at work dissecting their odd behaviours. If you want the latest scoops on my mobile adventures, you can follow me on Twitter.

The time has come to talk about the W3C Widgets part of my job. Exactly what is a widget, how do you create one, why would you want to, and which systems support them?

Personally I firmly believe that widgets are the future of the mobile web. They are easy to create, they’re based on open standards, they save the end user quite a bit of network traffic, and many people around the world already know how to create them.

In contrast to other recent publications about widgets, I’ll tell you the whole story — or rather, a condensed version thereof.

continue reading

I’m pleased to announce that Google has graciously agreed to sponsor my work on my compatibility tables. We’ve entered an agreement for this year; after that we’ll see what happens.

Therefore, if you go to the compatibility tables now, you’ll see a tasteful little sponsor bar at the bottom of every page with a well-known logo in it.

continue reading

The HTML 5 spec introduces the <time> element to mark up a date or time. Although I support the inclusion of these semantics in HTML, I believe that the current specification of the <time> element is vague because it avoids the question whether the element is safe for historians. Right now it hurts historical research more than it helps. In this entry I’ll explain why.

Although I will concentrate on the HTML5 syntax here, what I have to say also applies to the microformats datetime design pattern. The Microformats site adds one important detail to the discussion that the HTML5 spec overlooks: the point of having a <time> element (or a datetime design pattern) at all:

Use the datetime-design-pattern to make datetimes that are human readable also formally machine readable.

Who needs machine readable dates? As far as I can see there are two target audiences for this operation. The first is obviously social applications that have to work with dates, and where it can be useful to compare dates of two different events. An app must be able to see if two events fall on the same day and warn you if they do.

However, as a target audience social applications are immediately followed by historians (or historical, chronological applications). After all, historians are (dare I say it?) historically the most prolific users of dates, until they were upstaged by social applications.

This raises the question whether the <time> element should be tailored for historical use at all. When I started writing this entry I was convinced that it should.

In keeping with the definition of its purpose I the see the <time> element as a tool for an Internet-wide chronological search-and-compare system. Such a system will be a boon to historians, who would be allowed to quickly and easily look up events that happened around the same time as the event they’re writing about.

In history, just as in other academic disciplines, serendipitous discoveries are the meat of exciting new theories. A history-compliant use of the <time> element that allows automatic search and compare would broaden the horizons of historians.

However, now that I’ve reviewed some of the more common problems that have to be solved in order to decrease potential harm, I’m starting to doubt whether the <time> element can easily be made to fit history.

Right now, though, the specification is a vague compromise that doesn’t make the <time> element useful for historical research, but still allows it to be used historically.

I feel this ambiguity should be removed. I feel that the specification should clearly state whether the <time> element is meant for historical use or not. The current vague, implied “No” should be changed to a clear answer. I prefer Yes, but I can live with No.

If the <time> element should be made safe for historians, there’s quite a bit of work to be done; some of which is discussed in this article. If it should not be made history-safe, we have to add a cut-off date to the specification. Dates before this cut-off date would be ignored.

continue reading