Forum Moderators: not2easy
I got a strange bug and I need your help.
My Trouble: Form's input element does not display close its label.
Bug Condition: IE 6.0
Try:
Bug's code:
Xhtml:
<body>
<div id="details">
<form method="post" action="this">
<div id="contentNameCont">
<label for="contentName">Content name:</label>
<input id="contentName" type="text" />
</div>
<div id="defaultCulturesCont">
<label for="defaultCulture">Default culture:</label>
<textarea id="defaultCulture" cols="6" rows="4"></textarea>
</div>
</form>
</div>
</body>
CSS:
div#details {
margin: 0% 0% 0% 40%;
background-color: yellow;
}input, label {
display: block;
float: left;
}
#details div {
overflow: auto;
width: 100%;
margin-bottom: 5px;
border: solid 1px black;
}
Thank for your help!
[edited by: SuzyUK at 7:49 pm (utc) on Feb. 23, 2007]
[edit reason] just fixed some board formatting [/edit]
The "IE Inherited Margin on some Form Elements" bug was documented at PIE in December and I'm trying to see if it's the same thing we've got going on in all three cases here - yours is one of 3 posts that I've read (sorry for getting to it late!) in the last fornight but hadn't connected the dots
key points of the bug:
The bug seems to occur for all INPUT types except checkbox, radio, and image as well as TEXTAREA elements but not for SELECT elements.
ingredients to trigger the bug:
The problem only seems to occur when the direct parent of the INPUT element has hasLayout and any ancestor has margins.
Source: IE inherited margin bug: form elements and hasLayout [positioniseverything.net] The direct parents of your INPUT/Textarea elements have hasLayout=true by virtue of the fact that they have a width set (IE contain floats) and/or they have overflow: auto; (compliant browsers contain floats) and the INPUT/Textarea ancestor which has the margin is - div#details Tough one, and well spotted - I'll check it out as it's been a while since I bug squished :) - there's another two posts floating around here that I'm trying to find to see if they are related if they are I did find another way to fix it.. whether it applies here, I don't know yet, but I'll let you know [1]btw overflow:auto; is a new to IE7 hasLayout giving property
Suzy
I would definitely put this IE Quirk in the "Bug" category - even though hasLayout has a part to play the quirk is not consistently applied to all Form elements and as far I can see there are no "magic bullet" CSS fixes which almost all other hasLayout errors have - what do you think Bug or just IE?
It seems that there is depth to this bug!
If the nests to the affected element gets deeper and there is more than one ancestor with a margin - the "inherited" value that the affected element will take on will be the sum of all it's ancestors.
Out of the other 2 cases that I've noticed recently on the board only one of them is an example of the same thing Div centers but content doesn't [webmasterworld.com]
Reminder of ingredients.
The problem only seems to occur when the direct parent of the INPUT element has hasLayout AND any ancestor has margins.
There are a few documented CSS fixes but they are reliant on the individual set up of the circumstances - the quickest cure all (low down and dirty in CSS land :o) is an HTML fix - you simply use an extra container element which interrupts the hasLayout flow - remove that ingredient and the bug isn't triggered!
here's some code that illustrates the circumstances of the linked example:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
<title>Untitled</title>
<style type="text/css" media="screen">
div#comment {
position:absolute;
left:50%;
top:30%;
width: 400px;
background-color: #cfc;
margin-left:-200px;
border: 1px solid #000;
}
textarea {width: 196px;}
#comment * {margin: 10px 0;}
</style>
</head>
<body>
<div id="comment" class="panel">
<h2>Add Comment</h2>
<select><option>select box</option></select><br />
<textarea>text in textarea</textarea><br />
<input type="submit" value="submit" /><br />
<span>text in a span</span>
<p>text in a paragraph</p>
</div>
</body>
</html>
what's different about the code above from the OP, or any other example I've seen since reading about this, is that in this code both the hasLayout giving parent and the margin giving ancestor are the same element and it has a negative margin which is throwing the same bug. - the negative margin offers an interesting addition to the list of fixes
The list of documented fixes so far are very much dependant on the particular circumstances that the bug arises.
1. is not pratical for many reason but mainly because all input types are not affected you would have to add class names (HTML fix) to the all the form elements in order to target the affected ones
2. not practical, presumably they are there for a reason
3. again not practical it's likely (absolute, width, float) are there for a reason too
4. is possibly why the bug has remained fairly unnoticed, as it's usual for form elements to have a label (inline element) in front of/around them
have found some more CSS fixes, but again they have clauses
Lastly the "cover all" one is an HTML fix which can be done in either way - but will work across the board
The above solutions (2. would be easiest) work globally because they are removing a key ingredient from the bug
- i.e the direct parent of the affected element no longer hasLayout!
would love to hear if anyone has found any more cases/solutions
Suzy
edited for formatting
[edited by: SuzyUK at 8:16 pm (utc) on Feb. 25, 2007]
