Absolute Clearance

If you’re looking for context for this entry please see my previous post and its comments

Everything must go

Man, the internet is a tough crowd. Seriously, who uses the back button? Hehe, a broken back button was not one of the things I was testing for when attempting to make my SI_clearAbsolutes() function work with user resized text. I’m certainly glad someone noticed before the script was put to use in a production environment.

But no worries, I managed to fix the broken back button issue by using a manner of location.replace() on the dynamically generated iframe. Oddly, this only works in Firefox when called in the global namespace and not when inside a function. Fortunately this requires only slight modification to the way the script is incorporated into the XHTML.

Instead of attaching the single JavaScript file in the head it is now placed immediately before the closing body tag (something Scott Schiller recently suggested for IFR). This actually has two additional benefits (besides giving FireFox users their back button, um…back). The absolutely positioned elements are cleared earlier, before onload and possibly before the browser’s initial page draw. And it doesn’t overwrite an existing onload handler. Sweet.

Enough talk, have at these samples

Oh and curiously missing from the previous post was packaged source. Just unzip, configure the SI_url variable in the JavaScript file, upload to your server and then place the script tag immediately before the closing body tag of any document with absolutes to be cleared. Done.

Previous
This Land
Next
.htaccess Generator
Author
Shaun Inman
Posted
July 21st, 2004 at 12:39 am
Categories
CSS
JavaScript
Comments
012 (Now closed)

012 Comments

001

“Back” button gets 40% of all web-clicks… I wonder if it is really true. But I am sure, it is used pretty much.

Author
Rimantas
Posted
Jul 21st, 2004 2:05 am
002

Looks much better. Because IE doesn’t break the “Back” button anyway and to avoid the “double-smack” sound when going to the “absolutely clear” page in IE 5+ on PC, I would recommend changing the last line of code (#122) to:

if (!failed && !d.all) io.location.replace(SI_url);

Author
Dimitri Glazkov
Posted
Jul 21st, 2004 6:28 am
003

Looks great!

I didn’t mean to be a hassle when I brought that up. In fact, I would never have known if I had hit the Ctrl button before clicking the link (to open the sample in a new tab) like I had meant to. Then noticed it when I wanted to return to the article. Looks like the script is better now, though, so congratulations on an awesome script.

Also, I hate when someone posts a new technique and some people’s first reaction is to point out it’s shortcomings. That was not my intention, though it did seem that way. I didn’t realize IFRAME created a new entry in the history. That was an added lesson for me.

Thanks again for a great site, so inspirational and informative.

Author
Michael Hupp
Posted
Jul 21st, 2004 8:06 am
004

Dimitri: “double-smack?” Not sure I follow you (being a Mac user).

I appreciate everyone’s feedback. I’m not seeking praise when I share these little scripts. What I’m really looking for is everyone else’s range of experience being able to see past my own shortsightedness—just don’t take that as an invitation to bash everything I do ;D

So Michael your observation and criticism was quite welcome and resulted in a superior script.

Author
Shaun Inman
Posted
Jul 21st, 2004 8:43 am
005

With “Double-smack” I think Dimitri is referring to the “navigation/click sound” made by Internet explorer when a link is clicked (ie. a URL/page is going to be loaded etc.)

In this case it may be the “back” navigation “click” sound causing the unload of the page, which then goes to change the URL of the iFrame (causing another “click” noise)

Shaun: Thanks also for the honorable mention ;)

Author
Scott Schiller
Posted
Jul 21st, 2004 9:26 am
006

Yes, what Scott said. In IE PC, each loading of the page is accompanied by a click (or what I called “smack”) sound. Because you are re-winding the frame at the end, there are two sounds heard — one for loading the page, one for re-loading the frame.

Author
Dimitri Glazkov
Posted
Jul 21st, 2004 10:05 am
007

I think it’s great that you’re fixing the text-resizing issue, Shaun. When I first saw “Clearing absolute positioned elements” I went “omg, finally someone found a way?” and was happy. smile But then I saw what happened when resizing and I was sad. pout

However, as happy as I am, now, smile I do regret that in my Mozilla (at least) the javascript to reposition the various elements is a little too slow for comfort. I can see them jump into place after resizing back and forth. Other than that, however, I don’t really see any remaining issues with your incredibly valuable (let there be no mistake about that!) new method.

Think you can make it behave even faster, by any chance? Or is it just me that’s having a slow javascript re-calc ?

Author
Faruk Ates
Posted
Jul 21st, 2004 2:47 pm
008

It’s not just you Faruk. The delay in FireFox does bother me but it seems to be tied to when the onresize event fires rather than the speed of my script. In other browsers the event fires instantaneously (or close enough to appear so) but only fires after the content has been resized in FireFox. I guess until this is resolved we should be happy that FireFox has an almost inconsequential market share despite being superior to most of the alternatives.

Dimitri did the previous version of this script not exhibit the double smack or broken back button behavior? If not I should be able to roll the old IE PC branch back into the revised script pretty easily.

Author
Shaun Inman
Posted
Jul 21st, 2004 6:30 pm
009

Shaun, the previous version worked perfectly in IE PC. Please ignore the “fix” that that I provided in my first comment. It obviously is a goof that will simply disable the resizing altogether. Here’s the correct version (lines 106 — 125):

if (i.contentDocument) {
    // alert('w3c');
    io = i.contentDocument;
    }
else if (n.contentWindow) {
    // alert('ie5.5-6p');
    io = i.contentWindow.document;
    n.src = SI_url;
    failed = true;
    }
else if (i.document && !failed) {
    // alert('ie5m');
    io = i.document;
    }
else {
    // alert('Houston we have an IE 5.0 PC.');
    i.onresize = SI_clearAbsolutes;
    }
if (!failed) io.location.replace(SI_url);
}

Note that in your original code, checking for i.contentWindow will never return true, because when you do i = d.frames['SI_frame'] in IE, i will already contain a window object.

Author
Dimitri Glazkov
Posted
Jul 22nd, 2004 5:12 am
010

Good call Dimitri. That’ll teach me to trust logic that I piece together from code found on the internet! ;D I’ll release an update in a bit that incorporates this and renames the failed variable (which no longer seems appropriate).

Ah, isn’t peer review grand?

Author
Shaun Inman
Posted
Jul 22nd, 2004 5:24 am
011

This is all very clever (and I really do mean that) but when does it become too much hassle? When is it too much of a hack or too brittle?

Using JavaScript (even if you are not completely relying on it) just smells wrong to me.

Whilst it often frustrates me I’m more inclined to just accept that certain things can’t be done due to the current plight of browsers and HTML and move on instead. There’s plenty of other stuff to concentrate on.

I don’t mean this as a slur on your work as I am genuinely impressed. Just an honest question.

Author
Goynang
Posted
Jul 22nd, 2004 12:27 pm
012

Shaun, interesting work, but I have two concerns. These are based on being a seasoned .Net developer and long time web designer and Flash developer, working with many types of clients in many kinds of browsing and web application scenarios:

Javascripted solutions are Evil! Well, not 100% evil, but seems like alot of your solutions are based on scripting. My argument against Javascript as a solution combined with CSS is, if you have to go to all the trouble to make something work using scripts, you might as well go back to tables and get you some free DHTML menus and scripts from sites like dynamicdrive.com, where they are tested in all the agents and free. I dint see the point. I see more and more of tehse on alistapart.com and seems self-defeating. Think about it! Also, studies show that as much as 10% of people world-wide browsing the internet either dont have javascript enabled or their browser doesnt support it, or their corproate firewall/proxy is blocking scripting, or as so many mobile devices show, scripting is not supported at all in the agent, or browser or anti-virus technology has blocked it. Not good! So, throwing down the gauntlet to you, I say, can you design a positioned solution that does not use scripting whatsoever?

This same argument applies to thinsg like iframe, zoom, and all the other tricks that are prorietary to Internet Explorer only, as well. The purpose of moving to standards is to create sites that use CSS only and are simple to manage, with as few “ECMAscripted” reliances as possible. Not say that I dont use snippets of scripting to pull off tricks. I just worry that as we get deeper into these extensions, if we dont wind up where we started…tables and javascripted hat-tricks for menus, etc.

Mitchell

Author
Mitchell
Posted
Oct 9th, 2004 6:02 pm