Web server

[Scott van Looy]

Today Tim did spake thusly:

> 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.

It's not. You can mix tags up in HTML4, even though it's not recommended, 
whereas in XHTML they have to nest correctly.

>>>  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.

Not at all. If you type in the correct doctype they switch from quirks 
mode to standards compliance mode. IE6 is fussy and so will stay in quirks 
mode if anything appears above the doctype (spaces, carriage returns, the 
XML declaration, anything) so you need to watch for that, but that's all

>
>>> 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.

In which case not a single modern browser behaves correctly, which I find 
unlikely ;)

>>> 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.

That's always been the behaviour of browsers, it's wrong but all of them 
do it

>>> 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.

Do too :P

> 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.

You can write perfectly valid HTML4 that renders entirely differently in 
FF IE and Safari. It's only in standards compliance mode using XHTML that 
they start to actually correctly render pages. FF is broken in bits, IE is 
broken in other bits and so is Safari. Not a single one of them actually 
adheres correctly to the standard.

>
> Conversely, correctly written and served XHTML can't even be read by
> over 60% of the browsers.

84% (IE)

-- 
Scott van Looy - email:me at ethosuk.org.uk | web:www.ethosuk.org.uk
site:www.freakcity.net - the in place for outcasts since 2003
PGP Fingerprint: 7180 5543 C6C4 747B 7E74  802C 7CF9 E526 44D9 D4A7
       -------------------------------------------
       |/// /// /// /// WIDE LOAD /// /// /// ///|
       -------------------------------------------

Use the Force, Luke.