You have just finished your first website successfully validated with the online tool W3C (http://validator.w3.org/).

But hey! It doesn't work on all Navigators. Of course, everyone will tell you that an all XHTML and CSS website was the best way to have a maximum compatibility everywhere...

What's up with that? They all lied? Standards and norms would be a big joke?

Knowing the following three points will enable you to go on and to better understand the principles of strict use of the norms:

• A norm doesn't garantee compatibility
• Navigators have limitations on certain recommendations
• Tags have different by default padding and margins

A norm doesn't garantee compatibility

One of the advantages of having a normalised document is its compatibility with several platforms. Creating according to the recommendations allows your document to be multi-compatible, but also that it remains that way in the future. But...

... You can very well creat a perfect all XTMHL website and still have a senseless result. This is because the online validation tool you are using is not a magic wand: it will only verify that the syntax is correct and the tags clean.

But it cannot verify that you have indeed used the right tags at the right places. Nor to detect if your paragraph (<p>) is really a paragraph and not a title (<Hn>), and so on.

As an example, you may very well define a block with a 70,000px height. It's clean and valid, but still, it doesn't make sense.

Validating your website is the first good pit stop. but it's not enough.

There are other essential parameters, semantics for example and also accessibility validators that are good complements.

To finish, let's say that Norms garantee that you have a clean code, but it doesn't mean that your syntax is good.

Browsers bugs

There is another problem: all browsers are variable regarding their respect for norms. Certain browsers like Mozilla and other gecko-based (Netscape, Firebird, Firefox) respect the norms the best they can, but there are others like Internet Explorer that don't consider norms as priority and are often not very strict with standards applications.

There are differences that can be important because of certain browsers' bugs and that are not related with the language you use (this problem is the same no matter if you use XHTML/CSS or HTML 3.2 for example).

The most frequent difference is what is called "Microsoft Box Model": Internet Explorer will have its own interpretation for the boxes dimensions (that is by default blocks with padding and borders).

According to the standard model, the apparent width of a box will be logically equal to the sum of: the specified content width (CSS width property) plus the total width for its left and right padding plus total width of its left and right margins.

A box with a 250 pixels width, 20 pixel each paddings and 5 pixels each lateral borders will have a total width of: 250+20+20+5+5=300 pixels.

But the box model for Microsoft considers that padding and borders are within the content zone. The apparent width of a box will then be the specified width for the content only.

The precedent example's box will then have a width of only 250 pixels. Its content zone will be reduced by the total width of borders and padding, in this case by 50 pixels compared to the standard model.

The differences can be huge on the final document. More information on this common bug on Openweb: http://openweb.eu.org/articles/dimensions_boites_css/ (fr)

There is a large pannel of all the limitations of Internet Explorer on Fastclemmy's Website (fr)

Here is a complete table listing CSS properties and their eventual bugs on each of the Browsers: http://www.richinstyle.com/bugs/table.html [en]

There are several solutions to go around this problem:

• Don't specify a width for an element that has lateral padding or borders. Give external margins to these elements instead.
• Avoid specifying a height for an element that has vertical paddings or borders. Give external margins to these elements instead.
  As an example, your div must have a width of 15em, and you want to give it an internal space (padding-right) of 2em on the right. This will create problems of interpretation of the box. Avoid padding and specify a margin-right for the content of this block (paragraphs, other div, ...) or keep the padding but don't specify a width for the container div (you can specify its size by specifying its margins).
• It is possible to use hacks to trick IE (see links above).

Default margins and padding

Here again, browsers are all different and they don't always have a link with XHTML norms.

Each block tag has margins and padding by default that are read differently by each browser if they aren't explicitly defined.

The most common tag is <body>, but it's also the case for all the block tags: paragraph (<p>), citation (<blockquote>), form (<form>), list (<ul>, <li>), titles (<hx>), and more.
Except for <div> which is the only block tag that doesn't have padding and margins by default.

Take for example <body>. If you don't define its margins you will get a space at the top left of your site. These are the margins for the document and their size varies according to different navigators.

It's the same thing for the paragraph(<p>) tag which has a bottom margin by default, this is why it looks like you have an extra line between each paragraph, to the contrary of text separated by <br />. Suppressing the bottom margin would also suppress this "extra line" {margin-bottom:0}

These by default margins can create unforeseen positioning problems. A list (<ul>) won't be displayed on the same spot on IE or on Mozilla simply because of the margins by default around it.

The best way to be sure of your pages compatibility is to systematically define margins and padding for your elements, or to define them as null. if you think they might create positioning trouble.

Conclusion and solutions

Before accusing XHTML norms and W3C validator online, ask yourself if your syntax is correct and if your problem doesn't come from the limitis of certain browsers instead of XHTML language.