Re: Is this legal XHTML 1.1?

Hello Ian,


Am Freitag, 13. Dezember 2002 06:38 schrieb Ian Hickson:
> > 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.
>
> Eh?
>
> 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.
Yes, but *that* group usually even does not know of either W3C or XHTML.

>    Ergo these authors are not checking for validity.
Yes. They should be teached validity first, then XHTML.

>    Most authors (including me) occasionally include at least one error in
>    their documents, making them ill-formed.
Well, the only "error" I occasionally include is namespace declarations that 
should not be there because some XSLT processors have some really annoying 
(but still absolutely correct) behaviour about namespace declarations.

But usually all my XHTML documents are, and all my HTML documents were valid.
I check each document for validity *before* upload, even before locally 
viewing them in the browsers.

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

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

But that is not a reason not to use XHTML, that's a reason to learn about 
validation.
It's not an argument against usage of XHTML, it's an argument against stupid 
usage of XHTML.

If someone uses XHTML instead of HTML, always serves it as text/html, and even 
uses invalid XHTML, nothing has changed from the past.
Documents always should be valid, wether they are HTML or XHTML.
Using Attributes like topmargin is usually just lack of knowledge rather than 
neccessity.


> > 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.
It's bad in the cases described.

But what about a valid XHTML 1.1 document that displays fine even in Netscape 
4?
Why shouldn't such a document be served as .xhtml with application/xhtml+xml 
to Mozilla, Opera and all other browsers that send an Accept header which 
contains application/xhtml+xml and .html with text/html to the user agents 
that don't say they knew application/xhtml+xml like Internet Explorer? Those 
are tag soup anyway, they "don't know the difference".

> 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.)
See above. When I speak of XHTML I speak of validating XHTML.
Of course, many problems will arise if they have not been considered in the 
first place. HTML DOM seems not to apply to current implementations of 
application/xhtml+xml user agents, so XML DOM must be used.
Some differences are between HTML CSS and XHTML CSS in current User Agents.

What if all this has been considered?

> I don't know of _anyone_ who has switched or could switch from text/html
> to an XML MIME type without a single problem.
I also had my problems, but I detected them *before* I published the documents 
on the web.

> > Point 6 that could be considered by the CSS author.
>
> Yes, all of these points _could_ be considered. But they are not.
They are at least of me.

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

> > 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.
Something stops me from doing this.
Different projects in different companies that must interact with each other 
by parsing documents.

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


> > 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.
Not totally, just a bit, because each document exists twice with exactly the 
same content.

> > 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
> application/xhtml+xml?
The W3C note, which of course is just a note.
We're talking of HTTP and HTML, which are the WWW part of the Internet.
I consider the W3C's documents on WWW to have priority over those from the 
IETF. We're talking about HTML and HTTP, not about MIME for E-Mail or IPv6.

Okay, so here's a description of how I publish documents:
First, an Ant tasks checks wether all XHTML, SVG and other XML documents are 
well-formed and, if a DTD exists, valid.
Second, an Ant task transforms XHTML to add Layout and SVG to rasterize them 
into PNG. The transformation also checks for more restrictions.
Third, an Ant tasks checks wether all generated XHTML documents are 
well-formed and valid.
Optionally, a forth Ant tasks uploads the documents.
So my documents are always valid, at least Xerces says so.

When a document is new or something substantially changed, I check it in 
Mozilla1.2, Opera6, and IE6. Regularly I also check in konqueror, lynx, w3m 
and links.

Sometimes I even look at my documents with Netscape4, but I don't care wether 
the documents look okay in that browers since usually it's that browser's 
fault when their display is screwed up, not the fault of the code.

I still can't see why I should not serve them as application/xhtml+xml to 
application/xhtml+xml accepting ua's and text/html to the tag soup browsers.


Bye
-- 
ITCQIS GmbH
Christian Wolfgang Hujer
Geschäftsführender Gesellschafter
Telefon: +49  (0)89  27 37 04 37
Telefax: +49  (0)89  27 37 04 39
E-Mail: Christian.Hujer@itcqis.com
WWW: http://www.itcqis.com/

Received on Friday, 13 December 2002 01:15:36 UTC