SitePoint Sponsor

User Tag List

Results 1 to 8 of 8
  1. #1
    SitePoint Addict Scott Blanchard's Avatar
    Join Date
    Sep 2010
    Posts
    314
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Background image attached to html element delays rendering of body elements?

    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?

  2. #2
    The CSS Clinic is open silver trophybronze trophy
    Paul O'B's Avatar
    Join Date
    Jan 2003
    Location
    Hampshire UK
    Posts
    40,351
    Mentioned
    179 Post(s)
    Tagged
    6 Thread(s)
    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.
    Code:
    <!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.

  3. #3
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,276
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    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.

  4. #4
    The CSS Clinic is open silver trophybronze trophy
    Paul O'B's Avatar
    Join Date
    Jan 2003
    Location
    Hampshire UK
    Posts
    40,351
    Mentioned
    179 Post(s)
    Tagged
    6 Thread(s)
    Quote Originally Posted by Stomme poes View Post

    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. .
    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.

  5. #5
    Community Advisor silver trophybronze trophy
    dresden_phoenix's Avatar
    Join Date
    Jun 2008
    Location
    Madison, WI
    Posts
    2,798
    Mentioned
    34 Post(s)
    Tagged
    2 Thread(s)
    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.

    Code:
    <!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.

  6. #6
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,276
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    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.

  7. #7
    The CSS Clinic is open silver trophybronze trophy
    Paul O'B's Avatar
    Join Date
    Jan 2003
    Location
    Hampshire UK
    Posts
    40,351
    Mentioned
    179 Post(s)
    Tagged
    6 Thread(s)
    Quote Originally Posted by Stomme poes View Post
    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.
    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.)

  8. #8
    SitePoint Addict Scott Blanchard's Avatar
    Join Date
    Sep 2010
    Posts
    314
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •