css channel

The z-index IE bug

toby ho — Sat, 23 Aug 2008 14:38:16 -0400

Yeah, the z-index IE bug, have you heard of it? I was bitten by it a couple of days ago. In my case, I had a list of text fields in a form layed out from top to bottom. The problem is, I have these interactive drop downs on that can activate just under the text fields when you focus on the field and there is a validation error, which I use relative/absolute positioning to get in the right place, and so the position: relative declaration triggers the IE bug which causes the text field beneath the one that has the focus to occlude its drop down. My solution? I now have a javascript snippet that runs as the dom is ready that sets the z-index of all the containers(the one that has position: relative) of the text fields in descending order. So for example, if you have 10 text fields, the first one would have its z-index: 10 and the last one would have z-index: 1.

In a related note, if you use the relative/absolute positioning technique, the child element that has position: absolute is considered the child of the parent element that has position: relative in terms of z-index, which if you then have overflow: hidden on the parent element or its ancestors, the child element would get cut out if it's position is out of bounds, vs if you didn't have position: relative set on the parent element then the child would not get cut out because it's considered to be the child of the root element in terms of z-index.

Relativize that thing: todays CSS war story

toby ho — Fri, 22 Aug 2008 00:43:28 -0400

Today, I had a seemingly simple problem: position a floating label element inside of a text input field, inside a elastic layout. To achieve an effect like:

Moreover, I wanted to implement this as a generic javascript widget that I can reuse throughout the application. This was hard, real hard.

At first, I just used position: absolute and set the position of the label relative the the root document, getting the coordinates required from the position and dimension of the companion text field. Well, this didn't work so well when the window is resized. Too bad we got an elastic layout, if we had a fixed width one I would have been done. My quick and dirty solution was to register the window.onresize callback and reset the positions of the labels whenever the window is resized. This actually worked well in IE, but not so in FF. The problem with FF is that the callback is invoked too sparsely, it's just not responsive enough when you are just dragging the corner of the window around, but you see these labels in all the wrong places while you are dragging around the corner of the browser until you leave your mouse still for a second, at which point the labels receive the event and jump to where they should be. This just plain looks bad, and although your users probably won't resize the window too much, I think it will definitely give the impression of a cheesy app.

So, my first attempt at a work around is a brute force one. I wrote my onresize callback functionality for FF that is more responsive. Here was the code.
/* this is a funny hack in FF to get window resize events more often */
var ffonresize = function(){
    var listeners = [];
    var dim = document.viewport.getDimensions();
    var pe = null;
    pe = new PeriodicalExecuter(function(pe) {
        var nd = document.viewport.getDimensions();
        if (!(nd.width == dim.width && nd.height == dim.height)){
            dim = nd;
            listeners.each(function(l){l(nd)});
        }
    }, 0.2);
    return function(listener){
        listeners.push(listener);
    }
}();
/*
...
*/
if (Prototype.Browser.Gecko)
    ffonresize(this.__onResize);
else
    Event.observe(window, 'resize', this.__onResize);

This improved the situation, but... not good enough. Then I thought, there must be a way with position: relative to do it. After all, isn't that what it's for?

I tried making the label element position: relative, but this didn't work: you could shift the position of the element relative to where it would have been, but the space for where it would have been is still taken up, and now it's an empty space...
I did some research. One of the best resources is quirksmode again, this is also a helpful article. It turns out the common practice to use is to have a container that is relative and then a child under it that is absolute, which will cause the child to use the parent's position as the reference point. But trying the things out didn't work at first. After some trial and error, I figured out that, not only does the parent have to be position: relative, it also had to be display: block. My parent container happened to be table cells, so I either had to set their display to block or add a div under them. Setting their display to block didn't work for me because it completely messed up the layout of the table, so I had to go with the second method.

Adding the div was annoying because not only did I have to go to a few different places in the app to add the markup, it also made my widget depend on more. Of course, I guess I could inject the div dynamically, but I haven't tried that yet. So, this worked, I no longer had to use the onresize callback and reset the position of the labels, I just set:

position: absolute;
top: 2px;
right: 5%;

Top of 2px to give the top some space, right of 5% to give enough space for the label. Both are relative to the divs I newly added. Well, this kinda worked... except for my short textfields. See, I had long text fields that take up almost 100% of the width of the parent, but also shorter ones that take up about 60%, so while it worked well for the long textfield, sitting right inside it on the right edge, it was well outside of the short textfields. I wanted to use javascript to figure out what's the % of the width of the text field, which I could use to calculate where the label should be, but that number is in my css, and using javascript you can only get dimensions in terms of pixels, i.e., all the percentage info is lost.

What to do? Well, I calculated the percentage by doing a division between the text field and its parent's width in pixels, this is my code(using prototype.js):
right: (1 + 100 * (1 - this.field.getWidth() / this.field.up().getWidth())) + "%"

Yeah, it's pretty crazy, but it worked, beautifully. It works in IE7, FF3, and Safari, didn't work in Opera, but that could have been because other javascript bugs I had wrt Opera.

Styling Links

toby ho — Sun, 06 Jan 2008 09:06:33 -0500

Whenever you are styling links - like with background images, make sure you set display to block, otherwise things just won't work.

How to make your inner frame extend all the way to the bottom of the window-you can't

toby ho — Fri, 04 Jan 2008 14:40:20 -0500

This problem has come up a couple of times for me in the past. I shruged it off the last time, but this time I decided to do some research. What I found - as to the best of my knowledge, is that you can't. The problem is this:
I have a horizontal column that is centered in the middle of the window in my design, sort of like this. But what if the content is too short to fill up the entire screen? The bottom of the column abruptly ends and you end up with a discontinuity. There's no good way of fixing this that I am aware of. I've concluded the best way is just to use a background image at the bottom of the column to soften it's ending. Another thing I've done is to use the min-height hack to make short pages not so short. And in actuality you can use the min-height hack to make sure it always extends beyond the max of the screen, but I don't think it makes sense to create that much empty space at the bottom.

CSS recipes: min-height hack

toby ho — Thu, 03 Jan 2008 17:34:13 -0500

This really helped me out
And the order of the lines is important, make sure it's:
height:auto !important;
height:640px;
and no the other way around. And one more thing: Do not use overflow: hidden with this.