I could give a list of nice blog post I wrote this year. I could post a cool movie related to web development. However, I would like to do an mind experiment on how to markup the year 2007. Oh yeah, with HTML.

2007 is in my opinion just an chain reaction of both interesting and boring things. Like always we have the option to choose, so I pick the first one. ‘Things’ is multiple, so a good start is using a list. Here we go.

The element name is, as you can see, year2007. I couldn’t find if this is an allowed name in the DTD specification, but I could just see <2007> in my browser if I used that one.

Another thing I ran into was the fact that some events are really general, but some are personal. So I also use the type attribute to indicate which one it is. The attribute can be used on the year2007 element itself, or one of the list items. So now we are talking about semantics!

Only missing is when the events happened. Okey, in the year 2007, but that is not precise enough. So the datetime attribute could be used on the list items. User agents may want to export the dates to a history e-book, for example. So have a look at the example with usage of the datetime attribute.

I am lazy, and since this is a bad joke I will not write a full DTD for all this. However, if I had written one, I could use a good validator that can read custom DTDs and Doctypes to validate the cool document I will markup later. Writing one would not be that difficult, though.

Now we have some kind of structure the list can be filled with some real events. You could expect it, I added some general and personal events that happened in 2007.

To add some style, I made a style sheet to indicate the differences between general and personal events. Since personal events are very important for me, they are a bit heavier. Just a simple CSS2 selector, nothing new invented. Check that out.

By the way, happy new year!

Many designers want to use fonts for a web site that are not installed on most of the computers. More fonts are a large problem, but there are some solutions.

The first one is a replacement system. You just use h1 and h2 elements for your headers, and after the page is loaded a JavaScript will turn them into an image or a Flash file. All the images are auto-created. sIFR is the most used one in that kind. This solution is very welcome when you’re building a large web site, or a web site that changes of content very often, like blogs.

When the web site is static (the content doesn’t change often), there are two methods you can choose. But one is in my opinion very bad practice.

That bad practice is the usage of a background image, attached to the headers via CSS. It can be done via text-indent (set that to a large, negative number), or via a span element within the header element. CSS then hides the text with the simple rule display: none;.

This is bad practice, because when the user had images turned of, the user doesn’t see anything! Plus, it is not very semantic because you do show an image, aren’t you?

My way for small web sites, is to use just an image tag inside the header element. Via the alt attribute you handle the search-engines, screen readers and people with images turned off. Unfortunately, some browsers do render something weird when there is no image to display, like that red cross in Internet Explorer. I satisfied myself to hope not many people have turned images off…

So, all not very cool solutions… but better solved in this way than wait for ages for more fonts for the web.

Some good news from the browser companies and organizations. Slowly some new standards get implemented in those nice browsers, which is a good step forward of course.

First of all, KHTML now supports every CSS selector noticed by the Selectors Test. Opera announced to do the same in their next build. So no more JavaScript, classes and ids to do simple things.

When I read Anne’s article about HTML5 forms I also noticed Opera does support some nice HTML5 elements already.

The only one who’s missing is… Firefox with it’s Gecko layout engine. I’m looking forward to the Gran Paradiso version.

The WYMeditor doesn’t work like other text editors, it produces semantic code. That’s why users can’t change font size, face et cetera, but can change heading, class and titles of images. A demo shows nice things, but it can be better. Nevertheless is this much more better than the standard WYSIWYG editors. Via Peter Krantz.

Months ago I begun with a project: learn Mambo. The first horrible problem came in a few minuets: the code was bad. The second followed soon: all the output was hard-coded in the Mambo core components.

But finally: this (Dutch) result came around: Stichting Jazz In Groningen.