A client wants to implement some junkyard javascript code that has heaps of validation errors. I have explained that we can certainly do that but you need to be aware that it is full of XHTML errors.

Whats a convincing argument to get her to re-consider?

Put it in terms of money. Doing it right once is far cheaper than doing it over several times.

tim

^ good one.

Hello,

I've run into this issue before. Its extremely hard to educate the client about the validation process when they know nothing about the web and even less about computers. 'serandfae' had a very good idea. Best of luck.

If the code shows errors under different browser, you'll need to let them know about it. Either open it live in front of them, or use browsershots.org for some screenshots.

Point him to a url that explains with XHTML is better than garbled non compliant code.. hopefully once he understands why its better he can get off your back lol

If you put your inline JavaScript (in an XHTML document) within

<script type="text/javascript">
//<![CDATA[

//]]>
</script>

tags, it will validate every time. Likely, the validator sees "html" elements inside of the script where they don't belong, and is choking on them. <![CDATA[ within an XML document (which an XHTML document technically is) is a way of indicating it is general character data.

The problem is not the script, it is just the way XHTML is validated.

Exactly. The next question is what is this script doing ?? Can you find an AJAX alternative that's unobtrusive ?

At the risk of Lady's wrath, no poster has yet answered the quuestion why it makes a tinker's d*** to the real world.

I go for it but I am not obsesive compulsive that it has to be that way as long as the page renders in IE and FF.

I have my thick skin on, go ahead.

I tend to agree, it doesn't make a real difference in reality, and browsers are not slowed down or compromised in any way just because of validation errors (unless they're pointing out real mistakes in your coding).

The main reason I clean up errors like this, is that it makes debugging easier later on, if say, I miss closing a tag, or something thereabouts. Having tons of errors on the page makes it much harder to find mistakes that you need the validation to find for you.

This doesn't mean I support using deprecated tags or attributes, because I generally don't (I do sometimes put target="_blank" on <a> tags).

I've read that many hand held devices view xhtml compliant sites much better than sloppy coded sites. And, due to their popularity, the use of these devices will only increase from this day forward.
So, I ask the client: Do you want a current and future compliant website accessable to everyone?

The other thing you can do is find some really poorly coded sites (with navigation buttons that go nowhere, text runs right off the screen, etc.) and then validate those site's coding. Most likely they will have 60 or more errors that you can show your clients. Those sites become your case in point for using validated code.

Now if there only was a validating service for your clients last car repair?...
"Your last repair had contained 47 mistakes."
I'm sure they'd rather have "0" even though the car was 'working' properly.