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?
Related
So I read everywhere that CSS is render blocking. Though this is different than the blocking caused by <script> tag as it does not pause parsing of HTML. The browser basically waits for the CSSOM to be constructed and then only render anything to the webpage. Therefore, when CSS is loaded late, it can effect load time for your webpage. But what I don't understand is that if this is the case, how is FOUC (Flash of unstyled content) caused? FOUC is basically when the browser momentarily displays HTML without the styling, and then when the CSS is available, it displays the correctly styled page. So if browser always waits for the CSS to be loaded and parsed first before rendering anything, FOUC should not happen.
if browser always waits for the CSS to be loaded and parsed first before rendering anything, FOUC should not happen.
Indeed, that's what should happen in such a case, except that browsers don't wait for all resources to be loaded before rendering.
Note that this doesn't contradict what you "read everywhere", if you really did read "The browser basically waits for the CSSOM to be constructed and then only render anything to the webpage."
The browser can very well build the CSSOM while it still misses resources, for instance, it definitely doesn't need to load all background-images resources to calculate the elements' box positions.
And it may actually even need to build the CSSOM as soon as the DOM is being constructed because in cases like the below snippet, you need the CSSOM for the js to work:
<h1>test</h1>
<script>
// without CSSOM, we couldn't get its width yet
console.log(document.querySelector('h1').offsetWidth);
</script>
<style>
/* even if it's gonna be invalidated later on */
h1 { width: 300px; border:1px solid; }
</style>
I'm new at Drupal and I'm now administrating an existing site. There's a bug that the home slider asigns a size of 0x0 to its images, so only the pager is displayed.
When you open the website in another browser, it works fine.
What could be the problem? I googled it but non of the solutions I found work.
Thanks,
Brian
First, it's not Drupal related issue, but it's CSS related, so you tagged it wrong and probably googled about it wrong.
Problem can be in:
a) your theme (called "Porto")
b) slideshow module if you are using one
In any case you should (temporary) disable caching of CSS on page (admin menu) Configuration -> Development -> Performace
URL:
/admin/config/development/performance
Then find out what CSS causes this issue, find out what file you should change (user Firebug or some similar tool), change the CSS file, turn on CSS cache again, clear the cache (just in case).
So, Darko's solution can be correct, but definitely there is no point of changing cached CSS file since it will be re-generated in time and you'll loose your change, but it should be applied on correct file. Instead, as I said, disable cache, find the real CSS file, change it there and clear the cache.
Or, since you have access to all CSS files you don't even have to disable the cache, but just find and fix CSS in real file and clear the cache.
Let's say it is CSS related problem but it is not quite correct answer here.
You can see in different browsers different render outputs based on module settings. Issue is on this setting:
element.style {
height: 460px;
position: relative;
width: 930px;
}
element.style values are the values you set up in your module (in this case view_slideshow). In Firefox you get good output (code from above) but in google chrome you got just next code:
element.style {
position: relative;
}
It is a bug for sure and it is a module related because for some reason Google Chrome not read values which are set in module. First you should try to update your slideshow module on latest release. If you still have a problem you can easily fix it via changing CSS file.
#MilanG have a good point because once you clear the cache new CSS will be generated and you will have the same problem. I will try to explain what you should with little more details.
Go on admin/config/development/performance (if you are using drupal 7) and check out option Aggregate and compress CSS files. That will disable caching of CSS.
Open Firebug on your front page and find next line:
<div id="views_slideshow_cycle_teaser_section_carrusel_home- block"class="views-slideshow-cycle-main-frame views_slideshow_cycle_teaser_section" style="position: relative;">
If you use Firebug on Firefox you should find same line (but it is outputted different as you can see):
<div id="views_slideshow_cycle_teaser_section_carrusel_home-block" class="views-slideshow-cycle-main-frame views_slideshow_cycle_teaser_section" style="position: relative; width: 930px; height: 460px;">
Now you find which CSS is used on that line (it should be something like sites/all/themes/your_theme_name/css/views.css )
Find the right line in that CSS and change it like i showed you in my first post.
Clear the cache and now you go back on admin/config/development/performance and turn on caching.
Hope this helps.
You can fix this like this:
Go on sites/default/files/css
Open css_Ad8ea4Il0r-gy2oHf2eZpgamt3p0W3GurWCoZa6MhXU.css
Find this code in CSS:
#views_slideshow_cycle_teaser_section_carrusel_home-block{display:inline-block;}
Replace it with this code:
#views_slideshow_cycle_teaser_section_carrusel_home-block{display:inline-block;height:460px;width:930px;}
Save CSS
I've got a very strange bug in chrome recently that is when you load the page first time, or in incognito mode that none of the background images show.
when you then F5 the page, the background images all load in.
When you inspect the css it shows the image url in the css panel, however when you mouse over the url it doesn't display a tool tip with a preview of the image.
Neither when you check the downloaded resources are there even any mention of the background-images downloading.
you then refresh the page and it works fine, tool-tip of the css url even shows a preview.
The bug only randomly happens on first load occasionally, no way to guarantee to reproduce this.
Also its worth to note, it you untick then retick the background-image property on chrome it then downloads and displays the image.
I've got a piece of jquery that solves the issue but as you can see its hardly very elegant!
$('*').each(function(){
var bg = $(this).css('background-image');
$(this).css('background-image', 'none');
$(this).css('background-image', bg);
});
this happens on every instance of windows in multiple versions of chrome.
any ideas would be great! thankyou!
you might be able to see it happen on http://ensa.ac.uk
here is a video demonstration # http://youtu.be/oLTyhk5rXgE
Just to note.
The problem had been solved.
The issue was that the browser downloads all the css background images last. So if you refresh the page before its finished downloading the images, when the page loads again it loads from the cache. but because the images did not fully download they dont show correctly.
First of all, fix these:
backg1round-color: #c7dfe3;
backg1round-color: rgba(255,255,255,0.67);
If images is a subfolder then use
url('images/logo-bg2.jpg');
instead of
url('/images/logo-bg2.jpg');
in main.css
Try this instead. Not tested though;
$('*').each(function(){
var bg = $(this).css('background');
$(this).css('background', 'none');
$(this).css('background', bg);
});
And make relevant changes (ie, background-image to background) in your CSS also.
OR try;
$('*').each(function(){
var bg = $(this).css('background-image');
$(this).css('background-image', 'none');
$(this).css('background-image','url(bg)'); // or try url("bg") i am confused :P
});
From some search and research I came to a conclution;
The way I would tackle this is with classes. Have a separate CSS classes for each of the states, then simply use jQuery to change the class. This would ensure that all of the images are actually downloaded and available when you set the class -- which is where I think Chrome is failing (probably all WebKit browsers would do this)
Change css class as:
#nav
{
background-image: url(../images/logo-bg2.jpg);
height: 180px;
}
Owen,
I still see this problem on the application that I'm working on. I know this is also a hacky solution, but it's a little less hacky than the jquery solution that you had posted. I simply threw a version number based on time after the css include and it
e.g.
" rel="stylesheet" type="text/css" />
I know that this causes the css to never be cached, but I have not found any other solution.
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.
There is known css cache issue when you change your css, browser is not going to realize it unless time expires and everyone seems to be using querystring like ?version=29347 to update css when it changes on server.
But does img has the same issue? When img changes on server, is browser detects it? or do i need similar implementation for img?
Reason i am asking is because i am writing generic implementation for css and would like to know if there are any standards related to img so that it does not have same problem. Instead of just relying on my testing as i can't test all browser or real work scenario
Yes, images would have the same problem (as would flash, javascript files, or any other media that is cached by the browser).
Using a random dummy query string parameter in your <img src=> or <script src=> tags should solve the issue for those other cases as well though.