One Respo [...]

Well, its’ ok; I rather think this was the place to post such a comment.

Regarding serving XHTML 1.0 as text/html or application/xhtml+XML, I can live with that. But I have to say it’s disappointing to see so many using the Transitional doctype.

A little disappointing?

[...]

That was an interesting approach! Me myself I’m not sure if the users should/are capable of making that decision or not. Many users just get scared away by messages about errors that require of them to make a call about what to do next.

Thanks for the tip about the XML check class!

This way, it would allow the user to get to the information if it is important, but also make it clear something is not as it should be, thereby not promoting/allowing bad markup (IE. like HTML did).

Checking X(HT)ML for well-formedness on the server side is possible using PHP. I am currently writing it into my upcoming site. The XML check class at this site is useful, especially combined with the output control system in PHP, by using the callback function. It would allow you to check the markup before sending it out, and if there is a problem, you can send out a different friendly error page to the user (without well-formedness errors if this page is in XHTML too….!!).

Yes, built-in validation in the server-side languages would be a nice thing. Of course you can build it yourself, load the output into some XML object etc, but I for one would like it as an easier feature to use.

I think the browser should display an error message if the XHTML isn’t valid. The cryptical part of the error message would probably be “Unexpected element X found …” or some other common validation error message. It would be nice if the main part of the error message was easily understood by all users. The user should also be told what he/she should do to get back to where he/she came from.

I don’t think the browser should have to guess what the content of the invalid XHTML actually should have been.

One thing I really would like is a better XHTML validation support in server side scripting languages (eg JSP). The XHTML produced by the scripting language should automatically be validated while it is beeing generated and if the validation process finds an error the user should be redirected to my JSP error handling page where I, as a programmer, get the chance to find out about the error and can choose what to display for the user. If I am unable to output valid XHTML even on the error handling page, I suck. It might sometimes be a good idea to output HTML instead of XHTML on the error handling page.

If you have to deal with other people’s bad code, then XHTML is simply the wrong tool for the job.

Yes and no. For me, to write valid code and then present the flaws to the people responsible also helps me in pushing them toward demanding more from their tools and the content providers.

I’m not sure an error parser would be the best thing, I don’t know which approach would be the best. Hence the discussion.
But, as Chris mentions about Opera (I haven’t tested this myself), to show the error below while still displaying the web page sounds like a much better approach to me.

Chris,

Typos fixed, thank you. However, I’m not sure about what case errors you refer to?

bodaniel,

For a parser to go through valid XHTML, it should, theoratically, be faster than looking for optional tags.
But then we come back to those cases where the code isn’t valid, and how the web browsers should handle that…

I thought XHTML was the next step towards fast rendering browsers, that shouldn’t have to guess what your messy HTML actually tries to say? If the browser has to fix every error in the XHTML document you would also need recommendations telling how errors in XHTML documents should be handled. Try to think of all possible errors that can occur and what the error handling code would look like. What should the browser do if it is within an ordered list and finds the end of a heading?

But an XHTML document is static. It is not executed and modified in real-time, so there is no need for runtime exception handling.

Not quite. A document can be altered many times after loading by JavaScript. A single error there may render a valid document invalid. Also the content of a frame might be refreshed, bringing new and possibly invalid code into the page. XHTML documents are, like HTML ones, dynamic.

This post interests me because I have just made a round of XML tests (see XML Browser Differences). I’m delighted to say that an error in an XHTML page only gives a blank yellow screen in one browser - Firefox. In Opera the document is parsed and displayed! (The error message appears underneath.)

What’s more, IE6 also does the same, that is for XML documents. I was very surprised by this. Good news for the user, unless they use Firefox!

In my opinion, the browser should attempt to recover the document as far as possible, so at least something is displayed. After all, a single fault is not likely to affect the rest of the content enough to warrant not showing any of it at all. (Or perhaps I’m wrong in certain cases.) XHTML should therefore be no different than HTML. Browsers are now very good at fixing bad markup. Of course then we’re left with the argument about encouraging such markup by the browser fixing errors.

By the way, you might want to fix those typo and case errors in the main post…

> It’s the strictness of the syntax that promotes best practices tons better, not the actual tags/elements.

> But HTML doesn’t enforce you in any way to apply best practices to your code, whereas XHTML does.

Which best practices are enforced/promoted by XHTML served as text/html?

> Nobody on the planet ever learned how to do XHTML right in one go. Neither did you. We all need to take things one step at a time, in this case that means learning XHTML one step at a time. You can’t go expecting people to switch from old school, nested table-ridden, font tag-polluted HTML to clean, semantic, well-formed XHTML in one go. But that’s exactly what you’re saying, and that’s very elitist of you.

Don’t put words in my mouth.

If you have old-school, nested table-ridden, font tag-polluted HTML, then there are many intermediate steps you can take without switching to XHTML that will improve the quality of your code.

You don’t have to switch to XHTML. For the people who can’t do XHTML right, there are no benefits. If you switch to XHTML for the sake of “clean code” or “best practices”, and you start writing invalid XHTML, then you’ve taken a step backwards, not forwards. Pointing this out isn’t elitist, it’s using common sense.

XHTML isn’t a club all the smart people join, it’s a tool. What I am saying is that you should use the right tool for the job. For people who cannot do XHTML correctly, XHTML is the wrong tool for the job and HTML 4.01 is the right tool for the job. How on earth is that elitist?

> Keeping them at HTML will keep them away from promoting best practices effectively

How? Does HTML prevent them from writing valid code? No. Does HTML prevent them from using CSS for layout? No. Does HTML prevent them from writing accessible pages? No. HTML is not incompatible with and doesn’t discourage best practices.

Robert,

> But to be clear, my scenario is often that I write and deliver valid code. Enter .NET-based CMS systems, third party content providers and other web developers/administrators that don’t have the knowledge (or even interest) to do that.

If you have to deal with other people’s bad code, then XHTML is simply the wrong tool for the job.

Jeroen,

> I cannot get it into my head why anyone would want to enforce such a strict error handling.

Because web authors broke Postel’s Law. Because developers of authoring tools broke Postel’s Law. Postel’s Law only holds up when both parties respect it.

Robert,

> I think it’s a huge difference. In those scenarios where the errors you mention occur, you (should) have proper error handling to show it gracefully to the end user. With application/xhtml+XML we don’t get that option.

We don’t get that option with JPEGs, GIFs, PNGs, MPEGs, or pretty much any other media type that is directly presented to the end-user without opportunity to catch errors. Nobody’s asked for a JPEG parser that can automatically recover from corrupt images.

Thanks for the suggestions!

That was at least five cents (as opposed to the normal two).

I think (read:hope) my reasons for using XHTML has been declared above and in Ben’s post.

But sure, of course you’re right in one sense: there’s always people who jump on the bandwagon without knowing (or even caring) about the consequences.

Personally, I think everyone should go with what feels best for them, be it XHTML or HTML. But I do recommend using a strict doctype no matter what your choice is.

Seriously, how many of you aren’t using XHTML - just because of the `cool` little X in front, or maybe because it’s required to end elements without end-tags?

If you’re not in the section above, you probably like the `strictness` which XHTML gives you.
Well then, why not just use a stricter DTD of HTML 4.01?

I for my sake at least don’t understand why someone would go through the haze of content-neogation, just to get an error-handler which destroys the site if containing errors.

I used XHTML before. But at the same time I like to give my commentators full HTML possibilities.
And when someone with too little HTML experience came in and wrote a comment, the whole site crashed.
I would much more like to have a non-valid HTML document, than having a XHTML document that won’t display because it contain errors.

So my five cent: If you don’t have any need for XHTML in form of MathML etc..: Don’t use it