This blog moved again. Here is the new adress: http://tpeklak.wordpress.com/

...or definition lists – the semantic horror

Recently I had to design the web page for a glossary of about 400 terms. First I wanted to design it semantically correct with a definition list but ended up in using tables. I normally try to use only semantic markup, but I think the definition list is really hard to style with the CSS that’s available today.

What is a definition list?

Generally spoken it’s list of terms and definitions, something like this:

Term..
      and it’s definition

Term

Definition

Additionally it’s possible to have multiple definitions for one term (e.g. photo -> description and location) or multiple terms to one definition (e.g. cat, dog -> are animals with fur)

Default view

I don’t really like the default view of definition list, where the definition data is indented a bit. In my opinion it’s ok for small lists, where you won’t lose the overview. Applied on larger lists the viewer soon gets lost.

Table view

So I tried to implement an easy to read table view of a definition list.

Header

There is no way to define a header. Of course you can use the definition list for the header, too, but that’s not semantically correct. Definition is not the definition for term, this would be a semantical nonsense. Using two divs for implementing the header would be rather complicate and again semantically not correct, as you can not create a reference to the definition list.

Style rows

When I try to style large tables, I like to define alternating row colors for easy reding. This is done by settiing a class value to each second row or even easier with CSS3’s nth-chlid selector. In definition lists you have to set a class to every element that’s presented in one row. If you 1 term and 2 definitions for example, you have to style three tags in each row. This is rather unhandy and leads to a large amount of unnecessary markup.

If you only have a term and definition, you could try to style the rows with
dt.even, dt.even + dd{background:#lightblue}
But our old friend IE does not understand this selector.

Styling columns

To style columns in a table you just have to apply a style to the col tag. Doing the same with definition lists is pretty much the same effort. As you can style dt and dd separately. Again, this applies only to a one term and one definition environment. If you have more definitions, you have to set a class to at least one of them.

But here comes the real pain:
There’s nothing more simple than setting the width of the term column to the minimum required width, so you don’t have any line breaks in there. The browser does this automatically, and if there really is too less space, it makes line breaks. Doing the same for a definition list is in my opinion impossible. You have to set the width manually and therefore will never be able to set exactly the right width.

Definition lists are not semantic

If you look at the source code of definition list, you see that it’s not a good semantic markup. There is no reference between the two tags dt and dd. To associate these two you would have to introduce a third element (definition group) like this:

Or you would have to put the dd inside of the dt like this:

With this markup it would not be possible to have more than one term for a definition.

I think that definition lists where designed with the best intensions and with a lot of freedom, but not in a semantically right way. Therefore it’s harder, than it should be, to apply a suitable style to them.

Related: Definition lists – misused or misunderstood? by Russ Weakley on maxdesign.com

technorati tags:web, html, css, semantic

Flickr introduced the new feature Geotagging recently, that you can use the mark the location of a photo on a map. Last week I gave it a try and just could not stop until all my photos were geotagged. I admit, I’m an Geotag-o-holic. Even tough I’m not completely satisfied with the interface, the tagging goes with such an ease, that you wonder in the end, if you have really tagged all your pictures.

I like geotagging much more than writing a description to each picture, where it was taken. It’s a feature for the lazy, so it’s quite right for me. I dream of a future with GPS-enabled cameras, when the pictures are automatically geotagged.

The Flickr people did a great job, the problem is the mapping system. As Flickr belongs to Yahoo, they are forced to use Yahoo Maps. Unlike Google Maps it is a bit slow and it’s sometimes really hard to find cities, because they are either not shown or only shown when fully zoomed in. It’s interesting that I’ve found all location when searching for it, but they are often not displayed on the map.

That’s why I often changed to the hybrid view, but this really sucks. I have a 2 Mb internet connection and have to wait up to 1 min until the whole map is displayed. That’s far too long. The location you search is always located in the middle of the map. You can try and guess where exactly this is. It would easy up life, if the searched location showed up on the map. This feature shouldn’t be that hard.

Related: Dave Shea writes on mezzoblue.com about some problems when displaying the photos.

technorati tags:flickr, geotagging, photo