IMG tag in div tags problem

Well, I see the strangeness in IE7 (IE6 does it too, plus the search button is dropped down under the search bar).

Since it's a value, it should sit in the input... setting that image as the background of the form is a clever way of doing it, but you're positioning of the real input is wonky:
float: left;
position: absolute;
you have to pick one, is it float: left or position: absolute? Since you listed position: absolute lastly, that's what it's doing. And in IE there is sometimes more trouble with abso po than in other browsers... I'm guess that's why it looks okay in FF1.5 here.

I wouldn't set the form to display: inline. A form is normally a block, and it's okay to keep it that way. I'd keep it a block, and set a width that's wide enough to accommodate all your stuff (the stuff inside is what will be inline I meant). You try a width and check in all browsers until the width works for everyone.

form {
width:... I dunno, try 250px or something... ;
you could also float it to the right, to make it hug the right side of #header box;
and set that searchbar image as a background here on the form... position it to your needs with background-position property.
}

then the inputs and stuff should be inline (which they normall are anyway)

form input {
display: inline; (just in case... like I said they should already be inline)
other stuff;
}

I think possibly the search button is dropped down in IE6 because it sees the input being floated and then abso-positioned and maybe is trying to double the margins anyway.... not sure. When you float stuff, sometimes IE6 doubles the side margins on it. If you see that, you can safely add display: inline right after the float declaration and only IE6 will see it (other browsers ignore it), and somehow this removes the bug.

If you are still going to absolutley position the searchbar input (and you can, though I would try to not do that if normal positioning can acheive the same effect), then I think the parent (form) needs another declaration:
form {
position: relative;
width: whatever;
float: right if you want;
other stuff;
}

Position: relative makes Form the nearest positioned parent, which abso-po'd stuff uses as a reference. Now the stupid thing is, I've had h1's inside headers which were the same dimensions, and position: relative on the header should have been enough to position an image absolutely... and it was, in all modern browsers, but IE didn't work right until pos: rel was added to the h1 (which was the direct parent of the image in this case). So, that may solve the IE problem even if you didn't change any other code you currently have. However, if you look at your page with Aardvark (a Firefox plugin tool that can give you a vague idea of where elements are on your page when you can't see them), you'll see that the bookmark, searchbox and search buttons are NOT fitting in the form like we want, I think because you've set it to inline and then you have that floated/abso-po'd box in it. So I think you'll need to rewrite it making form a block again etc.

Re the menu, you are floating your a's, which normally corrects bugs in IE (by the way, if you're floating something, you DON'T need to say display: block because stuff that's floated is already made into a block... this is why saying display: inline on a float works to fix IE6 without screwing up other browsers-- they know floats are blocks and not inlines already : )

You might need something as simple as overflow: hidden on the ul:

#menu {
	margin: 0;
	padding: 0px;
	list-style: none;
       [b] overflow: hidden;[/b]
	}

Code (markup):

Check in all browsers after adding this-- it's very nice to use, but even if it does solve the problem, it can have some unexpected effects!

If you'd had a universal reset of margins and padding at the top of your CSS sheet (instead of saying the body has no margins or padding) then you wouldn't need to keep resaying it on your menus. I use
* {
margin: 0;
padding: 0;
}
And I've had good luck with this even on my forms, however there are reports that forms can get inaccessible if margins and padding are removed from the form controls like input, label, etc so you can set a more complicated reset instead... in place of the * you'd list every element you use, except the form controls. It's longer, and I don't use it, but Dan does and seems to work for him fine. I've found that even leaving default margins and padding on form controls means they will not position the same cross-browser (duh, I guess) and so I zero the suckers anyway.

You've given the ul an id of "menu" so you just need
#menu {
blah
}
your current declaration of #menu ul actually is saying "any unordered list inside the element called "menu", so, the ul inside the ul. Which you don't actually have.

You can do this:
ul#menu {
blah
}
instead if you want to keep it clear that #menu is a ul, but it's not necessary.


*edit
If you want to go for it with accessibility and do like Dan does, with fieldset and legend in place of that div, you can do this:
<form ... stuff...>
<fieldset>
<legend><span>teh search formz</span></legend>
rest of form...
</fieldset>
</form>

and then in CSS, near the top:
fieldset {
border: 0;
}
which pretty much means you won't see it at all : )

And for the legend:
legend span {
left: -9999em;
}
or whatever, a gazillion pixels to the left will do it too... I didn't use display: none because, and I dunno why as this is stupid, but we have the legend pretty much for screen readers and those who can't see the set-up of the form, right? and many (all?) screen readers, if browsing through a normal, CSS-enabled browser, will honour that, and the screen reader user won't hear the legend text! Stoopid, but that's how it is.

 

Thanks for the comprehensive reply. I tried everything you said and this is the stage it's at: http://hostingfrenzy.com/temp/

I made #searchbar float:left rather than absolute positioned. It fixed the problem. The search button is still not aligning properly. It's something to do with the #searchbar class, you'll see it has dropped down by about the height of the #searchbar class. I haven't got a class specifically for the search button image, I was trying to use less classes as possible and this is wrapped in the form class so I didn't think it was necessary.

The menu is positioned perfectly in all browsers now except Opera. If you look in that browser you'll see it is a full menu height above what it shows in the other main browsers. I'm not sure why it's decided to do this.

I tried the legend/fieldset tags and used left: -9999em for legend but it still displayed it in the input box. Not sure why so I removed it.

 

I see the image for the search bar is repeating... which also shows me the width. Search button might be being pushed down by the search bar input.

Opera, heh, seems to be setting the menu within where it really is... meaning, when I look with Aardvark at the menu, I can see the floats dropping out of the ul (which is what they do... overflow: hidden can force the ul to wrap those) while the ul in ff and opera is actually at the same height.

Hmmm, you're very close, so if I get a minute I'll try rewriting it myself, cause sometimes that's the only way I find out what an error is. Tomorrow is Queen's Day and the next day Jesus goes back to heaven or something so I'm bringing my laptop home and I can work on it : ) But, I only have fake IE6 4 linux on this thing, so I won't be able to do really good texts for IE until either Friday or Monday (depends if my building is open Friday... otherwise Monday).
I'll see if I can keep the legend and hide it too. Like I said, I don't usually use them, even for accessibility, for a form that only has one button. Normally, forms should have fieldset, legend, labels and inputs... but this one is just basically two inputs.

I'll find what's going on with the menu too.

 

Yeah I set the form width so it's the total width of the input image + search image (329+78=407px). I have just realised it's because I had the searchbar width at 329px but the padding-left at 20px. The padding-left was causing the search button to drop down. I just changed the width to 309px to allow for the 20px padding-left. I also added margin-top: 5px to make the input text look more vertically centered. All the browsers seem to display it slightly different.

Now the menu problem in Opera i'll work on but that's got me confused. I bet it's something simple. I tried overflow: hidden but that didn't make any difference.

I never use legend or fieldset either because I usually only work on small forms. If it's better design practice to use it then I will.

I might check out Aardvark. Thanks!

 

Legend and fieldset are at least generally considered more accessible, as the legend is supposed to give a sort of title to the form... in this instance, "search form" or the such... it's just that, like you, for small forms like this, I figure if someone can't tell it's a search form in the first place, then their guardian should probably be filling it in for them anyway...

However, it's not a bad thing to have and any form with more than one label-input pair I stick fieldset/legends on.

We'll both dick with it and if I find anything, I'll let you know, and you you get it working in everyone, post it here. At the very least, this thread can help others with the same sorts of forms (menus are a whole other ball of yarn and can easily be the most complicated part of a web page...)

 

I have been playing around with the menu a bit. If I add float:left to the #menu class it fixes the way opera aligns it BUT now if I do that IE aligns it wrong (slightly lower positioned). Even when I take away position:relative and top:26px from #menu class IE wants to align the menu slightly lower than the other browsers. By slightly lower I mean at least 6px lower. If you play around with it you'll see what I mean. I can't use both float and position in the same class can I? I added float:left at the beginning of the #menu class so I assume IE was ignoring that and choosing the position element over float. But as I said, even when removing 'position' and 'top' and just having the float:left, IE still positions it differently compared to opera, ff, safari, netscape. Argggh, hope you can help, surely i'm nearly at a solution.

 

I think I solved it! This is what I have now:

#menu {
	float: left;
	padding-top: 27px;
	width: 762px;
	margin: 0 auto;
	/*position: relative;
	top: 26px;*/
	height: 12px;
	line-height: 12px;
	font-size: 11px;
	font-weight: normal;
	padding-left: 8px;
	padding-bottom: 5px;
	}

Code (markup):

http://hostingfrenzy.com/temp/

As you can see i've used float:left and padding-top instead of using position:relative and top. I haven't tested in IE6 yet though.

I also changed width:100% to width:762px to stop the overflow. It overflowed using width as 100% because padding-left was adding 8px on the end. But this wasn't the cause of the problem.

 

It looked all over the place in IE6, but a closer look showed that mostly it's that your images are repeating (which is what they will do by default if you don't say no-repeat on background images).
Your form was still not valid as there was no block wrapper inside the form.

I never did figure out why the menu was all over in Opera, but here's what I got:
http://stommepoes.nl/Joshm/joshm.html and style.css

I started with the header, which has the single background image (no repeat). In IE6, you've set the height to 100px which is good, but IE6 will let that grow bigger to accommodate any more content (which it should not do but it's not a compliant browser). Therefore you see the bit of the top of the next header image in IE6 on yours.

So, I started with the header, and inside is the h1 which I did NOT set to display: inline. You usually don't want that with a header. They're blocks, and in this case, set a background colour on it and you'll see it's just stretching across the header. Then it can help push stuff down.

Next I took the form, had it switch places in the HTML with Bookmark, and floated it right, while inside (to keep the buttons in the correct order) I floated first the search button right and the text input left. That was how I could get them lined up in all browsers. I set overflow: hidden on the form to wrap those floats, but in addition to that, the menu, which comes right afterwards, is NOT floated and clears the floated form and bookmark. If the menu were floated, in IE the floats might not clear (though you wouldn't necessarily see any difference).

The bookmark button is also floated right, which will set it hugging the form.

Now at first, just styling the menu, the menu was too high, sitting just under the form. While the first thought would be to use top-margin, I didn't because IE treats floats differently. IE would have let me push the menu away from the form with top margin but I'm pretty sure Opera, Safari and FF would have looked at margin-top as pushing away from the bottom of the h1 becuase it's not floated-- meaning I would not see any difference. So instead, I put margin-bottom on the form and that was enough to push the menu down.

I changed the buttom and search images to transparent-background gifs. Otherwise, if something is a pixel off in some browser, you can't see it. Plus a gif can do the job here while a jpg is just needlessly bigger (and kept making those jpg compression artifacts, they be ugly). You can see the images in the Joshm folder on my server.

I did not style the text underneath. You've already done that.

Three things I don't like about it: text-enlarge breaks so bad, the menu will have to wrap when the real text comes in if it's longer than the words "Menu Item" and mostly, the Javascript. Do all those buttons work when Javascript is disabled? I'd rather they were at least moved out of the HTML and into the head of the page, esp since you already have rel="sidebar" in there... you must be using that for something, Javascript? You could have them all external files too, even better.

But anyway, here's what I got:

/*style joshm*/

* {
  margin: 0;
  padding: 0;
}

img {
  border: 0;
}

body {
  background: #003;
  font: normal .8em verdana, arial, helvetica, sans-serif;
  color: #efefef;
}

a {
  color: #efefef;
  text-decoration: none;
}

a:hover, a:active {
  color: #ff0;
}

#container {
  width: 770px;
  margin: 0 auto;
}

#header {
  background: url(header.jpg) 0 0 no-repeat;
  height: 100px;
  margin-top: 5px;
}

h1 {
  text-align: right;
  font-size: .9em;
  line-height: 29px;
  margin-right: 11px;
}

form {
  width: 408px;
  float: right;
  height: 30px;
  margin-bottom: 20px;
  overflow: hidden;
  background: url(searchbar.gif) 0 0 no-repeat;
}
	form input.search {
	  float: right;
	  width: 5em;
	  margin-right: 11px;
	}
	form #searchbar {
	  float: left;
	  background-color: transparent;
  	  border: 0;
	  width: 280px;
	  padding-top: 2px;
	  font: normal 1em/20px arial, helvetica, sans-serif; /*there's a font difference here between IE and Saffy/Opera/FF*/
  	  margin-left: 25px;
	}

#bookmark {
  float: right;
  width: 93px;
  height: 22px;
  margin-bottom: 20px;
}

#menu {
  clear: right;
  list-style: none;
  height: 14px;
  margin-left: 10px;
}
	#menu li {
  	  display: inline;
	}
	#menu li a {
	  float: left;
  	  line-height: 14px;
	  font-size: .85em; 
	  color: #fff;
	  padding: 0 10px;
	  border-left: 1px dotted #fff;
	}
	#menu li.end a {
	  border-right: 1px dotted #fff;
	}
	#menu li.active a {
	  background-color: #435ba3;
	}
	#menu a:hover {
	  color: #ff0;
	  background-color: #039;
	}

Code (markup):

 

I managed to get my css code working well in IE6. I didn't think it would have looked as awful as it did. Unfortunately about 30% of my visitors are still using IE6.

I'll most likely go with your code as it seems a lot more efficient, and there is less code which will help with bandwidth reduction. I have a habbit of doing things the long way.

I hate how the text enlarging messes everything up but I can't see a way to avoid this? I wish it was possible to stop the browser from enlarging certain sections of the site, eg: the header.

Regarding the js bookmark button, I agree the js code looks ugly but I don't think it will function if I loaded it from an external file. The bookmark function works in all browsers except Safari. And yes if a user was to have js disabled it wouldn't work, but how many people have js disabled these days? Less than 1%?

Thanks a lot for your solution, it looks great.

 

4% : ) But people can turn it off (they call us all the time asking why FF or Safari doresn't work in some site of ours, turns out they somehow accidentally did the JS out...) or can have their firewalls block it... and it's just good form to keep things like links working without JS (tho bookmark is not really a link in this case) and JS should always enhance an alread-working site when possible, and degrade gracefully in browsers who can't deal with it.

The only way to get around the text enlarge is to not have everything tied to that image. The only way to stop text-enlarge is to set all text in px units, and that only works to restrict text size in IE. Sorry.

 

And that 4% does not include mobile users anyway.

 

I actually don't know... I was having a JS argument with SpiderMan here (geez, I can't believe I just wrote that sentence... : ) and found a site that tried to keep stats per month since 2000 or so about all sorts of things including JS use... I might still have that bookmarked, but if it was just "users" in general then they wouldn't know who's on mobile or not... But the number sure fluctuated a lot from month to month, sometimes going up to 13%.