The CSS rules visibility:hidden and display:none both result in the element not being visible. Are these synonyms?
display:none means that the tag in question will not appear on the page at all (although you can still interact with it through the dom). There will be no space allocated for it between the other tags.
visibility:hidden means that unlike display:none, the tag is not visible, but space is allocated for it on the page. The tag is rendered, it just isn't seen on the page.
For example:
test | <span style="[style-tag-value]">Appropriate style in this tag</span> | test
Replacing [style-tag-value] with display:none results in:
test | | test
Replacing [style-tag-value] with visibility:hidden results in:
test | | test
They are not synonyms.
display:none removes the element from the normal flow of the page, allowing other elements to fill in.
visibility:hidden leaves the element in the normal flow of the page such that is still occupies space.
Imagine you are in line for a ride at an amusement park and someone in the line gets so rowdy that security plucks them from the line. Everyone in line will then move forward one position to fill the now empty slot. This is like display:none.
Contrast this with the similar situation, but that someone in front of you puts on an invisibility cloak. While viewing the line, it will look like there is an empty space, but people can't really fill that empty looking space because someone is still there. This is like visibility:hidden.
One thing worth adding, though it wasn't asked, is that there is a third option of making the object completely transparent. Consider:
1st unseen link.<br />
2nd unseen link.<br />
3rd unseen link.
(Be sure to click "Run code snippet" button above to see the result.)
The difference between 1 and 2 has already been pointed out (namely, 2 still takes up space). However, there is a difference between 2 and 3: in case 3, the mouse will still switch to the hand when hovering over the link, and the user can still click on the link, and Javascript events will still fire on the link. This is usually not the behavior you want (but maybe sometimes it is?).
Another difference is if you select the text, then copy/paste as plain text, you get the following:
1st link.
2nd link.
3rd unseen link.
In case 3 the text does get copied. Maybe this would be useful for some type of watermarking, or if you wanted to hide a copyright notice that would show up if a carelessly user copy/pasted your content?
display:none removes the element from the layout flow.
visibility:hidden hides it but leaves the space.
There is a big difference when it comes to child nodes. For example: If you have a parent div and a nested child div. So if you write like this:
<div id="parent" style="display:none;">
<div id="child" style="display:block;"></div>
</div>
In this case none of the divs will be visible. But if you write like this:
<div id="parent" style="visibility:hidden;">
<div id="child" style="visibility:visible;"></div>
</div>
Then the child div will be visible whereas the parent div will not be shown.
They're not synonyms - display: none removes the element from the flow of the page, and rest of the page flows as if it weren't there.
visibility: hidden hides the element from view but not the page flow, leaving space for it on the page.
display: none removes the element from the page entirely, and the page is built as though the element were not there at all.
Visibility: hidden leaves the space in the document flow even though you can no longer see it.
This may or may not make a big difference depending on what you are doing.
With visibility:hidden the object still takes up vertical height on the page. With display:none it is completely removed. If you have text beneath an image and you do display:none, that text will shift up to fill the space where the image was. If you do visibility:hidden the text will remain in the same location.
display:none will hide the element and collapse the space is was taking up, whereas visibility:hidden will hide the element and preserve the elements space. display:none also effects some of the properties available from javascript in older versions of IE and Safari.
visibility:hidden preserves the space; display:none doesn't.
In addition to all other answers, there's an important difference for IE8: If you use display:none and try to get the element's width or height, IE8 returns 0 (while other browsers will return the actual sizes). IE8 returns correct width or height only for visibility:hidden.
display: none;
It will not be available on the page and does not occupy any space.
visibility: hidden;
it hides an element, but it will still take up the same space as before. The element will be hidden, but still, affect the layout.
visibility: hidden preserve the space, whereas display: none doesn't preserve the space.
Display None Example:https://www.w3schools.com/css/tryit.asp?filename=trycss_display_none
Visibility Hidden Example : https://www.w3schools.com/cssref/tryit.asp?filename=trycss_visibility
visibility:hidden will keep the element in the page and occupies that space but does not show to the user.
display:none will not be available in the page and does not occupy any space.
display: none
It will remove the element from the normal flow of the page, allowing other elements to fill in.
An element will not appear on the page at all but we can still interact with it through the DOM.
There will be no space allocated for it between the other elements.
visibility: hidden
It will leave the element in the normal flow of the page such that is still occupies space.
An element is not visible and Element’s space is allocated for it on the page.
Some other ways to hide elements
Use z-index
#element {
z-index: -11111;
}
Move an element off the page
#element {
position: absolute;
top: -9999em;
left: -9999em;
}
Interesting information about visibility: hidden and display: none properties
visibility: hidden and display: none will be equally performant since they both re-trigger layout, paint and composite. However, opacity: 0 is functionality equivalent to visibility: hidden and does not re-trigger the layout step.
And CSS-transition property is also important thing that we need to take care. Because toggling from visibility: hidden to visibility: visible allow for CSS-transitions to be use, whereas toggling from display: none to display: block does not. visibility: hidden has the additional benefit of not capturing JavaScript events, whereas opacity: 0 captures events
If visibility property set to "hidden", the browser will still take space on the page for the content even though it's invisible.
But when we set an object to "display:none", the browser does not allocate space on the page for its content.
Example:
<div style="display:none">
Content not display on screen and even space not taken.
</div>
<div style="visibility:hidden">
Content not display on screen but it will take space on screen.
</div>
View details
There are a lot of detailed answers here, but I thought I should add this to address accessibility since there are implications.
display: none; and visibility: hidden; may not be read by all screen reader software. Keep in mind what visually-impaired users will experience.
The question also asks about synonyms. text-indent: -9999px; is one other that is roughly equivalent. The important difference with text-indent is that it will often be read by screen readers. It can be a bit of a bad experience as users can still tab to the link.
For accessibility, what I see used today is a combination of styles to hide an element while being visible to screen readers.
{
clip: rect(1px, 1px, 1px, 1px);
clip-path: inset(50%);
height: 1px;
width: 1px;
margin: -1px;
overflow: hidden;
padding: 0;
position: absolute;
}
A great practice is to create a "Skip to content" link to the anchor of the main body of content. Visually-impaired users probably don't want to listen to your full navigation tree on every single page. Make the link visually hidden. Users can just hit tab to access the link.
For more on accessibility and hidden content, see:
https://webaim.org/techniques/css/invisiblecontent/
https://webaim.org/techniques/skipnav/
Summarizing all the other answers:
visibility
display
element with visibility: hidden, is hidden for all practical purposes (mouse pointers, keyboard focus, screenreaders), but still occupies space in the rendered markup
element with display:none, is hidden for all practical purposes (mouse pointers, keyboard focus, screenreaders), and DOES NOT occupy space in the rendered markup
css transitions can be applied for visibility changes
css transitions can not be applied on display changes
you can make a parent visibility:hidden but a child with visibility: visible would still be shown
when parent is display:none, children can't override and make themselves visible
part of the DOM tree (so you can still target it with DOM queries)
part of the DOM tree (so you can still target it with DOM queries)
part of the render tree
NOT part of the render tree
any reflow / layout in the parent element or child elements, would possibly trigger a reflow in these elements as well, as they are part of the render tree.
any reflow / layout in the parent element, would not impact these elements, as these are not part of the render tree
toggling between visibility: hidden and visible, would possibly not trigger a reflow / layout. (According to this comment it does: What is the difference between visibility:hidden and display:none? and possibly according to this as well https://developers.google.com/speed/docs/insights/browser-reflow)
toggling between display:none to display: (something else), would lead to a layout /reflow as this element would now become part of the render tree
you can measure the element through DOM methods
you can not measure the element or its descendants using DOM methods
If you have a huge number of elements using visibility: none on the page, the browser might hang while rendering, as all these elements require layout, even though they are not shown
If you have a huge number of elements using display:none, they wouldn't impact the rendering as they are not part of the render tree
Resources:
https://developers.google.com/speed/docs/insights/browser-reflow
http://www.stubbornella.org/content/2009/03/27/reflows-repaints-css-performance-making-your-javascript-slow/
Performance differences between visibility:hidden and display:none
Other Info:
There are some browser support idiosyncrancies as well, but they seem to apply to very old browsers, and are available in the other answers, so I have not discussed them here.
There are some other alternatives to hide element, like opacity, or absolute positioning off screen. All of them have been touched upon in some or the other answers, and have some drawbacks.
According to this comment (Performance differences between visibility:hidden and display:none), if you have a lot of elements using display:none and you change to display: (something else), it will cause a single reflow, while if you have multiple visibility: hidden elements and you turn them visible, it will cause reflow for each element. (I don't really understand this)
One other difference is that visibility:hidden works in really, really old browsers, and display:none does not:
https://www.w3schools.com/cssref/pr_class_visibility.asp
https://www.w3schools.com/cssref/pr_class_display.asp
The difference goes beyond style and is reflected in how the elements behave when manipulated with JavaScript.
Effects and side effects of display: none:
the target element is taken out of the document flow (doesn't affect layout of other elements);
all descendants are affected (are not displayed either and cannot “snap out” of this inheritance);
measurements cannot be made for the target element nor for its descendants – they are not rendered at all, thus their clientWidth, clientHeight, offsetWidth, offsetHeight, scrollWidth, scrollHeight, getBoundingClientRect(), getComputedStyle(), all return 0s.
Effects and side-effects of visibility: hidden:
the target element is hidden from view, but is not taken out of the flow and affects layout, occupying its normal space;
innerText (but not innerHTML) of the target element and descendants returns empty string.
As described elsewhere in this stack, the two are not synonymous. visibility:hidden will leave space on the page whereas display:none will hide the element entirely. I think it's important to talk about how this affects the children of a given element. If you were to use visibility:hidden then you could show the children of that element with the right styling. But with display:none you hide the children regardless of whether you use display: block | flex | inline | grid | inline-block or not.
display:none; will neither display the element nor will it allot space for the element on the page whereas visibility:hidden; will not display the element on the page but will allot space on the page.
We can access the element in DOM in both cases.
To understand it in a better way please look at the following code:
display:none vs visibility:hidden
Related
I am working on asp.net webforms. I am displaying a asp:RegularExpressionValidator in a <td> element which validates entry in a textbox. When the page loads, it is displayed as a <span> element with visibility:hidden. The problem is that in Firefox, it still occupies space, which doesn't happen in IE and Chrome. Because of this the html is not displayed properly in Firefox. Is there any solution for this?
"Visibility: hidden;" renders the element but keeps it invisible.
If you intend not to load the element, you should use
.someElement { display: none; }
This would not even reserve the space for the specified element.
Hope this helps..
You should try display:none instead of visibility:hidden.
display:none means that the tag in question will not appear on the page at all (although you can still interact with it through the dom). There will be no space allocated for it between the other tags.
I'd recommend a different approach... I know that code depends on asp.net... I presume the thing you don't want is to have a bigger spacing because of those validators, or you don't want the layout to be expanding on error highlight, considering that, I'd suggest:
Make all validator messages having position absolute (I hope you have a container for each field, that one needs to have position: relative)
As each validator have absolute position, won't take more vertical space (it's better to add the code via a css class, which should have something like:
.validatorMessage {
position: absolute;
left:0;
top: 2rem /* should be the height of the field */
}
The only issue is, when those messages fires up, will shorten the available space, but I think is a reasonable tradeoff.
Hope this can help
Can anyone explain this behavior in FF?
Fiddle: http://jsfiddle.net/4mrt8wq3/
<style>
.b { display: inline-block; }
#a { display: block; }
</style>
<div class="b">
<label>xxxxxxxxxx</label>
<input type="text" id="a"/>
</div>
<div class="b">
<label>xxxxxxxxxx</label>
<div> / </div>
</div>
Only in firefox, the first div is positioned one line lower than the second. It works correctly in Chrome and IE (at least IE11). It's as if the block element within the inline-block is wrapping below the second element for some reason.
Using overflow: hidden on the first div fixes the problem, but the second div is then positioned slightly oddly with about 4 or 5 pixels of margin above it. Placing overflow-hidden on both causes it to render correctly.
I am not looking for a solution to the problem, as I've already found one, but I'm at a loss of explaining the behavior... Can anyone explain WHY it's doing this?
Yes, interesting question. First we need understand that the default vertical alignment of inline-block elements is baseline, and the baseline of each such element is the baseline of the last line box in them.
In the second div with class "b", the inner div itself contains a line box to hold the '/' character. That then provides the baseline for the second div with class "b".
That baseline must align level with the baseline of the first div with class "b". The question becomes: where is the baseline of the last line box in that div?
By making the input element itself display:block, Firefox¹ takes the view that the input element is "replaced", it's contents are opaque to CSS, therefore no line box is ever created by the input element. So the last line of the first div with class "b" is the one containing the label, and that is aligned level with the line of the '/' character.
Chrome takes a different view. Chrome treats the input element as having an internal structure visible to CSS, so the innards of the element form a line box, whose baseline then becomes the baseline of the first div with class "b", and it is that which aligned level with the '/' character.
When you add `overflow:hidden', it affects the baseline of the inline-blocks such that their baselines cease to be the baseline of their last contained line box, and becomes the bottom margin edge of the element.
Which behaviour is correct is unclear. It depends on history and the somewhat adulterated notion of replaced elements. In the early days of browsers, the rendering of some elements was delegated to external systems, either the underlying operating system or a plug-in. In particular, this was true of the input element, where rendering was done by O/S calls. The O/S had no notion of CSS, so rules had to be defined to allow the effectively black boxes to interact with the rest of the page. Such elements were classified as "replaced" elements.
Note the way this is defined. There is no official list of elements that are replaced elements, an element is a replaced element if the browser chooses to delegate its rendering to a system outside the CSS world, so in theory you could have two browsers, one delegating the rendering of an element and one natively rendering it, and from the CSS rules get quite different interactions.
As browsers progressed, they stopped delegating their rendering of the input element and rendered it themselves, in the process making the renderings CSS aware. This causes a problem because extant web pages, which assume that the input elements will be rendered using the replaced elements' rules, can become unusable. If a browser allowed that to happen, it would lose market share. So for the most part, to avoid this, the browsers implement those elements' layouts to interact with the page as if they were replaced elements, even though in reality they are not.
How far they go in this respect is not well specified. The HTML5 spec does not recognise the form controls as replaced elements, and suggests that they be rendered as inline-block, which would make Chrome's behaviour correct, but there are many ways in which all the browsers including Chrome simply don't behave that way. From a backward compatibility perspective with old web content, the Firefox behaviour is more reliable.
Until the layout of form controls is specified much more tightly than is the case currently, it is impossible to conclusively say which behaviour is correct.
¹For me, IE11 behaves like Firefox. Opera 28 (blink engine like Chrome) behaves like Chrome. Opera 12 (presto engine) behaves like Firefox.
Your problem is that per spec setting overflow:hidden changes the baseline position of an inline-block. Firefox implements what the spec says. Chrome does not.
Solution:
<style>
.b { display: inline-block;
vertical-align: top; /*add this line */
}
#a { display: block; }
</style>
The opposite of visibility: hidden is visibility: visible. Similarly, is there any opposite for display: none?
Many people become confused figuring out how to show an element when it has display: none, since it's not as clear as using the visibility property.
I could just use visibility: hidden instead of display: none, but it does not give the same effect, so I am not going with it.
display: none doesn’t have a literal opposite like visibility:hidden does.
The visibility property decides whether an element is visible or not. It therefore has two states (visible and hidden), which are opposite to each other.
The display property, however, decides what layout rules an element will follow. There are several different kinds of rules for how elements will lay themselves out in CSS, so there are several different values (block, inline, inline-block etc — see the documentation for these values here ).
display:none removes an element from the page layout entirely, as if it wasn’t there.
All other values for display cause the element to be a part of the page, so in a sense they’re all opposite to display:none.
But there isn’t one value that’s the direct converse of display:none - just like there's no one hair style that's the opposite of "bald".
A true opposite to display: none there is not (yet).
But display: unset is very close and works in most cases.
From MDN (Mozilla Developer Network):
The unset CSS keyword is the combination of the initial and inherit keywords. Like these two other CSS-wide keywords, it can be applied to any CSS property, including the CSS shorthand all. This keyword resets the property to its inherited value if it inherits from its parent or to its initial value if not. In other words, it behaves like the inherit keyword in the first case and like the initial keyword in the second case.
(source: https://developer.mozilla.org/docs/Web/CSS/unset)
Note also that display: revert is currently being developed. See MDN for details.
When changing element's display in Javascript, in many cases a suitable option to 'undo' the result of element.style.display = "none" is element.style.display = "". This removes the display declaration from the style attribute, reverting the actual value of display property to the value set in the stylesheet for the document (to the browser default if not redefined elsewhere). But the more reliable approach is to have a class in CSS like
.invisible { display: none; }
and adding/removing this class name to/from element.className.
Like Paul explains there is no literal opposite of display: none in HTML as each element has a different default display and you can also change the display with a class or inline style etc.
However if you use something like jQuery, their show and hide functions behave as if there was an opposite of display none. When you hide, and then show an element again, it will display in exactly the same manner it did before it was hidden. They do this by storing the old value of the display property on hiding of the element so that when you show it again it will display in the same way it did before you hid it.
https://github.com/jquery/jquery/blob/740e190223d19a114d5373758127285d14d6b71e/src/css.js#L180
This means that if you set a div for example to display inline, or inline-block and you hide it and then show it again, it will once again show as display inline or inline-block same as it was before
<div style="display:inline" >hello</div>
<div style="display:inline-block">hello2</div>
<div style="display:table-cell" >hello3</div>
script:
$('a').click(function(){
$('div').toggle();
});
Notice that the display property of the div will remain constant even after it was hidden (display:none) and shown again.
you can use
display: normal;
It works as normal.... Its a small hacking in css ;)
I use
display:block;
It works for me
Here's an answer from the future… some 8 years after you asked the question. While there's still no opposite value for display: none, read on… There's something even better.
The display property is so overloaded it's not funny. It has at least three different functions. It controls the:
outer display type (how the element participates in the parent flow layout, e.g. block, inline)
inner display type (the layout of child elements, e.g. flex, grid)
display box (whether the element displays at all, e.g. contents, none).
This has been the reality for so long, we've learnt to live with it, but some long-overdue improvements are (hopefully!) coming our way.
Firefox now supports two-value syntax (or multi-keyword values) for the display property which separates outer and inner display types. For example, block now becomes block flow, and flex becomes block flex. It doesn't solve the problem of none, but the explicit separation of concerns is a step in the right direction I think.
Chromium (85+), meanwhile, has given us the content-visibility property, and announced it with some fanfare. It aims to solve a different problem—speeding up page load times by not rendering an element (and its child layouts) until it approaches the viewport and really needs to be seen, while still being accessible for 'Find' searches, etc. It does this automatically just by giving it the value auto. This is exciting news in itself, but look at what else it does…
The content-visibility: hidden property gives you all of the same
benefits of unrendered content and cached rendering state as
content-visibility: auto does off-screen. However, unlike with
auto, it does not automatically start to render on-screen.
This gives you more control, allowing you to hide an element's
contents and later unhide them quickly.
Compare it to other common ways of hiding element's contents:
display: none: hides the element and destroys its rendering state. This means unhiding the element is as expensive as rendering a new
element with the same contents.
visibility: hidden: hides the element and keeps its rendering state. This doesn't truly remove the element from the document, as it
(and it's subtree) still takes up geometric space on the page and can
still be clicked on. It also updates the rendering state any time it
is needed even when hidden.
content-visibility: hidden, on the other
hand, hides the element while preserving its rendering state, so, if
there are any changes that need to happen, they only happen when the
element is shown again (i.e. the content-visibility: hidden property
is removed).
Wow. So it's kind of what display: none should have been all along—a way of removing an element from the layout, gracefully, and completely independently of display type! So the 'opposite' of content-visibility: hidden is content-visibility: visible, but you have a third, very useful option in auto which does lazy rendering for you, speeding up your initial page loading.
The only bad news here is that Firefox and Safari are yet to adopt it. But who knows, by the time you (dear fellow developer) are reading this, that may have changed. Keep one eye on https://caniuse.com/css-content-visibility!
In the case of a printer friendly stylesheet, I use the following:
/* screen style */
.print_only { display: none; }
/* print stylesheet */
div.print_only { display: block; }
span.print_only { display: inline; }
.no_print { display: none; }
I used this when I needed to print a form containing values and the input fields were difficult to print. So I added the values wrapped in a span.print_only tag (div.print_only was used elsewhere) and then applied the .no_print class to the input fields. So on-screen you would see the input fields and when printed, only the values. If you wanted to get fancy you could use JS to update the values in the span tags when the fields were updated but that wasn't necessary in my case. Perhaps not the the most elegant solution but it worked for me!
I ran into this challenge when building an app where I wanted a table hidden for certain users but not for others.
Initially I set it up as display:none but then display:inline-block for those users who I wanted to see it but I experienced the formatting issues you might expect (columns consolidating or generally messy).
The way I worked around it was to show the table first and then do "display:none" for those users who I didn't want to see it. This way, it formatted normally but then disappeared as needed.
Bit of a lateral solution but might help someone!
You can use display: block
Example :
<!DOCTYPE html>
<html>
<body>
<p id="demo">Lorem Ipsum</p>
<button type="button"
onclick="document.getElementById('demo').style.display='none'">Click Me!</button>
<button type="button"
onclick="document.getElementById('demo').style.display='block'">Click Me!</button>
</body>
</html>
opposite of 'none' is 'flex' while working with react native.
To return to original state put:
display=""
Use display: revert
From the documentation stated on https://developer.mozilla.org/en-US/docs/Web/CSS/revert
The revert CSS keyword reverts the cascaded value of the property from its current value to the value the property would have had if no changes had been made by the current style origin to the current element. Thus, it resets the property to its inherited value if it inherits from its parent or to the default value established by the user agent's stylesheet (or by user styles, if any exist). It can be applied to any CSS property, including the CSS shorthand property all.
It supported accross all major browsers - https://caniuse.com/css-revert-value
visibility:hidden will hide the element but element is their with DOM. And in case of display:none it'll remove the element from the DOM.
So you have option for element to either hide or unhide. But once you delete it ( I mean display none) it has not clear opposite value. display have several values like display:block,display:inline, display:inline-block and many other. you can check it out from W3C.
display:unset sets it back to some initial setting, not to the previous "display" values
i just copied the previous display value (in my case display: flex;)
again(after display non), and it overtried the display:none successfuly
(i used display:none for hiding elements for mobile and small screens)
The best answer for display: none is
display:inline
or
display:normal
The best "opposite" would be to return it to the default value which is:
display: inline
You can use this display:block; and also add overflow:hidden;
I have a div that I use to display alerts when needed.
If I want to close it after a while can I use display:none or should I use display:none as well as visibility:hidden?
So one or both.
Thank you.
Depends. If you need the space to be left blank, that is, the space won't be taken up by other elements below or around it, you'll need visibility: hidden. Otherwise, use display: none, which will allow other elements to move into the element's place.
There's no reason to use both.
If your hidden content needs to be accessible—to those with screen readers, for example—then you should not use display: none or visibility: hidden, as both can potentially hide content from screen readers. Instead, you should use a more accessible approach, such as moving the content off screen with a negative margin. See the following links for more information:
456 Berea Street: Hiding with CSS: Problems and solutions
WebAIM Blog: Hiding content for screen readers
Visibility:hidden hides the element but it still takes up space in the layout. Display:none removes it completely.
In your case, I would use Display:none
http://madisonlane.businesscatalyst.com
I'm trying to get the div#sign-post to sit above the div#bottom. This works fine in all browsers except IE6 & IE7. Can anyone see what the problem is here?
Also IE6 is displaying an additional 198px to the top of div#bottom.
Most of the answers here are wrong; some work, but not for the reason they state. Here is some explanation.
This is how z-index should work according to the spec:
you can give a z-index value to any element; if you don't, it defaults to auto
positioned elements (that is, elements with a position attribute different from the default static) with a z-index different from auto create a new stacking context. Stacking contexts are the "units" of overlapping; one stacking context is either completely above the another (that is, every element of the first is above any element of the second) or completely below it.
inside the same stacking context, the stack level of the elements is compared. Elements with an explicit z-index value have that value as a stack level, other elements inherit from their parents. The element with the higher stack level is displayed on top. When two elements have the same stack level, generally the one which is later in the DOM tree is painted on top. (More complicated rules apply if they have a different position attribute.)
In other words, when two elements have z-index set, in order to decide which will show on top, you need to check if they have any positioned parents which also have z-index set. If they don't, or the parents are common, the one with the higher z-index wins. If they do, you need to compare the parents, and the z-index of the children is irrelevant.
So the z-index decides how the element is placed compared to other children of its "stacking parent" (the closest ancestor with a z-index set and a position of relative, absolute or fixed), but it doesn't matter when comparing to other elements; it is the stacking parent's z-index (or possibly the z-index of the stacking parent's stacking parent, et cetera) which counts. In a typical document where you use z-index only on a few elements like dropdown menus and popups, none of which contains the other, the stacking parent of all the elements which have a z-index is the whole document, and you can usually get away with thinking of the z-index as a global, document-level ordering.
The fundamental difference with IE6/7 is that positioned elements start new stacking contexts, whether they have z-index set or not. Since the elements which you would instinctively assign z-index values to are typically absolutely positioned and have a relatively positioned parent or close ancestor, this will mean that your z-index-ed elements won't be compared at all, instead their positioned ancestors will - and since those have no z-index set, document order will prevail.
As a workaround, you need to find out which ancestors are actually compared, and assign some z-index to them to restore the order you want (which will usually be reverse document order). Usually this is done by javascript - for a dropdown menu, you can walk through the menu containers or parent menu items, and assign them a z-index of 1000, 999, 998 and so on. Another method: when a popup or dropdown menu becomes visible, find all its relatively positioned ancestors, and give them an on-top class which has a very high z-index; when it becomes invisible again, remove the classes.
Agree with validator comment - validating usually helps. But, if it doesn't heres a few pointers for z-index in IE:
1) elements who's z-index you're manipulating should be on the same level ie. you should be setting the z-index of #bottom and #body
if this is not feasible then
2) IE sometimes wont apply the z-index correctly unless the elements ou are applying it to have a position:relative. Try applying that property to #bottom and #body (or #signpost)
let me know how that works out
Darko
I just had this problem and the fix I found (thanks to Quirksmode) was to give the direct parent of the node you are trying to set a z-index of it's own z-index that is at less than the z-index of the node you are trying to set. Here is a quick example that should work in IE6
<html>
<head>
<style type="text/css">
#AlwaysOnTop {
background-color: red;
color: white;
width: 300px;
position: fixed;
top: 0;
z-index: 2;
}
#Header {
color: white;
width: 100%;
text-align: center;
z-index: 1;
}
</style>
</head>
<body>
<div id="Header">
<div id="AlwaysOnTop">This will always be on top</div>
</div>
<div id="Content">Some long amount of text to produce a scroll bar</div>
</body>
</html>
Welcome, I solved the problem with:
.header {
position: relative;
z-index: 1001;
}
.content {
position: relative;
z-index: 1000;
}
Looks to me like you have some malformed HTML in there. I tried counting, and perhaps I lost count of the opening and closing tags, but it looks like div#container isn't closed. Try running your page through a validator (such as W3C's HTML Validator, or something) and fixing some of the errors. That's helped me with these sorts of problems in the past. Good luck!
I've recently had an ongoing problem displaying one layer above another. In my case I was programmatically creating two layers in Javascript, one for diaplaying a custom control and one for creating a full screen layer behind it. FF was fine, bu IE displayed the full screen layer always on top of everything else.
After numerous trawls over the interweb, trying everyone's suggestions, the only way I eventually get it working was to remove position: attributes from both layers, and tweak the margin-top: attribute until I got a satisfactory result.
A bit of a hash, but it works and it'll be fine until IE 8 sorts out all of the current bugs......
the only reliable solution is, to put the top elements below in the code and then push them over the other stuff with absolute positioning.
e.g. Wordpress:
put the navigation in the footer file, but still inside the page wrapper.
might also bring some advantages for search engines, because they can directly start with the content, without crawling through the menu first...
UPDATE:
I need to correct myself. While putting the element below and then pushing it over is still the easiest way, there are certain cases when this is not possible in reasonable time. Then you have to make sure that each and every parent element has some kind of positioning and some senseful z-index. Then the z-index should work again even in IE7.