When connected over SSL particular styles are getting dropped from the stylesheet. I can't figure any rhyme or reason to it but it's the same styles that are consistently dropped. Perhaps notably, elements that were to be hidden with display:none; are visible. List styles also revert to default browser settings and a couple background images (not all of them) get dropped as well. All URI paths are relative -- both from the page head as well as from the stylesheets themselves.
For example, the following works...
body { background: url(../images/bg-yellowstripes.jpg) repeat 0 0; }
However, the next line does not...
#masthead { background: url(../images/bg-header.jpg) repeat-x 0 100%; }
Anyone have any experience with this that could help the page display properly and avoid the IE mixed content warning? Only affect Internet Explorer btw. Firefox, Safari, Chrome all render the page normally, without any SSL warnings.
It sounds like you're loading your CSS files with absolute paths. For example, if you have a site that is going to be served over HTTP and HTTPS, you should use a relative path instead.
Absolute: (Don't do this, IE will give security warnings when viewed over SSL)
<link rel="stylesheet" href="http://mydomain.com/css/style.css" />
Relative:
<link rel="stylesheet" href="/css/style.css" />
If the style is coming from another domain (such as a CDN), use double slashes instead of specifying the protocol. This will cause the path to inherit the protocol the page was requested with when making the CSS request.
<link rel="stylesheet" href="//otherdomain.com/css/style.css" />
Also, use the IE developer tools. They will tell you exactly what network resources are being loaded from the page under which SSL and not.
As well as the relative path structure, if it is IE9 and below there is a memory limit in the client that if the style sheets are to big it will just stop loading them. I can see this happening if you are caching a bunch of files
If you are loading fonts from another URL (such as: fonts.googleapis.com) please check the preamble in you CSS. Be sure the path also specifies: "HTTPS" in the path. This simple change solved my CSS over HTTPS problem instantly.
OLD PREAMBLE:
#import url('http://fonts.googleapis.com/css?family=Roboto... etc)
CORRECTED PREAMBLE:
#import url('https://fonts.googleapis.com/css?family=Roboto... etc)
Try adding quotes to your css background paths, like so:
body { background: url('../images/bg-yellowstripes.jpg') repeat 0 0; }
Also, I've read the background property needs a specific order of the values (color url Xpos Ypos repeat). So it would be like this:
body { background: url('../images/bg-yellowstripes.jpg') 0 0 repeat; }
Other than that, my styles were dropped too once, when I was loading them over http:// on a https:// website. But since you're using relative paths, I'm guessing it's something else.
It might be a caching problem.
Related
A subdomain http://board.woodstockschool.in will display a content within Iframe from my.woodstock.ac.in.
In the HTTP headers from my.woodstock.acin it does have this entry:
Access-Control-Allow-Origin => http://board.woodstockschool.in
But I'm unable to change the content look using CSS from the board.woodstockschool.in website.
I've tried these as well:
a ,iframe a{
color: red !important;
}
This changes color of all links except for in the Iframe.
There is an array of questions like How to apply style to a div which is inside an iframe of the page? in here but none with CORS enabled.
I've checked https://www.w3.org/wiki/CORS_Enabled#For_Apache but find no mention of css there.
What is the way to apply the css rule from the wrapper site without using any javascript?
What is the way to apply the css rule from the wrapper site
There is no way.
The closest you could come would be to:
Set a query string on the iframe's src and then have the embedded page use server side code to stick a <link> to the stylesheet in based on that.
Use postMessage to send a message (possibly including the URL of the stylesheet) to the embedded page and then have JavaScript running on the embedded page add the <link>.
CORS will not help or hinder you in this. It's entirely irrelevant.
The best way may be the following (in case you control both sites):
1) set the iframe link with style parameter, like:
http://your_site.com/target.php?style=a%7Bcolor%3Ared%7D
(the last phrase is a{color:red} encoded by urlencode function)
2) set the receiver page target.php like this:
<head>
..........
<style><?php echo filter_var($_GET['style'], FILTER_SANITIZE_STRING);?> </style>
..........
I am trying to do tracking pixel implementation where tracking pixel is being loaded from css, not js - body:after { background-image: url(url-to-tracking-pixel); }. While it works correctly in all other browsers, chrome keeps caching that tracking pixel. It only occurs when css file with code is also cached. How to prevent this so that resource in css file would not be cached in chrome?
Put a ?=datemodstamp at the end of any URL to prevent caching. The mod stamp would be a date modified timestamp of the file you are referencing. You'll have to echo this with a script.
If you are already referencing a file with ?a=b and so on, just add &=datemodstamp.
P.S. And I'm pretty sure Chrome caches everything.
EDIT:
This code won't work because nothing's changing. All that's wanted is for the image to be loaded from the server every time.
The solution?
Use an inline image with a current date stamp query.
<img src="tracking.png?=currentTimeStamp" style="position: absolute; top: -1000px; left: -1000px;"/>
It's basically the same idea as before.
I'm not setting display to none because the browser might not download it. So I'm just hiding it with a negative position.
Have you thought of doing <link rel="stylesheet" href=... instead of doing an image?
The site I am currently working on is http://rattscallion.com/ I am focusing my efforts on getting the site to look proper in IE.
I was having trouble getting the frame on the pages (look at /murals.html for the page I'm working on first). IE9 said that the inline-style stated that the background-image was "none," so it crossed out the original background image. I figured it might be getting this from somewhere on the main stylesheet so what I did was make a new frame that only exists in IE and style it only in the IE stylesheet. Unfortunately this also doesn't work...it still says that an inline-style is setting the background-image to "none", but there is no such thing!
I double-checked and this is happening in IE9 standards mode. So why is this happening? Can anyone help figure out how to "force" it over what IE perceives as the inline style?
Well there's your problem:
CSS was ignored due to mime type mismatch
normalize.css
If you check the network calls the normalize.css is received as text/plain instead of text/css. You should install static content (under server roles) in your IIS as for some weird reason it's not installed by default. I'm betting one WHOLE dollar you're using IIS.
You could have just copy pasted the normalize.css into a server side css file so it's not accessed remotely.
I got it working by doing the following:
remove #framePos img{ display: none; } from styles-ie.css
remove unitpngfix.js - the png filter fix was for ie6 and serves no purpose on ie9 (it's actually one of the reasons the frame does not show)
Note: the frame.png pic is place in lots'o'places as background so you should consider a little clean up of the css files
Another Note: unitpngfix.js replaces the frame.png with the clear.gif and places transparency filters on every png element. So tinkering on css will not do anything until you remove the js.
I have a css file that I only want to be visible to Firefox browsers. I thought I was super-smart coming up with
#-moz-document url-prefix() {
#import url("/a-large-css-file.css");
}
...only to find out that #import directives cannot be nested like that.
More details:
The file is heavy, so it's not an option for me to include its
content inline inside the "conditional" as I don't want for it to
affect total request size for other browsers
The file contains a font-face declaration with the font itself
base64-encoded. Why you ask? Firefox does not allow for fonts to be
downloaded from a different subdomain and that's how twe host static
content. There's a nice recap of the issue here and here
If you've looked through the links in the point above, you'd see a
suggestion to add an Access-Control-Allow-Origin http header -
unforunately this is not an option for me given our infrastructure
setup and deployment procedures.
Even more details:
Static content is hosted on a url similar to
resources.environmentN.domain.com while the pages' urls are similar to environmentN.domain.com where N is different across
the environments.
We're have Apache Tomcat running Liferay Portal.
At this stage I'm open to almost any workaround :)
Edit
I probably should have phrased this differently, but I must mention that I'm probably not open to javascript workarounds, the reason for that would be an unstyled content flash even after the resource is successfully cached locally - this would be the case with solutions proposed so far.
My apologies for the confusion!
You should really just bite the bullet and get the server side fixed, since http://dev.w3.org/csswg/css3-fonts/#same-origin-restriction requires the Firefox behavior and the other browsers will update to it at some point.
Detect browser with JavaScript then append stylesheet link if it's FireFox
$('head').append(' <link href="a-large-css-file.css.css" media="screen" rel="stylesheet" type="text/css" />');
I'm building a web site that uses a fair amount of drop shadows and gradients. I can accomplish a lot of this via CSS's box-shadow properties.
Alas, we're still supporting IE, so we need to add background images in those situations.
I could be lazy and just give everyone the background images, but I'm trying to streamline things for those that are using the modern browsers. Ideally, I'd like to have those users not have to request the images.
So, I'm adding an extra class via javascript if the browser supports the box shadow (box-shadowSupport) and my CSS ends up looking like this:
.box {
background: url('myImage.jpg');
}
.box-shadowSupport {
background: none;
[box shadow properties go here]
}
If the HTML ends up looking like this:
<div class="box box-shadowSupport"></div>
Will the image be requested? Or does the browser understand that it isn't needed due to the second style over-riding the background image property?
If the image is requested, I need to rearrange my CSS and javascript so instead of over-riding a style via the cascade, I'll have to swap out the classes so the first isn't even referenced in the HTML.
I believe every web browser will treat this in it's own way - as usual :) My suggestion is to use a web proxy like Charles and see, if the image has been requested or not. And of course, test this in the different browsers.
What you might want to consider is defining the IE specific styles in a separate sheet and loading it with conditional comments, like this:
<!--[if IE]>
<link rel="stylesheet" id="ie-css" href="ie-specific.css"
type="text/css" media="all" />
<![endif]-->
This will only load the sheet with IE-specific settings and you can override the other classes with !important markers. Conditional comments have been around since IE5, and any other browser will ignore the block above.
I would recommend just to skip the shadows in IE.
Most people use only one browser and they won't know that there have to be shadows. It isn't a big deal if the site looks different in different browsers as long they look normal (that means not glitchy).
Otherwise use with a if tag for ie specific css, and you can do drop-shadow there with:
.box {
filter: progid: DXImageTransform.Microsoft.dropShadow(
color=#818181,
offX=5, offY=5,
positive=true);
}
For more about that see here.
I am pretty sure that all modern browsers will load 'myImage.jpg'. Actually, the code you provided described the pure CSS way of preloading images without using javascript :)