If I attach my large background.png image to the html element (instead of the body element) does it adversely affect incremental page load?
Any differently than if I were to add it to the body element?
I ask because it would seem that its presence there might delay the browser’s rendering of the contents of the body element. So, the heart of my question is, "Does a background image attached to the html element have to fully download before the body and its child elements are rendered?
Hi,
I would think that it makes no difference because images that are applied to the body element are actually propagated to the html element by default anyway. That’s why you should avoid applying images to the html element as in most cases its not needed.
Sometimes though you can use the html for an extra image but you then end up shortening the body because the body image collapses to content height because it is not propogated to the html element as before.
e.g.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Untitled Document</title>
<style type="text/css">
html { background:red }
body { background:blue }
</style>
</head>
<body>
<p>test</p>
</body>
</html>
It’s not much of a problem and would be just like using a normal element but most would expect the body image to be repeated all the way down the viewport by default. (In html4 though the w3c recommends not applying backgrounds to html.)
I suppose the real answer would be to analyse your page with y_slow to see if there’s a difference but I can’t see that it would make a difference whethwr it was on body or html.
In another thread (can’t find it now) I found someone wanting to have a repeated image attached to the bottom of the page… and this particular reason meant they MUST put it on the html element, because putting it on the body would have worked, except that there were coordinates other than 0,0 involved. Once the dev tried to align the image to the bottom, the image appeared to really be set on the body element (instead of painted onto the html element), and without 800+ px worth of content in the body, the body was not tall enough. Yeah, the img was like 800px tall.
"Does a background image attached to the html element have to fully download before the body and its child elements are rendered? "
As I understand it, the browser calls the CSS file and needs to at least have called all the bg images in the CSS file before moving on to reading the rest of the document (meaning, stylesheet resources can “block”, just like Javascript in the head does). However it seems to be just that the images need to be called, since once all the calls to the server have been made, the browser continues through the HTML and starts rendering those and building the DOM as it goes. You may see the page loading in front of you before you see the bg image appear, if it’s huge… wouldn’t matter if it were on teh body or html element, because as a background, it’s called from the CSS sheet linked in your <head>. The element itself isn’t dependent on any backgrounds added to it, similar to it will load the element even if the bg image is 404.
It would be interesting to know the exact process that browsers go through as the browser does not fetch all images in the stylesheet but only images that need to be displayed on the page concered (as far as I can tell). That’s why we have sprite rollovers to avoid the delay of a new image being fetched. If a browser fetched all background images in the stylesheet then you could be waiting all day for a large site there could be thousands of images to load and the browser obviously doesn’t load all of those.
AFIK, which is not very much, CSS only requests images as needed to style the existing HTML. If this were not the case we wouldn’t need sprites to stop pseudo element blinking. So the actually question is most likely about the rendering order of the mark up. hoes HTML render before BODY? hmmm. One would assume so , but i am not sure.I had a problem with my ISP which made my cable connection run at 0.0001mps. I noticed my home page would: lay out first, then render bgs, starting with the html/body, and then IMG content. That could have been a fluke tho. Still , if we assume this “linear” rendering order then we would be afraid to load an anywhere as it would delay the next element… and the next … and the next. It’s just not something that you should make your code/functionality dependent on.
I was going to mention about using the HTML as an extra hook for an image along with the body tag… but Paul beet me to it. I will however clarify that the body DOESNT “shorten” this is merely a optical illusion caused by the mismatching colors.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Untitled Document</title>
<style type="text/css">
body { background:blue; border: 1px solid pink }
</style>
</head>
<body>
<p>test</p>
</body>
</html>
You can see by the pink border that even when the color match, the body remains the same height. As Paul stated, HTML {} has the off property of sucking up the bg styles of the BODY{} UNLESS they are specifically overridden. This why it is why it’s redundant to use : html, body {url(image.jpg);} as body {} would have uppard-cascaded its bg to the html style.
as the browser does not fetch all images in the stylesheet but only images that need to be displayed on the page concered (as far as I can tell). That’s why we have sprite rollovers to avoid the delay of a new image being fetched.
Because those are event–based. Which is kinda nice, even though it causes rollover delays.
And, whoops, I did have it wrong, it’s the other way around: until the stylesheet is full loaded, only then are the CSS images called. Not as the browser loads the stylesheet, but when it’s loaded and it begins to parse and match.
How browsers download and render CSS background images.
Firefox rendering and repainting Mozilla.org
Firefox rendering and repainting Wikipedia
I will however clarify that the body DOESNT “shorten” this is merely a optical illusion caused by the mismatching colors.
The body was ALWAYS short. Like other elements, its height is set to auto and is only as large as its contents inside make it.
When the HTML element ends up holding the background image, you get the illusion that the body is actually full-size.
Thanks for the links Mallory and that seems to confirm my understanding that background images are only downloaded when required on the page and downloaded in html order as I would expect. The css file has to be parsed fully first because the browsers would not know how to draw the page until it had all the rules at hand I would assume.
As I said before a browser won’t load every image in the styleheet - it couldn’t possibly do that although I believe very early versions of Opera did just that but were soon changed. (The tests with stylesheets outside the head are interesting but irrelevant because they are invalid outside of the head and therefore should not be used like that.)
Thanks for your insights All. This kind of in depth discussion, in terms easily understandable, is why SP is my go-to reference resource for web dev.