In my web application I have some files with extension ".css.map".
Looking on the internet I see that, as content type, I should put "application/json" so my include directive looks like this:
<link rel="stylesheet" type="application/json" href="resources/css/angular-chart.css.map"/>
Nevertheless, this does not prevent my browser to display the warning:
Resource interpreted as Stylesheet but transferred with MIME type text/html
This warning seems to be the cause of a blank page displayed on internet explorer browser (chrome and firefox seem to be fine). After reloading the page IE does display it right, but I'd like to solve this problem at its root, by getting rid of that warning.
I think the problem is in the
rel="stylesheet"
so, what should I put there?
You shouldn't link to map files at all. Tools that use them will use a X-SourceMap header or infer the URL by adding .map to the URL of the actual stylesheet or JavaScript program.
Try explicitly specifying the type as json in your link tag, like so:
<link rel="stylesheet" type="application/json" href="blah">
Related
I have a website running perfectly fine on Chrome, Firefox, Safari etc. however, the CSS does not load in Internet explorer (any version) as well as in MS Edge browser.
The Console shows this infamous error related to MIME Type:
SEC7113: CSS was ignored due to mime type mismatch
File: application-2015-2a0565839ee60a029c49fc918e3625e9.css
SEC7113: CSS was ignored due to mime type mismatch
File: CustomCss.css
SEC7113: CSS was ignored due to mime type mismatch
File: print.css
I have checked in the code, and this is how it is in the <head>
// ASP.NET MVC code - .cshtml layout file
<link href='#Url.Content("/Content/application-2015-2a0565839ee60a029c49fc918e3625e9.css")' media="screen" rel="stylesheet" type="text/css"/>
<link href='#Url.Content("/Content/CustomCss.css")' media="screen" rel="stylesheet" type="text/css"/>
<link href='#Url.Content("/Content/2015/print.css")' media="print" rel="stylesheet" type="text/css"/>
I have checked in the IE Developer Tools, and the css indeed returned with incorrect MIME type (coming as blank) in IE instead of stylesheet or text/css as in Chrome or Firefox:
IE:
Chrome:
I have checked in IIS, the mime type for .css is mapped as expected:
How can I make IE to understand the Mime type and let it load it correctly.
Any help is highly appreciated.
EDIT
As suggested, also checked the Registry value for .css in HKEY_CLASSES_ROOT and this seems ok as below:
Also, ensured that no program is associated with CSS to open.
This is because under default settings, “static content” is not installed with IIS.
To enable this on a Windows Server 2008 machine do the following
Fire up Server Manager
Select Web Server under Roles – notice that Static Content is not installed
Select Add Role Services from the right hand menu
Check Static content and install
i think it works for you
It turns out that there was an HTTP Module which was the root cause of it as it turns out to be a known issue with ASP.NET, IIS and HTTP Module aas mentioned here:
ASP.NET CSS file not loaded when adding HttpModule to web.config
Following this and handling in Http Module explicitly for css, fixed this issue.
Thanks for everyone for taking time out and providing your expert comments
Looks like you've tried everything that seems to have worked for others.
Try setting the output to the mime type through the ASP.NET framework:
Response.ContentType = "text/css";
Have you tested using a load function?
Response.ContentType = "text/css"
Response.AddHeader("Header")
Response.WriteFile("CSS File.css")
Response.End()
Response.Clear()
You should check these things because if IE
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
or
type="text/css" instead of type="css/stylesheet" when importing the stylesheet.
This is one of the strangest things I have ever seen. In the HTML file I have this link tag -
<link rel="stylesheet" href="../../Classroom/engine/repository/PAGE_010100027/css/custom.PAGE_010100027.css">
The CSS is properly loaded and interpreted in all browsers save for IE10. I added the type="text/css" attribute in case the MIME type was somehow wrong -
<link type="text/css" rel="stylesheet" href="../../Classroom/engine/repository/PAGE_010100027/css/custom.PAGE_010100027.css">
Still no dice.
So I copied the file and renamed it wtf.css (just for giggles) and changed the link tag to -
<link rel="stylesheet" href="../../Classroom/engine/repository/PAGE_010100027/css/wtf.css">
It loads and interprets perfectly in IE10. :-/
We can name the file anything we want other than *custom.PAGE_010100027.css* and it will load fine in IE10. Even just changing one number. Does anyone have an idea why this isn't working? I'm stumped and I cannot find anything on the web concerning the naming of CSS files for IE10 and the other couple of hundred CSS files in this project using this naming convention load and interpret just fine. Thanks for any insight!
UPDATE I have confirmed that it is an odd caching issue of some sort. Whenever cache-busting techniques are applied the CSS file is loaded and interpreted correctly. Removing the cache-busting techniques causes IE10 to revert to a much older stylesheet. This only occurs on this one page (out of a couple of hundred).
In reading about related IE10 issues it could be related to the OS (Win8 versus Win7) and this setting: "Use TLS 1.0" (unchecking may solve the issue).
TL;DR
I've read through many questions on Stack Overflow on this issue and I've tried to follow the given advice. Still, my CSS stylesheet will not work in Chrome/Safari but it can work in Internet Explorer.
The only odd thing that I can see about my scenario is my server is returning all files as of type application/octet-stream. I cannot change this aspect of the server. Is there something I can do to interpret my CSS file as a stylesheet in Chrome/Safari and IE?
I have an embedded web server project that I am working on. I have very limited control of the server software and the ability to make page-level settings. All I can do is create static HTML, CSS, and image files that are compiled into the server application.
As such, all files that are returned from the embedded server are declared as application/octet-stream in the HTTP header. This produces warnings in Chrome but no errors.
Initially, I had a problem loading this style sheet in Chrome/Safari but it would work in IE. After reading through a couple questions on Stack Overflow, I found that I needed to change my stylesheet declaration from:
<link rel="stylesheet" href="/styles/index.css">
to:
<link rel="stylesheet" type="text/css" href="/styles/index.css">
When I made this change Chrome & Safari still failed to process the CSS file but IE also started to ignore the stylesheet.
Oddly, if I do not declare a DOCTYPE on my HTML document I can get linked stylesheets to work in all of my browsers. This is, however, not a desirable solution.
My guess is this issue has something to do with the HTTP header declaration and that it doesn't match the type declared in the link element.
What can I do to get this stylesheet to work in Chrome, Safari, and IE while following good web development codes-of-practice (i.e. using doctypes on my HTML files and not embedding the style code in the HTML headers?)
For clarity sake, the relevant CSS/HTML code is shown below.
index.css
html {height:100%}
body {margin:0;min-height:100%;position:relative}
iframe {width:100%;height:100%;border:none}
.hdr {min-width:765px;overflow:auto}
.logo1 {float:left;margin:4px}
.logo2 {float:right;margin:4px}
.menu {position:absolute;top:70px;left:0px;bottom:0px;width:175px}
.content {position:absolute;top:70px;left:175px;bottom:0px;right:0px;}
index.htm
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<link rel="stylesheet" href="/styles/index.css"> <!-- Removed the type declaration so that this would at least work in IE9 //-->
</head>
<body lang="en-us">
<div class="hdr"><img class="logo1" src="/images/logo1.png" alt="Logo #1"><img class="logo2" src="/images/logo2.png" alt="Logo #2"></div>
<div class="menu"><iframe name="menu" src="/menu.shtm"></iframe></div>
<div class="content"><iframe name="main" src="/home.htm"></iframe></div>
</body>
FYI, this is a new project that is being developed from an existing one. The original project did not declare a DOCTYPE on the HTML files. Therefore, all page data was loaded and executed in the browser in quirks mode. Furthermore, the index.htm originally consisted of multiple frames within a frameset.
I am trying to update this application, using correct, and up to date methods for developing web pages. I can make this application work, but I feel that this would be at a sacrifice of future-browser compatibility if I have to rely on browser quirks mode and framesets.
I have tried to close the link tag but that doesn't help. Technically, this shouldn't be an issue since this document is declared as an HTML5 document, rather than XHTML.
It's certainly due to the application/octet-stream content type. I can re-create the issue on my end. Soon as the content type is set to text/css your HTML/CSS load fine.
As a workaround you can use <style> tags for you CSS if you can't get the server to send the correct content type.
I hate to have to answer my own question this way but the problem was most certainly with the fact that the server was returning a content type of application/octet-stream within the HTTP header.
After discussing the issue with management we had to update the code associated with the HTTP processor. This is code that is part of a third-party RTOS and we have been extremely hesitant to making any changes to this code.
However, in this case the need has out-weighed that desire. I've integrated the necessary changes to fix the HTTP header to return a content type of "text/css" for cascading style sheets. All is now right with the world.
I think I'll just chime in here. Not to answer the question, but to confirm the issue and perhaps help people with similar problems.
I had the same problem: an external css file was loaded alright, but it was not applied in Chrome. (Safari and FF were ok about it). So, same problem, slightly different cause.
It turned out that because of a bug in the webserver code the HTTP response contained two Content Types, 'text/html' and 'text/css'.
The solution was to remove the faulty 'text/html' line. It seems Chrome is pickier than other browsers about response headers. Which I suppose is legitimate, but a warning would have been nice.
btw, you can see all the http information for a loaded resource in Chrome, when you open Developer Tools, and select Network. Then click on the file that you want to investigate. (it took me a while to find that)
We had a problems with an iframe wich it's contents was updated by an external javascript routine, the CSS were loaded but were not applied. But updating the body HTML from a routine present in the iframe head worked as suposed to.
This same behaviour was not present in gecko and explorer, but happened the same at Safari browser (webkit)
Hope this could give some light in this curious case.
I would like to add one bit of information that may save some of you some time. It appeared that chrome was not recognizing my CSS either. After reading the above post I reviewed the files in the Developer Tools->Network. Turns out that Chrome was using a locally cached version of my CSS. As soon as I refreshed as opposed to accessing the URL again, it worked!
I'm no expert, but i've made this mistake before, it's rather simple.
You've written:
<link rel="stylesheet" href="/styles/index.css">
If this is a folder in the same directory as your index.html file, then you need to remove the first /. like so:
<link rel="stylesheet" href="styles/index.css">
EDIT: I think someone else mentioned this already, but it may have been overlooked.
Is there some directive I could use in my HTML to tell the browser not to ask for the favicon?
Add this line.
<link rel="icon" href="data:,">
This assigns an empty data URL to the favicon’s element which specifies the location of the external resource. This trick stops the user’s browser from sending an automatic HTTP request for the favicon.
This has some more details
No, I don't think there is. From Wikipedia:
Most web browsers do not require any HTML to retrieve a favicon that conforms to the de facto file name and type (favicon.ico) located in the web site's root. If no favicon link is detected upon HTML page load completion and no previous site visits are recorded in the browser's history, a favicon.ico is requested automatically.[8]
The only thing you could do is explicitly point the browser to a different location (that for example could return a 204 no content)
<link rel="shortcut icon" href="http://www.example.com/my_empty_resource" />
You could try pointing the <link> at a data URL. As commented below, IE will not like this, though.
Example (from 11011.net):
<link rel="icon" type="image/gif" href="data:image/gif;base64,R0lGODlhEAAQAIAAAAAAAAAAACH5BAkAAAEALAAAAAAQABAAAAIgjI+py+0PEQiT1lkNpppnz4HfdoEH2W1nCJRfBMfyfBQAOw==" />
Edited to reflect Pekka's concern regarding IE.
If you are not using HTML and its auto generated by Flask or some frameworks you can always add a dummy route in the app to just return dummy text to fix this issue.
Eg for Python Flask Application.
#app.route('/favicon.ico')
def favicon():
return 'dummy', 200
I've been showing a website to a customer who insists on using IE and found out, to my surprise, that IE7 does not autodiscover the Atom newsfeed.
The feed is linked to within the HEAD element of a valid HTML 4.01 Strict page with <link rel="alternate" type="application/atom+xml" href="atom.xml" title="Atom 1.0">, the link is pointing to the correct URL, the linked feed is a valid Atom 1.0 XML file served as application/atom+xml and contains the correct <link rel="self">.
Firefox, Opera, Safari and IE8 beta 2 all do correctly find out the feed and lighten up the relevant address bar button - it's just IE7 that stays greyed out. Same IE7 had no trouble in discovering newsfeeds elsewhere and to pass the HTML part of DiveIntoMark's autodiscovery test suite with flying colors.
Changing the HREF to a fully qualified URL made no difference, nor did changing the TYPE to a RSS 2.0 MIME or removing the TITLE attribute.
The website address is http://www.monteanalogo.net/.
Any hint about what's wrong here?
I copied your source to my local machine, and IE7's auto-discovery kicked in fine once I changed the href to a full url, rather than a relative one:
<link rel="alternate" type="application/atom+xml"
href="http://www.monteanalogo.net/atom.xml" title="Atom 1.0">
Needing a full URL seems to be an IE glitch, as the RFC on atom auto-discovery states that:
The value MAY be a relative URI, and if so, clients MUST resolve it to a full URI ... using the document's base URI
Microsoft's own publisher's guide also lists the full url in the href tag, but makes no mention of it being compulsory:
Here is an example of Atom Autodiscovery:
<head>
<link rel="alternate" type="application/atom+xml"
title="your feed title here"
href= "http://www.company.com/feedurl.xml">
</head>