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.
Related
I'm currently developing a complex print style sheet which is in some ways different from the HTML currently displayed on screen. I've hit a hurdle with a balance between performance and achieving the desired layout.
Basically there is a gallery of images which are loaded via javascript on the fly. Images are built dynamically via JS and output to the DOM on each request for the next image.
My problem lies in that I need to build this for printing purposes. I think I'm left with a scenario where I will have to build additional html on the page just for the print page to look correct; that isn't so much of a problem, except the images are rather big, and even using "display:none" and media print { display:block; } won't prevent the images from being downloaded on desktop devices behind the scenes by the browser. In essence I need them to stay dormont on screens, and come to life using print styles.
I had considered using the css background-image property - which I believe doesn't cause the image to load in the browser, however background image doesn't seem to reliably print across different browsers.
I've also tried using onbeforeprint javascript, but again, this is mess of browser inconsistency.
Can anyone suggest any sort of solution for this? at the moment it seems like I'm going to have to suck up the additional overhead of all the images to achieve reliable results.
If background images are an option, you could prevent the download of those when setting the parent element of the image container to display: none
Example HTML:
<div class="invisible">
<div class="img-container">
</div>
</div>
Related CSS:
.invisible {
display: none;
}
.img-container {
background: url(img.xyz);
}
#media print {
.invisible {
display: block;
}
}
Apart from that a similar question had been asked: Prevent images from loading
May be that will help you, if background images are definitely NOT an option.
I've come to believe that there's two things happening. Firstly, if you want to preload a url, you can do this:
body:after{
content: url(http://www.example.com/img/img_1.png) display:none;
}
But as far as I know, this doesn't help in this case:
body:after{
content: url(../img/img_1.png) display:none;
}
In this latter case, the image is already local, so it doesn't have to "download" it? Is that true? Or will the first bit of code cache the image even more?
I ask, because even though I do this, and I then transition to another page, using jquery mobile, the next page still takes a few seconds to load the background image. Even though it's a local asset.
How do I get around this?
From the tests I've done, it seems that two things can cause a delay when loading an image:
When the image needs to be loaded from a URL, or
When the image is locally located, but needs to be placed on the display screen
What i didn't realise is that with PhoneGap, even with the images local, it might take a little while to load. This is what was causing issues for me. Well, this and the fact that I was loading from URLs. So in my case I used the "CSS3 Caching Plugin" like so:
jQuery(function($) {
$.preload.images(document)
});
This solved my problem of loading images that was in the CSS file. But then for my own convenience, I added a section to the css file for locally cached files. Like so:
#cacheMe1 { background: #ffffff url('../img/img1.png') 50% 50% repeat-x; }
#cacheMe2 { background: #ffffff url('../img/img2.png') 50% 50% repeat-x; }
#cacheMe3 { background: #ffffff url('../img/img3.png') 50% 50% repeat-x; }
#cacheMe4 { background: #ffffff url('../img/img4.png') 50% 50% repeat-x; }
etc
This solved caching for most images, plus it allowed me to still keep URLs as loading in the app (i have a gallery section where its currently acceptable to see the images load, rather than on display).
What I also did that seems to be working, is that I use the "InAppBrowser" plugin to preload entire pages by opening them in a hidden window:
var ref = window.open('http://www.example.com', '_blank', 'hidden=yes');
If you open a bunch of files on load of the app, it seems when you either open these URLs again, or switch to the window with:
ref.show();
So there's two decent ways I've found to cache files that works perfectly for my scenario. Hope it helps someone else!
I do not know if I understood well, but maybe it can useful for you:
<img src="my.png" onerror="this.src = 'image-not-found.png';" />
When I was facing problems with preloading images I had to abandon an idea of using display:none; cause it didn't work properly (as long as I remember the browser refuses to load content of invisible elements in order to speed page load up and reducing the traffic). Instead I created a div that in browser's opinion was visible, but it had zero width and height. Required images I load as background-image for this block. The whole trick is that background-image property can take multiple values. The CSS will look like this:
#preload {
height: 0;
width: 0;
background-image: url(image-1.png), url(image-2.png);
}
So you don't get mess in the markup. Hope this trick will work in your case.
You don't need to attach the image to the DOM directly, therefor there is no need to use css to hide it. Use JavaScript to preload images.
var image = new Image();
image.src = "yourfile.jpg"
you can then provide a longer term solution using appcache.
So my site is locked at the top of the browser which is correct, however when I hit reload (command + R) on this gallery page it now vertically centers everything which is not what I want. It's a template based site (squarespace) with stuff I have added.
I added this css:
#canvas { top: 0 !important; margin-top: 0 !important;}
and this HTML
<script type="text/javascript">
window.onload=function(){
document.getElementById('canvas').removeAttribute('id');
document.getElementById('canvasWrapper').removeAttribute('id');}; </script>
When you first load the page, you have a div (with ID something like "yui_3_10_1_1_1376940471763_412") that has no inline styling. So everything looks fine.
When you reload the page, that div no longer has an ID, and instead has an inline top margin added to it, apparently by Javascript, which pushes your site down.
Meanwhile, your code makes no sense. You've applied CSS to the div with id="canvas", and then used Javascript to remove that id, giving your CSS nothing to apply to.
Having removed that, your page is also throwing a JS error because a SquareSpace function in site.js is looking for the IDs you've deleted.
I'd try removing your added JS (leaving "canvas" and "canvas-wrapper" intact). Your CSS (with the "!important" tags) should override any inline styling that SquareSpace adds.
There are two CSS files referenced on the same page: A generic.css file and a custom.css file. The generic file has default styles in it that are overridden by the custom.css file for the same elements. This allows users of the site to customize or "skin" their pages without needing to recreate the entire generic.css file. Only a few styles would be overridden.
My question is the following: If the generic.css file has a style for an element with a background image and that same style is overridden in the custom.css with a different background image, is the first image ever downloaded by the browser?
Also, I want to find out if this is bad practice - customizing or "skinning" a generic CSS file with another custom CSS file to override a few styles, including specifying different background images.
While not totally definitive, this site ran some tests regarding this. The significant statement from that site that is related to your question is:
CSS images are kicked off not in the order in which they appear in the
CSS but in the order in which they’re called in the HTML. I’m not sure
of the precise moment when the download is initiated, but my guess is
that it happens just after the CSS rules have been matched, when the
property values are assigned to the DOM elements.
This at least tentatively confirms what I thought I remembered in the back of my mind reading on this a few years back, namely, that background images which are not ever displayed (as in the generic.css images being overridden by the custom.css images) are not ever downloaded.
Further confirmation of this would be the typical image preloader script that used to be so common prior to sprite images (and is still found in certain uses). It was designed to download images that would be used on :hover in css, because without it, the image would not load until the first hover was initiated, and this caused an unsightly delay. So that, also, argues for the fact that unless actually displayed (or preloaded), the background images themselves are never loaded.
I don't think there are generally any issues with "skinning," unless you are essentially overwriting most or all of the generic.css with custom.css, then one could argue, why load the generic at all. But as you said, normally there are just a few styles overwritten.
I think i answered NO and NO BAD PRACTICE. Because when the css file readable / executable by the browser, the browser will make comparisons to find the same value or the difference between css file and then combine them.
Easy example:
css1.css on file there is a line:
.test {display: block; width: 100%; height: 600px; background: #991100 url("image1.jpg") center top; border: 1px solid red;}
then the css2.css there is also the line:
.test {background: #991100 url("image2.jpg") no-repeat center center;}
the result of a combination that will be executed and run by the browser are:
.test {display: block; width: 100%; height: 600px; background: url("image2.jpg") no-repeat center center # 991100; border: 1px solid red}
where the "background: # 991100 url("image1.jpg") center top;" read but not called / executed by the browser.
Far as I know the value of the file css1.css be stacked by the value of the css2.css. What if there a css3.css file? then the file css3.css will also stacking on the combination of css1.css and css2.css.
Hope it helps.
I have an issue where the screen goes white for a millisecond on a redirect when rendering the new page.
This causes the screen to flicker and annoys me so.
I have had a little scoot round the web and have found this IE solution which works on IE however it does not on chrome or FireFox.
<meta http-equiv="Page-Enter" content="blendTrans(Duration=0.0)" />
<meta http-equiv="Page-Exit" content="blendTrans(Duration=0.0)" />
Plus I'm sure using this method will have some knock on effects on update panels and Ajax controls.
Is there a way of setting the server to render the full page before giving it the client so not to have this white millisecond that works for all browsers.
Any ideas will be welcomed.
Is there a way of setting the server to render the full page before giving it the client
short answer: no. that's how a web browser works.
even with the fastest possible servers (using statically cached pages as you describe them), you're only decreasing the average "white" time, not eliminating it all together. as you're seeing with IE, that default page transition is part of the browser code, not something the server-side gets control over. if you write your own browser, you can write it to wash black, wash white, or hold the transition until the entire page is loaded, like IE does.
as other people mention, getting your page size down will decrease the "white" time. this time is not only the time the server takes to generate the page, but also all the network travel time for the page, images, javascripts, css, etc. that's why you can never fully get rid of it - only hide it using browser tricks.
and i'm not talking about "client-side" anything. that won't work. the "client-side" code isn't even downloaded, much less running, when the browser decides to white-wash the canvas. it's kind of a standard part of "the internet" that everyone just gets used to; it wasn't designed to be a slide show viewer or a graphically perfect renderer. unfortunately, if you care about transitions that much, HTML is probably not the right medium for your work.
The MSDN examples recommends to set
Response.BufferOutput
before calling
Response.Redirect("http://www.mydomain.com/default.aspx");
You may also want to try to use
Server.Transfer("default.aspx", true);
What you're seeing is a normal occurrence. Here is what happens during a redirect:
The server sends a response to the browser (redirects are done on the client side).
The browser loads the response, sees that there is a redirect and stops the page load
The browser loads the new page
The meta tags you are using are IE only, and will not effect any other browser. The only things that will remove the flicker all together will be one of the following:
You said that the redirect occurs when the user clicks on a button or on a grid row or something. If this were to trigger a change to location.href instead of a post-back, then the user would not see the browser flicker.
Use Server.Transfer (this will result in the browser's address bar showing the old page instead of the new page (a redirect will change the address bar). This will only work if you are redirecting the user to a page on the same server.
Send an HTTP 301 response (Moved Permanently). Tis will remove the flicker, but use this method with caution. It has other effects (it may effect search engine rankings).
To do #3, use this code on the server.
Response.StatusCode = 301;
Response.StatusDescription = "Moved Permanently";
Response.AddHeader("Location", "NewLocation.aspx");
By default the server will buffer the complete response before sending it. The "white" will be a result of the content of the HTML possibly its size. Use a tool such as firebug or IE Developer Tools (my preference is Fiddler) to examine the generated content. At a guess you have some very large ViewState.
Sorry, am late at party! I have been grappling with this on my apps for long. The solution I have devised works for me. Very much like what #Pike65 suggested...
Create a holder for an overlay:
<div id="overlayContent" class="overlay">
<div id="loaderContent" class="loader">
Loading...
</div>
</div>
CSS for this holder:
.overlay {
position: fixed;
border: 0; margin: 0; padding: 0;
height: 100%; width: 100%;
top: 0; left: 0;
background-color: #272727;
text-align: center; vertical-align: middle;
z-index: 900; display: none;
-moz-opacity: 0.1; opacity: 0.1;
filter: alpha(opacity=10);
}
.overlay .loader {
position: relative;
width:40%;
margin: 20% auto;
padding: 10px;
background-color:black;
border: solid 1px gray;
color: #cccccc;
font-weight: bold;
}
Javascript (jQuery):
$('a, input[type=button]').live("click", function (e) {
$("#overlay").show().css({ opacity: 0.1 }).fadeTo(UxSpeed, 0.8);
});
That's it. You may modify the 'js' to your liking. It will cause a translucent overlay to appear whenever any link or button is cliked. By browser's nature, it will wait until it gets a response for the new page (headers). So it won't vanish the current page until at least something is returned for the new page. Once new page starts appearing, it will automatically remove the overlay!
Probably best to do it on the client side. For example, you could have a div that covers the entire page and fades out once the DOM has been fully put together. In jQuery, something like this:
$(document).ready(function() { $('#overlay').fadeOut(); });
From a UX perspective though it might be a little disconcerting. I actually prefer a little bit of flicker so I know things are happening.