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)
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.
Reporter | ||
Updated•19 years ago
|
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
Comment 1•19 years ago
|
||
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
Reporter | ||
Comment 2•19 years ago
|
||
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.
Comment 3•19 years ago
|
||
>No standard says you have to do that That is wrong. read for example https://bugzilla.mozilla.org/show_bug.cgi?id=136529#c6
Reporter | ||
Comment 4•19 years ago
|
||
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.
Description
•