Closed Bug 53112 Opened 20 years ago Closed 19 years ago
In strict mode, stylesheet not loaded when type="text/css" attribute is missing
377 bytes, text/html
STEPS TO REPRODUCE: Open the attachement, which calls a stylesheet like this: <link rel="stylesheet" href="http://bugzilla.mozilla.org/showattachment.cgi?attach_id=14944"> Note the lack of a "type" attribute. ACTUAL RESULTS: Stylesheet is not used. EXPECTED RESULTS: If the "type" attribute on the <LINK> element is missing, then we should query the server to find the MIME type of the alledged stylesheet, and use it if we recognise it. It seems to work ok if the stylesheet is a local file, prompting questions about whether this is actually a Necko problem. Note: The "type" attribute is advisory only. If it gives a MIME type that we recognise then we should ignore it. If it is absent then we should ignore it. It is only if it is present and the type is one that we do NOT support that we should heed it's advice and not bother to fetch the file.
Tested on both Linux and Windows -> All/All.
This is a regression introduced between M15 04/18 and M16 06/02. The stylesheet is correctly loaded if you remove the strict DTD. Updated the title and reassigned to Harishd/Parser. Harish: if you dont feel that this bug is yours, please reassign to me and I'll investigate a bit more.
Assignee: pierre → harishd
Component: Style System → Parser
Summary: Stylesheet not loaded when "type" attribute is missing → In strict mode, stylesheet not loaded when "type" attribute is missing
Strict DTD has been yanked and all we have is strict layout. That is, as far as the parser is concerned all documents pass through CNavDTD regradless of DOCTYPE. Therefore, the problem is somewhere in layout. Giving bug back to Pierre ;-)
Assignee: harishd → pierre
Component: Parser → Style System
Summary: In strict mode, stylesheet not loaded when "type" attribute is missing → In strict mode, stylesheet not loaded when type="text/css" attribute is missing
Whiteboard: (py8ieh:slurp testcase for importtest) → [Hixie-P4] (py8ieh:slurp testcase for importtest)
The testcase works for me on build 2001070108 win32
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
> Philippe Verdy wrote: > Subject: Feedback on DevEdge /docs/technotes/incorrect-mime-types/index.html > > Your comment is a bit too restrictive... > > Both CSS and HTML have NOT been defined with a REQUIRED support of MIME > > types by the transport layer. > > That is why HTML provides the "type=" attribute for the "<LINK>" element, > > whose role is to specify the way the HTML page MUST be interpreted according > > to the linked resource. > > So, whatever the HTTP server says (or does not say) in its transport layer, > > a strict HTML page IS conforming and FULLY compatible if the browser > > interprets correctly the "type=" attribute of the "<LINK>" element. > > > > What does it imply ? > > HTML Documents will be able to refer to external CSS entities available by > > an external server, whatever the server says about them. You just need to > > specify the "type=" attribute explicitly: > > <link rel="stylesheet" type="text/css" href="/evangelism/lib/css/basic.css"> > > and not simply: > > <link rel="tylesheet" href="/evangelism/lib/css/basic.css"> > > because the latter will only work provided that the served external entity > > is transported through a layer that can deliver the MIME type accurately. > > > > If you look at the standard description of <script> and <link> elements, the > > strict definition REQUIRES specifying the "type=" attribute for the > > referenced external entity (this can also be used for images with <IMG>, > > though it is not required, as the actual file type is most often "sniffed" > > by its content magic values, and because the actual content does not impact > > the layout and the DOM for the HTML document rendered by the HTML browser). > > > > A "file:" transport protocol will most often try to associate the MIME type > > from the file extension (Windows, DOS, Unix), or from a filesystem property > > (such as the Creator attribute on Mac filesystems which traditionally don't > > need filename extensions, but hide them in a distinct 32-bit property), or > > from specific "content sniffers" (the Unix "magic" file type) > > > > An HTTP server is NOT REQUIRED to return MIME types in one of its headers > > (this is only a recommandation), and if it does, it SHOULD use the > > "Content-Type:" header for that purpose (some compliant HTTP servers will > > still use some other headers for that purpose, given that the MIME type may > > not be accurate enough on some applications, and some compliant HTTP servers > > can't be configured to support more content types than text/html and > > application/binary). > > > > This specification of the HTTP standard allows for interesting reuse of the > > same content with different interpretation. This, for example, can be used > > to change from the "text/html" default MIME type of an HTML page into the > > "text/plain" MIME type (for example to display the source text of an HTML > > page in an IFRAME, without rendering it as an HTML page, or to force > > another renderer than the default one in audio/video presentations). > > > > If Netscape 6/7 and Mozilla do not use this rule, they are wrong, and do not > > respect the standard, so this is a bug! > > The correct support of the "type=" attribute of the <LINK> element is > > mandatory for strict compliance, and if not, you cannot enforce and check > > the strictness of HTML page in the browser... If you don't use the "type=" > > attribute in <LINK> elements the way the HTML designer wanted it, you're > > breaking the HTML standard, as you link the rendering of the content to the > > transport layer which is clearly not part of the content but just a (not > > required) tool... > > > > Don't forget that other transport layers are NOT capable of specifying a > > MIME type (for example the FTP protocol !). > > With your requirement, an FTP server could not be used to deliver strict > > HTML content with CSS, despite the standard allows this: > > <link rel="stylesheet" type="text/css; charset=macLatin" > > href="ftp://myMacServer.myDomain.cc/Preferences/myMacOsStyleSheetForCSS"> > > > > Also note that we can give hints in the HTML document to the HTML renderer > > about how to decipher the encoding of the CSS entity. This support is > > required because CSS stylesheets don't contain any required elements that > > can be sniffed to autodetect their encoding (like XML contents, whose > > encoding can be sniffed as indicated in the XML standard)... > "Netscape 6 Technology Evangelism Team" <firstname.lastname@example.org> wrote: > Cc: <email@example.com> > Sent: Friday, May 24, 2002 4:31 AM > Subject: Re: Feedback on DevEdge /docs/technotes/incorrect-mime- types/index.html > > Please file a bug in http://bugzilla.mozilla.org/ and bring your view > point to the engineers. If you have a valid point, they will at least > listen to your position. > > Bob > > -- > Netscape 6 Technology Evangelists > Netscape Communications > firstname.lastname@example.org > http://developer.netscape.com/evangelism/ > Well, I would suggest that your page includes a note that, for best compatibility, recommends to always set the type="text/css" attribute explicitly in the <link rel="stylesheet" href="..." /> header element. For example, setting the "text/css" MIME type to all references to the same content (same URL), is not appropriate in some cases; for example, a web site could use the following link in an HTML page: <a href="../css/stylesheet.css" type="application/x-download">Download this stylesheet</a> to allow saving the referenced style sheet to disk, without rendering it as plain text in a new browser page or window(note that a well configured HTTP server will still send the "text/css" MIME type, optionally marked with charset encoding, so that the client browser knows if the content can be saved into a file of the appropriate type or meta-data, possibly reencoding it before storage)... In fact the "type=" attribute can and should be set (with the appropriate MIME type) on any element that refers to external entities in their "href=" or "src=" attribute, including <img>, <object>, <frame>, <iframe>, <a> and the transitional elements such as <embed>, <bgsound>. The same remark applies to the "hreflang=" attribute that can be set to specify the locale name of the external entity refered to by the "href=" attribute of relevant elements, though it is most often important for indexers, and most often only appropriate for <img> elements. Note also that the following code is still valid and should work in strict mode: <link rel="stylesheet" type="text/css" href="myStylesheet.txt"> despite a well configured HTTP server will typically return the "text/plain" MIME type in its "Content-Type:" header... The following should work as well in strict mode to load a CSS stylesheet (though not recommanded, because many web browsers may interpret it incorrectly when seeing a "text/html" MIME type returned from the HTTP server): <link rel="stylesheet" type="text/css" href="myStylesheet.html">
The HTML and HTTP specs say that the type attribute of the <link> element is merely advisory and that the Content-Type HTTP header should override it. Furthermore, changing the MIME type to trigger download behaviour is not a supported usage per the HTTP specs, so that should not be a relevant consideration in this case.
Status: RESOLVED → VERIFIED
------- Ian 'Hixie' Hickson says (2002-05-24 04:35) >The HTML and HTTP specs say that the type attribute of the <link> element is >merely advisory and that the Content-Type HTTP header should override it. > >Furthermore, changing the MIME type to trigger download behaviour is not a >supported usage per the HTTP specs, so that should not be a relevant >consideration in this case. This last paragraph is wrong! HTTP specs are not designed to fix ANY behavior of the client regarding the MIME type. In fact, HTTP is a TRANSPORT protocol, used to DOWNLOAD/UPLOAD documents specifically. The fact that a browser renders the document or saves it to disk is is NOT specified by HTTP, and a browser needs to perform its action about the DOWNLOADED document the proper way, according to its built-in rules, all of them can only be based on the MIME type of the document, not on the response of the transport protocol. The specs also say "SHOULD", not "MUST". This means that such sentences are NOT part of a CONFORMING or VALIDATING document. The fact that Mozilla (and Netscape 7, as indicated in the Technote) enforces the "SHOULD" into a "MUST" is not compliant to the standard, as it chooses to deliberately ignore the stylesheet specified in the HTML document, even if the document specifies the type="text/css" attribute explicitly in the <link> element of the HTML document. Reread the specs regarding the stylesheet attachment: you'll see that HTTP just RECOMMENDS (SHOULD) using the "Content-Type" according to the document (when it is taken in an isolated context), and that the HTML specs RECOMMENDS (SHOULD) specify the NON MANDATORY "type" attribute for <link>-type elements. So both specs use the SHOULD (non mandatory) keyword regarding content types. This clearly introduces a possible conflict, as these content types MIGHT not match between the HTTP returned content type and the HTML specified content type. What is the appropriate solution to solve the conflict ? One must resolve it according to the context: HTTP does not carry any contextual information, so the CSS file will be downloaded regardless of its use by the browser. Then the HTML document which references it dictates its use. There's no REQUIREMENT that a VALIDATING HTML document MUST have a matching content type from the server (in fact the web uses many links from different sources, and will work as such only because of the relations that can be established through <a name> anchors, <a href> links, supplementary <link> links. The solution is clearly indicated in the XHTML standard, which makes great importance on the links to mandate the behavior, and the semantics of linked documents. This is true for all meta-data attached to the link itself, which always has priority on meta data attached to isolated documents: this includes the content-type, but also the title, the encoding, the language, the display size (for images, objects and frames), and so on... When a browser needs to render a page, it will perform it according to the context of the HTML document containing or referencing the extra documents (images, stylesheets, objects, ...) which all are constrained to the limits imposed by the main referencing document. I see absolutely no reason why Netscape an Mozilla deliberately chooses to ignore the specifically designed stylesheet, even in strict mode (simply because the spec do not enforce these rules as mandatory). I think it is safer, and simpler to always honor the type attribute of a <link rel="stylesheet" /> element if it has a valid value (the "text/css" value is standardized, so it should be recognized as such and honored by all CSS-enabled browsers, regardless of the strict DTD conformance, once again because the CSS stylesheet itself is not part of the strict DTD definition). There are many cases where stylesheets do not have a dedicated "filename" extension, and the HTTP server will sometimes return a "text/html" content type as the only possible value if the stylesheet is generated by a script (for example through a CGI interface which does support specifiying HTTP headers). And the only way for the designer to specify the behavior is through the HTML document where the stylesheet is applied, i.e. through an explicit type="text/css" attribute in the <link rel="stylesheet".../> element, or in a <style href></style> element. This is also true for any other referenced subdocuments, i.e. in strict HTML with <img> images, <objects>, <script>, or in transitional HTML with <frame>, <iframe>, <embed>... where the type attribute can and should be specified for full independance with the transport layer (should it be http:, https:, ftp:, rtsp:, file:, or even telnet:). Don't link HTML with HTTP, this is going to the bad direction, as both were designed to be independant!
Please read RFC 2119. "SHOULD" is considered mandatory unless there are extremely exceptional circumstances. In the case described herein, there are not. See also bug 136529 comment 6.
Let's not have this debate in three different bugs (this bug, bug 113399, and bug 136529). I think the appropriate place is bug 136529.
You need to log in before you can comment on or make changes to this bug.