Closed Bug 290843 Opened 19 years ago Closed 19 years ago

link rel=stylsheet fails if using xhtml strict doctype and the server delivers stylesheet's content-type as anything but "text/css"

Categories

(Firefox :: General, defect)

1.0 Branch
x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: hughw, Assigned: bugzilla)

References

()

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3

when using 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"//www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

and, for example

<link type="text/css" rel="stylesheet" href="css.qwerasdf" />

and the server delivers the content-type for the linked stylesheet as e.g.
"text/plain" rather than "text/css" (as would happen in the above case using
Apache, if the server had no mapping for file extension ".qwerasdf"):

Then Firefox 1.03 fails to use the stylesheet to render the document: the
document appears as if the stylesheet does not exist.

Note that Firefox does download the stylesheet but simply does not use it properly.

If you remove the <!DOCTYPE... declaration, firefox renders the document properly.







Reproducible: Always

Steps to Reproduce:
1. Put this html document on an apache server:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"//www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>rdf this</title>
<link type="text/css" rel="stylesheet" href="css.qwerasdf" />
</head>
<body>
<div class="banner">
<span class="banner">this line SHOULD be red text on grayish background</span>
</div>
</body>
</html>


2. Create stylesheet file named "css.qwertasdf" on same server, and ensure
Apache does not map that file extension to "text/css" (highly unlikely!). 
Here is the css content:
.banner {
  font-weight: bolder;
  font-size: 150%;
  color: #cc0000;
  background-color: #dddddd;
}

div.assist {
  font-size: 80%;
}
span.assist {
  font-style: italic;
}

body { font-family:arial,sans-serif; }

3. Visit the page using Firefox 1.0.3

Actual Results:  
Document renders with unstyled text

Expected Results:  
Document should render with styled text.


See http://www.hughw.net/~hughw/firefox-css-bug/ for examples comparing
different variations.

Oddity: if you "File/Save Page As...", the <link> tag does not save properly for
xhtml: there is no closing </link> or self-closing <link .../>. When you view
source you see the correct construction. But using the menu command saves
improperly. This behavior occurs even for "good" situations where the css file
was delivered with the proper content-type, so may only be peripherally realted
to this bug.
Summary: link rel=stylsheet fails if using xhtml strict doctype and the server delivers stylesheet's content-type as anything but "text/css" → link rel=stylsheet fails if using xhtml strict doctype and the server delivers stylesheet's content-type as anything but "text/css"
Version: unspecified → 1.0 Branch
If you trigger the standard compliance mode you have to send it with the correct
mime-type.

the error in the JS Console :
Error: The stylesheet http://www.hughw.net/~hughw/firefox-css-bug/css.qwerasdf
was not loaded because its MIME type, "text/plain", is not "text/css".
Source File: http://www.hughw.net/~hughw/firefox-css-bug/bad.html
Line: 0

marking invalid because this is by design
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → INVALID
OK it's fair to say it's not a bug. It's just gratuitous pain, because it is 
not more "standards compliant" to reject the stylesheet on account of its 
defective Content-type. No standard says you have to do that. 

>No standard says you have to do that
That is wrong.
read for example https://bugzilla.mozilla.org/show_bug.cgi?id=136529#c6
Agreed. Thanks for the link. The convincing part is Ian's quote from HTTP 1.1:

#    If and only if the media type is not given by a Content-Type field, the
#    recipient MAY attempt to guess the media type via inspection of its
#    content and/or the name extension(s) of the URL used to identify the
#    resource. 

So I agree, to comply to that spec you have to refuse to process 
the "text/plain" stylesheet.

You need to log in before you can comment on or make changes to this bug.