My page loads fine then as soon as you hit the refresh button all the styling disappears.
It seems to be specific to chrome. If I look at the network tab I see that my css files returned with 304 Not modified but the type has changed to text/html. On initial load it is text/css.
If I turn off caching everything works fine.
I saw a similar question on here but It was working before and I have not changed servers.
I seem to have narrowed it down to a problem with one css file.
In particular adding a background image.
body {background:#b4dfff url(/images/backgrounds/background.jpg) no-repeat fixed top;
text-align:left;
font-family: Helvetica, Arial, sans-serif;
color: #585858;
font-size: 12px;
}
if I remove the background the problem occurs significantly less frequently.
I tried changing it to
background-color:#b4dfff;
Background-image:url(/images/backgrounds/background.jpg) no-repeat fixed top;
that didn't work
It turns out this has to do with chrome handling the 304 response.
Chrome asks for content and receives a 304 response saying it is not modified.
When IIS returns a 304 response it has content-type in it. Chrome doesn't ignore the content type and looks and sees that the content type has been changed since IIS just returns the default type chrome thinks the file is no longer a stylesheet and doesn't load it.
So in order to fix this we made it reload stylesheets everytime.
I have not figured out an easy way to modify the 304 response so that it does not include content-type.
Here is the google issue
https://code.google.com/p/chromium/issues/detail?id=246875
same exact problem is mentioned here : http://productforums.google.com/forum/#!topic/chrome/zID6uQQfKH8
It seems like a temporary solution could be
turning off ETags and setting no-cache in HTTP header.
I had the same issue.
An easy work around I found was to add "!important" to the end of each line in your css file to ensure it overrides whatever the default css styling was.
I went over the items that kept reverting back to their original styling once the page was refreshed and now they maintain the styling provided in the css file.
An example:
.div {
display: block !important;
margin-top: 10px !important;
}
Related
In Clarity 2, we used the following code to generate a stack view with nested block headers.
<clr-stack-view>
<clr-stack-block [clrSbExpanded]="true">
<clr-stack-label>Leases</clr-stack-label>
<clr-stack-block [clrSbExpanded]="true">
<clr-stack-label>vApp leases</clr-stack-label>
<clr-stack-content></clr-stack-content>
<clr-stack-block>
<clr-stack-label>Runtime expiry action</clr-stack-label>
<clr-stack-content>Never expires</clr-stack-content>
</clr-stack-block>
<clr-stack-block>
<clr-stack-label>Runtime Expiry Action</clr-stack-label>
<clr-stack-content>Content</clr-stack-content>
</clr-stack-block>
</clr-stack-block>
</clr-stack-block>
</clr-stack-view>
After upgrading to Clarity 3, I'm getting a glitch on my sub header where the right part of it is white instead of the background color.
This seems to be because of the following CSS rule. I can probably workaround it...
.stack-view .stack-children .stack-block-label, .stack-view .stack-children .stack-block-content {
background-color: #fff;
background-color: var(--clr-stack-view-stack-children-stack-block-label-and-content-bg-color, white);
}
The question is whether this a bug? Or was I just using unsupported behavior in Clarity 2? You can play with it here
I can't say whether it's a bug, but the following CSS override fixes it.
.stack-view .stack-children .stack-block-content {
background-color: inherit;
}
Moreover, if I remove that style declaration completely (from dev tools), everything seems to work fine, so it seems like that rule was left there by mistake to try to make sure the clr-stack-content|label was white in the body. Heck if I know...
See https://stackblitz.com/edit/stack-view-nested-header-fixed?file=src%2Findex.html
I had thought that TinyMCE was supposed to remain untouched by the Diazo theme, however some CSS from somewhere is leaking in and making certain functions harder to use. One such example is below, the line height on all the rows has become super short, making each row hard to select.
In Firebug, I can fix this by adding a min-height value here, a value set in dialog.css:
.radioscrolllist .list {min-height: 2em;}
However, I cannot find where to actually set this and have it stick. I've tried putting it in the Diazo theme style.css, in ploneCustom.css, and customizing both portal_skins/tinymce/themes/advanced/skins/plone/dialog.css and portal_skins/tinymce/plugins/plonebrowser/css/plonebrowser.css — none of these seem to do the trick though.
Any ideas on how/where to make this fix? The problem only shows up on the Diazo version of the site, not from the unthemed version. It looks like the only CSS files that load on the TinyMCE iframe are:
dialog.css
plonebrowser.css
columns.css
This is what I have in my project CSS to deal with a similar issue, though I find different issues on each project depending on what I do with the general CSS & columns in particular:
/* Fix TinyMCE gremlins */
#internallinkcontainer div.row {
/* Image browser was jumbled */
float: none;
}
#content #internallinkcontainer .list.item span,
#content #internallinkcontainer .list.item a {
/* Link browser was packed too much */
position: inherit;
}
#internallinkcontainer input[type="radio"] {
vertical-align: middle;
}
/* #end */
Which get's my Link Browser looking like this again:
Apart from the Diazo-CSS troubles, it sounds like you might be having trouble with
plone.css getting cached. The following is from the developer manual with amendments by myself that have not yet been pulled in.
plone.css
plone.css is automagically generated dynamically based on the full portal_css registry configuration. It is used in e.g. TinyMCE to load all CSS styles into the TinyMCE in a single pass. It is not used on the normal Plone pages.
plone.css generation:
https://github.com/plone/Products.CMFPlone/blob/master/Products/CMFPlone/skins/plone_scripts/plone.css.py
Note: plone.css is #import-ed by dialog.css which "hides" it from a browser refresh of a normal Plone page, even when Plone is in development mode. This means you may find you do not see your CSS updates within the TinyMCE plugin (e.g. in the link/image browser) whilst developing your theme. If this is the case, then simply do a hard refresh in your browser directly on: /plone.css to clear the cached version.
I just faced the same issue last week. My workaround was adding this in my theme's CSS (the tinymce dialogs are not part of the iframe that contains the content being edited; they are in the main frame):
#internallinkcontainer.radioscrolllist { line-height: auto !important; }
#internallinkcontainer .list.item span, #internallinkcontainer .list.item a { position: static !important; }
(Clearly we should find a less hacky solution, but I haven't had a chance.)
You almost answered it to yourself: You can customize column.css, that'll work, no important-declarations needed.
Additionally this seems not to be Diazo-related, the ploneCustom.css will also not be delivered to the dialog-window in a non-diazo'ed site, hmm.
Today when I wrote css I found that there are some problems appearing. I used bootstrap and darkstrap to design. In darkstrap the body's style is
body {
color: #c6c6c6;
background-color: #2f2f2f;
}
And in my own css:
body {
background: url(../img/11.jpg) no-repeat fixed;
background-size: 100% 100%
}
It looks no problem but the only question is when I switch the page, the page seems to have an asynchronous load (but I didn't refresh the page), first completing the style in darkstrap, then loading my style after 1 second. But I put my css before the bootstrap and darkstrap. And I just not refresh the page.
At last, I quote the body style in darkstrap, when I switch the page again, the body's background-color also complete after 1 seconds, it looks awful, I know the image load may send a http request and its loading may last. But I just switch the page... so where is the problem?
Where are you loading the scripts and css? Is it and the end of the page body?
One way to fix this might be to move the script loading into the page <head> section. When you do this, all of it will be loaded before any body markup. This will ensure that your CSS and the bootstrap css is ready before you see anything on the page. The downside of this is that it might make the page appear to take longer to load.
There could be other reasons, but this is the first thing that sprang to mind for me.
I'm having a weird bug in Chrome, I'm applying the following CSS rule to an element:
#element {
background-color: #0E0F10;
background-image: url(images/the_background.jpg);
}
Now the first time I open a new page containing "#element", the background image isn't shown until I refresh the page cache with ctrl+f5.
I tried adding Pragma, Expires and Cache-control meta tags and it don't make any difference.
The only way to make the image to be shown at the first time is to put the absolute url in this way:
#element {
background-color: #0E0F10;
background-image: url(http://site.com/images/the_background.jpg);
}
Now the problem is that I can't hardcode a site url, I need to use a relative or relative to the root path.
Looking around I found a dirty trick for fixing a related bug in Chrome that coincidentally also fixs this problem: http://blog.andrewcantino.com/blog/2012/02/15/fixing-the-chrome-background-refresh-bug/
Basically when I open the page the first time, all the background images are reloaded through JavaScript and from here on it works fine.
However I would like to implement a more elegant fix or find the real cause of the problem.
I'll appreciate any advice.
try
background: #0E0F10 url('http://site.com/images/the_background.jpg');
also, be sure to add a width and a height to your selector!
use relative path in style rule solve my problem. such as image url is "http://site.com/images/the_background.jpg", and your css file url is "http://site.com/stylesheet/style.css", use "../images/the_background.jpg" instead of "/images/the_background.jpg" in your style rule.
I happened to run into the same problem just before I believe.
Since you haven't accepted any of the answers. You might want to try, what worked for me:
Instead of:
background-image: url(images/the_background.jpg);
Change it to:
background-image: url('images/the_background.jpg');
With ticks... It seems odd, but it did the trick for me. Since all of my url's also had an underscore, it might be related to this, though I am not sure.
Anyway, putting the url in quotes, should make it work.
See that this is old question. But just faced the same problem. My problem was related with z-index. Increased value for example z-index:2000; and now as if all works. Just need to check z-index for other elements
If your file structure is like this
Main Folder
css
img
index file
then type this syntax:
#element{
background-image: url(../img/example.jpg);
}
Wrtie this code your bug will be solved.
I can not explain this at all, but I've put a theme selector on my site. A javascript dropdown box that changes the CSS the site is using.
Theme 7 is a theme that had an image of lights in the background. I didn't think it worked with the rest of it so I changed it to a different image using cPanel on my hoster, hit save, and it saved and changed like any other file.
I refreshed multiple times to get the changes, and scrolled down to Theme 7 to see how the new image looked.
Same image as before.
I tried a new image. Same thing.
....I deleted the line background-image altogether, and then quit out of the browser and restarted it.
The lights are still there.
What is going on??? I'm using Chrome btw. In Safari the image was just straight black. I think I've stumbled on a cursed picture.
Here's the css
body {
font-family: Calibri, Arial;
text-align:center;
*/background-repeat:repeat-y;
background-size: 100%;*/
}
input {
padding: 3px;
font-size: 22px;
}
select {
padding: 4px;
}
/*-----CLASSES-------*/
More stuff here
Try pressing ctrl+r to clear Chrome's cache.
It probably cached the css you were using before in your browser (and possibly the image too?) That's the only answer that makes much sense. You can force-clear the browser's cache of the css by changing the call to the file my-styles.css?abcdefghijkl in your html (or wherever it is you are loading up the styles from).... but manually clearing your cache will work too.
You may want to incorporate a dynamic Cache Control... every time you change the theme with javascript, have it change or reload the cache so your users won't have to continuously clear their own cached files when they change the theme... Depending on what server you are using, you can do this with php and .htaccess or .NET and web.config, im not sure if there is a way to do it with javascript directly..?