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.

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.

I’m impressed by how many developers still haven’t learnt to use labels in their pages. I mean, how hard can it be?

What are labels anyway, I hear you ask. Label is an HTML element, which describes an input field. Let me demonstrate:
<label for="uname">Username:</label> <input id="uname" type="text" />
Here I establish two elements. An input field, which doesn’t say much on its own and a label, which tells us what this input is for. The for attribute of the label matches the id of an input field. One can also put the input directly into the label…
<label>Username: <input type="text" /></label>
Which I prefer, due to the fact it’s shorter. Labels can be assigned to just about any form field. They are “text level” elements and can be styled with css.

So why should you use labels? There are various reasons, which you probably don’t really care about, like semantic coding, browsers being able to visually match the label and the element (although this is your job) and offering help to people using screen readers to help them see. But here’s one that should change your mind - Allowing users to click on the label to focus the input field. As an example, take all those “I agree to …” checkboxes. Isn’t it lovely how you can just click the text in order to check that checkbox? This works in all modern browsers that I know of. Mind you, that I don’t consider Internet Explorer 6 to be a modern browser, though.

To all those who still have no clue what I’m on about, try this demo.

For better understanding, I split this post into three parts. The first one may be skipped by experienced web developers.

Some basic XHTML tag-closing theory
In HTML, tags needn’t be closed. So this is correct:

<ul>
    <li>Item 1
    <li>Item 2
</ul>

But with XHTML, we have to respect the strict XML standards, meaning each and every tag has to be closed. A bit more code is needed.

<ul>
    <li>Item 1</li>
    <li>Item 2</li>
</ul>

Also, we have to take care of tags with no closing tag, such as <br>:
<br> is wrong, while <br /> is correct.

This way XML parsers can read our HTML code. And what’s more, the code is much easier to read and understand by human beings, such as ourselves. If done correctly it doesn’t affect the way our code is rendered.

Can every tag be self-closing?
According to W3, every tag can be self-closing, therefore <div /> is a valid piece of XHTML code. But can we use this in the real world?

Self-closing tags demo

As you can see in the demo, browsers get confused by self-closing tags. They treat them as if we never closed them. You can try navigating the HTML structure with the Firebug extension for Firefox, to see how confused they really get.

I’ve tested this with IE7, Opera 9.2, Safari 3, Firefox 2 and Konqueror 3.9. All produced the same results.

Conclusion?
Do self-close tags with no closing tag, such as br, hr, img, link, base or meta. For example, <br></br> is not valid. But don’t do it to tags that do not expect that. It may be valid, but you won’t like the result. Just do <a name="anchor"></a> or such.

About a year ago I was asked to make a website for a primary school. No money was involved in the project, but I did my best to come up with a cute design. So this is what I showed them: OŠ Valentina Vodnika, as I saw it

I was quite happy with the design and so were the school guys… for a while. They did use my htmls and I explained a few things to them on how to add new content. So they learned some html basics. And since the design was very dull and given the fact this is a primary school, they decided to liven it up. So they got rid of the plain white background and added butterflies to it. And of course, the design itself needed more color. Red maybe.. and blue and another shade of green. But still the design was so static. So why not add some animation? Of course! And some caps to make the important data stand out more. And that green boy on green background… What’s that all about? Let’s just put something more interesting there. So that was the looks, but they had more up their sleeve. They played with the navigation, making it more dynamic. And the final touch, the most important of them all, oh yes, the counter. Voila. Much better. So here’s the result: OŠ Valentina Vodnika, v2.0, the lively version.

I didn’t take the time to congratulate them yet, but I did change the link in the portfolio, for I don’t like taking credit for someone else’s work.