I have an image I want to set as a background, with background-attachment: fixed element, but I'd like to set it on two divs, which scroll at different speeds. So as you scroll it 'appears' that both divs are giving little peeks at the same image hiding behind it all. However, it would actually need to be two separate divs with the same image set as the background.
I'm curious, will using the same image twice be less clunky than two separate images? I know the render will be relatively the same, but in terms of the page loading, will It save some performance?
Yes it will, if the URL is exactly the same.
Browsers will cache media resources if the URL is the same, so using the same image in two places is better than using two separate images.
Related
In other topics I've found that IE/FF doesn't print background images by default. Now that's a shame, because background images add some possibilities that are very difficult to reproduce with classical <img> tags:
You can align them both horizontally and vertically
You can crop them if they are larger than the target element (which also enables the idea of CSS sprites)
Now, it's not impossible to do, but it will require me to have different HTML layouts for printing and normal page, and the printing layout will be quite overcomplicated (since I'll have to use <table>s to achieve vertical alignment). Also, the benefits of CSS sprites will be lost.
Is there any hope? I gather that #media print doesn't help, but isn't there something else, maybe browser-specific, that would allow one to say: "Yes, this isn't a normal background, it really needs to be there even in print view"?
Not possible. You would have to some how convert your background images to img or use Canvas. Of course using canvas depends on which IE you supporting.
Its a browser setting which restricts the printing of background images. I think the logic behind it was that the vendors wanted to give the users the option of printing background images and ensure that the web developer could not alter these settings through some sort of script.
As a general rule, background images should be reserved for adding to the page design but aren't essential to understanding the content. Therefore it shouldn't matter if they are missing when the page is printed. If something (such as a product shot) is important, then it should be included as an actual image (which has the added bonus of being more accessible).
Could you look at including the image, then hiding it using CSS and duplicating is as a background image (perhaps dynamically using JS)? That way, you can ensure the image itself shows in your print stylesheet, and you get the benefits that having a background image brings. I've created a very simple example here.
I have recently begun using image sprites and they are definately great for reducing http requests. Is there a point where it becomes bad practice?
Im thinking particularly where a lot of extra markup has to be added to support them. For example, using them for list bullet points, I have to add two or three extra spans to get everything alligned etc.
Theres also the annoying point that you cant use repeating images, so therfore there is always the toss up between one large image as part of sprite or a tiny 1 pixel image used for repeating downloaded on its own.
Im really looking for an opinion on the two situations outlined here + any other general considerations/guidelines for using sprites.
They can often cause performance issues on mobile devices. I'm not 100% certain why (never really dived into the problem), but I'm assuming it's because the mobile webkit is loading a new copy of a relatively large image into memory for every instance of it on the page. Since mobile devices often have very small amounts of RAM, it can quickly cause the page to slow down.
I've run into this issue before when having about 300 "icon" sprites on a page at one time, each pulling from a sprite image that contained about 50 different icons. Going back to "normal" methods of one icon per image (or 2-3 for hover states) solved performance issues on this particular page.
Also, many browsers (mobile and otherwise) will often not 100% respect the clipping of sprites when you slightly resize the page content (e.g. using "Zoom In/Out" on the browser itself). You'll often see little pieces of the sprite next to the one you want to use.
As for your bullet example, you shouldn't ever need more than one extra div/span. You would set a margin-left on the li and position your "bullet div" in the empty space it creates.
That being said, I use sprites all the time because they're convenient, just be aware of a few issues with them. Generally, I have sprites.png, sprites_h.png and sprites_v.png for horizontally and vertically repeating pieces.
Write two simple test pages, use sprites on one, and not on the other. Use a tool like http://www.webpagetest.org/ to measure the performance in a few different browsers. Once you have data, you can make decisions.
I would divide sprites by related elements, like navigation and content-related sprites, so you can benefit from sprites and keep a logical order in your code. Don't forget that readable and understandable code should be a priority (particularly with CSS, it can get very messy) unless you're working on a Google-scale project.
I've observed that often the websites use only one background image which contains multiple images on it. For example, instead of using separately icons, all of the icons are put on one image and then the different parts of image are used in different section.
Is there any advantage to this?
How can this be used?
For example, for the following Stack Overflow sprite, how would I display just one of the images?
The technique is called CSS Sprites. Basically you use CSS's background-position property and fixed height or width for your element.
If your elemnts are fixed width and fixed height at the same time you can freely create a more compact image. See this site for more complex examples.
You are talking about CSS sprites, in which the background position changes on hover. Learn more here:
http://css-tricks.com/css-sprites/
Change the css property background-position.
yes , using sprites is good for website performs because every single component on website send different http request .So, when we use sprites images the http request become less & website performance increase.That rule is also apply on css also less css files less http request. you can yourself with the help of safari web inspector.
for more better performance download "yslow"
And with CSS sprites is also possible to make e.g. menu button hover effect without waiting until second image loads. see
It has the advantage that only one image needs to be loaded so that things like hover (roll-over) effects are faster. The technique is usually called "CSS sprites". Google for it.
It has been common for a while to put two images on one sprite sheet, but the tendency has been moving towards combining ALL of your background images on the same sprite sheet to load just one file for all of them. There's a rather good tutorial here.
I'm chopping up a new design into valid HTML/CSS. This particular design has several images that are very detailed and I'm debating on how to approach dividing them up.
Here is a link to a folder containing the different options I see. There are four aptly named images - bg.brickLeft, bg.brickMiddle, bg.brickMiddle, bg.combined.
I'd just like some input in how other web-developers would break up this design. bg.combined is obviously what the final product needs to look like.
I'm leaning towards bg.combined because 1) less css 2) one http request - but the CSS purist in me is screaming and even wants to separate the gradient into a 3px wide repeatable image.
I'm concerned with the bg.combined approach because it won't look so pretty when loading on slower connections.
How would you approach chopping up this design?
What are the technical pro's/con's you see for these two approaches?
Would you approach it entirely different?
EDIT - Also, the height of the site is static
I'm a fanatic for giving people with wide screens something to look at (you mention static height, but there really is no such thing as static width), so for me, I would make the brick left/right into an image that can be repeated nicely and have a repeat-x applied to it so that wide screen visitors saw more wall.
Other than that, I would leave the center one as my content background in a div centered on the page. So the short of it is, I would do 2 images, the brick as the body background and the patterned 'middleBrick' as my page wrapper div background.
I ended up combining these images, in addition to adding a wider background.
Here is the final result
I have a site that uses a large centered background image, which naturally loads a tad slower than the other elements on the page. For the most part this works okay, but there is also a repeat-x background image that covers the background for large monitors. The only problem is that this smaller file loads first and flashes briefly before the large image loads fully. Is there a way to have the large image load first so it is in place before the repeating background image loads? Thanks!
I don't know whether there is a way to accomplish that but you can use either javascript or jquery to change your dom elements show priority.
There's no way using strictly css to absolutely control the order images load.
The browser will try to download the images in the order they're listed in the css file, so putting your large background iage first will help, but the download time is gonna make it a moot point more than likely.
You could load the larger background via javascript once the rest of the DOM has loaded if it's worth going that far.
I figured out the answer to my own question: Instead of repeating the whole pattern of the upper body, I used only the pattern portion that is where the main content is. This loads quickly and looks natural behind the content while the large image loads. Thanks Aaron for the reply.