More accurate testing of XHTML documents with XHTML Proxy

[Christoph Schneegans]

Hi!

I would like to announce XHTML Proxy, a service that allows more accurate
testing of XHTML documents.

<http://hixie.ch/advocacy/xhtml> states that "Sending XHTML as text/html
Considered Harmful" since "authors write XHTML that makes assumptions that
are only valid for tag soup or HTML4 UAs" and might find that the "site
breaks horribly" when they decide to "send the same content as
application/xhtml+xml".

This is where XHTML Proxy can help. It tunnels HTTP requests and changes
the MIME type of text/html resources to application/xml. You can then use
XHTML user agents such as Firefox, Opera or Amaya to browse a site without
modifications to the server's configuration.

Just go to <http://schneegans.de/xp/> and give it a try. Comments welcome.

--
All free men, wherever they may live, are citizens of Denmark. And
therefore, as a free man, I take pride in the words "Jeg er dansker!"

[Spartanicus]

Christoph Schneegans <Ch*******@Schn eegans.de> wrote:

I would like to announce XHTML Proxy, a service that allows more accurate
testing of XHTML documents.

<http://hixie.ch/advocacy/xhtml> states that "Sending XHTML as text/html
Considered Harmful" since "authors write XHTML that makes assumptions that
are only valid for tag soup or HTML4 UAs" and might find that the "site
breaks horribly" when they decide to "send the same content as
application/xhtml+xml".

This is where XHTML Proxy can help. It tunnels HTTP requests and changes
the MIME type of text/html resources to application/xml. You can then use
XHTML user agents such as Firefox, Opera or Amaya to browse a site without
modification s to the server's configuration.

Just go to <http://schneegans.de/xp/> and give it a try. Comments welcome.

This is so idiotic in every aspect, are you taking the piss?

--
Spartanicus

[Christoph Schneegans]

"Spartanicu s" wrote:

<http://schneegans.de/xp/>

This is so idiotic in every aspect, are you taking the piss?

You prefer broken XHTML documents to proper ones, of course.

--
All free men, wherever they may live, are citizens of Denmark. And
therefore, as a free man, I take pride in the words "Jeg er dansker!"

[Chaddy2222]

Christoph Schneegans wrote:

"Spartanicu s" wrote:

<http://schneegans.de/xp/>

This is so idiotic in every aspect, are you taking the piss?

You prefer broken XHTML documents to proper ones, of course.

I think it's a case of a lack of support for XHTML, in it's true form
from browsers such as IE and I am sure their would be others.
So you need to eather serve your pages as Text/HTML or just use HTML
4.01 Strict.
Most web authors, or a lot in this group anyway choose to use HTML over
XHTML for very similar reasons to this. They don't want to write PHP
scripts to change the Domument type in the HTTP header of the document,
they would rather just use plain HTML, if you used XHTML in it's proper
form, you would need to still serve it as HTML to IE and other browsers
that have no XHTML support.
--
Regards Chad. http://freewebdesign.cjb.cc

[Spartanicus]

Christoph Schneegans <Ch*******@Schn eegans.de> wrote:

<http://schneegans.de/xp/>

This is so idiotic in every aspect, are you taking the piss?

You prefer broken XHTML documents to proper ones, of course.

I'm of the opinion that anyone who considers XML restraints relevant to
documents served as text/html is delusional.

I'm against XHTML for almost all current day web authoring:
http://www.spartanicus.utvinternet.ie/no-xhtml.htm

--
Spartanicus

[Andy Dingley]

Christoph Schneegans wrote:

"Spartanicu s" wrote:

<http://schneegans.de/xp/>
This is so idiotic in every aspect, are you taking the piss?

I don't think this proxy is itself idiotic, just that almost every use
of it would be.
What is this thing actually useful for ?

It's _not_ useful for turning XHTML Appendix C documents into XHTML ~C
documents.
The rules are different for these documents and why should we want to
see some other site's Appendix C document in a way that it isn't, and
that it was never claimed to be?

It's not useful for feeding XHTML ~C content to XML browsers for
testing browsers. If you need to do that, just author a few documents
and set their HTTP headers accordingly.

It's not useful for testing XHTML documents, because if they're your
site, then you cna control their original headers.

It's of possibly marginal use for validation Appendix C documents to
see if they might also be valid ~C documents. I can't imagine why you'd
want to do such a thing, except possibly within a web design theory
group.

What it certainly will do is to present some valid Appendix C documents
in a way that will cause browsers to break, even when they ought not to
do so. Then the hixiephiles will shout out "XHTML is so evil" and put
the blame in completely the wrong direction.

You prefer broken XHTML documents to proper ones, of course.

"broken" - now there's a loaded term, which makes me disinclined to
take much notice of Christoph's postings. Appendix C is _not_
"broken", it's a valid alternative.

[Christoph Schneegans]

Andy Dingley wrote:

<http://schneegans.de/xp/>

It's not useful for testing XHTML documents, because if they're your
site, then you cna control their original headers.

In theory, you can. But most people are lazy. And pasting a URL in a form
is easier than editing your .htaccess. Furthermore, it's not trivial to
set up proper content negotiation, and you'll always struggle with caching
issues. For some authors, content negotiation is not an option at all -
what do you do if your website is running on IIS and you want to serve
static XHTML files?
What it certainly will do is to present some valid Appendix C documents
in a way that will cause browsers to break, even when they ought not to
do so.
Do you have an example of such documents? In my opinion, if an XHTML works
well when served as "text/html", but "breaks horribly" when served as
"applicatio n/xhtml+xml", there's something wrong with that document. This
is the very scenario that you can easily avoid with the help of XHTML
Proxy. XHTML Proxy is not an argument for <http://hixie.ch/advocacy/xhtml>,
but invalidates Hickson's reasoning.
Appendix C is _not_ "broken", it's a valid alternative.

I know. <http://schneegans.de/xp/> is XHTML 1.0 Strict served as
"text/html".

--
All free men, wherever they may live, are citizens of Denmark. And
therefore, as a free man, I take pride in the words "Jeg er dansker!"

[Harlan Messinger]

Christoph Schneegans wrote:

Andy Dingley wrote:

> <http://schneegans.de/xp/>

It's not useful for testing XHTML documents, because if they're your
site, then you cna control their original headers.

In theory, you can. But most people are lazy. And pasting a URL in a form
is easier than editing your .htaccess. Furthermore, it's not trivial to
set up proper content negotiation, and you'll always struggle with caching
issues.

If the webmaster isn't up to the task of configuring the server to serve
application/xhtml+xml, then the pages aren't going to be served as
application/xhtml+xml. If the pages aren't going to be served as
application/xhtml+xml, then what is the point of testing them to see if
they would work if they were?

[Andy Dingley]

Christoph Schneegans wrote:

Andy Dingley wrote:

What it certainly will do is to present some valid Appendix C documents
in a way that will cause browsers to break, even when they ought not to
do so.

Do you have an example of such documents? In my opinion, if an XHTML works
well when served as "text/html", but "breaks horribly" when served as
"applicatio n/xhtml+xml", there's something wrong with that document.

Or something wrong with the browser. What happens if your proxy is used
to serve XHTML ~C to a browser that really doesn't wannt it? There will
be a browser-caused error, but this is likely to be presented as more
fuel for Hixie's "it's all XHTML's fault" argument.

There are admittedly few Appendix C documents that are not also valid
XHTML ~C (you have to juggle with encodings in the XML prolog). Some
serialisers for XHTML ~C generate <option selected> for better browser
compatibility, but that's anyway dodgy for being well-formed "XHTML",
even when served as text/html

My point is though that the only point for this proxy, where it's not
just easier to do it right, seems to be to deliberately confuse non-XML
browsers.

[Christoph Schneegans]

Andy Dingley wrote:

In my opinion, if an XHTML works well when served as "text/html", but
"breaks horribly" when served as "applicatio n/xhtml+xml", there's
something wrong with that document.
Or something wrong with the browser.

While testing my proxy, I've found _one_ bug in Opera 9.0b2, see
<news:e6******* ***@news.christ oph.schneegans. de>. I've found _dozens_ of
broken XHTML documents.
What happens if your proxy is used to serve XHTML ~C to a browser that
really doesn't wannt it? There will be a browser-caused error, but
this is likely to be presented as more fuel for Hixie's "it's all
XHTML's fault" argument.
<http://schneegans.de/xp/> clearly advises to use "XHTML user agents such
as Firefox, Opera or Amaya".
There are admittedly few Appendix C documents that are not also valid
XHTML ~C (you have to juggle with encodings in the XML prolog).

My experience is that most XHTML documents published on the web today even
violate basic XML well-formedness constraints. If this situation does not
change, Hickson will be proved correct. XHTML Proxy can help to change the
situation.

--
All free men, wherever they may live, are citizens of Denmark. And
therefore, as a free man, I take pride in the words "Jeg er dansker!"