Hello,
I’m missing something easy, obviously.
li {
position: relative;
min-height: 180px;
}
Inside that <li>, I have absolute positionned elements. When their height exceeds 180px, the <li> doesn’t extend to match their height.
How could I fix that?
Regards,
-jj. 
Yes
Absolute elements are removed from the flow and will have no impact on their surroundings. Although you create a stacking context with the parent that does not mean the parent will surround the absolute element. The parent doesn’t care about the absolute element at all and will have nothing to do with the errand child.
Why would you want to remove the element from the flow and then have it impact on the flow? Just use a normal element and it will take up space as required.
The highest element now looks like this:
position:relative;
display: inline;
width: 75%;
margin-left:25%;
float: right;
I tried not to use float, and have
position: relative;
top: 0;
left: 0;
but it somehow added some padding/margin to the top of the element. It can’t be the parent element passing along some of its stuff (the parent element being what I posted in my first post).
I think we’d REALLY need to see more of the page to say one way or the other – though it feels like you’re over-thinking you layout or interactions.
Though as Paul said, just to clarify – apo removes them from flow – as such they no longer EXIST to make that parent container larger.
What are you aiming for on appearance and/or content there – CSS without the HTML it’s applied to is gibberish, and you’re asking about interactions when really, you’ve given us no clue what you’re working on.
… at which point ANYTHING we tell you is a wild and random guess.
<div>
<p>content</p>
<p>author</p>
<img>
</div>
author and img appear on the left of the containing div. content on the right.
The problem with everything being absolutely positioned is solved (the div now stretches when content’s height is bigger than img, which was the original problem).
Now, if I use position:relative to position content, I get a sort of padding/margin. If I float it right, it disappears.
Still not enough to go on but it just looks like you want the content floated right.
Float the content to the right with the appropriate width but don’t put any margins on the left side or that will stop the author and img wrapping to the side.
For the parent div add overflow:hidden and zoom:1.0 (ie fix) so that it encompasses the floated content otherwise the floated child won’t be contained within the parent and the background won’t extend with it.
The img should really be inside a block container and not all alone like that.
We’d probably still need to see a mock up of what you want if that doesn’t help
That or pad the right equal to the image width, and APO it top:50%; margin-top:-(half the image height) – assuming he wants it centered, and the height is consistent on all of them.
Though yeah, we’d have to see the image, (or two or three of them to see if they’re all the same size), with some real data – either as a mockup or as actual code.
Yer really not giving us enough to diagnose what you want.
I’m going to post a mockup asap
What kind of container would you use for <img> and why is it necessary? Is it because it’s an inline element in the middle of block elements?
Yes, it’s not invalid but just not semantic and a pet hate of mine. Besides that it causes bugs in IE7 and below and is best avoided.
You can use a div to hold it (as Jason will say) but I think most images should be in p tags as images are basically saying something in the same way that text content would and normal text content should go in a paragraph.
After all should the image be missing you will likely have the alt attribute explaining what the image was and if that text was on the page by itself you would most likely have used a p tag for it.
Unless of course the image is for decoration and then it should be in the background anyway.
Unlike Paul, assuming everything is already in a block level container like a DIV, what does it need an extra wrapper for?
I’ve never once encountered a single problem with inline-level tags next to block level – I do it all the time and consider it to be one of the great MYTHS that continues to be propagated about HTML.
An image is NOT a paragraph unless you are treating paragraphs as presentational – which defeats the point of semantic markup in the first place. I would have NEITHER a DIV or a P around it. It’s a IMAGE. The tag says clearly what it is, and so long as there’s a PARENT wrapper around everything in the section, it should not need any extra bloat around it!
P is for paragraphs, not “anything that just happens to be text” and most certainly not for NON-TEXT elements. – next thing you know we’ll be wrapping OBJECT, VIDEO or AUDIO in P for no good reason too. 
But then I say the same thing about LI – it shouldn’t need P, and if it does need P or worse, more than one P and/or numbered headings along with it, it’s no longer a list item… Though I tend to think that MENU got it right and everything else is too permissive; since MENU’s (prior to it’s being deprecated in 4 Strict) LI do not allow block level elements inside them.
You start slapping P around everything, P starts to lose it’s meaning… which is why as a rule I reserve P for my content column when it uses actual grammatical SHOCK content paragraphs, not just because it’s where I want a line-break – and certainly NOT where I have a tag that already implies a meaning to it’s content. The ONLY reason for IMG to go inside a P is if it’s inline with the text like a smiley. 
But as Paul began to imply, it’s an old argument. Me? I err on the side of “don’t add an extra element to the DOM for NOTHING”.
Yes it’s an old argument and it’s a pet hate of mine (you have to have some don’t you :)) so I may be biased a little.
Usually I wouldn’t add an extra element where none is necessary but in this case the browser will automatically construct an anonymous block box for you - so why not save the browser the trouble :).
When you do this:
<p>This is some text</p>
<img src="img.gif" alt="This is some text about the image" />
</div>
You are effectively doing this:
<div>
<p>This is some text</p>
This is some Text
</div>
And while it’s not invalid - it’s not semantically correct (IMO) and I occasionally see layouts breaking in Ie7 and under because of it. The white space after the image seems to make IE lose track of where the next element is exactly and elements become misplaced. Of course setting the image to display:block will usually cure the white space problems - but not always.
Agreed it’s probably not enough to worry about as it happens pretty rarely but I do see about once every couple of months a problem where this has resulted in a broken layout.
Of course I occasionally break my own rules and in drop downs I don’t add the extra elements and let the browser do it.
<ul id="nav">
<li><a href="#">Home</a></li>
<li>[B]<a href="#">About</a>[/B]
<ul>
<li><a href="#">History</a></li>
<li><a href="#">Team</a></li>
<li><a href="#">Offices</a></li>
</ul>
</li>
</ul>
So I do break the rules when it suits me
The difference here is that the ul is absolutely placed and removed from the flow and the bug I mentioned is avoided.
It’s a minor issue and most times you can ensure that the image is actually inside the element that it refers to anyway.
<p>This is a photo I took last week <img src="img.gif" alt="A Nice Sunset" /></p>
It’s one of those times when I think that html got it wrong and images should have been block level elements by default and we wouldn’t need to worry.
Very interesting.
I would humbly say that the concept of wrapping an image in a block element depends on the image. In my case, the alt attribute would say the same thing as <p> right under the image. Then, if the image isn’t displayed, it could just… go. I’m not even sure it is of great interest to use the alt attribute in my case.
Does that make sense?