I’m not saying that XHTML is “the right way to go”. I’m more trying to emphasize that there are a multitude of reasons for picking one or the other. For myself, my own sense of internal consistency suggests XHTML.

Personally, at least when it comes to the <img> tag, I think that the tag itself is specified poorly. The img tag should be a container for an image: with an opening sequence and a closing sequence appropriately. Instead, it was created so the src is referenced as an attribute of the tag. That’s fair - it’s also a possibility with the <script> tag.

I consider the <br> tag to be anomalous: it doesn’t really fit with my conception of semantic code because it contains no meaning within the document at all. I do make use of it, but prefer to minimize that use when I can.

Thanks for your comments!

Yes, a paragraph, or a hyperlink or table cell or list item, has clearly defined content and so can sensibly be wrapped in “beginning” and “end” tags. That much makes sense.

But what about line breaks or images? These don’t have any content (in the main flow of the document) - you can’t put anything between the beginning and end tags! So why not be happy that these are spot tags that mark an instance rather than a section, and need no closing?

Moreover, I have tried using both before, but I found switching between the two made me think too much. Post-validation and I’d have to go back and fix XHTML boo-boos in HTML documents and vice-versa.

Been there…that definitely influences my decision a fair amount, as well. It’s simply much easier to do all my sites in ONE format - keeps the mind stiff and inflexible. ;)

My main reason to use the XHTML Strict DTD over HTML strict — which I do exclusively, even though I serve my documents as text/html — is that it puts me that much closer to the day when I change my site’s MIME types to a supported version of XML. Moreover, I have tried using both before, but I found switching between the two made me think too much. Post-validation and I’d have to go back and fix XHTML boo-boos in HTML documents and vice-versa.

Some would argue that this means all supposedly valid XHTML sites are actually invalid, because they are processed as broken HTML: I don’t agree, because I believe that the validity of code is inherent to the structure of the code, not to the rendering capabilities of the user agent. The fact that a user agent can’t accept my code doesn’t necessarily make my code invalid.

Also, since the browser reads your source as HTML, you can’t take advantage of many of the XHTML modular namespaces: MathML, XHTML-MP, or custom made namespaces. Since part of the whole point of using XHTML is the fact that it’s parsable in XML, NOT being able to use this XML spaces is a bit inconvenient.

The fact is, this downsides to serving as text/html are pretty esoteric - if you’ve written valid XHTML and served it as text/html AND tested your site thoroughly in a wide range of browsers, you’re just fine. If you want to add any extra functionality by adding additional XHTML modules, you’ll have to switch.

And, if you decide to switch to serving application/xhtml+XML at any point - you’ll have to check over your site again, very thoroughly, in all browsers, because the rendering is likely to change.

Well…that was practically a whole new post…

In order to actually deliver XHTML, the MIME type application/xhtml+XML or text/xml is required. Without this MIME type, the advantages of XHTML are irrelevant.

What advantages do you lose by serving it as text/html instead of application/xhtml+XML?