HTML and CSS Reference
In-Depth Information
You may be thinking that browsers seem to handle the markup
whether it's invalid or not, so why should you bother with writing valid
markup? The next section answers that question.
Validation and why you should bother
If browsers can cope just fine with invalid and even not-well-formed
markup—and not only that, different browsers manage to do a similar
job of rendering that invalid markup—why should you bother writing
valid markup in the first place? There are at least three good reasons,
as this section summarizes.
First, even though things look the same when they're this simple, dif-
ferences probably exist underneath. The earlier sidebar “Markup,
parsing, and rendering” distinguished between the markup in the text
file, the parsing of that markup into an internal structure by the
browser, and the final rendering of that internal structure on the
screen. In the screenshots at the end of the previous section, you saw
the final result of the invalid markup for this fragment:
<p><strong>A slightly <em>odd</strong> looking sentence</em></p>
Although it looked the same in all four browsers, here are the internal
trees they built.
Firefox and Chrome
Opera and IE
This example involves only three (or four) elements, and already there
are cross-browser differences. The more complex the page becomes,
the more likely invalid markup is to cause an oddity in rendering that's
hard to discover. This is especially true when
CSS
and JavaScript are
involved.
Moving on from this first point, browsers and other web tools are opti-
mized for valid markup. Invalid markup is always dealt with as an
