XHTML and its value

The
problem I ran into the other day is that .NET doesn’t generate valid
XHTML. There exists a number of hacks to get around this, and then one
can set what HTML is delivered to different web browsers (basically, high-level HTML to Internet Explorer and old HTML to all other web browsers).
The version of HTML/XHTML being rendered is however customizable in Visual Studio 2005.

Naturally, one wants to write valid code that validates
with its DOCTYPE. However, a colleague of mine recently asked a very
good question, whether there’s any relation between if the page
validates and if it’s being rendered correctly. And basically, the
answer is no.
Of course,
if you have som major erros in your code it won’t look ok, in those
cases the validation can be a hint how to solve the problem.

But
in the big picture it made me wonder if we’re just chasing valid pages
just for the sake of it, not for the ultimate purpose: that it looks
and works the same in all web browsers and behaves consistenly. In the
case of major errors, they should be removed, but if the FORM element
has an extra, invalid, NAME attribute or not doesn’t really matter.

I’m starting to wonder if W3C have gone overboard with the recommendations,
that they’re not alwaws justified. I mean, they’ve given up on the
fabulous IFRAME element to give room for using the OBJECT tag and
setting parameters for it.
This
is, of course, not properly supported by Internet Explorer, so I guess
we can estimate about five years (at least) before we can use that.

Principally,
it’s then impossible to have valid XHTML Strict and IFRAME
functionality and to target all major web browsers, but of course it
works in all of them.
What’s the point of being valid then?

Leave a Reply

Your email address will not be published. Required fields are marked *