Help with overlapping - code revision

Hello all,

The css and html is validated, the css is inside:
http://lab.webhs.pt/webhs_testes/apregi/testOverlapHelp.php

I want to have the logo image to overlap the keyboard image.
However, if I add a margin-left to the logo, or I give it a with of 450px for example, the float element can’t be contained on the float.

I do understand this behaviour when the elements are on the same stack level.
If the sum of their width is bigger then the container width, the last float element drops.

But I’m not getting why this is happening even if they are on different stacks.

How can we allow the logo to have a margin-left:1em; and that 1em be used to overlap the keyboard image?

Thanks in advance,
Márcio

Hi,

Not quite sure how you want this to look but the destaque-principal will not line up alongside the floated logo because the logo is 406px wide and the destanue-principal is only 554px wide which leaves only 148px of space for that 554px image to fit inside.

Obviously it can’t so it starts underneath.:slight_smile:

Floats are removed from the flow and although destaque-principal starts after the float the background (and borders if any) of the element flow underneath the float until they meet the containing block. The float then takes up all the room in that element and the image has nowhere to go but below.

You should remove the width from destaque-principal and then it will fit.

You could drag the keyboard over the logo using a negative right margin on the float to drag the element over. Only positioned elements can have a z-index so you would need to add position:relative.


#container {
    width: 59.7em; /*955px more or less*/
}
#logotipo-apregi {
    width:400px;
    float:left;
    margin-right:-1em;
    position:relative;
    z-index:2;
}
#destaque-principal {
    position:relative;
    z-index:1;
}


Hope that explains it :slight_smile:

Thanks a lot, please be patient:

So, I thought, 554+406 is less then 955 container width, hence they should be able to be placed side by side… so I thought. :s

Why doing: 554-406 ?

I will need a push on the above so that I could properly understand.
And you tried, but I still have doubts:

what element?

So does this means that the float element as all the container width? I’m getting lost.

the container?

I thought that, by default, elements will have position:relative; but I guess I was wrong? (there is nothing similar to this statement that I may getting and that leads to misunderstanding?

The code works, I just need to adjust and I believe all will be ok, however, I really like to understand what is going on here.

Thanks in advance,
Márcio

No worries a lot of people get this aspect wrong :

So, I thought, 554+406 is less then 955 container width, hence they should be able to be placed side by side… so I thought. :s

If you had floated both elements then yes they would float side by side.

Floats are removed from the flow so imagine at first that the floated element is not there at all then all you have is a 554px wide element sitting at the top and side edge of the parent container.

Now you introduce a float in the html before that 554px element and the float will appear to slide inside it the 554px element (although it doesn’t really because floats are removed from the flow and slide in and out of elements as required) .

Floats only repel the foreground content and not the whole div. Therefore the foreground content inside that 554px div is repelled to make room for the float but as there is only 554px space inside that div the big image that foloows must drop down to fit.

The 554px element doesn’t get shifted to the side because floats only repel the foreground content. The div stays where it always was but as you have limited the width available to it then the image must drop below the float.

So to recap a float will slide inside an element and if that element has a width defined then the space in that element must be enough to hold the float and the width of the content that you want alongside it.

The float doesn’t just move the whole div out of the way. The div’s measurements are exactly the same as before and the position of the div is the same as when the float wasn’t there. It’s only the foreground content that gets repelled from the float but this content must still remain within the confines of the divs 554px width.

(Note that IE less than 8 behaves differently but incorrectly in this behaviour and will move the element to the side in error.)

I thought that, by default, elements will have position:relative; but I guess I was wrong? (there is nothing similar to this statement that I may getting and that leads to misunderstanding?

No the default is position:static which means no positioning at all. Only positioned elements can have a z-index which is why you need to add position:relative to static elements when you want to stack them in order.

Hope that clears it up a bit :slight_smile:

Because according to the documentation if we have a float element before, the floated element after, should lose the flow, just until he reaches the edge of the previous floated element. yes?

ok.

Ok.

I see…
Removed from the flow means having no sensibility about other elements, yes, in the floats case, is more like, other elements but the container.
Yes?

Now the hard part:

Using w3c verbosage what does repel mean? how it works?
What is the foreground content? On general concepts. (I believe here is related with the image inside the div perhaps?)

All the rest is dependent of this hard part clarification.

Please I’m doing my best to make an “AH AH! Now I get it” - at the end.
Regards,
Márcio

Using w3c verbosage what does repel mean? how it works?
What is the foreground content? On general concepts. (I believe here is related with the image inside the div perhaps?)

All the rest is dependent of this hard part clarification.

Please I’m doing my best to make an “AH AH! Now I get it” - at the end.
Regards,
Márcio

Foreground content is the text and images in that div. (Backgrounds and borders are unaffected and slide under the floated element.)

By repel, I mean that the line-boxes alongside a float are shortened to make room for the floated element.

The css reference has some diagrams that should help visualise this. If you look at figure 1 you will see a floated image that moves the text contained within a p element out of the way. It does this by shortening the line-boxes (not the p element itself) until there is room for the float to fit alongside.

The text is moved out of the way but should the image be bigger than shown then the text would start underneath the float because it cannot escape from the confines of its container.

In your case the image is in a container that is only 148px bigger than the float above it and therefore the image can never fit alongside because there just isn’t room.

Your float is 406px wide.

It will float inside your 554px div and force the content in that div to move out of the way but stay within the confines of the dimensions you set.

Just shout if that’s still not clear and I’ll draw a diagram which may be easier to follow.

Don’t worry - a lot of people still get this aspect wrong :slight_smile:

So if we have them, on a floated left element, they will also go the left.
Yes?

line-boxes even if we are talking about other foreground content then text?

Yes!! I see!! :smiley: I do understand this concept of line-boxes shortened on text, I’m strugling to see this same concept on other foreground elements that are not text.

And in that case, the text container will be the <p> </p> element itself. Yes?

yes.

THE ISSUE IS HERE:

How? if since it is floated it get’s out of the flow?
How can we understand this inside?
Haven’t we seen before that there are any inside?

Same doubts here.

AHHHHHHLMOST!!! :smiley: Let’s have hope should we?

Hm… I should be near the limits already… When I’m the only one, please let me know! Let me just see if I find a nice rope and a chair somewhere…

:wink:
Márcio

I was talking about the background and borders on the non floated content that follows a float. The foreground content will be moved out of the way of the float but any background images and colours will slide behind the float until they meet the confines of the containing block.

The block level element that follows a float occupies the same space as the float in that they both reside in the same containing block.

The fact that the float is apparently outside the element that follows it is irrelevant because floats are removed from the flow and are therefore effectively inside any following elements but not confined by them.

In the following example the display is identical yet one float starts inside the following element and one is outside.


<!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">
.float {
    width:300px;
    height:300px;
    background:red;
    float:left;
}
.block {
    width:310px;
    background:green;
    margin:0 0 10px;
}
</style>
</head>
<body>

<!-- example 1 -->
<div class="float">float</div>
<div class="block">Non float</div>

<!-- example 2 -->
<div class="block">
    <div class="float">float</div>
    <p>Non float</p>
</div>
</body>
</html>

It doesn’t matter that the html for the float is outside the following block box because it floats inside it and moves any foreground content out of the way.

It does this by shortening the inline boxes within the block elements inside that container. The block elements inside the box are re-adjusted to account for their inline content which has now been shortened and re-positioned.

The float did nothing to the block elements but the block elements will have appeared to move because the content within them has changed.

Floats do not affect the block boxes only the line boxes within them. The line boxes of course in turn affect the block boxes to account for their new positions where necessary.

line-boxes even if we are talking about other foreground content then text?

What other foreground content is there apart from text and images and other inline content (inputs etc)?

Yes!! I see!! :smiley: I do understand this concept of line-boxes shortened on text, I’m strugling to see this same concept on other foreground elements that are not text.

There aren’t any other foreground elements apart from text and images etc. What elements are you talking about exactly?

If you mean a p element then the p element contains inline content and it is that inline content that gets re-positioned by the float. The p element isn’t moved by the float at all. It slides underneath the float and the inline content (such as text) is moved away from the float. This will in turn now make the p element stretch from the containing block where it always was but it will now still encompass it’s inline content which has been moved by the float to somewhere else.

Subsequent elements will also therefore also be repositioned to follow on from where that p element now ends and assuming that there is no influence from further floats and assuming that they have room to do so or they will overflow.

Consider this example where the float and the block level element that follows it have exactly the same dimensions.


<!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">
p {
    margin:0
}
.float {
    width:300px;
    height:200px;
    background:red;
    float:left;
}
p.test {
    width:300px;
    height:200px;
    background:green;
}
</style>
</head>
<body>
<div class="float">float</div>
<p class="test">test</p>
<p>hello</p>
</body>
</html>


The green box is invisible because it sits completely under the float.

The text “test” has been pushed outside of the red box because the float has repelled it downwards.

The word “hello” overlaps the word “test” because “test” has been pushed out of and overflowed it’s fixed height container and no longer takes part in the flow of the document.

This shows you that the float has slid into the green box and the green box has not moved at all.

And in that case, the text container will be the <p> </p> element itself. Yes?

The p element is a block level element and only its inline content is affected by the float. The p element would still be under the float but it will now stretch to encompass it’s re-positioned content.

THE ISSUE IS HERE:
Quote:
Originally Posted by Paul O’B
It will float inside your 554px div

How? if since it is floated it get’s out of the flow?
How can we understand this inside?
Haven’t we seen before that there are any inside?

This is the same issue again and just because the html for the float is outside the element that follows it does not matter because they both sit in the same containing block and the backgrounds and borders of the block element effectively slide under the float until they reach the containing block as if the float was never there.

If you imagined that the float was an absolute element without co-ordinates then a static element that followed in the html would sit right on top of that absolute element and occupy the same space. This is effectively what happens with a float except that a float is able to move the foreground content out of the way. The float can’t change the width or height of the block element that follows it so the content is still confined within it’s original element (but could overflow as shown in the previous example above).

I think the main cause of your confusion is that you you expect the whole block box to move to the side of the float but this is not the way it works. The block would need to be floated itself to do that (or have its overflow property set to something other than visible (because boxes with overflow other than visible behave very differently but I don’t want to confuse the issue too much here)).

The only thing you need to know is that when you want a fixed width element such as an image to fit alongside a float then the container that the image sits in must be wide enough for the both the float and the image (even though the float may not actually be in the same container as the image).

In practice the issue you are having trouble with should rarely occur because usually there is no need to dimension the block level content following a float. If you do want the whole block level element next to the float then float that also. You can always regain the flow of the document by clearing if that was an issue.

Hope I’m still making sense and not driving you mad :slight_smile:

ok. I have tested and see the effect.

Ok. So, because the floated element has loose (pass for lost?) the normal-flow, all elements that are on the normal-flow, will ignored.
hence, the element will stay below (if we had a background yellow image we will see it).
Correct?

In this case, the floated logo element is “visually” inside the section element but is not inside in terms of markup, hence, structurary inside, hence, it is not confined by the float element.
Correct? Or could be better?

At what is the container here? On the example1 provided? The body?

So the floats don’t actively push aside the elements that appear AFTER the float element. They have just been shortened (by the layout engine?) on their inlines, to be placed into the “floats flow” sort of speak?

I was talking about images. I do almost understand the shorened of inline boxes on a text (when he finds a space between words and if the word doesn’t fit the container width, drop it), but what about the image? What is shortened box images?

Ok. That is defined by the markup structure and we haven’t change it, so it makes sence that only the element inline elements are getting moved.
Yes?

We can see that if we add a yellow background to our p element.

Now the hard part:

Ok…

I don’t get the capital verb here, but to not loose my flow, let me keep reading it…

So that will be placed back respecting the normal-flow, starting from the end of the <p> element - knowing here that, this first p element will ignore the position of our “not normal-flowed” floated element. And that will afect the position of other elements, because the normal-flow is one element less (the one that as been floated).

Hm?

Yes.

The container here is the body?

We have an element of 300px;
we have another element of 300px;
we float one element;
We will have one element after another.
Ok.

But why can’t we have more? Because we have reached the limits of our container block. What container block? the body?

:goof::goof:Does the body on this case as 300px wide only and I thought it was all the wide of the viewport, and that was the issue???:goof::goof:

It was already on the left side, hence no need to move. (I haven’t seen the code for this sentence)

HHmmm… so we will have, a floated image, and after that image we will have a p element. that p element will ignore the image, but the inline content will not, and it will place himself after the floated image, if that inline content has some place to go.
?

The body in this case.

Because the float does have an effect on the inline elements that are inside those elements that follow the float.

The only thing it will do, is ignore the float.

Ok. Because then the rules on floated elements will apply on this case, and it will go up until it finds another floated element.

Because on those cases, the content will not be clipped (for example, they could just disappear (if hidden), of placed side by side with a horizontal scrool bar(if auto)

Np!! AHHhh!!! :cool:

Yes. Even if they are at the same container but, the image container and the floated element are on under the same container, at should be THAT container that should allow them do be placed side by side.

Yes. And I normally do that. But I was never understood this precisely and it’s so important. :slight_smile:

Clear. :slight_smile:

Funny I was hoping the same on your side. I do a lot of questions, but the goal is noble. Not been a copy paster on those matters. :wink:

Thanks a trillion, please confirm if the main issue is my interpretation about what should be the body width and any other inconsistencies on my recently gained interpretation.

Note as well, that despite this, I still not getting, or making the connection between this and the solution provided (remove the width) but, lets leave that for later, when those subjects are gettered.

Márcio

Yes that sounds about right :slight_smile:

At what is the container here? On the example1 provided? The body?

That depends on a number of things and are explicitly defined by the link I gave to the containing block earlier. It is a vitally important piece of the jigsaw.

In example one there are no parents apart from body so the containing block is the “initial containing block” (the containing block for the root element is called the initial containing block, and has the same dimensions as the viewport).

I was talking about images. I do almost understand the shorened of inline boxes on a text (when he finds a space between words and if the word doesn’t fit the container width, drop it), but what about the image? What is shortened box images?

Images are replaced elements but are inline elements also and have special properties but for most purposes you can simply think of them being treated in the same way as text. There is no need to treat them any differently except that maybe they are bigger than a normal character. The image will be moved away from the float just as unbroken text would be. It would be moved to somewhere where it can fit in the space allowed.

I have skipped some of the questions as I have attached a graphic which may answer some of your questions as it is usually easier to see things in diagram form.:slight_smile:

Have a look at the attachment and see if that answers your problems about the differences and why the width limits the space available to the text.

If not fire away - we’ll get there in the end :wink:

Yes. On your example the container was easy to understand, in contexts were we have a clear “markup container” (sorry for the jargon).

In order to understand “where is the container?” (this was, as far as I can tell the hardest to get) on the case presented at the beginning of this thread, we should really understand - what you have heroically try to explain into the constrains of a forum communication possibilities and the dummyness of this author (myself) - the inline elements behavior when a float occurs.

So, let’s see, if I can trow away this rope and chair out of my sight:

Still, please correct any miss understandings:

We have a floated element A, that will float the inline content of the element B into is flow and, that inline content, will not
follow down if, there is space in the container OF THAT INLINE ELEMENT.

The floated element is removed from the normal-flow, but inline content still assumes it’s presence (the pushed aside thing), because the floated element still takes up space in a way that it stills influences the boxes that follow the float, and inline contents.

So, despite the fact that the B element, ignore the position of the float, their inline content don’t.

Since the B element is below our floated element, in order to have space for the image (that is inside that B element) (before the float happened)
that element B container should have a width that allows the accommodation of:

a) the floated element (because even if the B element itself doesn’t care, the inline content does, and if the inline content does care about the floated element, then the B element should care about their inline elements if she wants to have then at the side) (sound like a mother/child talking)
+
b) the width of that inline content

Now we have two options (or, better saying, I can only see two options here):
Make the calculations and give a proper width or, not give a width to the element because, since the element B is a block element
it will be as wide as the container (in this case, the body), hence, enough space will be available.

Did I finally understand this sentence?

??? :shifty::shifty::shifty::shifty::shifty:

Thanks a lot,
Márcio

You need to reword that because I have absoltely no idea what the heck you are talking about. Float the inline content of that element???

The floated element is removed from the normal-flow, but inline content still assumes it’s presence (the pushed aside thing), because the floated element still takes up space in a way that it stills influences the boxes that follow the float, and inline contents.

If you are referring to inline elements and floats sitting next to each other, then, in the case of element A being inline, B being float, then if the HTML appears that way (A comes before B) only a few browsers will place them on the same line. It’s best to have the float first :wink:

Since the B element is below our floated element, in order to have space for the image (that is inside that B element) (before the float happened)
that element B container should have a width that allows the accommodation of:

a) the floated element (because even if the B element itself doesn’t care, the inline content does, and if the inline content does care about the floated element, then the B element should care about their inline elements if she wants to have then at the side) (sound like a mother/child talking)
+
b) the width of that inline content

Yes. The total width of the parent must equal A+B in order for them to sit on the same line
\

Let’s see if I get it better this time:

The element A is floated;
Inline content (on element B) then moves out of the way to make space for the floated block.
If after moving out of the way, the container (of element B) still has space for it, they will be, side by side, if not, they will flow down.

Do you thing is more precise?

Hmm… I believe not, I was referring to something like this:


<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>test case kindly provided by Philippe W.</title>


<style type="text/css">

div {background: yellow; width: 600px;}
h1 {float: left; font-size: 1em; background: lime; color: white; width: 200px; height: 50px;}


</style>

</head>

<body>
<h1>floated block</h1>
<div><img src="/_img/someimg.png" alt="test image" style="width: 420px"> some text and more text and more text and again, more text.</div>


</body>
</html>

Thanks a lot,
Márcio

You know, my approach might seem a bit odd, but why do they need to be separate elements? Why do you need to be screwing with floats?

Why not just make the keyboard image a background on either the IMG tag or the H1? A little padding to make it big enough instead of declaring widths (You do know that on 120dpi machines like mine your 59.7em ends up 1194px, right?) with some background positioning and you’d be good to go.

To me it looks like you are making this WAY more complex than it needs to be. Of course to me, NEITHER of those images would actually qualify as content so they’d both be in the CSS… the first one applied with gilder-levin image replacement if possible. (possibly a double wrap G-L since it’s a transparency, that could get tricky).

That or just pre-composite them into a single image ahead of time rather than trying to do it in the markup.

The layout is a little bit more complex then this. They are semantically distinct as well. One is a head image, another is a logo. So I do believe separate elements is the way to go. :slight_smile: Maybe some other user agents need to change the way I have choose to dispose things, in order to make them transport the same communication message on other envirioments. Hence, I do intend to make a distinction between what is a logo and what is a head first page image.

I don’t. I just need to understand them. :slight_smile: so that I can properly learn one of the parts of a Visual Formatting Model.

I’ve thought about that approach once I’ve started this one. :slight_smile: And I do believe that, since this is only an override of one image over another, z-index is quite exaggerated and a background image, as you suggested, is the way to go. However, this is nothing to do with floats.

I didn’t know that, but I’m glad you can see it properly. :slight_smile:
The aim of using em for layout width dimension is for accessibility proposes. I’m absolutely against tiny little k00l layouts (and those that are not that kool as well) or layouts that don’t allow the user to zoom the text without breaking completely.
But, if there is a better alternative, now it’s the time to change. :slight_smile:
If we change to % I believe we will archive the same results as with em (but without “the stretch to fit part” - but I can be wrong. If so, please let me know. :slight_smile:

The opposite. I’m making the way LESS complex that it needs to be. That’s the way of understanding the Visual Formatting Model :slight_smile: Before it was really hard, now it’s still hard, but not that much… and counting. :slight_smile:

I didn’t know about that technique. I will read more about it. :slight_smile:

That I cannot do, by the reasons explained above.

:shifty:
Márcio