All geek questions in one place

The style sheet does not work in Chrome / Safari, but it can work in Internet Explorer

TL DR

I read a lot of stack overflow questions on this issue, and I tried to follow this advice. However, my CSS stylesheet will not work in Chrome / Safari, but it can work in Internet Explorer.

The only thing I see in my script is my server, which returns all files by 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 over the server software and the ability to configure settings at the page level. All I can do is create static HTML, CSS, and image files that are compiled into a server application.

Thus, all files that are returned from the embedded server are declared as application/octet-stream in the HTTP header. This causes warnings in Chrome, but no errors.

Initially, I had a problem loading this stylesheet in Chrome / Safari, but it would work in IE. After reading a couple of questions about stack overflows, I found that I need to change the style declaration from:

 <link rel="stylesheet" href="/styles/index.css">

in

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

When I made this change, Chrome and Safari were still unable to process the CSS file, but IE also began to ignore the stylesheet.

Oddly enough, if I don't declare a DOCTYPE in my HTML document, I can link stylesheets to work in all my browsers. This, however, is not a desirable solution.

My hunch is that this problem has something to do with the HTTP header declaration and that it does not match the type declared in the link element.

What can I do to make this style sheet work in Chrome, Safari, and IE, while following good web development practice codes (i.e. using dotypes in my HTML files and not embedding the style code in the HTML headers?)

For clarity, the corresponding 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 DOCTYPE in the HTML files. Therefore, all of the page data was loaded and executed in the browser in quirks mode. In addition, index.htm originally consisted of several frames within the frameset .

I am trying to update this application using the correct and modern methods for developing web pages. I can make this application work, but I feel that it would be a victim of compatibility with a future browser if I have to rely on browser ghost mode and frame sets.

I tried to close the link tag, but that does not help. Technically, this should not be a problem, as this document is declared as an HTML5 document, not XHTML.

+4
source share
6 answers

I can't wait to answer my question this way, but the problem was, of course, that the server was returning the content type application/octet-stream in the HTTP header.

After discussing the management issue, we had to update the code associated with the HTTP processor. This is a code that is part of third-party RTOS, and we really did not dare to make any changes to this code.

However, in this case, the need for this did not affect. I have included the necessary changes to fix the HTTP header in order to return the content type “text / css” for cascading style sheets. Now everything is in order with the world.

+3
source

This, of course, is due to the content type application/octet-stream . I can recreate the problem on my part. Soon, when the content type is set to text/css , your HTML / CSS loads fine.

As a workaround, you can use the <style> tags for CSS if you cannot get the server to send the correct type of content.

+4
source

I think I'll just call you back here. Do not answer this question, but confirm this question and possibly help people with similar problems.

I had the same problem: the external css file was uploaded in order, but it was not applied in Chrome. (Safari and FF were fine). So the same problem, a slightly different reason.

It turned out that due to an error in the web server code, the HTTP response contained two types of content: "text / html" and "text / css.

The solution was to delete the erroneous string "text / html". Chrome seems to be narrower than other browsers about answer headers. I believe this is legal, but a warning would be nice.

btw, you can see all the http information for the downloaded resource in Chrome when you open the developer tools and select "Network". Then click on the file you want to explore. (it took me a while to find this)

+3
source

We had problems with iframes, the contents of which were updated using an external javascript procedure, CSS were loaded, but were not applied. But updating the HTML body from the routine present in the iframe head worked like suposed.

The same behavior was not in gecko and explorer, but the same thing happened in Safari (webkit)

Hope this can give some light in this curious case.

+2
source

I would like to add one bit of information that may save some of you for a while. It turned out that chrome did not recognize my CSS. After reading the above record, I looked at the files in Network Tools-> Network. It turns out that Chrome used a local cached version of my CSS. As soon as I updated, rather than accessing the URL again, it will work!

0
source

I am not an expert, but I made this mistake before, it is quite simple.

You wrote:

 <link rel="stylesheet" href="/styles/index.css">

If this is a folder in the same directory as the index.html file, you need to delete the first / . So:

 <link rel="stylesheet" href="styles/index.css">

EDIT: I think someone else has mentioned this already, but this may have been missed.

0
source

Source: https://habr.com/ru/post/1445540/

More articles:


All Articles