I have multiple divs in my webpage. there is this javascript slide show and i have put a menu over that slideshow and positioned the div absolute. I have formatted the order with z-indexes. They work perfect in firefox but Internet Explorer does not work on that. what can be the solution.
Thanks in advance.
If you have a full page wrapper div anywhere or can make one or there is an ancestor/parent div you can freely alter,...
Explicitly state position: relative; or position: absolute; and either way also set z-index: 0; or the lowest value you can use.
Also some browsers (especially some IEs) allow a smaller range of z-index.
For sure values between 1 and 100 are safe. Probably more like 1-255 but I vaguely recall some old issue,...
Related
I have a table-like structure made out of different divs (and not the html tag). (kind of like an excel view).
I want to implement the fixation of the top row (header) and the first column (has some actions).
All my actions are in one view. Every row with data is a separate view and the header is a separate view.
I have presently applied position: sticky/-webkit-sticky and top: 0/left:0 as required.
This has been able to fix my problem in most browsers. However, Safari is behaving very abnormally.
My left column gets to stay fixed, but the top column on scrolling goes out of the viewPort.
Can anybody suggest some other fix or a Safari related fix?
Please find images attached below:
Sticky can be finicky. If you showed us relevant html/css it would be easier to offer solutions.
Is there a reason you can't use position: fixed; instead of sticky? unless the sticky elements are only sometimes sticky, then fixed should work.
Or maybe set the body 100% width and height, overflow: none; and then set the area you want scrollable to 100% height with overflow-y: scroll or 'auto'.
Edit: Based on your comments below.
I think I have a better idea about what you are trying to do. You want the left column to scroll up/down with the rows, but not left/right. position: sticky; may be the only way to achieve that other than javascript.
I think you should take the top row out of the equation though. Put the whole thing in one container, then setup nested containers within that. There are lots of different ways to structure it. Because position: sticky; gets positioned relative to the nearest scrollable ancestor.
I made a jsfiddle to show one possible method. https://jsfiddle.net/c9kaz854/4/ I can't test it in safari right now, but maybe you can test it, and maybe it can give you some different ideas.
I would suggest you make the same sort of structure you are going for in a simplified format. Start with a clean html file and basic css reset file. Build the basic structure and tweak it until you have something that works consistently across the browsers you need to support. Then use that basic pattern in your full site.
Because position: sticky; has inconsistent implementations in some browsers, a possible workaround for your situation could be to put the element in an <iframe>, <object> or <embed>. Then you could used position: fixed; in a more limited context.
To make that work though, you would put the top row above and outside the iframe, and all the scrollable content inside the iframe (left column and all but top row). Just have left column (inside iframe) be 'fixed.' Put the iframe in a div with overflow-y: scroll; (or auto), and make the iframe itself taller than its container div, so for vertical the scrolling happens outside the iframe, and the whole iframe element scrolls within the containing div, including the left column which is fixed inside the iframe. Then put a class on the iframe source's html/body elements and limit their width with width: 100%; (size of the container) and give them overflow-x: scroll; (or auto), so the the horizontal scrolling happens within the iframe where the left column is fixed and won't move.
I'm running into some extremely strange behaviors, and non-consistant across every browser i've tested.
I've a pretty complex layout, but the main issue lies here:
<div id="drop">
<div id="header"></div>
</div>
#drop has position:absolute and z-index:100
#header has position:fixed; top:60px;
As I start scrolling down Chrome ignores the position:fixed rule. If I remove either of the two styles above from #drop then Chrome starts respecting the position:fixed rule.
can't get it working on Ubuntu Chrome 23.0.1271.97 and see the same behavior on Mac Chrome 25.0.1364.99. My friend uses Ubuntu Chrome 25.0.1364.68 beta and it works correctly for him. I've tested it on firefox and it kinda works (with other symptoms)
Has anyone heard of this error? or can anyone even reproduce it?
edit
I'm using openlayers map as another div with position:fixed if I delete that layer or at least change it to display:none then this weird bug goes away.
edit
Noticed that during the presence of this bug, if I change the zoom level back and forth, then the position adjusts itself to the proper behavior. To me, this indicates a webkit issue that fails to execute some internal callback function on scroll.
Another extremely strange thing is that I have a few links inside of #header and they work if I just click the expected location, even though the the div does not appear there. Overall I've noticed that it's only the rendering that's broken. If at any point of time I force the browser to re-render by resizing the window, or changing zoom, or just doing Select-All, then the header bar jumps to the proper position, but does not remain fixed.
You mentioned in the comments that OpenLayers uses CSS transforms. That being the case:
the element with fixed positioning will become relative to the element with the transform - not relative to the viewport
Take a look at the spec: The Transform Rendering Model
Specifying a value other than ‘none’ for the ‘transform’ property
establishes a new local coordinate system at the element that it is
applied to.
.wpr
{
width: 200px;
height:1000px;
background: pink;
position:relative;
margin: 0 200px;
-webkit-transform: translateX(0);
transform: translateX(0);
}
.fixed
{
width: 200px;
height:200px;
margin: 50px;
position: fixed;
top:0;
left:0;
background: aqua;
}
<div class="wpr">
<div class="fixed"></div>
</div>
As the accepted answer says, this is the intended behavior, and is spec-compliant. Another important component of this is what it means to be using CSS transforms.
In your case, it was due to OpenLayers, but this applies to anyone using will-change: transform as well (probably a lot of the people visiting this question). This has been brought up on the Chromium bug tracker here, and marked as WontFix, because (as I said) it's intended behavior. The official comment is this:
This behavior is required by the spec
(http://dev.w3.org/csswg/css-will-change/): "If any non-initial value
of a property would cause the element to generate a containing block
for fixed-position elements, specifying that property in will-change
must cause the element to generate a containing block for
fixed-position elements."
The idea is that once will-change:transform is specified, you should
be able to add/remove/change transforms cheaply, without needing
fixed-position descendants to get re-layed-out.
Note that using other values of will-change (e.g. opacity, top) will
not change the positioning of fixed-position descendants.
As far as I am aware, the only solution is to make the child of the will-change element a sibling instead, to prevent the attribute from cascading.
As a side note, in my specific case, I was able to fix it by being more specific with the will-change attribute. Instead of using it on the div containing the performance-jarring element that required GPU offloading, I used it directly on the offending element. This was due to my original bad code, though, so it won't work for most cases.
You will have to place header outside the parent container drop to make it work.
I had slightly similar issues days back.For instance,if you set z-index of header,it will be attain the z-index of the parent dropcontainer.The z-index of header will be useless because it is already inside a container which has another z-index.
The same logic of z-index applies to position.
I want to add another possible solution because I was struggling with chrome ignoring position:fixed for quite some time until I finally found the culprit:
-webkit-perspective: 1000;
It was coming from a plugin I was using and causes ALL position:fixed elements to be ignored.
Hope it helps someone.
I think this is impossible, i don't think if two positions can be placed at the same place without one to collapse. But i think its better to use Avail height in javascript, i mean if you wanna an outer div to hold inner div, and outer div must cover the whole screen, use Availheight in js, this will get the screen height and then apply if, thereafter set all the divs in fixed position.
Add this to parent:
position: fixed;
...and this to the child:
position: sticky;
First of all, put something in your div as empty ones behave really weird. Then, what do you expect by putting a fixed into an absolute? Obviously, nobody knows what is the reference point of your fixed div. Should it be its parents position? which is not changing with scroll or the page position which changes? Try to use things that are completely meaningful and have a clear definition because if you fix it in chrome, what would happen with another browser? Do you really prefer to test is on all of them?
I suppose a small change in your divs so that pull the fixed div out of the absolute one or move the absolute div somewhere else.
I've been trying to use the z-index css attribute to make one element always be in front of another, but it isn't working. The z-index of one element is clearly greater than that of the other, but it is still positioned behind the other element. Could it be because one of the elements (the one showing up in front) is an iframe? Does anyone have any other advice?
For those that arrive here later, the correct answer is to put position: relative; or any of the other position props on the problematic elements.
My recommendation would be to put this on every element involved with the problem:
position: relative;
z-index: 0;
and then increase the z-index on the back-most element(s) that are in front of the iframe.
If you do that, you will start winning pretty quick.
In my testing here, z-index only works if you have position explicitly set. Test it by modulating your z-index values and then trying to highlight the text on the screen via mouse-clicking. You should see evidence of layers acting either as desired or horribly incorrect.
I find it works great if you press F12 (to open dev pane, in Chrome) and then click the Inspect Button at the top-left or press CTRL + SHIFT + C. Then you can mouseover everything and see what their stacking context is relative to adjacent elements.
UX BONUS TIP: Remember, users may want to copy text, so make sure they can select it.
If you are having problems, most likely you are either:
missing position: relative; on an element's parent, or
missing z-index: 0; somewhere
Remember that the z-index index only counts on absolute elements. Both elements should has the position:absolute. More info in the CSS 2.1 Specification
I'm using a div with position: fixed to overlap an image. This works fine in firefox, but not in IE8. The div just sits below the image, even if I play with the top and left parameters.
Example of my Problem
Is this a known bug?
This is not the only way but should give you good starting point at least.
http://jsfiddle.net/lollero/EREc7/ - Parent element that has position: relative; makes sure that the element with position: absolute being the overlapping div would stick with the image no matter where you put the image.
http://jsfiddle.net/lollero/EREc7/1/ - The same with border
You can also do something like this:
position: relative;
z-index: 4 /* The higher the number the higher the element is. make sure to*/
top: -50px;
left: 0px;
And something like this:
http://jsfiddle.net/lollero/EREc7/3/
Note that the first one is the most flexible one.
Here's a bit bigger example
http://jsfiddle.net/lollero/EREc7/4/
Examples from the comments:
http://jsfiddle.net/lollero/nBk79/1
http://jsfiddle.net/lollero/nBk79/6/
Use z-index if you're talking about layering over one another. Then you can adjust them where you want and put one on top of the other.
The nav works the same in every browser i've tested on a mac and pc; however, I cant for the life of me figure out why in IE7 the nav is appearing under the content in the main content block. Check out http://obs4.dynapp.net/ to see the problem, it only exist in IE7. Check out the source if your interested in helping out with the problem. I dunno, I've spent hours staring at html/css and cant figure anything out.
http://obs4.dynapp.net/
This is a seriously annoying IE7 bug. It occurs because positioned elements later in the DOM will be given priority over those earlier in the DOM, regardless of z-index status.
This article will explain how to fix it: http://thedesignspace.net/MT2archives/000763.html
Basically, add position and z-index to the least common ancestor. So, if your header and content are both contained in a container, add position and z-index to that container. If they're direct children of the body, add it to the body.
Hope that helps.
z-indexing is weird with IE7. You have position: absolute for your nav. You have position: relative for your content. Yes, z-indexing should work where your position doesn't matter, but IE7 will take that into affect and give you two different "stacks" for z-indexes so absolute and relative positioned elements do not interact with each other. Try giving your nav a position: relative instead and then readjusting your css accordingly.