xhtml Validation Errors

[Big Bill]

Well that's not really true... carefully used XHTML works fine in IE, even
with the correcty doctypes. There are only a few specific things that it
chokes on, which can be avoided (same goes for CSS in IE, and nobody bitches
about that these days). Our last two sites were completely XHTML (more
logical), and worked fine across all the browsers we test with (IE, Mozilla,
FireFox, Opera - on PCs, Mac and Linux).

But what's the point in doing it in XHTML when HTML will do just as
well without any potential complications?
Oh yes, while I remember, are you saying that table cell width and
height can be done in CSS and IE gets it now? I've been reading the
CSS in 24 hours book and in that it says it can't (if I understand it
properly, he said cautiously).

BB

 

[Big Bill]

Which is what I said. You just said it a little more tactfully....

That's thoughtful of you but I've long since been reconciled to the
ugly truth that it's only through criticism that you learn.

BB

 

[Big Bill]

No, XHTML deliberately sent as ordinary HTML works fine in IE but not
because IE is able to handle XHTML.

If IE receives a .html extension and a text/html content type from the
server it just interprets the page as HTML4. Then it comes across
trailing slashes in IMG and INPUT tags, and sees these as errors. Its
error-correction code just gets it past these syntax errors (which they
indeed are since the text/html page is being parsed as HTML just as you
asked) and it continues rendering the rest of the page.

Try making a *real* XHTML1.1 page and send it out with the content type
you're supposed to and see how far IE gets.

My first play with XHTML was a few years ago. Everything was fine when
loading off disk but imagine my surprise when I uploaded it all and
tried loading it over the web. Opera ignored half of the CSS, Mozilla
ground to a halt and soaked up 100% CPU until I killed it and IE couldn't
get past the DTD. These were in the days of IE5 and I understand that
someone at the W3C informed MS about the problem. About a year passed
and IE6 came out with exactly the same problem.

And the moral of the story: We all still use plain HTML, even if we fool
ourselves that we've attained enlightenment and mark up in XHTML because
at the end of the day the browsers we're sending the pages to are parsing
them as HTML. HTML with syntax errors in it, despite what the validator
says. Regardless of how well current versions of Mozilla and Opera handle
real XHTML those browsers are totally irrelevant since IE users outnumber
them almost 20:1.

A survey published this month gives 68.1% of the market to IE6, loads
of the rest to IE5 and 4, and 1.8% to Mozilla. So unless AOL manages
to give Netscape the kiss of life It's M'soft we have to concern
ourselves with.

BB

 

[Whitecrest]

But what's the point in doing it in XHTML when HTML will do just as
well without any potential complications?

Currently the truth of the matter is, today there is no advantage,
possibly, a little disadvantage to making your site XHTML. In a few
years when all the browsers support it, and CSS correctly (cough cough)
you can say,

"Ha! I prepared and did not have to change my site!"

But since most sites require regular maintenance and updating anyway,
you really don't lose out there either...

 

[Whitecrest]

A survey published this month gives 68.1% of the market to IE6, loads
of the rest to IE5 and 4, and 1.8% to Mozilla. So unless AOL manages
to give Netscape the kiss of life It's M'soft we have to concern
ourselves with.

That sounds a little suspicious to me. We estimate (depending on the
content of the site) 80% - 90% of the browsers are IE, and the rest are
"something else" We always test in Mozilla and IE because they are the
only ones that support live connect, and test on Safari and Opera when
the job requires. (Which interestingly enough is about 10% of the time)

 

[Neal]

Contrary to popular belief it's not against the law to send XHTML as
text/html.

It's also totally legal for a man to wear a bra. If you must serve it as
text.html where's the benefit/purpose in using XHTML?

 

[GD]

Be careful to clean the sand out of your ears when you both to pull your
head out of that hole

You seem to have your head in a hole with regard to my post since you've
haven't responded to a single point in it. I assume you concede that
genune XHTML doesn't work in IE and is not fit for use on the Web.

Those who use it are fooling themselves that they're some kind of elite
developer. In truth, the doctypes people use has become a fashion and
the authors fashion victims.

Can you disprove my claim that XHTML sent *as* XHTML doesn't work in IE
and it therefore merely parses it as HTML, encountering unnecessary
syntax errors (which it deals with adequately) in the process?

To reiterate, Even with an XHTML doctype and syntax, most people are
still producing HTML4 pages as far as the browsers are concerned, and
there are no future-proofing issues if you use valid and sensible HTML 4
and CSS that doesn't depend on any particular browsers quirks or bugs in
order to render coherently.

Browsers (and whatever they evolve into) will still happily deal with
ordinary HTML for many years to come and render them well.

At the moment, the closest thing to a real reason to use XHTML is to
trigger Mozilla's higher standards mode, though its almost-standards-
mode is fine for me and that is triggered with HTML4 strict.

And given that I've been using CSS in favour of table layouts and font
tags for over 4 years, I do not think I'm a luddite with my head buried
in the sand. Perhaps the blinkers you appear to be wearing are obscuring
the view of me with my ear to the ground?

 

[Toby A Inkster]

It's also totally legal for a man to wear a bra. If you must serve it as
text.html where's the benefit/purpose in using XHTML?

1. I can use XML tools to process it on the server.

2. For browsers with proper XHTML or XML support, I can send it with an
XHTML or XML MIME type by peeking at the browser's HTTP Accept header.

 

[GD]

Contrary to popular belief it's not against the law to send XHTML as
text/html.

That will cause IE to parse it as HTML, not XHTML. You seem to have
taken what I said out of context.

My point was that if the markup is XHTML then it should be parsed as
XHTML unless the browser is incapable of doing so. IE is one such
browser, and it parses it as HTML, interpreting the XHTML syntax as
errors which it then works around. I don't care if you send it as
text/plain, my point was that most people are really making HTML 4 pages
with syntax errors the validator doesn't show (because they validate to
the XHTML DTD). Most users' browsers do not interpret these pages as
XHTML and the authors use tricks in order to fool themselves.

Since you've focused on content types, why *not* send an XHTML content
type with your XHTML pages? Why don't business websites use one when
viewing their source shows XHTML markup? I don't care if they are
allowed to use either, I want to know why they chose not to use an XHTML
content type, especially as the W3C seems to dissuade people from using
text/html, especially in XHTML 1.1 onward.

 

[SpaceGirl]

You seem to have your head in a hole with regard to my post since you've
haven't responded to a single point in it. I assume you concede that
genune XHTML doesn't work in IE and is not fit for use on the Web.

Those who use it are fooling themselves that they're some kind of elite
developer. In truth, the doctypes people use has become a fashion and
the authors fashion victims.

Can you disprove my claim that XHTML sent *as* XHTML doesn't work in IE
and it therefore merely parses it as HTML, encountering unnecessary
syntax errors (which it deals with adequately) in the process?

To reiterate, Even with an XHTML doctype and syntax, most people are
still producing HTML4 pages as far as the browsers are concerned, and
there are no future-proofing issues if you use valid and sensible HTML 4
and CSS that doesn't depend on any particular browsers quirks or bugs in
order to render coherently.

Browsers (and whatever they evolve into) will still happily deal with
ordinary HTML for many years to come and render them well.

At the moment, the closest thing to a real reason to use XHTML is to
trigger Mozilla's higher standards mode, though its almost-standards-
mode is fine for me and that is triggered with HTML4 strict.

And given that I've been using CSS in favour of table layouts and font
tags for over 4 years, I do not think I'm a luddite with my head buried
in the sand. Perhaps the blinkers you appear to be wearing are obscuring
the view of me with my ear to the ground?

Blah. So why not adopt markup that does work pretty much everywhere, but
also lends itself for a more structured approach and hopefully better
rendering in more modern & future browsers? Not as if XHTML is hard work you
know...

 

[Toby A Inkster]

Oh yes, while I remember, are you saying that table cell width and
height can be done in CSS and IE gets it now?

Can't be done in HTML 4.01 Strict either, so what does this have to do
with the HTML vs XHTML debate?

 

[SpaceGirl]

But what's the point in doing it in XHTML when HTML will do just as
well without any potential complications?
Oh yes, while I remember, are you saying that table cell width and
height can be done in CSS and IE gets it now? I've been reading the
CSS in 24 hours book and in that it says it can't (if I understand it
properly, he said cautiously).

BB

These "complications" have yet to rear their heads in any of the sites we've
done. We'd rather be geared up for when the technology is more widely spread
seeing as it does no real damage to use it now. At some point you will
*have* to switch, so why not do it now when there's no rush, and no client
beating on the door screaming because their site mis-renders in Mozilla 2.0.

 

[GD]

Blah.

So far you've made 2 responses to all the points I made and not a single
word has been a meaningful reply. See what I mean about fashion victims
using XHTML blindly and being totally unable to articulate the reasons
why they do it?

So why not adopt markup that does work pretty much everywhere,
but also lends itself for a more structured approach

We already do. What you're describing is HTML4 strict and CSS2, which is
precisely what most browsers (IE) interpret every time they receive a
XHTML file with a text/html content type.

and hopefully better
rendering in more modern & future browsers?

Better in what way? Modern browsers get the box model and other quirks
right now. What is it that future browsers are going to do which causes
them to render so much better from the current versions of Mozilla,
Opera and IE? HTML4 will still be HTML4 in years from now, but the same
is true of XHTML1. Do you not see that?

If you write HTML4 today then it won't be XHTML1 tomorrow, but the
XHTML1 you write today won't be XHTML2 tomorrow either.

Future browsers are not going to stop working with HTML4 and CSS2. Do
you have any problems with Analog's HTML2.0 reports in Mozilla 1.6?

Not as if XHTML is hard work you know...

No, but why is that a key factor in deciding which markup to use? Just
because it's not hard work, does that make it any less true that XHTML
doesn't work on the web, largely because IE can't handle it yet?

Most of the XHTML flag waivers seem to have a lot of their arguments
based on FUD rather than fact or common sense.

 

[SpaceGirl]

So far you've made 2 responses to all the points I made and not a single
word has been a meaningful reply. See what I mean about fashion victims
using XHTML blindly and being totally unable to articulate the reasons
why they do it?

I have the flu. I dont feel to much like explaining everything

We already do. What you're describing is HTML4 strict and CSS2, which is
precisely what most browsers (IE) interpret every time they receive a
XHTML file with a text/html content type.

Until when...

Better in what way? Modern browsers get the box model and other quirks
right now. What is it that future browsers are going to do which causes
them to render so much better from the current versions of Mozilla,
Opera and IE? HTML4 will still be HTML4 in years from now, but the same
is true of XHTML1. Do you not see that?

Well, easier code to read, better structure for a start.

If you write HTML4 today then it won't be XHTML1 tomorrow, but the
XHTML1 you write today won't be XHTML2 tomorrow either.
??

Future browsers are not going to stop working with HTML4 and CSS2. Do
you have any problems with Analog's HTML2.0 reports in Mozilla 1.6?


No, but why is that a key factor in deciding which markup to use? Just
because it's not hard work, does that make it any less true that XHTML
doesn't work on the web, largely because IE can't handle it yet?

Most of the XHTML flag waivers seem to have a lot of their arguments
based on FUD rather than fact or common sense.

Based on "why no write something that is better structured, and will work
anyway". I don't think there are any really tangible benefits for writing
XHTML over HTML, other than it forces you to work in a more structured
manner (which will be adopted by 'whatever comes next'). That's a good
enough reason.

 

[GD]

Well, easier code to read, better structure for a start.

How is XHTML1+CSS easier to code, read or structure than HTML4
strict+CSS?

??

What I'm saying is that XHTML1 isn't any more future proofed than HTML4
strict. Future browsers are not going to change the way they understand
the set of elements and attributes we know as HTML4.

I don't think there are any really tangible benefits for writing
XHTML over HTML, other than it forces you to work in a more structured
manner

It's always good to put more effort into your work and produce
structured, well-formed markup, but that has been true since the
original HTML. It is human nature that has lead to people ommiting
closing tags and wrapping blocks in font tags etc, but as I have said,
there is no advantage of well-formed XHTML and well-formed HTML4 strict
or even ISO HTML.

The only differences arise when you try and present XHTML to browsers
and they can't render it properly, whereas they can HTML4 - which is
exactly what most browsers think they're looking at when you give them a
XHTML document sent as text/html.

How many XHTML advocates have pages online using
<script type="text/javascript" src="file.js" />

If as many browsers had problems with shorthand on IMG tags when they
parse XHTML as plain HTML it would be far less fashionable to use XHTML,
but I suppose a script tag is burried in the san-- I mean HEAD where
no one can see the problem.

 

[Toby A Inkster]

Since you've focused on content types, why *not* send an XHTML content
type with your XHTML pages?

text/html *is* an XHTML content type.

Unless we're being pedantic.

If we're being pedantic, then HTML 4.01 must not be served as text/html.
The IETF (the Internet's official standards setting body, who govern the
registration of content types) has only sanctioned the use of that content
type for HTML 2.0 (as per RFC 1866) plus a few i18n extensions (RFC 2070).
Other RFCs alluding to newer versions of HTML and XHTML are only
informational, so don't define standards.

So if we're being pedantic, then you can only choose between 'text/xml',
'application/xhtml+xml' and 'application/xml' for XHTML documents. And for
HTML 3.x and 4.x you'd have to use something like 'text/x-w3c-html'.

 

[Toby A Inkster]

We already do. What you're describing is HTML4 strict and CSS2, which is
precisely what most browsers (IE) interpret every time they receive a
XHTML file with a text/html content type.

Don't try to rationalise IE's limited support for XHTML that way. When IE
sees *anything* served with "Content-Type:text/html" it interprets it as
"Content-Type:tag/soup" and uses smoke and mirrors to render the page --
this takes place whether you use HTML 4.01, XHTML 1.1 or your own custom
doctype.

 

[Big Bill]

Can't be done in HTML 4.01 Strict either, so what does this have to do
with the HTML vs XHTML debate?

Have not tables always been a hack?

BB

 

[Big Bill]

1. I can use XML tools to process it on the server.

2. For browsers with proper XHTML or XML support, I can send it with an
XHTML or XML MIME type by peeking at the browser's HTTP Accept header.

and if it's a bog-simple handful of pages advertising a few villas in
Spain? You really need to get all James Bondy about this? Are you
designing with your client's needs in mind, or are you designing to
stroke your ego?

BB

 

[Big Bill]

www.luxuryvillasspain.co.uk/

Fool that I am, should be only one "s". Doh! Just clocked it.

BB