How to keep floated list item elements from wrapping to the next line?

In this nested menu, the UL’s list elements are floated left to create css based flyout menus. However, when the parent container (header) is not wide enough to fit them all on the same line, they get bumped down to the next row.

However, since this is a flyout menu, that screws up the vertical alignment of the elements.

How can I force the floated elements to not wrap to the next line (and optionally force the layout to expand horizontally when the width of menu.top.cat exceeds the header div’s stated 977px?

This screenshot shows the correct display (when top row elements total width does not exceed container width of header element - 977px)

This shot shows what happens when more elements are added to the top row of list items. The last list item is wrapping under the first.


<div class="header">
	<div class="menu top cat">
		<ul>	
			<li class="cat-item cat-item-35"><a href="">Line 1 el 1</a></li>
			<li class="cat-item cat-item-13"><a href="">Line 1 el 2</a>
				<ul class='children'>
					<li class="cat-item cat-item-25"><a href="">Blue Cameras under $100</a> </li>
					<li class="cat-item cat-item-26"><a href="">Red Cameras Under $100</a> </li>
				</ul>
			</li>

			<li class="cat-item cat-item-14"><a href="">Line 1 el 3</a>
			</li>
			
			<li class="cat-item cat-item-27"><a href="">Line 1 el 4</a>
			</li>

			<li class="cat-item cat-item-12"><a href="">Line 1 el 5 (wraps to next line)</a>
				<ul class='children'>
					<li class="cat-item cat-item-30"><a href="">Slim Cameras Pocket Sized</a>
					</li>
					<li class="cat-item cat-item-31"><a href="">best black cameras under $200</a>
					</li>
				</ul>
			</li>
		</ul>
	</div>
</div>

<div class="main">stuff here below menus</div>


.header {width:977px;}
.menu.top.cat {overflow:visible;}
.menu.top ul { position: relative; list-style: none; z-index: 50;}
.menu.top ul li { position: relative; float: left;}
.menu.top ul ul { position: absolute; visibility: hidden; list-style: none; z-index: 9999; }
.menu.top ul ul li {display:block;width:100%}
.menu.top ul ul ul {left:150px;}
.menu.top ul ul li { clear: both;}
.menu.top ul a { display: block; }
.menu.top ul ul ul { position: absolute; top: 0; }
.menu.top ul li:hover ul, .menu.top ul a:hover ul, .menu.top ul :hover ul :hover ul, .menu.top ul :hover ul :hover ul :hover ul { visibility: visible;}
.menu.top ul :hover ul ul, .menu.top ul :hover ul :hover ul ul { visibility: hidden; }
.menu.top ul a:hover {background:url(spot2.gif);background:url(bar-bg.png) repeat-x, url(spot2.gif) repeat;color:#333; text-decoration:none;}
.menu.top ul.children li.current-cat a {color:#333;}

First thing I see looking at that - there’s sometimes an apostrophe in Cameras (but only about half the time).

Second, 977px is going to be too wide for some people. You should aim to have your site no wider than 770px so that it fits onto the vast majority of screens/windows/setups.

Third, making your site even wider to accommodate additional list items will guarantee that some people never see those menu items off to the right, and is a really bad idea.

I’m not aware of any way to force the floats to stay on the same row, even if it was the right way to go about it. A better solution would be to ensure that your menu doesn’t get that big. For a start, how big is the text? Could it be reduced without compromising readability/accessibility? Then consider how many categories you actually need, and keep that to a minimum.

I’m wondering, “Why not use jQuery to make a drop down list.”

Put all best cameras in one list have the prices drop down. Seems more user friendly to me. I really don’t think whether they are blue or red is a big user concern. Then in your Cameras by review have "top rated, Amazon top-rated.

To Stevie D: If the best size for templates was 720, there wouldn’t be so many developers using the 960 grid. Moreover, if you look at many high-profile e-commerce sites, the pages are scalable (probably spelled wrong) and may take up the whole screen.

I do think that 977 is too wide since you have to accommodate browser scroll bars and such, but 720 on sites with many products often results in a cramped looking page with a sea of background on either side of the template.

Scott, I know none of this answers your question. However, on sites with scalable (there’s that iffy word again) pages, those floats generally do move down. I think that’s part of the “float” idea.

I don’t see your apostrophe after cameras. Did you already fix it? It was good that Steve pointed it out, although he could have done it in a kinder, gentler way. Sometimes it does take a second pair of eyes to zero in on a mistake.

Hi,

If you mean you want the top main menu to be as long as the number of entries then float the element without a width but add a negative right margin.

e.g.


.header {
    /*width:977px;*/
    float:left;
    margin-right:-999em
}

That will stop the floats from wrapping but it will look a bit odd as they will poke out of the side of any main container that you may have. You’d then need to ensure that the following content is set to clear:both.

I’m not really sure of the dynamics you need but it’s not really feasible to make the menu stretch the whole page if its wider. I’d probably need to see working example of the page to fully understand the implications.

I don’t think Stevie was having a go at you but rather pointing at the pitfalls of wide layouts and of course it’s ultimately your choice to go the way you think best.

I believe Stevie means starting from 720px, with a flexible layout, extensible up to 1120px or more, rather than using a fixed 960px.

With the mobile market these days, there’s a bit of a change in the way you look to start laying out the page. Some say you should start with a basic layout most devices understand and work your way up, rather than starting from the top and add media queries for “lesser” devices, since media queries proved to be not so helpful in their case.

Why not just give the menu or it’s container a min-width to prevent it for dropping the floats?

All you need to do is put a fixed width on the UL to prevent it wrapping if the viewport width is narrower than with width of the menu. Or at least a min-width.

Generally, as I understand it, most desktop browsers can now easily accommodate a wrapper width of 1000px and more. I wouldn’t worry about the width of the current design.

EDIT: Whoah, three more responses in the time it took me to answer. Better answers above.

Thanks Paul, I think this is the best solution.

Some background: This is an exception handling situation. The example pics are just that, examples that I threw together pretty quickly. Its a localhost test bed.

In this case the code will be used in a shipping WordPress theme in which I can’t know beforehand how many top level menus the end user’s site will have. And although my usage instructions for this menu will state words to the effect: “Ideally, the number of top level menu items should not exceed the width of the container menu”, I’m trying to gracefully handle the exceptions.

I always appreciate your clever and helpful solutions Paul.

~ s

OK, I understand a bit more now :slight_smile:

Thanks Ralph, I agree. My actual width is 967, not 977 (made more than one typo on the opening thread but the edit window’s closed).

I find that 967 is optimal to support 1024 pixel width screen resolutions.

Common practice ≠ good practice. IMX most of the sites that use a 960-grid (or any template grid) are not ones that I would take advice from over the best way to build a website that is fully accessible and usable. As noonnope correctly surmised, I’m not in favour of a fixed width at all, but prefer a fluid layout with min/max constraints. The bottom line is that if you design your site to require a maximised window with no sidebars on a 1024px display to avoid getting horizontal scrollbars then you will be causing problems for a significant minority of visitors, and those problems might include them never even finding the right-most menu item.

I don’t see your apostrophe after cameras. Did you already fix it? It was good that Steve pointed it out, although he could have done it in a kinder, gentler way. Sometimes it does take a second pair of eyes to zero in on a mistake.

Nope, the apostrophes are still there in the screenshot, but not used consistently. Sometimes they’re there, sometimes they’re not.

Another thing that needs to be tightened up is capitalisation. Unlike the apostrophes, you can choose your own house style here, as to whether you want to use capital letters or not. One is not necessarily right and the other wrong (in this context), but you have to be consistent throughout.

This isn’t just me being a nasty anal-retentive pedant. People will, consciously or subconsciously, judge the presentation and quality of writing on your site. If it is badly written and has lots of typos, spelling mistakes, missing or erroneous punctuation etc, they are less likely to believe it to be trustworthy. If you’re not going to take care over the details when writing the website, why would they trust you to take care over the details of any other aspect of the business? You owe it to your customers and your business to proof-read everything carefully, and to make sure that you haven’t got that kind of glaring mistake or inconsistency as the first thing people see. No, the occasional typo is unlikely to turn people away … but mistakes on that level will lose you business.

That’s all very well if you know how wide it needs to be. But in the case of a menu that can have sections added, changed or removed, or one where the text is not set in px and so can be resized, you can easily find situations where what you think ought to be enough width suddenly isn’t. A method like Paul’s that doesn’t rely on knowing the exact dimensions of all its child elements is better, although to have it sticking out potentially beyond the page design and even beyond the viewport is not an ideal solution … which is why I think the OP is actually trying to solve the wrong problem.

Ah, I didn’t realize it needed to be a fluid width layout.

[ot]

Jiminy Cricket, I can’t see a single apostrophe on the word camera in that screen shot. Could you be looking at a cached version?[/ot]

[ot]

Aha, yes … I’ve reloaded the images and they have now disappeared![/ot]