Aleksandar • Vacić

iOS bits and pieces


I first heard about AdSense few days ago, while crusing through daily blogs. Finally an ad-punching technology that actually gives you ads you are interested in.

I signed up, received confirmation in 24h and placed it online. Their script dynamically insert one iFrame to the page and writes ads in it. This script caused my Firebird 0.6 and 0.6.1 to sometimes (too often to ignore) write whole page in white, with an error

google_write_tracker is not defined

I wrote to Google support team and was pleased to receive the quick answer. Not the one I was expecting though. They were unable to see the problem and recommended me to upgrade to 0.6.1 (I was using 0.6 then). I did, problem persisted.

I could choose. Remove AdSense or change the script myself. I really didn’t want to remove AdSense (they were not given proper chance yet) so I downloaded the script and changed the offending Line 92 to this:

if (typeof(google_write_tracker) != "undefined")


Original script did not have typeof check. This is possibly Mozilla/Firebird problem, and someone else will have to check that out.

I’m happy now. Please report if the page goes all white again.

Those things that refuse to obey

While developing AD xMenu, this script was incorporated to allow menu to pass over select boxes and similar windowed controls.

It worked so good, and was so easy to implement it for any layer, that I moved it to separate script and added few bits to ease-off integration with other scripts.

What’s it for?

Take a look at this example. Maroon layer is absolutely positioned and it goes over select box.

over drawn


Did I say over?

In the old days, when there was nothing dynamic about HTML, browser makers used OS controls to draw HTML form elements. That means that they were at the “lower-level” compared to HTML browser engine and was thus untouchable for web authors. This was most obvious in revolutionary IE4. Microsoft changed this in IE5 (all form elements but drop-downs), further enhanced it in 5.5 (iframes were also moved to HTML engine); other newer browsers followed similar path.

If you are using Gecko-based or Opera 7 browser, then you don’t see a need for this script (as everything is displayed correctly for you). Same goes for Safari, as I hear. But you are a very small minority. Regular Windows users (those that we make websites for), use IE. And IE still uses OS control for one form element: select list (aka drop-down box).

So in IE, drop-down punch through the layer.

This script uses one fine trick to overcome this problem. (Danger ahead: in the following text, I will identify term browser with IE).

IE "phone-book"

This one’s very bad one.

If you load up this page you’ll see a layout which has this structure:

example layout structure - gecko/khtml/opera display

  • relatively positioned list, id=“topnav”

  • static div below it

  • relatively positioned div, id=“content”, which has some example content

In Mozilla, it apears as you (or at least I) would expect - menu goes above the remaining text. In IE, it goes below the Help section text, for reasons I thought had something to do with float + position:relative combo.

example layout structure - IE display

Real reason was this: when you define block element to be position:relative (content in my test case) this will not only reset the coordinate system for its child elements, it will also create a whole new dimension for z-index. Thus, an absolutely positioned element in the body with z-index: 400 (or I assume any other number) will go below the absolutely positioned (or floated) block with z-index:1 in the content div.

Update: I’m wrong here: new z-index context (dimension) will be created only if z-index is non-auto. Declaring only position:relative will not create new context.

This goes on for as much relative divs you have. In my example, content of 2nd relative block element was showing above the content of the 1st relatively positioned.

I named it after Michael Landis’s explanation on css-discuss list, who suggested that each pos:rel marks the beggining of the new set of pages, all above the previous ones.


Whatever you come up with. I chose not to use position: relative in the dynamic drop-down menu I was building (and encountered this).

And now, the funniest thing: IE’s behavior is by-the-book (thanks to Big John who pointed this out to me). Yes, this is how W3C specs say it must work. I must admitt that I can’t see when would one want this to behave in this manner. But I can also just be grumdgy.

Bah…every day you learn something new.

No spans. IE z-index thingie fixed.

At the original post for AD xMenu, I stated that main UL element must have position:relative. This created simplest possible solution, as it defined new coordinate system for submenus (which are absolutely positioned) and allowed me to use simple xLeft and xTop.

What I wasn’t aware of is that position:relative in IE also creates another “dimension” for z-index. After 5 days of trying this and that (I falsely accused floats as the source of problem), a good weekend spent with a girlfriend probably relaxed me enough to try something different and find a solution.

So now, ADxMenu 1.4 has a mandatory rule that you should not make your main list relatively positioned. This now means that submenu positions are calculated using xPageX and xPageY, which took few hours of testing to make sure it doesn’t break under any (yeah, right) circumstances.

Another improvement is that I removed all spans inside of A elements, which means we now have beautyful, simple unordered list of links.