Clearing Absolutes Again

Update

A revised script that addresses the issues brought up in the comments of this post is available for discussion in Absolute Clearance.

Prompted by renewed conversation about clearing absolutely positioned elements by Eric Meyer and Mike Davidson, and a concern voiced by Simon Willison in the comments of my original post I’ve developed a revised approach to the issue.

Shortcomings of the Original Script

Previously the script I wrote required containing elements to have a specific class to indicate that they should “clear” the absolutely positioned elements inside them. On top of that, once the script ran, any resizing of text via browser controls caused the layout to either overlap in the case of enlarging the text, or spread apart when the text size was reduced. Neither limitations would be acceptable in a production environment, the first for semantic reasons and the second for accessibility/usability concerns.

Exploration

In developing this alternate approach I explored a number of options. To eliminate the inline classing of target elements I imagined setting a fictional CSS property, -si-flow: inline together with position: absolute to indicate a cleared absolute. Unfortunately Safari dashed that idea as it’s scripting engine remains blissfully ignorant of all but inline or scripted styles (I would love for someone to prove this statement wrong).

Look Ma, No Classes!

What developed instead was a logic that determines the positioning of child elements based on their parent element’s height. If all elements inside a parent element are absolutely positioned then the parent collapses resulting in an offsetHeight of 0. If one or more of the elements are absolutely positioned, then the parent element’s offsetHeight will be less than the sum of the offsetHeight of its children. Any element for which either case is true should be cleared by the script.

A Second Round of Exploration

Problem number one solved (for now). Solution number two proved a little more challenging to imagine but came together rather quickly after that. My first attempt assumed that there was no way to determine if the user had resized the text via a browser menu and instead focussed on capturing keypresses equating to the key commands that achieve the same effect. It was incomplete but a fair start I reasoned. That effort proved fruitless as the JavaScript engine in most browsers seemed to be ignorant of any keypresses that result in a predefined browser action.

The solution came to me while working on another problem and I stumble across the fact that the onresize even can be triggered on “windows and objects.” Excitedly I slapped the event on an image set it’s width and height in ems and resized the text in my browser. No luck. It turns out the event only fires on the window and document objects. So what to do?

Everybody Loves iFrames

The solution to the second problem is to dynamically create an invisible iframe, set its dimensions in ems and then load into it a small document (which is admittedly malformed to conserve bandwidth) that calls the SI_clearAbsolutes() function onresize. Now whenever the user resizes the text, the proportions of the hidden iframe change relative to the text size and an onresize event fires and redraws the page. Here are two examples of the revised script in action: a single instance and nested instances.

Problem Solved?

The only remaining concern is the dependence on scripting for layout. That is easily accommodated by setting a default height for elements that contain cleared absolutely positioned elements that is in excess of their potential offsetHeight. There may be extra scrolling for those without JavaScript or with it disabled but that is more desirable than the alternative overlapping of positioned content.