159776 - CSS does not load properly for this site nmx.fromtheshadows.net

Status: RESOLVED FIXED

(Tech Evangelism Graveyard :: English US, defect, P3)

Description

[Mike Nuss]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020615
Debian/1.0.0-3
BuildID:    20020615

The stylesheet on this page doesn't load at all, but there is no logical reason
for it not to. 

Reproducible: Always
Steps to Reproduce:
1. Go to http://nmx.fromtheshadows.net in Mozilla.

Actual Results:  The page loads without applying the proper stylesheet as
specified in the page source.

Expected Results:  It should have loaded the stylesheet. Open the page in
another browser to see the difference.

The page is in XHTML. If I change the document type to HTML it works fine. If I
change it to point to a stylesheet from a different website it works fine, yet
if I copy that same stylesheet to my local server and reference the local copy
it doesn't work! Mozilla is the only browser that demonstrates this problem, and
as I examine my server logs I can see that it is clearly accessing the CSS file,
but it doesn't appear to be parsing it at all.

Comment 1

[Wesha]

JavaScript Console Oracle says:

Error: The stylesheet http://nmx.fromtheshadows.net/styles/dynamic.css was not
loaded because its MIME type, "text/plain", is not "text/css".

==> Evangelism.

Comment 2

[Mike Nuss]

That is interesting indeed... in the code it does tell it to load the file as
text/css and not text/plain.

Comment 3

[Niklas Dougherty]

curl -I "http://nmx.fromtheshadows.net/styles/dynamic.css"

HTTP/1.1 200 OK
Date: Sun, 28 Jul 2002 07:07:59 GMT
Server: Apache/1.3.26 (Unix) Debian GNU/Linux PHP/4.2.1
Last-Modified: Mon, 22 Jul 2002 19:35:29 GMT
ETag: "2fe004-1a4f-3d3c5e81"
Accept-Ranges: bytes
Content-Length: 6735
Content-Type: text/plain

The spec. says:

"type = content-type [CI]
This attribute gives an advisory hint as to the content type of the content
available at the link target address. It allows user agents to opt to use a
fallback mechanism rather than fetch the content if they are advised that they
will get content in a content type they do not support. Authors who use this
attribute take responsibility to manage the risk that it may become inconsistent
with the content available at the link target address."

The reality is that there are tons of misconfigured servers out there, and
approximately 100.00% of servers will at time be unconfigured for new media
types (try video/mp4 for an example). The spec. allows the user agent to give
the user control over the content. After all, the user should know better than
anyone else what content she serves.

Unfortunately, Mozilla's stance on this is that the mighty Server (= some
company who doesn't give a **** about your pages) will decide what is being
served and not. No matter how much evangelism is going on, these servers will
continue to be misconfigured, because the majority if ISP:s simply don't care
about standards or non-Windows formats (MIME types).

Furthermore, there is no registered MIME type for JavaScript. Yet, Mozilla seems
to accept text/javascript and application/x-javascript (two proposed types),
whereas IE only accepts text/javascript. I won't even go into
application/ecmascript...

For me, Mozilla is all about power to the user. I therefore urge the dev team to
reconsider the position on server prority.

Comment 4

[Mike Nuss]

Thank you for the info nikd. This explains why it worked when I referenced a CSS
file on a different server. Luckily I have root access to the server in
question, so I was able to add a line for the CSS mime type in the Apache
config, and the site now loads properly. I suppose in the Mozilla team's eyes
this is not a bug but a design decision, but I agree with you that it is a
decision that warrants reevaluation.

Comment 5

[Christopher Hoess (gone)]

Per reporter's comments, resolving FIXED.