I’m sure you’ve seen one of these icons before. These are used to indicate that a certain page uses W3C valid code. There exist smaller or text-only versions. I often click such icons when I come across one, just to find out it’s actually incorrect. I can’t remember ever seeing a W3 valid website using this icon.

Many people fail to answer the simple question of “why W3 valid XHTML?”. Or even better, “why XHTML over HTML?”. Bragging rights, mostly. Of course, no-one takes you seriously with a HTML 4 transitional code, that doesn’t even validate.

Why validation in the first place? Web browsers throughout history have never complained about errors in HTML structure. Rather than that they have tried to fix the errors. This made developers lazy and they didn’t care wether their code was really an actual html code. All programming languages complain about syntax errors and so don’t work when “invalid”. But making browsers work this way would break 90% (if not more) of the internet. A big no no there. So W3 took a different approach - Let’s promote the idea of validity among developers. And this is good. It has gone somewhere in the recent years. The problem, though, is that most people don’t realize why this is so important. Browsers draw my page correctly anyway. Yes they do, but have you tried all of them? Are you sure future browser will handle errors the same way they to nowadays? Do screen readers know how to handle errors? How about Google?

Ok, so we know why valid (X)HTML is good, and we have created a valid page. But do our users care? The only thing they care about is wether the page renders correctly or not for them. They don’t care if it renders correctly for everyone else. We should be caring about that.

One thing that I really find funny is how people try to bypass the validation errors. For example, target attribute is not supported in strict doctypes, therefore a link cannot open in a new window using valid strict (X)HTML. What people do, is they add a target attribute to links using javascript. This way they have made an invalid html code, that looks valid to the validator. This shows how validation itself is irrelevant to people, as long as they can stick a “W3 valid” badge to the page. The effect for regular (non-validator) usage is the same though.

So yeah, I’m all for the “validation passed” badges, they do raise people’s awareness, I guess. But using them on pages that are invalid, to me, is like saying you’re a badger, when you’re actually not.

Now with all the badges… Why don’t I ever see any WAI icons?

We spend a lot of time reading text on the internet. This is mainly read on our computer screens. But reading information on a computer screen is far less comfortable than reading it on the paper. Because of that I often print out some longer articles to read them. And I’m amazed by how little people take care of such readers. Most of the time I get a paper full of useless info and links, which I can’t click anyway (or at least clicking them won’t do anything).

Example - CNN.com is a decent news website. A random article on the site might look something like this. Quite ordinary, really. But try printing this article. Or better yet, click “print preview” to save precious paper. See how bad it is? It is full of information you don’t want. I’d rather copy the news text into a text editor and print it there.

Now try doing the same with this article on A List Apart. The printed page does indeed look like an extract from a newspaper or a magazine.

“How do I accomplish a proper printout then”, I hear you ask. There isn’t much to it really. When presenting content, a browser knows which media it is rendering for. For instance, when reading a page on our computer display, the media is “screen”. For printed pages, media would be “print”.

One can specify the correct media type for each stylesheet on the page. Therefore this would include all the rules to show on screen:

<link rel="stylesheet" href="style.css" type="text/css"
        media="screen" />

And this would do it for a printed page:

<link rel="stylesheet" href="style.css" type="text/css"
        media="print" />

Now, does that mean you must create two css files, one for screen and one for print? No. You can cover both by saying media="all". So what I usually do, I create a default stylesheet with media="all" and include another one for print just bellow it. In there I rewrite some rules, which should be special for a printed page.

Things to look for are:

Removing unneeded elements

Interactive elements such as menus, banners, form elements, etc. might be useful on your page, but are totally unneeded on a printed page. You can specify a display:none; for them in print css.

Units

Primary screen units are pixels. But what is a pixel on the paper? This depends on the DPI, but you probably don’t want people with better printers to read smaller font. So try using units such as points (pt), millimetres (mm) or inches (in). A good font size would probably be somewhere between 10pt and 12pt

Colors and contrasts

Keep in mind that not all people will print your site in colors. Do check how your text and graphics look in grayscale. Fonts are usually best if black.

Backgrounds

By default, most browsers won’t print background images. So make sure your content looks ok without them.

Page width

The paper’s width isn’t 1024px or 800px. It’s usually 210mm (8.27 inch) for A4 or 8.5 inch (215.9mm) for letter. But there are paper margins to consider. I think you’re best of by not specifying any width at all, or doing it in percents

CSS does include some special rules for paged media, but as you might have guessed, most of them don’t work well in today’s browsers. The two that do seem to work, are page-break-before:always and page-break-after:always rules. These two, applied to an html element force a page break before or after it. Might be useful in cases such as when you always want a title to always start on a new page.

Preparing your website to print well usually doesn’t take much time. Just make sure to cover the basic stuff and do some test prints (different browsers and different printers, if you can). Visitors won’t get too bothered if there’s an input or a button visible, but they might get annoyed if a navigation menu doubles the amount of pages printed.

I’m always happy to add another project to the portfolio. This time it’s Slovenski blogi, or “Slovenian blogs”. I don’t know how you call this type of a website… Blogosphere maybe. It’s a colletion of blogs by Slovene authors, but not necessarily in Slovene language. Most of them are, though. Babble.

I was asked by Robert to do a simple design for the page. He planned to keep at least the basic structure, and after seeing the old design, I decided to keep the color scheme as well ;) The main thing that bothered me with the old design was the complexity of it. It was full of features, but all of them were kind of hidden behind illogical icons (or at least they were to me). So I did my best to simplify it. In the good ol’ “what would Apple do to make it intuitive” spirit.

Robert was quite happy with my design and was quite eager to finish the redesign as soon as possible. I think he had had quite a few sleepless nights during the past 2 weeks, but by this morning, he was done and the site went live.

SloBlogi.net - Slovenski Blogi

I’m really happy with how the site turned out. I hope you like it. And sorry about the orange…

In the spirit of statistics class that started for me yesterday, I found some fresh browser statistics.

First thing to notice is how many people still use 800×600 resolution (8% of users) and how many tend not to maximize their browser windows (The author states 50%, but don’t take that too seriously). This is especially interesting because some people keep claiming how 1024×768 is a standard nowadays and how lower resolutions don’t matter any more. Well, think again. Myself, I’m using 1440×900, but usually keep my browser window under 1024px of width to save precious space for other windows.

Secondly and sadly, Internet Explorer 6 remains the most popular browser with 46% of user base. CSS nightmares anyone? Internet Explorer all together holds a terrifying 78%.

But take a look at the map of Europe. Slovenia still holds the first place in Firefox market share and we’re almost at 50%.

Conclusion? Not much has changed for web developers. 800×600 should still be considered a minimum and IE6 should still be our main priority when it comes to cross-browser compatibility. Except you only want Slovenian users, I guess…

Oh and… I’m quite proud of readers of this blog as well. 63% Firefox and only 26% of IE :) I’m sticking with Camino, though.

A few years ago, we used to lay out websites by using huge nested tables. Why? It worked. But then someone said, “hey, that’s old fashioned” and we replaced tables for div elements. And we mocked at anyone who was still using tables. But even then, people weren’t quite satisfied. Are nested divs really any different from nested tables? So we started to familiarise with other html elements, such as headings, paragraphs, ordered and unordered lists, … And this is good. It’s how the web was supposed to be in the first place. We should always use the appropriate tag for our content. Why? To help us understand our code better, to help search engines understand our content and to help people with disabilities read our website.

By people getting to know more and more html tags, I’m surprised by how little people have heard of definition lists. These act a bit like unordered lists, but can contain two different elements - definition term and definition description. Let me illustrate, using a definition list:

Definition list - DL

Represents a list of definitions, like a dictionary

Definition term - DT

Identifies a new term, a word in our little dictionary

Definition description - DD

Describes the given term

So obviously, definition lists are used for various forms of dictionaries. Also, as W3 states, they can be used to mark up dialogs, “with each DT naming a speaker, and each DD containing his or her words.”

I’m not sure this is 100% correct, but I like to use them for menus sometimes. Example - see left menu. One might think of these as headings, but why can’t they be definitions as well?

Also, I tend to use them for forms:

<dl>
    <dt>Username:</dt>
    <dd><input type="text" ... /></dd>

    <dt>Password:</dt>
    <dd><input type="password" ... /></dd>
</dl>

(For demonstration purposes I left out label tags, don’t try this at home)

So, almost anywhere where I encounter a list containing two types of data, I find definition list to be the appropriate tag. Both semantically and visually - you can style different types differently without using extra class names.