Image Movement in Browsers


I have two images at the top and bottom of my website, which are coded in my CSS layout as:

[B]“background: url(#) repeat-x top left”

“background: url(#) repeat-x bottom left”[/B]

I noticed that when I viewed the page in “IE” and “Firefox”, the images shift or change size?

I was wondering if I need to apply javascript coding for both images to be in the same position in all browsers? Any help would be greatly appreciated!

Just woke up, thought I’d start in on a rewrite for you that will avoid many of the headaches.

Though really, I would SERIOUSLY consider throwing the entire design away as it’s WAY too image reliant. Right now at 2.1 megabytes you would be shooting the client in the foot by deploying that… the BEST I could get it down to is going to be around 300k (probably more like 350) which is still two and half times larger than I usually consider the upper limit for a single page!

It’s a perfect example of “This is why you can’t just draw a pretty picture in photoshop and slice it up to call it a website”

Much of the problem comes not just from the images chosen, but how you (and how you didn’t) slice them up. The banner.gif for example on top of being an eyesore (no offense) has no real way to be optimized down on filesize smaller than about 40k… If that was split into a sliding doors background with a close-enough AA foreground that might be able to be chopped down even further. With little to no of that ‘wood plank’ image ACTUALLY showing, there’s no reason to be wasting a megabyte on it as a gif, the background-image not only looks silly not fading to black at the corners, but is also ridiculous at 579k, much less the use of the welcome.jpg for plaintext or the 113k ‘under construction’ image that probably could be optimized down to 16 colors/9k.

… and there’s all the javascript for nothing. The 70k of jquery is by itself the size I usually reserve for the ENTIRE page on my designs (images + markup + CSS + scripting)… and for what? Some lightbox bull and javascript to do CSS’ job on the menu? (scripting that frankly should ONLY be sent to IE in the first place)

So first, let’s clean up the markup. In going through I see where most of your problems occurred once I noticed the commenting format. DREAMWEAVER. The only thing that can be considered professional grade tools in regards to Adobe’s web development software are the people promoting it’s use. Do yourself a HUGE favor, throw that bloated pile of manure in the trash, and go get a plain text editor.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

	content="text/html; charset=utf-8"


	content="The Muskie Challenge Fishing Tournament"

	content="muskie,musky,challenge,tournament,fishing,freshwater,lake st. clair,pike,northern"


	The Muskie Challenge Official Website - Home


<div id="pageWrapper">
		Muskie Challenge<br />
		Lake St. Clair

	<ul id="mainMenu">
		<li><a href="index.html">Home</a></li>
		<li><a href="#">About Us</a>
				<li><a href="ourMission.html">Our Mission</a></li>
				<li><a href="ourSponsors.html">Our Sponsors</a></li>
		<li><a href="rulesAndRegulations.html">Rules</a></li>
		<li><a href="prizes.html">Prizes</a></li>
		<li><a href="#">Muskie Info</a>
				<li><a href="muskieId.html">Muskie Identification</a></li>
				<li><a href="measuring.html">Measuring</a></li>
				<li><a href="handlingFish.html">Handling Fish</a></li>
		<li><a href="gallery.html">Gallery</a></li>
		<li><a href="contactUs.html">Contact Us</a></li>

	<hr />

	<div id="content">
		<div class="borderTop"></div>
		<div class="borderSides">

			<h2 class="welcomeTo">
				Welcome to the Official Website<br />
				of the Lake St. Clair<br />
				<span>Muskie <span>Challenge<span></span></span></span><br />
				Fishing Tournament<br />
				November 5-8
				alt="Under Construction"
				Information About the Tournament:
				Our website is currently under construction, annoucements will be made soon...

		<!-- .borderSides --></div>
		<div class="borderBottom"></div>
	<!-- #content --></div>

	<hr />

	<div id="footer">
		&copy; Muskie Challenge - All rights reserved - Designed by Joshua Jorgensen
	<!-- #footer --></div>

<!-- #pageWrapper --></div>


To sum up the changes, switch to strict since Tranny is for old/outdated/half-assed coding, add a bit of formatting to make it clear what’s going on, swing a giant axe at the “javascript for nothing”, trim down the keywords to 8-10 WORDS (it’s called keywords, not keyphrases) and get it down to a reasonable file size – though from a SEO standpoint it still has relevance issues. (description meta still needs a rewrite), get rid of the ‘let’s use six separate stylesheets just to make it harder to code’ nonsense, add in ‘projection’ and ‘tv’ for kiosk and webtv users (who are still out there) and trim off all the fat from the header.

On the body we can get rid of the POINTLESS ID on body, first heading on the page becomes SHOCK the h1, empty span for gilder-levin image replacement. Get rid of the table, get rid of the idiotic comments for leaner comments (that in many ways are clearer!), and then I take an axe to all those “nested boxes for nothing”… A simple content div, a top div for the top border, a div for the sides and a bottom div for the bottom border… When it comes time for the CSS we won’t even declare widths on them since we’ll be constrained off that nice #pageWrapper div.

Inside .borderSides we drop both sections to H2’s, put a class on the unique one that will get gilder-levin image replacement. The first level span sets a huge text, the next level span will be used to move ‘challenge’ to it’s own line and give it some color, the empty span being there as our image replacement. This way images disabled with CSS on the page will look good, and you’ll have sensible markup when CSS is not present as well.

The footer is simple enough to call #footer, and you’ll see some HR thrown in. I use HR as dividers for when CSS is disabled, and set them to display:none for screen. (since I use BORDER as dividers between DIVisions when CSS is enabled).

When it comes to actually putting the CSS together, I think Stevie D indirectly hit upon a lot of your problem. You’re spending too much time declaring widths on things… when for the most part you should be declaring the outer width ONCE and then padding in off it. Apart from the dropdowns on the menu or using width as a haslayout trigger there’s no real reason you should be using WIDTH more than once for this layout!

Oh, and you know 800 wide is not 800x600 friendly, right? Don’t forget to take at LEAST 32px off for browser chrome. Note I’m saying “browser chrome”, NOT the “chrome browser” – aka borders and scrollbars – and real-world 48px is the safest bet – aka 752px!. Just thought I’d mention that since if you’re not going to bother supporting 800 wide users, you might as well do something with the additional 224px that gives you to work with for 1024 support. (or should I say 176px once you account for browser chrome). Of course, I would probably find a way to make that layout semi-fluid, but that’s me; I hate fixed width layouts almost as much as I hate bull like lightbox, jquery, mootools… It’s all a steaming pile of /FAIL/.

Pretty simple. Gimme… five minutes to get food in my belly and another ten minutes to toss together the images and CSS that would go with that.

I fixed the problem using CurvyCorners. It’s a great script, I suggest it to everyone!

“Great script” – that appears to do nothing in opera 10.62 or IE 8. Some solution. Yeah, let’s throw javascript that doesn’t even work at the problem.


The problem with the page in question is the attempt to use wrapping on something that shouldn’t, multiple images for something that can be done with just one image, comment placement proven to trip rendering bugs in IE, tables around non-tabular data, widths that don’t add up properly, etc, etc…

If I have time later I’ll toss together a quick mock-up of how I’d approach that.

I changed the em’s to px’s and I got this result:

It seems like the height of the background image is distorted and shrunk?

Here is my CSS Coding:

#center {
 	margin-left: auto;
 	margin-right: auto;
 	width: 800px;
div.body {
	font-family:"Times New Roman", Times, serif;

#plain_wood {background: transparent url(../graphics/plainwood.gif);}
#fading_woodtop {background: transparent url(../graphics/fadingwood.gif) repeat-x top left;}
#fading_woodbottom {background: transparent url(../graphics/faddingwoodmuskie_bottom.gif) repeat-x bottom left; padding-bottom:200px;}

div.contentbox {

div.information {

h1 {text-transform:capitalize; color:#916130;}
h1.hidden {display:none;}
h3 {color:#bc4535;text-transform:capitalize;text-indent:0;}

#text {padding:0; line-height:20px; color:#000; font-weight:600;}
p.italic {font-style:italic;}
.light_text {font-weight:500;}

p.contactus_short {
#copyright {
	margin-left: auto;
 	margin-right: auto;

You get a similar effect in Opera to Firefox.

The problem is that you’ve defined the size of <div id=“information”> in a combination of px and em, but the background image it has to line up with is a set size in px - so because browsers render font sizes slightly differently depending on software defaults and settings, it’s coming out at a slightly different computed size in different browsers. You need to change the left and right padding on that <div> to pixels.

I know we often recommend using ems rather than px for layout, but this is one occasion where using ems just doesn’t work.

You shouldn’t need any Javascript for that! How much are they shifting or resizing by?
Have you got a live link so we can see for ourselves?

Background images don’t distort and shrink.

The problem with converting the ems to pxs is that your numbers aren’t right.

In the top wood image, you have a white area 731px wide.
You have then set the block that is supposed to fit inside that to be 700px + 17px left padding + 17px right padding = 734px. So obviously it is going to be 3px too wide. But get the numbers right so that the size of the box (including padding) equals the width you want it to be, and it will be right,

Here is a link to the website:

I put the white corners in the background image and they seem to shift by 1px if you view the website in Mozilla Firefox.

They shouldn’t be resizing or shifting – it’s actually impossible for a background-image to change size (unless you’ve screwed with the default zoom) – though their relative position might change based on the width of the browser; a common rookie mistake assuming that everyone’s browser can handle the same width. (this is why usually if it’s fixed width layout I align the background-position “top center” and “bottom center” since then it’s consistent with the centered layout.

Though this is all a wild guess. As Stevie D suggested. No link/example and you’ve tread into “this is why we can’t help you” territory.

Ok, here’s what I came up with.

as with all my examples the directory is unlocked

So you can easily get at the CSS, images and other related files.

Valid XHTML 1.0 Strict, would be valid CSS 2.1 if not for resorting to zoomfix (which is NOT using zoom as a haslayout trigger but instead for a different issue) and some -moz properties for FF 2.x support. Tested working just fine in IE 5.5, 6, 7, 8 and 9 beta, Opera 10.62, FF 2 and 3, and the latest flavors each of Safari and Chrome.

To summarize the CSS.

Start with a reset, hide the HR, set up a sensible body font and centering behaviors.

#pageWrapper lets us set that width ONCE for most of our elements.

H1 and it’s child span are a simple gilder-levin image replacement.

#mainMenu uses CSS to build the menu instead of javascript, we throw the at legacy IE to make it work there, meaning we don’t need no steenkeen javascript for the lions share of visitors.

You can see on the LI I set them to display:inline to remove most of their cross-browser buggy behaviors, and set the anchors to inline-block so we can center them easily with text-align. The nested UL get slid around with absolute positioning, moved off-screen to the left to avoid the screen-reader ‘display:none’ bugs. When slid into place I change the display state so IE won’t “stick” with them showing (aka refusing to hide them when you move the mouse off) and a 50% left with negative margin-left lets us center them under their parent which IMHO just looks nicer. From there it’s just figuring out the web of font and color inheritance.

Content itself doesn’t do much right now. If you have columns on other pages this would likely be where the faux-columns and float wrapping behavior should go.

.borderTop and .borderBottom share a lot of values so we just set those, and then override what’s different for .borderBottom. You’ll notice the image I use for this:

Stuffs it all into a single image file. Top/bottom on the left, right half of the image is the repeat-y part. The image still needs some tweaking as the transition between the corners isn’t smooth, I just did this fast so you can see everything lines up. Putting the white area on the background-image means no headaches with alignment.

.borderSides simply uses padding to push the content in. You’ll notice on all of these I set a white background-color, this is so images off with CSS on the page works just fine (instead of giving the user black text on the body background, which would be bad).

h2 - pad the top to say ‘this is a new section’, font and color – yawn.

.welcomeTo - the first H2 gets a gilder-levin over it, but you can see I played games with all the SPAN to make it a reasonable facsimile again for when images aren’t available.

#footer – ooh, padding. Impressive.

… and that’s it really. Pretty simple layout, pretty simple code. It’s only as complex as you make it.

Still, I’d probably throw the entire concept away as non-viable for web deployment as it’s still 350k, and my usual upper limit for a page comes in around 128k with an ideal of around 70-80k.