Thanks for your thoughts, I was evaluating to convert to XHTML, and you helped me making my decision

Stick to HTML.

Yes, this discussion never seems to go out of fashion. I wrote another post later on, HTML or XHTML?, that also might be of interest to you.

Sounds like a valid reason, if you want to put it through an XSLT. When it comes to ASP.NET and valid code, you can read my post How to generate valid XHTML with .NET.

No problem at all (at least not to me).
But thanks for trying to keep it at a reasonable level and as a balanced discussion, instead of flaming away.

I really appreciate serious discussions.

In re-reading my previous post I see that in my haste my comments could be inflamatory on a number of levels and to a plethora of people, so here are my apologies and restatements in a more civil manner.

First of all, I’ll retract my “no one’s mentioned this” claim. This concept WAS mentioned amongst the many people participating, pauldwaite most notably. He raised the point that XHTML pages are easier to deal with. I simply added an example of an internet app that takes advantage of XML now and applied it to XHTML sites in general.

Next, my final statement in the previous post could be interpreted as insulting to many individuals and I extend my most sincere apologies to anyone who may have interpreted my statement as an insult to any individual or collective peoples. If I could amend my final statement it would read…

RSS seems to be an intermediate step towards an XHTML-prevalent internet.

Better late than never.
To me, I see much easier re-using and parsing of the code if it’s valid, well-formed XHTML.

However, the world throws us obstacles all the time, like WYSIWYG tools, “features” in .NET etc.

But at least we need to have the ambition and vision to do it right and not give in.

Aggregators could determine the XPATH into each site’s article nodes and directly extract new content without the intermediate RSS step (which of course, generates XML!) Alternatively, XHTML web sites could publish in META tags the XPATH needed to extract article content from that specific site.

RSS seems to be a crutch for the XHTML-challenged.

Sounds like a good ambition!
Preferably, one would like to convince the customer that opening a new window isn’t a necessity.

However, if that fails, the solution you’re striving for should be a good alternative. A new window for those who use web browsers that support/have JavaScript activated, and just linking to the correct page for those who don’t.

Nah, I’m talking solely on finding an alternative to target="_blank", one that works without requiring that attribute, and one I can parse in- and out of documents easily.

A javascript approach would have the only downside that if javascript is disabled, the link opens in the current window. The target="_blank"-approach has a much bigger downside, in that IE-users can’t really do anything easily to make it NOT open in a new window. So if you want that link to open in your current window, you need to manually copy the shortcut and paste it into your address bar. That’s an accessibility issue for the vast majority of people, namely everyone that uses Internet Explorer and can see.

So, to cut my irrelevant rant short(er :/), my idea will most likely be a very accessible approach that allows the use of XHTML Strict.

I should write an article about it once doing it, and see if ALA / Sitepoint care to publish it

I don’t know what the JavaScript-approach will consist of (like using the rel-attribute and an onload script?), but if you require JavaScript of the user, won’t you, most likely, get accessibility issues then?

Hah, thanks! I’d have come here earlier if I hadn’t been so ridiculously behind on my weblogs. See, my CMS isn’t entirely finished yet, and right now, virtually all my time is spent on finishing it. It’s annoying, because it’s keeping me from being very up to date every so often, but ohwell. Eventually I’ll catch up (and get something more worthwhile done with my site, *mutters at self*)

Yeah, the Almost Standards Mode-aspect isn’t great, but sadly I have no way of working around it. I’m looking into using a Javascript-approach to work around it so that I can make all the sites XHTML Strict, but for the time being that’s not finished yet (and also, lower priority than finishing the missing features on the CMS itself…).

Good to see you here!

I agree with what you said and think it sounds good.
The only thing I have a problem with (although I understand the issue) is using the Transitional Doctype because of its Almost Standards Mode rendering in Firefox.

I’m not interested in having a heated debate where people fight for their particular standpoint. How do we make these two camps meet? Is it even possible? I want to reach a middle-ground, what’s acceptable, where can we set the bar so it suits the majority?

I’m not sure whether it’ll really work, but it’s my effort anyway: proving that creating True XHTML websites even for businesses doesn’t have to be a problem, as long as you use content-negotiation to serve non-conforming browsers normal HTML (whether you switch your markup around to be truly HTML with an HTML doctype or not is up to you).

My CMS is doing just that. Ensured well-formed, valid XHTML documents (Transitional sadly because customers still demand to use target=”_blank”), sent as application/xhtml+XML to all browsers that support it, and sent as text/html to those that don’t.

> This may be too optimistic, but maybe Microsoft will fix this and actually let IE7 display pages delivered in proper XML mime type and syntax in standards mode.

I do hope that happens. However, then we need to implement an extra check between IE 6 and IE 7 in all our solutions, to distinguish between them…

pauldwaite,

> Sorry, rambling. The basic point: XHTML is easier to deal with programmatically

I agree, and that’s one of the many reasons it’s appealing to me.