Take a look here: http://jsfiddle.net/Nvntm/1/
The "Support" navigation item actually disappears on Firefox (and other similar browsers), leaving only the other three navigation items. Why is this so? Am I doing something wrong here?
There is not enough width in the containing <ul> for all the child <li> items. Are you able to increase the fixed width to 670px?
The reason for that is probably due to different browser's different default CSS for elements. Do you have a good "reset" CSS in your app?
Changing the nav css to show the overflow demonstrates that the nav items are simply being wrapped to the next line.
Fix this by increasing the width past 660px (exact working value for your example is 668px):
.nav_centered ul {
overflow: visible;
width: 668px;
Keep overflow on while you are adjusting the width to see the wrapped contents, otherwise you can turn it back off. It is purely to help with visualization. Hope this helps :)
Related
While looking for keyboard-accessible menus, I stumbled across this question, which has as its answer a CSS drop-down menu http://jsfiddle.net/cfWpE/. It seems to use styling on the anchors in the menu rather than :hover on the <ul> items to display the submenus without any Javascript, but I can't figure out how.
Could someone who's better than me at CSS explain how this works? I'd like to try to extend this to a 3-level menu, but without understanding how it works for two levels, that's going to be difficult.
edited for clarity:
It's not actually the keyboard part that confuses me; I understand that tabbing through updates :focus on the current focus link, but the only CSS rule that seems to be applied to those elements is
ul.menu li.list a.category:hover,
ul.menu li.list a.category:focus,
ul.menu li.list a.category:active {
margin-right:1px;
background: black;
}
I don't understand how setting margin-right to 1 pixel makes the parent <li> visible.
This is an interesting Technique to achieve a dropdown menu.
The list items .list have a very high negative margin-top and a width of 250px. This places their content out of the viewport of the browser. The child anchors a.category have a positive margin-top with exact the same value, so they are visible to the user as if they were positioned normally. Now both, the a.category and the ul.submenu have a float:left applied. that's why the submenu does not appear beneath the anchor, but beside it. (But it has no margin-top, so it is still "invisible") Both elements (a.category and ul.submenu) have 125px width and fit perfectly into the parent li which has a width of 250px. Now on hover the anchor gets an additional 1px margin. This makes both elements too wide to fit into the parent container side to side and so the floated submenu breaks onto a newline and suddenly appears below the anchor - TADA:-D
I hope you could follow my explanation - if not ask please which part I need to clarify;)
Extending this to a third level is not possible - I would just go with a regular css-menu with display:block; and hide. However, you can use absolute positioning and switch the top value from a very high negative value to 0 when hovering, which would have the same effect.
Generally, i would use this with care. Some searchengines consider text that is hidden via negative margins or text-indent as blackhat SEO and may penalize one for that. Although it might be possible that Google is clever enough to recognize this as a regular dropdown-menu
I'm having a slight problem. Whenever I hover over the "SEO" option on my navigation in IE, the navigation breaks & moves to the side. This doesn't happen in Firefox. Changing the navigation to position:absolute fixes it, but then the main content becomes merged with the navigation. It all validates. Any help would be much appreciated!
http://www.joemarketeer.com
http://jsfiddle.net/eoJ1/Ra4tR/
Thanks loads!
The navleft and navright divs are resizing independently, which is to be expected given your design structure. But it looks weird as it comes down on top of the content below:
One suggestion I can give you is not to set the navigation bar width in %, which you have done for these two divs. If you set a fixed width (in px) or remove the width specification completely (in which case it will take the width of its inner content), a horizontal scrollbar will appear below the page when the width is small, which I suppose is fine. Also, use as few floats as possible as they break the flow of content in the document and are more prone to breaking layouts. Both these divs have a float:left, which can be dumped for more stable solutions. I'm saying all this because I think the breaking of the layout on hover is occurring due to these reasons. If you can take care of this, your problem might disappear.
So my suggestion is to have a single nav div with width: 100%. Inside this put two divs: navleft and navright with display:inline and widths a.) specified in px or not at all, or b.) specified in % but with some min-width in px. If you don't specify any width for navright, it will expand to fill all of the space on the right.
This way these two divs will not reflow independently.
Basically, toy around more until you get better command over CSS; I think more experience will automatically help you sort out issues like this.
I have this and it got an HTML img#logo-image, on some occasions it will not be displayed, display:none.
The problem is that the entire div#menu-title should fit the width of the page.
I tried putting width:100%, but when the img#logo-imag" is displayed it breaks the line being below the img#logo-image.
The width:100% does not work with elements float:left
Just unfloat the menu-title div and remove the width.. it will automatically be 100% of the header then.. and if the image is present it will adjust the ul#menu list to make room for it, which is a natural behaviour
if you want the menu-list to really only take the available width (say for a background color or something then you can add overflow: hidden; to ul#menu - though I don't see a need for that in your example code
here's a simplified version of your Fiddle - hover on the header to make the image disappear and see the ul#menu adjust to suit
Example Fiddle
You have both logo-image and menu-title floating left. Since they arent really in separate divs, they are all part of the same div, they appear next to each other. On top of that, you set the menu-title to be 760, which isn't the width of the page. At least that what it looks like you did. Do not use width 100% because resizing the page will shrink that menu title.
You really just have to play around with the divs, but i would say that separating those two divs would make you be able to stack them on top or below each other.
And in using Chrome's inspect element feature, I don't see a display:none for the image's css. I don't know why that would do that.
I'm really not sure of what you are trying to accomplish since making the div#menu-title width: 100% doesn't leave any room for anything else on the same row.
Why not let them both be inline and let the widths be whatever they need to be?
Anyway, I have a guess at what you want. You want those two elements to behave as being in a table, inside a table row, and each in a table-cell so that the image takes a maximum width, and the div#menu-title taking all of the rest of the place. In that case put them in a table, or use display: table-cell for the image and the div and fiddle around with that.
Here is my site, first of all.
You'll notice that underneath the divider bar in the middle of the page, there are three columns, one with a form, one with text, one with links.
Now, resize the window to slightly smaller, and the right div will drop down to the next line.
Is there anyway to just not display that? So, the divs will adjust (I have a liquid layout) up to the point where they won't fit, then, instead of wrapping the div down to the next line, it just won't be displayed?
You can also achieve that with CSS only.
Just assign the following CSS attributes to #row4:
#row4 {
min-width:1202px; /* the exact value depends on the sum of the width of your 3 column boxes */
overflow:hidden;
}
This differs slightly from your intended solution, since the right box will stay partly visible when sizing down the window and will not immediately disappear completely.
Please be aware that min-width won't work in IE6. However, there are several ways to emulate the min-width property, if you need to support old IEs:
http://www.thecssninja.com/xhtml/ie6-min-width-solutions
You can give them a wrapper div with a min-width set and force it to use a horizontal scrollbar if it gets too small. The nice thing about a wrapper div is you can give it a max-width as well and keep things from getting wonky on super huge monitors.
I'm not a fan of horizontal scrollbars, but it beats completely removing content.
Ok here is what you should do
Wrap all three floated division on a parent div, something like this
<div id="parent">
<div class="form">......</div>
<div class="text">......</div>
<div class="links">.....</div>
</div>
Now to solve your problem give a fixed height to the parent div like
#parent { height:400px;clear:both; }
You would have to use Javascript to get the width of the viewport, then change the display property of the div that is wrapping to display:none so that it doesn't show up when the browser width is too small.
Say I have textboxes, dropdownlists and submit buttons. They are all inline-elements. Which means that "officially" margin, padding, width and height properties should be ignored (in practice not really). If I were to go the right way to set the height to a button I would write something like display:block and then define the height. But there are considerations that a block level element would expand itself unexpectedly so I'd better set its width to some fixed value. The problem is that I don't know its width since it can be dynamically defined upon the text of the button.
Another scenario: I wish to create a menu via <ul> and <li>. I want to have it horizontally aligned, with some items grouped to the left, and with a few stretched to the right. Both <ul> and <li> are block-level elements. Since I wish my menu to take all available horizontal space, then to play with the items height and to have menu items pushed to both sides, the block-mode is fine to me. I'll just use float:left and float:right to achieve the task. But again use should kinda set a width to menu elements, since they are block elements. I do not know their widths because the text of the items can vary. But it seems that everything is rendered just fine as it is.
I have not noticed any issues with both inline elements forced to render as block elements without being floated or width set, or with the list item example. It works just fine in IE7, FF3, Opera 9 and Safari whatever the current version is. The question remains: should I worry about these inline-to-block elements or real block elements floated but without the width set or just leave everything as it is? Am I missing something or is it just one more of those things you simply should not expect to get right?
Say I have textboxes, dropdownlists
and submit buttons. They are all
inline-elements. Which means that
"officially" margin, padding, width
and height properties should be
ignored (in practice not really). If I
were to go the right way to set the
height to a button I would write
something like display:block and then
define the height. But there are
considerations that a block level
element would expand itself
unexpectedly so I'd better set its
width to some fixed value. The problem
is that I don't know its width since
it can be dynamically defined upon the
text of the button.
Unless you're referring to Internet Explorer's box model quirks, you shouldn't be worried about anything expanding or contracting unexpectedly. As long as you take care of normalizing for browser variation, you will be fine. If you have an unexpected and unwanted side-effect along the way to design glory, you debug it, as that is programmer error you contend with. CSS can be quirky, but that is not an appropriate excuse 95% of the time for most major browsers. The other 5% we don't talk about.
This is how I understand your problem:
You want a menu of floated <li> so that you have a horizontal menu that spans the width of the viewport (what your user sees 'in the browser window') to be consistently the full width of the viewport.
It sounds like you are thinking in terms of a fixed width design, when really what sounds like it would suit your purposes is a fluid-width design. This means you create a design that is 'elastic' and expands and contracts relative to the size of the user's browser window. If you created your design anticipating pixel widths being set on each element, you can probably find an elegant way to maintain a fluid-width header and navigation, but have a fixed-width main content area. You can find a happy medium without a full redesign. This walkthrough will likely be what you're looking for. A good explanation of the terms fixed-width and fluid-width can be found here if you're unfamiliar with the jargon and want a closer look at these ideas.
One more for the road:
Setting a width on all floated elements is not only recommended, but is a part of the CSS2 standard as per W3C.
Angelina
You're getting yourself a bit over stressed I think :)
Check out these links, especially 9.4, 9.5 and 10.3. And ctrl-f "inline-block"
If we take the "Official" line that you mention then life is easy as we don't need to worry about widths, heights and on for these elements.
Don't think pixel perfect, don't worry about the minutia of presentation, follow the standards, allow the browser & its users to define styles...
(if only it was really that straight-forward in the "un-Offical" real-world)
Ok, I suppose my question was not understood correctly.
What will happen if i do not set width for floated boxes? I can't set it, I don;t know it. because it depends on the content. Will all boxes just shrink to their content width? This is how it's working in practice. And i'm satisfied with it. Is there any official confirmation that this behaviour should be expected?
Added:
I foudn something interesting here: http://www.webmasterworld.com/css/3811603.htm
I suggest checking the recommendations for a more technical explanantion for the differences, but simply put, the behaviour of floats changed between css2(1998) and css2.1(a couple months of 2005, and then 2007). Per css2 it was mandatory to set a width on floats, while the "shrink-wrapping" you see in ff3 is css2.1. That means pre-Jul/2007 browsers are conforming to the recommendation relevant to their time of manufacture when they stretch div#container the full viewport width. (Which doesn't explain Opera, but it always has done its own thing.)
If so, then i'm contended. As I mentioned, it works in current IE7, FF3, Opera 9 and Safari.
Any more comments?
(assuming if i understand you problem)
In most cases you don't need to set width on list items.
But (yes, there is a but here) if you have a link with display:block (let say you want to use sliding door) you have to do a little trick:
the html:
<ul class="menu">
<li>Link</li>
<li>Link</li>
<li>Link</li>
</ul>
And CSS:
.menu li {
float:left
}
.menu li a {
display:block;
}
/* ===================== */
/* = and the IE6 trick = */
/* ===================== */
* html .menu li a {
width:1%;
white-space:nowrap;
}
If you don't do like this, then the LINK will be stretched to all parent. The LINK not the LIST Element ;) Doing this way you set a "min-width" to IE6 and you won't have any other problems.