Archive for August, 2011
After my previous battle with Internet Explorer 6 & 7 I ran in to yet another z-index bungle. This time it was with the advertising banners on our site. Our drop-down menus from our navigation were getting overridden by a few pesky advertisements. I increased the z-indexes on the elements conservatively and didn’t see a change. I then thought it was something imbedded within the flash and asked our resident flash expert for her opinion and she found an obscure fix that would keep SWFs from overlapping HTML.
To keep a swf from overlapping html, set the wmode parameter to “transparent”.
Example: recipe-widget at http://www.foodandwine.com/holiday-guide
<param name=”wmode” value=”transparent”>
See how the New Year’s dropdown overlays the widget.
Other examples and discussion:
This wouldn’t be something we could easily fix as the advertisements are served from an advertising partner and we would have to have the partners contact the advertisers to fix their flash advertisements. We were about to give up and deploy without a fix, as the advertisement only showed up very ocassionally on a few pages, when someone from the marketing side sent an email asking us to bump up the z-index even higher and see how that worked.
I bumped them up to about z-index: 9999; but no dice. Finally, I did what I probably should have done at the beginning and just did into the gabillion lines of code of the offending advertisement and look for z-indexes being specified. And ‘lo and behold, they were setting their ad to 1000000. Hmm. Thanks, guys!
Obviously, they wanted their advertisement to show up above anything else on the page, but that becomes a problem for us when our users wouldn’t be able to navigate the site.
I decided that so this doesn’t happen again, why not just set the z-index to the largest z-index possible? After playing with Firebug in Firefox, I found that yes, indeed there is a maximum z-index and Firefox will automatically truncate the value if the maximum is exceeded. After a little more research, the maxmum is different and what happens when you exceed the maximum depends on which browser you use.
It seems Eric Puidokas did all of the research for us and came up with this nice table explaining the maxmum values and what happens if you exceed those values.
I made a simple test page to find these limits and figure out what happens when you exceed them.
Browser Max z-index value When exceeded, value changes to: Internet Explorer 6 2147483647 2147483647 Internet Explorer 7 2147483647 2147483647 Internet Explorer 8 2147483647 2147483647 Firefox 2 2147483647 *element disappears* Firefox 3 2147483647 0 Safari 3 16777271 16777271 Safari 4 2147483647 2147483647 Opera 9 2147483647 2147483647
The “lowest” maximum value is “16777271″ but as it’s a outdated browser, I went with the common value of “2147483647″ and then “2147483646″ for the child element per my previous post.
I’m not sure if there is etiquette when it comes to using z-indexes on a page, and that’s why I was originally hesitant to make the z-index some outrageous number like “1000″ (only to find out other people seem to yawn at “1000000″) but I hope with this change, we won’t have to deal with drop-down menu z-index problems ever again.
Another annoying issue today.
After fiddling with the z-index of the menu element itself, I finally did a cursory search on Google and found quite the peculiar fix for this problem. I’m sure this is old news to the web gurus out there but I’ve been out of the loop for a few years on recent IE hacks and workarounds since I’ve mostly dove into Ruby on Rails coding full-time.
The trick to this fix is to make the parent element’s z-index higher than the child element that is having the problem. And not just the immediate parent of the child element, but the closest parent that has the relative positioning attribute defined. For me, this was 3 or 4 levels higher than my absolutely positioned child element.
Can I stop supporting IE 6 & 7 yet?
More information on the fix: Relative, z-index, and IE
For the past few months, I’ve been having problems with one pesky site that stopped working with 1Password’s auto-submit from both Safari’s and Firefox’s tool toolbar quick menu. I am assuming that the web site had recently been redesigned and the form had changed. I did what I usually did in these situations — delete the login information from 1Password and try to resubmit the form and re-save the log in information.
However, this time it didn’t work, 1Password would not even save the log in information for me ever again!
Having better things to do with my time, I dealt with the minor inconvenience for months but after having some annoying down-time at work to kill, I flexed my Google-fu and found a quick work-around for troublesome form fields that don’t want to auto-save and don’t want to auto-submit.
There is a feature that I had forgotten about, after you fill in a form, you can right-click on the form and a menu will pop-up with the option for “1Password” and under that menu will be “Save Login…” Select that option and your friendly “Save Login in 1Password” dialog will pop-up. Here, you can save your log in normally. If you’re lucky, you will be able to auto-submit again. If not, you will at least be able to have the form auto-fill and you’ll have to do the heavy lifting of just clicking the submit button.
Here is 1Password’s guide to “Website Login Issues” that may be able to help you further if you’re still having problems.