Height in different browsers

I am just getting back into CSS after giving up as a very newbie:

I have fixed my problem now I think. But I am looking for advice on how I can resolve these bugs more quickly in the future, cos’ there seems to be a huge cost in time to get things to work in different browsers using what I understand to be a STANDARD!!

I eventually traced back my skewed layout to this:

BACKGROUND
I have a div id menu and in it I had 3 uls etc making up the menu. Height is not set, so I thought inherits the agent’s auto (ie what ever space you need for the content). In IE8 this is what happens, but same code in Firefox 3.6 has computed height zero. Now the following div sits below the menu div (divs are block boxes right?). I make this following div float left and it jumps up immediately to the right of the menu div. Why did it go there, since the div above is a block box with 100% width. If I’ve read the spcs right nothing should be able to go right/inline of a block box.

MAIN QUESTIONS

  1. Why don’t the tools (eg firebug) show me that the expected height auto wasn’t used.
  2. What tools (or maybe techniques) might have helped me to spot this more quickly, rather than just +++experience
  3. Is there such a thing as a reference browser that complies fullly. I guess not, cos then every one would just use that!!

Also:
Why did my floated left div go there(see above), since the div above is a block box with 100% width. If I’ve read the spcs right nothing should be able to go right/inline of a block box.

ASIDE:
I notice in firebug that background shows more than I have in the css, is this agent inherited, cos I dont see other agent inherited attribute values shown this way.

Is there any way to save out my discoveries and corrections to my css to the original or alternaive file name?

SORRY FOR LONG POST - I AM LEARNING - SLOWLY!!!

Hi,

There are too many variables in your description for me to give you an accurate answer. What I’d need is some code that exhibits the effect and I can tell you why it is doing what it is doing. In 99% of cases it is author error or author misconceptions that initially cause the problems although of course there are a number of bugs to contend with also.

Floats should float from wherever you float them and if there is non floated block content above the float then the float should float horizontal from where it already is in the flow. This is not true for floats that are on the same line as inline content though and the inline content will be shifted aside to allow the float to move horizontally on that same line.

Parents that hold only floated content will have zero height unless they are cleared.

  1. What tools (or maybe techniques) might have helped me to spot this more quickly, rather than just +++experience

The problem is that there is always a right way to do something although there are probably many ways that the same thing can be achieved due to the flexibility of CSS. However there is usually a right way to do it which comes from understanding the properties you are using and experience.

It’s not difficult but it isn’t always obvious.:slight_smile:

  1. Is there such a thing as a reference browser that complies fullly. I guess not, cos then every one would just use that!!

There are always bugs in software but browsers like Firefox, Safari and Opera are pretty consistent but do all have occasional bugs. IE8 is pretty good compared to other versions of IE also.

I think you just have to accept that it’s part of a web designer’s job to cater for these different browsers as best you can. If it was too easy I’d be out of a job :slight_smile:

CSS isn’t hard but it does have rules that must be followed and understood before you can get the best out of it (like most languages). Use the Sitepoint reference to understand how things are supposed to work and to check on any common bugs.

I always design with at least 4 browsers open at the same time with the page in progress displayed in each and a quick refresh of each as I add each line of code soon shows me the differences and only takes a couple of seconds.

Also:
Why did my floated left div go there(see above), since the div above is a block box with 100% width. If I’ve read the spcs right nothing should be able to go right/inline of a block box.

I’d need to see the exact code you are using to answer this.

ASIDE:
I notice in firebug that background shows more than I have in the css, is this agent inherited, cos I dont see other agent inherited attribute values shown this way.

Backgrounds are not inherited.

The background property is a shorthand for all the background properties and all the properties that you don’t define revert to default values. eg If you say background:red then effectively you are setting background image to none as all omitted values revert to default.

Is there any way to save out my discoveries and corrections to my css to the original or alternaive file name?

If you are talking about Firebug or edit css in Firefoz then I think there is an option to save changed files although I never work that way.

SORRY FOR LONG POST - I AM LEARNING - SLOWLY!!!
No problem - we’ve all been there :slight_smile:

Just remember to provide code examples with your questions as it makes it so much easier to see what you mean and to provide correct answers.

Thanks.

I have attached css & htm (but as txt files).

I have chopped out some old stuff, but may possibly have left one or two ‘unused’ rules.

I have been seing the unwanted symptoms I described in Firefox 3.6 but not in IE8. I have put a comment for my initial hack / fix, but more thought needed.

I’m really trying to understand.

  1. Why the height is managed differently.
  2. Why the floated div moves inline to the div above it.

Maybe I can counteract some faulty understanding of the standard that will save me buidling my learning on a bogus foundation.

You have an incorrect doctype and therefore ie8 will behaving more like ie5.

Use a full doctype to maintain standards mode. This is the full transitional doctype.


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

Try it now and you will see that IE8 is behaving almost the same as Firefox.

I have been seing the unwanted symptoms I described in Firefox 3.6 but not in IE8. I have put a comment for my initial hack / fix, but more thought needed.

IE8 will now behave like Firefox and the maincontent will be to the right of the menu.

I already guessed at the reason why in my previous post but to explain again in more detail:

The element called #menu is not floated but its child (the ul) is floated and therefore #menu has no height at all and collapses to zero because floats are removed from the flow as mentioned before.

That leaves a floated ul standing alone so any following content (whether floated or not) will wrap to the side of the floated ul as now seen in all browsers except ie7 and under.

IE7 and under will auto clear floated children when the parent has “haslayout” which is triggered in this case by the width set. Therefore #menu encompasses the floated ul and clears it which means that following content will start on a new line unlike other browsers.

If you remove the haslayout trigger form #menu then IE would behave the same as everyone else.

To make other browsers behave like IE you need to clear the floated ul by either adding a div with clear:both before the closing div of the parent or use one of the other clearing mechanisms (see sticky thread faq on floats at the top of the forum).

You could add overflow:hidden to #menu and that would make it encompass it’s floated children because that is one of the side effects of the overflow (other than visible).

“Floats are removed from the flow”

If you always remember the above then any time you want a parent of a float to stretch around the floated child you need to do something special to make it do so. Just because IE does what you wanted does not mean that it is right and indeed IE’s behaviour can make it impossible to achieve certain things because of this behaviour.

IE7 and under auto clear when the parent has layout and hence the differences noted but this is incorrect behaviour. Read the faq on floats for a full description of floats and associated problems.

When you use css don’t mix in deprecated presentational mark up such as “align” as you will only be asking for trouble and presentation should be handled from the css anyway.


<P align="right"></P>

Use lower case for everything as it is so much neater and easier to read and debug.

Hope that explains this issue satisfactorily :wink:

Thank you.

I KNEW that floated items were removed from the flow, but for some reason didn’t spot this in the ul, which I put in a while ago before I came back to this.

I guess I should use these tools and build the thing up block by block again. I guess if I hover over the div in firebug and the display doesn’t hilite a box with size , then I ought to be investigating not just it’s dimemnsions and inherited dimensions, but its contents and their properties.

Sorry for being dumb!!

Sorry for being dumb!!

No problem, we’ve all been there and said the same things :slight_smile:

You also might set a background color on your boxes, that way it’s handy to see what they do/how they interaact and you’ll get a good grip on what ‘the flow’ is :slight_smile:

Yes, sounds a good idea.

I notice in IE Developer tools you can turn on hiliting for flow, relative, absolute etc, but I can’t see anything similar in firebug. Probably just missing it.

Are there any other recommended tools for debugging? Thinking about it, I guess they have to be tied to the browser given the slight differences and that it’s in the browser that css is being interpreted.

I know the only tool I use for debugging cross browser is firebug. It’s probably the number one debugging tool I know. You can see everything going on every element.

I recommend firebug. I don’t like anything else :slight_smile:

You should give the Web Developer toolbar add on for FF a go. Play a bit with the ‘information’ tab on that toolbar. The ‘outline’ tab lets you see the positioned elements.

It’s not as complete as firebug but if you are visual minded… it can take you a long way

Thank you for every ones comments.

My appologies. I stiil haven’t quite got my head around floating. In my example code if I give #maincontent some additional content and move it down relatively, then the floated #column1 still looks central, though it is now lower than the uls in the menu.

I havent full understood what is meant by the floated item being taken out of the flow of the containing block, so why is it still affected by the height of the its container then

and the other common description, to go left as far as it can go until it reaches the padding of the container or the margin of another float. It could be said this element should, going left, reach the edge of #maincontent or #Pagecontainer first. Is something more specific meant by shifting left, left in the back down the reading line sense so to speak?

I still havent quite got my head around float and it relates to the bixes and overflow.

Non-floated content will flow around but it seems it’s not the later non-floated div in the same container as the float or the p within that non-floated div, but the inline content inside the p. The non-floated div and p seem to be allowed to take the full width of the container from which the float floated, overlapping the float.

I see that some people set these unfloated divs to overflow:hidden; When this is done, the part that overlaps float disappears (in firebug hiliting) but I thought that overflow control was for overlapping content and the content has gone around the float and doesnt need more space. Is it really “content area” overlap that is dealt with? Now fire bug hilites just the unhidden area, has the block changed? I didnt understand hiding actually changed the block, but the next float left div (#the col1) having a % width (% of “containing block”) appears to be affected by the overlap setting of its container #secondcolumn. Therefore it appears that the containing block IS changed by overlay:hidden.

Any help or advice on seeing this more clearly would be greatly appreciated. I sometimes find the terminology hard to link with precise features (eg content vs available content area, overlapped available contnet area and overlapped content). Also by content floating around it doesnt mean any contained element (eg a div without overlay hidden) but ultimate inline content.

Hi, I’m not quite sure what you mean but I’ll go over a quick brief of it.

Overflow:hidden; (not overlay ;)) establishes a new containing block. As a result, it will realize, “hey, I have children inside me. I didn’t see them before without the overflow:hidden. I should contain them”.

So as a result the parent will expand to fit. Otherwise, without overflow, the children are like…ninjas and hide from the parent and the parent thinks that it is an empty element and thus it has no height.

It’s just a nice little side effect of overflow:hidden. It wasn’t developed with that in mind, however Paul O’B discovered this overflow method and it works quite well, unless you need a design feature hanging out of it (in which case you can use the clearfix method or some other clearing mechanism, like a clearing div, etc).

Did that clear it up for you? Sorry if I didn’t address your certian topic.

Understood now :).
Take this example

<!doctype html>
<html>
<head>
<title>sdf</title>
<style>
*{margin:0;padding:0;}
#left{float:left;width:300px;height:300px;background:red;}
#right{/*overflow:hidden;*/background:green;}
</style>
</head>
<body>
<div id="left">
</div>
<div 

id="right"><p>text</p><p>text</p><p>text</p><p>text</p><p>text</p><p>text</p><p>text</p><p>text</p>

<p>text</p><p>text</p><p>text</p><p>text</p><p>text</p><p>text</p><p>text</p><p>text</p><p>text</p>

<p>text</p><p>text</p><p>text</p><p>text</p><p>text</p><p>text</p></div>
</body>
</html>

If an unfloated element comes after a floated element it will wrap around the floated element if said element has enough content in it.

However overflow establishes a new containing block and as a result this doesn’t happen :).

Sorry. I still don’t understand this. I need time to formulate a full explanation of what I dont understand but in brief.

  1. If the block is new then it didnt exist before so how are there children that it didnt see before, if the box is really resized then how are there children it didnt see before? They appear to flow around the float whether oveflow hidden is set or not, so surely they are already seen. Why does the box need overflow:hidden to expand to fit, since it has already has 100% or auto width and will already expand height as needed. It still expands even if overflow hidden is not set.

  2. The next post. If an unfloated div follows a floated div that unfloated div does NOT wrap around as far as I can see, and the ref as far as I can see says that when the float is removed from flow the surrounding boxes will be unaffected. Isnt it actual inline content that flows around? All the divs and ps still seem to be full width onl the text inside flows around. Re: "However overflow establishes a new containing block and as a result this doesn’t happen " Meaning that above setence is will no longer happen, ie establishing overflow means that If an unfloated element comes after a floated element it will NOT wrap around the floated element if said element has enough content in it.
    I dont see this, I still see the wrap around.

I am confused, but I am told CSS is easy, so I must just be stupid!!

[quote=hardya;4520404. ]In my example code if I give #maincontent some additional content and move it down relatively,
[/quote]

Don’t use relative positioning to move things around like that as it isn’t meant for that. It’s meant for more subtle overlapping effects and not for structural in the flow changes that you want.

A relatively positioned element is an element that is moved visually but not physically. That is to say that it will look as though it has been moved but in fact it still occupies the same position on the page that it always did and all elements on the page will think that it hasn’t moved at all.

What you should be using is margins to move elements away from other elements while maintaining the flow of the document. Only use relative positioning when you want to move and element but doe nothing else on the page to move with it. That’s why it’s most used to create subtle overlapping effects without disturbing the flow of the document. It isn’t meant for structural positioning as such.

then the floated #column1 still looks central, though it is now lower than the uls in the menu.

As explained above it will look exactly the same as it was before but jast shifted down by the amount of relative positioning used. If you had used margin-top100px on #maincontent instead then it would have pushed the content past the floated ul and align to the left.

However what you needed to do was as I mentioned above and ensure that you clear your ffoats.

#maincontent{clear:both}

I havent full understood what is meant by the floated item being taken out of the flow of the containing block, so why is it still affected by the height of the its container then

When you float an element you float it from where it already is in the flow of the document and then it is moved left or right as far as it can be moved without hitting something (apart from inline elements on the same line but ignore that aspect for now).

If the only thing to the side of a float is the containing block then that’s as far as it will go. If there is already a float to the side of the float then it will line up alongside that float assuming there is room. If there is not enough room for it it will drop down until it finds room.

The height of the parent container has no impact on the float except that setting a smaller height on the container than the float itself could cause cross browser problems.

A container that has no height defined and contains only floats will be zero height tall. The floats float out of the container. To make the parent encompass the float (e.g. when you want the parents background colour to extend) then you need to add a clearer after the float but before the closing div of the parent (or use one of the automatic methods such as the clearfix technique or adding overflow:hidden to the parent - see faq on floats).

The behaviour of floats is slightly complex to understand at first but it’s rules are carefully defined and once you understand them then you know exactly how the float will behave in any given situation (excluding browser bugs of course).

The easiest way to learn is to take a couple of hours playing around with them on the page and I can guarantee that you will soon get to grips with them as they aren’t really that complicated although it sounds complicated when I try to explain it:)

No you have done a very good job. I shall do what you suggest. However I wonder if I need a slightly different or more elaberate concept to help me understand “shift left”.

With the addition to the htm mentioned, if I ignore or best turn off all the relative positioning, #maincontent appears ontop of the floated uls (#menu has no size) and #column1 (when unfloated) appears top left of #maincontent. No (in simplistic terms) if i shift (move?) #column1 left from where it already is (by floating) it immediately “touches the padding edge of the containing block” and so stops there (albeit on top of the floated uls)? Apparently not?

May be I need to get straight what means containing, what ecompasing etc…

I will get there, it’s probably the way my mind works, but I think as a learner you have a double problem that by accidentally doing something unconventionally you open up a need to understand what happened in greater detail than if you’d already done something the intended way.

Thanks again.

Floats are removed from the flow

Just remember that for now and say it to yourself a few times and repeat it to anyone who asks you :slight_smile:

The ul menu above #maincontent is floated therefore #maincontent’s containing block will be the previous static html element above it. Therefore #maincontents top border would actually be in the same place as the top of the floated menu. Backgrounds of non floated elements slide under floated elements until they reach their containing block.

#maincontents containing block would be exactly the same as if the ul menu float was not there.

What happens when you float an element is that it is removed from the flow but with the caveat that foreground content is repelled away from the float. So although the text content may be at the side of a float or wrap under a float the elements background actually slides all the way under the float until it reaches the containing block (see my link to the containing block above).

and #column1 (when unfloated) appears top left of #maincontent.

If you un-float (is that a real word?) column1 it moves to the far left edge only because you have set the width to 20%. You can see that the blue background still slides under the floated menu above it as already mentioned, but the foreground content is repelled downwards. If you increase the width of this now un-floated column1 to say 100% then you will see that the h1 headings now have room to align to the right edge of the floated menu (<h1>S</h1>).

For the content to wrap around the float it must be wide enough to reach the end of the floated element otherwise it can’t wrap because of the simple mathematics of the situation.

No (in simplistic terms) if i shift (move?) #column1 left from where it already is (by floating) it immediately “touches the padding edge of the containing block” and so stops there (albeit on top of the floated uls)? Apparently not?

If you float column1 it does exactly as it should do and floats next to the floated menu and sits on the right side of the menu as expected. If you floated another element left it would then align to the right side of column1.

This is what floats do. They will float horizontally left/right from the position they find themselves at until they hit something. After all this is how most menus are constructed with a series of floated list elements aligned horizontally across the top. It would be no good if each list started on the next line down.

May be I need to get straight what means containing, what ecompasing etc…

What we mean by encompassing is when you want the background of a parent to encompass it’s floated child.

Perhaps it’s easier to explain with an example:


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Untitled Document</title>
<style type="text/css">
.parent {
    background:red;
}
.child {
    float:left;
    width:200px;
    height:300px;
    background:yellow
}
</style>
</head>
<body>
<div class="parent">
    <div class="child">Float</div>
    <p>Non floated content that only has a red background as long as real content is present</p>
</div>
</body>
</html>


In the above example the red background only encompasses the non floated text.

However if we clear the float as in this example.


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Untitled Document</title>
<style type="text/css">
.parent {
    background:red;
}
.child {
    float:left;
    width:200px;
    height:300px;
    background:yellow
}
</style>
</head>
<body>
<div class="parent">
    <div class="child">Float</div>
    <p>Non floated content that only has a red background as long as real content is present</p>
    <div style="clear:both"></div>
</div>
</body>
</html>


We have regained control of the flow of the document and the red background now encompasses the float because we have placed an element after the float but within the parent forcing the parent to take notice.

I will get there, it’s probably the way my mind works, but I think as a learner you have a double problem that by accidentally doing something unconventionally you open up a need to understand what happened in greater detail than if you’d already done something the intended way.

Thanks again.

Yes that’s quite true :slight_smile:

Note that I have merged these threads as they are asking the same questions :slight_smile:

Here are a few extra reading links that will clarify further.

http://www.search-this.com/2007/01/10/floats-repelling-content/