xhtml and firefox

content headers.

[zero]

Hello, I'm new here..

Maybe I'm lousy at searching but anyway, I have a valid xhtml 1.0 strict document sent with the header application/xhtml+xml. It will display as intended in Opera but in Firefox 1.0 it displays this message:
"This XML file does not appear to have any style information associated with it. The document tree is shown below." followed by the page source.

The document has a <link rel="stylesheet" type="text/css" title="default" href="../index.css"/>, so how come the page isn't being rendered?

[encyclo]

Welcome to WebmasterWorld [webmasterworld.com], zero.

The first thing to check in this situation is the mime type of the index.css file. If you<re not sure, load that file directly in the browser and go to Tools then Page Info. The mime type should be listed as

text/css

. If the server is misconfigured (sending for example

text/plain

for CSS files), then your stylesheet may not show.

[tedster]

Also, you should have a space before the trailing slash in the link element.

If you are serving the xhtml as application/xhtml+xml, then FireFox will be very strict about that standard - and it may be causing FireFox to give up on the link element and therefore the document. Note that you can also serve xhtml 1.0 as text/html and be more relaxed about things like this.

[zero]

Hmm, well the css header is all right and there IS a space before the close of the link, which Firefox chose not to display in the "document tree" but it can be seen in the page source.

I dunno what other information to provide, what's a working site that uses application/xhtml+xml?

[iamlost]

Add: media="screen" :

<link rel="stylesheet" type="text/css" media="screen" title="default" href="../index.css" />

[Robin_reala]

Tedster: I believe it's only IE5/Mac that needs the space before the trailing link - XML certainly doesn't demand it. But yeah, it's good form to put it in there.

[py9jmas]

Any browser that supports XHTML (ie Mozilla, Opera) won't care about spaces before a closing />. Adding a space is only needed for people serving XHTML as text/html (ie, treating XHTML as corrupt HTML).

Mozilla, Firefox and Opera can all cope with my web pages serverd as application/xhtml+xml. I'd check the mime-type is what you expect it to be. In Firefox, look at the page info dialog (Ctrl-i in Mozilla) to see what type the browser thinks it was served. Also, run the page through W3C's validator.

The error you are getting is Firefox thinking it has some generic XML. Without an XML processing instruction telling it how to render the XML, <?xml-stylesheet href="mystyle.css" type="text/css"?>. It has nothing to do with HTML's <link> method of linking to stylesheets.

[tedster]

Any browser that supports XHTML (ie Mozilla, Opera) won't care about spaces before a closing />

I'll need to check further on this. I know what you said is true IF the page is served with a mime type of text/html. But to my current understanding, that is not true when you serve a mime type of application/xhtml+xml - as I said, I'll need to check, as I don't serve application/xhtml+xml anywhere right now.

[zero]

Thanks everyone for your help so far.

Well my pages validate without the space in the link tag, so it appears to be all right not having it.

In response to py9jmas, the error goes away after adding the xml-stylesheet. However now Firefox will apply my CSS rules but display the page as plain text without default HTML styling e.g. <a>s aren't links, like if it was any XML doc. How to solve this problem?

Does this mean that stylesheet <link>s are meant to be ignored in XHTML? In Opera the page is displayed the same whether application/xhtml+xml or text/html is used, with and without the xml-stylesheet tag.

If py9jmas you have working pages in application/xhtml+xml, perhaps you could post a link so I can compare them to mine, or is this against the rules of the forum?

[tedster]

Please use sticky mail for trading links, thanks. That guards against the self-promotion that would inevitably evolve if we allowed personal urls in the public threads.

I really hope you can understand what's going on here and report back - right now I'm mystified.

[encyclo]

I've had a chance to look at this today and I'm still rather confused by the problem. Usually in Firefox, if you serve a file as

application/xhtml+xml

it should not display as an XML tree even when there is no explicit style associated with the file. If you take this very simple document:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>zero test</title>
</head>
<body>
<p>A simple test case<br/>with a line break</p>
</body>
</html>

What happens when you try and serve it as

application/xhtml+xml

?

About the trailing slash and spaces: the space is required only to cater for older user agents when dealing with an XHTML document served as

text/html

. In true XML the space is not required. Both, however, are supported. In a real world scenario, you should always use the space.

Of course, in a real world scenario, you wouldn't be serving content as

application/xhtml+xml

outside of a testing situation anyway: it is entirely the wrong approach for a public document using XHTML only, as you are actively penalising more modern user agents (such as Firefox or Opera) compared with older ones such as IE.

[zero]

aha! thanks, encyclo. I did something dumb (especially since I got it right last year, but have deleted the former page already) with the xmlns attr., but it validated so I didn't realise the problem.

(By the way the same document displays differently with the different Content types, but I should look into it myself before asking.)

I am doing a sort-of test, and I agree with you on the space and closing slash, but I don't quite get your point on why its "entirely the wrong approach".. After all, it is the W3C recommendation. Why would you be penalising the newer browsers when they can deal with it properly? IMHO, only the server would have any trouble as it needs to browser-sniff.

[encyclo]

I'm glad you got it sorted out, zero. Validation doesn't help as much as you might expect, because XHTML served as

application/xhtml+xml

doesn't actually need to validate to display, it merely has to be well-formed: in other words tags or attributes could be missing or incorrect, but the page will display if the open/close order is respected. Validation also doesn't verify the contents of attributes (unless they are specifically required).

I consider, however, the use of

application/xhtml+xml

to be a bad idea on a public website for the following reasons: if you upload or generate a page with a well-formedness error (easy enough to do on a busy site or due to a CMS coding error or third-party content), the page will not display in modern browsers such as Firefox and Opera. It will however show up in IE as you are serving it as

text/html

. That means that IE becomes a better choice for viewing the site as you've not got the risk of pages failing. Secondly, Gecko (the Firefox/Mozilla rendering engine) displays pages sent as

application/xhtml+xml

more slowly (no incremental display) than

text/html

pages. Thirdy, you are more limited in what you can do: no

document.write

in Javascript, for example (so no AdSense). Finally browser-sniffing is not always fool-proof, and I've seen posts here from members whose sites were dropped from the Google index because their browser-sniffing served the wrong mime type to Googlebot (which doesn't support

application/xhtml+xml

but may send an Accept header of

application/*

anyway).

Unless you are using XHTML modularization (such as including MathML or SVG content), then you should stick to

text/html

for the best user agent compatibility. I prefer HTML 4.01 Strict in most cases, but you might prefer to use XHTML 1.0.

[zero]

Ah, search engines. I see what you were getting at now, anyway this part of my site isn't in production yet. Thanks everyone.