53112 - In strict mode, stylesheet not loaded when type="text/css" attribute is missing

Status: VERIFIED WORKSFORME

(Core :: CSS Parsing and Computation, defect, P3)

Description

[Hixie (not reading bugmail)]

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.

Comment 1

[Hixie (not reading bugmail)]

Attachment: Simple and self explanatory testcase. Output should be green, not red.

Comment 2

[Hixie (not reading bugmail)]

Tested on both Linux and Windows -> All/All.

Comment 3

[Pierre Saslawsky]

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.

Comment 4

[harishd]

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 ;-)

Comment 5

[basic]

The testcase works for me on build 2001070108 win32

Comment 6

[Philippe Verdy]

> 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" <[e-mail]> wrote:
> Cc: <[e-mail]>
> 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
> [e-mail]
> 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">

Comment 7

[Hixie (not reading bugmail)]

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.

Comment 8

[Philippe Verdy]

------- 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!

Comment 9

[Hixie (not reading bugmail)]

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.

Comment 10

[Philippe Verdy]

Isn't it an exceptional circumstance when the standard suggests that there's a 
risk of ambiguity ? In that case a SHOULD is not mandatory because we need to 
solve the ambiguity one way or the other, considering the best cases for 
frequent occurences. I see absolutely no problem in trying to use the CSS 
parser on what the server reports as "text/html" or "text/plain" 
or "text/unknown" or "text/xml" or "text/source" or "text/javascript", just 
avoiding to use it on content types that the server says not being of 
the "text/*" family (because this is a basic requirement for a CSS parser which 
first of all is a text parser).
The designer assumed this risk in its design (regarding what the standard specs 
says) so let's trust him first when it used the type attribute in its HTML code.

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.