Yui Autocomplete Renders Under Other Page Elements in Ie7

YUI Autocomplete renders under other page elements in IE7

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.

YUI autocomplete misalignment problem

AutoComplete doesn't automatically brute-force the position of your AC container every time it shows, because unless you're doing inline work this is unnecessary. However, now that you've moved your input field inline, you do need to take another step to align the container, either with custom CSS or brute force JS positioning.

Here's the brute force approach.

After you define your AC instance:

oAC.doBeforeExpandContainer = function() {
    var Dom = YAHOO.util.Dom;
    Dom.setXY("myContainer", [Dom.getX("myInput"), Dom.getY("myInput") + Dom.get("myInput").offsetHeight] );
    return true;
}

Here's a working example:

http://ericmiraglia.com/yui/demos/acalign.php

YUI 3 Autocomplete Textbox Value Change

resultTextLocator was the ticket. All I had to do was to return the value I wanted to display in the box.

resultTextLocator : function (result) {
                        return result["Last Name"] + 
                        ', ' + 
                        result["First Name"];
                    }

Problem with YUI Calendar widget

Managed to find a solution. When all else fails.. just add more HTML and style.

First wrap the "calWidget" with another div (we'll give an id of "calPanel"). It will look like this.

<tr>
<td>Expiry Date</td>
<td><input name="ExpiryDate" value="" id="ExpiryDate">
         <img id="calico" src="resources/images/calendar_icon.gif" />
          <div id="calPanel">
             <div id="calWidget"></div>
          </div>
</td>
</tr>

Then with some simple CSS the "relative" calPanel wraps around the "absolute" positioned calWidget. You can fool around with the positioning of the calendar from there using left/right/top/bottom in the "#calWidget" CSS..

#calPanel {
    position:relative;
}

#calWidget { 
    display:block; 
    position:absolute; 
    left:0px;
    z-index:99;
}

Positioning seems to be consistent in IE7/8 and FF3+... Hope this helps if you have the same prob...

Google Maps, Z Index and Drop Down Javascript menus

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.

How do you deal with Internet Explorer?

Do you specify a valid doctype? You can get Internet Explorer to be a bit more compliant by switching it into standards mode. http://msdn.microsoft.com/en-us/library/bb250395.aspx#cssenhancements_topic2

Do you use a browser reset CSS file? That can help bring the versions together. http://meyerweb.com/eric/tools/css/reset/

Be aware of IE's CSS bugs: http://www.positioniseverything.net/explorer.html

For the skeleton of your layout, consider using markup that is known to work, such as http://matthewjamestaylor.com/blog/perfect-multi-column-liquid-layouts or http://960.gs/ for liquid or fixed layouts, respectively.

Keep up with JavaScript differences between browsers. jQuery handles some of them, but not all of them. http://www.impressivewebs.com/7-javascript-differences-between-firefox-ie/

Yeah, IE is a pain. If you want it to work in IE, you really want to test in IE every couple days. You don't want to save the pain for the end--you want to handle the nightmares one at a time.

---

By the way, if you think IE is a pain, try looking at your page with a mobile phone. The other day I went to REI.com with an iPhone and the middle fifth or more of the screen was taken up by a bunch of garbled markup that rendered as text.

---

Related Topics