Ghost margin on input?

I have a label and input inside of a div that is positioned using a left float. There are three divs side by side using the same rules. The inputs use a background image to style them up a bit and I styled them using tips from a SitePoint book. They are not floated, just in the flow of the document relative to the floated div. The labels, however, ARE floated. It renders correctly in IE8, Firefox 3.5, and Safari 4. My problem is that for the two inputs included in these three divs, there looks to be some left-margin included when rendered in IE7. When i put the border around the inputs it doesn’t wrap this extra space so that’s how I know it must either be some margin for the input, a padding of the containing div, or something strange I’m not familiar with.

Here is Firebug’s relevant info on one of the inputs:


input.zip  {
background-image:url("https://perksforwork.com/business/new/images/txt70.png");
background-repeat:no-repeat;
border:medium none;
font-family:Arial,sans-serif;
font-size:16px;
padding:9px 10px;
width:50px;
}
css_index.css (line 588)

Inherited from div.zsrch
html, body, div, span, applet, object, iframe, h1, h2, h3, h4, h5, h6, p, blockquote, pre, a, abbr, acronym, address, big, cite, code, del, dfn, em, font, img, ins, kbd, q, s, samp, small, strike, strong, sub, sup, tt, var, b, u, i, center, dl, dt, dd, ol, ul, li, fieldset, form, label, legend, table, caption, tbody, tfoot, thead, tr, th, td {
font-size:100%;
}
reset.css (line 4)

Inherited from form.perksearch search
html, body, div, span, applet, object, iframe, h1, h2, h3, h4, h5, h6, p, blockquote, pre, a, abbr, acronym, address, big, cite, code, del, dfn, em, font, img, ins, kbd, q, s, samp, small, strike, strong, sub, sup, tt, var, b, u, i, center, dl, dt, dd, ol, ul, li, fieldset, form, label, legend, table, caption, tbody, tfoot, thead, tr, th, td {
font-size:100%;
}
reset.css (line 4)

Inherited from div#white-content
#white-content {
color:#555555;
}
css_index.css (line 388)

html, body, div, span, applet, object, iframe, h1, h2, h3, h4, h5, h6, p, blockquote, pre, a, abbr, acronym, address, big, cite, code, del, dfn, em, font, img, ins, kbd, q, s, samp, small, strike, strong, sub, sup, tt, var, b, u, i, center, dl, dt, dd, ol, ul, li, fieldset, form, label, legend, table, caption, tbody, tfoot, thead, tr, th, td {
font-size:100%;
}
reset.css (line 4)

Inherited from div#outer
html, body, div, span, applet, object, iframe, h1, h2, h3, h4, h5, h6, p, blockquote, pre, a, abbr, acronym, address, big, cite, code, del, dfn, em, font, img, ins, kbd, q, s, samp, small, strike, strong, sub, sup, tt, var, b, u, i, center, dl, dt, dd, ol, ul, li, fieldset, form, label, legend, table, caption, tbody, tfoot, thead, tr, th, td {
font-size:100%;
}
reset.css (line 4)

Inherited from body
body {
font-family:Georgia,serif;
}
css_index.css (line 9)

and CSS for the labels:


.perksearch label {
clear:none;
margin-bottom:3px;
text-align:center;
width:100%;
}
css_index.css (line 326)

label {
color:#555555;
float:left;
font-size:16px;
padding-top:7px;
width:70px;
}
css_index.css (line 28)

html, body, div, span, applet, object, iframe, h1, h2, h3, h4, h5, h6, p, blockquote, pre, a, abbr, acronym, address, big, cite, code, del, dfn, em, font, img, ins, kbd, q, s, samp, small, strike, strong, sub, sup, tt, var, b, u, i, center, dl, dt, dd, ol, ul, li, fieldset, form, label, legend, table, caption, tbody, tfoot, thead, tr, th, td {
background:none repeat scroll 0 0 transparent;
border:0 none;
font-size:100%;
margin:0;
min-height:0;
outline:0 none;
padding:0;
vertical-align:baseline;
}

and then the containing div for both:


.perksearch div {
max-width:none;
}
css_search.css (line 55)

.perksearch div {
border:1px dotted black;
float:left;
margin:0 10px;
max-width:302px;
}
css_index.css (line 318)

.zsrch {
width:72px;
}
css_index.css (line 333)

html, body, div, span, applet, object, iframe, h1, h2, h3, h4, h5, h6, p, blockquote, pre, a, abbr, acronym, address, big, cite, code, del, dfn, em, font, img, ins, kbd, q, s, samp, small, strike, strong, sub, sup, tt, var, b, u, i, center, dl, dt, dd, ol, ul, li, fieldset, form, label, legend, table, caption, tbody, tfoot, thead, tr, th, td {
background:none repeat scroll 0 0 transparent;
border:0 none;
font-size:100%;
margin:0;
min-height:0;
outline:0 none;
padding:0;
vertical-align:baseline;
}

I’ve attached a picture of what it looks like with dotted borders applied to the containing divs. I just can’t figure this out! :mad:

note: maybe its helpful to know that these and other elements are all contained inside a form element that I have also floated left with no margin and padding: 0 65px.

note2: I usually try to do things without floats and absolute positioning first but with labels and inputs it has proven difficult for me. It’s the domino effect: float one thing, you usually have to float everything else inside it or position it absolutely. I also refuse to resort to tables.

Hi, we need the HTML as well. THough this is probably a case of inheriting margins bug. The parent needs haslayolut.

Can you post the link to the site in question? :slight_smile:

Well the HTML has a ton of PHP built-in but you can see the page at:

https://perksforwork.com/search

I have recently had some issue with the hasLayout conflict so I made sure it would never happen again by giving everything a layout in my reset.css file. I know that this could cause issue in the future but it hasn’t broken the site yet. I set min-height: 0; for all elements. I thought maybe having a layout was the problem so i deleted that property and no change. I know the input itself must have a layout because I have already applied height and width properties.

I await your advice Guru! :slight_smile:

Setting haslayout on everything is horrible. It can cause bugs and along with other things :).
[URL=“http://www.sitepoint.com/forums/showthread.php?t=627103”]
I just spent 10 minutes going through every post I had, searching for a particular thread because this other guy tried the exact same thing. He was ignorant of the cold hard truth :wink:

To answer the question. I was indeed correct. THe inheriting margins bug is causing this. PS- your min-height:0; trick to fix this is not supposed to be put on the input, but rather the anchestor that has the margins set.

There are multiple ways to fix this bug, aka removing haslayout from the ancestor,
Remove the margin on the parent
Wwrap the <input> in an inline element, aka a <span> (no haslayout)
Give negative margin on the input

Removing the haslayout isn’t possible since the parent that has that is AP’d/width/height and it’d just be too had

THe margin can’t be taken off because you still need the spacing.

The negative margin would be hard for CMS type sites

Using an inline element around the <input>, aka a <span> would probably be best in this situation. If you feel comfortable using the negative margin then go for it. THe selector that the inputs are getting hte margin from is “.perksearch div”

I was reading a thread earlier while researching where you told the guy “If I say that’s the problem, then that’s the problem” with a bit of modesty attached. Don’t mess with the 2009 CSS Guru of the Year! Haha I was entertained. I digress…

Thanks for your time and effort on this issue. Sometimes the design just gets so complicated that I just continue to make it worse. I know that the hasLayout property shouldn’t be applied to everything, but I did it out of frustration at that time. That being said, when SHOULD it be applied? Just on a case-by-case element-by-element bug-by-bug basis?

The original fix applied to a menu I had setup. Granted the markup wasn’t quite valid but I learned about a new display property: inline-block. I am intrigued at it’s use with complex menus like the one I was working with. After my last post in this thread I tried some experimenting with the elements here in question. I changed the containing divs to spans and set their display to in-line blocks. I thought everything would work out better that way just because I wanted to center everything, but that definitely isn’t the case. The label and inputs still need a vertical-type layout but if I changed the divs to spans I can’t then use block elements nested inside.

Ahh this is a mess. If it isn’t too much to ask, how would you lay out these search boxes with their labels? Floating with margins? Absolutely? Or some relative positioning kung fu? I don’t need all the CSS rules, just a general description of your opinion. I want to get better at my CSS!

Well the thing with that thread is that I specifically tested that code. And that annoyed me that he didn’t think it worked lol

Thanks for your time and effort on this issue. Sometimes the design just gets so complicated that I just continue to make it worse. I know that the hasLayout property shouldn’t be applied to everything, but I did it out of frustration at that time. That being said, when SHOULD it be applied? Just on a case-by-case element-by-element bug-by-bug basis?

Normally parents of complicated content need haslayout. You really just have to have experience to know when to apply haslayout.

The original fix applied to a menu I had setup. Granted the markup wasn’t quite valid but I learned about a new display property: inline-block. I am intrigued at it’s use with complex menus like the one I was working with. After my last post in this thread I tried some experimenting with the elements here in question. I changed the containing divs to spans and set their display to in-line blocks. I thought everything would work out better that way just because I wanted to center everything, but that definitely isn’t the case. The label and inputs still need a vertical-type layout but if I changed the divs to spans I can’t then use block elements nested inside.

Ahh this is a mess. If it isn’t too much to ask, how would you lay out these search boxes with their labels? Floating with margins? Absolutely? Or some relative positioning kung fu? I don’t need all the CSS rules, just a general description of your opinion. I want to get better at my CSS!

FLoats and margins would be what I’d use. Well…forms … it depends on how the end result is lol :slight_smile:

Let me ask you something else as well if I may…it’s always felt wrong to me to float a <form></form> element. It feels like it doesn’t quite behave in the same way as other block-level elements. Do you find it problematic? Should I instead just work with containers inside (or outside) in terms of positioning?

I don’t know why I can’t edit my previous post but, I have a minor issue still with IE7. I want the label text centered over the input/select elements. It’s not noticeable with the zip and radius elements but with the search box you can clearly see that the text is not centered. After applied a border, I can see that the label element is not 100% wide even though i set it’s float:none, display:block, and width:100%. paragraph elements work as expected and fill the entire width of the parent div but I can’t get it to work with a label. I want to remain semantically correct and keep the label. Again, this is only an issue in IE7. Suggestions?

Floating the form should be no problem although I usually avoid this because the developers often want to move the start and stop positions of the form to encompass other controls so I usually float the container instead and avoid the issue.

have a minor issue still with IE7. I want the label text centered over the input/select elements.

IE7 and 6 won’t allow that label element to have 100% width in a widthless floated container. However you should be able to get the effect you want by setting the text-align:center here.


.perksearch div { 
    /*border: 1px dotted black;*/
    float: left;
    margin: 0 10px;
    max-width: 302px;
  [B]  text-align:center;[/B]
}

You will of course need to ensure that the inputs are set back to text-align:left though (where necessary).

Awesome thanks Paul! (and Ryan!)