PDA

View Full Version : Alignment issues in IE/FireFox



kuku
11-03-2005, 01:53 PM
I've been running into this issue for over a year now where I use a DIV to create a border or something similar. It usually lines up perfectly in one browser (typically FF), but is off in the other. Here's a small snippet of code for example:



<html>
<head>
<style type="text/css">
<!--
#Layer1 {
position:absolute;
left:8px;
top:100px;
width:40px;
height:400px;
z-index:1;
background-color:#FF0000;
}
#Layer2 {
position:absolute;
left:8px;
top:90px;
width:100%;
height:10px;
z-index:2;
background-color:#FFCCCC;
}
#Layer3 {
position:absolute;
right:100px;
top:100px;
width:40px;
height:400px;
z-index:3;
background-color:#FF00FF;

}
-->
</style>
</head>

<body>
<div id="Layer1"></div>
<div id="Layer2"></div>
<div id="Layer3"></div>
</body>
</html>


Everything lines up fine in FireFox; however, in Internet Explorer the right most layer overlaps the horizontal border. Why is it doing this and how can I fix this and similar problems?

Wedgy
11-03-2005, 08:05 PM
First thing I see is you haven't defined 3 other parameters:

border:0px; margin:0px; padding:0px;

For some reason there are different defaults and behaviours between browsers. Although inconvenient, the best fix is usually to shut all border-like objects off unless you really need them....

----------------------

Okay I tried your code.
You are incorrect about the overlap. If you add the following text to each 'layer' in your example code:

<body>
<div id="Layer1">layer1</div>
<div id="Layer2">layer2</div>
<div id="Layer3">layer3</div>

You will see that both layers are differently positioned between browsers.
Run the following in both browsers at a quarter screen size to see what is going on:


<html>
<head>
<style type="text/css">
<!--
/* add BODY to make I.E. same as Firefox at

window-right and top */
body { border:0px; padding:0px; margin:0px;}

/* add H1 to make Firefox same as IE at top */
h1 {border:0px; padding:0px; margin:0px;}


#Layer1 {
position:absolute;
left:8px;
top:130px;/* moved all 3 layers down */
width:40px;
height:400px;
z-index:1;
background-color:#FF0000;
}

#Layer2 { /* appears 20 pixels tall in IE */
position:absolute;
left:20px; /* changed to show layers */
top:120px;
width:100%;
height:10px; /* fails in IE due to text

size */
z-index:2;
background-color:#FFCCCC;
}

#Layer3 {
position:absolute;
right:100px;
top:130px;
width:40px;
height:400px;
z-index:3;
background-color:#FF00FF;
}

-->
</style>
</head>

<body>

<!--=== this section tests h1/p behaviour -->
<div id=header><h1>
Overlap/Overflow Test:
</h1><p>Run quartersize on Desktop in both

browsers.</p>
<p>Note slight difference in vertical spacing

for paragraphs.</p></div>


<!--=== this section tests layer behaviour -->

<div

id="Layer1"><br/><br/><br/><b>layer1</b></div>

<div id="Layer2"><b>layer2:</b>10px height

fails in IE due to default text size.<br>
It only looks good in Firefox because Firefox

fails to extend the background for text

overspill.

</div>

<div

id="Layer3"><br/><br/><br/><b>layer3</b></div>
</body>
</html>

kuku
11-03-2005, 08:11 PM
Are those three items required to be listed? Won't they just default to 0px or off if you leave them out? I don't understand why they don't line up correctly in IE. Any attempt that I know of to fix it in IE will screw it up in firefox.

Wedgy
11-03-2005, 09:20 PM
Okay I just edited and gave you the fixes. look back at my edited version.

You can make them the same, but the default settings are NOT the same in
the two browsers.
Its FIREFOX that has the 'bug' not IE.

They handle overspill differently. But since you were not printing any text, you didn't notice the overspill problem.

IE is not the problem. It correctly extends the background.
If you want heights smaller than 10px for these things,
then set the font size in the DIV to a smaller font size.

If you want reliable visual control, you have to set defaults to be the same
in both browsers. Sorry, but that's life.

Don't forget to thank me and praise me. :)

kuku
11-04-2005, 01:31 PM
Ah, this is starting to make a bit more sense to me. So I wasn't accounting for possible text heights in FF, so I changed the dimensions to make it work in that browser, which in turn made it misaligned in IE... interesting. The actual CSS I am working with will be a little more tricky than this example (using one of the navigation menus from here), but we'll see if I can fix it.

Thanks for the help! :D

Wedgy
11-13-2005, 09:58 AM
Just for the record, I may have overstated the Firefox vs I.E. case here.

It may be that there is no bug in either browser, but that the default handling of
overspill is set differently in the two browsers, and that is all. I have not experimented
enough to comment on whether there is a fundamental flaw in the two approaches to
default settings/overspill handling.

mwinter
11-13-2005, 01:45 PM
Just for the record, I may have overstated the Firefox vs I.E. case here.Yes, you did. In the wrong direction, no less.


It may be that there is no bug in either browserThere is: IE is broken.

First, IE should respect the height property absolutely. As it is, it expands elements to fit the contents. This is what the min-height property is meant to be used to achieve.

That is what causes the problem in the first example. If you raise the z-index of the first div element, you'll see quite clearly that part of it was obscured under the expanded second element.

Second, Fx is right not to extend the background colour. A background is only to be rendered within the border edge. In other words, only the content and padding regions should be filled by a background colour or image. If the content of an element overflows the element and extends past the border (overflow: visible, the default), no background should be rendered; it should be the equivalent of the transparent value, allowing overlapped elements to show through.

To the OP: if you want to create borders, then use the border (and related) properties.

Mike

Wedgy
11-14-2005, 11:24 AM
I still don't see how allowing overspill isn't a glaring error, if you are going to insist that the background be confined to a predefined area. Especially as a default setting, allowing text to spill over onto other elements with a broken (unextended background) may be some designer's idea of a cute (but extremely limited) effect, but come on:

In most situations, the overspill will be a miscalculation by the page-designer, or a result of resetting the font-size by the viewer in his browser. It appears ludicrous to me to insist that Firefox is not committing some kind of buggy behaviour in this (the most common) case. The result is certainly the ugliest scrap spilled all over your screen. Again, how does having a background only on part of the contents help in any way? (except to warn the web-designer he has goofed a size estimate, or failed to prevent the viewer from resizing his page/font).

In other words, The current ideal/standard for designers, that of 'liquid' pages is totally broken by this 'default' behaviour in Firefox. Not a bug? at the very least, not a forethought.

While I.E.s behaviour may not be ideal either, (especially if a designer is misusing design elements for the wrong functions), it is often a 'friendly' compromize, allowing the page to continue looking 'normal' (and readable!). Perhaps IEs behaviour is a total accident, but if so, its a lucky one, providing overspill with a compatible background that will preserve readability when users change font sizes or windows.

There may be no solution to the problem of such miscalculating or the interaction of 'user-controllable' fonts and windows, except with some 'Auto' formatting function that works for most situations, and frees the designer to 'drag n drop' or something. But if that is the case, how has the choice made by Firefox helped, especially if it results in hetro-mogenous behaviour between browsers, and no standard way of writing compatible html/css?

mwinter
11-15-2005, 01:01 AM
I still don't see how allowing overspill isn't a glaring error, if you are going to insist that the background be confined to a predefined area.Because it's quite clear from reading the specification? Besides, if one stops to think about the alternatives for a moment, it's clear the current behaviour is the most logical.

Starting with the height property, its use is to say to the browser, "I want the content box of this element to be rendered exactly x units high." If that isn't the desired behaviour, then it isn't the property that should be used.

With regard to the overflow property, the default value of visible provides the most accessible behaviour, as well as behaviour that is absolutely necessary for some quite common effects.

If hidden is used, content will be clipped making it unreadable. If auto is used, overflowing content will cause scrollbars to be shown, potentially producing a scrolling area inside another scrolling area: a usability problem. The scroll value will always invoke the latter, overflowing content or not.

An example of an overflow effect is some uses of absolute positioning (there are others). If the left property value is greater than 100% (either as a value in itself, or a length value as a proportion of the width), or if the right property is a negative length, the positioned element will be rendered out of the boundaries of its containing block. This isn't possible without overflow: visible.

Finally, the background property simply can't be confused. From the CSS 2 Recommendation, section 14.2 - The background:


Authors may specify the background of an element (i.e., its rendering surface) as either a color or an image. In terms of the box model, "background" refers to the background of the content and the padding areas. Border colors and styles are set with the border properties. Margins are always transparent so the background of the parent box always shines through.If the content overflows the padding, it should be obvious what the result will be.


In most situations, the overspill will be a miscalculation by the page-designer, or a result of resetting the font-size by the viewer in his browser.Boxes that contain text should either never be assigned sizes in pixels (use a font-proportional unit), or they should be allowed to grow. There are no excuses if the developer cocks this up.


It appears ludicrous to me to insist that Firefox is not committing some kind of buggy behaviour in this (the most common) case.It is ludicrous to me that some Web developers don't read specifications, but then expect to be able to predict the right outcomes.


Again, how does having a background only on part of the contents help in any way?As I said, if that isn't the intended behaviour, don't use properties in such a way that produces that effect.

Mike

Wedgy
11-15-2005, 05:27 AM
Thank you for your insightful response.

I am plodding along trying to grasp this now.
When I looked at the question of disappearing/folding float elements in IE,
I was horrified at the complications that were needed for predictable behaviour
between browsers, yet amazed at the cleverness and elegance of the 'kludges'.
Makes you want to become a simple Amish farmer.