W3C home > Mailing lists > Public > www-html@w3.org > December 2002

Re: Is this legal XHTML 1.1?

From: Ian Hickson <ian@hixie.ch>
Date: Fri, 13 Dec 2002 05:38:46 +0000 (GMT)
To: Christian Wolfgang Hujer <Christian.Hujer@itcqis.com>
Cc: Elliotte Rusty Harold <elharo@metalab.unc.edu>, "www-html@w3.org" <www-html@w3.org>
Message-ID: <Pine.LNX.4.21.0212130526180.21095-100000@dhalsim.dreamhost.com>

On Tue, 10 Dec 2002, Christian Wolfgang Hujer wrote:
>>    http://www.hixie.ch/advocacy/xhtml
> Point 2 about script/style is outdated. No current non-XHTML ua renders 
> script/style element contents, even when they are not commented.

That doesn't matter: people still comment the script and style elements
out, whether it is needed or not.

> Point 3 I am not sure of, I think the SGML specs had been updated for that.

Nope, they haven't.

> Point 4 has bad argumentation: "Since most authors only check their documents 
> using one or two UAs..., and thus most XHTML documents on the web now
>    are invalid." Because plants are green, most trees are invalid. It's not 
> concerning valid documents.


Please point out the exact step where you think there is a logic error:

   Most authors only check their documents using one or two UAs,
   rather than using a validator.

   Ergo these authors are not checking for validity.

   Most authors (including me) occasionally include at least one error in
   their documents, making them ill-formed.

   Ergo the authors that are a cross-section of both groops, and use
   XHTML, are placing invalid XHTML documents on the web.

Since the two groups are huge proportions of the Web authoring community,
as a quick perusal of XHTML sites will show,most XHTML documents on the
web now are invalid.

Where is the error?

> Point 5 again bad argumentation. Again it's not concerning valid documents.

This document isn't some sort of theoretical excercise. It is listing
practical reasons why using text/html for XHTML is bad.

One of those reasons is that if you ever switch your XHTML documents from
text/html to text/xml, then you will in all likelyhood end up with a
considerable number of XML errors, meaning your content won't be readable
by users. (Most XHTML documents do not validate.)

I don't know of _anyone_ who has switched or could switch from text/html
to an XML MIME type without a single problem.

> Point 6 that could be considered by the CSS author.

Yes, all of these points _could_ be considered. But they are not.

> Point 7 see 6

See above.

> Point 8 Only sometimes. But definitely not on Windows when the ending is 
> .html.

Whenever you save an XHTML document to disk as an XHTML document, e.g. on
Windows using the .xhtml or .xml extension, or on Unix on a system that
detects XHTML by examining the DOCTYPE, you will hit this problem.

> Point 9 No. I could use those tools to *parse* XHTML, not generate or
> modify.

Nothing stops you using real XHTML internally, and publishing HTML.

> And XSLT won't transform *from* HTML, only *to* HTML, and only if the
> processor supports that.

That is all I meant: store it internally as XHTML, and serve HTML.

> Point 10 HTML 4.01 is not XML. That's reason enough.

Exactly. People consider jumping on the bandwagon reason enough. and that
is _sad_.

> Are you very sure about <br /> should be rendered as &#xA;>? Last time I 
> looked that up in SGML, it looked otherwise to me.

Look again. This is a definite fact. (Look up NET SHORTTAG).

> Using XHTML and sending it as text/html is tag soup. But I might send it as 
> application/xhtml+xml or text/html, depending on the UA.

That totally screws up caching.

> I think you should update your document to reflect the fact that 
> application/xhtml+xml exists.

See appendix A at the bottom.

> Anyhow, both, RFC2854 and RFC3236 are informational

Well in that case, there's absolutely no reason to be using text/html at
all, is there. I don't see your point.

> So I can't see why you consider these two RFCs of such very high 
> importantance.

What else gives you any allowance to send anything as text/html or

>>> I have the feeling, that Mozilla and IE6 interpret at least entities from
>>> the internal subset of the DTD, even when the document is served as
>>> text/html.
>> Mozilla makes no attempt to parse the internal subset in HTML.
> It does with application/xhtml+xml.

That's not HTML.

Ian Hickson                                      )\._.,--....,'``.    fL
"meow"                                          /,   _.. \   _\  ;`._ ,.
http://index.hixie.ch/                         `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 13 December 2002 00:38:54 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:06:01 UTC