17 replies to this topic

[qwerty]

I'm doing my standard business of taking a client's page out of nested tables and into a CSS-based layout. On one of the pages, I've taken the template I've built for them and modified it so that the main layer gets split into two columns (I did that by putting a container div into the content div and splitting that). After the end of those columns, the layer goes back to a single column before it ends and the footer kicks in.

Make sense? It did to me. Now, if the two columns aren't the same height, I can understand that potentially causing problems, but not the problem I'm experiencing. What I'm seeing is that the content in the content layer, after the close of the columns and their container, is appearing in the same space as the content in the right column -- not before it or after it, but superimposed over it and the only way I've been able to get it where it's supposed to be is to stick in a bunch of empty paragraphs.

The following example pages don't have images, but take my word for it -- that doesn't make a difference. The pages with images in a protected directory of my site are showing up the same way.

Here's the page with the empty <p>s and here it is without.

There has to be a better way to work this.

[meta]

The display looks normal when I view it. It sounds like you are saying that the cart is superimposed on the descriptive information that should be above it, yes? That's not happening for me. I tried IE 6.02 and Firefox 1.0.4.

[lcobb]

It looks okay in IE 6 sp1, but I see the overlap in Firefox 1.0.

Larry

[lcobb]

I am not a css expert, but couldn't you stack your divisions instead of nesting them?

Larry

[qwerty]

Here's what I see in FF 1.0.4:

Attached Thumbnails

• 

[lisety]

No problems in IE 6.0.29

[qwerty]

Yeah, that's part of the weird thing. It look ok in IE. The client complained that there wasn't enough vertical space before it, and I could fix that pretty easily, but I'd feel a teeny bit guilty about fixing that and leaving the page as utter mud for FF users.

It seems ok in Opera too.

[meta]

How very annoying. The table looks perfectly normal in both the examples that you posted when I view them in the same browser, here's the detailed browser info:

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

[meta]

Wait - I'm wrong - I can see the overlap in the version with no space on Firefox 1.0.4. The table is appearing in the area where I'd expect just the second column of the main layer.

[chrishirst]

put a clearing div between the close of container <div> and the opening <table> tag
<div style="clear:both;"></div>

"proper" browsers will give tables an implied float

[qwerty]

You da man, Chris Thanks!

Now, what is an "implied float"?

[chrishirst]

it's where floated elements apparently don't take up any space in the parent container and tables just end up occupying the same space.

Now it may be a bug in the other browsers and IE is correct (as unlikely as that sounds, if does happen.)

[meta]

Thank you, Chris, I know I'm going to need that one day soon.

You know what's sad? That page looked better in Netscape 4.78 than it did in Firefox.

[Shane]

Alright, set your flame throwers to deep fry, but ... why go through all the pain of trying to get CSS to display two columns when a table would do it just as well, quite possibly with less code, and work in more browsers?

[qwerty]

Because tables are not for layout!

Actually, there is a table on the page in question, but it's there for the "tabular display of data" as they say, so I'm ok with that.

Basically, I avoid using tables for layout whenever possible. If this couldn't be done without either using a table or throwing in all those empty paragraphs, I would have had to decide which was the lesser of two evils.