[thelist] XHTML or HTML WAS Good Examples of XHTML Usage

Ian Hickson ian at hixie.ch
Mon Sep 8 14:16:00 CDT 2003


TjL wrote:
>>> How about restating this better... show me a real "in the wild"
>>> example of an XHTML file sent as HTML that causes a browser to
>>> fail.
>>
>> This is a strawman argument. I never said that sending XHTML as
>> HTML (assuming it complies with XHTML 1.0 Appendix C guidelines)
>> would cause Tag Soup ("HTML") renderers to fail.
>
> and I didn't say you did. I was raising a new point that in the wild
> this has no real side effects on actual browsers.

Ah, my bad. I was confused because you said you were "restating" your
question, which you had stated in the context of my previous comment.

In the real world, there are no XHTML files sent as HTML that fail
when sent as HTML for the same reason that there are no HTML files
sent as HTML that fail. People would fix them.

I don't really understand what that proves.


> Arguing about theoretical problems assumes things are going to get
> more strict in the future. I don't think they are. I believe an UAs
> are going to have to get more adept at deaing with problems.

For text/html, I imagine there will be very little change from the
current behaviour. For application/xhtml+xml, browsers will simply
refuse to render mal-formed content, since the specification requires
this behaviour.


>> If all you are going to do is rely on the UAs' error handling code,
>> why bother trying to make your markup valid at all? Just write pure
>> Tag Soup and be done with it.
>
> because I prefer to try to write valid XHTML to HTML

Surely there must be some _reason_ though. What is it about XHTML that
makes you prefer writing it? Despite the problems I've listed?


>> Why is
>>
>>   <link ... />
>>
>> ...and "stricter" than:
>>
>>   <link ... >
>>
>> ...? Both are just as valid in their respective languages.
>
> closing tads for P abnd LI and UL etc are more strict

No, they're not. There's nothing "unstrict" about having an implied
end tag in HTML -- the spec exactly defines what should be implied
when, and UAs actually do a very good job of handling that correctly.

It may look neater to you, but it isn't any stricter, in any technical
sense.


>> It's probably even faster to write perfectly valid HTML, e.g.:
>>
>>   <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
>>   <title> ... <title>
>>   <p> ...
>>
>> ...which is perfectly valid.
>
> no it's not.. I left the doctype out entirely... And even HEAD. Like
> I said, it was bad HTML.

Leaving out the DOCTYPE saves you few bytes and loses you the ability
to check for validity. Leaving out <head> is perfectly valid. Like I
said, the document above is valid HTML, even though it has no <html>,
<head>, <body>, </p>, etc.


>>> I also said that XHTML was easier to parse and makes it easier to
>>> transition to understand some XML concepts.
>>
>> It is a lot _harder_ to parse if you are just sending it to an
>> HTML4 / Tag Soup parser and hoping it turns out right. When sent as
>> text/html, XHTML uses the same parser as HTML4: It is not any
>> easier to parse.
>
> but I'm not just sending it to such a parser. I'm using a parser
> that needs closing tags.

Not if you send it as text/html. (Unless you are now talking about a
particular device, but I presume you are not since the context of this
discussion is my "Sending XHTML as text/html considered harmful"
document and that document does not speak of any particular device.)


>>> If you use HTML4 instead of XHTML you aren't going to get parsing
>>> warnings either.
>>
>> No, but at least you don't have to rely on possibly-changing error
>> handling behaviour.
>
> again, error handling is in practice only going to get better, not worse.

But why rely on error handling at all?

If you are only going to use text/html, then surely it would be much
wiser to do so in a way that you know is correct, instead of relying
on UAs "getting better".

Especially if you are going to teach it -- it seems like having to
just teach how to write HTML is easier than having to teach how to
write XHTML _and_ how to make sure it works right in both an HTML and
an XHTML context.


>> http://www.hixie.ch/advocacy/xhtml
>
> unfortunately it doesn't display properly in my Treo.

Treos don't support text/plain documents?! That's incredible.


Incidentally, for totally unrelated reasons today I found a page that
claims to be XHTML, but was presumably never tested in an XHTML
browser, and thus fails miserably.

   http://www.tntluoma.com/php/ua.php

This demonstrates my point quite well... the author clearly didn't
understand XHTML, and never tested the document in an XHTML context,
but claimed it was XHTML anyway, and immediately fell foul of the
issues my document lists.

Cheers,
-- 
Ian Hickson                                      )\._.,--....,'``.    fL
U+1047E                                         /,   _.. \   _\  ;`._ ,.
http://index.hixie.ch/                         `._.-(,_..'--(,_..'`-.;.'



More information about the thelist mailing list