Tim: >> XHTML has to be served as if it were HTML, for the most prolific web >> browser in the world to render it. If served as XHTML, it will only >> download it. What's the point of writing XHTML pretending that it's >> HTML? Scott van Looy: > It's a better structure. Makes one more diciplined. It's just not the best > thing to learn from scratch. It's the same structure. The main difference being that you do write in the previously optional closing tags. And that's always been a recommendation with HTML, anyway. There's been quite a few browsers which make mistakes when you didn't explictly type in the closing tags. >> And doing so brings in other strange compatibility issues (MSIE's >> quirks/not-quirks modes are bad enough, already, likewise for other >> browsers playing similar silly tricks). > Not at all. If you add a doctype then your document is rendered in > standards compliance mode. There's more to it than that. Depending on how you typed in the doctype, browsers would behave variously, in manners that they shouldn't do. >> XHTML isn't html HTML. There are other clients which don't handle >> XHTML, and throwing XHTML at them means they'll interpret it >> differently, according to the rules of HTML. That extra slash, added to >> non-empty elements, actually has another meaning. > Doesn't Fraid so, and it's nothing to do with Netscape, it's the rules of HTML, itself. >> e.g. XHTML <br/> is NOT the same as HTML <br>, it's really <br>> (a line >> break element, followed by a greater-than sign that should be visibly >> rendered). > In Netscape 4. Perhaps. It's why if you wish for compatibility you write > it as <br /> Same problem (even with the space). The slash has a special meaning, there. Both <br/> or <br /> are actually <br>> in "HTML". And HTML client that renders is like that is behaving correctly, any that doesn't, isn't. >> The original idea of XHTML would be that you (the author) either get it >> right, or the browser refuses to display it. At long last, we'd be rid >> of crap web sites, because the author would immediately see that they'd >> cocked it up. But, no. We're back to square one with browsers still >> doing the tag soup analysis of XHTML/HTML, so we've lost that benefit. >> They'll keep on producing crap. > Unless you use a doctype, in which case it's all fine. Keep watching. If, and when, Microsoft decides to make MSIE render XHTML served as XHTML (i.e. with the right MIME type, etc.), it won't be long before they make the browser always try and render an XHTML page, no matter how broken it is. >> As it stands, XHTML is a waste of time, and a new set of problems. > Not at all. If you create well formed XHTML you can be reasonably sure > that all browsers will display it pretty much the same. If you create tag > soup then you're stuck with quirks mode in IE6+ and Firefox/Mozilla and > then you have to write specific CSS for each of them, which is vile. The non-use of XHTML doesn't automatically mean that you create tag-soup HTML. We've had validators and other error checkers for years, but authors don't make use of them. Well formed HTML does *exactly* the same job as well formed XHTML does. XHTML is not the magic fix people vaunt it to be. Nor will it ever be until Microsoft gets their head kicked in. Conversely, correctly written and served XHTML can't even be read by over 60% of the browsers. -- (This box runs FC6, my others run FC4 & FC5, in case that's important to the thread.) Don't send private replies to my address, the mailbox is ignored. I read messages from the public lists.
