Challenging DIV width issue

This site is best viewed in a modern browser with JavaScript enabled.

TimeBandit

I have an issue that I am wondering if there is a solution for. Here's the scenario:

I am working on a hybrid (tableless where possible without spending a week on figuring it out) 1024 minimum width page. It flows but minimum is 1024. Am trying to use least amount of tables as possible, again without taking a week to figure it out.

In the header area i have: on left side-company logo, then a tab navigation area. The combined logo and tab area width comes to right around 968, which is the "safe" size we're going with for the 1024 display spec. FYI, not sure this is pertinent but the tabs in this design are LI elements that are displayed inline. There are several DIVs inside each LI to form the tab ends, etc.

In order to get this tab nav to display correctly in the browsers speced for this job, I've had to declare a width for the DIV surrounding the tabs. If I didn't do this, some browsers would stack the tabs even though they are set to display:inline - i think it's IE that demands a width be set - I'm sure it's at least the dreaded IE5Mac cuz I just checked.

Anyway, it's all fine and dandy with 7 tabs, as long as I force a width, except I need to allow for more tabs to possibly be added by the client. Currently when even one tab is added, that 8th tab falls down into the next row instead of displaying beside the 7th tab because of the width I've declared on the surounding DIV. This is as I expect.

Here's the issue... if I force the tab nav DIV to always be wide enough to allow for a couple more tabs, there will always be a scrollbar at the bottom of the page if the viewer doesn't have window open that wide. If I do not use a width, IE will stack all the tabs even though they are declared display:inline.

I know it's darn tough but can anyone offer ideas without seeing my HTML and CSS? I'll have to retool a bunch of stuff if I need to make public the CSS and HTML of this project.

What I'm wondering mainly is, is there some CSS thing I've overlooked that would help me take any tabs that might fall below and force them to show instead to the right of the DIV, without making that DIV always be forced to be declared a longer width. Can overflow or clip help here? Can I take an element's overflow and move it? I'm just not sure if there's something simple I am overlooking.

One caveat is that this is a real-world project, not a personal one. It will be browser tested and validated and I will have to make it work in MANY browsers... heheh....

TimeBandit

Actually maybe I should amend this post by saying there is no DIV around the tab nav that is there specifically to control the UL/LI tab nav. The width that I am setting is on the UL. Boy, I'm just making this really confusing now.

There is a bigger DIV around entire header area that contains all the header elements, which is only the UL tab nav plus a logo on the left. But this DIV isn't in question... if I take the width off of the UL then the tabs collapse in IE5Mac and all sorts of wacky stuff happens...

TimeBandit

Okay, I know that was pretty fruitless without a sample, so here:
http://www.brookgroup.com/test/menu1/round06f-help/header7.html

Consider me kicked so I won't have to bother after someone shows me how simple this is. Anyway, what I'd like to happen that that the bottom of the tabs line up with the bottom of the red-bounded box, even if they should stack to 2 lines if the user makes the window smaller. But then if they make the window wider it should continue trying to put all the tabs on one line. This is really screwed in IE5Mac but others i tested quick show the same.

None of this can be absolutely positioned because the entire page may move up and down depending on circumstances. Any ideas? Thanks.

TimeBandit

The echo of cricket chirps is deafening...

toicontien

If the LIs are set as inline elements, try setting #nav-top to have white-space: nowrap;

That should cause the inline elements (LIs) to stretch the table cell. IE would stretch a DIV, but standards compliant browsers will simply spill over the edge of the DIV.

I don't envy your situation. There's a reason people don't design DIV-based layouts for 4.0 browsers: They support CSS for @#$T!

Give your header DIV a min-width: wide enough to accomodate the tabs. Then head to http://www.svendtofte.com/code/max_width_in_ie/ to find out how to emulate the max-width: property for IE. IE doesn't support max-width. I guarantee 4.0 browsers don't.

In short; to hell with semantic markup. Use tables. It's the crutch of 4.0 browsers. Even if you only use tables for the tabs in the header. If you're in as big a hurry as I think you are, you wouldn't mind cutting corners to get a workable solution for an impatient client.

TimeBandit

Thanks, i will look into these options tomorrow. Tomorrow is my last day to find a solution. I either need to figure out how with CSS or go back to a table for this. We wanted to try to move to keeping those tabs as LI elements... we'll see how it goes.

TimeBandit

Originally posted by toicontien
If the LIs are set as inline elements, try setting #nav-top to have white-space: nowrap;

Thanks but i couldn't get this to help.

I did 2 versions so we can decide here what the pros and cons are. The CSS way will always force a scrolbar because we alwyas have to plan for added tabs that will not break to the next line. The TABLE way makes everything work just fine but I can't run around and brag that it's TABLE-less.

Obviously there are other issues, since the TABLE way no longer uses UL/LI to make the tabs, which makes it not as accessible as we'd like, though it still meets our requirements for this client (non-government).

sigh I think some call this "cutting your losses" but it just feels like I lost. I really think there's an answer, I just couldn't come up with it. Rats...

ajimenez

Hi,
This may be too little too late but I thought I'd through my two cents in. I made this page kind of quick and dirty and not sure if it'll help you any. But is this what you're sort of looking for?

I haven't really tested in all browsers and you may need to do some adjustments to positions/widths and such.

Save file to html extension.

tab_divs.txt

1kB

TimeBandit

Originally posted by ajimenez
But is this what you're sort of looking for?

Thank you! You're in the ballpark but I am trying to get (from your example) #nav to always be at the bottom of #banner while it is beside #logo, and to display preferably without wrapping LI elements (without having to specify a width). The bottom scrollbar should only appear when there are too many tabs for the window size to accomodate. The problem is that I have an unknown number of tabs in the top - the client will decide later and add or subtract tabs at will. If I do not force a width then things wrap and break the header area, if I do force a width then it is too wide because I would have to plan for how many could possibly be added.

It would be a nice alternative if I could indeed wrap the tabs, but to have the tabs always at the bottom, so if the 1 line of tabs had to break to 2 lines, it would not force the header area down but would instead push tabs UP so that the bottom of row 2 is at the bottom of #banner. Maybe if it broke 2 3 lines it would break the header but that's OK since there most likely will not be that many tabs.

Whew... very confusing! Thanks again though for taking time to help.

toicontien

Depending on the browser you want to support, you may only need to float the LI's, and A's within them. Float one left, and the other right. That gets around IE5/Mac's problem.

Just what browser compatibilty are you aiming for? I was always assuming you were shooting for 4.0 browsers too.

TimeBandit

Originally posted by toicontien
Just what browser compatibilty are you aiming for? I was always assuming you were shooting for 4.0 browsers too.

Well, we always like to try to get IE5Mac to behave because it is the majority on Mac, though it is hopefully moving to Safari. It's even more important on this project that we strive for the various IE5Mac flavours to behave because this project will be used by art departments most likely, in a sort of art database type of thing.

So I am not shooting for 4.0 but the MacIE thing is just a b!tch. In our office we are "fortunate" enough to see users on OS9-IE5 and OSX-IE5 and the various 5.x IE browsers almost all behave differently. It's funny and sad all at the same time.

Also, these need to work in various AOL browsers, which contrary to poular belief do not render the same as "XYZ" brand browser. We've heard it all, but when it comes down to it sometimes they simply do not display in the same manner as whatever browser they are based on (it has varied over the years).

My workflow is: build in safari, hack for IEonPC, hack again for IE5Mac. That workflow, granted it has sometimes a few stops along the way, generally gets the page working in every browser we need. We do not cater to 4.0 unless specifically asked, or if we bring it up because of a given client's government or education audience.

So far, I haven't been able to get this, what I feel is fairly simple, design to work out in CSS. It's disheartening but I just do not have more time to put into it.

Wait utnil you see our company's new web site though... I'll have to brag about that when it launches, although that'll be setting myself up as apunching bag for sure!