XHTML rendering on browser

[Bill Thoralina]

Hi,

I created an XHTML page, but for some reason it isn't rendering on my
browser. It is showing up as code.

Any suggestions? Thanks.

[Brian]

Bill Thoralina wrote:

I created an XHTML page, but for some reason it isn't rendering on my
browser. It is showing up as code.
Not enough info. Is the browser IE? What is the declared content-type?
Any suggestions?

Yes. Give is a url, and tell us which browser (and os).

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

[Philipp Lenssen]

Bill Thoralina wrote:

I created an XHTML page, but for some reason it isn't rendering on my
browser. It is showing up as code.

Sounds like you send the correct content-type, and you are using buggy
Internet Explorer. You need to send XHTML files not as XML but as HTML
for 90%* of your users to see it.

*Approximation.

--
Google Blogoscoped
http://blog.outer-court.com

[Lachlan Hunt]

Bill Thoralina wrote:

Hi,

I created an XHTML page, but for some reason it isn't rendering on my
browser. It is showing up as code.

Any suggestions? Thanks.

First, you should validate your document and make sure it is infact
XHTML. Although I doubt this would prevent it from at least attempting
to render the HTML, it's always a good start to solving most problems.
http://validator.w3.org/

Otherwise, this can happen in the following situations:

If the document is being loaded from your local file system:
* Check that it doesn't have a .txt extension.
eg. file.html.txt or just file.txt, it will be treated as "text/plain"
in everything, except IE because it will attempt to sniff the document
and determine that it's HTML.
* If it has a .xml extension, and no doctype or namespace declared,
then you will see a document tree. IE will always show a document
tree for anything with a .xml extension, whether or not is has a
doctype and namespace. These files will be treated as either
text/xml or application/xml.

If this is being sent from a server
* Check that the server is sending the correct Content-Type header
eg. Content-Type: text/html or Content-Type: application/xhtml+xml,
etc…
If it's sending text/plain or text/xml or application/xml then see the
above reasons. The XML media types are also correct, and
should render correctly, however IE will incorrectly treat it as
plain XML and show you the docuement tree, unless you use Dean
Edward's recent hack which allows text/xml to render in IE.

If this doesn't help solve your problem, could you please send a URI
so we can see what is happening.

--
Lachlan Hunt
http://www.lachy.id.au/
la**********@lachy.id.au.update.virus.scanners

Remove .update.virus.scanners to email me,
NO SPAM and NO VIRUSES!!!

[Kris]

In article <eg*******************@news-server.bigpond.net.au>,
Lachlan Hunt <la**********@lachy.id.au.update.virus.scanners> wrote:

* Check that it doesn't have a .txt extension.
eg. file.html.txt or just file.txt, it will be treated as "text/plain"
in everything, except IE because it will attempt to sniff the document
and determine that it's HTML.

If there is a browser that will treat it as plain text because of the
file extension, then it is likely to be IE. It is the content-type
header that first of all determines what kind of file it is. I can put
images online with the extension .txt and serve them as image/jpeg and
they will not be treated as plain text by most browsers. I will however
not do so, since IE is the triggerhappy partycrasher here.

--
Kris
<kr*******@xs4all.netherlands> (nl)

[Brian]

Kris wrote:

Lachlan Hunt wrote:

Check that it doesn't have a .txt extension. eg. file.html.txt or
just file.txt, it will be treated as "text/plain" in everything,
except IE because it will attempt to sniff the document and
determine that it's HTML.
If there is a browser that will treat it as plain text because of
the file extension, then it is likely to be IE.

We've had this discussion before. IE only considers the file extension
after other means have been tried. I might add that you snipped the
context. L Hunt was talking about opening a file on a local file
system, where file extension might have some meaning.
It is the content-type header that first of all determines what
kind of file it is.
In a network situation, sure.
I can put images online with the extension .txt and serve them as
image/jpeg and they will not be treated as plain text by most
browsers. I will however not do so, since IE is the triggerhappy
partycrasher here.

Have you tested this? MS claims that IE sniffs the content and guesses
the correct content-type. If I believe MS, the problem isn't as you
describe it. On the contrary: if you declare the content-type as
text/plain, IE may treat it as something else, e.g., image/jpeg.

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

[Keith Bowes]

Philipp Lenssen wrote:

Bill Thoralina wrote:

I created an XHTML page, but for some reason it isn't rendering on my
browser. It is showing up as code.

Sounds like you send the correct content-type, and you are using buggy
Internet Explorer. You need to send XHTML files not as XML but as HTML
for 90%* of your users to see it.

*Approximation.

Or can send it as application/xml as a cruel joke.

[Ian]

Bill Thoralina wrote:

You need to send XHTML files not as XML but as HTML
for 90%* of your users to see it.

I've heard the term "content negotiation" referred to as a
solution to this. I figure it involves having Apache serve
application/xhtml+xml to Mozilla/Opera/etc. and text/html to IE.
Is this a practical solution?

Ian
--
http://www.bookstacks.org/

[Brian]

Ian wrote:

Bill Thoralina wrote:

You need to send XHTML files not as XML but as HTML for 90%* of
your users to see it.

I've heard the term "content negotiation" referred to as a solution
to this. I figure it involves having Apache serve
application/xhtml+xml to Mozilla/Opera/etc. and text/html to IE. Is
this a practical solution?

Only if done very carefully. IE/Win does not include text/html in its
accept header (sic), and will thus happily accept xhtml that it cannot
parse. Thus, you have to look explicitly for application/xhtml+xml in
the header, and send text/html if it isn't there. Then you must
disable caching, so that IE/Win users don't get the appl...xml version
via a proxy cache.

In short, I don't recommend it. The costs are rather high, for very
little benefit. But ciwah regular Mark Tranchant managed to pull it
off without too much adverse effects.

http://tranchant.plus.com/notes/xhtml11

Call him brilliant, persistent, or crazy. I'd go for at least 2 of
them. ;-) His switcher works, but note the no-cache header.

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

[Ian]

On Mon, 26 Jul 2004 20:36:24 -0400, Brian
<us*****@julietremblay.com.invalid> wrote:

http://tranchant.plus.com/notes/xhtml11

Call him brilliant, persistent, or crazy. I'd go for at least 2 of
them. ;-) His switcher works, but note the no-cache header.

Thanks, Brian. I'll keep that in a cubbyhole until I become better
educated. :-)

Ian
--
http://www.bookstacks.org/

[Claire Tucker]

On Mon, 26 Jul 2004 20:36:24 -0400, Brian
<us*****@julietremblay.com.invalid> wrote:
[snip!]

Then you must
disable caching, so that IE/Win users don't get the appl...xml version
via a proxy cache.

Theoretically, you should be able to send:
Vary: Accept
....in the response header so that caches either don't cache at all or
cache a different version for each unique Accept header. Of course, in
practice caches probably ignore this rule completely.

-Claire

[Alan J. Flavell]

On Tue, 27 Jul 2004, Claire Tucker wrote:

Theoretically, you should be able to send:
Vary: Accept
If you're negotiating on the Accept header, then it would indeed be
very remiss of you not to do so.
...in the response header so that caches either don't cache at all or
cache a different version for each unique Accept header.
Keep in mind that the client or proxy still has the option (if using
HTTP/1.1) to say to the server, "excuse me, I have this ETag on hand,
how would you feel if I used this to fulfil the request" and the
server can say either "go ahead" or "no, here's the correct variant".
Or in technical terms, an "if-any-match" request to the origin server.
Of course, in
practice caches probably ignore this rule completely.

Of course, in practice HTTP/1.0 proxies will follow HTTP/1.0 rules;
whereas HTTP/1.1 proxies aren't mandated to use if-any-match requests:
it's optional.

But if everyone would follow the rules (if -only- everyone would
follow the interworking rules, instead of assuming that because
they're the biggest they have to be right), the results could be
correct, even when the response might be a bit slower than it had to
be.

[Alan J. Flavell]

On Tue, 27 Jul 2004, Alan J. Flavell wrote:

Or in technical terms, an "if-any-match" request to the origin server.

What *was* I thinking??? That should've been "if-none-match", of
course.

[Brian]

Alan J. Flavell wrote:

On Tue, 27 Jul 2004, Alan J. Flavell wrote:

in technical terms, an "if-any-match" request to the origin
server.

What *was* I thinking??? That should've been "if-none-match", of
course.

That explains it! I read that message a couple of times, and wasn't
sure how a if-any-match request would fit in. ;-)

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

[Alan J. Flavell]

On Wed, 28 Jul 2004, Brian wrote:

Alan J. Flavell wrote:

What *was* I thinking??? That should've been "if-none-match", of
course.

That explains it!

Somehow got my wires crossed with Apache's "satisfy any", but that's
something entirely different. I blame the fading grey cells...