YUI Autocomplete renders under other page elements in IE7 - css

I'm working now on a page that has a column of boxes styled with sexy shadows and corners and whatnot using the example here. I have to admit, I don't fully understand how that CSS works, but it looks great.
Inside the topmost box is a text-type input used for searching. That search box is wired up to a YUI autocomplete widget.
Everything works fine in Firefox3 on Mac, FF2 on Windows, Safari on Mac. In IE7 on WinXP, the autocomplete suggestions render underneath the round-cornered boxes, making all but the first one unreadable (although you can still see enough peeking out between boxes that I'm comfortable IE7 really is getting more than one suggestion).
Where could I start looking to correct the problem?
Here's what success looks like in FF2 on WinXP:
And here's what failure looks like in IE7:

Jeremy,
Sorry for this being so late, but hopefully the answer will be of use to you in a future project.
The problem here is that IE creates a new stacking order anytime there is an element with position:relative, meaning that z-index itself is not the only controlling factor. You can read more about this here:
http://therealcrisp.xs4all.nl/meuk/IE-zindexbug.html
To solve the problem, if I'm understanding your problem correctly, apply position:relative to the container that wraps your whole autocomplete implementation (and then position:absolute to your results container). That should create an independent stacking order in IE for those elements that allows them to float over the other position:relative stacks that appear later in the page.
Regards,
Eric

The working solution I finally implemented was based on reading this explanation over and over again.
In the underlying HTML, all of the blue rounded corner elements are DIVs, and they're all siblings (all children of the same DIV).
The z-index of the autocomplete div itself (which is the great-great-grandchild of the rounded corner container div) can be arbitrarily high, and it won't fix this issue, because IE was essentially rendering the entire contents of the search box below the entire contents of the "Vital Stats" box, because both had default z-index, and Vital Stats was later in the HTML.
The trick was to give each of these sibling DIVs (the blue rounded corner containers) descending z-indexes, and mark all of them position:relative. So the blue div that contains the search box is z-index:60, the "Vital Stats" box is z-index:50, "Tags" is z-index:40, and so on.
So, more generally, find the common ancestor of both the element that is getting overlapped and the element that is overlapping. On the immediate children of the common ancestor, apply z-indexes in the order you want content to show up.

I'm not totally understanding the setup that's leading to the problem, but you might want to explore the useIFrame property of the YUI Autocomplete object -- it layers an iframe object beneath the autocomplete field, which allows the field to then float above the objects that are obscuring it in IE's buggy layout.
http://developer.yahoo.com/yui/docs/YAHOO.widget.AutoComplete.html#property_useIFrame
But the docs say that this matters in 5.5 < IE < 7, so this might not be the issue you're experiencing. So again, without totally understanding the setup you're working with, you might also want to try to experiment with various z-index values for the autocomplete field and the surrounding block-level elements.

Make sure the z-index of the auto-complete div is a larger number than the divs that constitute the rounded corner box. Microsoft puts the z-index of the top elements to 20000 or 100000 I believe. Might be wise to do the same.

I had a similar problem to this, I fixed it by basically just changing z-index for the different divs. Just setting higher number for each div in the order it should display.

Related

Z-index issue in mozila firefox, in a css only page

I know this has been asked many times, and I have been searching for the answer in a lot of places but I can't seem to fix my code. Thank you for reading this because I'm going crazy here! First I had a different z-index problem with safari, than another with explorer, but now the z-index problem I'm having with mozila I can't fix in any way. I code in chrome, where it seems to work perfectly (for me it seems at least!)
I believe now it works more or less fine in most browsers but not on mozila. The idea of the page is to make (only with CSS because that's the only language supported by the website) a flipping book of several pages. I see some examples around of CSS only flipping cards (only one page), but not a book of more than one page. So I essentially overlap several "cards", in order to give this effect. You can see the demo from codepen here: pkrein/pen/qBOewem
Btw I do know this code is not as clean as it could be, but that's the way I figured to make a fuction like that works only with CSS, and I hope it will make sense for you.
Ok, so the matter is, the content inside the book pages is not "scrollable" on firefox. I guess this is indeed a z-index problem, because when I move any page outside the book, that is, from behind the rest of the content, it scrolls fine.
Let me know if I can give any more info that could help you understand my issue!
I figured a possible solution for this. It's not quite the solution for the problem itself but it's something that can make what I want to do work.
The problem was: (what I had to remove in order to make it work):
(1) The div #content-holder holding all the text inside the flap
(2) The div .preparation-text inside the .preparation (that's the text I want to scroll). That was a scrolling div (.preparation) inside a non-scrolling div (.preparation-text). I always add a scrolling div inside a non-scrolling div in order to hide the scrollbar, by adding a high padding-right to the inside div. I know I can use code to hide the scrollbar but it do not work in all browsers.
How I fixed:
(1) I just removed the #content-holedr divs, since it was not strictly necessary.
(2) I removed the .preparation-text and transformed .preparation into a scrolling div. Then I just covered the scrollbar with an image of the same size and colors as the background (a print of the layout).

How do I get this sub menu of a three level menu aligned under it's parent?

I'm having trouble figuring this one out, it's a menu I am changing a bit to make it more usable on touch devices. Thus I need the first part of the CSS to stay as it is for normal screens, and then have to overwrite it with the touch styles. But I am trying to position the sub menu of services below services when services is selected. See the sketch. I have created a fiddle to show my problem.
My main problem, and what would solve it, is that I can't seem to get the ul.level_2 to position itself under the selected li, neither with absolute position or floating and clearing. Any ideas?
JS fiddle of problem
I sipmlyfied your example a bit to show you what is the minimal required css to achieve this. http://jsfiddle.net/3EKAq/10/
The positioning of the submenu should be fairly easy, it goes almost automaticly, no positioning required as you can see.
I think the key lies in the clearing of the menu element you want to appear on the left, the 4th one in this case. You could also consider working with the :n-th child css3 selector, but i would not do that for cross browser compatibility.
Hope this puts you in the right direction. Feel free to let us know if you need any more help!

Div float left having strange effect on Div floating right

I'm work on the CSS for a page and I can't fathom out what is going on with my floated left divs and the effect it is having on the image floated right.
http://www3.nottinghamshire.gov.uk/enjoying/countryside/countryparks/sherwood/schoolvisitsherwoodforest/
If you look at the code you'll see that the image on the page (the tour guide talking to the kids) appears directly after the first paragraph on the page. Yet it always appears level with the 3rd (and final) div that has been floated left.
This behaviour only seems to occur in the modern browsers IE8, IE9, FF, Chrome etc. IE6 and IE7 seem to deal with it in the way you'd expect.
I've been working with CSS for a number of years and was pretty confident that I could solve most CSS issues but I've been looking at this for 2 days and I can't figure out what is going on. Here's hoping that some SO experts can spot my errors and point me in the right direction.
The HTML is mainly from the CMS we are using, I don't normally nest my elements to such a great extent.
From the Visual formatting model specification,
Floats. In the float model, a box is first laid out according to the normal flow, then taken out of the flow and shifted to the left or right as far as possible. Content may flow along the side of a float.
This means that when you float a div, it doesn't appear any more "top" then it would have despite the float. Without diving into the specifics of your situation, have you tried re-arranging the order of your divs such that the tour-guide image would naturally occur at the vertical position you would like and expect?

drop down menu float Visible over UI CONTROL like TEXTBOX, select boxes, and iframes

Issue is Menu is not overlaping or float, above the IFrame i am design the menu with table and Div tag in Usercontrol From and i called Usercontrol from in the Index.aspx.
If any got the idea or experience to solve this issue please help me Thanks for Time and help
Hari
Most likely, you are running into an issue with z-index. For your menu, set the z-index for it and all of it's child controls to a high number, and then set the z-index on the iframe to a low number. If this doesn't solve your problem, you are going to need to continue setting the z-index in the parent elements of both your menu and your iframe because in some (all?) browsers, z-index does a sort of propagation, where if a parent has a lower z-index than one of its siblings, then the sibling will get priority and end up on top.
You also need to make sure that your elements have the css position property set to something other than the default, because z-index only works with positioned elements.
There are also known issues with older browsers with regards to iframes, so if you are using an older browser, try something more modern.
iframes are a tricky beast, so you are really going to have to experiment with various things to figure out your exact issue. I could provide more information, but I would need to see an example of your HTML/CSS where it isn't working.

IE (Z-index rendering problem)

I have an ASP.NET application that renders a 3rd party (Telerik's) menu control under
another control (RadDock) when the menu expands.
This artifact ONLY happens in IE7. Not in Safari/FF/Opera/Chrome (Have I left any out?)
The menu control needs to be rendered OVER the other control.
I have Google'd this a fair amount, but have yet to find a simple solution to fix it for IE7.
What is the easiest to solve this problem for IE?
Also do you know if this z-index problem has been resolved in the (pending?) IE8?
This Q is not meant to start a browser flame war. Please only respond if you have a
relevant comment.
Thank you kindly.
I don't know if this is similar or not, but I had an issue with z-indexing where when the z-index was applied to the elements of a container, but not to the container itself, the z-index wasn't being properly applied to the child elements. This manifested itself as background borders appearing over the top of the menu items that should have been on top. I solved the issue by applying the same z-index to the container holding the menu items. I don't know how the Telerik controls set up their CSS, but you may want to check that the class being assigned to the container has an appropriate z-index as well as the menu items themselves.
I've had some problems like that before, although not with the 3rd party controls you mentioned. Check to see if either of the controls sets it's own z-index conditionally if the browser is IE. If that's not the case, try setting a specific z-index for each of the controls (or their containers) to make sure IE doesn't fall back to some sort of default unknown z-index.
If the z-index changes do not fix it, it may actually be a positioning problem rather than a z-index problem. Positioning problems are quite common (from my own experience) when you try to do cross-browser compatibility.

Resources