Sitepoint Members,
I checked my code to make sure which image is called for second in the code (background image is called for first). Unfortunately, the image I programmed to be called for third is, acording to http://www.webpagetest.org/ charts being loaded second. I need the image I programmed to appear second to be loaded second. In other words image B that appears at the bottom of the web page is being loaded before Image A, which is at the top of web page. Have any idea what’s going on?
Are you talking about the code source order background images in the css or the source order of html images?
I would guess that background images (and normal images) will usually be loaded sequentially according to the element they apply to starting from the top of the dom and downwards so images at the bottom of the DOM will obviously get painted last. However some aspects will be asynchronous so smaller file size image may be loaded first and displayed while the browser is still fetching the larger image.
The question is somewhat changed now because someone showed me there’s an error in the website that I was using that listed the sequence of images being loaded - the images are being loaded in the right order.
I still have the white flash.
What I did that resulted in the white flash is get rid of the CSS file and put it’s contents in the php file I use for all the initial code of a website.
Someone reasoned that the flash is because the change caused my site to be cached as an image by the webhost server and is not a collage of graphics and text. Last night I remembered that a long time ago I had this flash and it went away after about a week. Any thoughts?
Are you “importing” the css files? If so use the link element instead as import is slower and loads differently giving a flash of unstyled content. Not sure if that’s what you meant anyway.
Paul,
No importing. I have the first lines of code for each page in a php file and the php file is called for in the html.
In that same php file I have the css code.
<style type=“text/css” media=“screen,projection,tv”>
css code
</style>
Is the site online and what is this white flash that you see? There will always be a delay while the styles are propagated to the elements concerned and it is never instant.
Paul,
I decided not to use the css file anymore. It takes too long to load. Caching is becoming another word for stale. If I make a change to my css file, visitors won’t see the change until the htaccess expiration occurs and if the date is shorter than a week it won’t cache anyway.
Your missing the point a bit there and you are making visitors download the whole css file on every page of your site so they have the same wait while the page and the same css has to load again. CSS should always be external unless it was perhaps a splash page viewed once (or never hopefully). Why do you think that everyone uses external CSS files?
I had a look at the link you sent via PM and the only flash I see is the default white background before the body background image has time to get loaded and then repainted. If you had a heavier page you would actually see other components also being load sequentially anyway so the odd flash wouldn’t be anything to worry about. You only have text on that page so the only thing you will notice is the background image.
You should anyway put a coloured background behind the image to lessen the effect.
e.g.
body{background:#9F9FFF url(/a.jpg) repeat 0 0}
What you had in place originally meant the background colour was replaced by the image and the background was reset to transparent.
What I have is
body{background:#9F9FFF;background:url(/a.jpg) repeat fixed}
What you have is
body{background:#9F9FFF url(/a.jpg) repeat 0 0}
I took out the semicolon and the “fixed” and put in 0 0 and the result was no background at all, just white.
Then I kept the semicolon out and put in “fixed” and got the same result.
Then I put the semicolon in and put in 0 0 for fixed and the background came back, but I still get the white flash.
What are the advantages and disadvantages in 0 0 versus “fixed”?
You were saying
Your missing the point a bit there and you are making visitors download the whole css file on every page of your site so they have the same wait while the page and the same css has to load again.
But that wait is shorter than the wait for searching for and openig the CSS file. At the bottom of FF browser with Firebug there’s a loading progression field and when I use a css file that progression stops right in the middle waiting to find and open the css file. There’s no such searching and waiting the way I’m doing it.
With my way the text loads long before the background. We still don’t know what’s happening with the white flash becaue my eyes and brain see the white flash not for the whole page but just where the background image goes (like a picture frame) - the solid blue, which is what’s not the picture frame, doesn’t flash white at all. Assuming this is true, how come we can’t get the picture frame painted blue just as fast as the blue that’s not the picture frame? I guess I came full circle on this because I think that’s what your code above was trying do. Unfortunately, it’s not doing it.
The background property shorthand so what your rules are saying is this:
background:#9f9ff;
That says I just want background colour and none of the other background properties at all. All the other properties not mentioned in the shorthand will revert be their defaults (e.g. no image please).
Then you are redefining the background again.
background:url(/a.jpg) repeat fixed
This time you are saying I just want a background image that is repeated and fixed but I don’t want a background colour.
I said:
body{background:#9F9FFF url(/a.jpg) repeat 0 0}
Which says give me a background colour and a background image and repeat it for 0 0. Just add fixed in the mix if you want it fixed.
When you use shorthand all rules that you don’t specify revert to their defaults so you must take account of this.
You were saying
Your missing the point a bit there and you are making visitors download the whole css file on every page of your site so they have the same wait while the page and the same css has to load again.
But that wait is shorter than the wait for searching for and openig the CSS file. At the bottom of FF browser with Firebug there’s a loading progression field and when I use a css file that progression stops right in the middle waiting to find and open the css file. There’s no such searching and waiting the way I’m doing it.
It may be fractionally shorted because of the http request for the linked css file but only on the first page. On every other page you are making users wait far longer because the css file is not cached. On large sites that would be unbearable. For a one page site it doesn’t matter and you could embed the css if you wanted.
With my way the text loads long before the background. We still don’t know what’s happening with the white flash becaue my eyes and brain see the white flash not for the whole page but just where the background image goes (like a picture frame) - the solid blue, which is what’s not the picture frame, doesn’t flash white at all. Assuming this is true, how come we can’t get the picture frame painted blue just as fast as the blue that’s not the picture frame? I guess I came full circle on this because I think that’s what your code above was trying do. Unfortunately, it’s not doing it.
We do know what the white flash is and that’s the time it takes to load the image and repaint it many times down the screen. If you had used the code I gave you you would not have noticed the white flash because the background would have been blue first and then the image repainted on top of the blue which is less noticeable.
If you use an external stylesheet the image will be cached an most likely other pages will display without the flash - although they will still have to load some things of course.
Just click Crtl F5 on any website with a background image and you will see the same white flash. You are making an issue out of something that is not really an issue :). Pages have to load and cannot load instantly and cannot really load exactly in the order that you decide. You could hide the page with JavaScript until the whole page is loaded but that creates a more noticeable delay as users like to see something on the screens as soon as they click. If I see a blank screen or a loading image I’m off somewhere else before it loads ;).
Paul,
Hey that code works ever so great. Thanks. No white flash at all !! I tried and tried to make it occur but no white flash (no blue flash either that I could see).
When you say shorthand are you saying when I use background instead of background-color? That would mean if you’re not aware of what the defaults are, completely avoid shorthand to avoid unexpected results.
That’s the only shorthand I know of in
body{background:#9F9FFF url(/a.jpg) fixed repeat 0 0}
-second-
Paul,
I really think you fixed a problem I didn’t know I had with the code I’ve neen using for about the last five years: Body {background:url(/a.jpg) repeat fixed}
because with what you have
body{background:#9F9FFF url(/a.jpg) fixed repeat 0 0}
the page loads very fast, even on a wireless computer.
Would you say that five years ago I should have had at least
body{background-image:url(/a.jpg) repeat fixed} instead
and so was having default problems I didn’t know of and the default problems were slowing loading all this time?
I don’t really think your error has anything to do with the speed of loading as css rules are parsed and you end up with a result so even if you add loads of the same styles only the more specific wins out.
That rule will fail because because “background-image” is not a shorthand yet you have added background-repeat and background attachment properties to it so it will fail. see the reference for more information.
Shorthand is very useful and when you say things like:
border:1px solid #000
You are actually defining border-width, border-style and border-color which themselves are shorthand for border-top-width and border-top-color and border-top-style and so on for the other edges. So without shorthand you would have 12 rules to border a box instead of one.
You just have to remember with shorthand that the things you don’t define will be returned to their default.
e.g.
border-left:2px solid red;
border:1px solid blue;
All the borders will be blue.
Shorthand will save on rules so on a large stylesheet using shorthand will make a big difference.
Paul,
On your refertnce page it shows: background: {background-color background-image background-repeat background-attachment background-position …
So if I have just “background” the browser has to figure out which sort of background I’m talking about.
so if I have
background-image:url(/a.jpg) repeat fixed the browser knows the type of background is image, but I had
background:url(/a.jpg) repeat fixed so the browser had to figure out whch type of image. Where if I hadbackground-image 5 years ago, the browser wouldn’t have spent time figuring out what type of backgtound I was talking about I guess defaults set in with shorthand and then the defaults are changed when the browser sees background specific infornation like url(/a.jpg) repeat fixed. That takes time.
Whether you do it longhand or shorthand the browser will still need to take into account the defaults so there will be no difference in processing except that longhand rules will bloat the stylesheet and thus take longer to download. The browsers has to get all styles rules from all sources (user stylesheet, UA stylesheet, author stylesheets) and then orders them according to specific criteria to finally arrive at a set of rules that apply to an element.
I would hazard a guess that shorthand rules would parse quicker than a set of longhand rules but in nearly all case this would never be noticeable. There are selectors that slow pages down and you can read more here but in normal use they would rarely have an impact.
Paul,
You say “If I have
background-image:url(/a.jpg) repeat fixed the browser knows the type of background is image…”
What if you have the shorthand version background:url(/a.jpg) repeat fixed the browser knows the type of background is image
Isn’t it true the browser has to figure out what kind of background that background is? If so then that takes time. So I would think no short hand is faster.
You cannot say “background-image:url(/a.jpg) repeat fixed”
That is invalid and will be ignored by the browser altogether. It just looks at it and sees it is invalid and so skips to the next line. You cannot add repeat and fixed to the background-image property. You can only add them to the shorthand “background:” property.
What if you have the shorthand version background:url(/a.jpg) repeat fixed the browser knows the type of background is image
Isn’t it true the browser has to figure out what kind of background that background is? If so then that takes time. So I would think no short hand is faster.
No to paint a background the browser needs to know what all the values are anyway otherwise it can’t paint it. Whether it gets the values from you or from its various defaults (UA stylseheet, inherrittance and the cascade) it will still have to work out what the values are and then determine the specificity so it can apply the rule. If you only supply the background image then it still has to manage that with the other defaults for that property which it will gather together and then apply the style.
Any difference in css algorithms for that aspect are unlikely to have any negative impact on performance. What slows down performance in non specific selectors as mentioned before and even then it is only an issue on large sites. In most cases you can forget about speed issues with css and concentrate on using clean code that does what you want with minimum effort. Shaving 1k off you image would make more impact than messing about with css efficiency .
But that doesn’t mean write bad long winded code. Keep the css short, use shorthand and use short paths (don’t over qualify selectors).
Paul,
Now that I don’t have a css file, the line at the bottom of my php file @media print{body{display:none}}
won’t work in the php file. I can’t understand why since I have <style>…</style> in the phph file.
Any ideas? @media print{body{display:none}} is css code, so it’s not like I can put it anywhere.
There can only be one value for background image.