Absolute vs relative positioning

HTML & CSS
1

A little while ago I posted about the need to mix units in a height property. For the moment I have a rather inelegant workaround for my problem, but here’s what I’m trying to do, and would dearly like to do it ‘properly’:

<div id=“a” style=“position:relative”>

[INDENT]<div class=“b” style=“position:absolute; top:0; left:0”>

[INDENT]<div id=“c”>
</div>
[/INDENT]</div>

<div class=“b” style=“position:absolute; top:0; left:0”>

[INDENT]<div id=“d”>
</div>
[/INDENT]</div>
[/INDENT]</div>

Div a is the containing div, sitting in the flow of the page as normal; the two divs with class b are both pinned to the same spot, one on top of the other inside div a, alternately fading in and out to create a slide show. The divs inside those, c and d, are each regenerated by Ajax while they’re invisible. They’re fairly complex, containing a row of three floated divs, each of which in turn contains an image and various further divs containing text and links.

The text in the inner divs can vary in length, thus giving the inner divs varying heights, and my problem is that - mainly due to pure rustiness on my part - I can’t find a way for div a to have a real height (without my imposing an abitrary height on it). Because of the b divs having absolute positioning, div a has no height, so the stuff that should follow all this on the page overlays it.

If my explanation above isn’t clear enough, you can see what I’ve done with a compromise solution something like the one suggested by Paul O’B in answer to my previous query here - but try zooming in a few times (set to zoom text only) and you start running into trouble. There’s another minor side-effect I’d like to get rid of, but I won’t go into that here because I’m pretty sure if I could solve this box model issue it would cure that too.

2

How much does your text inside vary in content? If they don’t vary much, a min-height set in ems can go pretty far. Though it can’t deal with a whole bunch of difference. em’s still fail once text starts wrapping a lot, which you won’t see with zoom, but will see with text-enlarge, or too much difference in amount of content.

Other question is, do they have set widths (class b boxes I mean)?

I was thinking about display: table and making the b’s siblings but table display rules don’t mesh with positioning well. If one of the class b’s is always always going to have M0AR content in it than the other, the float-wrap trick with a background colour/image/border can fake the two boxes looking the same height, but that’s a pretty specific setting.

You could also mix CSS and Javascript. Have CSS do as good of a job as it can (min-height set in ems for example) and then Javascript to ensure the two boxes are always the same height justincase, so long as the Javascript looks at the rendered height of each box after it gets its content, and then sets both boxes to that height. It would mean a recalculation after every ajax call. Dunno if that would be fast or slow.

Edit are you talking about teh group of three news items section? Homeshow?
That page breaks with text-enlarge anyway, because heights were set on most of the containers (instead of min-heights) meaning when I make the text as large as I need, it spills out of the containers, and since the containers aren’t growing to contain their text, the text spills and falls behind (or covers) the next boxes. Ideally they should be pushing those boxes further down.

That whole page can be flexible, and you can still have your homeshow box be pos:rel with a min-height (and it looks like your content does have some limits, so your main worry really would be text-wrapping).

Also: have you looked at what Linkedin does? They have a similar setup. I haven’t actually investigated it, but I’ve noticed (on browsers with JS on) that they actually cover up any spilling out of news items… only on mouseover (and hopefully on :focus) do they let the rest of the info show. They bottom-align the image and content and let the title get covered up a bit (kinda backwards from what you’d think you’d want to do, but, dunno why they did it that way).

3

Yes, well that’s how I’m doing it at the moment.

Yes.

Yes, I wondered about that, but it somehow smacks slightly of desperation! I’d prefer to avoid it if possible.

Yes indeed.

Yes, exactly my problem. However…

I don’t know what gives you that idea. There are a number of heights in the style sheet, but not concerning that part of the site. That’s all min-heights.

Anyway, thanks for the thoughts. I’ll keep trying!

4

There are a number of heights in the style sheet, but not concerning that part of the site

For example, #topmenu. The text in it pops out and starts hitting your group-of-three.

I was on LinkedIn today and looked at what they did. Unfortunately they have fixed-height as well, but actually no Javascript for the actual positioning, just for swapping as you’re planning. Though their CSS to drop the image down on :hover is still kinda neat.

Hm, so because abso-po’d elements aren’t enlarging their container because they are out of the flow… since your widths are fixed and the homeshow container is also fixed width… put the three boxes back in-flow (you’ve mentioned floating them, I like inline-block myself) and you simply let the javascript call the image and text + markup… and throws it into the floats. Meaning, instead of using positioning to determine where the content sits, it may be much better to use id’s to find each box and replace its content (let’s say it’s all sitting in a documentFragment for less DOM manip), so CSS can do all the positioning stuff?

Still, #topmenu (height: 82px;) and #endorse (height: 80px;) need min-heights instead of heights as well, to stop them from flowing into the slideshow.

With in and out fades you may be getting no good benefit from abso-po. It seems you’re using abso-po so JS knows where to put particular content…?
Your content is mostly the same length, so your largest differences in height on text-enlarge are going to be from word-wrapping. However, at the point where it really starts to differ insanely, it’s no longer a goal to make all three boxes appear to be the same height. The goal for folks who need to enlarge text that badly is pure readability. If I need to keep boxes looking the same height, I’ll test several text-enlargements, but sizing I stick to no more than 3 CTRL++s.

5

Hi,

I’m not quite seeing the logic here.

You have two boxes absolutely positioned on top of each other but both may be different heights? is that correct?

If you want both boxes to be in the flow then why don’t you just hide one (display:none) and then show the other one when needed and therefore keep them in the flow.

However, I see a flaw in this in that when one box is bigger than the other then the whole page will reflow and look dreadful. No one likes the whole page jumping around. You would be better off fixing a height in ems greater than you will ever need or capping the line-length to a certain length.

Or did I misunderstand? :slight_smile:

6

If you want both boxes to be in the flow then why don’t you just hide one (display:none) and then show the other one when needed and therefore keep them in the flow.

The boxes ARE getting display: none’d while the one to fade in is placed on top of it. But I like javascript adding/removing the content inside the box so abso-po isn’t necessary… that way the tallest element can hold the container open because it’s in the flow.

7

Guys, thanks for the further thoughts on this, and sorry not to be back here sooner to answer - I’ve been busy on a different part of the site (the CMS you can’t see, where all the really exciting stuff happens :slight_smile: ).

To sum up, the reason I can’t just use display:none is the cross-fade, during which both boxes need to be visible at once.

So I’m sticking with abso-po (hadn’t seen that abbreviation before - lovely!) and the heights in ems. It also avoids the problem, as Paul O’B pointed out, of the page below jumping about if successive boxes are different heights. I also agree with Stomme poes about the need to compromise to a certain extent over how many Cmd-+'s (or Ctrl-+'s if you must) one does when testing. I take the view that users with exceptionally poor eyesight who have to keep the text enormous all the time will be used to layouts going a bit flaky, and it’s worth that sacrifice for the majority.

Overall, I’m pretty happy with the way it works now.