(h)onder(d)hond.com/100 posts jubilee

Sat, 19 Jul 2008 11:49:30 +0200

It's probably not smart making Dutch puns on a site which has an international audience, but I just couldn't resist. After 245 days of blogging, I finally added my 100th post. A nice milestone that deserves a little attention and reflection. It's also a good time to tell you something more about the whole Onderhond deal I guess.

I remember pretty well that right before starting my blog I read an article that mentioned half of the bloggers quit after the first 4 months. It actually frightened me a bit as I had really no idea what I was getting myself into. Luckily I survived those first 4 months (although I can understand why so many quit) and I'm still here to celebrate my 100th post.

Looking back at my articles I might not really be a true blogger either, as I do my best to write articles instead of blog posts. I've been thinking about removing the word "blog" from my site completely, but the alternatives I came up with never really related as much to the continuity of fresh content as the word "blog" does. I guess I'll just leave it be for now.

As for the whole Onderhond monicker thing, I know it was a strange decision to take a Dutch language url/monicker for a site with an international audience, but it's a nick that served me well on the net for over 8 years now. It's always and everywhere available too, and it's really too closely connected to my persona to simply neglect it. For those who are curious, onderhond is actually a Dutch transliteration of the word underdog (under = onder, dog = hond). And for the pun in the title, honderd = hundred. So nobody can complain about feeling left out.

Guess that's it for now, on to the next 100 posts! Though I'll probably reach my 1 year celebration before that. For me it's been worthwhile so far, hope it been the same for you.

css type selectors/designing the semantic web

Fri, 18 Jul 2008 11:43:39 +0200

html and css are closely connected, no doubt about that. When we style a web document we do it through the mark-up of the document. It's one of the pillars of modern web design and we all take it for granted. But take a closer look and you'll find that this way of working isn't always as logical as it sounds. This article will focus on the way html and css coexist and the effect this should have on the way we write our css.

avoiding inconsistencies

When people start off writing css the results are often pretty chaotic. Starters focus on making things work, which leaves css files badly structured and littered with inconsistencies. It was like that for me too. But the more I learned about css, the more I saw the need to avoid these inconsistencies and to optimize my way of writing css.

Of course, there is no one way to write css, so from time to time I had to decide which choices would be most beneficial in the long run. One particular problem had me puzzled for quite some time and it wasn't until recently that I found some good arguments to base my decision on.


		/* css selector with type selector */
		ol.breadcrumb
		/* css selector without type selector */

		.breadcrumb

When looking into the way I composed my css selectors I asked myself whether it would be useful to include the type selector to a class selector. The little piece of code above illustrates the decision I was trying to make. The choice is easy when a class selector can appear on multiple html elements, but what if the class was unique to one html element?

coming up with arguments

There are things to be said about both ways of working. For one, if you leave the type selector off it will decrease the length of your selector which improves the readability of your css file, especially when many selectors are stringed together. Less scrolling sideways is a good thing. On the other hand, adding the type selector does give you extra information on the class and might make it easier to recognize elements as you got the html element to help you out.

A more important argument popped up when I was revising our deliverables (our company only does front-end, so we deliver templates to be implemented by partners). Adding the type selector locks the css to the html code. By doing this, you create an extra checkpoint for people to implement the templates you deliver. If, for example, they used an <ul> element to mark up the breadcrumb it wouldn't be styled and they would know there was something wrong with the implementation. The argument was good enough for me and I started to include the type selector.

flexibility, the magic word

This went well for a while, but soon I also started to notice the drawbacks of locking css to html. I become more aware of the semantic meaning of some html elements and as I read through several discussions I saw the need to change a few things. One of those things was the breadcrumb, which I changed from an <ul> to an <ol>. When I did that, all the css styling dropped off even though the component itself hadn't really changed. Not a good thing.

It may not seem very likely for things like this to pop up often, but with html5 and xhtml2 in the pipeline I wouldn't be surprised if quite a few html implementations will change over time. And when that happens, it would be nice to simply change the html templates without having to touch the css. So flexibility became my key argument for leaving the type selector off, but something still didn't feel quite right.

the theory

If you really think about applying css to html on a very basic level, it doesn't make too much sense. html might be is a semantic language, but at the same time it's very generic. Of course we can add styles and layout to a paragraph, but most mark-up elements are too generic to really tell us anything about the actual component we're styling (think of everything marked up with a <div>).

Going back to our breadcrumb, you'll see that I've used a list to implement it. But a breadcrumb is pretty specific implementation of a list, which is in itself a very generic term. As a matter of fact, the most important semantic information in this case comes from the class we added on the list (the microformats principal). The reason why we use the list element is because we don't have any better, more semantic ways to implement our component.

Whenever this is the case, I believe it is safe to omit the type selector, as the added information is too generic for the component we're styling, and could be prone to change. In the case of our breadcrumb, the <ol> could be changed to <nl> (navigation list) over time, but even that would still be a generic definition. So from now on, I simply omit the type selectors whenever I'm styling a component that hasn't the exact same semantic meaning as the html element (I still use the ul selector to style plain bulleted lists for example).

concluding

The interesting part here is that many consider it logical to apply css to general semantic elements, while it is definitely not. When we are writing css we are styling components, and these components should be addressed only through their adequate html equivalents. In most cases, this means leaving the type selector off as it is simply too generic to be of any value.

An argument I'm pretty content with, and allows for more flexible css. Double gain.