I'm creating a custom select plugin. Everything is going great, but the dropdowns (<ul>-objects) are overlapping on each other :(
I understand, that the overlapping order is set after the elements order on page or when they are created. So my question is: What is the method to make the latest opened/shown object (<ul>) on top of the hierarchy?
I just need the correct method. I'm not going to copy the full code, but a little example:
$('#trigger').click(function () {
new_dropdown.slideDown();
});
(A picture is worth of 1000 words)
So lets say, that I open the green select the last.. How can I make it on top of the yellow one?
EDIT
For easier testing I created jsfiddle. For future references I'll post the link: http://jsfiddle.net/hobobne/uZV5p/1/ This is the live demo of the problem at hand.
What you're looking for is the CSS z-index property (higher values put elements at the front).
You could probably just set them in ascending order (e.g. set green one to 1000, yellow to 1001), but if you really need to bring it to the front when clicked, you can change the z-index with javascript
var zindex=100;
$("#trigger").click( function() {
newdropdown.css('z-index', ++zindex);
});
Here's a demo: http://jsfiddle.net/waitinforatrain/Vf7Hu/ (click the red and blue divs to bring to front).
Edit: gilly3's approach is better, and as was mentioned there may be some issues with older versions of IE.
Two ways:
Set a z-index
Setting a z-index will change the default stacking order. You can have a counter that increments and use that to set the z-index of newly stacked items. You may have issues with IE 7 or earlier, though, and those can be fixed by setting the z-index of other items. https://developer.mozilla.org/en/Understanding_CSS_z-index/Adding_z-index
Use absolute positioning, and append the div to the body
If you use absolute positioning, you can append the div to the body and still have it appear below the element. If you append the div to the body, the one last added should be on top, because of the default stacking order.
Give it a class when it is opened, and remove that class from the previously opened ones:
$(".slidedown_active").removeClass("slidedown_active");
$(this).addClass(".slidedown_active");
Then your users can use z-index in their style definition for that class to ensure the active list is always visible.
The reason I don't recommend setting the z-index directly is because you can mess up your users' layout unnecessarily. These kind of overlap issues can be a real headache for a web developer. For a plugin to try to guess at how to resolve overlap issues, without any knowledge of the code or design, would be virtually impossible. Instead, give your users the tools they need to fix the overlap issues themselves. It may be that your users would never encounter overlap issues, so setting the z-index for them would be pointless at best, and potentially harmful.
Related
I'm developing a slide in/out panel using HTML and CSS.
I notice in some CSS code examples on the internet that they set the visibility property of the div to hidden once the div is completely out of view (via some negative margin-left index or some other), and obscured by overflow: hidden of its parent container. (and then back to visible when the user slides it out again)
However, in other examples they ignore this property, instead relying on the fact that it is completely hidden due to being out of view already.
I'm curious of the differences of these two approaches. One example I can think of is performance: I'm ignorant of whether or not browser rendering engines apply better optimizations to elements that are set to visibility: hidden, because it is guaranteed that they will not be seen.
Or is the browser smart enough to realize it is not being shown? Or does none of this matter, and the performance is identical regardless of whether it is visible to the user, hidden by overflow, or hidden by visibility: hidden?
Does anyone have any insight into this? Or can recommend the best practice?
There was an interesting study done on this actually which can be found here
To save you reading it, I'd say this is the main bit you're probably after:
The renderers correspond to the DOM elements, but the relation is not
one to one. Non visual DOM elements will not be inserted in the render
tree. An example is the "head" element. Also elements whose display
attribute was assigned to "none" will not appear in the tree (elements
with "hidden" visibility attribute will appear in the tree).
Basically saying, setting an element to have a visibilty of none will not stop it getting rendered but using display: none will.
In regards to the coding examples you spoke of, I'd say it's personal preference. Some people will set the visibility to none to maybe double-cover for themselves in the case that the hidden element gets put into view but doesnt need to show a particular element, maybe also to prevent the horizontal scroll bar from appearing too?
It's definitely not needed or required though and I'd personally leave the visibility property alone in this case.
I have a wordpress theme that i'm building but i've hit a snag with some code and can't seem to get my div to expand correctly. I've tried clearing the floats at different positions, i've tried overflow: hidden, but nothing seems to work.
What i'm trying to do is have the content slide in from either side based on what header you click. The content is based on a wordpress post for each link. So the client can easilly edit it to any size.
Because of this it isn't viable to use pixels in the sizing of it. And i know that absolute positioning means that pixels are very nearly the only option.
I've messed with everything i can think of in firebug and just cannot get it to expand.
You'll find the site here: http://tinyurl.com/okd5wnf
However i couldn't get this to work either. Maybe that'll give you a clue as to what might be wrong.
I know it's a long winded post, and i apologise. If i have time later, i should be able to make a jsfiddle. However time is short at the moment.
Any help would be appreciated. Thank you very much.
Your problems stems from setting the <div class="box"></div>'s position property to absolute. Give the parent element(<div id="body-wrapper"></div>) overflow-x:hidden; to hide children that are not being displayed, and then use negative margins to position child elements within the viewport (the parent element). This is basically how most sliders work.
Remove position absolute from box class. please also mention what desired layout you need for content. we will suggest you classes for that.
Romove position:absolute from div.box
I guess that's all.
We are making this template in our language, Persian, that is right-to-left (RTL). Template address
Now, all parts are RTL, except that the submenu that opens to the right side,
Question: What changes should be made to this css file of the template, so that submenu width will be the same as its menu width? Or: How can the submenu be made to open on the left side?
Be aware that am not talking about the text in the submenu (text is rtl now as you see in picture)
Just a thought off the top of my head ...
I suspect you would adjust this line:
width: 140px; /*width of sub menus*/
to reflect a narrower width for your needs.
If you need to do this dynamically, you may have to do some work with Javascript to check the text being applied, then adjust the class reference to a custom class reference ... OR ... apply the new width to the element directly ... once the drop down entries have been filled.
Ah, ok, I see now. The problem here is that with the particular component you are using, you cannot adjust it with only CSS. The reason why is that the Javascript completely rewrites your CSS for that portion of the menu every time a user hovers their mouse over it. You're going to have to do some adjustment inside the Javascript to solve this.
There are several ways to go about this, I'm only going to get into one of them.
One way to solve this is adjust how the menu is rewriting it's CSS on the fly for the submenu. In this case, you can have the Javascript write a negative value in for the "left:" CSS element attribute to have the submenu position itself to open as you're wanting. Note: With this solution, this may not work in older Internet Explorer browsers - I'm not sure if that's a concern here. However, it will work just fine in the modern browsers (at least the ones I've been poking about with).
Open up your copy of the ddsmoothmenu.js file, that's the little bugger that is causing all the problems here.
The change needs to be done in the
$curobj.hover(function(e){..})
function. Stay with me, I'll explain...
That function is calculating the starting left position of your submenu once the user positions their mouse over the main menu choice. Namely, this line here is the culprit:
var menuleft=header.istopheader && setting.orientation!='v'? 0 : header._dimensions.w
As you can see, it is returning a '0' for you, which means it will anchor the left side of the submenu, forcing it to spill out to the right like it does now.
However, fear not!
Since you need the submenu to anchor on the right side and spill out to the left instead, we simply need to change this from assuming '0' to a formula with a little intelligence behind it.
What we need, is for the Javascript to find the correct position to anchor the submenu on the right. We do this by helping the routing understand what the "right side" of the "header" element is.
To find this, we simply take the width of the header, remove from that the left offset of the a-href tag that actually contains the header text (this is in case of any margins that exist - which this has some set in the CSS) and then remove the actual width of the submenu UL tag itself. Now as a sidenote, I wish I didn't have to use something so imprecise as assuming the header is the first child, but... eh... sometimes you work with what you got.
So comment out the line I mentioned above, and put this line in instead:
var menuleft=((header._dimensions.w-header.childNodes[0].offsetLeft)-header._dimensions.subulw);
And from what I see, it should open out towards the left as you were needing it to do in the first place.
Hope this answer helps more than my previous one.
Ok so the story is my users need a multi-select dropdownlist, which doesn't exist in ASP.NET, so the simple solution I'm going with is I'm using listboxes with multiselect on and I start them off at size 1, and onmouseover I change the size to say 10, onmouseout sets it back to one. Simple enough and the users don't know the difference.
Now, my issue comes from the fact that since I have any number of controls on my web app, I've set these listboxes to higher z-index numbers than the other controls, which creates a problem: on my listboxes closer to the bottom of the page the list expands below and not above, and part of the listbox goes under the bottom of the page but since onmouseout resets the size of the listbox I can't scroll the page down.
Does anybody know what I need to set to make it expand up instead of down?
edit Also, some may ask "why don't you just rearrange the listbox to a higher position in the page," the reason this isn't a viable option is I have well over 40 controls on the page and it they're grouped cohesively, I didn't just randomly place them where they are.(ie. investment info in one section, account in another, suitability in another)
EDIT: It's worth noting that the jQuery version of the below will be more compact and, in my opinion, more easily understood.
Glo, the code you have currently would be helpful here, especially since it seems you will have difficulty changing anything we give, or implementing what we might describe. Anyway, this works as intended in IE7, Firefox, and Opera; Safari and Chrome go quirky with it: http://jsfiddle.net/bUFzq/35/ (modified from http://www.plus2net.com/html_tutorial/html_frmddl.php).
The CSS just makes the select position-able relative to its default placement. Elements can only be positioned relative to other positioned elements. `position: relative;' leaves the element where it was until you move it, unlike absolute and fixed. It also positions relative to the edges of its nearest positioned ancestor. (The IT industry has the unfortunate convention of increasing Y downward rather than upward; just a heads up - or down.)
element.offsetHeight is the computed height of the element - how big it appears on the screen. element.style.bottom (like its cousins top, left, and right) sets the element's offset from the corresponding edge, in the direction of the element's center. setAttribute is fairly self-explanatory; it acts as if you were actually editing the HTML. Most properties of element.style (that aren't on all other objects) represent and modify similarly named CSS properties. For example, element.style.backgroundColor sets the background-color property.
addEvent is a function copied from Dustin Diaz's Rock Solid addEvent() because the browsers don't agree very well on how to do events. However, I would have put his script in a separate file and mine in yet another if I weren't working within a single script area. I did the `var addEvent = init();' thing just so you wouldn't have to scroll through his source, even though it is a good example of good code.
mouseover & mouseout are the actual listeners, explicitly called using apply 1) because I needed that height value for later and 2) because for some reason (at least within jsFiddle) it doesn't start out in the correct position, and only if the listeners are called in that order will it get there.
I've run on a little problem today: I have a JS drop down menu and when I inserted a GoogleMap... the Menu is rendered behind the Google Map... Any ideas on how to chance the z Index of the Google Map?
Thanks!
If your problem happens in Internet Explorer, but it renders the way you'd expect in FireFox or Safari, this link was extraordinarily helpful for me with a similar problem.
It appears to boil down to the idea that marking an element as "position:relative;" in CSS causes IE6&7 to mess with it's z-index relative to other elements that come before it in the HTML document, in unintuitive and anti-spec ways. Supposedly IE8 behaves "correctly" but I haven't tested it myself.
Anutron's advice is going to be really helpful if your problem is with a <SELECT> form element, but if you're using JavaScript to manipulate divs or uls to act like a drop down I don't think it's going to help.
Note that dropdown menus in some browsers (ahemIE*ahem) cannot be zPositioned at all. You'll need to use an "iframe shim" to obscure it or hide the dropdown entirely if you want to position something above it. See: http://clientside.cnet.com/wiki/cnet-libraries/02-browser/02-iframeshim
The map is already wrapped inside a div. Give it a negative z-index and it works - with one caveat: the gmaps controls aren't clickable.
If your menu is wrapped in a div container e.g. #menuWrap then assign it position relative and give it a high z-index.... e.g.
#menuWrap {
position: relative;
z-index: 9999999
}
Make sure your map is inside a div
Try setting your menu z-index insanely high. Apparently Google Maps uses a range from -9000000 to 9000000.
Wrap the map in a DIV, give that DIV a z-index of 1. Wrap your drop-down in a DIV and give it a higher value.
IE gives the problem
every div that is wrapped in a relative positioned div will start a new z-index in IE. The way IE interprets the outer relative divs, is in order of html. Last defined is on top. No matter what the z-indexes of the divs inside the relative positioned divs are.
Solution for IE: define the div that should be on top at last in html.
(So z-index does work in IE, but only per holder div, every holder div is independent of other holder divs)
z-index (especially in Internet Explorer 7) really didn't work for me. I tried many different combination's of high vs. low map z-indices but had no joy.
By far the simplest/quickest answer for me was to re-arrange my mark-up/css to have my flyouts/rollovers listed in the mark-up above/before my map (literally, before the <div id="map">), this way I could let the z-index remain default (auto) and move on to more important aspects of my webapp ;)
Hope this helps!
<ul id="rollover">
<li>There</li>
</ul>
<div id="map">...</div>
I created a google style drop-down and had the same issue...using the V3 api for google maps, you just create a control and place it on the map using:
map.controls[google.map.ControlPosition.TOP].push(control);
Since it is a drop-down, just make sure the z-index of the containing div is highest (z=3) then the drop-down part containing the menu items is lower that the containing div (z=0).
Here's an example.
From my experience, the only time you need to use shims is for plug-ins (like with Google Earth).
No need to set the z-index for both the map and the menu. If you simply set the z-index of the menu higher than the map, it won't necessarily work.
Set the z-index of the map div to -1. Now the menu will drop down and display over the map.........but if you're using a wrapper then the map will no longer be interactive as it is now behind the wrapper.
To work around this, use onmouseover and onmouseout functions in your wrapper div. Make sure those are in your wrapper div and not your map div.
onmouseover="getElementById('map').style.zIndex = '10000';"
onmouseout="getElementById('map').style.zIndex = '-1';"
I've found that sometimes inadvertently neglecting to declare the !doctype will cause this kind of hiccup in IE, when other browsers seem to be able to negotiate the page fine.