Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Westi on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

CSS positioning weirdness in IE 2

Status
Not open for further replies.

dspitzle

Programmer
Sep 9, 2003
45
US
Ok, I'm trying to set up a table-style data entry display, where several records are displayed for editing, one record per row. I was beating my head against a CSS problem in getting the rows to work, and I've reduced it to what appears to be a very basic positioning inconsistency in IE. You can see the page in its current form at .
Right now I'm letting each DIV tag occupy its own line, even though I want to line them up into rows via floats. The problem arises when I do my little design tapdance, switching between Firefox 1.0.2 and IE 6.0 (I'm running Windows XP). In Firefox:

FirefoxView.JPG


, the text fields are flush against the left side of the container DIV. However, for some reason, in IE:

IEView.JPG


, the text fields get shifted to the right. It took me a while to figure this out, but for some weird reason, the distance of the spacing of the text fields is controlled by the margin-left property of the containing <div id="activity">; I'm using the margin to shift the main content area to the right of the navigation block. When I set #activity {margin-left: 13em;}, both #activity and the text fields are displaced 13em; when I change the margin to 20em, they are all displaced 20em. I can't figure out how the text fields could possibly be inheriting the margin-left property from #activity in IE, and explicitly setting the margins on them doesn't make any difference. Does anybody have any insight into what the hell is going on here?

Oh, I'll note that both the page and the CSS validate without a hitch on the w3.org website.
 

It is this style that is causing the problem:

Code:
div.item {width: 35em; height: 2em; }

If you remove it, both IE and Firefox display it fine.

Hope this helps,
Dan


[tt]D'ya think I got where I am today because I dress like Peter Pan here?[/tt]
[banghead]

 
Ok, you've got a point there; I actually knew that already, having stumbled across it in my debugging process. The problem is that I need to specify the width of the div.item, as I want to line up the entries into columns, and I can't work out a way to align them correctly with the labels at the top unless I set the sizes for the div tags.

This still doesn't actually explain >why< this is occuring. Is this a particular instance of a known rendering bug in IE? If so, is there a workaround? If not, is there something else lurking in my CSS which is causing it?
 

How odd...

If you put a non-breaking space (or any character, it seems) before the first input in each div, the alignment suddenly fixes itself.

A rendering issue, maybe?

Dan



[tt]D'ya think I got where I am today because I dress like Peter Pan here?[/tt]
[banghead]

 
Ok, now >that< is an answer I can work with. So, now if I can find a character code for a non-spacing space, so to speak, I can get the layout I want. I'd still like to know any further details people may be able to find on what's driving this bug, but for now, I think I can move forward. Thanks!
 

Try either:

Code:
&zwnj;

(zero width non-joiner), or

Code:
&zwj;

(zero width joiner)

Hope this helps,
Dan



[tt]D'ya think I got where I am today because I dress like Peter Pan here?[/tt]
[banghead]

 
Thanks, Dan. I've never heard of either of those character entities. Might come in handy.


Tracy Dryden

Meddle not in the affairs of dragons,
For you are crunchy, and good with mustard. [dragon]
 

Would you believe I now have the opposite issue?

If I have content before my form, my form elements dissapear. If I remove the content, they appear normally. Ah well. I'll figure it out sooner or later!

Dan


[tt]D'ya think I got where I am today because I dress like Peter Pan here?[/tt]
[banghead]

 
Well, if you haven't I'd strongly recommend running the page through a validator, as that sounds suspiciously like a tag closure bug.
 

It turned out to be some floating elements that were causinbg the problem. All sorted!



[tt]D'ya think I got where I am today because I dress like Peter Pan here?[/tt]
[banghead]

 
Dan, my boss asked me this and I had no answer: "Under what circumstances would you need a 'zero width non-joiner"? I can imagine some situations in which you might use the other.


Tracy Dryden

Meddle not in the affairs of dragons,
For you are crunchy, and good with mustard. [dragon]
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top